Live data from Hacker News

Good code is like a love letter to the next developer who will maintain it

addyosmani.com

271–274 of 274 posts

Re: Good code is like a love letter to the next developer who will maintain it

#271

Earlier quoted context omitted.

Yep. Yesterday I ran into a job opening asking for "Java developer who delivers 3x faster than the other developers" in one of the bullet points. It's such a weird point to emphasize that you want speed with no concern to trade-offs, and the maintainability and scalability of the codebase will be the first victims sooner or later.

My personal experience is that the majority of developers I ever encounter at work (as opposed to within my social network) are usually slow because they're bad engineers who don't understand problems quickly, don't have the knowledge or experience to see solutions quickly, and in general don't think deeply quickly. It's not hard to 3x performance without sacrifices when the baseline is mediocre at best. "Fast must b…

I used to work with this kind of developer. He was bounds and leaps faster than all the other developers in the team.

The code he produced was absolutely and completely unmaintainable. The joke was that this guy could program C in any language. His code kindof-sort-of worked, but only he understood it and when anyone else had to take over his stuff, the first thing they had to do was rewriting the part from scratch. Of course there were no tests, so when the new person broke something in their attempt to try to work with their code they were scolded. The person in question was the CTO of the company, by the way.

He was 3x alright, but at the expense of everyone else on the team. I was very glad to see him go.

Re: Good code is like a love letter to the next developer who will maintain it

#272

As someone who has gone back and read my old code as well as a lot of others old code, there is no such thing as good code. IMHO, the problem is one of cultural context which is often not shared between generations of coders. Languages and best practices can change so violently that best-practices one decade are often anti-patterns in the next. As a codebase outlives its best-practices, do you stick with them and ext…

> there is no such thing as good code But do you think there is bad code? If so, I'll give you the official definition of good code: code that isn't bad code.

There's another, perhaps a bit nihilistic possibility: all code is bad, and the only good code is no code at all.

Re: Good code is like a love letter to the next developer who will maintain it

#273

Earlier quoted context omitted.

Usually the situation is someone has meticulously crafted some perfect system which can be extended and reused in many coherent ways. And then that person leaves the company and no one else truly understands how it works or was meant to be used so it gets a series of hacks and patches applied to it which violate the original design which is known by no one at the company. For most projects this is not that big of a d…

For anyone interested in a discussion about the concept of systems not being understood by newcomers, I can recommend Peter Naur's Programming as Theory Building: https://pages.cs.wisc.edu/~remzi/Naur.pdf

Right to the spot, thanks for sharing this! I've always thought that having a decision log of justifying design/implementation choices which are somehow surprising would be healthy thing to do.

Re: Good code is like a love letter to the next developer who will maintain it

#274
post #259

Earlier quoted context omitted.

> The craft is not the code, but the product. These two are not disjoint, but instead quite related. > Your job is to deliver good product, not good code. If your job is software engineering, then "good code" is what facilitates "good product." It boils down to maximizing the "abilities": - Understandability - Applicability - Testability - Maintainability - Flexibility - Durability

Yup, good code helps to deliver a good product, but you should not focus on the code, rather focus on how the code influences the product. Better to have hacky code that delivers value than to deliver nothing.

This is a false dichotomy IMHO.

"Hacky code" is most often a result of those responsible for delivery having gaps in their understanding of the product need.

When engineers have a deep understanding of what is needed, there is rarely a need for hacks. Of course, the obvious exception to this is when libraries and/or external services mandate them.

Post reply on HN