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