I haven't discovered it yet. Of course, there are certain studies and models like 16 personalities, DISC, etc. But you cannot pinpoint people to these categories easily. It's a spectrum, I guess.
It's not either/or. The observation that freezes and no Friday deployments capitalize on is that the single most likely cause of production incidents is production changes.
We always should target better stability, but no matter how good your system and incident response are, if your goal is to minimize customer disruption during a certain time window, or avoid dealing with incidents on weekends, minimizing production changes is the simplest and most effective measure
I agree. The flipside though is a freeze also invokes a scenario that can lead to a premature release. Any blanking window forces a decision between deferring or rushing work, neither of which are ideal.
> Those three don't belong together in any way. Yet here we are.
The difference here is degree of humanization of an animal. Recent Andrew Huberman podcast with a former FBI hostage negotiator[1] touched upon the topic.
In animal research labs, the researchers are disallowed to name the animal subjects, only to assign numbers or codes.
In a hostage situation, simply letting your captor know your name increases the chances of your survival. Conversely, having your face covered reduces the chances.
Humanization and dehumanization of things, living beings, other humans and ourselves is something that we generally tend to do. A lot of cruelty in the world can be traced to this observation.
I sympathize with your sentiment, but I don't think Go has anything to do with this.
The disregard for the fact that some engineers are more productive than others originates from companies' processes and planning. Projects are usually estimated without considering who will be working on the project and individuals are compressed to person-weeks. I have experienced it myself and read texts describing this issue in the same terms[1].
It doesn't really help that Go was designed in such a company, but saying that it was designed to mitigate this disparity is saying that the best predictor of an engineer's productivity is the number of LOC cranked out. I don't think that is the case, neither in principle nor in Google particularly.
Much better predictors of productivity are effective communication and conceptual integrity of the design, as the linked article points out. It doesn't really help that you use brilliant language if, 6 months in, you've realized you're building the wrong thing, or you build it in the wrong way.
curious - is there a way to learn this other than from experience?