Surely you’re joking Mr. Feynman!

Back in the day when Richard Feynman was in high school, he would spend his free time fixing radios for some pocket money. There was something really peculiar about the way he approached the problem of figuring out what is wrong with a radio. He would sit, listen and think.

This bothered some of his customers who expected him to jump right in, open it up and work on fixing the radio. Instead he would sit or stroll around apparently doing nothing. Eventually he would open it up and fix it. In fact he would fix radios that others have failed to and became famous as “The boy who fixes radios by thinking”.

Don’t jump right in

Coding could use a similar mindset. We often find ourselves compelled into quickly jumping in and writing code. As a matter of fact, your manager or peers might get a bit uneasy when they find that you spent half a day “thinking” and have yet to write a single line of code. Yet my experience shows that jumping right in is not the optimal approach, you waste a lot of time redoing stuff and it produces the most number of defects.

Effectiveness of thinking before coding

The key concept here is to build the code paths in your head first. If you can trace this map in your head, you will find that walking it in the editor is a lot more efficient and is a lot less error prone.

I found this especially effective when writing tests. It doesn’t really matter what testing approach you use; test driven development, unit tests, black box tests or any other methodology as long as you can figure it out in your head first, the results were solid.

Dealing with bigger problems

When dealing with large and complex systems, you may find it useful to accompany your thinking with a notebook, where you can draw images and jot down some notes and thoughts. These will come really handy when things don’t go as planned and your code fails. It is very important to criticize yourself and think back to what you missed. Did you miss to think about it or did you just misunderstand. This feedback loop is necessary to build the brain muscle that will turn you into a master planner.

Building imagination

If you find it hard to imagine your code before writing it in an editor, remember that it takes time and effort to build any skill. You get better at it overtime and in some cases just like an experienced chess player, you can build-retract-build entire execution trees in a very small amount of time.

Science is not dull or boring it just requires a lot of imagination, some find that difficult — Richard Feynman

Building a habit of deep thinking goes a long way, but thats not the only thing, there are things you can do to improve yourself as an engineer and become a rockstar programmer.