1. Understand the problem and the solution. Figure out the best tools to use for it. Learn just what I need for version 1 if necessary.
2. Implement version 1. It works. It's ugly. But it's efficient. It's my MVP and I can get by with it if other duties call.
3. Observe what's truly missing. Add to knowledge base and improve the solution. Refine. Test. Refine. Deploy.
4. Document everything.
I used to be the kind of guy who read whole books to implement something because I had FOMO. Now I focus my energy on what I need to solve the problem. During downtime, I might expand my overall knowledge because it's necessary or I'm curious.
Am I a 10x dev? I don't think so. But I like where I am at and always want to improve.
I first learned this from Tim Ferris (btw, that guy isn’t full of it he actually gives out some good stuff) : it’s better to learn things JIT (just in time) than JIC (just in case).
There are some labels developers use today that sound like a need to validate themselves. Is this a result of a competitive environment or a time when everybody gets a trophy? I'd like to understand this one.
I feel like the meat of your post is in the "Refine. Test. Refine. Deploy" section that you glossed over. Everybody starts at (1); they may arrive at (2) with different levels of how much knowledge they've acquired. You're purporting that minimal should be acquired. At (3) is when you start to get in trouble because you don't always know what you don't know.
There is no right or wrong answer here I guess. It's just what aligns with your goals, how you've prioritized things and what makes you happy.
Just don't be a 0.1 developer. Since there are so many of those, wasting their time writing blog posts or mindlessly reading social media, it's easy to be a 10 dev.
Blogging about a topic is a good way to build network and raise awareness. A 10x developer surely strives to be a good blogger; writing is a key skill of such developer, and it needs to be continuously improved.
Technical writing is a great skill and a valuable one. I used to write blog posts, a lot. It truly improved my ability to write great documentations, and i'm getting appreciated a lot by that skill, well on the other hand, if you are talking about the "how to reverse a string in x?" types of content, it's completely understandable.
Believe it or not, there are senior engineers with comp packages of $300k+ who spend 80%+ of their time writing and being in meetings and very little if any actual coding. You could really call what they do as writing blog posts, just for the company.
The anti-blog sentiment on HN is strange, considering that a large volume of the content I like comes from good blog posts. I know it’s not everyone, but you see a bit of the herd mentality with words like “blog spam” getting thrown around.
I thought blog spam were those short articles designed to capture SEO traffic about generic terms, offering little new substance or deep insights. They often read more like PR and white papers, than providing practical content beyond the simplest tutorial.
Whatever, linkbait and exhausted discussion. The idea that there's some universal rule for productivity is trivial to disprove, it's going to be a function of the environment you find yourself in.
You'll find some companies where the most effective use of your time is building, because everybody else plans. You'll find some companies where the most effective use of your time is tooling. You'll find companies where the most effective use of your time is doing product work. You'll find companies where the most effective use of your time is challenging the business status quo.
Did you assume that, and avoid clicking the link? It doesn’t suggest a universal rule for productivity, and even starts by predicting your reaction: “It’s not a clickbait title, but I understand why it looks that way.”
> it’s going to be a function of the environment you find yourself in.
The article agrees with you, and talks about some specific ways to be a force for good in creating that environment for yourself and for those around you. Is it perhaps worth a quick glance before jumping to conclusions?
> Did you assume that, and avoid clicking the link? It doesn’t suggest a universal rule for productivity, and even starts by predicting your reaction: “It’s not a clickbait title, but I understand why it looks that way.”
No, I read it, and regretted reading it, and figured I should save others the trouble. I specifically called it out as baity because it claims not to be, which is ludicrous, because it's a meandering piece that isn't really saying much ("try boneheaded solutions") of anything, seems like a mix of generalities, caveats, and self-promotion.
I'd challenge you to ask yourself this -- Is there even the slightest chance that anybody who reads this article is going to become 10x as productive from this "technique"?
If not, then that seems the definition of linkbait.
Fair enough, I hear your points, but FWIW I think you’re still being a little unfair. Clickbait is defined as being misleading. This article, being a blog post, could be accurately described as light on content, and not very deep. But I don’t see it as misleading or serving any agenda besides what it said. It doesn’t fit the definition of linkbait at all in my book.
I don’t know whether it would convince someone, especially someone who’s in a pessimistic frame of mind, to be more productive. But I will say this: after a couple of decades of professional programming experience, the number of times I’ve seen extremely “productive” people who think they’re clever over-engineer the shit out of something that ends up wasting a ton of money and time for entire teams, I can’t even count. It’s a very good point to stop and evaluate whether there are ‘boneheaded’ solutions you’ve overlooked, rather than try to hero-code something complicated.
I also think it’s very true that mentoring others and helping the team is how you achieve this symbolic notion of ‘10x’, and this point does get overlooked sometimes in other discussions and blog posts on code productivity. There is, of course, no objective metric here at all, and the number 10 is being used metaphorically, mostly because it’s basically a meme at this point, which is obviously why it was used in the title, so I think it’s reasonable to avoid taking it literally and using it as the criteria for whether the writing is valid.
Anyway, cheers, I hope you find some articles here that reach you in a positive way.
> I think that someone who produces 10x as much code as someone else has left a wake of destruction that will slow down other developers. I don’t think 10x counts if you achieve it by slowing down everyone else. I think 10x has to take into account how you impact other people.
A 10x developer doesn't (usually) write 10x as much code. They get 10x the work done in 1x of the time. The quantity of work output is famously not measured in SLOC.
I've had the pleasure to work with a few. We all know the names of most of the dozen of 25x or 50x developers that exist in the world.
I think this person is writing to their preordained conclusion that the idea of a 10x developer is a myth. It's not.
I think they don’t just solve the problem faster, but over time they’re more likely to solve the right problems in the right ways. It’s not “here’s a programming problem, I’m going to start a stopwatch go!” It’s over the past year you’ve had 10x the impact.
Agreed, and I've seen way more instances of developers who have no idea what they're doing, not interested in learning, and actually leaving a wake of destruction.
Agreed. I also had the pleasure of working for several years with a "10x" developer where "x" roughly describes "meaningful work done".
He was brilliant, probably slightly autistic, spoke multiple (human) languages fluently (that he had taught himself, not grown up speaking or learned in school), and easily wrote 500-1000 lines of great code per day (not that that's the metric, but that's what I'd see when running `git pull`), implementing feature requirements in a front-end web application. His work truly had a "wow" factor. Give him a very big job that would take the average 4-person team more than 6 months, and it would be done in less than a month.
As a senior developer on that team, I quickly learned that the best use of my time was to remove roadblocks and streamline his workflow.
I worked across from him in an office for a couple of weeks one time, and was impressed at how focused and disciplined he was -- more than anyone else I ever saw. Every moment of the work day he was scrolling and typing into his editor. A quick break every few hours, and then back to work.
1) identify the most important problem you're facing
2) solve it somehow
If you get better at your craft, you can get better at #2 as you'll understand the costs and benefits of different approaches and how to accomplish them.
You may wish to select an environment that makes use of your skills vs one that uses skills you don't care about.
Are there artificially high IQs? As opposed to a 'naturally' high IQ?
Also missing from you list:
- Hard work?
- Dedication?
- A 'can do' attitude?
In the end it's easy to remove yourself from the race by rationalizing that since you don't have the 'lucky' ingredients you mention, it's not even worth trying.
Yes, and 10x basketball players usually have a lucky combination of:
-6'+
-Having a close family member who is an athlete
-Playing sports since 9
-Naturally athletic physique
-Decent cooperative and competitiveness
I only meet 2 of those and 6'+ is definitely not one of them, but I don't avoid basketball because I'll never be as good as a "10x" basketball player (probably NCAA D1 level, Euroleague). In fact, I play often, and years of that have made me an at least serviceable player.
What I'm saying is maybe you'll never be a 10x dev (I won't be) and a large part could be because you don't have the traits you mentioned - which in my experience, definitely describes most of the 10x types I know. but hard work over time can get any person of average talent to at least a 2x or 3x dev (or basketball player). So there is no reason to beat yourself up if you aren't Einstein. A person is competing with themselves.
Tangential point that I think is important is to realize that 10x work is very contextual to how you frame a job.
People are talented but they often aren't asked to do very much. Most jobs don't give all that much responsibility and even then they weigh you down with oversight and meetings.
So, in those jobs, one of the hallmarks of a 10x performer is someone who rejects that baggage. A lot of 10x performers are kind of jerks where they stand up to the status quo and choose their own path. That sort of job is setup to select for only 10x performers who are also willing rebels.
But... many times that I've given more responsibility to someone I've ended up seeing them perform better and more than anywhere else in their career. I think that's nothing more complicated than that people have a lot of untapped talent. Roughly, I'd say if you asked all of the people you worked with to do 10x work that half of them would be able to.
I never saw productivity as a function of raw speed of churning out code. Some of the most productive engineers I know are about average at coding. They just seem to know how to perceive which areas of work would have the most impact, and focus on them. They are also generally experienced enough to avoid pitfalls, both technical and organizational.
The few engineers I know who approach 10x productivity have done so by building tooling that helps all the other engineers do their jobs easier.
Has there been much written on the culture that led Shekhar Kirani (the author of the infamous thread) to such conclusions about 10x devs? I’m curious about how software development is different in places outside of SV—I’m not prepared to cast any judgments of my own.
When I was coding full time I always followed a simple principal: if you really love this system and want it to succeed even after you leave the company, then keep it as simple as possible - sure, you could condense those ten lines into some unintelligible masterpiece, but right now they could be understood by any other developer, and if you really want that code to live a long life then just make sure there’s no barrier to entry for the next person who maintains it. If they’re junior, they’ll still be able to maintain it and if they’re a rock star they’ll get what you were up to.
I love to improve on every aspect of programming. On every field you can become 10 times better and combined it is just awesome to be able to provide solutions that defend against changes.
For example lately I have created VSCode extension to show myself messages with things I don't remember or that help me code without Googling all the time.
The result is great because coding is much much faster and streamlined.
But also there are other areas to pursue 10x speed. For example navigating in an organization, getting necessary information fast, vetting ideas fast with client and team. Going for good solutions rather than partial ones. I love programming for that. You can become better and better all the time. And when everything clicks, nothing can replace that feeling!
42 comments
[ 3.4 ms ] story [ 25.5 ms ] thread1. Understand the problem and the solution. Figure out the best tools to use for it. Learn just what I need for version 1 if necessary.
2. Implement version 1. It works. It's ugly. But it's efficient. It's my MVP and I can get by with it if other duties call.
3. Observe what's truly missing. Add to knowledge base and improve the solution. Refine. Test. Refine. Deploy.
4. Document everything.
I used to be the kind of guy who read whole books to implement something because I had FOMO. Now I focus my energy on what I need to solve the problem. During downtime, I might expand my overall knowledge because it's necessary or I'm curious.
Am I a 10x dev? I don't think so. But I like where I am at and always want to improve.
There is no right or wrong answer here I guess. It's just what aligns with your goals, how you've prioritized things and what makes you happy.
Mind expanding on this?
You'll find some companies where the most effective use of your time is building, because everybody else plans. You'll find some companies where the most effective use of your time is tooling. You'll find companies where the most effective use of your time is doing product work. You'll find companies where the most effective use of your time is challenging the business status quo.
Did you assume that, and avoid clicking the link? It doesn’t suggest a universal rule for productivity, and even starts by predicting your reaction: “It’s not a clickbait title, but I understand why it looks that way.”
> it’s going to be a function of the environment you find yourself in.
The article agrees with you, and talks about some specific ways to be a force for good in creating that environment for yourself and for those around you. Is it perhaps worth a quick glance before jumping to conclusions?
No, I read it, and regretted reading it, and figured I should save others the trouble. I specifically called it out as baity because it claims not to be, which is ludicrous, because it's a meandering piece that isn't really saying much ("try boneheaded solutions") of anything, seems like a mix of generalities, caveats, and self-promotion.
I'd challenge you to ask yourself this -- Is there even the slightest chance that anybody who reads this article is going to become 10x as productive from this "technique"?
If not, then that seems the definition of linkbait.
I don’t know whether it would convince someone, especially someone who’s in a pessimistic frame of mind, to be more productive. But I will say this: after a couple of decades of professional programming experience, the number of times I’ve seen extremely “productive” people who think they’re clever over-engineer the shit out of something that ends up wasting a ton of money and time for entire teams, I can’t even count. It’s a very good point to stop and evaluate whether there are ‘boneheaded’ solutions you’ve overlooked, rather than try to hero-code something complicated.
I also think it’s very true that mentoring others and helping the team is how you achieve this symbolic notion of ‘10x’, and this point does get overlooked sometimes in other discussions and blog posts on code productivity. There is, of course, no objective metric here at all, and the number 10 is being used metaphorically, mostly because it’s basically a meme at this point, which is obviously why it was used in the title, so I think it’s reasonable to avoid taking it literally and using it as the criteria for whether the writing is valid.
Anyway, cheers, I hope you find some articles here that reach you in a positive way.
A 10x developer doesn't (usually) write 10x as much code. They get 10x the work done in 1x of the time. The quantity of work output is famously not measured in SLOC.
I've had the pleasure to work with a few. We all know the names of most of the dozen of 25x or 50x developers that exist in the world.
I think this person is writing to their preordained conclusion that the idea of a 10x developer is a myth. It's not.
He was brilliant, probably slightly autistic, spoke multiple (human) languages fluently (that he had taught himself, not grown up speaking or learned in school), and easily wrote 500-1000 lines of great code per day (not that that's the metric, but that's what I'd see when running `git pull`), implementing feature requirements in a front-end web application. His work truly had a "wow" factor. Give him a very big job that would take the average 4-person team more than 6 months, and it would be done in less than a month.
As a senior developer on that team, I quickly learned that the best use of my time was to remove roadblocks and streamline his workflow.
I worked across from him in an office for a couple of weeks one time, and was impressed at how focused and disciplined he was -- more than anyone else I ever saw. Every moment of the work day he was scrolling and typing into his editor. A quick break every few hours, and then back to work.
http://antirez.com/news/112
1) identify the most important problem you're facing 2) solve it somehow
If you get better at your craft, you can get better at #2 as you'll understand the costs and benefits of different approaches and how to accomplish them.
You may wish to select an environment that makes use of your skills vs one that uses skills you don't care about.
10x developers are usually people who have the lucky combination of:
-Having a close family member who understands computers
-Programming since 9 years old
-Naturally high IQ
-Decent emotional development and communication skills
Also missing from you list: - Hard work? - Dedication? - A 'can do' attitude?
In the end it's easy to remove yourself from the race by rationalizing that since you don't have the 'lucky' ingredients you mention, it's not even worth trying.
That would be unfortunate...
-6'+
-Having a close family member who is an athlete
-Playing sports since 9
-Naturally athletic physique
-Decent cooperative and competitiveness
I only meet 2 of those and 6'+ is definitely not one of them, but I don't avoid basketball because I'll never be as good as a "10x" basketball player (probably NCAA D1 level, Euroleague). In fact, I play often, and years of that have made me an at least serviceable player.
What I'm saying is maybe you'll never be a 10x dev (I won't be) and a large part could be because you don't have the traits you mentioned - which in my experience, definitely describes most of the 10x types I know. but hard work over time can get any person of average talent to at least a 2x or 3x dev (or basketball player). So there is no reason to beat yourself up if you aren't Einstein. A person is competing with themselves.
People are talented but they often aren't asked to do very much. Most jobs don't give all that much responsibility and even then they weigh you down with oversight and meetings.
So, in those jobs, one of the hallmarks of a 10x performer is someone who rejects that baggage. A lot of 10x performers are kind of jerks where they stand up to the status quo and choose their own path. That sort of job is setup to select for only 10x performers who are also willing rebels.
But... many times that I've given more responsibility to someone I've ended up seeing them perform better and more than anywhere else in their career. I think that's nothing more complicated than that people have a lot of untapped talent. Roughly, I'd say if you asked all of the people you worked with to do 10x work that half of them would be able to.
Sometimes there are just no magic solutions.
The few engineers I know who approach 10x productivity have done so by building tooling that helps all the other engineers do their jobs easier.
For example lately I have created VSCode extension to show myself messages with things I don't remember or that help me code without Googling all the time.
The result is great because coding is much much faster and streamlined.
The extension name is Assistant: https://marketplace.visualstudio.com/items?itemName=tomasz-s...
But also there are other areas to pursue 10x speed. For example navigating in an organization, getting necessary information fast, vetting ideas fast with client and team. Going for good solutions rather than partial ones. I love programming for that. You can become better and better all the time. And when everything clicks, nothing can replace that feeling!