Ask HN: How do you find the "why" behind old code decisions?

The answer to why is almost always because that is the limit of talent available to the organization at the time with the given technology options available. Its really that simple.

In some cases there are many options and great talent is readily working on the problem for the given organization. Its nice to have options, but this is an exceedingly rare scenario. For example there are tons of options available today, but from reading HN job posts it looks like the answer is still a CRUD app that does some SAAS solution with React, AI, and Python. I could guess that and be right more than 60% of the time, which is extraordinary considering these businesses have thousands of technology combinations and unlimited ideas to pick from. Its all about the talent available, but when I say talent I just mean people because when you are that restricted it isn't very talented.

Hi level answer is always - to satisfy the product/customer requirements.

If the requirement was never documented or lost, then you can only deduce it like Sherlock Holmes.

Low level answer is always- because this is the best way current developer could come up with given the organizational context and his level of experience.

The honest answer is you probably won't find it. Historical documentation is hard, it is the first "features" cut when teams are scrambling to meet a deadline. There is no malice in this, it's just something that the end user doesn't need or see so when shit hits the fan, it get skipped.

Commit logs, slack/email/etc, documentation silos, or issue trackers are your best bet, other than actually being able to talk to the author(s) of the code.

But in general, the decision was made because in the time the developer had to implement the feature or fix, this was the best solution they could come up with. Hopefully if there were clear tradeoffs, there is some comment as to what they might have done with more time. Likely though they were rushed, told their team they wanted to go back and fix this, and then were ushered into a new project the second this one stabilized.

I think gghhjnuhbb has the best alternative to finding actual documentation and that is sitting and putting yourself in their headspace. That can sometimes lead to insights you might have missed.

[dead]

Anything that has a "why" _should_ have a comment. I know people like to structure code so that it doesn't need comments. However, nice clean well structured code can describe the _what_ without comments but never the _why_.