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.
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.
This is sometimes true. On a project long-term, will you keep velocity up by writing quality code? Yes. In certain, narrow areas (very "mathy" code, perhaps, that doesn't interact much with he world) might you go faster by writing quality code from the beginning? Maybe.
However, can one also go much faster by: not writing tests one ought to have written; ignoring security issues; ignoring input edge-cases; ignoring output edge-cases; treating a variety of variables as constant, or as having bounds that they actually do not; not writing enough documentation; et c.? Oh my god, yes. Of course.
Anyone who's ever seen a "we're really happy with the output of our outsourced team on this Rails 'app', they've gotten this MVP ready so fast!" codebase knows that's definitely also a way to be fast, and that a team writing actual quality code and not putting in a ton more hours couldn't have matched that team's "productivity", because they'd have been doing way more work.
OK, what you're saying definitely applies when we incentivize speed and forget everything else, or when we compare ourselves to others without knowing the whole story. But this current discussion is in the context of someone's personal goals to improve their own productivity from their existing baseline. Valuing that doesn't necessarily mean they have to stop valuing quality or maintainability.
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.
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 nothing about either, because there’s too many parameters at play.
If a project took only 1 month, I’d be very cautious with calling it easier to work with, because it likely means fewer tests (leading to lower velocity long-term) and fewer hours spent by other developers trying to understand it, and giving feedback on how to improve legibility.
Creating something quickly can be really important in specific contexts, but actually KEEPING something flexible to work with, hard to break, and easy to understand is more important when dealing with software that’s supposed to last over many developers and a long period of time.
Maintaining velocity requires you to spend more time on keeping the code base healthy.
I find the notion of being a fast programmer irrelevant in a business-context. Because there I think it’s more valuable to be a programmer that can ensure business goals are met on time, ensuring the correct problems are solved, ensuring contracts aren’t broken, while still keeping the code base professional (i.e. well-tested, clean, consistent).
Being a fast programmer is great and all, but being reliable is the more favorable trait if I had to pick one. Both require huge amounts of active training.
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.
> 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
Nobody here is saying you should do this, it is a strawman. Rather being fast means that you can revisit your interfaces 10 times rather than 2 times, spend more time thinking about your names, have more time to write tests, review everything several times before code review so no issues are found etc, ultimately producing much higher quality code.
It seems like you think this article is about "I write code quickly by not doing things properly", rather than "I practice to become faster".
I have no disagreements with the article at all. I only disagree with the idea that "doesn't understand the language/codebase/requirements" can only cause slowness. That condition is at least equally likely to cause the fast solution.
The real "10x programmers" I have known spend practically all of their time deleting and refactoring code. A handful of fake 10x'ers I have met in my career, who enjoyed a reputation of rapidly dashing off MVPs, were stone-cold idiots, one of whom wrecked an entire company with his 10x-ness.
... 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.
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.
- 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.
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.
I've always had a somewhat weird work process. I probably spend a large amount of time just plain fucking around. But it's interspersed with exploring solutions to the problem.
The fuckaround time is important. It lets me re-evaluate the problem with a clearer mind.
Oftentimes this looks like I'm doing nothing for a day or two. Then by day 3 I just write everything that needs to be written in an hour or so.
Now there may be bio/psychological differences here, you (and I) seem to enjoy physical activity. Some might very well not.. I'd say it mostly depend on how the activity fits the person too (speed, effort, balance of type of efforts, sense of improving skills and not just mindless sweating).
I like computing work, but it depends the context, if it's grinding through obscure and unreliable program semantics .. it's less fun. Unless you approach it mathematically (like scientific inquiry trying to discover how it may work), it's gonna be grinding.
If you have simple building blocks and you can just unleash creativity.. then it's different, it's pleasurable. You're the only limit.
Now even in that case, my best days is when I can alternate thinking hard, and sport. 20 min of jogging whenever I'm stuck on a feature branch helped me a lot getting stuck mentally and emotionally.
And in a way, thinkers rarely sit down, they move around, it's vibrant.. it's not just grinding on a keyboard.
I think when you begin to work on something, there's the phase where you are "stuck" and need understand the problem well enough to generate an acceptable initial idea to get started. To me, this is the draining part. However, once I have that understanding and can start exploring it, I can easily work for hours; it still requires mental energy and is still draining if I go overboard and don't stop in time, but it's not the soul-crushing kind that being stuck on a problem can be.
I'll add that it's different when I'm coding and have full autonomy - I could practically go all day on personal projects.
When I have to yield to hierarchy, maintain "agile" processes, and put up with other bs, it drains the work drive and gets tiring real quick. It's not just toll from hard mental labor but also from bad environments - which can exist in any industry.
It does teach you about effort and pragmatic productivity, which is a general skill.
I've spent years trying to design code that would give me some benefits but in reality they were taking too much time for low use-case value. When you have time pressure, you write code very differently. You aim at the smallest patch that can solidly implement a feature. It minimizes code changes, patch size, bug introduction, time spent, client happiness. Also mentally beneficial to see tiny regular results.
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.
My point is more about the possibility that a big chunk of future cash flow is entirely independent of engineering work, at least for some reasonable bounds for what constitutes "engineering work" (e.g. you could argue that an engineer ought to judge whether their time is better spent cold calling potential clients or finding office space to rent, but those I would call "out of bounds"). Any easy example to illustrate this would be two engineers who each develop a functionally identical app for two different startups, but at one startup the founder later embezzles company funds, gets arrested, and the whole company falls apart, while the other company goes on to be successful. Was one engineer really more productive than the other in any meaningful sense?
That is a good point. I guess for the purpose of this definition we need to make some more assumptions. But decoupling software development from the business completely is going too far the other way.
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.
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).
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".
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.)