How To Prevent Coding "Heroes" From Destroying The Team

Do we really need them?

Listen to the audio version!

The world is full of problems: diseases, corruption, violence, disasters…. There are some professions in this world whose practitioners can be considered heroes that help to treat those problems: They can be doctors, police, fire brigades, NGOs…

In software development, there could also be "heroes", but they might not be what it looks like.

• They can be the ones who can help saving a burning production issue with a short-term (hack) solution. However, they don't care about the long-term implications or to fix the root cause of the problem.
• They can be the only ones to know about the specifics of something, providing the information for those who seek it. But they don't have the habit of sharing that information, which increases their Truck Factor.

Basically, if there's a problem: they are there.

Saving the day.

That’s the reason they have the title of “heroes”. And despite first impressions, it may not be a good thing to have that title because "fixing" the surface of a burning problem temporarily is not the same as fixing it's root cause.

In software development, "hero" is the name given to those individuals who are always there. Ready to save the day.

A hero have many attributes and there's no authoritative definition, although there are some people who use the same term to describe someone who "treats the symptoms of the project, like lateness or defects, but ignores the disease".

The term should not be confused with Heroic Programming which describes the "expenditure of huge amounts of (coding) effort by talented people to overcome shortcomings in process, project management, scheduling, architecture or any other shortfalls in the execution of a software development project in order to complete it".

In this post, "hero" will be the term used to those who are inefficient but can be seen as efficient by non-technical people, not Heroic Programming which treat "heroes" the ones who are efficient but can be seen as inefficient.

So what is a “hero” in software development exactly?

• It can be that person who works long hours without stop. The first one to arrive and the last one to leave the office. However, one should be able to do their job in their time, if they can’t, then that means there’s something wrong that needs to be fixed. Instead of working harder, they need to work smarter instead. This way they can achieve the same progress in less time.
• They can try to avoid meetings that don't have a direct impact on the project, like retrospectives. They might believe those meetings are useless and a waste of time. They might think the job of a developer is mostly to write code and not to care about meetings unrelated to programming, even though retrospectives are useful to foster continuous improvement.
• Their work can be "finished" quicker than anybody else, which creates the impression they are the most productive developers. However, a "hero" tend to know very little about the techniques of software development and focus mostly on the syntax instead of fundamentals. That makes them create bad code and "quick-fixes" which helps to lower the quality of the codebase. They treat the symptom of the problem instead of the root cause.
• They tend to become the only person who knows everything about the system and can be treated as a "god", even if they don't realize it. If the codebase is newcomer-unfriendly, the ramp-up of new members will be harder. The lower quality the codebase is (see the previous point), the more the hero has the opportunity to shine.
• They can be against documenting things or learning the skills for writing technical documentation. Their Curse Of Knowledge blocks them from understanding the value of making other people make sense of their work, like writing self-documented code. They find it hard to put themselves in the shoes of someone who don't know the very specific information they hold in their heads. The less documentation there is, the more the team will have to rely on the hero.
• They tend to stay with the same company for a long time because they might not have enough general skills to try new opportunities, just the domain specific knowledge they acquired in that company. Companies also tend to reward them for staying loyal, which encourage them to stay in their comfort zone and never look for other opportunities. Sometimes the only leverage they have is being a hero in that specific company or project.
• The oldest team member is usually the one who has more chances to become the hero. However, they can also be formed by new members when they don't share information about new projects. People come and go, but those who tend to become the hero are usually the ones who stay and by consequence carry a lot of domain knowledge that should have been documented somewhere, like by writing self-documented code where possible.

The hero can have many attributes. Some of them can be to be the oldest team member, carry a lot of specific domain knowledge, have a weaker programming skill, avoid certain meetings or work long hours

One thing in common is that they are always seen by other people as "saviors" while doing a bad job. What matters for some people that don't understand software is always the end result. And they know that.

That doesn't mean they do it out of arrogance or bad faith. It could be just something the environment forced them to become or believe in.

