What I have Learned at Flatiron School

Originally Posted on October 7, 2020

I am ever so close to official graduation from Flatiron after adding some new features on my snakes and ladders board game project. I thought a series of truths from completing this bootcamp would be an appropriate entry to add to my blog to sum things up. My experience at Flatiron School has really taught me just how capable I am at learning how to code, and how to code well, but it also taught me how to think at anything I do, with trial and error being my best teacher.

I would say this Flatiron bootcamp worked just like a flatiron itself, hot enough to smooth out plenty of my initial doubt of whether or not learning the skill of programming at the level I am at now was something I could achieve.

Now without further adieu what I learned…

1) I shouldn’t compare yourself to others whatever I do especially when it comes to learning to programming.

Comparing myself to others is like falling into a black hole. To really put that in perspective, a black hole has a force where gravity is so unforgiving that you need to travel even quicker than the speed of light to even have a chance to get out of it! It just isn’t fair to compare, and it takes my energy and focus away from getting things done as successfully as I can. I am sure most people have heard the “don’t compare yourself to others” lesson before, but it is so true and I’ll explain why.

It isn’t fair because everyone has their own set of life experiences and has their own strengths. Sometimes that means they have had more opportunities to spend time learning something while I’ve had certain life circumstances that make it harder or impossible for me to have spent the time that they have. On the other hand, sometimes some people have been given innate abilities to pick up on concepts faster than others.

It just doesn’t matter. The key thing to understand is their success/failure has nothing to do with making me a success or a failure. Rather it is more important to focus on what I have done, where I am going, and the steps I am taking to get there. Only I am responsible for my own destiny and nobody is just going to hand that to me neither should I expect them to. At the same time, it is always a good idea to encourage others because it is better to spread positive energy than to let the negative comparison energy suck the positive energy out of me.

2) The importance of collaborating with others and asking for help.

I firmly believe that in the forest of humanity’s achievements, a large number of achievements that are really remarkable have come from the roots of a team effort. This means that starting a happy well-knit family came from the combined efforts of a committed couple. All the big tech companies came from groups of people coming together with their ideas. Even the average small business owner who achieves success with a sole proprietorship has a loving family or friends or even their accountants to support them in accomplishing their goals.

Point being after I’ve tried my best, I have learned not to be afraid to ask for help from others to solve problems because learning from others is one way of how I become a better coder and on the flip side when I don’t think I need help, even then I make the effort to work with others even if it’s every once in a while because I’ve found I might see new ways of doing things I wouldn’t have seen before from working independently.

3) Recognize whether to solve something yourself and when not to.

Despite the importance of teamwork, I should mention this next part too. I would say it was important for me to learn the skill of being able to recognize when to ultimately solve things independently or not. What I mean is when debugging in my code, I recognized sometimes it is harder/more time consuming to receive solutions from others when they look at my code because it is harder for other people to understand your code than it is to understand it yourself. Therefore, it is sometimes faster/easier to come up with solutions yourself, that’s why it is critical to be able to have the skill of looking in the right place when googling things while working in the field of software development.

4) You know more than you realize in anything you know you’ve been putting consistent long enough effort in.

With this being said I try my best to no longer lose hope when a bug seems nearly impossible to solve. There are always ways to solve something while coding even if it means taking an entirely different approach by refactoring, it’s all a matter of trusting myself enough that I’ll find those solutions through persistent effort and process of elimination of what doesn’t work. If I don’t trust myself, I believe that will cause me to give up and if I give up that is the surest way I won’t get where I wanted to be.

See Yoda got it wrong when he said, “do or do not, there is no try”. What he should have said is, “there is always a try, oftentimes lots of tries, so with each try give it all you’ve got until it happens”. Things are more achievable than you think if you recognize how far you’ve come and keep trying.

5) How critical it is to take effective consistent enough breaks in between coding sessions

This is just a fact of programming: A lot of different processes take place when someone codes a complex application, with that comes a whole lot of thinking, and a whole lot of thinking derives a whole lot of energy from a person’s brain causing confusion in terms of trying to solve something. That’s what programming is all about; solving problems for the world through the language of technology. So, if confusion is bound to happen, then why continue to cloud my head without being able to take a break and see things from a fresh perspective after coming back to it.

I’m not suggesting taking an hour break at a time, but sometimes a quick 10-minute walk outside is what I needed to instantly solve a bug that should have been easier than I thought to solve from the start. This rang true for me multiple times.

I’ll say this next part too because I feel this needs to be said: even if I don’t run into bugs and am not feeling confused, nobody’s body/mind is a machine who can run consistently 24/7, and even if those machines can run like that, they can only do so for so long until they need maintenance. My mind will code a whole lot better if I give it small breaks to recharge. It was ironic that I found myself working faster with multiple breaks than without one.

There are so many more points I could add to this list but ultimately Flatiron’s software engineering experience was highly educational in terms of being able to get smarter in terms of programming “street smarts” and in terms of actual programming book smarts. Despite the struggles of recognizing these concepts, because yes each of them were personally difficult to accept at some point or another, personal and coding growth happened at a higher rate than I expected.

At this point I’m now full of gratitude for what I’ve been through and at the same time full of undying hope and excitement for the unknown of what happens next from here. I’m so glad the Flatiron flatiron straightened/flattened me out!