push.cx
Peter Bhat Harkins
Solving vs. Fixing vs. Introspecting
I liked this blog post Solving vs. Fixing (via). In my first job out of college I did support and maintenance on a medium-sized (250kloc) system that had spent a year looked after by a developer who only fixed things, never solved them. The code had started poor and gotten gotten steadily worse, but I always tried to fix bugs twice and slowly ground out improvements in the system.
So this blog post caught my eye, though I think this it misses two vitally important steps.
After you have fixed the bug and committed your code, stop and think, “How could I have found this bug faster?” Are there tools that you could’ve used to locate it quicker? Hypotheses you discarded too quickly? Some pattern in the code you overlooked? Why did it take you the time it did to find this bug, and what have you learned about how to do it better?
And then second, “Where did this bug come from?” Was it a typo? When you were originally writing the code, what test could you have written to catch it? If you misunderstood a requirement, what question could you have asked that would’ve exposed the mismatch? How could the system be redesigned to make this kind of bug impossible? What have you learned about how to code better?
Software development is design, it’s all mental processes, not a production process. The hard problems are all in the thinking, not in the typing. So you have to introspect and improve your thinking to get better at it. I don’t feel like an amazing developer, but when I recognize a design issue or a bug as something I’ve seen before I can jump ahead of colleagues to an answer. There’s no magic developer talent at work, it’s just deliberate, conscious practice, and these two questions are most of how I do that.
(If you’re wondering, the blog has been quiet lately because I’ve been putting all my free time into an art project. I’m now waiting on production and have spare brainpower again. I plan to post about it in six weeks or so.)