Live data from Hacker News

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

addyosmani.com

261–270 of 274 posts

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

#261
post #220

Earlier quoted context omitted.

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

There's room for conflicting viewpoints of course, but Shakespeare is enjoyed in the original by English speakers in the 21st century, and academic consensus calls his language "Modern English" - as opposed to Middle English, which is a struggle to understand, or Old English, which very few people can grok today. So no, it requires no translation. I disagree completely that the humour is lost. There may be jokes I do…

I studied Shakespeare in school from a textbook that had two columns: the original and the modern English translation. Something like this: https://www.makeuseof.com/tag/read-shakespeare-side-by-side-...

> So no, it requires no translation.

It does for most students in most schools.

Sure, there's some grey-haired academics that insist it doesn't need translation -- but they've spent a career learning Shakespearean English!

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

#262
post #173

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…

Imagine that the carpenter already gets the wood cut from a far far away land, and has to make due to the way they were prepared.

After nailing a couple of them together, it has to send them to another far far away land, for some glue job.

Afterwards he gets them back, he applies varnish over the wood pieces, and sends them yet again to another far far away land for the paint job.

Those people on the far far away lands don't have any carpentery training and do whatever they feel like to meet the description of what they are supposed to deliver back.

While the carpenter tries to rescue what is possible from each delivery, so that the table and chairs only look half as bad, people can still seat on them without falling, and the tables have four legs about the same size.

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

#263
post #262
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…

Imagine that the carpenter already gets the wood cut from a far far away land, and has to make due to the way they were prepared. After nailing a couple of them together, it has to send them to another far far away land, for some glue job. Afterwards he gets them back, he applies varnish over the wood pieces, and sends them yet again to another far far away land for the paint job. Those people on the far far away lan…

This is a very concise description of a lot of modern manufacturing.

I just took apart a bunch of stuff on a VW van: the bus itself was nominally manufactured in Poland. According to some of the labels the guts of the servo that I took apart and repaired was made in Switzerland. But the servo itself was made in Germany. When you look at the guts parts of it were made in China, parts in Japan and probably some parts in Switzerland but it's unclear which those would be.

The parts of that car have collectively already traveled more than the car ever will by the time it gets delivered to the customer (in the Netherlands).

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

#264

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 don’t think I’d do much differently in retrospect, except be far more cautious about where and who I spend time around.

Another angle here is that code has become seen as something with the shelf life of a banana. People today talk of code merely a year old as legacy that needs to be rewritten ASAP. If one grew up in a world where code is scheduled to be thrown away as soon as it gets to production, I guess I can see how quality of code and documentation doesn't matter at all.

That's not a happy world though.

I grew up with the codebases of Unix (particularly SunOS, later Solaris). Code lives on for decades. One matures it to perfection and then it's perfect for a long, long time. That's a much more pleasant way to honor the craft.

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

#265

Earlier quoted context omitted.

I never had code where I was like, oh this has too many comments. I never get this sentiment from developers. I've had reviews were developers wanted me to slim down & rewrite comments. It's often hard in the moment to understand what's obvious or not. Just always writing a comment even if it's obvious can save a lot of pain in the future.

You have never seen a comment that helpfully explains that getUsername() returns a string with the username of the user that the method is invoked on?

> You have never seen a comment that helpfully explains that getUsername() returns a string with the username of the user that the method is invoked on?

Yes, but that's not all that annoying when the opposite is you stumbling upon a service pattern with uncommented methods along the lines of CVKUser getCVKUser(int cvkId, ...) or VFUser getVFUser(int cktId, ...), without having any idea what the person writing the code 4 years ago was thinking.

You've no idea what CVK or VF is supposed to be and have to spend an hour looking at both of those classes, as well as everything that surrounds them in the codebase, as well as what cvkId and cktId are supposed to be and why cktId supposedly matches VFUser, to do enough code archaeology, so you're able to figure things out confidently.

That said, there is little use in code comments that explain WHAT the code does for trivial bits of code, instead of comments that explain WHY it works like that (like a more sane version of having to dig through Jira tickets, or years of commit history, or old pull requests, or whatever) or what other considerations there are to take into account (since separate docs won't be read as much and Jira tickets won't always have the technical information).

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

#266
post #262

Earlier quoted context omitted.

Imagine that the carpenter already gets the wood cut from a far far away land, and has to make due to the way they were prepared. After nailing a couple of them together, it has to send them to another far far away land, for some glue job. Afterwards he gets them back, he applies varnish over the wood pieces, and sends them yet again to another far far away land for the paint job. Those people on the far far away lan…

This is a very concise description of a lot of modern manufacturing. I just took apart a bunch of stuff on a VW van: the bus itself was nominally manufactured in Poland. According to some of the labels the guts of the servo that I took apart and repaired was made in Switzerland. But the servo itself was made in Germany. When you look at the guts parts of it were made in China, parts in Japan and probably some parts i…

Indeed, it is everywhere.

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

#268

Earlier quoted context omitted.

I’ve hunted down contact info and emailed a dev who’d left the company to thank them for the clean code they left behind. I encountered their code while debugging weird behavior in a legacy feature. The code structure was immediately intuitive and comprehensible. Just the right amount of detailed but not superfluous commenting. Beautiful. It made my day so I let them know!

I never had code where I was like, oh this has too many comments. I never get this sentiment from developers. I've had reviews were developers wanted me to slim down & rewrite comments. It's often hard in the moment to understand what's obvious or not. Just always writing a comment even if it's obvious can save a lot of pain in the future.

> I never had code where I was like, oh this has too many comments.

It happens. Even worse is when the code has been updated but the comments have not. I've picked up the habit of double checking comments with git blame.

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

#269
post #138
post #50

Meh. I've seen teams and projects bogged down by "good clean code" rules and nit picking code reviewers. These folks, typically "staff" engineers, over-police the repos and care more about clean code than delivery and execution. I'm waiting for the day where AI/co-pilots can enforce team and industry best-practices, style, maintainability, testability, etc before the code is even committed. Call it "uber-linting" and…

Can't you already do that with pre-commit hooks? We use those at work to check a lot of stuff like that before a commit ever goes through.

Of course! I'm talking about the kinds of checks and scans that are made on the code during the pre-commit hook

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

#270
post #231

Earlier quoted context omitted.

The exception here I think is the choice of data structure. If you know that code will be extended to accept additional fields it makes sense to be sure to use an extensible data structure or to ensure that side effects are contained correctly (a good idea anyway) and in a way that allows extensibility when they must be changed.

> If you know that code will be extended to accept additional fields Well, you rarely know , more often "guess". There's an important distinction between public and private interfaces. With public interfaces, I contend that it does make sense to think about future use cases and put in some flexibility even at the cost of a small overhead.

That seems reasonable.
Post reply on HN