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.
Good code is like a love letter to the next developer who will maintain it
231–240 of 274 posts
Re: Good code is like a love letter to the next developer who will maintain it
#232Earlier 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;
Edit: if even 30 seconds
Re: Good code is like a love letter to the next developer who will maintain it
#233Earlier 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.
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
#234Earlier 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.
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
#235Earlier 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…
Re: Good code is like a love letter to the next developer who will maintain it
#236Earlier 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'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
#237Earlier 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…
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
#238Earlier 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…
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
#239Earlier 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?
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
#240Earlier 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;