One of the strange paradoxes of team development is that effort beyond the call of duty is generally discouraged. Developers who are new to team working assume that, if they work wonders to solve apparently intractable programming problems in record time, then all around them will smile in gratitude. The instinct to solve problems is commendable. Older and more cynical programmers do it too, the main difference being they don’t expect any gratitude from their colleagues.

One such cynical developer recently recounted to me how, many years previously, he’d joined an IT support team whose morale was at rock bottom, drained low by the endless stream of drudge, manual maintenance tasks that prevented any “real” work. In the days before Group Policy or App-get, it was a particular pain to perform manual, machine-by-machine updates of everyone’s workstations to install the latest software updates and patches. Keen to help and impress, he found time in among his own responsibilities to write what I guess could be considered the forerunner of a tool like Chocolatey. It was suite of batch files that connected to the network and automatically updated everyone’s machine with the required software.

For a brief moment, he told me ruefully, he was a hero among men, his colleagues in tears of gratitude at how much time they “had back”. Just as quickly, however, the complaints began. New staff had replaced several of his grateful colleagues and, having never encountered the painful “old way” of doing things, they were less impressed with his handiwork. Despite the success of the system in practice, he was bewildered to find he’d suddenly gained reputation as something of a loose cannon, whose code was “clever” but impossible to understand or maintain, and had bugs!

It’s a story I’ve heard before and seen repeated in different guises many times. This tale, for example, of a programmer with a happy knack of writing clever automation scripts, follows a similar trajectory. Initially buoyed by the wild popularity of his timesaving tools, he was soon overwhelmed by complaints, requests for bug fixes and new functionality. Worse still was the dread realization that his neck was “on the hook when something stopped working at the worst possible moment”.

Team working requires great tact. Bugs attract blame. The more productive the developers are, the more bugs that are associated with them, the more maintenance tasks are required for their work, and the more likely the unintended consequences.

No achievement is impossible for individual developers in a team, as long as they expect no credit or reward for doing it. Instead of impulsively doing dazzlingly clever work, it is better to pause first to consider possible unintended consequences and strategies for preventing them. It involves ensuring that everyone in the team understands the idea, and feels they contributed to the solution. It means making sure it is maintainable, supported, well documented and robust. Now that is real heroics.