Some reasons to work on productivity and velocity

You should not expect a better payment from your company because you are a better programmer. Payment is according to demand and offer. Your company will mostly demand what you say: OK engineering, management skills, good communication skills, getting well along with your colleagues.

But from being a better programmer you can still derive better monetary gains. Instead of striving to become a lead or manager or product owner, you can either become an entrepreneur or search for a company where being a better programmer is a highly desired skill.

This is great example of virtue-signalling and rationalizations.

No, typing speed is irrelevant related to content quality. Think of poetry - it is all about finding the right word rather than committing them into writing.

He just plainly typing too much - a thick book fallacy. Truth does not require lots of verbiage, on the contrary, it requires a short, clean, precise, adequate "just right" formulation.

That piece of text in in the link could be reduced 10x without losing anything meaningful (which is very sparse indeed).

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.

This is doing wonders for my procrastination!

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)

At least one way to increase velocity is to design software such that you can radically accelerate the aging process to get the software to 10+ years maturity but within a matter of weeks.

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.