Two is One and One is None

You’ve probably met a developer or two who liked to talk about ‘job security’ a lot when it comes to software development. This individual is proud of their code’s complexity and lack of comments or other helpful documentation. They don’t particularly care if you can follow it or not. If you could then why would you need them, right? Job security. You review this developer’s merge requests and can’t help but notice that they are fond of chaining as many statements together as possible – readability be hanged. Job security. The code works. Heck, it may even perform well. But only this one developer truly understands it and knows what to do if it ever breaks or needs to be modified in the future. Job security.

Well I’m not buying it and neither should you. This isn’t job security. It’s a ticking time bomb that will most likely blow up when the rest of the team least expects it (and probably when Mr. or Ms. “job security” is long gone – having left the team for greener pastures). Which brings me to a mantra you may or may not have heard before – Two is One and One is None. What this means simply is, if only one person understands the code then really nobody understands the code. Because that one person could leave. Or die. Or win the lottery. You get the point. The idea that “two is one” simply means that every team needs to cross-train at least one other person (at a minimum) to understand the code. So now if our original clever developer is no longer with us (for good or bad reasons), there is still one person left who can bail the team out.

In a perfect world, multiple developers on the team would understand the code and this wouldn’t be an issue. But all too often I see ‘oh so clever’ undocumented code written by legitimately talented and highly intelligent individuals that the average developer can’t follow. Or that the average developer would have to waste 30 minutes to an hour wrapping their head around.

Why not just follow the golden rule and “do unto others as you would have them do unto you”? If you don’t want to spend 30 minutes to an hour slogging through someone else’s hard to follow code, then comment your own code. Comment it like you’re talking to someone who is brand new to your team (because whoever is reading it later will very likely be brand new to your team and not familiar with what you’re trying to accomplish). This will pay you dividends financially as well. Your teammates will appreciate it more than they will probably tell you. This type of feedback often shows up in performance reviews that often leads to raises and bonuses (or certainly can). You are building up ‘credit’ with your teammates that you can cash in later when the time comes when you need a hand understanding someone else’s code.

That's real job security.