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.
It makes one vulnerable though, that's for sure. Psychologically I mean.
Probably a pipe dream though.
But for sure I don't want to force it on people.
Don't use the feature if you don't want to, I'm all about freedom of choice.
Just saying the upside to it.
I know I'm done with a module when people add features to it the way I would have done so. That sounds like a non-statement, but I bet if you watch your projects closely, you'll see that's often not the case and sometimes it's laughably bad. It goes along with Knuth's thing about code meant to be read by humans and incidentally by computers, and also Kernighan's Law. My code eventually just says exactly what it does. And I don't use the same noun to mean three different things in three different places. Why? Because then I can take my name off of the bus number list and pick something else up. This module that I wrote is Steve's baby now, and that one is David's. In fact taking it over is how David got promoted.
The only reason they'd go deeper is for a bisect, or some other analytical method.
At least one day I hope they level up to be able to do that.
It's a golden rule thing for me.
I like more information because it's easier to filter too much data, than to reconstruct destroyed information.
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
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.