Today I got a comment asking how "The Healer" archetype from my work "The League of Heroic Software Developers" compared to "The Idealist" from my work "How to Deal with Difficult People on Software Projects":
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?
In order to fully understand what Guillaume is asking, you'll need to have read the profiles for both "The Idealist" and "The Healer." You'll notice that each profile has a different format as they are from different works with different purposes:
- "The Idealist" comes from what is effectively a guide for managers.
- "The Healer" comes from what is effectively a guide for software developers.
Nonetheless, they are both archetypes that describe a type of developer, and in practice, they can be very similar.
After some thought, I believed the essence of this question is:
Is a developer who proactively improves code quality a "good" developer or a "bad" developer?
If this question is asked to software developers, I suspect most would agree that proactively improving code quality is a clear sign of a "good" developer. However, when looked at by a manager, modifying the codebase without gaining explicit permission beforehand for a purpose not directly related to a business requirement can be considered very bad.
Here was my answer:
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 is 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,
I am interested in what people think about my answer, as this is a very tricky topic that is at the same time highly specific yet highly subjective - as are all topics related to code quality.