Check your ego

Is Egoless Programming still relevant?

Natali Vlatko

Ego image via Shutterstock

It has been more than 40 years since Gerard M. Weinberg created the concept of Egoless Programming. We take a look at the treatise now to see whether the rules contained therein still serve a purpose for the modern programmer today.

Egoless Programming was initially established in Gerald M. Weinberg’s book The Psychology of Computer Programming. It’s a methodology that takes the focus away from personal factors in order to produce quality work. It’s been around for a while, too – the first edition of the book was published in 1971.

Dubbed ‘The Ten Commandments of Egoless Programming’, Weinberg coined ten edicts for all egoless programmers to live by. With the growth of programming methodologies reaching a peak of late, we wanted to revisit this historic list and see whether its message was still relevant today.

Egoless Programming – rules and relevance

1. Understand and accept that you will make mistakes

The fact that mistakes will happen in programming is pretty universally accepted, however the point to take home here is to catch them before they hit production. By employing good habits to ensure the majority of mistakes are found, a small slip here or there can be considered bearable.

Good habits include testing – lots and lots of it. If you’re testing often, that small blip on the radar can’t be blamed on your overall processes and eventually connected to a personal issue. Unless you’re writing safety-critical code, the mistakes that do slip through can be moved on from and turned into a learning process.

2. You are not your code

The second rule is trying to draw a very purposeful line between yourself (as a person with emotions, opinions and ideas) and your code, which isn’t supposed to represent those aforementioned emotions, opinions and ideas.

Sure, the code you write could be a clue as to what you know about a programming language or framework, but reviewing that code and finding problems doesn’t translate to an attack on you personally. Quite often developers get caught up in code being personal, especially in the pursuit of ‘beautiful code’.

3. No matter how much “karate” you know, someone else will always know more

No-one is a perfect software programmer. There is always more to learn and discover, and accepting this fact will help you possess a higher level of egolessness (so to speak). Expanding your knowledge and experience is never a bad idea, and investing in a lifelong learning strategy will ensure you stay technically current.

This rule can often be hampered however by the growing fixation the industry has with “rockstar programmers”. Bestowing someone with this title not only inflates their ego but also their relevance – as Scott Hanselman puts it:

  • It sets an unreasonable expectation for regular folks
  • Calling out rockstars demotivates the team
  • Telling someone they are a rockstar may cause them to actually believe it

4. Don’t rewrite code without consultation

Joel Spolsky wrote a blog post a while ago with a pretty good title related to this rule: Things You Should Never Do, Part I. Rewriting code, as opposed to fixing it, is something that Spolsky describes as “the single worst strategic mistake that any software company can make”. Why would he have thought this way?

There’s a subtle reason that programmers always want to throw away the code and start over. The reason is that they think the old code is a mess. And here is the interesting observation: they are probably wrong. The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming: It’s harder to read code than to write it.

Trying to navigate past this issue can be hard, but the idea is to develop stylistic changes within the framework of a code review, not to just throw it all away and start again. Spolsky says that when you start from scratch there is absolutely no reason to believe that you’re going to do a better job than previously, so start learning the difference between “fixing code” and a rewrite ASAP.

5. Treat people who know less than you with respect, deference, and patience

It’s hard to ignore the stereotypical view of developers and it doesn’t need to be championed by someone’s treatment of nontechnical members of staff. Culture clashes exist amongst different departments, but if your attitude is respectful and patient, you can hopefully break down those stereotypical barriers. Don’t forget: You were once a n00b, too.

6. The only constant in the world is change

Change is inevitable, especially in software development. New languages, processes and procedures come about and you need to be adept and flexible enough to keep up. Having said that, this rule also highlights the need to embrace this fact – whether that be via learning to use a new tool or altering some part of your work process.

Being open to change means being able to accept and embrace it, by looking at these opportunities as a challenge. But we all know that situations differ and there is always an exception to the rule, so it helps to be mindful of the other points in this list when considering this rule in particular.

7. The only true authority stems from knowledge, not from position

A loaded statement, this one. What Weinberg is getting at here is the importance of respect, which is earned through the accumulation of knowledge and the eventual precipitation of authority. What we want to believe is that the people who fill the important positions got there because of their knowledge and hard work, but unfortunately this isn’t always the case.

Jeff Atwood says that if you want respect in an egoless environment,  you must cultivate knowledge. The trick is to work in an environment that is egoless in the first place.

8. Fight for what you believe, but gracefully accept defeat

Thanks to the above-mentioned hierarchies, there will come a time when your contribution to the project is passed over or not favoured. Weinberg thinks you ought to fight for it tooth and nail if you can, but don’t be a sore loser about the result.

It should also be noted that being right in the long-run doesn’t always warrant a vengeful sulk about your original idea. Just because your suggestion was passed up doesn’t mean it wasn’t a meaningful contribution to the project.

9. Don’t be “the guy (or girl) in the room”

What does this mean, you ask? Weinberg is trying to warn us about becoming that person who codes alone in a dark room and doesn’t interact with their coworkers and community. That kind of employee could be seen as out of touch, out of sight and according to Atwood “has no place in an open, collaborative environment”.

10. Critique code instead of people – be kind to the coder, not to the code

Like Rule No. 2, people are not wholly represented by their code, so reviews should be conducted with only the code in mind. Reviewing comments should be positive and oriented to improving the code, not seen as a chance to personally attack someone. Your review could follow a structured format to guarantee that it doesn’t get personal.

Egoless programming has been linked to best practices for complex tasks, the promotion of open communication channels and greater conformity for consistent documentation. However, it’s also at odds with a lot of traditional corporate hierarchies, meaning that the process may not be able to exist in a “pure” way all the time.

But does that matter? Due to the time that has passed between the conception of these rules to now, do they need to be updated to reflect modern methodological thinking in development? Let us know in the comments below.

Natali Vlatko
An Australian who calls Berlin home, via a two year love affair with Singapore. Natali was an Editorial Assistant for (S&S Media Group).

Inline Feedbacks
View all comments