WET Dilutes Performance Bottlenecks The importance of the DRY principle (Don’t Repeat Yourself) is that it codifies the idea that every piece of knowledge in a system should have a singular representation. In other words, knowledge should be contained in a single implementation. The antithesis of DRY is WET (Write Every Time). Our code is WET when knowledge is codified in several different implementations. The performance implications of DRY versus WET become very clear when you consider their numerous effects on a performance profile.

When Programmers and Testers Collaborate Something magical happens when testers and programmers start to collaborate. There is less time spent sending bugs back and forth through the defect tracking system. Less time is wasted trying to figure out whether something is really a bug or a new feature, and more time is spent developing good software to meet customer expectations. There are many opportunities for starting collaboration before coding even begins.

Write Code as If You Had to Support It for the Rest of Your Life You could ask 97 people what every programmer should know and do, and you might hear back 97 distinct answers. This could be both overwhelming and intimidating at the same time. All advice is good, all principles are sound, and all stories are compelling, but where do you start? More important, once you have started, how do you keep up with all the best practices you’ve learned and how do you make them an integral part of your programming practice?

Write Small Functions Using Examples We would like to write code that is correct, and have evidence on hand that it is correct. It can help with both issues to think about the “size” of a function. Not in the sense of the amount of code that implements a function — although that is interesting — but rather the size of the mathematical function that our code manifests. For example, in the game of Go there is a condition called atari in which a player’s stones may be captured by their opponent: A stone with two or more free spaces adjacent to it (called liberties) is not in atari.

Write Tests for People You are writing automated tests for some or all of your production code. Congratulations! You are writing your tests before you write the code? Even better!! Just doing this makes you one of the early adopters on the leading edge of software engineering practice. But are you writing good tests? How can you tell? One way is to ask “Who am I writing the tests for?” If the answer is “For me, to save me the effort of fixing bugs” or “For the compiler, so they can be executed” then the odds are you aren’t writing the best possible tests.

You Gotta Care about the Code It doesn’t take Sherlock Holmes to work out that good programmers write good code. Bad programmers… don’t. They produce monstrosities that the rest of us have to clean up. You want to write the good stuff, right? You want to be a good programmer. Good code doesn’t pop out of thin air. It isn’t something that happens by luck when the planets align. To get good code you have to work at it.

Your Customers Do not Mean What They Say I’ve never met a customer yet that wasn’t all too happy to tell me what they wanted — usually in great detail. The problem is that customers don’t always tell you the whole truth. They generally don’t lie, but they speak in customer speak, not developer speak. They use their terms and their contexts. They leave out significant details. They make assumptions that you’ve been at their company for 20 years, just like they have.