Hazardous Enthusiasm and How Eagerness Can Kill A Project

Programmers are constantly contributing to my open source projects (all of my projects are open source FYI). Some are volunteering their time, others are paid through Zerocracy. While I’ve worked with a lot of great developers over the years, I’ve also come across a number of people afflicted with what I call "hazardous enthusiasm." 

These people have energy and often the skills, but are overzealous and don’t know how to break down their changes and deliver them incrementally. People afflicted with hazardous enthusiasm frequently want to tear down and rebuild the entire architecture or implement some other huge changes, often simply for the sake of doing so. Let’s take a closer look at what I mean.

Let’s say a new developer joins the team. At first, he checks all the boxes. He knows his code, he’s got energy, he’s easy to communicate with and he’s putting in time, submitting new tickets and offering useful suggestions. During those first few days, he seems like a gift from the heavens.

Then as he learns more about the project, the hazardous enthusiasm starts to creep in. Instead of tickets with helpful suggestions, he hits me up on Telegram with a bold claim: the architecture is a complete and utter mess, and I’ve got just a matter of weeks before the project will implode.

I counter with a polite reassurance that I understand but before even hearing me out, he’s already suggesting that we re-do everything from scratch. At the very least, he suggests that we trash a collection of objects, and replace it with a singleton and a particular ORM library. Of course, he’s been using these for months, and they’re amazing and as soon as I see everything in action I’m going to be floored and, and, and…

Now at this stage, there’s a lot I’ll probably want to say. I could remind him that I am an architect myself, and that I have a long string of successes under my belt. I might point out that we’ve been working on this project for some time and that so far development is progressing at a comfortable pace.

Often, however, I say very little and instead ask him to submit a ticket. I offer an assurance: I’ll review his suggestions as soon as possible. And I casually remind him that I am an architect, and in fact the architect for this project. In an ideal world, he’d accept that and follow up some incremental changes. More often, he claims that he’ll show me how it’s supposed to be done.

A few days later he hits me up with a huge pull request. There are tons of changes and some of them actually look quite interesting. Problem is, a lot of the suggestions are all but antithetical to the principles I’ve embedded into the existing architecture. I know he’s put a lot of time into his project but I have to reject the pull request anyways.

Can you guess what happens next? The developer, once a godsend, simply ups and disappears. You see, I’m the bad guy here. I’m evil and anti-innovation and closed minded. How dare I not scrap an entire project and start over!? I’ve been through all of the above time and time again.

The sad thing is, that developer probably could have made a lot of useful contributions. Sometimes we come across incompetent developers but a lot of times they’re actually great from the technical perspective. What they’re lacking is an ability to microtask.

Developers jumping onto new projects need to know how to breakdown changes into small, digestible chunks and then deliver them incrementally. Instead of pushing out one huge chunk of changes or trying to completely upend the entire project, they need to set their sights lower. As an experienced and successful architect, I’m not going to allow someone to completely implode a project in their first week.

Maybe I’m evil. More likely, the developer has been struck with a case of fatal enthusiasm. Although they want to do the right thing, they are way too eager and overly zealous. Every fix has to be implemented in one pull request and there’s no time to wait. And any incremental improvements simply won’t be acceptable. Remember, in their view, time is running and the project is only weeks from failing anyways.

So why don’t I just step aside and let them fix the code the way they want? Maybe they’re simply a better architect then me. But here’s the thing, being a successful architect requires microtasking. As an architect, you have to manage changes, and you have to implement them gradually. This is a basic necessity in a dynamic, collaborative work environment.

The moment a developer comes to me and tries to upend the entire project just a few days in, I already know that they’re going to struggle with incremental change. And that means they’re going to struggle in the architect’s seat, so I can’t exactly hand over the keys to the whole venture.

So no, you’re not being evil or closed minded when you reject hazardous enthusiasm. You’re being prudent, wise, or whatever you want to call it. Most importantly, you’re being a good architect.

Yegor Bugayenko is founder and CEO of software engineering and management platform Zerocracy.