> Engineers read code when they have to work on it. If naming and structure are good, it will be self evident what that code does and why. In early greenfield

> Engineers read code when they have to work on it. If naming and structure are good, it will be self evident what that code does and why. In early greenfield software, sure, but given the test of time this assumption will always fail. The reason is that each team that works on a given software has an operating context that's often undocumented. They use lingo and rhetoric that likely aligns to that and is illuminating now but when that lingo isn't as common it'll likely die off. The very idea that words of a contextual language will be exactly relevant in the future is a short-sight in its own. Writing a lot of docs has its own tradeoffs, but I do think it's worth pursuing principles of writing good notes. I'm oft fascinated by reading the comments on old code that remain durable.