Hacker News new | ask | show | jobs
by darkwater 1620 days ago
Why does the "does it actually work" go down over time? I would expect to be the other way round: more experience, more chances your software "actually works", even if it's not following strict rules anymore.
4 comments

There are multiple metrics to describe what “works” even means. You are right that battle tested code can be more stable and fulfill its goals more than new untested code or code written without a customer. At the same time it’s also true that any sizeable codebase, especially production code, will accumulate bugs over time, will almost always slow down over time, and will eventually once large enough become crufty and smelly and unfactorable and difficult and, maybe most importantly, expensive to maintain. Big systems are hard.
> more experience, more chances your software "actually works"

Exactly, so you don't have to think so much about if it will work, you can take that for granted and think more about subtler things.

I'm about 80% sure that this graph eventually ends up back at the initial state.
The axis is labelled "relative importance". If you place non-zero value on readability, you must place less than 100% importance on "does it work".
Why? There is absolute no correlation between readability and working status. It might be obfuscated code that works perfectly, or it might be obfuscated code that explodes every 2 days. And it might be perfectly clear code badly implementing a business need or implementing it perfectly.
i interpret it this way:

when I was younger it was really important to me that the code work the entire time I was writing it

as I got older it got less important and now I make the code "look right" (that is, read well) and then I get it working