An often-overlooked combination of tools to develop software are pen and paper. Don’t panic, I do not propose to write a first draft of your code on paper and only use a computer for the final version. Some universities or companies in their hiring process may do that, but that is not what I mean.
A few weeks back we needed to figure out how an external API works. We wrote tests to triangulate our implementation but did not yet came up with a useful set of input and return values. The API is very talkative and accepts somewhere around 40 key-value pairs for every action. While some scenarios could profit from this verbosity, we were overwhelmed. All we wanted to do is to get simple and understandable interface to put some documents into the system and make sure that every important field is covered.
That’s when we took a step back and got us a pen and some sheets of paper. While my colleague run the test in the debugger, I wrote down the 5 to 10 fields of the response we were interested in. We did this for all the API calls and quickly ended up with an understandable overview. A few boxes and lines later, we had our wish list together and checked all the calls one more time to ensure that all the data was available. ¨
We could have done this in a text editor. However, on paper we could group the fields as we saw fit and where not forced to follow the concepts of the application. Lists can be done with ease in Excel but drawing lines and boxes to form classes is hard. On paper we switched from one form to another without any delay. Even better, we could make little changes to our lists as we found a better grouping while reviewing our ideas with another colleague. It did not look pretty, yet we had exactly what we needed to go ahead.
With all open questions answered, we wrote the necessary code in a few minutes and got everything running with the least amount of changes. I did not measure the different parts of our solution with a stopwatch, but I assume we spend less than 30 minutes with pen and paper and saved ourselves hours of rewriting code.
I therefore suggest that you get some distance between you and your code when you are stuck with a problem. A simple switch to pen and paper may be all it takes to save hours of rewriting code. Try it!