Page 104 -

will be blown, the hero will often take the problem home on Friday night, work all week-
end, and come in on Monday morning with a solution.

It seems like the hero is good for the team. But there are some serious downsides to his
heroics. He’s a constant scheduling problem for the project manager, because it seems that
no project can be completed without him. He’s constantly over-allocated, and there are
entire programming teams who cannot move forward because they are waiting for him to
finish a project. Meanwhile, he is constantly working 70-hour weeks, and the entire team
is afraid that he will burn out or leave the organization.
In some cases, the hero is inadvertently keeping the rest of the team from advancing,
either professionally or in the organization. It seems that the hero wrote the core of every
code library. Only he knows the details of critical architecture pieces. The hero is tired of
people talking about him getting hit by a bus, which seems to come up at least once in
every architecture or code planning meeting.
The most difficult problem to deal with in this situation is maintenance. Because of his
peculiar over-allocation problem, there is an increasing amount of code that only the hero
is able to maintain. This is usually because he was called in to write the most difficult part
of the code. Sometimes it is algorithmically difficult, and he’s the only one with enough
experience to do it. At other times, the coding task relies on a library that he wrote and
that only he knows how to use. In either of these cases, if that code needs to be updated,
the hero is the only person in the organization who is familiar with it.

Code reviews and pair programming can help alleviate the dependence on the hero.
When he writes a piece of especially tricky code, he can hold a code review. If a group of
programmers inspects that code, they will be able to maintain his code. In future projects,
they’ll be able to draw on what they learned in the review session. This will help the
entire team’s professional development. What’s more, the hero is often not much more
advanced than everyone around him; he may just know a few tricks that the rest of the
team can begin to pick up. Pair programming can be especially helpful if the hero is
teamed up with another senior programmer. Sometimes the “hero” status is merely a mat-
ter of perception—everyone just “knows” that he’s the best programmer around. Pair pro-
gramming can help everyone on the team realize that they have other people who are just

as valuable. For the true hero, sharing his skills with others will help him earn real respect
from the team. Team members will be able to continue to learn from his experience, and
he will be able to share and teach the team. The team, in turn, will come to see him as a
role model and a leader, instead of just a hero who swoops in to fix their problems.

96 CHAPTER FIVE