If you enjoyed it, I’ve collected a couple of others:
A software engineer that loves Disroot and the team behind it.
If you enjoyed it, I’ve collected a couple of others:
Reminds me this great story from a different era:
I definitely agree that too many comments is often a bad sign, esp. when large part of them is obviously generated.
As mentioned in my other comment, names will rarely explain the reasons why a given solution was chosen. These reasons are important from maintenance perspective and should be recorded next to the relevant code.
You’re definitely not the only one.
In my opinion the important information we should record in comments is WHY, because the code can only explain HOW, maybe WHEN, but never WHY. If we don’t know WHY, any refactoring done in the future could break the logic by ignoring assumptions made by the authors.
I keep telling myself that in the ideal world, phones would be programmed in Forth.
That comment… Oh my, I want to joke and talk someone like you! Now!
I tried searching for research on it, but only found results claiming this didn’t work… Not actual scientific research, but better than “we think this should work, so now we’ll try selling it”
And “Y” stands for “Your Mom”. But it was a one night stand…
I’m beginning to feel we’re no longer talking about Clean Code being bad, but about people following ideas they don’t understand, which is not related or caused to any particular book.
I hope your book won’t have a table of context and those stupid indexes. If they read it, they should know where you mention topics, right? Tables of contents considered harmful! /s
I’d love to learn what that damage was. I often see complaints (sometimes also involving tech choices) but usually they’re not specific, so I’m always left wondering.
C Tesseract has this interstellar vibe and brings quotes like the following, but with a totally different meaning:
I’m not going to argue, because I don’t know your work environment, but the notes I mentioned weren’t supposed to be published or attached to the product. They’re more of a personal knowledge base, where you can look up former approaches, issues found in the past, reasoning, decisions with context… All the zettelkasten tools out there do exactly that: help maintaining a useful knowledge base.
That’s the next level of trolling!
That’s why we keep notes… Literate DevOps is a solution for my preferred editor, but there definitely are solutions for other tools too, even if they don’t work exactly the same.
I can’t recommend keeping notes too much.
I want people like you around me!
I’m trying to convince a senior developer from the team I’m a member of, to stop using copilot. They have committed code that they didn’t understand (only tested to verify it does what it’s expected to do). I doubt it’d succeed…
They’ve got Paid BSOD, I’ve got FreeBSD, we’re not the same.
Talk to the manager Karen! Do it!