Give me 0.5x developers or give me death!

Marko Bjelac - Feb 11 '23 - - Dev Community

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.

. . . . . . . . . . . . . . . . . .
Terabox Video Player