Comment by jdlshore
5 years ago
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.)
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.
> If you need an X, how quickly can you implement an X at a high level of quality?
That's the wrong question for anyone who's not a new grad junior engineer. If these are the only kinds of question you're addressing, you're probably replaceable by a Ukrainian dev shop.
In reality depending on your particular role and organization the questions you need to answer range from "How do I find product-market fit" at an early-stage startup to "How do I meet my client's requirements" to "How do I move the needle on X metrics" at a big company.
The key difference between these kinds of questions is that there can be many different routes, and measuring "productivity" in one metric limits the ability to explore. For example, "How fast can you implement a chat widget" doesn't allow for the exploration of alternative ways to engage with customers -- emailing them directly might've been much better.
Even assuming you are very "focused" on pure engineering, measuring the speed of implementing X doesn't account for "productivity" on a personal level, i.e. perhaps you built it in 5 days but now you're burnt out for the next month. Or you had other projects you didn't end up working on. Or you neglected your family. By the way, you handwaved over "X level of quality" but I'm sure we all know that this in itself is nontrivial to gauge.
There are many goals that may count as "productivity", and you don't necessarily even know all of them. Therefore its quantification is nontrivial.
> "How fast can you implement a chat widget" doesn't allow for the exploration of alternative ways to engage with customers
If you make a list of alternatives, and you don't know which one is the best, having higher overall velocity allows you to try more options.
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.
10 replies →
... and with these architypes, the definition of a 10x-er would be - One who pounds out the solution in an hour because they understand their language, codebase, and requirements.
There are also a freaking ton of mediocre programmers who take three days to pound out flawed solution.
See: the recent story about Missouri revealing SSNs of teachers.
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.
after doing a few kinds of jobs:
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.
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.
6 replies →
None of that experience translates to programming work imo
3 replies →
Somehow, this never really clicked for me before.
Mind blown.
Thanks!
How much sleep do you get?
My problem isn't sleep, my problem is skipping meals which screws with my energy. I always get at least 8 hours of sleep.
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.
> 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?
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.
2 replies →
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.
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.
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.
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 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.
3 replies →
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".
It's measured by tweeting, github social actions and giving talks at conferences
productivity is delivering value to your customers