Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

addyosmani.com

Post reply on HN
Print view View original

171–180 of 274 posts

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

#171

Post by yMEyUyNE1 »

mattgreenrocks wrote: post #122

After almost 20 years of writing the best code I can muster as much as I can, I’ve come to understand that most people won’t ever really appreciate it for the effort you put in. Many won’t even notice; they’re too preoccupied with their own lives to open their eyes to what is there. Nor do they give a damn about mastery. But, that doesn’t mean it’s a waste. I don’t think I’d do much differently in retrospect, except…

It takes a master to recognize a master's work. Know that you have made their work easy even if they don't realize it.

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

#172

Post by atoav »

mattgreenrocks wrote: post #122

After almost 20 years of writing the best code I can muster as much as I can, I’ve come to understand that most people won’t ever really appreciate it for the effort you put in. Many won’t even notice; they’re too preoccupied with their own lives to open their eyes to what is there. Nor do they give a damn about mastery. But, that doesn’t mean it’s a waste. I don’t think I’d do much differently in retrospect, except…

I too have met many developers who have developed the mindset that good code is impossible. That is really sad.

Imagine a carpenter that says straight cuts aren't possible, just because they never maintained their tools and the last 10 cuts came out wrong.

Of course good code is possible. But not every person is going to write it and it is not going to happen under all possible circumstances and in all given project structures.

Our job as professional software people is to be able to judge how to create the circumstances and the time frames under which good code can be written — and to say No to projects that cannot be written by us and our team.

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

#173

Post by atoav »

mattgreenrocks wrote: post #122

After almost 20 years of writing the best code I can muster as much as I can, I’ve come to understand that most people won’t ever really appreciate it for the effort you put in. Many won’t even notice; they’re too preoccupied with their own lives to open their eyes to what is there. Nor do they give a damn about mastery. But, that doesn’t mean it’s a waste. I don’t think I’d do much differently in retrospect, except…

I too have met many developers who have developed the mindset that good code is impossible. That is really sad.

Imagine a carpenter that says straight cuts aren't possible, just because they never maintained their tools and the last 10 cuts came out wrong.

Of course good code is possible. But not every person is going to write it and it is not going to happen under all possible circumstances and in all given project structures.

Our job as professional software people is to be able to judge how to create the circumstances and the time frames under which good code can be written — and to say No to projects that cannot be written by us and our team. This isn't always a simple thing, but it must be done.

The saddest aspect is that you see many experienced software developers who never experienced things working well. And as someone who sometimes writes code for fun I cannot understand that at all. What I get is that throughout your professional life you can never had the chance to be in a project where you could write good code. However you can write good or even perfect code at home where nobody pressures you. And if it is possible there, why wouldn't it be in a professional context?

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

#174

Post by phreack »

beebmam wrote: post #15

In my opinion, good code is like a Brita filter. It does its job, will one day need to be replaced, and it should be easy to replace. More importantly: metaphors are not a healthy way to understand an idea. Ideas are more nuanced than a metaphor could possibly account for. Abstaining from metaphors might not make for a catchy headline though.

Unrelated, but lately I find that I have a much harder time learning with metaphors than if educators and explainers would just speak directly about things. I had very terrible experiences learning physics because teachers would always resort to weird metaphors, about music, about electricity being like a river, and more.

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

#175

Post by whstl »

Gigachad wrote: post #126
mattgreenrocks wrote: post #122

After almost 20 years of writing the best code I can muster as much as I can, I’ve come to understand that most people won’t ever really appreciate it for the effort you put in. Many won’t even notice; they’re too preoccupied with their own lives to open their eyes to what is there. Nor do they give a damn about mastery. But, that doesn’t mean it’s a waste. I don’t think I’d do much differently in retrospect, except…

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…

That's often the rationalization for most "perfect" and "ultimately reusable" code I see, however what I've seen too many times is code that ended up turning into shit even when the creator remained the sole maintainer.

Blame often gets passed upwards to some product manager or sales coming up with some outlandish business requirement, but honestly the real reason is that the code wasn't that flexible to begin with.

Which is perfectly fine, not all code can be flexible and infinitely reusable. Perhaps we should stop forcing every single file to be.

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

