Earlier quoted context omitted.
No, you have it backwards. The original claim about “10×” engineers is in the book Peopleware. The author specifically claimed that they had observed at least an order of magnitude difference between the best and the worst software engineers. This is very much talking about variation between individuals, not comparing the extremes to the average. The average engineer is I guess somewhere around 3×, but note that this…
Great, thanks for the detailed clarification — I wasn't aware of the book reference: it was my impression that everybody compares to an "average engineer" when talking about 10x, so perhaps it has entered "common knowledge" as a misinterpretation (or maybe it's just my misinterpretation, which is most likely).
Some reasons to work on productivity and velocity
141–150 of 183 posts
Re: Some reasons to work on productivity and velocity
#142Earlier quoted context omitted.
You went from "10x the average" (which the claim is about) to 10x between arbitrary people: it's obvious why the latter is true (some people just need to terribly suck at something), it's harder to buy into the 10x the average performance because of... how hard it is to define (improvement in) performance when you are not starting off of (near) zero.
No, you have it backwards. The original claim about “10×” engineers is in the book Peopleware. The author specifically claimed that they had observed at least an order of magnitude difference between the best and the worst software engineers. This is very much talking about variation between individuals, not comparing the extremes to the average. The average engineer is I guess somewhere around 3×, but note that this…
Re: Some reasons to work on productivity and velocity
#143Earlier quoted context omitted.
> Before thinking of improving specific skills, just being able to be focused and working without distraction all day every day would be an order-of-magnitude improvement for me. I solved this problem by going to a psychiatrist, getting diagnosed with ADHD (at age 35), and starting medication. Not an exaggeration—I struggled with compulsive video gaming for almost my entire life; now on medication that issue has just…
Thank you. I was fearing/expecting someone to mention ADHD. I have never been formally diagnosed but everything I read about it feels suspiciously similar to the way my brain is wired. I might have to look into it more seriously. I’m currently 33.
Re: Some reasons to work on productivity and velocity
#144The problem I have with discussions about “productivity” (including 10x engineer chest-beating) is that no one ever defines what they mean by the word. Is it lots of lines of code? Is it clean design and architecture that’s easy to maintain and extend? Responding quickly to business needs? Making a lot of money in a short time? Too often, people arbitrarily choose what they’re good at, or what someone else they admir…
That said, I think software development is a relatively well defined task. There's typically some clear need from clients, and there's some restriction. Your problem space is somewhat confined.
Now, corollary is this: the more restriction you have, the easier you can be productive (or invent a way to be productive). Specialists can be generally more productive than generalists because they can have a more precise definition of "being productive".
Re: Some reasons to work on productivity and velocity
#145As this seems to be about productivity from a respected person, I want to make sure I get the important ideas and I have tried. Is there a context in which this article must be read? Is it a commentary to another? Neither its introduction nor its conclusion seems to capture all of its ideas it is about. I know it is not meant to be readable but I'll appreciate any help.
It is related to this article: https://news.ycombinator.com/item?id=28879240
Re: Some reasons to work on productivity and velocity
#146I suspect the dissenters and Dan are not as far apart as one would expect. What I see in the dissent is a rejection of the specific brand of Silicon Valley rah rah productivity cult. There's a lot of mysticism in SV style productivity, whether it's the new hottest app or the latest lifestyle craze. It's also almost always directed at squeezing more work out of someone who's already working far too much. What Dan's pr…
Very well put. This was sort of my attitude to programming years ago - to try to get really good at the craft. But the question is, is that going to be rewarded or recognized at all? Who makes more, the programmer dedicated to their craft and domain getting better every day, or the leetcode expert who jumps from one FAANG to another getting 30% raises each time? What is the track for promotion at most companies - bei…
Re: Some reasons to work on productivity and velocity
#147Earlier quoted context omitted.
Eh, there are two archetypes in this industry: One who pounds out the solution in an hour, is not smart enough to perceive its flaws. One who takes three days because they understand their language, codebase, and requirements.
The thinking pattern "I don't want to get faster, I prefer writing quality code" is a false dichotomy. The fastest programmers writes quality code, since quality code is much easier to get right and working with which are the most important factors for being a fast coder.
I've spent effective years of my life unfucking code written by fast programmers because no one can extend, change or understand their code.
As far as I am concerned the probability that a fast programmer also writes quality code is approximately 0.
There are outliers out there. But if you tell me someone is a fast programmer I'm not betting they write quality code.
Re: Some reasons to work on productivity and velocity
#148Earlier quoted context omitted.
It is related to this article: https://news.ycombinator.com/item?id=28879240
Thanks! Your reply was helpful in giving the background although the background itself wasn't so helpful. Just to be sure, is the sole purpose of these articles to suggest why (and not how) to improve productivity? I think I am looking for the secret to 10x productivity which is still hidden somewhere inside those articles. Or is it?
My interpretation of these articles is that it is worthwhile to become faster and more productive, that there are real tangible benefits to your quality of life. And that you might gain a lot of productivity by deliberately training your skill at "low-level" components of your workflow, e.g. doubling your typing speed, practicing writing documents, perfecting the use of your tools.
Re: Some reasons to work on productivity and velocity
#149Working on the right thing means driving in the right direction. Velocity is the speed at which you get there. Anyone that says velocity doesn't matter is wrong and there should be no debate.
If you are able to achieve speed that is 2x, then as long as your angle is less than 60 degrees off axis from the theoretical perfect direction, you're making progress towards the goal faster than everyone else. Though I wouldn't be surprised to find out that your error is not nearly that high, and given your high amount of practice/experience, you might even end up with the least amount of angular error amongst your peers.
Re: Some reasons to work on productivity and velocity
#150Earlier quoted context omitted.
The thinking pattern "I don't want to get faster, I prefer writing quality code" is a false dichotomy. The fastest programmers writes quality code, since quality code is much easier to get right and working with which are the most important factors for being a fast coder.
>The fastest programmers writes quality code I've spent effective years of my life unfucking code written by fast programmers because no one can extend, change or understand their code. As far as I am concerned the probability that a fast programmer also writes quality code is approximately 0. There are outliers out there. But if you tell me someone is a fast programmer I'm not betting they write quality code.
Fast programmers writes most shitty code, yes, but that is because fast programmers writes most code period. I have seen nothing to suggest that an average slow programmer actually produces quality code when given the time, it seems to be the opposite, most slow programmers have terrible mental models and create even bigger messes if you give them the time to do it.
Are there slow programmers who produce quality code? Yes, but in my experience those are the exception and are even rarer than fast programmers who produce quality code.