More Getting Past Programmer’s Block

Walking into a large code base is a real challenge. I’ve talked about reading code before, but it seems that no matter what happens you can never become a primary source. There have been plenty of times when debugging a problem you come across code that doesn’t make sense and an effort is made to determine what the original author might have been thinking. This isn’t analyzing the person’s state of mind or anything deep, but it is simply trying to understand what the programmer was worried about.

I frame this as “worry” because that is what I do. When I’m writing code, there are usually situations or cases that I’m protecting myself against. Honestly, these are probably premature optimizations, but at the same time, why introduce a bug that is easy to fix. In my mind this seems pretty reasonable, but in looking back at what others have done, my conclusion is it is a terrible idea. Code is there to tell the computer what to do and not what some requirement was at the time or the intent of the programmer. In school we learn to write criticisms dealing only with the subject of critique, yet as programmers, we often inject small snippets of code that really require some background to make any sense at all.

Lately, when I hit snags in my understanding of the code, my recourse has been to step away and try writing something about it. This may be a waste of time, but it does help battle the morale beating nature of reading code. There is nothing worse than having a large piece of code in your editor and constantly putting print statements all over the place only to keep missing the one detail that is important. You feel as though you’re incompetant and in adequant and indeserving of the title “programmer”. So, when this happens, it only makes sense to try a little deconstruction of the issues you’re facing and write about it in hopes someone else might find help or you can talk through the problem.

The technique is not new, but it is still difficult to master. When I worked in an office, there were many times where I’d close the door to really focus. That privacy often led me to start talking to myself, which in turn ended up being an effective means of working through a problem. When I was young, we took a test that help reveal what kind of learner you were. I ended up auditory, which makes a good deal of sense as I’m also a musician. The obvious downside of simply writing about problems is that I don’t get the auditory aspects of the process. That said, I think it is still useful as it means there is still a requirement to improve my communication skills, something that is always useful.

Someday, I really hope that my understanding of the code base is like that of a primary source. It is really nice to have the confidence and understanding of the problem and implementation when maintaining code. If you are the one writing code for the first time, please consider this second source maintainer. This is kind of a “duh” idea to most programmers, yet in practice, I’d argue that most developers miss their non-x86 audience.