#176

Post by whstl »

AdieuToLogic wrote: post #140
thumbuddy wrote: post #128

Earlier quoted context omitted.

And this is why Go lang exists... The trade off is screw brilliant engineering just make it simple so other people can build on it easily. Not saying it's my favorite, but it has it's merits long term.

A semantically weak language does not reduce the inherent complexity of a system, as problem complexity is constant. What Go does is encode solution complexity implicitly throughout a code base. This is the same effect JavaScript often has.

Go isn't my favourite language, but I disagree with that: a language being being simple does wonders to reduce the possibilities of accidental complexity added by complicated features that are unnecessary for the business.

But of course it's still possible to make a mess: I've seen someone who created an ad-hoc object model (with its own structs, plus multiple inheritance and all) on top of Golang and wrote a few apps in that style. But not having the features in the first place can help.

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

#177

Post by matjazmuhic »

atoav wrote: post #173
mattgreenrocks wrote: post #122

After almost 20 years of writing the best code I can muster as much as I can, I’ve come to understand that most people won’t ever really appreciate it for the effort you put in. Many won’t even notice; they’re too preoccupied with their own lives to open their eyes to what is there. Nor do they give a damn about mastery. But, that doesn’t mean it’s a waste. I don’t think I’d do much differently in retrospect, except…

I too have met many developers who have developed the mindset that good code is impossible. That is really sad. Imagine a carpenter that says straight cuts aren't possible, just because they never maintained their tools and the last 10 cuts came out wrong. Of course good code is possible. But not every person is going to write it and it is not going to happen under all possible circumstances and in all given project…

Now imagine a carpenter who can build the most beautiful, elegant piece of furniture in 30 days, but you force them to make it in 10. Or you forbid them from using a certain tool. Or force them to use a tool you prefer. Or …

Yes, not every programmer cares about good code. But of those that do, also not all of them can agree on what good code is.

And not all good programmers can write good code, for one reason or another.

It is way less black and white than good vs bad/mediocre programmers.

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

#178

Post by [deleted] »

imoverclocked wrote: post #57

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…

[deleted]

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

#179

Post by stodor89 »

jiggawatts wrote: post #90
38 wrote: post #70

Earlier quoted context omitted.

> there is no such thing as good code definitely not true. this is good code: https://github.com/torvalds/linux/blob/master/fs/file.c this is good code: https://github.com/golang/go/blob/master/src/strconv/atoc.go its formatted, commented, direct. the fact that you struggle with writing time tested code does not mean that everyone does.

By linking to those examples you confirmed the point you were trying to refute. From my personal perspective this is mediocre code at best. It’s written in an unsafe language. Littered with macros, which in C are not hygienic and are land mines in waiting. Constants defined with lowercase and not actually marked as const. Double underscores everywhere, which are the bad alternative to namespaces seen in weak language…

I've got a different personal perspective: Any code that helps achieve one's ends is good code.

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

#180

Post by quietbritishjim »

Gigachad wrote: post #126
mattgreenrocks wrote: post #122

After almost 20 years of writing the best code I can muster as much as I can, I’ve come to understand that most people won’t ever really appreciate it for the effort you put in. Many won’t even notice; they’re too preoccupied with their own lives to open their eyes to what is there. Nor do they give a damn about mastery. But, that doesn’t mean it’s a waste. I don’t think I’d do much differently in retrospect, except…

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…

> Usually the situation is someone has meticulously crafted some perfect system which can be extended and reused in many coherent ways.

Very rarely is that good code, even if you actually do understand the design. Most of the time, when you come to extend it, it turns out to be in a slightly different way than the original author had expected. Now you've got the complexity of solving the original problem (inevitably) and the new problem (also inevitable) and also some other problem that might have needed solving but didn't after all (not inevitable).

Most of the time, code that is easiest to modify or reuse is the code that does its current job in the simplest way possible. That doesn't mean you can't create reusable abstractions - doing so often does make the code simpler even for just its current job. And that usually ends up aligning quite nicely with what turns out to be (almost) what is needed for other tasks anyway.

Post reply on HN