Andrea: “Unhappy is the land that breeds no hero.”
Galileo: “No, Andrea: Unhappy is the land that needs a hero”

If you ask children what they want to be when they grow up, chances are that you get answers from this list: police officer, firefighter, astronaut, rock star. Children nearly always choose professions that are accompanied with acclamation, jobs where they can shine, where they can be big.

Even as adults, most of us still want to be heroes (or heroines), at least to some extent. This desire is deeply rooted in all human cultures and societies: Those who act, especially at the peril of their own lives, get praise and reward.

Strangely enough, the yearning for recognition is sometimes so strong, that people who should actually help in hazardous situations deliberately create them, just to get a chance to prove their bravery. You have probably heard about cases where firefighters set buildings on fire, just to be the first on the scene to extinguish it. This phenomenon is called “hero syndrome” and is an extreme form of degenerated professionalism, but it nevertheless does happen.

There is a lot of heroism going on in software development as well. Many software projects, for lack of software engineering knowledge and discipline, rely on heroics; the successful outcome totally depends on individuals who work crazy hours in an endless code-and-fix cycle. Especially the game industry has gained a sad reputation for such malpractice.

But sometimes it is not the companies which foist heroics upon their developers — sometimes, and much in line with the hero syndrome, developers deliberately create “hero situations” themselves.

One case in point is when developers accept impossible assignments in hope to get praise by their bosses for making the impossible happen, cases, where a clear, professional “No” would haven been the right answer. In his book “The Clean Coder” Uncle Bob cites a programmer whose words say it all: “I hit SEND, lay back in my chair and with a smug grin began to fantasize how the company would run me up onto their shoulders and lead a procession down 42nd Street while I was crowned ‘Greatest Developer Ev-ar'”.

By accepting ridiculous schedules and working ridiculous hours, such “heroes” not only put their pesonal well-being at risk, they also put their companies future at risk, at least for two reasons: first, if management is told that something which is highly improbable is doable, they might not look for alternatives, they might not set up a life-saving plan B; second, by leaving rushed, brittle, unmaintainable quick-hack code behind that nobody understands or dares to change.

But I’ve also met developers who gold-plate their code, write overly complicated code, or fervently and constantly use the most obscure language features — C++ template meta-programming immediately comes to mind — just to show everyone how clever they are. Again, the only thing such “heroes” usually achieve is that coworkers don’t dare touching their abominations — there is no praise at all, just head-shaking. This behavior is quite the opposite of what modern software development practices demand: software minimalism; that is, the simplest code that works, code that is easy to read, refactor, and extend by everyone — the basis for one of the most important software values: evolvability.

To me, people who behave in such a manner are no heroes at all, in fact they are quite the opposite of a hero. What they do is not a selfless act in order to help others but rather an act of selfishness that almost always hurts others. A wise manager would advise these folks to consult a specialist to get over their inferiority complex; if that doesn’t help, to seek their luck elsewhere, in the game industry, for instance.

By contrast, true heroes are invisible, they shun the limelight. They do things because they know that the overall benefit of their action is by far larger and more important than their own personal benefit. They are heroes because they do things that are right and not things that just shine bright.

There are firefighters out there who save lives every day, and some of them can rightly be called heroes. But the even bigger heroes are the people who probably nobody knows, people who work out fire protection standards — they must have saved hundreds of thousands of lives over the last century. Benjamin Franklin’s saying “An ounce prevention is worth a pound of cure” is what they live by. Such heroes, modest people who strive to prevent, are the true role models of every software professional.