"The Pragmatic Programmer" Review

This book is so famous as one of “programmer must read books”, and it’s been widely recommended for good reasons. It covers varies crucial topics to help programmer grow and succeed, guides you on how to think about your work, and provides practical suggestions on how to approach the common challenges. Reading it refreshes all the lessons I learned over the past few years in industry, and puts some new enlightenments on me.

What resonated with me most is the “It’s a continuous process” in preface.

A tourist visiting England’s Eton College asked the gardener how he got the lawns so perfect. “That’s easy,” he replied, “You just brush off the dew every morning, mow them every other day, and roll them once a week.”

“Is that all?” asked the tourist. “Absolutely,” replied the gardener. “Do that for 500 years and you’ll have a nice lawn, too.”

Keep making small process every day is exactly what I learned recently from a senior peer (E8), when I asked him how could him accomplish so many big impact projects. He is busier than most of engineers as he has so many responsibilities and meetings, but he can always find time to make small commits and drive projects forwards. I’m amazed by what he did and start to take actions on this advice, by trying to making small changes and improvements everyday not matter how busy I am on things like meetings and supports. Only few days later I start to feel the good difference, and so does my team.
One thing worth to mention is: people may already be aware of this plain advice, but true belief in its value and actions on it is the secret to see the effect.

Another interesting philosophy is “be a catalyst for change”. People find change difficult, sometimes due to fear by natural. But most people find it easier to join an ongoing success. So, we should try to become the solder who start a soup with stone, and let people put their staffs in to complete the soup. Be the one to show people a glimpse of the future and you’ll get them to rally around.

Apart from all the inspiring philosophy, some practical tips are fresh to me.

One is “what to say when asked for an estimate”? You should always say “I’ll get back to you.”

• Then the first thing is to ask people who did similar things to help estimate.
• For new projects nobody had experience, you need to break it down to modules and iterate.
• Thinking through biggest risk and provide both optimistic and pessimistic estimation.
• Adjust the estimation timely during the iteration. Take retrospect on the inaccuracy, and share the learning.

You almost always get better results if you slow the process down and spend some time going through things like requirements, risk, design/implementation/integrate, user validation… Estimates given at the coffee machine will (like the coffee) come back to haunt you.
Also note the time unit you choose matters. Using days to estimate big projects implies a higher degree of accuracy than you feel. So if a project will take 125 days, you might want to deliver an estimate of “about 6 month”.

Another interesting tip is “don’t outrun your headlights”.

Car headlights have a certain limited range, known as the throw distance. Past that point, the light spread is too diffuse to be effective. In addition, headlights only project in a straight line, and won’t illuminate anything off-axis, such as curves, hills, or dips in the road.

Stop or steer in time in response to the headlight’s illumination.
In software development, our headlights are similarly limited. We can’t see too far ahead into the future, and the future off-axis you look, the darker it gets. So pragmatic programmers have a firm rule:

Tip 42 Take small steps - always

Always take small, deliberate steps, checking for feedback and adjusting before proceeding.

I will stop here because what I consider delicious may not be your flavor. Overall I think the 100 useful tips in this book could benefit every programmer. It will help entry level engineers to set the right mindset and basic skills, and help seniors recap the essentials and calibrate. It’s surely a fun and inspiring read to me, and I want to finish by the last tip about programmer’s attitude to future

It’s your imagination, your hopes, your concerns that provide the pure thought-stuff that builds the next twenty years and beyond.

You are building the future, for yourselves and for your descendants. Your duty is to make it a future that we’d all want to inhabit. Recognize when you’re doing something against this ideal, and have the courage to say “no!” Envision the future we could have, and have the courage to create it. Build castles in the air every day.

We all have an amazing life.