Most engineers don't stick with a project long enough to learn from their failures. That's a mistake.
Facebook's Mark Zuckerberg popularized the idea of "moving fast and breaking things," which is a great recipe for agile software development. In the real world, however, those broken things sometimes stay broken for a long time. Worse, the developers responsible may not stick around long enough to learn from their mistakes. I was reminded of this in a conversation with Jean-Michel Pettit, a colleague and vice president of engineering for Adobe Experience Manager (AEM). Over the last 25 years, AEM has evolved to see a significant percentage of its engineers working on the product for a decade or longer.
According to Pettit, one of the best things about having an engineering team live with a product for so long is that they have to deal with the consequences of their coding mistakes. That may not sound like much fun, but it's a great recipe for helping to develop engineers as they, in turn, develop software.
When crashing and burning is a good thing
LinkedIn engineering lead Tom Dale agrees. Citing his colleague Stefan Penner, he noted in a tweet that "when mentoring junior developers, most people know it's important to give them challenges they can grow into. But it's also important," Penner went on, that "they be responsible for fixing it when the wrong solution crashes and burns."
In other words, Dale summarized: "There needs to be a direct line between tech decisions and the costs that come with them. If someone else swoops in to clean up your mess, it's harder to reflect on and learn from your mistakes."
SEE: Job description: Platform developer (Tech Pro Research)
Recently, Dale also noticed "a correlation between the 'we need to rewrite this legacy mess!' Folks and short tenures" at the company. "They don't often have to live with the fallout of their grandiosity," he continued.
Playing helicopter engineering manager to younger developers or to older developers on so-called "legacy code" results in stunted learning. If you don't allow people to fail and learn from that failure, Penner added, "you're robbing them of key learning opportunities." This isn't a matter of "throwing them to the wolves," which might also not fit well with delivery timelines and business objectives. It's simply a matter of allowing developers to learn by doing, and "doing" must include failure.
Keeping it interesting
Of course, not everyone wants to hang out with their code to see it through its awkward teenage years and into adulthood. As EmpireJS developer Kelly Sutton hhighlighted: "Asking folks to stick around to see things behave can be hard: it's put to the engineering manager to keep the challenges interesting and continuing." Developers, he went on, "need variety after a long-running project."
So what's the secret? "Vacations and patience are key," he noted.
This might have been meant a bit tongue-in-cheek, but the principle is right, and reflects the hallmarks of great leadership and mentorship. This is arguably one of the greatest functions an engineering manager (or, really, any manager) can fill: Helping employees grow. When managers see their roles in this way, near-term code problems become long-term building blocks to developing talent within their organizations.
- How to become a developer: A cheat sheet (TechRepublic)
- Mozilla's radical open-source move helped rewrite rules of tech (CNET)
- One million Linux and open-source software classes taken (ZDNet)
- How to build a successful developer career (free PDF) (TechRepublic)
- Programming languages: Your best options (ZDNet)