When people ask what it’s like to be a programmer, I usually tell them about the basics, design something with tests, write production code to pass tests and steadily some software will start to take shape. It doesn’t have to any more exciting than that, because regardless of what I say the response will be “Can you build an app?”. If I respond with the affirmative, I will typically hear something along the lines of “Cool, I have this idea… do you think you could build it for me?”.

Now, the thing that I wonder is what would happen if I told people what programming can really be like. What if I told them, that sometimes I can spend days finding out a way to write a test, or solve a small problem. The problem can roll around in my mind endlessly, nagging at me until I solve it. The frustration can get so excessive that I start to question my choice of career “This should be simple, if I can’t solve this, maybe I’m too stupid to be a programmer!?”. Of course, when I finally solve it the sensation of achievement is huge, and extremely satisfying. No pain, no gain as they say.

Those moments of sheer frustration, where everything you try seems to have no effect. Those moments are difficult, and they are frequent. They are the “battle hardening” of the seasoned programmer. You will not find a programmer who is unfamiliar with this description. Nor for that matter, will you find many you can’t relate in some part to this. So, what follows then, is my perhaps naive, but just workable tactic for dealing with the unsolvable problem.

1. Be the immovable solver!

Quite simply, don’t give up. These problems will come back, and there is only so many times you can put off solving them. If you can, relish the opportunity to take on the challenge, a smooth sea never made a skilled sailor after all!

2. Take a step back

This is not intended to directly conflict with my first point. The skill here is the ability to take a step back and say “Am I trying to solve the right problem?”, “Is what I am trying to do the best way to tackle the problem?”. Sometimes you will see that actually, you haven’t taken the best step forward, and you can git stash, and write a new test to progress down a better route.

3. Google it!

If you hadn’t thought of this yourself, then you really are too stupid to be a programmer. Go home and get some rest.

4. Read around the problem

Consciously a different solution to number three. This is less about looking for the quick fix code example or tutorial from stackoverflow. This is about reading the documentation, given, a slightly more daunting prospect but who better to guide you through a problem than the person that has created the problem!

5. Look at the source code

Reading source code has always seemed like a scary idea to me. “Why should I look at that? I can’t even understand the documentation, why would the source code help?”. And yet, on numerous occasions the source code has provided the answer in the most succinct way possible. The more you go through this process, the easier it will become.

6. Ask for help

Gretchen Rubin writes in her bestselling book The Happiness Project that one of her “Secrets to Adulthood” is asking for help. Somewhere between being at school and being at work, asking for help becomes harder. It shouldn’t though, if anything your network should have grown, so you have even more people to ask for help from! The best thing about asking for help is, it helps! So do it!

One of the biggest challenges in this problem solving game, is gaining enough context around the problem to see what the challenge really is; sometimes knowing what to search for is half the battle. I often wondered how my more experienced colleagues were able to solve something so quickly, I know now that with experience comes context. Context, more than an ability to recall small code snippet solutions is what takes time. The more problems you solve, the more context you have to solve the next problem, so be persistent!