> The only “best practice” you should be using all the time is “Use Your Brain”.
This is true, in that very few best practices are universally applicable and you should never stop thinking. The author is also totally right about people jumping on bandwagons and being cargo cult members.
So I'm not really disagreeing with him, but just adding that a lot of best practices actually aid your ability to reason through code. They can help to push repetitive things off to the automatic portions of your brain. They can help to make patterns in your code that are visible and familiar, so you can spend less time thinking about how to implement (or read) some simple thing and more time thinking about how the simple pieces fit together.
Which is not to say all "best practices" are great. But even the questionable ones usually have some interesting problem they are trying to solve that explains why they sprung into being. If a "best practice" is popular enough that it gets called a best practice, it's probably worth paying attention to and thinking about even if you ultimately decide not to use it.
If you face the exact same problem 10 times, and you think it through from the beginning every single time, you're going to get 10 different answers. You just can't remember all the little details every single time.
Once in a while I surprise myself by independently coming up with exactly the same designs for similar problems (or, in fact, the same problem that I forgot I solved already few months ago). Most of the time I don't remember any details of the problem besides the general idea that I had it before. And then when I finally dig up the code it looks exactly like I was going to write (or was in the process of writing :)).
I think experience can actually become a liability. Things have changed and you don't have to write assembly code to optimize your program. Compilers will probably do a better job than you. And if you have a lot of experience writing JavaScript for IE6, you may actually be wasting time optimizing in ways no longer relevant.
True, but this is why you tend to migrate towards an architect/lead role later in your career where the general insights about systems and design are still applicable with out needing to overly focus on present day implementation minutia .
Well said. Normally, a best practice becomes known as a best practice because it is the right choice most of the time. It probably won't be the right choice all of the time and the truly successful can excel by knowing when to creatively deviate from the "best practices", but they make for good baseline to adjust and customize from.
>They can help to push repetitive things off to the automatic portions of your brain.
I agree, further, anything that can be automated should be. GTD and most similar systems stress getting everything possible out of your head and into the system, so you can concentrate on what is most important. Many "best practices" try to do the same, the trick, as you point out is to use the ones that are appropriate to your problem.
This is true, in that very few best practices are universally applicable and you should never stop thinking. The author is also totally right about people jumping on bandwagons and being cargo cult members.
So I'm not really disagreeing with him, but just adding that a lot of best practices actually aid your ability to reason through code. They can help to push repetitive things off to the automatic portions of your brain. They can help to make patterns in your code that are visible and familiar, so you can spend less time thinking about how to implement (or read) some simple thing and more time thinking about how the simple pieces fit together.
Which is not to say all "best practices" are great. But even the questionable ones usually have some interesting problem they are trying to solve that explains why they sprung into being. If a "best practice" is popular enough that it gets called a best practice, it's probably worth paying attention to and thinking about even if you ultimately decide not to use it.