- "I have to get this done today, no matter how long it will take" -> procrastinate the whole day, waste the night to do the stuff in low quality, using "it's late now" as an excuse.
- "I have to leave early today" -> productive focuessed work to get some stuff done before the time runs out
Case 1 happens to me when I don't completely understand the problem so I don't know where to start. This leads me to procrastinate. I lack a sense of direction in those cases.
I'll agree, but also add that taking the time to understand the problem is half of the work. If someone just said 'type this in' and gave you the code already formed, it would take a fraction of the time
Sorry, I read over the piece and have zero idea what 'naps' have to do with this - it's only mentioned in the title and once in the conclusion. Really hard to figure out what the take home of this article is - I was hoping it tied sleep cycles into performance or something like that.
It's really incoherent. I think the point was to talk about the subjective perception of your personal productivity but the text is really just a jumble of too many different thoughts at once.
It's a metaphor...the authors' point is that hour in do not equate to value out. An engineer can develop a solution worth tens of thousands of dollars to a company in just a day, by merely automating tedious tasks.
This might be off, but have previously interpreted the term 10x engineer as someone who is a 10x multiplier to the team and brings the collective level of the group up by ~10x. To me, that especially doesn't correlate with cranking out 10x more code or working 10x more hours.
You aren't off at all. The article is making the same argument that the myth of the 10x engineer is not someone who can crank out 10x more lines of code, but someone who can bring 10x (or InfinityX) business value to the company because of what they spend their time working on.
Author here. +1. I didn't mention the multiplying effect of also empowering people, but we agree that the take that defines a "10x engineer" as someone who cranks 10 times more code is irrelevant, even though I have seen it used as such, a lot (mostly as a joke, I must say).
People spend far too much time ruminating about what makes an especially productive programmer. Essentially it comes down to making good choices most of the time, so basically IQ.
Bad developers are bad because they do stupid things. Hallmarks are wheel reinvention, misuse or abuse of patterns, excessive abstraction or complexity, ignorance of security ramifications. You could go on forever but really it just boils down to someone making bad decisions from inadequate knowledge and lack of foresight.
Code written by good developers can be understood and read easily and often appears simple. The extreme complexity that many companies are proud of is just a sign that their developers lack the foresight to build an elegant system.
>You could go on forever but really it just boils down to someone making bad decisions from inadequate knowledge and lack of foresight.
To what level should a developer be at before joining the workforce?
How do we bring all potential developers up to this level so that we can have a smarter workforce?
Can you create an education system that reliably produces developers at that level?
That's what interviews attempt to do, but since those vary so widely between companies (with some being done terribly), you can't get a coherent picture of what to actually learn that will serve you among the greatest number of companies.
This means that, if you can't answer all three questions above, the workforce at large MUST support bad developers writing bad production code at some point in their careers because that is simply how they learn what is and isn't important to know.
If we can't create this system, then we're all complaining about nothing because there's no way to avoid writing bad production code at some point in your careers.
(I specifically mention production code because conceivably, you could just have them learn and write code in a dev environment, then have that code reviewed, but never let them have much of a business impact. Most of us don't care much if someone is writing bad code in a dev environment because that's meant to break occasionally)
>>You could go on forever but really it just boils down to someone making bad decisions from inadequate knowledge and lack of foresight.
> To what level should a developer be at before joining the workforce?
> How do we bring all potential developers up to this level so that we can have a smarter workforce?
> Can you create an education system that reliably produces developers at that level?
The solution is really to give junior developers a level of responsibility (and feedback) that matches their level of experience. Juniors shouldn't be making architectural level decisions or even major design decisions, nor should they be deciding _what_ to build.
They should be receiving feedback on the small-scale design decisions they do make, and exposed to the senior devs' decision-making processes so they can develop that level of knowledge. And their responsibilities and exposure to business goals and impact metrics should be gradually increased as they gain the experience to be able to make larger and higher-level decisions.
> exposed to the senior devs' decision-making processes so they can develop that level of knowledge
This is really important I think. Asking newbies a lot of questions to try and coach a good solution out of them, on their own, is a really great way to get them to "learn to think".
Also I recommend checking out the Blooms Taxonomy.
Good and great developers think about the lifecycle of the code and managing unnecessary complexity so the greatest number of developrs can grow or be competent care takers beyond themselves.
Clear thinking and clever architecture that results in a simple but effective and flexible design will almost always trump any attempt by clever programmers (skilled or not) to build monuments to their cleverness.
The key skill that made a big difference to me is being able to build discipline.
Once I could buold discipline and apply it to learn anything (like improving focus), the effects multiply and compounded.
Discipline strangely is freedom to maximize things. Discipline for me started with being open to the fact that things (lkke 10x dev's) may exist even if I can't fathom it.
People have called me unusually productive, but compared to others I know I don't feel the way.
Author here. I can't really agree with the view that there is a static mindset to being a good/bad developer, and you're one of those and that is that. I think there is an entire spectrum of less-experienced/less-insightful developers to more-experienced/more-insightful developers, and that an individual can absolutely transition from the former to the latter group by building experience and with the right focus. You can view my article as merely an attempt to help less-experienced individuals get there faster with the focus that I believe will carry them further.
> People spend far too much time ruminating about what makes an especially productive programmer. Essentially it comes down to making good choices most of the time, so basically IQ.
Are making good decisions and IQ directly correlated?
I'm seeing it as a feedback loop problem, again. Managers and stakeholders have an easy time remarking on surfaced progress. The developer has to think and communicate everything else. Going purely hands-off doesn't work, because then the developer will tend to wander towards working on the wrong problems and get mired in them. Neither does chaining them down to a deadline, since that creates rushed, ill-considered work.
So the people who are perceptually 10x tend to have hit on a strategy that keeps them in the feedback zone without being overly concerned about surfacing everything right this second, and have management that cooperate with their strategy.
Author here. I agree that being able to produce advanced value is also a factor of the work environment; and not only the engineer's ability to be in touch with it, but also the environment's ability to keep the engineer in touch when they should be. I didn't think of it, but I think it's a great point.
I don't understand why HN readers are so eager to debunk the idea of 10x developer when it's obvious they exist.
For example, in this post you seem to be setting the upper bound around 3x. But actually, it is trivial to be 3x more productive than average: (a) Don't browse the internet while at work; (b) Sit there and spend your time working on the actual problem, not ratholing on programmer fixations that have nothing to do with the end result. Done. Congratulations, you are now 3x, before any consideration is made of experience level or talent or smartness or unique instinct or whatever else.
You make it sound so trivial to do, but in fact if you did that you'd burn out. All that ratholing and reading is in fact resting.
You can only concentrate so many hours a day. Without that resting your productivity drops.
The most productive/best programmer I knew used to piss around flying virtual helicopters for half the afternoon, would throw together prototypes no-one asked him to because he was bored, and went home at 5:30 every day.
I disagree. That ratholing and reading is not resting at all, it is procrastination. If you want to rest, go to lunch or take a coffee break, or meditate or something.
> You can only concentrate so many hours a day. Without that resting your productivity drops.
This is the kind of thing people tell themselves to justify procrastination. If you are unable to concentrate for long, maybe you have damaged your attention span by too much internet browsing, and the cure is just to stop?
I think part of the denial is people can't imagine something is posisble if they can't see how or do it themselves.
Also the age demographic of hn lately is younger and less experienced and perhaps the next wave are still learning about the reality of developers that are many orders of magnitude more effective and productive than their average peers.
Some people are just more prolific than others at certain skills.
This was a good read when it had come out. I can say I know more than a couple of (experienced very bright) 10x developers and they commonly annoy lots of people around them because they're so effective between their technical chops are so high they can focus on using them in the right amount.
The wonderful thing about 10x developers is that you can keep redefining what 10x means to make your point. The 10x developer is a mythical beast that changes with every retelling. There's only one definition with any experimental weight behind it—10x the worst and 2.5x average—which isn't quite terrifying enough to keep telling stories about 'round the campfire.
That's a perfect illustration of what I'm getting at. You can just keep redefining whatever 10x means to make your point. In your example, minus the the initial "Haha", this might as well be lifted from a cover letter or a consultant's sales pitch:
"I have a highly unique track record of delivering entire projects that would take longer schedules or larger teams to complete.
Clients have called me a force of nature, a prolific creator that delivers when the job must get done and one who lifts up entire teams to be better when they work beside me. I provide the right kind of compounding experience that goes a long way."
Such confidence. The hiring managers are swooning over here.
But that's beside the point. Where's the study that meaningfully quantified that type of performance? Especially at an individual, repeatable level? If we can't answer those questions, I must conclude that the current usage of 10x developer is about as meaningful as "passionate ninja rockstar".
Yes, and it's also about inflection points, like avoiding choosing the wrong technology that could make a project 10x less successful than it might have been. Or making the wrong build vs. buy decision. Decisions that require experience and insight, that you have to make early and will be impactful and can't be easily reversed when they turn out to be mistakes.
Author here. You're basically summarizing my entire article in a much (MUCH!) more digest and straightforward way. So, yeah, absolutely +1000 and thanks for that!
I actually read some of the research that produced the 10x number.
The 0.1x developer, if they're actually competent enough to remain employed for more than a probationary period, probably isn't at 0.1x; you're probably underrating them because you're better than average and are thus overrating what average is. (This is part of the Dunning-Kruger effect).
-10x developers should be fired fairly quickly if they're actually that negative and the business is being managed competently. I've worked with a few; they were fired within months or weeks.
It's a common misconception that the Dunning-Kruger effect is just about dumb people not knowing they're dumb. In fact, it's about something we all do - overestimating our knowledge and competence in areas where we have little of both. It's worth recognizing the distinction because everyone is subject to the Dunning-Kruger effect when we're out of our depth in some area and there are a lot of "unknown unknowns".
Yeah, most people know "too dumb to know I'm dumb." The "too smart to know I'm smart" is less well known but it has a lot of implications.
For instance, highly skilled people will often underestimate the difficulty of a task for average skilled people, because they complete it with relative ease. It's effectively an overestimation of what "average" is, because they think of themselves as average when they're really not.
"Relative" is the key word here. Your natural high skill performer may think a task is difficult, but they don't necessarily find the same sources of difficulty as average people.
I've always heard the "too smart to know I'm smart" as manifesting differently. Getting better improves two distinct sub-skills: excution, and perception of performance flaws. Dunning-Krugar effect, to me, just says that flaw perception grows faster with skill than execution does.
At a concrete level, I remember watching a lecture from a Jazz instructor by the name of Hal Galper, who said something like "Not liking the music you're playing is a sign that you're getting better, since it means you can now hear the mistakes you've always been making". It's really stuck with me through learning other creative pursuits (dance, in particular).
I have heard someone else say a similar thing about writing, and I believe it. They described it as "having or developing taste", and were encouraging people to keep writing through those feelings because as they got better it would help them know what to write and what not to write.
Dunno if I've seen it in software development, but I also don't have any real objective estimation of how good I am at software development.
It does, and has since its original discovery. Though the effect is not as pronounced as its popular conception would have you believe. The poor performers overrated their performance, but did not rate it higher than the high performers did. It is more like the grandparent observed that everyone tends to think of themselves as close to average.
No. The negative ones usually form crowds and alliances, and with a lot of backpadding and self management it leads to your typical failed projects. Many of them are very high-profile, and they would never have the insight that they are actually more destructive than useful. That's why forks do exist.
"I can tell you of a few engineers currently working on technical problems that offer zero promise to add any business value to their companies, just for the sake of the technical problem being interesting and challenging, the engineer being too inexperienced or not value-driven enough to realize why it’s misguided, and their leadership being too little technical to understand that this work should probably be reprioritized."
I think the author works on my team.
Since starting my current gig I've built several functioning prototypes at work that have business value. After about 1.5 years I was given lead on a project that just shipped to production, which serves a business need. I don't really consider myself a 10x programmer, but I create useful stuff.
The lead developer on our team has been spinning wheels on a project whose result is supposed to be useful. The problem is he doesn't have the proper technical knowledge, and our manager is even less technically inclined than him. He simply smiles and nods whenever the lead spews jargon at him. This project has been going on several years without tangible results. It blows my mind.
My issue isn't that his project is useless, it's that our manager strongly urges me to follow his advice. I can't follow the advice of any engineer, lead or otherwise, whom I've never seen ship a system. Period. So I just do what any good engineer does - whatever I think is best for the company.
Edit: The sad part is I'm only working 20 hours a week on average. When I work from home I do take naps right after lunch; usually for about 2 hours. I could actually take on a second job and still be sane. It's quite dumbfounding to see what passes for "productivity" in corporate America.
Author here. Fortunately, none of the engineers I was referring to are on my team. ;)
Still though, I believe you're looking at this right, and by worrying about that, I believe it shows that you are part of the solution rather than the problem. I was working for an employer that was grossly under-using me in the past, and just like you, it felt so useless I had the feeling I could work another similar job simultaneously (I got involved with a lot of non-work-related stuff at the time). I couldn't leave because of visa ties; but as soon as I could, I did, and the growth of my career could finally resume. I consider that year to have been a temporary pause on my career progress, I'm glad it could be that temporary.
I know there are many good reasons to stay in a non-perfect job; but are you considering that your knack for doing the most useful thing for your employer could be better valued by another one?
- "I have to get this done today, no matter how long it will take" -> procrastinate the whole day, waste the night to do the stuff in low quality, using "it's late now" as an excuse.
- "I have to leave early today" -> productive focuessed work to get some stuff done before the time runs out