A Reflection of Understanding Problems

Introduction

In programming, it's possible to say understanding a problem is more important than anything else. It doesn't matter what technologies you use, or which languages you know, if you don't understand the problem, then you most likely won't be able to provide an effective nor efficient solution. As beginner programmers we (myself included) often jump at problems with gusto, excited to show off our skills we've just learned. And how often do we discover that we missed a key part of the problem that stops our solution in our tracks causing us to scrap a genius solution we had written that didn't address a key part of the problem.

Beginner Bugs and Frustrations

Over the past 5 months I have been attending flatiron school bootcamp, and I'll be graduating this week if things go as planned. I began to reflect the past couple of weeks as I finished my magnum opus or grand finale of the program about how I've grown since I started. I remembered throughout the program how often I would encounter code not doing what I expected or throwing an error, and being so frustrated because I didn't understand why. I would just reread my code and keep saying to myself this should work, why doesn't it work.

const obj = {title:"John", age:22}

if (obj.name === "John") {
    console.log(obj.age)
}
//Why doesn't this work?!?!??!

I'm sure many of us have been there. I eventually learned to calm myself during those frustrations and go through my code piece by piece. And when looking for bugs I learned to always look at my code and confirm that it is doing what I expected, to check that the object you're returning actually has a property called name and it's not actually called title or some other nonsense. Start from the beginning of the logic and work to the end. I still make those types of mistakes today, but now I recover from them more quickly and I'm able to find them in a timely manner.

Growing into New Problems

In the midst of my last project I also ran into problems, but I realized that they were different types of problems. When something doesn't work the way you expected it leaves you with a sense of powerlessness, because it means you made a typo, or you don't understand your code like you thought you did, which leads to frustration. But the type of problem I found in my project was not one of understanding why, but one of how. How could I do this? In my last project I wanted to have my front end and back end being seamlessly updated by input from the user. I knew what I wanted and as I wrote the code I saw that what I wrote wasn't going to work. I knew why it didn't work, and at that moment I didn't have an answer. However instead of that powerless feeling that I was accustomed to when facing a problem. It was the opposite! I felt empowered, I understood the problem, I could solve it! It just took some effort to work it out.

And I did, after trying a few different potential solutions, I found the one that seemed the best and I was eventually able to implement a live update feature into a budgeting web-app. The solution isn't perfect and I'm sure it could be improved upon. But working through that problem made me realize that I had made the mistake of not understanding the problem before jumping in. I went through various solutions that didn't work. One solution implemented caused the page to do a complete rerender after every character the user typed. And all of those failed solutions were pit stops on the way to my solution, but I'd like to think I might have arrived more quickly to a final solution if I had stopped to think about the problem and planned my solution a little more first.

Conclusion

Without a doubt, I have learned a lot over the past 5 months: new languages, new technologies, and new terminology, but I think I've also started looking at problems differently. And that might be the most valuable asset I've taken from the program, how to approach a problem to arrive at an effective and efficient solution.