151–160 of 274 posts
This is fairly tired conversation and while superficially interesting, there is simply no way to define good code except through local consensus of the people writing and reading the code. But that's as far as it will go, and time will will take what's owed to it.
1) "Code sober, debug drunk" It's harder to read the code than to write it so if you can barely comprehend the thing you just wrote, you probably won't understand it in the future: https://sonnet.io/posts/code-sober-debug-drunk/ 2) I think it's more like speaking with ghosts (including a spoiler for The Sixth Sense): https://sonnet.io/posts/emotive-conjugation/
>it’s harder to read code that to write it Isn’t this only true of bad code? Good code is almost certainly the other way round, harder to write than read… just like a really good book was much harder for the author than it was for you, the reader.
The quote you call into question is semi-famous and I believe the idea is that it's relatively difficult to jump into one code unit of a larger system and get back up-to-speed because one must fill the data cache of their brain with all the considerations for why the author may have done things in a certain way. The algorithm choices and edge cases and exceptional logic paths were clearer to the one writing the original at the time.
Like, 1000x more.
Sorry next developer, I'm on a tight deadline, used to love this craft, now I just do what the product people tell me to get a nice paycheck.
The craft is not the code, but the product. You can have beautiful code and garbage product, and great code and a garbage product. If your PM is pushing bad products, that's on them. Your job is to deliver good product, not good code.
These two are not disjoint, but instead quite related.
> Your job is to deliver good product, not good code.
If your job is software engineering, then "good code" is what facilitates "good product." It boils down to maximizing the "abilities":
- Understandability
- Applicability
- Testability
- Maintainability
- Flexibility
- Durability
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…
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’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.
https://blog.desdelinux.net/en/el-open-source-con-malas-pala....
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... .
As said there, this might as well be simply a correlation with commented code.
Or, people swearing might be an indication of having taste.
"At the start of my book, Learning JavaScript Design Patterns, I say "good code is like a love letter to the next developer who will maintain it". It is an intimate correspondence, from one developer to another, spanning time and space." Seriously?! It's simple. It's a matter of respect, and treating others as you would like to be treated. It's no fun trying to figure out the "why?" of some code you've inherited resp…
Because I've found there's a bunch of developers who apparently think it is fun to figure out the "why?", and they code accordingly.
>So why would you put others through it.
Because they think their code is "self documenting" and perfect and that anyone that can't immediately understand their code is too dumb to be working with it.
>Explain it with comments.
We just had a discussion here in the last week or two where people were actually saying that comments are completely useless and should never be used.
>Make it so that there's minimal - preferably zero - unnecessary digging for the next poor soul who'll work on it.
Sounds great to me, but in my experience it's a minority of developers who agree with you. It makes working on others' codebases very frustrating in most cases.
Precisely why I also create READMEs in top-level directories. I'm not going to remember how to structure queries for my API a year from now. Future me will always appreciate how considerate present me was.
> Future me I like this term a lot more than "the next developer."