Crossing developer generations with design docs
Hypothesis: Products often fail because engineers lose confidence in making changes.
What things do developers do to create confidence in a change set?
How do they lose confidence then?
So let’s talk about churn
Engineers are born to a product in generations:
- 1st gen build the feature
- 2nd gen work with the engineers that build the feature
- Nth gen never work with the original creator.
Even with the best retention in the world churn will happen and you’ll lose your first generation developers.
So let’s do something about it.
What can we do?
More tests? More code documentation?
What does a design doc look like?
Consists of:
- What were goals?
- were there any non goals that aren’t covered and why?
These sound a bit like ADRs?