> 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 guide

> 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.