After the Hero Comes

Don’t be a hero. Our work is about shared understanding, communication, and teamwork. I try very, very hard to never be a hero.

For those that aren’t familiar with the term Hero Coder, let me share. A Hero Coder is the one person that typifies the lone hacker trope. They work late into the night, all alone, and drop amazing volumes of code into your git repo each time they get on a roll. Unfortunately, nobody else on the team has an understanding of what’s going on in this new code. Your bus number is a little lower, your shared understanding has dropped, and the cost of supporting this coder’s work is unknowable.

This is why we do things like code review or pull requests, why we have demos, why we pair program. We’re on a team, and knowledge is not something to be hoarded.

So, what happens when we come to a rare situation, an emergency or deadline, and the need for a hero arises with no good alternatives? We must act, of course. But, more important, is what comes after.

Even if you’re alone in your work, you have a responsibility to be able to communicate what happened to the rest of the team later. Make it easy on yourself:

  • continue to use pull requests, even if you merge them yourself
  • catalog all work in a log, or in the PRs, especially the why
  • share links to graphite stats, splunk logs, and any other supporting evidence
  • as soon as possible, send out a retrospective email with links to PRs, and a summary from your log
  • create tickets for yourself and your team for refactoring work against each PR you made
  • demo your changes to the team at the earliest convenient time
  • document any information available around the cause of the crisis
  • discuss mitigation tactics with your team and determine if similar events or circumstances can be prevented and at what cost

All of this work is to counteract the lost understanding your team will have after you’ve done your brief hero stint. You owe it to your team, and to the future success of your work.