Ask HN: What bits of fundamental knowledge are productivity multipliers?

W. Edwards Deming said over and over again that the system in which an employee works puts a ceiling on how much output they can produce.

But you should take it a step further than just trying to maximize your output, and instead understand how your work creates value for your boss, your company, for society. Productivity is not a measure of how much you can output, it's a measure of how much value you can create, or how much closer you can come to achieving your goals.

If you can come in, spend five minutes and change the label on one button and increase sales 200%, you've been much more effective than if you spend years optimizing the performance of a component that isn't impacting overall performance of the system.

(2) End of list.

But seriously, "10x" aside, there are some techniques that have come up surprisingly often and been surprisingly effective during my career. A lot of them are around caching, cache coherency, memoization, etc. and I see many of those have already been mentioned. How to write a simple parser is another one, likewise.

The one I haven't seen mentioned (and don't expect to) is "poisoning" of data or requests. Sometimes it's not very convenient to delete a piece of data or turn a request around with an error at the very moment when the need for that is detected - often because of locking or reentrancy issues. Just marking something as invalid, until some time when removal is more convenient, can be a very powerful technique. It can also make monitoring such events easier.

I've brought this idea into a codebase at least a dozen times, and more often than not it has gotten a "wow, that makes things so much easier" reaction. I can't take credit, of course. Like many things around caching or state machines, I got it from the hardware folks where it's a standard technique. In general, software folks can learn a lot from looking at how hardware folks have solved similar problems in an even more challenging environment, and "bring back" those solutions to their own domain.

* Fully understanding how SQL prepares queries; optimization strategies

* Embracing garbage collection in JITted runtimes, mainly JS for now

* Being able to diagnose and replace a squeaky belt in your car

* Know what a cat is saying when it meows at you and indicates something in the vicinity of its food / water / the door / a dead mouse.

These have all saved me a ton of time.

* The ability to challenge a proposal and figure out you don't need "an xxx with yyy but just a zzz should be enough"

F.e. merging seperate repos to monorepo, simplifying development & CI/CD enormously for a tiny team.

* The ability to understand which solution matches best with your whole context (environment, capabilities, skillset, risk, ...)

Don't go for integrating a rules engine in an MVP with a tight deadline, but just setup a monthly alignment between Product owner & back-end dev.