A declarative programming style focuses on what you want your program to do rather than how to perform the task. By avoiding implementation details, well-written declarative code is easier to understand, modify, and maintain. The code you write in a declarative style is often so readable that you can share it with your project’s domain experts. Furthermore, once you start working with declarative code, you can automatically process it to verify properties of its operation, generate test cases, or create parts of the system's documentation. Small choices, such as the naming of your methods and variables, matter. If you’re coding an algorithm, have your code match the algorithm’s published description. Other approaches to consider include table-driven programming, the implementation of a domain-specific language, or the use of task-specific libraries. When you have the choice, pick the highest level language you can afford and that’s suitable for the task at hand.

The choice between using the functionality of the application’s platform (Java EE or .NET), calling one of several available external libraries, or writing code on your own involves numerous factors. When you write your own code, you control its quality. If some alternatives come in the form of external libraries, start by looking at the licensing terms. Next, judge the usability of the library or the platform API and the library’s compatibility with your system. Elements with diverse naming conventions are an open invitation for disorder and style abuses. Other compatibility areas you should investigate include error handling, memory management, multithreading, and build management. Finish your examination by looking into the library’s dependencies, quality, and support.

The DTrace dynamic-tracing framework provides uniform mechanisms for spying comprehensively and unobtrusively on the operating system, application servers, runtime environments, libraries, and application programs.

The Unix system and its pipelines are a model of software reuse, while software repositories, package-management systems, shared-library technologies, and language platforms have also increased reuse's return on investment.

Open source software development efforts offer professionals a new and valuable way to obtain significant experience in a wide range of areas as an alternative to existing certification schemes.

There's no language suitable for all tasks, and there probably won't ever be one. When choosing a programming language, you have to balance programmer productivity, maintainability, efficiency, portability, tool support, and software and hardware interfaces. Often, one of these factors will shape your decision. In other cases, the choice depends on the productivity you gain from certain language features, such as modularity and type checking, or external factors, such as integrated development environment support. Finally, for some tasks, adopting an existing domain-specific language, building a new one, or using a general-purpose declarative language can be the right choice.

Debuggers are cheap and effective tools. Typically we use them in a bottom-up fashion starting from the problem going to its source, but when this strategy fails, we might have to resort to a more tedious top-down breadth-first search.

Stringent quality control helps eliminate bugs. Tools can help prevent them from ending up in production code. We can use type-safe languages, heed compiler warnings, adopt specialized bug-finding tools, and adjust our code to locate bugs during testing.

Source code makes up only a small part of a system’s assets; we also have specs, design diagrams, build rules, version history, documentation, regression tests, and more. Chances are you dread even the thought of changing the tools you use.

With modern shell command-line editing facilities, we can build commands bit by bit until they are exactly what we need. Nowadays, many systems offer the original Unix tools, so there's no reason not to add this approach to your arsenal.