3 ms·

> it's often buried in a bunch of other discussion and dead ends If your "why" doesn't contains this, I have an hard time understanding why you want it in the

by dwild 8y ago

> it's often buried in a bunch of other discussion and dead ends If your "why" doesn't contains this, I have an hard time understanding why you want it in the first place. The "why" is important to not make the same mistake. Theses others discussions and dead ends are all related to the issue, they are all questions that was asked/answered during it, they are all mistakes that may have been made. Personally every time I only needed a tiny bits more context, the commit message was enough and if I needed more, the full related ticket was essential (and not a simple why, but the full though process that became that decision). > Funny how many people who would rather die than write a design spec I'd rather die than lose time over something I consider won't save time in the long term. Writing any documentation is long and if that time is longer than the few time we'll need it, it's a loss of time. It's pretty rare that we need to go back to that information, when we do, the ticket information is enough and if it's not, doing the though process a second time isn't so bad the rare time it happens (which will provide more context by the new ticket discussion too). For sure if your ticket just say: - Break when we enter text - FIXED You are going to have a pretty bad time and you need to change that.

notacoward 8y ago
> If your "why" doesn't contains this, I have an hard time understanding why you want it in the first place. The "why" doesn't need to include every minor style nit (all the way down to variable naming) that came up during the review. It doesn't need to include every "I would have done it this way instead" comment which was in neither the original nor final version. That's noise, not signal. > Personally every time I only needed a tiny bits more context Lucky you. For much of the code I have read or written, that was not the case. In general it tends to be less and less the case as code climbs up the complexity/innovation scale. > I'd rather die than lose time over something I consider won't save time in the long term. Is that an unavoidable issue with the medium, or more of a reflection of how some people are bad at writing? I've whipped out a spec for a medium-complexity feature or component in under an hour, and been thanked for it five years later. Many times. If you've never had that experience, then I can only say I hope you'll be able to some day. > when we do, the ticket information is enough and if it's not Again, lucky you. Others have a different experience.

by dwild 8y ago

notacoward 8y ago

> If your "why" doesn't contains this, I have an hard time understanding why you want it in the first place. The "why" doesn't need to include every minor style nit (all the way down to variable naming) that came up during the review. It doesn't need to include every "I would have done it this way instead" comment which was in neither the original nor final version. That's noise, not signal. > Personally every time I only needed a tiny bits more context Lucky you. For much of the code I have read or written, that was not the case. In general it tends to be less and less the case as code climbs up the complexity/innovation scale. > I'd rather die than lose time over something I consider won't save time in the long term. Is that an unavoidable issue with the medium, or more of a reflection of how some people are bad at writing? I've whipped out a spec for a medium-complexity feature or component in under an hour, and been thanked for it five years later. Many times. If you've never had that experience, then I can only say I hope you'll be able to some day. > when we do, the ticket information is enough and if it's not Again, lucky you. Others have a different experience.