Live data from Hacker News

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

addyosmani.com

231–240 of 274 posts

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

#231

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

I agree wholeheartedly. Code which is "designed to be extensible towards future use cases" very often expects the wrong kinds of extensions and actually makes it more difficult to extend it because it's necessarily more complicated. > 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. Very much this.

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.

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

#232

Earlier quoted context omitted.

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?

Or the classic result of updating the code but not updating the comment: //Returns the user's full name return user.email;

Okay but when you see that why not just take 30 seconds and update the comment?

Edit: if even 30 seconds

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

#233
post #172

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 a carpenter that says straight cuts aren't possible, just because they never maintained their tools and the last 10 cuts came out wrong." Anyone who's worked on a construction site would agree that this is not too far from reality. I agree, it's quite sad, but that sentiment usually comes with burnout from too many quick deadlines and vast piles of tech debt.

> but that sentiment usually comes with burnout from too many quick deadlines and vast piles of tech debt.

That would be my question. We are not talking about people saying that within their context good code is not possible, we are talking about people who say good code is not possible, period. Maybe burnout has to do with it, maybe also depression. But I even if I was stuck in a job that made me churn put half broken code all day I'd still remember my hobby projects in which I experienced myself that perfectly fine code can be written by a single determined person — and quite frankly: it doesn't even have ro take that much longer, it just has to be a trusted, concentrated low pressure environment.

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

#234
post #193

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

I am not denying that at all. I know my share of carpenters and if they are in a pickle, they might take on a job like that, and swear about it like there is no tomorrow all the way to the bank. What I found remarkable wasn't that there are badly managed projects, but that there are software devs who seem to think there is no other way than doing it like that.

Yep, I have met a few developers like this. A lot of them would not even question the situation or explain it is not a food idea doing things a certain way. They would just take the path of least resistance.

I think the abundance of jobs - maybe not anymore? - also added to the problem.

I’ve received countless CVs where the developer didn’t stay at the same job for more than a year, max two. Now, it could be that some of the jobs sucked, bit it is highly unlikely that all of them sucked.

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

#235
post #223

Earlier quoted context omitted.

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

Well put, about the engineering solutions and business solutions. There is definitely big faps between business people and developers. They usually both think they are right. :)

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

#236

Earlier quoted context omitted.

One can figure out 'how' and 'what' from the code, given enough time. The most valuable thing in code is the brain of the Past Person who wrote it, looming over your shoulder, telling you 'why' in very explicit terms. That 'why' also helps to show that Past You knew wtf you were doing, and lets Present You feel confident in making changes, because you know what the intent was. "I'll remember this!" is one of the grea…

Yeah when I find myself wanting to write a comment that describes the implementation, I usually end up writing a test where possible. I'm trying to think, but I can't come up with any kind of comment that has been useful that didn't have a "because" word, explicitly or implied. Like, even if there's a comment like: "This function only queries X and Y fields. Don't add more. If you need more than that, use this_other_…

> I would probably appreciate those comments if I ever need to read branchless code, SIMD code, or similar performance-sensitve witchcraft.

I've done this before in production code. One of my only exceptions to my policy against leaving in commented-out code has been things liking leaving the unoptimized serial code commented out at the top of a section of some hand-vectorized code full of SIMD intrinsic. It clearly showed the intended "what", but was also useful to keep around as a baseline for performance testing and reference code to compare against for debugging.

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

#237
post #221
post #181

Earlier quoted context omitted.

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…

It does matter because what constitutes good code for some people is often terrible code for others, to the point of people making jokes about it [1].

With food, at least there is a wider agreement of what consists of good and bad.

[1] https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

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

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

I find Go bizarre... 90% of the code written in it seems to consist of checking for errors and passing them around. And yet, every time I've had to interoperate with somebody's Go code, it falls apart immediately because of significant processing errors that it seems like somebody should've caught, like a null-pointer dereference, or a wrong lookup into a map, or a (de)serialization error. _Every time_ the programmer…

I personally prefer rust over go as well. That said, some rust code is genuinely scary in a way where you do have to wonder if anyone else could maintain it without rewriting it themselves. There's a lot of complexity that although is visible in the syntax is too much for anyone to keep a mental model of - at a certain level of complexity.

Kindly written rust is fine, same goes for a lot of languages. The issue is, sometimes really smart people have no interest in kindness. There are a lot of social factors that go into people writing monstrosities "gotta look smarter!" "Gotta have job security!" "Don't want anyone to call me out on this".

I write dumb code 99 percent of the time. I'll never get promoted for it, but people know exactly what it's doing.

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

#239

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?

I'd rather someone over does it then under does it.

The issue is that most things are obvious when you write the code, but that it's often not clear what's not obvious in the future.

So if you just get in the habit of explain every function it will lead to a more understandable codebase.

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

#240

Earlier quoted context omitted.

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?

Or the classic result of updating the code but not updating the comment: //Returns the user's full name return user.email;

yeah that's an issue, but the much easier to update a comment then an extensive suite of unit tests. And in my experience the payoff of good comments is about the same, minus the cost.
Post reply on HN