It also doesn't mean acting as a hero is always bad. Being a hero is. Anyone can act as the "hero" and step up to save a burning project temporarily, as long as they understand the implications of what they are doing and how to do it right. What they shouldn't do is act out of inexperience and take actions to fix the real cause.

Being a hero is not just bad for the company. It’s bad for themselves as professionals.

• The hero might eventually realize they are essential. Without them, some things just don't work. Once they figure that out, their ego can get bigger, which can make them believe they know better than what they actually do for similar subjects. That blocks their capacity for having an open-mind and continuously improving.
• If there's a hero, the team will have to depend on them most of the time. If the hero gets sick or goes on vacation, the impact will be very high in the delivery of the project. For that reason, the hero won’t be able to take leave or change teams at any time they want to. Their knowledge is essential to one specific project or to the company, therefore they tend to be pulled back to stay and help. That can impact their own freedom to do work-unrelated stuff.
• They will also tend to have a lot of responsibility, which can force them to work long hours. That can increase stress. It can also affect their self-improvement because they will have no time to make a proper research to solve a problem and will be forced to do a mediocre job.
• When the team sees the hero being praised, it will encourage other team members to follow the same path and that will create more heroes in different projects or areas.

The "hero" status can cause a negative impact on the company or project, including to themselves and their team

There's also an interesting type of hero: The Syntax Hero.

A lot of people knows the JavaScript specification, including the intricacies of the with statement, typeof and the subtle differences between null and undefined.

A lot of people also know that:

• The with statement can cause problems when the codebase grows because someone reading that code in the future might not be able to identify from where a variable inside that block comes, therefore it should be avoided.
• The typeof statement can also be complex and cause astonishing results (See The Principle Of Least Astonishment). The statement should be avoided for most use cases except when we want to check if a variable is undefined where a conditional would cause a syntax error (for example, if typeof undeclaredVariable !== ‘undefined’ – that’s a valid use case).
• Returning undefined in a method instead of null can break the common language convention. It might not be desirable to return undefined for a method that returns “nothing” if all other languages don't have the concept of undefined.

However, despite knowing or not about the tradeoffs of the syntax (which can increase or decrease the chances of them be acting by malice or ignorance), the Syntax Hero is the one who uses a lot of complicated features of the language in the code and ignores the common programming conventions. That will turn them into the heroes who can understand those parts of the system because of their specific programming language knowledge and their mental map of what was done, so others will have a hard time maintaining that code.

The Syntax Hero is the one who uses a lot of complicated features of the language and ignores the common programming conventions, this way he or she will become the only one who can understand it

The first step preventing a hero from being created is to prepare or adjust the environment of the project to remove the characteristics which can make them thrive.

• Permitting individual work inside a team will increase the chances of heroes to be born for specific parts of the system. Allowing a more collaborative workflow by making all decisions come from the team instead of a single person and to use techniques such as Pair Programming to share knowledge helps to remove that individuality.
• Bad code, like violating conventions and not writing in an understandable way, can create heroes with a huge Truck Factor. Forcing the team to understand the importance of legible code (by using style guides or something else), and demonstrating empathy for the next one who will touch it will allow the code to be easily handled by somebody else if it needs to. That can prevent a hero from having specific domain knowledge later that nobody else does.
• There’s a difference between being essential by centralizing information (consciously or unconsciously) and being essential by preventing information from being centralized. The former will be the hero and the latter will be the professional who will be essential to the project because of their ability to help the project to succeed. "Being essential" is not holding important information to yourself. Making the team members understand that will prevent heroes from being created.

It’s imperative to look for strategies aimed to prevent a hero from being created in the first place. After they are created, it becomes very hard and expensive to dismantle them.

The world is the same for everybody, the only thing that changes is how you see it.

It’s better to start seeing heroes as what they are, instead of treating them as benevolent gods, because they are not.

As Tina Turner puts it:

We don’t need another hero.

We don’t need to know the way home

All we want is life beyond the Thunderdome

See you on the other side 👋

Thanks for reading. If you have some feedback, reach out to me on Twitter, Facebook or Github.