One of my favorite quotes is attributed to Martin Golding, "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." The psychopath is The Next Guy.
Often senior developers write new applications, write the hardest parts of an application, or at least set the standards to be used in writing an application. However it is usually junior and newbie developers who actually spend the most time in the code in what is the longest phase of any application: maintenance. So junior and newbie developers are The Next Guy.
Often we write code when our heads are totally wrapped around the subject matter and the technologies involved. However in two months or even less, when we go back to work with the code it might as well have been written by someone else. We are The Next Guy in this case who cannot recall what the heck is going on.
In the if-you-have-not-read-it-yet-stop-writing-code-and-read-it-first-then-get-back-to-work book Code Complete, the author reiterates a long established truth about programming: Write code for people first, computers second because computers can read ugly code but they don't have to debug and enhance it. In other words, you must keep The Next Guy in mind when writing code, it is imperative.
How do you keep the next guy in mind?
This can be done in many ways, too numerous to record here but I’ll list a few of my favorites or greatest related pet peeves when I am the next guy.
- If I am the next guy, do not make me think about, work with, or understand anything more than I absolutely have to in order to get my job done. Try to apply some level of a separation of concerns for my sake. The notion is simple really. It is easier to think about things, work with things, understand things and communicate things when we only think, work, understand, and communicate with the least amount of concerns as possible.
- Follow some coding standards so I don’t have to constantly figure out what some new convention is supposed to mean as it changes from module to module. Any standards please! If someone else already started the coding on a project using a particular convention then use theirs, I don’t care what your preference is.
- Magic data values make me mad, like violent psychopath mad.
- Widget.DetermineThis(5, “Begin”, false) – Huh?
- Write code using the core framework and basic functionality of your language. Stick to what you would expect a new developer in the chosen language and framework to understand. Anything else should be strongly contested and verified as necessary.
- We all know (or have been) the developer who reads a chapter on threading and now all the sudden everything is a needle and requires some good threading. Oooh, Microsoft LINQ I’m doing that! Generics, cool it’s not just for collections anymore. Oh yeah, I’m stick’n
- The best business application developers are not more productive because they know all the intricacies of a language. Language-certified developers scare the hell out of me. Don’t make things more complex than they absolutely have to be because I want to get in, get out, and get testing.
- In an ideal world, well-written code does not require comments. In the real world, even well-written code could use some comments of intent. Well-written comments are the Excedrin to the migraine pain of bad code.
- Use objects. At least object-based, but consider object-oriented. And no, I do not consider rudimentary knowledge of objects and object-oriented thinking to be above the newbie developer. I started teaching my daughter programming when she was nine and the first thing I taught her was what an object is. I explained it is the building block of everything and all the "smart" code you'll write is inside them. Some 10-year development veterans using an OO language like VB.Net still don’t get that.
- Apply a little defensive coding to help the next guy figure out what went wrong after they have broken the code. For example, any time you have a case statement always have an else block to check for the unexpected. Adding a new enumeration should make the code bomb if somewhere in the bowels of the code that enumeration was not expected.
- I have to stop. I could go on all night with this. However since these were the first 7 things to pop in my head I am going with them.