How do you capture WHY engineering decisions were made, not just what?

We have recently added a senior engineer with 8 years of experience. He spent 3 weeks as a code archaeologist to understand why our codebase looks the way it does.Not the one who codes. that was fast. But the reasoning behind the decisions:

– Why is Redis larger than in-memory cache? – Why GraphQL for this one service but REST everywhere else? – Why is there this strange exception in the authentication flow for enterprise users?

The answers were buried in closed PRs with no details, 18-month-old Slack threads, and the heads of two engineers who left last year.

We tried ADR. Lasted for 6 weeks. No one maintained them. We tried the PR statement template. Was ignored within a month. We have a Notion Architecture document. Last updated 14 months ago.

Every solution requires someone to write something manually. Nobody does.

Curious to know how HN teams actually handle this:

1. Do you have a system that really works long term? 2. Has anyone automated any part of this? 3. Or is everyone quietly suffering this at every new job?



<a href

Leave a Comment