After having it on my to-do and wish list for about a year, I finally ordered and read ‘The Pragmatic Programmer‘. It was a really interesting read. I was able to relate to many of the chapters in it. The book talks about how programmers can rise from journeymen to masters.
The book contains many (70 to be precise) one line nuggets of programming wisdom. The authors themselves have made these available online here. Coding Horror (Jeff Atwood) also has a handy quick reference to many of the ideas mentioned in the book – link.
Even though the tips by themselves are great, I would recommend reading the whole book rather than reading them in isolation. What makes the book great is the way the authors presents the ideas in easy-to-understand ways, often using small stories and analogies wherever applicable. Some of the interesting ones below:
The Broken Window Theory (wiki):
Consider a building with a few broken windows. If the windows are not repaired, the tendency is for vandals to break a few more windows. Eventually, they may even break into the building, and if it’s unoccupied, perhaps become squatters or light fires inside.
This is how human psychology works. The same is applicable in terms of software quality. If we introduce entropy into the system (in the form of poor code, lack of unit or integration testing, poor review practices etc.), it will spread rapidly and destroy the system. The opposite can also happen where once we establish an immaculate system and great practices, individuals would try not to be the first to lower the standards.
The Stone Soup
The story can be read here. The authors have lessons from both sides of the story:
Tip: Be a Catalyst for Change
Like how the soldiers (or travellers as per the wiki) influenced and brought about change gradually, if we show people a glimpse of the future, they will be more willing to participate.
Tip: Remember the big picture
Villagers fall for the stone trick since they failed to notice gradual changes. This can happen to our software systems and projects as well. The next point is related.
The Boiled Frog
If a frog is put suddenly into boiling water, it will jump out, but if it is put in cold water which is then brought to a boil slowly, it will not perceive the danger and will be cooked to death.
The story is often used as a metaphor for the inability or unwillingness of people to react to or be aware of threats that rise gradually. Gradual increases in CPU/memory utilisation or service latencies which eventually bring down systems come into mind here. Gradual feature-creep and/or project delays which eventually add up to failed projects are also examples.
Some of the programming pearls of wisdom that I found most compelling were:
The Requirement Pit
Requirements are often unclear and mixed with current policies and implementation. We must capture the underlying semantic invariants as requirements and document the specific or current work practices as policy.
Tip: Abstractions live longer than details
The Law of Demeter for Functions (wiki)
An object’s method should call only methods belonging to:
- Itself
- Any parameters passed in
- Objects it creates
- Component objects
Following this law helps us write ‘shy’ code which minimises coupling between modules.
Listing other tips below:
- DRY principle – Don’t Repeat Yourself. Avoid duplication of code or documentation.
- Orthogonality – Decouple systems into independent components.
- Always use version control (even for documents, memos, scripts – for everything)
- Use Domain Specific Languages (DSLs) and Code Generators to simply development
- Ruthless testing – Test early, test often, test automatically
- Use prototypes and tracer bullets wherever and whenever possible
On stranger tides 