I actually wrote this around 3-months ago, forgot to post it, and just now read through it and decided it might be a worthwhile read for the struggling developer. As I move ever deeper into my programming career I still believe that programming is simple and should be approached with a simple open mind.
If you’re like me, you started learning to program later in life than the average bear. You were searching for something that would be both intellectually stimulating and creative… very difficult parameters for any standard career to meet. But the field of programming is such an outlier relative to anything else out there in the ‘real world’ abyss.
Being a decent programmer has very little to do with learning the syntax of a language and very lot to do with solving problems. You hear this mantra from almost every potential employer, “we’re looking for problem solvers.” The only problem is very few people posses this very fundamental skill. Why? We all have to solve small problems growing up. You have a flat tire and no cell phone reception… problem! You lose your house keys and phone while out getting hammered… problem! You’re kind-of ex-girlfriend sees you hooking up with another girl at a soccer game… you get my point. Maybe we’re just better suited for solving immediate pressing problems than having to sit down for hours and break an encryption app into it’s components.
I’m 10-weeks into my programming career and every day is still very challenging and requires laser like focus for extended periods of time if you want to keep up with the pace. My fellow classmates, some of the most intelligent people I’ve ever encountered seem to struggle in one way or another. The first 5-weeks of training seemed un-bearable at times. Objects as classes, methods defining behavior, instance variables defining state, dependencies, readable and writable attributes, testing methods, throwing pry bindings all over the place…. and on and on it goes with seemingly no end until you slap into the git wall and start encountering merge conflicts and failed pull requests. If you told me I would have a fundamental grasp of what I just listed 10-weeks ago, I would probably optimistically nod and doubt the possibility. But as with most things, when you apply yourself, and I mean really apply yourself good things happen.
What I’ve learned from myself and the brilliant people I’m surrounded with on a daily basis is, you have to slow down to go fast. Solving programming related issues doesn’t always come down to high IQ. Most often newbs like me spend hours upon hours on a small component of our applications only to see a more experienced programer implement something so simple you feel insulted by it. Deep down you know for a fact you could have come up with the same solution and frankly there was nothing complicated about it. It was just a different way to approach the problem. I’ve noticed that 9 out of 10 times when I can’t seem to solve a problem it’s not because I don’t have or posses the tools it’s because I don’t take those extra 5min to draw out the problem and each step on a piece of paper or just pseudo code it. This is where slowing down to go fast comes into the picture. A newbs instinct when confronted with a problem is to start typing things up without really understanding where they’re heading. Sometimes it works, which may only lead to developing a terrible habits. A more patient focused individual will sit down draw/sketch out the problem or at least one of the components and then start actually writing code.
Amazingly the fine folks at Turing warn the newbs countless times about the hurdles they are inevitably going to encounter and yet very few actually listen. Granted some people have a better ability to hold on to process and evaluate information. They’re just better thinkers, less cloudy in the head but even they’re not immune to tricky problems. Inevitably every seemingly complex problem I’ve solved turned out to be relatively simple, I just didn’t bother to incrementally take a linear step-by-step approach to solving it. I’ve since improved greatly. It’s a peculiar skill to acquire. Programming is easy it’s just not what most people are used to doing.
Humans are used to communicating with other conscious humans, not with algorithmic machines. We could easily tell a human to go to the supermarket and pick up a list of groceries but imagine telling that to a machine with it’s own language and operating system? What takes a few sentences for humans takes maybe a hundred lines for a machine. And being able to break down the steps of going to the grocery store choosing certain items in specific locations, putting those items in the cart, taking them out, putting them on the register table, waiting for them to be scanned, bagging them, paying for them, walking out of the store to the car, opening the car… you get where this is going. And that’s not even a fraction of all of the commands you have to tell your machine in order for it to properly execute. But when you think through it you realize how easy these commands are. Does it take time? Yes! But it’ll take far more time if you don’t think through the whole process in very tiny detailed increments. The newb out of the gate will skip and not think through the detailed algorithm, the master will. That’s why hard coding something that works, even if it’s 100 lines, is far better than 15 pretty lines of janky-ness. The 100 lines will easily be refactored into less than 15.