The Pragmatic Programmer: List of tips


Chapter 1: A Pragmatic Philosophy


The first chapter discusses the attitude, style, philosophy approaching problems (and their solutions), and behaviors of a pragmatic programmer that distinguishes them. Topics discussed are:

·       Taking responsibility (don’t say, cannot be done, provide options)

·       Software Entropy (fix the bug immediately when its found, don’t leave enemy alive!)

·       Stone soup and boiled frogs (you know the story J )

·       Good enough software (all functionality works, no UI broken)

·       Invest in knowledge portfolio (what did you learn today?)

·       Communication tips (know what’s asked first)


Chapter 2: A Pragmatic Approach


This chapter discloses useful but rarely documented tips and processes for things like decision-making, creating prototypes, debugging, producing estimates, and domain languages. Topics discussed are:

·       The evils of duplication (DRY – don’t repeat yourself)

·       Orthogonality (don’t make components dependent on other components)

·       Reversibility (techniques that help insulate your projects from their changing environment)

·       Tracer bullets (try them first)

·       Prototypes and Post-it-notes (make models, estimate)


Chapter 3: The Basic Tools


In this chapter the authors suggest some criteria on selecting tools for a pragmatic programmers day-to-day tasks. The authors also describe why you should master on those to be a pragmatic programmer.

·       The power of plain text (Markup)

·       Shell games (*nix)

·       Power Editing (IDE, keyboard shortcuts)

·       Source Code Control (Git/SVN, Github/BitBucket)

·       Debugging (XDebug)

·       Text Manipulation (Perl)

·       Code Generators (Scaffolding)


Chapter 4: Pragmatic Paranoia


In this chapter, the authors acknowledged the painful truth that no software is perfect and provide some ideas on how to find and fix errors as early as possible and minimize the effect of errors that make it into production code. Section headers are:

·       Design by Contract (build, what you’ve been asked for)

·       Dead Programs Tell No Lies (do not damage while working the bugs out)

·       Assertive Programming (assertions – write code that verifies your assumptions)

·       Exceptions (when to through)

·       How to Balance Resources (destruct anything allocated)


Chapter 5, Bend, or Break:


The chapter covers some techniques for writing code that is easily maintainable and modifiable (as flexible, as possible – according to the author). Also discussed how to reduced coupling in your code (both physical and temporal), using metadata instead of hard coding configurations, using blackboards, and different ways of handling events including the publish/subscribe model and MVC.

·       Decoupling and the Law of Demeter (SoC – Separation of Concerns)

·       Metaprogramming (Move details out of the code, make things configurable)

·       Temporal Coupling (tick before tock? Analyze the workflow)

·       It’s just a view (MVC)

·       Black-boards (meeting place for modules which are decoupled from each other completely, to exchange data anonymously and asynchronously)


Chapter 6, While You Are Coding:


The chapter rails against the notion that coding should be approached as a mechanical process that converts a detailed design into source code. The authors suggest that mindlessly translating a design into code is a primary factor in creating poorly written, and sometimes actually wrong, software and that programmers must constantly be thinking about what they are writing and how it effects the rest of the system.

·       Programming by Coincidence (code might work, but there is no particular reason why)

·       Algorithm Speed (estimate the speed of code)

·       Refactoring (do it often)

·       Code that’s easy to test (yes!)

·       Evil wizards (don’t use them)


Chapter 7, Before the Project,


The chapter opens the myth of requirement engineering. It focuses our attention on some key things that need to be addressed at the very beginning of a project like eliciting and documenting requirements, dealing with constraints, producing specifications, and development methodologies.

·       The Requirements Pit (simply listening to users is not enough. Find the reason behind their necessity, think like them)

·       Solving Impossible Puzzles (they aren’t as difficult as they appear to be)

·       Not until you’re ready (don’t jump into coding)

·       The specification trap (advantages of specification, clear the doubt nuggets)

·       Circles and arrows (no formal method can replace thinking. Ask, communicate back and forth)


Chapter 8, Pragmatic Projects:


Yes, teamwork rocks! The chapter discusses how groups of pragmatic programmers can work together as a team, automating everything (well, almost everything), various types of tests that should be in place (all automated, of course), and managing the customer's expectations.

·       Pragmatic Teams (how to)

·       Ubiquitous Automation (automate everything)

·       Ruthless testing (test early, test often, test automatically)

·       It’s All Writing (documentation is the key)

·       Great Expectations (how to delight the client)

·       Pride and Prejudice (sign your work!)


Add new comment