Ask HN: What change in your programming technique has been most transformative?

When working on most things, I ask two basic questions: how does it fail? how does it scale? I picked that up years and years ago.

Any line, function, workflow, etc can fail. You need to have worked through all the failure cases and know how you are going to handle them.

Somethings don't need to scale, ever. But most things I work on do. If I don't know the story on how I can ramp up an implementation a few orders of magnitude, then I can't say I've designed it well.

Aside from that, measure everything. Metrics, telemetry, structured logging. Design for failure and design for understanding what happened to cause the failure. Data will tell you what you are doing, not what you think you are doing.

There was a post here yesterday about a neat map thing. I hit a bug and the author could only rely on their experience with it being potentially slow at times but saying it should work. If there were proper metrics in place, they would know that N% of calls exceed M seconds and cause a timeout. He could then relate this to the underlying API and its performance as the service experiences it. With proper logging, they see what the cache hit ratio is and determine if new cache entries should be added.

Build, measure, learn.

Oh, and automated tests. So much to be written on that.

Many developers think of themselves as abstraction masters. "Moar abstraction is moar better!" Abstractions have a cost in readability and maintainability. It is very hard to make the abstraction that improves both. I'm tempted to say that pre-abstraction is a larger problem than pre-optimization.

Make your code easy to read at the expense of easy to write. Don't abstract unless you know exactly the use case. If the use case is not immediately forthcoming, YAGNI (you aint gonna need it). Related, don't be clever. Clever is cute and all. It does not belong in production code.

What would be some fundamentals to practice for a software developer?

Using static typing to make changes slightly bigger than intended.

But with a better architecture and nearly zero mistakes. Through using OO correctly ( please read the word correctly)

One step at a time.

Ps. This is mostly when a code-base is detected where a part of the code is sensitive for bugs. Eg. From today: handling better payment providers and payments.

I thought it was important enough to make the change bigger, but with the intention of removing recurring/similar errors in someone else his code-base.

Afterwards, go to him and explain why. Developers can be proud of their code, although it's just shitty code ( eg. Long functions, loops, if else, switch, by reference, ... Is mostly an example of bad code) and never say it's shitty..