Distinguish Business Exceptions from Technical There are basically two reasons that things go wrong at runtime: technical problems that prevent us from using the application and business logic that prevents us from misusing the application. Most modern languages, such as LISP, Java, Smalltalk, and C#, use exceptions to signal both these situations. However, the two situations are so different that they should be carefully held apart. It is a potential source of confusion to represent them both using the same exception hierarchy, not to mention the same exception class.

Do Lots of Deliberate Practice Deliberate practice is not simply performing a task. If you ask yourself “Why am I performing this task?” and your answer is “To complete the task,” then you’re not doing deliberate practice. You do deliberate practice to improve your ability to perform a task. It’s about skill and technique. Deliberate practice means repetition. It means performing the task with the aim of increasing your mastery of one or more aspects of the task.

Domain-Specific Languages Whenever you listen to a discussion by experts in any domain, be it chess players, kindergarten teachers, or insurance agents, you’ll notice that their vocabulary is quite different from everyday language. That’s part of what domain-specific languages (DSLs) are about: A specific domain has a specialized vocabulary to describe the things that are particular to that domain. In the world of software, DSLs are about executable expressions in a language specific to a domain with limited vocabulary and grammar that is readable, understandable, and — hopefully — writable by domain experts.

Don’t Be Afraid to Break Things Everyone with industry experience has undoubtedly worked on a project where the codebase was precarious at best. The system is poorly factored, and changing one thing always manages to break another unrelated feature. Whenever a module is added, the coder’s goal is to change as little as possible, and hold their breath during every release. This is the software equivalent of playing Jenga with I-beams in a skyscraper, and is bound for disaster.

Don’t Be Cute with Your Test Data It was getting late. I was throwing in some placeholder data to test the page layout I’d been working on. I appropriated the members of The Clash for the names of users. Company names? Song titles by the Sex Pistols would do. Now I needed some stock ticker symbols — just some four letter words in capital letters. I used those four letter words.

Don’t Ignore that Error! I was walking down the street one evening to meet some friends in a bar. We hadn’t shared a beer in some time and I was looking forward to seeing them again. In my haste, I wasn’t looking where I was going. I tripped over the edge of a curb and ended up flat on my face. Well, it serves me right for not paying attention, I guess.

Don’t Just Learn the Language, Understand its Culture In high school, I had to learn a foreign language. At the time I thought that I’d get by nicely being good at English so I chose to sleep through three years of French class. A few years later I went to Tunisia on vacation. Arabic is the official language there and, being a former French colony, French is also commonly used. English is only spoken in the touristy areas.

Don’t Nail Your Program into the Upright Position I once wrote a spoof C++ quiz, in which I satirically suggested the following strategy for exception handling: By dint of plentiful try...catch constructs throughout our code base, we are sometimes able to prevent our applications from aborting. We think of the resultant state as “nailing the corpse in the upright position.” Despite my levity, I was actually summarizing a lesson I received at the knee of Dame Bitter Experience herself.

Don’t Rely on “Magic Happens Here” If you look at any activity, process, or discipline from far enough away it looks simple. Managers with no experience of development think what programmers do is simple and programmers with no experience of management think the same of what managers do. Programming is something some people do — some of the time. And the hard part — the thinking — is the least visible and least appreciated by the uninitiated.

Don’t Repeat Yourself Of all the principles of programming, Don’t Repeat Yourself (DRY) is perhaps one of the most fundamental. The principle was formulated by Andy Hunt and Dave Thomas in The Pragmatic Programmer, and underlies many other well-known software development best practices and design patterns. The developer who learns to recognize duplication, and understands how to eliminate it through appropriate practice and proper abstraction, can produce much cleaner code than one who continuously infects the application with unnecessary repetition.