The Pragmatic Programmer

Summary

Quotes

But 20 years is many lifetimes in terms of software. Take a developer from 1999 and drop them into a team today, and they’d struggle in this strange new world. But the world of the 1990s is equally foreign to today’s developer. The book’s references to things such as CORBA, CASE tools, and indexed loops were at best quaint and more likely confusing. At the same time, 20 years has had no impact whatsoever on common sense. Technology may have changed, but people haven’t. Practices and approaches that were a good idea then remain a good idea now. Those aspects of the book aged well.

Great lawns need small amounts of daily care, and so do great programmers. Management consultants like to drop the word kaizen in conversations. “Kaizen” is a Japanese term that captures the concept of continuously making many small improvements.

It is your life. You own it. You run it. You create it. Many developers we talk to are frustrated. Their concerns are varied. Some feel they’re stagnating in their job, others that technology has passed them by. Folks feel they are under appreciated, or underpaid, or that their teams are toxic. Maybe they want to move to Asia, or Europe, or work from home.

Responsibility is something you actively agree to. You make a commitment to ensure that something is done right, but you don’t necessarily have direct control over every aspect of it. In addition to doing your own personal best, you must analyze the situation for risks that are beyond your control. You have the right not to take on a responsibility for an impossible situation, or one in which the risks are too great, or the ethical implications too sketchy. You’ll have to make the call based on your own values and judgment.

There are many factors that can contribute to software rot. The most important one seems to be the psychology, or culture, at work on a project.

Don’t leave “broken windows’’ (bad designs, wrong decisions, or poor code) un-repaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then board it up. Perhaps you can comment out the offending code, or display a “Not Implemented” message, or substitute dummy data instead. Take some action to prevent further damage and to show that you’re on top of the situation.

We like to think of all the facts programmers know about computing, the application domains they work in, and all their experience as their knowledge portfolios. Managing a knowledge portfolio is very similar to managing a financial portfolio: Serious investors invest regularly—as a habit. Diversification is the key to long-term success. Smart investors balance their portfolios between conservative and high-risk, high-reward investments. Investors try to buy low and sell high for maximum return. Portfolios should be reviewed and rebalanced periodically. To be successful in your career, you must invest in your knowledge portfolio using these same guidelines.

A thing is well designed if it adapts to the people who use it. For code, that means it must adapt by changing. So we believe in the ETC principle: Easier to Change. ETC. That’s it. As far as we can tell, every design principle out there is a special case of ETC. Why is decoupling good? Because by isolating concerns we make each easier to change. ETC. Why is the single responsibility principle useful? Because a change in requirements is mirrored by a change in just one module. ETC. Why is naming important? Because good names make code easier to read, and you have to read it to change it. ETC!

Not All Code Duplication Is Knowledge Duplication - As part of your online wine ordering application you’re capturing and validating your user’s age, along with the quantity they’re ordering. According to the site owner, they should both be numbers, and both greater than zero. So you code up the validations:   def validate_age(value): validate_type(value, :integer) validate_min_integer(value, 0) def validate_quantity(value): validate_type(value, :integer) validate_min_integer(value, 0) During code review, the resident know-it-all bounces this code, claiming it’s a DRY violation: both function bodies are the same. They are wrong. The code is the same, but the knowledge they represent is different. The two functions validate two separate things that just happen to have the same rules. That’s a coincidence, not a duplication.

Suppose you have a cat in a closed box, along with a radioactive particle. The particle has exactly a 50% chance of fissioning into two. If it does, the cat will be killed. If it doesn’t, the cat will be okay. So, is the cat dead or alive? According to Schrödinger, the correct answer is both (at least while the box remains closed). Every time a subnuclear reaction takes place that has two possible outcomes, the universe is cloned. In one, the event occurred, in the other it didn’t. The cat’s alive in one universe, dead in another. Only when you open the box do you know which universe you are in.

Tracer bullets are loaded at intervals alongside regular ammunition. When they’re fired, their phosphorus ignites and leaves a pyrotechnic trail from the gun to whatever they hit. If the tracers are hitting the target, then so are the regular bullets. Soldiers use these tracer rounds to refine their aim: it’s pragmatic, real-time feedback under actual conditions.

Catch and Release Is for Fish Some developers feel that is it good style to catch or rescue all exceptions, re-raising them after writing some kind of message.

