14 ms·

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 lo

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 admire is good at, call that “productivity,” and then come up with a post-hoc rationalization of why that’s good. Note: I only skimmed the article, so consider this a comment on productivity discussions in general rather than the specific article. (Oh, and a pet peeve: the agile concept of “velocity” originally introduced by Extreme Programming is absolutely not a measure of productivity. It’s a way of predicting your capacity for the next iteration. I’ve taken to calling it “capacity” instead of velocity for that reason.)

Graffur 5y ago
It's measured by tweeting, github social actions and giving talks at conferences
karmakaze 5y ago
10x engineer: one that produces 10x the solutions, or creates 1/10th the problems, or a mix of the two--over a long enough time span to include second-order effects. The weak version of the term is one that enables the team to produce 10x, or ..., which I personally don't go for, it's watering down a difference in abilities which acknowledging makes people uncomfortable. I would call them sqrt(10)-x engineers who do 3x and let the team do 3x.
foolfoolz 5y ago
productivity is delivering value to your customers
crate_barre 5y ago
At the moment for your typical developer in Agile Disney World, productivity is move a ticket from in-progress to done. Identifying what is high impact, or what’s it’s important to focus on continuously is a form of autonomy that is oddly not offered too much to most of us.
es7 5y ago
Productivity: If you need an X, how quickly can you implement an X at a high level of quality? If your product manager asks for a new widget or api, can you implement it without any major bugs in 1 hour? Or will you take three days because you don't understand your programming language, your codebase and your requirements? Will the widget/api be free of major bugs, or will it fail on a variety of edge cases that could have been solved ahead of time? Productivity may not have crisp, clear lines. There's always context. But it comes down to: if you can do X in half the time at the same level of quality, you're twice as productive. I admire Dan Luu's work and this article in particular really resonated with me.
- jeffbee 5y ago
  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.
  - Jensson 5y ago
    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.
    - jeffbee 5y ago
      I agree there's not a natural tension between quality and speed, but the speed part is really hard to measure. You must consider the time of all future readers and maintainers of the code you are writing. Spending time to write a test or comment today is an investment that pays back in future fast iteration. Saving time by skipping code review, dashing off weird and confusing interfaces or variable names without revisiting them in a second pass, that type of thing is the opposite: it can appear to save you time today, but is costing you future time.
      - 5y ago
friedman23 5y ago
I used to be amazed wondering how people claimed to work 12 hours a day until I realized they consider writing emails and talking to people on the phone work (which it is). But of course me being a software engineer I imagined for some reason when they said work they meant something like coding which after 6 hours has me drained.
- gliese1337 5y ago
  Somehow, this never really clicked for me before. Mind blown. Thanks!
- agumonkey 5y ago
  after doing a few kinds of jobs: - food retail: producing hundreds of sandwiches an serving hundreds of customers back to back, teaches you about productivity - landwork: 8000 picks per day teaches you about work maybe i'm masochistic, but whenever I see people relaxed at work, neither doing much nor thinking much, I consider it's not work. There's no difference between what they do and me at home chilling.
  - handrous 5y ago
    I've done tough physical labor, and repetitive physical labor. They may wear out the body (or may invigorate it, depending on the load), but the mind is fresh even after 8+ hours, in my experience. And it feels good. After six hours of typey-typey in front of a screen I feel used up. Worthless. Dead. And that's a very good day—four is more typical for "how long can I do computer work before I just want to curl up and do nothing until I fall asleep?". I mean four hours of actually working, mind you, not screwing around, but still. I know for a fact I don't have a general work ethic problem that prevents me from going past 4-6 hours of computer work in a day—I have a "this particular shit—computer shit—sucks the life out of me like nothing else" problem. Always been that way, even when I was young. Work? I'll do it 'till I drop and feel good about it. Computer work? Uuuuugh, if I have to, I guess, but I'll hate it the whole time and feel like shit when I'm done, which, BTW, won't take long. But, anything I could do that wouldn't involve sitting in front of a computer much of the day would mean a 60+% pay cut, so... here I am.
