The Healer

A Underappreciated Software Developer that refactors or rewrites parts of the system other developers are afraid to work in.

Special Abilities

Reduce Reuse Refactor

Ability to dramatically improve badly written code.

Whistle While You Work

Inability to get triggered by badly written code.

Let It Go

Capable of deleting and rewriting large sections of code.

Overview

The Healer paves the way for other software developers to add features in less than ideal code. They patiently learn unfamiliar areas of the codebase and skillfully implement the changes needed to make the code a pleasure to extend and maintain. Healers dramatically increase the quality of life of other developers as they radically reduce the estimated time needed to implement new features in an existing area of code.

Healers have a passion for maintaining clean code. They are unintimidated by areas of the codebase that other developers dread working in, allowing them to fearlessly apply extensive refactorings and rewrites in even the most challenging parts of the system. The result of their efforts are beacons of best practice that act as inspiration and motivation for other software developers to write better code.

A Healer’s value is obvious to other software developers but the importance of their contribution can be a complete mystery to anyone else. Their main opportunity for improvement is typically around helping non-coding stakeholders understand the positive effects of the work they do. Additionally, helping stakeholders understand the relative risks and rewards of allowing them to proceed with their cleanup efforts will dramatically reduce the pressure they feel as they work to improve the codebase.

Identification Checklist

  • Will have the respect and faith of their team in their ability to improve the design of software.
  • Will produce excellent code of the highest quality.
  • Will voluntarily refactor code they did not write.
  • Will not hesitate to rewrite large sections of code prior to their team having to work in that area.

Common Misconceptions

  • Healers are similar to The Idealist, but the key difference is that their intent is to make software easier for their team to maintain and extend, rather than simply to improve it’s aesthetics.
  • Healers and not The Bull in the China Shop, as they always improve the areas of code they modify.
  • Healers are not The Hostage Taker, though they will often need to exclusively own a particular area of code if they are rewriting it.
  • Healers are not The Technology Enamored, as they typically are not driven to add new technologies, only to improve the use of current technologies.

Supporting Team Members

  • The Tank can free the Healer from distraction so that they can focus on what is often time-consuming and technically challenging work.
  • The Sage can offer guidance on how to best rewrite or refactor parts of a system.
  • The Wizard can assist the Healer in rewriting particularly difficult parts of the system.

Showing Appreciation

  • Healers enjoy being given the freedom to address code improvements without needing to seek prior approval.
  • Healers will always appreciate tolerance, understanding, and forgiveness for refactoring and rewrites taking longer than they anticipated.
  • Healers will welcome thoughtful, well-reasoned, and constructive feedback when their code is reviewed.
Download Appreciation Certificate PDF
Previous Next

5 thoughts on “The Healer”

  1. Hi Neil,

    I would like to know if the fence between The Healer and the Idealist personalities is thin (as I think), or if there are major differences.

    Let me elaborate through an example: A developer is focused on quality (easily readable and modifiable code), and likes to refactor bad parts of the program for the team and a view on the future, but they are less good than average at writing new code (e.g. providing code to answer a need or fix a problem) and are a bit poor in terms of delivery (like, the function is delivered at the deadline, but not in the optimal amount of time).

    Would it make them an example of the Idealist, or rather an “average” (as opposed to “good”) Healer?

    Cheers,
    Guillaume.

    Reply

    • Hi Guillaume,

      You’ve asked an excellent question, which I will do my best to answer:

      Of the 12 difficult developers, there are at least two that are only “bad” if there is organizational dysfunction, and those are “The Rockstar” and “The Idealist.” In the case of The Rockstar, the organization has allowed for a massive discrepancy in average competency vs. the competency of The Rockstar; in the case of The Idealist, the organization does not emphasize the quality of a technical solution, labeling The Idealist as a problem. As the 12 heroic developers are all examples of good developer traits, inevitably, there is always the question of, “Is this heroic developer similar to or the same as The Rockstar or The Idealist.” For example, The Assassin would be considered The Rockstar in many organizations, despite them not meeting the unrealistic expectations of a Rockstar to be perfect. Along the same lines is your observation that The Healer may very well be considered The Idealist if they found themselves in an organization that puts little value on code quality.

      To answer your question directly, I would say you described a Healer that in an organization that did not put emphasis on code quality would be considered an Idealist. An important distinction between the Difficult Developer Archetypes and the Heroic Developer Archetypes is the perspective of the observer: The Difficult Developer Archetypes are defined generally from the perspective of the organization; The Heroic Developer Archetypes are defined broadly from the perspective of other developers. This distinction allows for what other Developers see as a Healer to being seen as an Idealist by non-developers. This discrepancy in view not surprising as the value of a Healer is entirely centered on their ability to improve code quality, and only other Developers benefit directly from code quality. Furthermore, only another developer can tell the difference between a true Healer and a true Idealist: The Healer is functioning tactically, only emphasizing what needs to be refactored right now for the sake of a team; The Idealist sees code quality as being strategically important, and generally draws no distinction between a tactical refactoring and a strategic refactoring.

      The question of “Are they are Healer or an Idealist?” is one of the many maddening conundrums that comes from comparing the 12 Difficult and 12 Heroic developers. Another dilemma is that most organizations would consider The Assassin to be The Rockstar, where The Ghost is far more deserving of that designation – yet a Ghost can be easily confused with The Soldier. Indeed, being given poor requirements can determine if a Ghost is actually a Solider: A Ghost will not proceed until the requirements are fixed, where a Solider will implement them as written without question. However, this difference can be erased by Product Management and Project Management, whereby a Napkin Sketcher combined with a Tyrant can easily convert Ghosts to Soldiers.

      My hope is that by providing 24 developer archetypes, organizations can have productive and insightful discussions around what we actually mean when we label a developer “bad” or “good.” These labels are applied ruthlessly by people on software development teams around the world with no regard for their accuracy, often leading to unfair consequences for an individual with a label of being “bad.” During discussions using these archetypes, I believe that people will discover that “bad” or “good” are far too simplistic to have any utility when describing a role as nuanced and complex as a software developer. What makes a developer “bad” or “good” in many cases has more to do with their organization, project, and the specific circumstances under which they are working, than their individual characteristics.

      An excellent question, thank you for asking it,

      Neil

      Reply

  2. Hi Neil,

    Thank you very much for your answer.

    I would then like to know some advice on how to improve as a Healer and leave the Idealist territory (from a fellow developer’s point of view).

    I suffer from that: I want to have quality code that can be read, understood and modified easily by colleagues, but I struggle with having proper professional standards about what is a good level of quality (due to a lack of professional experience).
    It leads to being stubborn on perfectionism, and then to very poor delivery time, and the number of features; thus being more of an Idealist than a Healer.

    I would like to know if you happen to have information about what is satisfying quality in periods of feature sprints (several features, or a long one) and outside of those (~free time); and when to refactor code.
    (of course, it would be better without bordering on the Bull in the China Shop, the Hostage Taker or the Legacy Maintainer)

    Again, thank you for your answer.

    Have a nice day.
    Cheers,
    Guillaume.

    Reply

Add your thoughts