Slow is smooth & smooth is fast.
How does one become a 10x developer?
Here's my opinion the Truth:
Mikey is a 10x developer. Mikey is that guy who started the project. He knows every little detail, architecture decision & helper method. The entire codebase fits in his head. He started in Heaven, i.e. working alone. Unfortunately software is too big these days & time is money so his boss hired more developers. To work on HIS code. Mikey is trying his best to hold the code together, gatekeeping left & right (he's the pull request reviewer), making sure his vision is kept pristine & unsoiled. The other developers can't onboard as fast as the boss wants. They don't know their way around the code nearly as well as Mikey does. The boss says Mikey's churning out 10 times more stuff than them. They're helping but thank goodness we have Mikey on board - a 10x developer who is saving this project.
This is a myth. Mikey appears fast because he started the project, or has been so long on it he might as well been there from the start. Mikey takes shortcuts. Mikey rushes stuff. This makes him appear even faster. However, this is only good if you want to keep Mikey as the single developer on the project. New people take time to get acquainted with the code, with Mikey's decisions, patterns & conventions. Worse, since Mikey took many shortcuts, the codebase is convoluted & unreadable. There are no tests. Mikey refactors seldom if ever ("Gotta churn out those features!", "Have no time to clean up now, I can always do it later..."). Other developers either take their time putting things in order, writing tests & refactoring, or don't take time for this, instead trying to churn out features, breaking things & fixing them - taking even more time.
In reality, Mikey is probably as good as any other developer (all of us are) not better or worse. Churning out rushed code alone for a long time warps Mikey's mind & he becomes stuck to his codebase, thinking this is the best there can be. Mikey develops a blind spot and can't see he's slowing down. Mikey is slowing down because he's breaking stuff all the time, or having trouble putting in features which use existing code (often just copy-pasting the code & modifying that).
The charade breaks down when you put Mikey on a different project or confront him with lack of built-in quality in "his" project.
So, what to do?
How do we develop software without getting caught in a code quagmire?
The solution is absurd: 0.5x developers
These guys are 2 times slower! How's that gonna help?
Well, they're slower because for every line of feature code they write, 3 lines of test code goes in. For every 5 minutes of typing, another 5 minutes goes into discussion with their team mates.
They squander engineer hours (i.e. the client's money) on setting up continuous delivery pipelines, architecture & test patterns, attending exploration testing sessions, writing acceptance tests before the first line of feature code is even written & insane stuff like that.
They're slower. Because they take the time to make their work smooth. Which in turn makes them faster.
For every test not written, skipped refactoring or good practice ignored, there is an undeterminable length of time waiting silently in some dark corner of the project's uncertain future. Time spent in debugging, reworking existing code or just plain bashing one's head against the desk.
No, I say give me half-x developers. They're faster.
Top comments (2)
There is also 1000x developers who rewrite parts with 100k loc to 10k loc in a couple of hours. They pick out a specific logical area from the onion code and after a few months they enable the normal devs to work on it. They create huge diagrams of the database, they write the documentation. They don't need to communicate, they just look at the code of a few devs and know how they think and which docs they have read and are able to provide a platform for them to work in e.g. strict issue type templates, json schema validations and test templates and strong docs and templates for the product owners to follow to write good feature requests.
Give me two 1000x devs instead of a thousand 10x or a billion 0.5x. But give me the budget for the thousand 10x.
I get that the multipliers are just to make a point, but I've never met people that fit the description ... The best people I've known can spot room for improvement in a codebase from small things within classes to large architecture stuff.
However, I've met plenty of guys who code fast and dirty, knowing "their" codebase by heart and making their bosses shine with pride.