A software engineer that loves Disroot and the team behind it.
Talk to the manager Karen! Do it!
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’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.
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 often skip meetings without agenda. If they don’t care to prepare a reasonable invitation, I don’t care to join. Also - I skip meetings where they announce stuff. Announcements should go to my inbox, so I can read them when ready, not when they think it’s suitable for them.
My main concern with people making fun of such cases is about deficiencies of “AI” being harder to find/detect but obviously present.
Whenever someone publishes a proof of a system’s limitations, the company behind it gets a test case to use to improve it. The next time we - the reasonable people arguing that cybernetic hallucinations aren’t AI yet and are dangerous - try using such point, we would only get a reply of “oh yeah, but they’ve fixed it”. Even people in IT often don’t understand what they’re dealing with, so the non-IT people may have even more difficulties…
Myself - I just boycott this rubbish. I’ve never tried any LLM and don’t plan to, unless it’s used to work with language, not knowledge.
Now I’d love to see a Perl monk comic!
I’ve recently changed to a part-time contract, thanks to decent wages we get in IT. None of my friends outside of IT could afford that. If anyone claims IT professionals earn too little, they should change their job and see how much their life improves then.
It would rather go like that:
“Documentation is on discord.”
“Why”
A true FP programmer would make it
apply
instead ofrun
…