3 ms·
The only people who get 10x productivity are people who are either: - solo projects - startups with few engineers doing very little intense code review if any
by Jcampuzano2 1y ago
The only people who get 10x productivity are people who are either:
- solo projects
- startups with few engineers doing very little intense code review if any at all
- people who don't know how to code themselves.
Nobody else is realistically able to get 10x multipliers. But that doesn't mean you can't get a 1.5-2x multiplier. I'd say even myself at a large company that moves slow have been able to realize this type of multiplier on my work using cursor/claude code. But as mentioned in the article the real bottleneck becomes processes and reviews. These have not gotten any faster - so in real terms time to ship/deliver isn't much different than before.
The only attempt that we should make at minimizing review times is by making them higher priority than development itself. Technically this should already be the case but in my experience almost no engineer outside of really disciplined companies and not in FAANG actually makes reviews a high priority, because unfortunately code reviews are not usually part of someones performance review and slows down your own projects. And usually your project manager couldn't give two shits about someone elses work being slow.
Processes are where we can make the biggest dent. Most companies as they get large have processes that get in the way of forward velocity. AI first companies will minimize anything that slows time to ship. Companies simply utilizing AI and expecting 10x engineers without actually putting in the work to rally around AI as a first class citizen will fall behind.
- TacticalCoder 1y ago[dead]
- evantbyrne 1y ago10x has always been an exaggeration, but I know from repeated experience it is possible to complete projects far quicker than 2x the speed of the typical team on a modern web stack. The way you do it is by writing less code. Typically this is done by using mature software as a starting point, rather than screwing around with the hot new thing. Seems fairly obvious when stated plainly, and yet so many teams make the same mistake of building from near scratch. Even worse, what teams come up with is usually slower to iterate with than existing software, because they approach it from the perspective of building a singular app rather than designing something to build generalized solutions upon.