This year we hired a “revolutionist” developer at Bird.
In his second week - before he had opened his first pull request - he insisted that we needed to upgrade our Vue.js 2 codebase to Vue.js 3 immediately, to benefit from hooks - nah, Composition API. The team pushed back on the urgency as well as the assumption that the new API is superior and/or whether we’d (immediately) migrate to it.
A day later, he proposed to convert the full code base to Svelte. His reasoning was that he found it worrisome that with Vue.js 3 there was two APIs, Options API and Composition API. Where a day prior he wanted to use the new Composition API, today the mere existence of two options, the possibility of confusion suddenly made him question all of Vue.js and its future.
The same pattern happened time and time again, with every single dependency or implementation choice. He left no good hair or ignored existing patterns, while preaching opposing ones. The new dev was deaf to any reasoning why choices were made the way they were, that we stood by most of them. He didn’t want to hear that even those decisions we regretted, we’d only change if the value of remaking the code was higher than the costs of the change and the opportunity costs. That we were iteratively pruning our systems, not remaking them at a whim without consideration of costs and proggress on the product. He ignored that the primary goal of the application’s code base was not to follow every trend, but to outlive any IC and stay predictable over time. That we have resource limitations. That there was more nuance and complexity than he was understanding, one week into the new code base.
All those things to him were arbitrary legacy arguments, holding back his creativity. Instead of prioritizing adding value to the app that was, he first wanted to transform the app to shape the environment according to his desires before stating to add value. Anything else felt like a chore. He wanted to immediately leave his mark of tech stack preferences. He was not interested in implementing features improving our product for users, or gradual iteration on maintenance and tech debt.
We let him go after one month, and he was happy to go, already having grown frustrated with our lacking enthusiasm for his activism. It was best for everyone.
This is not the only time I worked with a “revolutionist”. At Yara a freelancer was supposed to temporarily lead the back end team. He also pushed to change everything about the back end code base, making it a pre-condition to any product work. Other back end developers, who built the code were miserable under the constant complaints and mood swings. Nerves were blank, but luckily the freelancer left with a single day of notice to head a greenfield project as CTO. It was best for everyone.
I am not proud to admit that I’ve been a (less capricious), smug “revolutionist” developer myself.
Impact on the team
The revolutionist is a loud voice, pulling the team’s attention at whatever the revolutionist wants to remake. Focus is destroyed. Attention leaves ongoing project and the actually important things. Productivity drops. The team’s cohesion is torn apart, as the revolutionist is going to convince some parts of the team with some argument (revolutionists are not wrong about everything after all). Even if everyone puts up a united front against the revolutionist, the good mood will be gone.
Value and curse of new joiners
New joiners see everything for the first time. They notice all the imperfections, get to know the system at Bird’s eye view and compare it to theoretical perfection. New joiners are full of fresh motivation and energy, they want to distinguish themselves. They want to make the code base “their own”. New joiners know they’ve been hired for their skill, and want to apply it. Every month that goes by makes it more likely that the fresh view has grown into complacency. So the early phase of contributing is the right one to challenge the existing.
But first, enough understanding needs to gained. Confidence should grow alongisde a good model and context of the new environment.
When to avoid revolutionists
If your team’s task at hand is to expand an existing application with a settled tech stack, you don’t want to hire a revolutionist. Probe for a revolutionis mindset in the hiring process by asking the candidate to design a new facade of your existing system - the degree to which the candidate proposes to change the system might give you a hint.
When you want to spin up a greenfield project on the other hand, an idealistic person wanting to get the system design right might be a good match.