I used to idolize a developer on my team who was a lone wolf. He wrote the most code and came up with the most complex systems. He would disappear into the abyss for weeks and emerge with sacred deliverables that only he could have fashioned in that period of time.

    Everyone looked up to the lone wolf, and I modeled my behavior after him as I went on to work at another company. I strove to be the guy who kept track of everything about a system in my head. I took immense pride in cranking out large features in isolation and adored the idea that others would have to come to me for deeply nested voodoo knowledge that I alone possessed.

    Then, I left for vacation for a week. As you can imagine, it was a painful experience for both me and my team—all because I had my hands in many areas of code and didn’t make any effort to develop sustainable code and artifacts.

    I never relied on having any documentation. My team had been conditioned to just reach out over instant message with questions, and I would reply right away. When making larger changes in the codebase, I outlined patterns so intricate that they inevitably led to misuse. Neglecting this support meant that others who would attempt to help while I was unavailable were set up for confusion.

    The code I worked on rarely had dire bugs, and because of this, I found it quicker to skip writing tests altogether. Nobody complained since I would fix issues myself anyway in the event that something came up. Unfortunately, the code you write in the office doesn’t take a break while you’re on vacation, and I ended up being pinged during my trip when a cryptic error showed up that was related to something I had worked on.

    My work-life balance was abysmal. After this first vacation debacle, I found myself checking in on vacations—the one time I was supposed to be disconnecting entirely. But vacations weren’t the only time my quality of life suffered; it did so in my day-to-day as well. I remember going out to eat with a friend for breakfast one morning before work and checking my phone non-stop, even rudely pausing mid-conversation a few times just to reply to a few questions from coworkers.

    I didn’t learn my lesson by the time I left that company. Absurdly, I found myself scrambling even after I put in my notice that I was leaving for a position with another organization. I still cared deeply about the product and my coworkers, so I frantically tried to make up for lost time by brain dumping as much documentation as I could into a huge manifest. There are many problems with this approach, but the biggest one was that nobody was ever going to read it because it was so overwhelming and haphazardly written.

    The bottom line is that in an effort to help my team, I actually hindered them. I certainly helped make things happen fast, which is what teams may need from time to time. But my lack of diligence ended up making everything I touched brittle, and it became clear that I sacrificed resilience and cross-training so that I could deliver more features in the short term.

    I had turned into my idol, the lone wolf developer, only to realize that I had chosen the wrong role model.

    Software development can be a funny profession. In no other field can two similar roles be titled by something as dry as “Software Engineer IV” to something as outlandish as “Ninja Code Wrangler.”

    Hiring gimmicks aside, hero worship is something to which software teams are not immune. Perhaps it stems from the Hollywood trope of a programmer who functions as a one-man army, feverishly coding throughout the night in a caffeine-induced state of transcendence, all to emerge with pristine code that could have only been forged under such grueling conditions.

    One of the terms used to describe such a person is “rock star.” But although these so-called rock stars undoubtedly have their own talents, the practices portrayed by this stereotype are at best short-sighted and at worst they set the team up for imminent failure.

    Breaking down the behaviors of a rock star reveals how they affect a team in the long term. Suppose a developer abides by the Hollywood example of staying up all night to work on a feature on a tight deadline. Let’s look at the qualities they’re embracing.

    Writing code hastily. Typically code that is written quickly is written carelessly. This carelessness may manifest in the form of bugs, poorly defined interfaces and abstractions, or verbose code with hard-to-read variable names. With a discipline as intricate as software development, elegant code isn’t born under rushed conditions.

    Sloppy code is distinctly harmful when it’s relied upon by many areas of an application. It’s common for startups to embrace Facebook’s old motto, “Move fast and break things,” but when it comes to architecture decisions that are core to a product, spending more time upfront making thoughtful decisions far outweighs the pains of supporting a malformed solution for years to come.

    Working in isolation. “Knowledge silos” occur when only one person on a team has an intimate understanding of how a system or process operates. It’s enticing for a team to have a go-to person for a select area of an application because they can fix or extend that code the fastest. This is especially true on a team that is short-staffed, and redundancy in code comprehension is viewed as a luxury in place of a necessity.

    Having knowledge silos inevitably comes back to bite a team. In the world of code, it’s the equivalent of putting all your eggs into one basket. The more a team relies on one person to know a part of a system, the more painful it is when that person eventually leaves. Sometimes a team will luck out and realize this when the expert is on vacation, but more commonly it’s not apparent how crucial this person was to a system until they have already left the company.

    Delivering code all at once. Code that’s shipped in one big piece is harder to review and more inclined to contain bugs. It also gives the product team fewer opportunities to preview behavior. See The Code Delivery En Masse Pitfall for further discussion on this practice.

    A developer’s success shouldn’t be measured by how many miracle projects they can pull off via their own grit. Code that only they understand is no badge of honor. In fact, if your team’s greatest asset is a rock star developer who is viewed as a miracle worker, you're relying on miracles. That’s a tragic way to produce software. Your team can and should thrive without rock stars. The best leaders in software are collaborators who help amplify teams rather than stealing the glory for themselves.

    Collaborators strive to share knowledge. They know that no individual will be around forever to explain things. They recognize that articulating the intent and structure of how an elaborate system works is immensely more beneficial to a team than cranking out feature after feature that only the author understands. They know when to clarify behavior in code comments or when to make sure a feature has corresponding documentation. They embrace pair programming and make the effort to explicitly have other developers pick up tickets even when they themself could have done the ticket faster and easier. They play the long game even though it may be more demanding.

    When it comes to impact, the rock star will always fall short of what the collaborator can achieve. The rock star’s biggest contribution is writing lots of code, but there is a limit to how much code a single developer can write. There is no limit, however, to the impact a developer can have when they focus on trying to make the entire team better.

    You may think I regret ever becoming the lone wolf whom I had once looked up to. But in some ways, I think it was inevitable; seeing the rock star approach portrayed in movies made it seem commonplace. Leading with the wrong approach solidified the lesson I needed to learn at the time—being able to deliver features quickly and autonomously is a useful skill to have, but proceed with caution. It’s easy to make that your identity in an attempt to become the hero. The true heroes are those who realize the limit of one person’s contribution, lay a foundation for any developer on the team to be successful, and amplify those around them in pursuit of a shared goal.

    Code comes and goes. It gets refactored and deleted. Lessons taught to other developers live on. They survive longer than any feature or project. They are passed on and help members of other teams.