Live data from Hacker News

Good code is rarely read

alexmolas.com

1–10 of 115 posts

Re: Good code is rarely read

#3
I don’t think this is a good rule of thumb.

Code that does what it should is rarely read. Until you need to change it. And it may not be changing due to it being incorrect. If an attendant system gets replaced, you may have to change all the other systems it has touched. Business requirements may have changed. Stakeholders may have changed.

There are plenty of reasons for code to change beyond there being a bug.

Re: Good code is rarely read

#5
post #2

I don't think the author has worked on long-lived projects. Eventually, all code is revisited because there's always shit to get done.

Not just long-lived projects. Working on bespoke, internal systems means you’re never truly done. And what you’ve done a month ago may not be what’s wanted now.

Re: Good code is rarely read

#6
post #2

I don't think the author has worked on long-lived projects. Eventually, all code is revisited because there's always shit to get done.

Exactly my thoughts.

The reason why good code is code that is easy to read, is because products evolve, and so does the code.

Suddenly the taxonomy of that enum starts to shift, and the name that was perfect yesterday does not make sense tomorrow.

These changes happen gradually and a basic acceptance of the code base not being on par with the product understanding is necessary in order to have any kind of velocity on not only spend time refactoring.

Re: Good code is rarely read

#7
Recently I was going through the codebase that our company has spent the last 7 years developing, trying to find examples of code we reuse a lot. This turned out to be very unintuitive: the functions we actually reused the most had practically fallen below the threshold of conscious thought. They almost "just work", so I hadn't realized how much I'd been using them.

Re: Good code is rarely read

#10
That is a bold statement. I'm 100 convinced that it's based on your code architecture.

Good code in my systems are ones that don't need to be touched or read very often, and the fluid/unknowns parts are decoupled elsewhere. Sometimes business requirements issue, Sometimes difficult technical problem.

Post reply on HN