Live data from Hacker News

Some reasons to work on productivity and velocity

danluu.com

141–150 of 183 posts

Re: Some reasons to work on productivity and velocity

#141
post #135

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).

It’s a very, very common misinterpretation. People see the number 10× and immediately go to the straw–man of the mythical average programmer.

Re: Some reasons to work on productivity and velocity

#142
post #135
post #84

Earlier 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…

The study they referred to removed all cases where the student didn't finish the project, so it doesn't have any data points for the worst engineers.

Re: Some reasons to work on productivity and velocity

#143

Earlier 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.

Do thorough research first, so you don’t just look like a drug seeker if you do decide to talk to a doctor. Highly recommend Dr. Russell Barkley’s YouTube videos, as well as Edward Hallowell’s still-relevant book Driven to Distraction.

Re: Some reasons to work on productivity and velocity

#144
post #8

The 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…

I actually think that defining the metrics is half of the game for productivity. Once you define the metrics, it's relatively easy to game it.

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

#145

As 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

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?

Re: Some reasons to work on productivity and velocity

#146

I 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…

If your motivation is to be able to work "at a FAANG or any of these beautiful environments with amazing people dedicated to the craft of engineering", then maybe it's more useful to think of the advice in terms of, making it easy to get a job "where your job really is just engineering and good engineering is recognized and rewarded". Or is this not actually your motivation and it's more to lightly mock people who grinded to get such jobs? If you've never worked at a company that has amazing people, that was a beautiful environment, that had dedication to craft, then it might be difficult to believe that such companies do exist. But once you enjoy it and recognize it, then that just becomes your standard for companies, so you'll only interview at companies that you think might meet that standard, you carefully evaluate them during the process, and you switch if you find that not to be the case.

Re: Some reasons to work on productivity and velocity

#147
post #38
post #35

Earlier 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.

>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.

Re: Some reasons to work on productivity and velocity

#148

Earlier 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?

You can probably think of it as hidden secret in the sense that, here a couple of people who believe they have greatly increased their own productivity, that it gives them an advantage relative to others, and that you need to piece together from their thoughts how you might apply such anecdata to yourself.

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

#149
post #44

Working 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.

velocity = speed + direction

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

#150
post #38

Earlier 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.

If you tell me a programmer wrote a thing in a month, and another programmer wrote a similar thing in a year, I'd assume the 1 month project is easier to understand and work with.

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.

Post reply on HN