Finish What You Start This tip is easy to apply in most circumstances. It simply means that the function or object that allocates a resource should be responsible for deallocating it.

Just as the car headlights have limited throw, we can only see into the future perhaps one or two steps, maybe a few hours or days at most. Beyond that, you can quickly get past educated guess and into wild speculation. You might find yourself slipping into fortune telling when you have to: Estimate completion dates months in the future Plan a design for future maintenance or extendability Guess user’s future needs Guess future tech availability But, we hear you cry, aren’t we supposed to design for future maintenance? Yes, but only to a point: only as far ahead as you can see. The more you have to predict what the future will look like, the more risk you incur that you’ll be wrong.

Tell, Don’t Ask This principle says that you shouldn’t make decisions based on the internal state of an object and then update that object. Doing so totally destroys the benefits of encapsulation and, in doing so, spreads the knowledge of the implementation throughout the code.

Don’t Chain Method Calls Try not to have more than one “.” when you access something. And access something also covers cases where you use intermediate variables, as in the following code:   #

# This is pretty poor style  
amount = customer.orders.last().totals().amount;
# and so is this…
orders = customer.orders;
last = orders.last();
totals = last.totals();
amount = totals.amount;

This is a very powerful abstraction: we no longer need to think about time as being something we have to manage. Event streams unify synchronous and asynchronous processing behind a common, convenient API.

import * as Observable from 'rxjs'
import { mergeMap }    from 'rxjs/operators' 
import { ajax }        from 'rxjs/ajax'
import { logValues }   from "../rxcommon/logger.js"
let users = Observable.of(3, 2, 1)
let result = users.pipe(   
  mergeMap((user) => ajax.getJSON(`https://reqres.in/api/users/${user}`))   
)
result.subscribe(
  resp => logValues(JSON.stringify(resp.data)),   err  => console.error(JSON.stringify(err))   )

You might think that this is just syntactic sugar. But in a very real way the pipeline operator is a revolutionary opportunity to think differently. Using a pipeline means that you’re automatically thinking in terms of transforming data; each time you see |> you’re actually seeing a place where data is flowing between one transformation and the next.

Use Mixins to Share Functionality Inheritance Is Rarely the Answer We’ve had a quick look at three alternatives to traditional class inheritance: Interfaces and protocols Delegation Mixins and traits Each of these methods may be better for you in different circumstances, depending on whether your goal is sharing type information, adding functionality, or sharing methods. As with anything in programming, aim to use the technique that best expresses your intent.

In the actor model, there’s no need to write any code to handle concurrency, as there is no shared state. There’s also no need to code in explicit end-to-end “do this, do that” logic, as the actors work it out for themselves based on the messages they receive.

Only human beings can look directly at something, have all the information they need to make an accurate prediction, perhaps even momentarily make the accurate prediction, and then say that it isn’t so.

You refactor when you’ve learned something; when you understand something better than you did last year, yesterday, or even just ten minutes ago. Perhaps you’ve come across a stumbling block because the code doesn’t quite fit anymore, or you notice two things that should really be merged, or anything else at all strikes you as being “wrong,” don’t hesitate to change it.

Build End-to-End, Not Top-Down or Bottom Up We strongly believe that the only way to build software is incrementally. Build small pieces of end-to-end functionality, learning about the problem as you go. Apply this learning as you continue to flesh out the code, involve the customer at each step, and have them guide the process.

We have an instance method that discounts an order  public void deductPercent ( double amount ) First , deductPercent is what it does and not why it does it . Then the name of the parameter amount is at best misleading : is it an absolute amount , a percentage ? Perhaps this would be better : public void applyDiscount ( Percentage discount )

In 1967 , Melvin Conway introduced an idea in How do Committees Invent ? [ Con68 ] which would become known as Conway’s Law : Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations .

We are uncovering better ways of developing software by doing it and helping others do it . Through this work we have come to value : Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is , while there is value in the items on the right , we value the items on the left more .

No Broken Windows Quality is a team issue . The most diligent developer placed on a team that just doesn’t care will find it difficult to maintain the enthusiasm needed to fix niggling problems . The problem is further exacerbated if the team actively discourages the developer from spending time on these fixes .

My thoughts

Questions you should be able to answer after reading this book