I understand the point, but shouldn't the code be documented and well structured so that the intent is clear without looking at the discussion around changes?

I'm working on a legacy system right now - I'd commit several felonies just to have well documented code, I don't really care about all the conversations that the original team had to decide what they eventually did.

Maybe I'm just too old and don't get it.

▲

anthonypasq 2 hours ago | parent [-]

surely you could imagine that being able to sit in on a meeting that was had when they were designing the system would be useful for you?

theres a lot of context and decision making that is useful but not documented in the code. The code tells you how the system works, not how its supposed to work.

▲

godwinson__4-8 an hour ago | parent [-]

This is just the classic rehash of are comments in code an anti-pattern.

I tend to agree that at a certain point if you need to constantly think "gee, I wish I was in the meeting when they came up with this" the code you are looking at might just suck.

In such contexts it is also often the case that being in the meeting may not have helped. As they say, garbage in, garbage out.

	▲	bredren 2 minutes ago \| parent [-]
		Sometimes it is useful to simply know something was brought up, but then someone had a sneezing fit and everyone lost track of the thread and the important edge case under discussion just fizzled. A similar thing happens in agentic conversations, where a model may point out something but it is not recognized as important by the operator. A few directives later and the model is being pushed another direction. It can be very useful to have perfect recall of moments like these.