The urge to do
Programming and debugging are activities where we should think a lot and do little. Commonly what happens is the reverse. We are driven by the urge to do something.
It’s particularly true for debugging. We see a problem, the first instinct is to print something, build and rerun. And then print some more. In the end when we discover the problem we go: Ah, that was obvious. I could have gotten there faster instead of these x iterations. And on complex systems these iterations take a long long time.
It often helps to resist the urge to do and think what could be going off here. It saves a ton of time.
So also for programming.
A lot of programming time is spent in the edit build debug cycle. We make numerous iterations through this cycle to get to our goal. How could we optimize this? What if we are allowed only 1 iteration through this?
To ensure that I put enough thought in the process, recently I created this game for myself. After breaking the problem into subproblems I take it as a challenge that every submodule that is built will run completely in the first iteration itself. I get to decide the size of the submodule, but my code should do exactly what I intended in the first shot. Over time I have found that this leads to a lot of efficiency by forcing me to think of all the dependencies and side effects upfront.
Of course not all problems can be addressed with this method. Especially if it’s a new technology or domain you learn much faster through each iteration. But for a lot of cases this approach does magic. You should try it out…
Originally published at kedar.blogspot.in on February 8, 2016.