YZF 5y ago
I'm gonna try. Productivity is the discounted future cash flow per hour of work. Here's what it's not: It's not about how much code you write. It's not about the quality of the code. It's not about clever engineering solutions. All these can (and should) be part of the above, or they may not. Sometimes sucky code that can bring in a billion dollars is better than great code that brings in nothing. Technical debt is fine as long as the "interest" on that debt is << the profit you made by taking on that debt. Just like any other debt. A business pays you $X an hour, what are they getting out of you $-wise? To be clear, that doesn't mean that e.g. someone working on internal tooling can't be productive, but their productivity is measured by the impact on someone else who eventually uses the tooling to make money somehow. This is incredibly difficult/impossible to measure perfectly, certainly on an individual level, but I still think it's worthwhile to look at it like this... EDIT: I totally agree with the spirit of "sharpen your axe" and "be good at what you do". I spent a lot of time as a teenager learning to type fast. I did coding competitions to learn how to code real fast. This is part of what being a craftsman is about. But the leverage there is really limited. I liked what one of my ex-CEOs used to say, that just because he types fast doesn't mean he should do his secretary's work. So after you know what you're doing, you have the right approach, you're the right person to do this, all the other business factors, you should definitely excel at doing it.
- tshaddox 5y ago
  > Productivity is the discounted future cash flow per hour of work. That's not an unreasonable proposal, but isn't the whole point of startups that we're playing with upsides that are extremely huge and extremely unlikely? It seems like it would be extremely difficult to apply this definition to an engineer or a very small engineering team at an early-stage startup. Surely all the functionally equivalent restaurant delivery apps (at least those above some reasonable baseline of engineering competence) had very similar engineering going on in the early days, yet most of them you barely remember while a very small number of them are unicorns. But could you really have looked at an engineer in the early days and picked out the difference?
  - YZF 5y ago
    For sure. In that context, the engineer that got the product to work before the startup ran out of money and shut down by deciding to hack around some issues rather than "do it properly" is the more productive engineer. Another way to think about this is the engineer that better optimizes the expected present value (sure, there might be a pretty wide distribution of outcomes). At the very least I feel like this business/economic context is very important, and often ignored. Without it it's very hard to say because in a different context the engineer that creates the very same hack maybe just cost the company a lot of $'s in future maintenance work.
ltbarcly3 5y ago
Note: I only skimmed your comment, so consider this about something else. Programmers protest too much about 10x programmers. Saying there isn't a 10x programmer is the same as saying nobody could possibly work hard and improve enough to be that much better at something. But we know that every single activity we can objectively measure has far more than a 10x variation in performance. Why is there someone 10x better than average at assembling Ikea furniture, or shooting a bow and arrow, or juggling, or running, or even eating, but programmers are interchangeable cogs? Its a totally bizarre thing to even consider without very strong evidence, and that evidence doesn't exist. Seems like sour grapes to me.
- necovek 5y ago
  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.
  - db48x 5y ago
    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 was a qualitative statement rather than a quantitative one; I chose the geometric mean because we are talking about multiples, but we shouldn’t forget that this isn’t based on concrete numbers. The average could be 2× or 5× or anything else. Note that they are referring to the worst software engineers that could keep their jobs; these people probably still had net positive productivity for their companies. Note also that this was across many companies that the author had consulted for; any individual company likely had a narrower range of ability. Because of company policies, management styles (aka manglement), mistakes, cost–cutting, or whatever, there are companies that absolutely fill up with 1× programmers. Also, the best and worst programmers are not necessarily at the same stage of their career; the 10× engineer is much more likely to be a greybeard who has seen it all and knows how to get results, while the 1× engineers are much more likely to be fresh out of college. The whole point of the book is that we can deliberately set up an environment where engineers are allowed to grow and succeed, or we can set up an environment that drives away anyone with skill. If management can do the former, then the company can succeed. Too often management sets up a system that is actively hostile to success, and then has to hire consultants to come and tell them how to fix it.
