3 ms·

I have these on display at my desk. I've always wanted to know how to encourage cultural adoption? What are the arguments against these rules? There must be som

I have these on display at my desk. I've always wanted to know how to encourage cultural adoption? What are the arguments against these rules? There must be some. My reasoning about these rules is that they derive from the idea that as teams of programmers, we're professionally motivated (and being paid) to produce the highest possible quality results. To that end, these rules compensate for human biases and faults to maximize quality. Many of the practices you've read about some companies enforcing, such as "there are no bad ideas" or "no stupid questions" can be related back to these rules under the same reasoning. None of us do a perfect job of compensating for our human faults and biases, so some rules help to improve our performance. My dad also passed away very early, soon after I finished college, and I credit him for making these rules so easy to follow.

dasmoth 12y ago
> What are the arguments against these rules? There must be some. I don't actually find this set terribly objectionable, at least when they're treated as guidelines rather than rules, but I'll have a go anyway. Excessive focus on issues like this is seen as a symptom of a managerialist culture. While few developers I know would object to the ideas that everyone has something to learn, and that apprentice and journeyman coders should be supported and encouraged, there is -- sometimes justified -- suspicion that the real agenda is to commoditise developers and turn programming from a craft into a factory-floor activity. Or, to refer to another article that's on the front page this morning, to turn antiwork into work. The kind of things that get put in place to "compensate" for ego are rules which value maintenance over re-writes, and third party components (even if they're only a tenuous fit for the problem) over in-house development. While I agree that there are biases to be aware of here, dismissing every proposal for a re-write or new internal development as egotism ends up shutting down discussions about the actual trade-offs.
- mfisher87 12y ago
  >While I agree that there are biases to be aware of here, dismissing every proposal for a re-write or new internal development as egotism ends up shutting down discussions about the actual trade-offs. I'm not sure how this behavior could be attributed to any of these rules. Could you elaborate further?

dasmoth 12y ago

> What are the arguments against these rules? There must be some. I don't actually find this set terribly objectionable, at least when they're treated as guidelines rather than rules, but I'll have a go anyway. Excessive focus on issues like this is seen as a symptom of a managerialist culture. While few developers I know would object to the ideas that everyone has something to learn, and that apprentice and journeyman coders should be supported and encouraged, there is -- sometimes justified -- suspicion that the real agenda is to commoditise developers and turn programming from a craft into a factory-floor activity. Or, to refer to another article that's on the front page this morning, to turn antiwork into work. The kind of things that get put in place to "compensate" for ego are rules which value maintenance over re-writes, and third party components (even if they're only a tenuous fit for the problem) over in-house development. While I agree that there are biases to be aware of here, dismissing every proposal for a re-write or new internal development as egotism ends up shutting down discussions about the actual trade-offs.

mfisher87 12y ago
>While I agree that there are biases to be aware of here, dismissing every proposal for a re-write or new internal development as egotism ends up shutting down discussions about the actual trade-offs. I'm not sure how this behavior could be attributed to any of these rules. Could you elaborate further?