The Ten Commandments of Egoless Programming

We've all dealt with hero programmers--not a fun job. We've also all been in situations where the code that you've produced gets hammered by criticism--whether an application failure or a missed requirement--and we've also been in that same situation where the result of the code was directly affected by restraints or deficits in resources, changes in requirements, missing documentation, etc. Nothing feels worse than pouring your heart into building an application--dedicating your time and your mindfulness--only to have others throw criticism at it. An attack on your code feels like an attack on you, and it's hard not to take that personally.

I've recently become a fan of Offscreen Magazine--an excellent indie magazine well worth the added price you pay to support indie projects (I encourage everyone to give it a read). In issue 13, Offscreen reprints the Ten Commandments of Egoless Programming by Gerald M. Weinberg from his book the Psychology of Computer Programming. These Ten Commandments struck a cord with me as a programmer, and are important things that programmers, project managers, and stakeholders should keep in mind during the project lifecycle.

• There are many gems in these Ten Commandments--many of them pushing against hero programmers, ninjas, and those who wield titles like a badge of absolute, objective "rightness." Weinberg encourages us to acknowledge that, as programmers, we make mistakes, no matter how good we think we are, and that we want to try to focus on catching and tackling those mistakes well before deployment to production.

• Change is a constant in the world and Weinberg wants us to face it with a smile, understanding that change will happen, whether from a new requirement or some new technology. It is better to embrace that change than to fight against it.

• It is only knowledge that creates authority--not somebody's position-- and it important for people to understand that to create an environment of respect, one must create an environment of knowledge, that will lead to an egoless programming environment.

• You are not your code. Let's say that again: you are not your code. As mentioned above, I've often struggled with the political game that begins to fault a project. I take that personally, but really, I shouldn't. On top of that, don't be stressed out or standoffish about code reviews or when people point out bugs. They're trying to help. It's not about you, personally.

• Whether you're a ninja, wizard, or rock star (I really, REALLY hate those labels in technology), take note that there is always somebody out there who knows more than you, so don't turn down any opportunities to gain new knowledge and insights.

• It is important to fight for what you believe in, but unless it's your company, know when to accept defeat. You will be overruled on occasion. Accept it. More than that, stay humble if your ideas are rejected, but they later turn out to be the right ideas. This is just a part of growth.

• There is a difference between refactoring code and rewriting it. You should strive to make code better, but don't rewrite code just to rewrite it, or to make it your own. Weinberg wants us to remember to not rewrite code without consultation.

• Modern technology lecturing refers to dark matter developers as those that aren't involved in speaking, hackathons, or any kind of coding engagements, but sit there, do their work, and check-in their code. That's great, but be sure that you aren't being the programmer in the corner. In lean and agile environments, collaboration is key, so staying in the basement and only peeking your head out for refills of your Mountain Dew isn't the best of ideas for personal growth and success.

• There are people that will know more than you. There are also people who will know less than you. Treat those people with respect. Programmers already have reputations of being condescending and brutal towards non-technical people. Don't be that guy.

• Last, but perhaps most important when it comes to programmer-to-programmer relations is to critique the code and not the coder. Focus on improving code, improving patterns, and creating better practices. Don't let the critique degrade into criticism of work habits or a lack of knowledge. Be kind.

These commandments were created back in the early 70's, and they are still incredibly relevant today. In fact, they might be more relevant today then they've ever been. Keep them handy. In the end, they'll make you a better programmer and a better co-worker.