3 ms·

> I am surprised that most of the comments here are actually advocating for navigating Dilbert-style office politics as an effective way of "getting along." Th

> I am surprised that most of the comments here are actually advocating for navigating Dilbert-style office politics as an effective way of "getting along." That's unfair. Most people who are advocating for deference when first joining a team. And the common justification isn't politics! The most common justification is that there are a lot of "unknown unknowns". Therefore, sitting back and learning the social and technical history that led to the current system is actually the correct place to be in the exploration-exploitation axis during the probationary period. Both for social reasons, as well as for technical reasons. That's very different from "put up with office politics". The point is not that you should be likable during the probationary period. The point is that people who go way the hell too far to the "exploitation" side of the axis so quickly are demonstrating poor engineering judgment. Characterizing that poor judgment as "well I guess I'm just not PC enough" is just icing on the cake. > The team "criticisms" are to the person who is actually doing his job, instead of the ideas this person expresses, falling at the very bottom of "Graham's Hierarchy of Disagreement." According to this account. I submit that it's not even obvious that the engineer in this story was even making the correct engineering decision. Engineers are not scientists: > In such situation, leadership should have had created a secure context for the team to consider their gaps in process that produce results with reduced quality. I think the core problem in this story was wasting a bunch of the company's time arguing over a heuristic that's "good enough" in practice. Both solutions would have been "good enough"; the engineer put his ego above producing value for the company. > Organizations that need to move fast cannot afford such conformism and dysfunctional communication. Organizations that need to move fast cannot afford engineers spending time to prove they were correct when going with the established heuristic would've produced a good enough result with far less engineering time involved. If the story included a thorough cost/benefit analysis showing that the change saved the company $N0,000 with N > (cost of engineering time) then you might have a more cogent argument.

humanrebar 8y ago
> And the common justification isn't politics! The most common justification is that there are a lot of "unknown unknowns". They're mostly not unkown unknowns. They're mostly arcane knowledge of some sort or the other. And what prevents good communication of this knowledge besides either lack of competence or politics? Someone didn't know or didn't care to do better and nobody held them accountantable for it. In particular, the strange horrible code might be there for a great reason. But there is not a good reason for nobody to take five minutes to write a comment about why. And there is no reason to not ask for that comment when the change is reviewed.

humanrebar 8y ago

> And the common justification isn't politics! The most common justification is that there are a lot of "unknown unknowns". They're mostly not unkown unknowns. They're mostly arcane knowledge of some sort or the other. And what prevents good communication of this knowledge besides either lack of competence or politics? Someone didn't know or didn't care to do better and nobody held them accountantable for it. In particular, the strange horrible code might be there for a great reason. But there is not a good reason for nobody to take five minutes to write a comment about why. And there is no reason to not ask for that comment when the change is reviewed.