211–220 of 274 posts
Code works. Not all work is fun and beautiful, some work is not even worth doing. But making something work because it needs to work is also worth doing.
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.
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?
//Returns the user's full name return user.email;
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.
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…
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.
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…
There are no automated to enforce good abstractions, but languages and tools can serve as a way to shepherd programmers into avoiding or preferring certain patterns. This is an argument as old as the programming language field itself.
For some people Golang strikes a good balance. I'm not one of those people, but I have learned to respect it.
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)…
> 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.
Personally I came to terms with myself for not having to do that. Some companies who rush things to market do not understand it but it is okay with me.
Looking back at years and shipped projects I do not trust such metaphors as in the article.
I prefer other pov. Where I grew up one songwriter and performer coined it (sorry at incorrect translation) "[they] write as they breathe. It is a natural order of things". So if I do not like working with someone's code I have to move on.
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.…
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.
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…
So no, it requires no translation.
I disagree completely that the humour is lost. There may be jokes I don't get, but that's more true for Futurama with all its 90s American telly references.
Perhaps Chaucer would be a better example?