The following quote from Buzz Andersen’s blog (which I highly recommend) caught my eye:
…full-time pairing can make the certain amount of “staring into space” time every programmer needs to get things right excruciatingly awkward.
I don’t want to dive into the pair programming discussion this time, I’ll leave this for another post. I would like to talk about staring. Staring on the code. Staring on a comment. Staring on a UML design sketch. Or, as Buzz puts it, staring into space. (*)
As far as I can tell (and I have done my fair share of staring over the years), staring is a software engineering technique where, for an extend period of time, the software developer refrains from any movement of his extremities, stops moving his eyeballs and focusses on a particular piece of code, while his CPU cores, umm, brain runs at 100% load trying to solve the problem at hand.
If we’re lucky, said developer appears to wake up from time to time, types a few characters, maybe adds a comment and resumes staring. If we’re less lucky, said developer will remain unresponsive for extended amounts of time and will make no measurable progress towards his goal.
I don’t dispute that “Staring” may be a technique to get things right, but I would like to go on the record that it’s an efficient technique to get things right. Day after day, I observe that developers “stare into space” or, even more inefficient, “stare on the code” in order to solve problems. However, I’ve never seen a problem getting solved by staring, I’ve only seen problems getting solved by adding or changing code.
Why is staring an inefficient technique, you may ask?
Staring is inefficient because it doesn’t employ a feedback loop. You are reasoning about the code with yourself. Nothing wrong with it, but there’s no one involved giving you feedback on your thoughts or challenging your assumptions – after all, it’s just you staring at the code.
If you catch yourself staring at code too often, make sure to get into the habit of doing something with the code instead:
- Even if you don’t have automated tests (and you know you should, don’t you), you can do tiny, lowest-risk refactorings which help you deepen your understanding of the code just a tiny little bit. Rename a variable, a function, extract a few lines of code to a new method, write a comment (gasp), change the formatting to suit your style (quadruple gasp). You can always revert this changes after you understood what’s going on (you do use version control, don’t you?)
- How about running the code in a debugger to get the additional feedback of variable / objects / state changes at runtime?
- How about writing unit tests? Write a test, write a little bit of code, write some more code, see a test failing, change the code, write a test to test your assumptions about specific parts of the code. Do a change to the codebase to learn something? Do the tests still run? Great. They don’t? Looks like your assumptions were wrong. Trace back, take another route.
If you absolutely must “stare” at the code, I suggest to take a step back and “sleep on it” or to take a short walk. But those are techniques which should be reserved to occasions when you really got stuck and you’re trying to solve really hard problems. Guess what, most of the time the problems aren’t that hard. They may be challenging but they are quite solvable by taking tiny, reproducible (sometimes revertible) steps towards a solution.
Code is like clay. Make sure to mold it. Carefully. You’ll learn way more by molding the code, not by staring at it.
(*) Don’t want to get into discussing “staring on web-sites not at all related to the task at hand” either.
Hello,
in my experience there are 2 extremes of coders – given the same Problem:
Coder one Hacks furiosly on the keyboard for the following 4 hours writing 2000 of lines of code and finally solves the Problem.
Coder two stares on his empty project file for 5 hours, writes a total of 50 lines of code and too, solves the Problem.
In reality most of us will do something in between.
I feel that if you actually do coding/refactoring/testing you have a very narrow focus. (BrainCPU 100% single on trad)
If you do staring you are expanding your focus to see the big picture – and sometimes find a much more elegant solution. It´s more like the RAM of the brain ist too small and you have to doo swapping.
So it really depends on the problem wicht is the most efficient technique.
But I agree with you that you can get suck in your “Staring” and sometimes coding your way too solution, or go for a walk and start with a cleard brain can help to break that loop.
Regards,
Daniel