There’s a debate on whether 10x software engineers exist.
They do: I’ve seen several of them.
And their existence freaks the hell out of me. 5 examples of 10x engineers and why you should be afraid when you see one:
1. The Move-Fast-And-Leave-Behind. A dev with a hacks mindset at a scaleup. They get shit done 10x faster than the engineers who that take this (literally) shit over when it needs to scale, try to reverse engineer it, but ultimately have to toss and rewrite the whole thing.
2. The That’s Trivial To Finish. Someone w many product-minded traits blog.pragmaticengineer.com/the-product-mi… amazing at prototyping and telling the non-technical manager they’ve done 90% of the work, and the other devs should have no problem finishing the last 10%. Which then takes 10x as long.
3. The Only Non Quitter. A company a terrible eng culture and just as bad codebase which oversells itself. Devs quit all the time and the new joiners struggle with everything. Save for TONQ who gets stuff done. Obviously the most tenured dev, and the only one lasting >2 years.
4. The Debugging Machine. A place with a codebase w no tests or documentation. New joiners tend to break everything and TDM needs to be called in to save the day. An engineer who has been around for years, though refuses to ever document/share any of their well-earned knowledge.
5. The Story Point Hoarder. A company where productivity == story points shipped. A tenured engineer who figured out how to make sure every second sprint they claim 5-10x as many story points as most other team members through cherry-picking work, optimising for these points.
So yes, 10x engineers do exist. They live in a mostly unhealthy engineering environments allowing for 10x behaviours.
If the above examples proved anything it’s how we should not ask: “how can we have more 10x devs?”, but answer “why are most our devs at 0.1x productivity?”
10x devs share the trait of being tenured at a company, and being perceived 10x as efficient as most new joiners.
Which begs the questions: 1. Why does an engineer need years of work at the company to get productive? 2. Is perception == reality?
Those are the 10x questions.
2 more archetypes: 6. The Reinvent The Wheel Dev. One of the first engineers at a startup who decides to reinvent the wheel. Writes a custom SPA framework, with layer, MVC abstraction. Then gets everything done 10x faster than new hires (who they label as “not smart enough”)
7. The Stupidly Hard Worker. Typically someone who is also #1 or #6 at some level. They work 12+ hour days, also through most weekends. Management loves them as they’re clearly devoted to the company, and ignores any complaints because this hard work & perceived 10x output.
Finally, my observation on what a highly productive engineer can look like (who I would not call 10x):
Casey’s interaction with the “whistleblower” where he gradually realizes all “evidence” is AI-generated, designed to fool even journalists… then he confronts the faker. Worth the read
We’re entering a time when it’s harder to trust anything online: and surely more people will try to fool journalists with AI-generated “evidence.” In some cases, they will succeed, especially at publications chasing headlines and not doing proper investigation / reporting!
For the last ~20 years, I did most of my coding inside an IDE - the last ~15 with increasingly good autocomplete.
Which is why it’s so weird that I barely opened an IDE the last two weeks, even as I pushed lots of code. I use the CLI, the web and my phone (!!) to prompt code
When I just started out developing I remember being so so so full of ideas that I was coding in my head and wished I could have done programming while commuting / on the bus. With eg a phone. But it was impossible, ofc.
Now it’s possible!! A massive change
I feel we’re in the middle of the biggest dev tooling change happening across the industry - and it’s happening over a few short months. And rapidly spreading everywhere.
Amusing: Google does not allow its devs to use its newly launched IDE, Antigravity, for development.
They can only use an internal version called Jetski: also built by the Antigravity team, with Google-speicfic features (eg monorepo support, docs search etc)
Using Antigravity is specifically disallowed and devs cannot sign up to it with a @google.com work address
The reason for this “ban” is, of course, Google’s “tech island” tech stack: Antigravity is simply not compatible with its monorepo, and not integrated to Google’s custom tooling.
Jetski has all of this - but it's a different product. A bit like Borg vs GCP (most of Google doesn't use GCP!)
Covered a lot more on Google’s unique culture (and how they have probably the most custom tech stack across Big Tech) in this deepdive: newsletter.pragmaticengineer.com/p/google
My personal anecdote on the impact of AI (aka Claude Code + Cursor)
There was this tool I wanted to build that would have helped my business a little bit at @Pragmatic_Eng, but not enough to
1. Do it myself (would have taken ~days) 2. Hire someone (too much onboarding)
But...
... but then I gave it a go with Claude Code + Cursor open.
In 30 minutes, I had something promising. In an hour, I got it done, exactly how I wanted (this was an addition to my existing codebase.) In another hour, I moved it over to a new stack I've been wanting to play with!
... and now it's done, and I've onboarded the first company on to this feature.
Here's the thing without this AI tool, I don't think I would have EVER done it! Not worth it.
So I think AI tools will do this. People + companies doing stuff they wouldn't have, before!
Linear has a 30-minute weekly meeting called "Quality Wednesdays." I sat through one and WOW
Devs show a quality or perf-related fix they did last week. It can be big, or small. We went through 17 issues, from massive backend performance wins, to this tiny one. Can you see it?
On one end, it was super casual. On the other, it was really dense.
A dev spent 2 minutes showing how because styled-components *feels* slow, they tried out 3 other frameworks & measured how they compare for build time, JS bundle size, CSS size, and LCP rendering performance.
Based on this, they'll probably move off styled components... mainly for LCP rendering for massive pages to be faster. But it's all tradeoffs.
And it could really be *anything.* Some devs showed work they picked up as reported by users that resulted in higher quality.
Most devs though found a small thing or two to fix last week. That first bug (off by 1px) was found and fixed by a frontend engineer.
Lots of small but irritating things fixed like moving the mouse over an element takes a small delay to show the tooltip, or the tooltip first shows as empty etc
Amusing use of LLMs at a more traditional company:
“A project with ~50 people got stuck. There are too many JIRA tickets, no clear specification, and anytime one team tries to make progress, the others shoot it down.
So a dev built an LLM to try and break the deadlock: (cont’d)
- Fed all JIRA tickets to the LLM. Built a basic RAG with vector DB
- Had it generate questions about the project, about topics not covered by the tickets
- Had the LLM attempt to answer the same questions
- Generated a report of what areas are not specified
- Tried to use this to stop teams rejecting suggestions “because this is not well specified”
A PM at this company told me this story. Asked him if this LLM helped break the deadlock? His response:
“No. We’re still stuck. But it was good fun to build it and an excuse to play around with vector databases!”