Identify and Manage the Honey-Badger Developer

A few years back I read Rands’ blog post about the Free Electron developer archetype: “the single most productive developer you’re ever going to meet.” This is a good archetype to understand, identify, recruit, and retain. I would like to discuss another related archetype which can be quite powerful if properly harnessed: The Honey Badger.

“There is no other animal in the kingdom of all animals, as fearless as the crazyass Honey Badger.”

Like the honey badger itself, the honey-badger developer has no fear. They will undertake any project, with any technology, on any deadline. They will not be paralyzed by the impossibility of choosing a good architecture. They will proceed single-mindedly in the direction of the current stated requirements, even as those requirements change.

What makes for a honey-badger developer?

  • Willing to work with grotty systems
  • Uses undocumented APIs
  • Reverse engineers protocols
  • Finds third party libraries whenever possible
  • Able to glue anything to anything else
  • Able to work within really challenging constraints
  • Pursues a successful implementation regardless of architectural purity
  • Gets things done

Of course, these are not universally positive traits. If you are developing the foundation of a new software platform, a new hypervisor or database kernel, you won’t want to make these kind of tradeoffs. On the other hand, if your largest customer absolutely requires an integration with their unmaintained COBOL running on an IBM mainframe by the end of the quarter, then a honey badger may be just what you need.

Sometimes it can be hard to tell the difference between a honey badger and a non-badger who is struggling. The difference is in what they attempt and accomplish. A struggling developer may try some of these behaviors, but their project isn’t actually that difficult and a better developer could just do it properly. A honey badger, on the other hand, brings out these tools in clutch situations where other developers throw up their hands in despair.

How do you properly manage a honey badger? What a honey-badger developer needs is audacious requirements, guardrails, and admiration. What they don’t need is unrestricted commit access. Create the right environment, and they will be a powerful force for project success.

Audacious requirements are the honey for the badger. They are happiest when attempting projects other people think are impossible. So make sure you pick good projects. The best projects will have deadlines. Integrations are often good, particularly when one or both systems are proprietary and poorly understood. Performance challenges can also be a fit, particularly in scaling and throughput (latency often requires more detail work). Demonstrations and proof of concept work often create the right context, with lofty aspirations and tight deadlines. Make sure the honey badger understands whether the goal is to do the work or to show the work. It may make a big difference in how they approach things and where they spend their limited time.

The guardrails for a honey badger should give them plenty of room to choose implementation, but a bright line not to cross. For example, your code must run in a separate process, or it must run on a separate machine. It must expose this API, or use this API. It must run in this VM or this container. And be clear. If you want the code to be in Java, you have to say that, otherwise your requirement that it work with a JVM may result in the use of Clojure because the honey badger found a library that did most of the work.

Finally, a honey badger needs admiration. They are going to do things which are hard, and unpleasant. They will likely work long hours to meet a deadline, or travel to work directly with an inaccessible customer system. They know they are creating solutions which are not the most elegant code. They need to hear from you, and from the team, that what they are doing is important and they are doing an impressive job.

The one thing not to do with a honey badger is invite them to make changes on your core systems. This is a corollary to the guardrails requirement. If the honey badger has the ability to change something, they will, and often not in a way that everyone on the team appreciates. Unfortunately, it will be in service of some critical requirement. So get in front of those conflicts, and either create a process for approving their changes, or just enforce a guardrail.

When your honey badger has succeeded, you will have a working system, sometimes just a single unreproducible instance. To defend against this, try to get them committing early and often, even if it is to a private repository. Your system, if it was built for a customer, may be distressingly close to production. Your customer will also have fallen in love with the honey badger and not want to let them go. You must either fit this into the economics of your  business, or ideally find ways to wean them off the honey badger.

The honey-badger developer can be tremendously valuable asset to any software team, and especially a software business, if managed correctly. What other success stories do you have about honey badgers? Other management tips?


  1. A Honey Badger says:

    I’d never heard of this kind of developer until I’d read this, but know the category very well. I’ve been a honey badger developer for 20+ years.

    I don’t say that with a lot of joy though. Most of those 20+ years of being a professional honey badger haven’t been easy. What you’ve correctly identified as single minded tenacity can be perceived by others as cockiness, competitiveness, or even laziness.

    It’s also very difficult to be a honey badger in an environment that embraces process. I’ve worked for scores of companies that valued their various flavors of “code stuff that isn’t coding” (aka, process) more than they valued solutions. This tension usually ends in me losing or leaving a job.

    My wife often thinks I’ve burnt out on writing code when a job relationship ends. But it’s not true, as the happiest and most productive times I have as a programmer are when I’m working on my own, unpaid, projects. The only process tasks I have are ones I do without thinking. The only constraints I give myself are that the thing I’m doing must solve the problem.

    I’ve yet to find a company that really knows what to do with me very well. The closest fit I’ve had is when I work on “special projects” – stuff that people don’t even now is possible, or stuff they think is impossible, prototypes, experiments, or one-offs. That works well until I’ve knocked down each challenge. Then I get put onto a “normal” team, and live through the misery of 2 hours of coding for every 6 hours of meetings and other meta-tasks. Miserable developers don’t last.

    It’s not all bad though. I know I can solve a problem. There’s no doubt, ever. I’ll learn a new language in a few days if that’s what it takes. I’ll dive into (and have dived into) actual dumpsters to find information I need to unblock myself. That ability and near obsession to make it work have opened a lot of doors (the first of which was teaching myself how to write code in the first place).

    Having read your article and really let it sink in I realize I have a better understanding of myself, but also, a way of finding the kinds of places that suit me (and need me).

    If only I could just figure out how to say “I will, at any expense, find a solution” on my resume without it sounding scary.

  2. [...] employees are disruptive to an egalitarian team. Engineer types such as the Free Electron or the Honey Badger need specific accomidation. The team needs negotiation between Stables and Volitiles. Extroverts [...]

  3. says:

    These proteins have been linked to Parkinson’s disease,
    Alzheimer’s disease, and other forms of dementia.
    Acai research is an ongoing study and will surely demonstrate
    that the Acai berry in indeed very beneficial to humans.
    Pets as young as 5 years of age are diagnosed with cancer and auto-immune disease is also on the

  4. Ian McGowan says:

    Love the idea of putting a name to this archetype. I am not a honey badger, but long ago realized my own career would not be successful unless I could partner with someone who is. I’ve been lucky and worked with some great badgers over the years and like to think being an architecture astronaut added a little value to the partnerships ;-)

    To “A Honey Badger” above, the “at any expense” is the part that scares people, especially managers who control a budget. If you change it to “I always find a way to overcome any roadblocks and make it happen” it’s semantically the same, but less scary. You probably need to work at small companies where heroics are appreciated. Big places values predictability over delivery – it’s ok to deliver in a year, plus or minus two weeks, as opposed to the “impossible” six weeks, but at the cost relying on a hero/deferred maintenance.