Nobody needs to know quite how messy the process of making the sausage is though. There are steps that provide information, even about how the bugs got in there. But not every thought needs to be expressed.
I cook my own commits 75% for me six months from now and 25% for everyone else. I'm literally only doing about 1/3 more work (on the therapy part) than I would have done anyway.
health inspector is a literal job that needs to know how messy the process of making the sausage is, so they can enforce health standards so nobody gets sick when eating it.
if you're calling what you're doing engineering, you are following a standard best practice, and should easily be able to run through a checklist and show your work at each step.
not every thought needs to be expressed sure. its irrelevant what you thought about your lunch. Its important how you picked what latency numbers are important, and how you went about predicting volume, including what factors your did and didnt look at.
software developers havent been rigourous engineers over the last several decades, and that isnt a good thing
No arguments here. The weird thing is that this was all much more straightforward when we did trunk-based development. You still ended up stashing four different things and having multiple speculative local branches while you tried your crazy ass ideas out, and Mikado Method was your very best friend.
What ended up happening is you committed the safe bits and the reversible decisions first to buy yourself time to work out the tricky bits before you had to commit (literally and figuratively).
I think trunk-based development is greater than PRs, but the values are close enough that the politics of PRs (specifically, consensus-based development) win out, or at least aren't worth fighting.
It makes one vulnerable though, that's for sure. Psychologically I mean.