Taking myself as a 0.5x programmer, I have sadly encountered some 0.01x programmers. In fact it might be better to characterize them as -0.01x programmers, who I believe can work indefinitely without ever producing a working piece of software. Usually the best indicator of this is when the initial snaglist for a piece of work grows after the snags have been "completed". Then each round of fixes becomes a kind of Hydra and finally we have to give up cutting off heads and start over.
I resisted believing in this phenomenon for a long time, especially because I'm no great shakes myself. But in the end it could no longer be rationally denied.
I've also seen negative impact developers. If they did not code, we'd be closer to the finish line than if they did not.
Works great if you pair them with a more senior developer who has the chutzpah to make an impact by deleting egregiously bad code. E.g. one of the best I know made a failing project succeed by literally deleting all unit tests (which in that case were not providing value at all).
> I've also seen negative impact developers. If they did not code, we'd be closer to the finish line than if they did not.
Code? I know people that have caused big projects to fail by just showing up at the meetings. The amount of damage a -10x idiot can do to a project is just mind boggling.
Here is my unsolicited advice to young players: if you end up in a project with a -1x (or worse) guy who is also the darling of the PM or CEO: no matter how hard you work you cannot save this project, don't wait for the shit to hit the fan, give them your two week notice today!
We had a guy coming into every meeting demanding we produced some low-level internal document for him. We tried to explain to him that (A) our project was not related to his project and (B) we were not comfortable giving anyone an internal implementation document of something that was highly agile.
So this went on for a year and by then the managers were really pissed off that we didn't have the "proper documentation" in place. We spent the next year creating a stable internal API and writing the documents he wanted.
What I learned from all this was that the only way to fix a -10x guy is to fire him. Because despite all this we spent the third year defending internal design decisions from a guy who wasn't even part of the team. In the end he was fired for failing to deliver in his own project - by which time our productivity doubled.
Failing project: the tests were the impediment (too broken and costly to refactor, every change would cost more in unit test fixing than actual implementation).
Yes. If you add two -2x programmers to the project, you decrease its productivity by 4 programmers. You don't multiply it by 4.
I started my professional career in a project where the previous developer had been given incentives per lines of code produced. Her approach was to do
This was on a 8-bit microcontroller with 64k program memory. And, surprise surprise, I, a humble CS student, was given a task to "implement software to control our new HW with memory paging mechanism, so that the software, which is larger than 64k, can be put on a 128k EEPROM, and then add a network management interface".
Well, having taken a look at the code we didn't have to do any paging; soon after deploying a print function we could put everything on one 64k page and the other 64k of program memory was just sitting empty.
I resisted believing in this phenomenon for a long time, especially because I'm no great shakes myself. But in the end it could no longer be rationally denied.