31–40 of 321 posts
I've worked with people who could be classed as almost a 10x programmer. Their code worked, but it was also incomprehensible to everyone else on the team. I have found that high-speed programmers tend to develop a very personalised workflow style. They do things their way, they code their way and forget that other people may have to maintain that code.
One thing that it's missing from the post is a bit of focus on how good developers (and indeed good leaders) concentrate on maximizing their impact. Not only you want to be fast and reasonably accurate, but also make what you do matter. Sometimes shaving down compilation time by a couple of minutes will save each developer in the team two minutes multiple times a day for years, for example. Not all productivity wins are obvious.
I've worked with people who could be classed as almost a 10x programmer. Their code worked, but it was also incomprehensible to everyone else on the team. I have found that high-speed programmers tend to develop a very personalised workflow style. They do things their way, they code their way and forget that other people may have to maintain that code.
I worked with a guy who was the star of the department, a nice and friendly guy, but holy crap he built some interesting solutions. Example: Our main product could only be debugged if we started up a development environment, consisting of 12 VMs. The 10x guys only problem was that the subnet these thing ran on was a little to small for all us to have a full environment.
You're absolutely right that these people develop tend to develop a very personal style, and often it's harmful to everyone else.
- Distractions
- Feature creep
- Poor code organization: coupling, action at a distance, cyclomatic complexity
- Noise: comments that do not get to the point. A tool to mitigate this is https://foxtype.com
- Hacks and lack of consistency
- Lack of automation: tests, builds, deployments
Regarding hacks, imagine what would physics equations would look like if a fundamental constant was wrong. All equations would need to compensate for it by including some arbitrary constant making everything more complicated. That is what messy code bases look like, layers of lies to compensate for lies. Clean code is more straightforward, easier to work with.
Regarding iterations... does the army run an exercise with soldiers and trucks and live ammo each time a general wants to test an idea? No. They use simulations, and only the ones that look promising are turned into exercises. So rather than asking engineers to prototype some throwaway idea, get your hands dirty and use Powerpoint and your imagination, stress the idea, then build it. And if it's built, keep it in a feature branch until you've actually decided to keep it for good.
When a car is built, engineers tell designers to modify their concepts in order to make the production more cost efficient. Same in software... be prepared to negotiate requirements if that is in the best interest of the project.
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 Hydr…
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).
Everything from the original post sounds reasonable, you should absolutely read it. Just some random thoughts to add to it: * For most of my past clients, the skill / output of their programmers was not the bottleneck, even though they thought so. As long as something is not a bottleneck, there's not point in trying too hard to optimize it (since you can get better ROI somewhere else). * Software is a team effort. Im…
10x programmer = very good programmer. End of discussion.
I'd argue that it's greater than that these days, many programmers really just can't do what a lot of good programmers can do. Even if they're given all the time in the world they'll just never get a result. So whats that make them infinityX programmers?
At the beginning of my career I've done comparable things. I once spent multiple weeks implementing a solution to a problem that would have been trivial if I had known about unification [1]. Thousands of lines of complicated C++ code, countless bugs,... If you don't even recognise the problem, how can you expect to find a reasonable solution in a time that is only 10x as long as it would take someone who recognises the problem and knows how to solve it?
[1] https://en.wikipedia.org/wiki/Unification_(computer_science)
I've certainly worked alongside programmers who's output is so bad that I would consider myself both 10 times better and 10 times faster. And I wouldn't even consider myself a top teir programmer. They are often people who's contributions to the project are net negative in that they actually require additional work from someone else to go clean up their mess afterwards.
Stop imaging a mythical coder who is 10 times better than everyone else, and instead think of the worst coder you've ever worked with who is 10x worse than everyone else. There is your 10x'er. We are nearly all 10x'ers when compared to the bottom few percent.
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 Hydr…