euske 5y ago
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".

Graffur 5y ago

It's measured by tweeting, github social actions and giving talks at conferences

karmakaze 5y ago

10x engineer: one that produces 10x the solutions, or creates 1/10th the problems, or a mix of the two--over a long enough time span to include second-order effects. The weak version of the term is one that enables the team to produce 10x, or ..., which I personally don't go for, it's watering down a difference in abilities which acknowledging makes people uncomfortable. I would call them sqrt(10)-x engineers who do 3x and let the team do 3x.

foolfoolz 5y ago

productivity is delivering value to your customers

crate_barre 5y ago

At the moment for your typical developer in Agile Disney World, productivity is move a ticket from in-progress to done. Identifying what is high impact, or what’s it’s important to focus on continuously is a form of autonomy that is oddly not offered too much to most of us.

es7 5y ago

Productivity: If you need an X, how quickly can you implement an X at a high level of quality? If your product manager asks for a new widget or api, can you implement it without any major bugs in 1 hour? Or will you take three days because you don't understand your programming language, your codebase and your requirements? Will the widget/api be free of major bugs, or will it fail on a variety of edge cases that could have been solved ahead of time? Productivity may not have crisp, clear lines. There's always context. But it comes down to: if you can do X in half the time at the same level of quality, you're twice as productive. I admire Dan Luu's work and this article in particular really resonated with me.

jeffbee 5y ago
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.
- Jensson 5y ago
  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.
  - jeffbee 5y ago
    I agree there's not a natural tension between quality and speed, but the speed part is really hard to measure. You must consider the time of all future readers and maintainers of the code you are writing. Spending time to write a test or comment today is an investment that pays back in future fast iteration. Saving time by skipping code review, dashing off weird and confusing interfaces or variable names without revisiting them in a second pass, that type of thing is the opposite: it can appear to save you time today, but is costing you future time.
    - 5y ago

friedman23 5y ago

I used to be amazed wondering how people claimed to work 12 hours a day until I realized they consider writing emails and talking to people on the phone work (which it is). But of course me being a software engineer I imagined for some reason when they said work they meant something like coding which after 6 hours has me drained.

gliese1337 5y ago
Somehow, this never really clicked for me before. Mind blown. Thanks!
agumonkey 5y ago
after doing a few kinds of jobs: - food retail: producing hundreds of sandwiches an serving hundreds of customers back to back, teaches you about productivity - landwork: 8000 picks per day teaches you about work maybe i'm masochistic, but whenever I see people relaxed at work, neither doing much nor thinking much, I consider it's not work. There's no difference between what they do and me at home chilling.
- handrous 5y ago
  I've done tough physical labor, and repetitive physical labor. They may wear out the body (or may invigorate it, depending on the load), but the mind is fresh even after 8+ hours, in my experience. And it feels good. After six hours of typey-typey in front of a screen I feel used up. Worthless. Dead. And that's a very good day—four is more typical for "how long can I do computer work before I just want to curl up and do nothing until I fall asleep?". I mean four hours of actually working, mind you, not screwing around, but still. I know for a fact I don't have a general work ethic problem that prevents me from going past 4-6 hours of computer work in a day—I have a "this particular shit—computer shit—sucks the life out of me like nothing else" problem. Always been that way, even when I was young. Work? I'll do it 'till I drop and feel good about it. Computer work? Uuuuugh, if I have to, I guess, but I'll hate it the whole time and feel like shit when I'm done, which, BTW, won't take long. But, anything I could do that wouldn't involve sitting in front of a computer much of the day would mean a 60+% pay cut, so... here I am.

YZF 5y ago

