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 d

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