The parts that jump out to me in the context of being a professional programmer: 1) Definitions == overloading. We regularly run into overloaded terms that mea

The parts that jump out to me in the context of being a professional programmer: 1) Definitions == overloading. We regularly run into overloaded terms that mean very different things to different people. Microservices. Technical debt. 2) Being wrong - there is a perceived cost to being wrong, and in many organizations it is unfortunately a reality. When new or young, there is so much emphasis on proving oneself that there is easily a disincentive to opening oneself up to risk of being wrong. After being around a while, it is easier - sometimes I like advancing a position I know to be wrong because I know it will more efficiently generate explicit reasons why, as people protest (although even there I usually make clear I am doing devil's advocate). 3) Abstraction scaling - it's unfortunately so common for programmers and technical people to get pedantic, which frustrates people and wastes time. Sometimes it's driven by insecurity. For instance, needing to be the smartest person in the room, or proving competence in an area that is not directly relevant. And sometimes that insecurity is rational, for instance if part of an organization that encourages insecurity through its systems. But oftentimes it is because of a lack of experience with abstraction, or an inability to recognize what "rung" a discussion is on, or losing one's place on the abstraction tree. Complicating this is that sometimes it is important to drill down when no one else wants to. Recognizing this and keeping track of relevance is one of the hardest things to do when dealing with deep subjects and arguments.