I'm gonna try. Productivity is the discounted future cash flow per hour of work. Here's what it's not: It's not about how much code you write. It's not about the quality of the code. It's not about clever engineering solutions. All these can (and should) be part of the above, or they may not. Sometimes sucky code that can bring in a billion dollars is better than great code that brings in nothing. Technical debt is fine as long as the "interest" on that debt is << the profit you made by taking on that debt. Just like any other debt. A business pays you $X an hour, what are they getting out of you $-wise? To be clear, that doesn't mean that e.g. someone working on internal tooling can't be productive, but their productivity is measured by the impact on someone else who eventually uses the tooling to make money somehow. This is incredibly difficult/impossible to measure perfectly, certainly on an individual level, but I still think it's worthwhile to look at it like this... EDIT: I totally agree with the spirit of "sharpen your axe" and "be good at what you do". I spent a lot of time as a teenager learning to type fast. I did coding competitions to learn how to code real fast. This is part of what being a craftsman is about. But the leverage there is really limited. I liked what one of my ex-CEOs used to say, that just because he types fast doesn't mean he should do his secretary's work. So after you know what you're doing, you have the right approach, you're the right person to do this, all the other business factors, you should definitely excel at doing it.

tshaddox 5y ago
> Productivity is the discounted future cash flow per hour of work. That's not an unreasonable proposal, but isn't the whole point of startups that we're playing with upsides that are extremely huge and extremely unlikely? It seems like it would be extremely difficult to apply this definition to an engineer or a very small engineering team at an early-stage startup. Surely all the functionally equivalent restaurant delivery apps (at least those above some reasonable baseline of engineering competence) had very similar engineering going on in the early days, yet most of them you barely remember while a very small number of them are unicorns. But could you really have looked at an engineer in the early days and picked out the difference?
- YZF 5y ago
  For sure. In that context, the engineer that got the product to work before the startup ran out of money and shut down by deciding to hack around some issues rather than "do it properly" is the more productive engineer. Another way to think about this is the engineer that better optimizes the expected present value (sure, there might be a pretty wide distribution of outcomes). At the very least I feel like this business/economic context is very important, and often ignored. Without it it's very hard to say because in a different context the engineer that creates the very same hack maybe just cost the company a lot of $'s in future maintenance work.

ltbarcly3 5y ago

Note: I only skimmed your comment, so consider this about something else. Programmers protest too much about 10x programmers. Saying there isn't a 10x programmer is the same as saying nobody could possibly work hard and improve enough to be that much better at something. But we know that every single activity we can objectively measure has far more than a 10x variation in performance. Why is there someone 10x better than average at assembling Ikea furniture, or shooting a bow and arrow, or juggling, or running, or even eating, but programmers are interchangeable cogs? Its a totally bizarre thing to even consider without very strong evidence, and that evidence doesn't exist. Seems like sour grapes to me.

necovek 5y ago
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.
- db48x 5y ago
  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 was a qualitative statement rather than a quantitative one; I chose the geometric mean because we are talking about multiples, but we shouldn’t forget that this isn’t based on concrete numbers. The average could be 2× or 5× or anything else. Note that they are referring to the worst software engineers that could keep their jobs; these people probably still had net positive productivity for their companies. Note also that this was across many companies that the author had consulted for; any individual company likely had a narrower range of ability. Because of company policies, management styles (aka manglement), mistakes, cost–cutting, or whatever, there are companies that absolutely fill up with 1× programmers. Also, the best and worst programmers are not necessarily at the same stage of their career; the 10× engineer is much more likely to be a greybeard who has seen it all and knows how to get results, while the 1× engineers are much more likely to be fresh out of college. The whole point of the book is that we can deliberately set up an environment where engineers are allowed to grow and succeed, or we can set up an environment that drives away anyone with skill. If management can do the former, then the company can succeed. Too often management sets up a system that is actively hostile to success, and then has to hire consultants to come and tell them how to fix it.

euske 5y ago

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