I'm sympathetic to the analogy of practice. Too many people are extremely static in their assessment of their skills. They make overarching claims like "oh I'm just not good at cooking" or "I just can't type very fast", when they can remedy these issues with practice. Of course they aren't obligated to do so, but it's a useful mindset to see weaknesses as potential places of improvement instead of permanent failings. It's also true that if you're racing against someone who doesn't see it as a race, you'll win. Granted they probably won't care, but sometimes people get to the end, realize they did care about the race, and were just never clued into the fact that it was a race.

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

I am typically energy constrained rather than time constrained, as I imagine is the case for many working in engineering/science. Yet, the author's advice remains useful. Deliberate practice should provide gains to both time and energy costs of tasks.

For me most productivity advice, including this post, ultimately reduces to "try to get better at your trade, and track your progress".

If you really are not comfortable with the consequences of your personal labor you should probably leave your job or not take it in the first place. This sounds like a decadent rationalization for highly compensated people that want to feel moral while being lazy.

  > In part of a previous post, I described how long a tiny part of that process took and multiple people objected to that being impossibly fast in internet comments.

BUT there was something missing in the back-story and it's apparent in this latest post from danluu. This...

  > I find this a bit funny since I'm not a naturally quick programmer. Learning to program was a real struggle for me and I was pretty slow at it for a long time (and I still am in aspects that I haven't practiced). My "one weird trick" is that I've explicitly worked on speeding up things that I do frequently and most people have not.

Crucially IMHO, getting to danluu-speed ALSO means enjoying the grace of being able to ask questions and discuss stuff with skilled folks that is completely outside of what's on some project manager's gnatt chart. That's not usually possible in a nose-to-the-grindstone workplace unless you find the right teammates and a protective, encouraging, and tolerant manager.

I find I'm always trying to learn the new code base or tech it's built on. I hate the hours wasted trying to find out how to do something I already know how to do in another stack.

Then there is the time wasted trying to learn git after mercurial and then Docker.

As for typing after loads of intentional practice I seem to have plateaued at 60-70wpm. No idea how to get beyond that.

One of the linked HN https://news.ycombinator.com/item?id=22253893 post has an interesting advice. Record yourself when you're coding. Watch them and identify possible improvements. Reminds me of James Woods' lawyer character in the TV show Shark. He did the same thing.

This sounds exactly like an instance of Jevon's paradox: https://en.wikipedia.org/wiki/Jevons_paradox.

But I agree that if you find out that you have been working on the only problem worth solving for 10 years you should be able to take a break because the likelyhood that anyone else is able to run past you is very small. (they would have needed to start before you without you finding out for 10 years because hard problems are not solved faster in a group)

What about data science / research?

Curious if anyone has suggestions.

Seems to help me work fairly quickly, and fairly well.

I write good code, quickly.

I’m not at all interested in comparing myself to, or competing with, anyone else.

I can get the job done to my satisfaction, and in a timeframe the I consider acceptable.

The only example I see in the post is a typing test.

One comment mentioned a time-tracking app called Harvest.

Churning out code is something that bores me. I'm interested more in problem solving, computer science part of programming, optimizations, research, discovery, architecture.

I am not interested so much in how I do this common thing fast, but rather in how I solve this hard or interesting problem. If a problem is already solved, can I find a better solution? How fast the code will run? How robust it will be?

For example, say you're implementing a distributed consensus protocol like Viewstamped Replication, Paxos, ZAB or RAFT. This could be several thousand lines of code, just to get something up and running, excluding testing. Then months of writing unit tests and integration tests by hand and thereafter you would still expect several years of widespread industry use and sometimes weeks of debugging per reported issue just to shake out all the non-obvious edge cases.

How would you increase your velocity here?

The key insight is that the implementation phase represents only several months of work, whereas the actual maturation process or debugging phase represents perhaps years of work. And, until recently, both phases were typically treated the same way—people manually writing code, and then people manually writing tests, manually running the code on real systems in real time, manually filing issues, manually classifying these issues and manually debugging issues.

So, if you can accelerate the second debugging phase, automating all the manual steps, then—even if your team don't enjoy much velocity in the implementation phase—you could end up several years ahead in velocity where it really counts.

If we go back to our consensus example, then you could solve the velocity problem in the testing/debugging phase by spending a little extra time upfront in the design and implementation phase to make sure that all non-deterministic resources in your consensus software (such as message passing or networking, time, timeouts and storage I/O operations) are pluggable and can be swapped out with deterministic shims.

Then, when it comes to testing, you could write self-generating unit and integration tests, like Worms, Scorched Earth or SimCity.

Your test would spin up a randomly generated but fully deterministic simulated cluster in a single local process on your local developer machine, and then simulate random client requests and random network/storage fault injection, with random network/storage latency/reliability properties, while hooking into where the critical things like state transitions take place and checking linearizability immediately as these state transitions happen, also checking all other invariants along the way required for your software to be correct, so that your test simulator could even tell you if an issue is a liveness bug or a correctness bug, without you having to spend time to figure that out.

Then, because you're also shimming your time source, you can just speed up time, so that you can simulate hours of real-world runtime (that would otherwise have literally taken hours if you were using something non-deterministic like Jepsen) in just a few seconds.

And now, if a test finds an invariant violation, you can just replay the randomly generated test, again and again, but with debugging logs turned on, to also accelarate the time it takes to reproduce and fix the issue and then verify the fix.

For me at least coding seems to take less time objectively than subjectively, but it's also quite obvious that most of my time is not spent on coding, sadly. A good chunk of it is completely unproductive bullshit that simply has to happen because that's how the company chooses to operate. I tell them it's not the only way to do things, but they insist on wasting ~1.5 person days a week on "standups" and "scrum" (the team is 12 people, excluding me). They could _easily_ move 50% faster if they shed that bullshit and just gave people sizable tasks and some degree of autonomy and personal responsibility. Instead it's down to who can _appear_ the busiest during standup.

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.

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.

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.

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.

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.

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

> The top reasons I see people say that productivity doesn't matter (or is actually bad) fall into one of three buckets: 1. Working on the right thing is more important than working quickly 2. Speed at X doesn't matter because you don't spend much time doing X 3. Thinking about productivity is bad and you should "live life"

Here's his argument for your last point:

> The last major argument I see against working on velocity assigns negative moral weight to the idea of thinking about productivity and working on velocity at all. This kind of comment often assigns positive moral weight to various kinds of leisure, such as spending time with friends and family. I find this argument to be backwards. If someone thinks it's important to spend time with friends and family, an easy way to do that is to be more productive at work and spend less time working.

Personally, I deliberately avoid working long hours and I suspect I don't work more than the median person at my company, which is a company where I think work-life balance is pretty good overall. A lot of my productivity gains have gone to leisure and not work. Furthermore, deliberately working on velocity has allowed me to get promoted relatively quickly4, which means that I make more money than I would've made if I didn't get promoted, which gives me more freedom to spend time on things that I value.