I'd be more inclined to believe Jeff when he says he doesn't need the rules, if I had some evidence he actually knew them.<p>From what I can see, the problem of "overly-rule-bound developers" is nowhere near the magnitude of the problem of "developer's who don't really have a clue."
Following rules slavishly is a pretty easy target; of course you want to do X because you think it's the right idea, not just because someone else told you to do it.<p>But at the same time, often the only way to develop the intuition and experience to know when to follow those rules (even if it's hard) and when to break the rules is to blindly follow the rules for at least a little while so that you get a feel for them. How do they fit with your personality or problem space? Which parts seem to add value or prevent mistakes? Which parts are getting in your way? Which parts add value some of the time but not if you have to try too hard to follow them?<p>Any idiot can come up with a set of "rules" that other people should follow, but there are also plenty of incredibly intelligent, experienced people who have attempted to distill their knowledge for other people in that form. Dismissing them out of hand and then patting yourself on the back for it ("I'm an awesome programming precisely because I don't follow other people's rules") is not the way forward.<p>To me, part of being a good programmer is being able to temporarily put aside your existing notions of what's good or bad, what will work and what won't, in order to try out someone else's way of working so that you can truly internalize it and hopefully learn something new. That applies not just to following simple "rules" about how to structure your code, but to trying out new styles of development, new programming paradigms or languages, new toolsets, etc. All of those require the ability to temporarily suspend your judgment about what works and what doesn't and to just try to do something "by the book" for a bit in order to hopefully come out the other side an even better programmer.
There are many ways to write a small piece of software so that it conforms to certain specs. Rules, even if arbitrary, tell a developer what is a "better way" and reduces the doubts he has about how to write that code. So developers, especially novices, like rules.<p>Software engineering is fundamentally about trade-offs and it seems plain rules like IF context THEN follow_recipe are not expressive enough. Like a database engine, rules based optimizer will only take you so far, for better results you need to use cost based optimizer, and learning the costs associated with each option only comes with experience.
It's like human machine learning.<p>Rules are what you use to program programmers. If your aims are limited and it's a good set of rules, why not.<p>If you want to use your programmers to do something you don't know how to do, instead create an environment that evolves the right kinds of programmers and set them loose.