The Pragmatic Programmer

it’s these expectations of business value that really count—not just the software project itself. The software is only a means to these ends.

Why Don't Many Business Users Read Cucumber Features? One of the reasons that the classic gather requirements, design, code, ship approach doesn’t work is that it is anchored by the concept that we know what the requirements are. But we rarely do. Your business users will have a vague idea of what they want to achieve, but they neither know nor car

Concurrency is when the execution of two or more pieces of code act as if they run at the same time. Parallelism is when they do run at the same time.

Commenting source code gives you the perfect opportunity to document those elusive bits of a project that can’t be documented anywhere else: engineering trade-offs, why decisions were made, what other alternatives were discarded, and so on.

When Should You Refactor? You refactor when you’ve learned something; when you understand something better than you did last year, yesterday, or even just ten minutes ago.

Meyer’s Uniform Access principle, described in Object-Oriented Software Construction [Mey97], which states that All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation.

We’ve found that as our knowledge of the domain increases, we’re better able to make suggestions on other things that could be done to address the underlying business issues.

The distinction is important enough to warrant repeating. Prototyping generates disposable code. Tracer code is lean but complete, and forms part of the skeleton of the final system. Think of prototyping as the reconnaissance and intelligence gathering that takes place before a single tracer bullet is fired.

Plan what you want to say. Write an outline. Then ask yourself, “Does this communicate what I want to express to my audience in a way that works for them?” Refine it until it does.