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

221–230 of 274 posts

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

#221

Post by atoav »

whstl wrote: post #181
atoav wrote: post #173

Earlier quoted context omitted.

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…

But what is "good code", even? For some people that's thousands of two-line methods in hundreds of classes where each part is easy to understand. For others it is more direct code that is optimized for debugging, but not as aesthetically pleasant. Very often those two groups people dislike each other's code a lot. And there's even more other "groups" than those obvious two.

Does that question really matter for this discussion? Every developer will have their own flavour of what constitutes good or bad code, but independent of their flavour isn't a software engineer who doesn't believe in the possibility of achieving good code a somewhat sad thing? Imagine being a cook that doesn't believe in the possibility of cooking good food — sure what constitutes good food is a matter of discussion, but if you have a cook that doesn't believe in it that alone is remarkable in itself.

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

#222

Post by pseudocomposer »

quietbritishjim wrote: post #180
Gigachad wrote: post #126

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…

> 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)…

This can be condensed into the simple, age-old rule: don’t worry about DRY or reusability until you’ve copy-pasted the code into a third place.

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

#223

Post by atoav »

matjazmuhic wrote: post #186
quietbritishjim wrote: post #183

Earlier quoted context omitted.

> 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 … Some of these are not like the others. Not allowing a carpenter to use the most suitable tools is petty. Not allowing them 30 days may make sense depending on the business context. What if it's…

Completely agree. It’s all about trade-offs. Which many developers don’t - or just refuse to - understand. My point was that without some context this kind of conversations - about good and bad code and good and bad coders - are not very useful.

Yeah sure, but in the context of my argument (it is sad that there are aoftware developers who don't believe the product of their craft can ever be good) it doesn't actually matter. Sure, maybe that just means coders have impossible standards that cannot be reached, ever. Or it could mean that typical projects tend to be manages in a way that leads to code that those who wrote it don't consider good (to such a degree where they don't believe good code is actually possible).

Personally I believe good code is an reliable, maintainable, transparent and well designed solution for a problem (or a set of problems). And that means for a small problem aome ad hoc script can be good, while for a big complicated set of problems an elaborate well coded project with a build system can be good code.

But what I believe is that there are ideal solutions from an engineering standpoint, and there are ideal solutions from an business standpoint. And those sometimes don't align with each other. E.g. when you solve a core problem that should really be dealt with properly with a quick fix that might be a cheap way to reach the short term business goals, but it could shape a lot of engineering decisions in the future in a bad way and maybe even become a business problem in the long term.

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

#224

Post by codingdave »

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…

Agreed. At the same time, my customers are downright joyous when the code works and solves their problems. I've had numerous occasions where people were thrilled to meet me and gave me more hugs and praise than I was comfortable with once they heard that I created certain tools they use.

So while I do try to write good code, if you are looking for appreciation, it comes from what the code does, not how it is written.

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

#225

Post by thumbuddy »

kaba0 wrote: post #190
whstl wrote: post #176

Earlier quoted context omitted.

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 app…

Then why not assembly is the ideal program language? Ad absurdum, that’s the simplest, isn’t it? Each line does something completely trivial. Abstraction is the only tool we have to even hope to manage complexity. Unfortunately there is no way to force good abstractions, finding out the perfect abstraction is the deal of the art. Maybe I’m wrong on this, but I’m on the elitist view that the industry really shouldn’t…

Assembly is a lot harder to write correctly/safely than go lang is. Comparing the two seems disingenuous.

I do agree with you to some extent about not replacing senior engineers. But a "bad" senior engineer who is "too smart" for their own good can do more damage then juniors following a template.

All things in balance for sure.

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

#226

Post by gavinhoward »

psunavy03 wrote: post #157
gavinhoward wrote: post #143

Earlier quoted context omitted.

> I’ve come to understand that most people won’t ever really appreciate it for the effort you put in. I've had several people comment on the quality of my code. For a FOSS project. Of a command-line tool that nobody cares about. People notice. But yeah, this article is too much fluff because people don't see it that way. Half of the people who commented on my code mentioned the snarky comments I wrote.

A study apparently found that open-source code with profanity in the comments was statistically measured to be of higher quality. https://blog.desdelinux.net/en/el-open-source-con-malas-pala... .

I don't swear, so this is my replacement.

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

#227

Post by kaba0 »

jiggawatts wrote: post #168
AlotOfReading wrote: post #131

Earlier quoted context omitted.

While I don't think this code is the best, these complaints are like disliking Shakespeare because his writing is archaic. Yeah, no shit. Good writing is relative to the norms and expectations of the audience, which are other kernel developers in this case. It’s written in an unsafe language. So is every other mainstream kernel. Double underscores everywhere, which are the bad alternative to namespaces seen in weak l…

> disliking Shakespeare because his writing is archaic But... his writing is archaic. Not just quaintly archaic, like a novel from the 1800s, but literally requiring translation archaic. Worse still, the vast, vast majority of people "teaching" Shakespeare pronounce it wrong, which means most of the humour is lost: https://www.youtube.com/watch?v=YiblRSqhL04 The jokes don't work any more! The rhymes sound wrong! The…

Nitpicking, but Shakespeare is written in Modern English, as in the language is the same we use now.

> It's taught because our teachers were taught it. Those teachers... and on

That’s bullshit. Greeks are also taught, there are just eternal literary works.

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

#228

Post by mattgreenrocks »

agumonkey wrote: post #182
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…

other colleagues not caring is one thing, your company not recognizing the value and giving you the adequate compensation is another.. I don't mind if colleagues don't appreciate as long as I don't have to either lower my skills or be underpaid

I interned somewhere where I wrote a 56k modem codec decoder. That particular codec relies on decompression by streaming bits out, which is something awful. Was able to deliver it by summer’s end.

After I graduated college in 2004, they hired me at 50k.

I didn’t know my value.

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

#229

Post by kaba0 »

BugsJustFindMe wrote: post #31
Arisaka1 wrote: post #16

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…

Especially in CRUD settings when if people would just bother to learn at least a bit about the framework, they could outsource most of the code to that. It’s not like that filtering you have to implement is some brand new discovery that has never been done before.. these apps are literally fancy excel tables very often.

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

#230

Post by kaba0 »

The_Colonel wrote: post #219
misja111 wrote: post #199

Here are my 2 cents, after 25 years of development in several companies. If you want to do the next developer a favor, your codebase should be simple to understand. Period, that's it. Simple to understand means: 1. Don't use fancy design patterns, FP constructs, performance optimizations etc. Unless the use case specifically requires it. 2. Code should do whatever it needs to do to fulfill its business requirements.…

Where "fancy" is relative. There was a time when Java 8 streams were fancy for many devs, today it's the default way to manipulate collections. I think the code should be "optimized" for the expected audience (of other devs). If you're a single rock star in a mediocre dev shop, you need to code differently than when you're part of a team of MIT PhDs.

That’s actually a very good point!
Post reply on HN