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 , there could also be "heroes", but they might not be what it looks like. software development 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 of the problem. fix the root cause 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 to describe someone who "treats the symptoms of the project, like lateness or defects, but ignores the disease". some people who use the same term The term should not be confused with which describes the "expenditure of huge amounts of (coding) effort by 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". Heroic Programming talented people In this post, "hero" will be the term used to those who are but can be seen as by non-technical people, not Heroic which treat "heroes" the ones who are but can be seen as . inefficient efficient Programming efficient 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 , they need to work instead. This way they can achieve the same progress in less time. harder smarter 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 of software development and focus mostly on . 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 . the techniques the syntax instead of fundamentals root cause They tend to become 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. the only person who knows everything about the system They can be against documenting things or learning the skills for writing technical documentation. Their blocks them from understanding the value of making other people make sense of their work, like writing 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. Curse Of Knowledge self-documented 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 where possible. self-documented code 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 is always bad. 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. acting as a hero Being a hero 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 statement, and the subtle differences between and . with typeof null undefined A lot of people also know that: The 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. with The statement can also be complex and cause results (See ). The statement should be avoided for most use cases except when we want to check if a variable is where a conditional would cause a syntax error (for example, – that’s a valid use case). typeof astonishing The Principle Of Least Astonishment undefined if typeof undeclaredVariable !== ‘undefined’ Returning in a method instead of can break the common language convention. It might not be desirable to return for a method that returns “nothing” if all other languages don't have the concept of . undefined null undefined undefined However, despite knowing or not about the tradeoffs of the syntax (which can increase or decrease the chances of them be acting by ), 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 of what was done, so others will have a hard time maintaining that code. malice or ignorance mental map 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 to share knowledge helps to remove that individuality. Pair Programming Bad code, like violating conventions and not writing in an understandable way, can create heroes with a huge . 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. Truck Factor Forcing 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 and the latter will be the 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. hero professional 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 , or . Twitter Facebook Github

Facebook

Twitter

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

How To Prevent Coding "Heroes" From Destroying The Team

Too Long; Didn't Read

Companies Mentioned

Fagner Brack

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

How To Prevent Coding "Heroes" From Destroying The Team

Too Long; Didn't Read

Companies Mentioned

Fagner Brack

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES