As an engineer, we’re responsible for creating things that people care about deeply. Whether you’re programming something as important as a car’s operating system or as silly as an iPhone game, our code touches lives. It’s no wonder, then, that the people who interact with our products feel strongly about them — and possibly about us, as well.
This can sometimes be a good thing. It’s always touching to receive a heartfelt letter of thanks and admiration from a customer. But much more commonly, you’ll hear complaints, demands, and anger.
Under a deluge like that, it’s easy to become disillusioned and bitter. I see it all the time: programmers who hide in their shells at the slightest provocation. They make excuses, shift blame, and refuse to own their actions. I think this attitude is ultimately cowardly — if you’re willing to take credit for the good things you’ve done, you have to “take credit” for the bad stuff too. And cowardice of this sort contributes to making bad code, since your goal is no longer to to solve your organization’s problems, but to shirk responsibility.
That’s what I call coding defensively — an entirely separate subject from defensive programming. Coding defensively mires you in your codebase. It’s hard to go forward because you don’t want more responsibility, and you can’t go back because it would be admitting error. And it’s a self-reinforcing cycle: once you start becoming defensive, it’s difficult to stop.
I was a defensive coder too. I struggled to own the results of my actions: I would refuse to discuss solutions in a sensible, level-headed way. It took me a long time to change my approach, and as part of doing so I wrote a list of maxims summarizing how I wanted to think and act. When I feel myself slipping I go over them to refresh my resolve. I’m publishing them here in the hope that they’ll help someone else as much as they’ve helped me.