10x engineers take long naps
medium.com
medium.com
- "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
"... feel like I’ve never been as productive an engineer as today; and yet, I notice that I’ve never worked less hours in a given week"
This is more of a thought piece than anything.
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.
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)
> 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.
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.
Are making good decisions and IQ directly correlated?
Even Google admits that IQ is the best predictor of job performance but they go on to say that the metric is discriminatory.
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.
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.
In my experience, clever (usually simple) architecture in solving a problem will always beat clever code, and volumes of code.
... or the infamous -10x developer.
Count your blessings.
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.
Interesting to think it goes in both directions!
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.
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).
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.
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 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.
> 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?
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.
They are forces of nature, prolific creators that deliver when they have to, and lift up entire teams to be better when they work with others.
The right kind of compounding experience goes a long way.
"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".
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.