The Danger Of Best Practices

Every person has at some point experienced the phenomenon known as writers block. For programmers, this manifests as a block against writing code or getting into the flow of programming. Like all creative enterprises, this block often stems from a fear of creating. Our creative cogs get stopped up because we fear that what we create might not be good enough, correct, or otherwise valid.

In programming, this fear often manifests as "am I doing this the right way?" I sometimes have trouble getting into the flow of coding because I'm constantly thinking "Maybe I'm doing this wrong. Maybe there's a better way. Maybe maybe maybe." This fear can be debilitating and is a would be creator's biggest enemy. Unfortunately this problem can be compounded in the coding world by the existence of Best Practices.

Best Practices, which describe the "best" way to accomplish a given coding task, are usually useful and helpful to a programmer. The problem occurs when one begins to fear ever violating some ethereal Best Practice. It isn't a specific best practice which causes the problem, but the existence of Best Practices as a whole. Letting the fear of not doing something the "best" way restrict your creative flow is utterly pointless and self-defeating. The quest for best practices should be a relaxed one of new learning, not a frantic one of self-validation.

The fix to the problem is the same as it is in all creative ventures - damn the torpedos and full speed ahead. Ignore other concerns, other ways of doing things, other "best practices" and just do it. Write that program. Code that library. Going back and changing things later is easy. If you never write anything, you'll never have anything to change. Apply Best Practices after the fact. Refactor. Revise. If you happen to see a better way of doing something in the future, modify your source, run your tests, and check in a new revision. Never let "what could be" get in the way of "what can be right now."