The Pragmatic Programmer

TLDR:

This book is a must read for software engineers. On any classic book list, it is suggested for a reason. It is fully of principles and ideas that are timeless and useful. The big takeaway is that software engineering is a craft and your role is a craftsman.

My Steps to Implement Lesson from the Pragmatic Programmer

This is a checklist of actions that I will try to implement on a daily basis working as a software engineer.

Here's my list for Deep Work.

• [x] Schedule Deep Work Blocks in diary daily.
• [x] Eliminiate Distraction.
• [x] Set Clear Goals for each Deep Work Session.
• [x] Limit internet use in deep work blocks.
• [x] Keep a tally of Deep Hours completed.
• [x] Batch tasks

I will expand on each of these below. This is just my approach. Feel free to change this however you like.

1. Schedule Deep Work Blocks

The aim here is to have sessions, ideally 90 minutes long where I can work uninterrupted. The focus here is on tasks like coding, debugging or learning new technologies. I have a macbook. I set a countdown timer on a spare monitor screen and I try to stay on that single task for the length of the timer.

2. Eliminate Distraction

This is easier said than done. Task switching and interruption have a terrible effect on concentration, way more than we realise during the day. There is a heavy price to pay for interruption. I think the best way to eliminate distraction is by choosing an environment that facilitates this. Some things that help me are: working in a quiet space, wearing noise cancelling headphones and turning notifications off.

3. Set Clear Goals for Each Deep Session

This will help in 2 ways. The first way is simple. I simply ask, did I achieve what I planned to achieve. The second way is a little different.

By estimating what I can get done in a block, I will improve on my estimations of how long certain tasks take. As I am pretty new to working as a software engineer, this is helpful to know.

What are some examples of targets I might have for a session? In my case examples might be to create an api, write a block of code or format documentation. At the end of a session it's easy to check whether I did this or not.

4. Limit internet use in deep work blocks.

It's so easy to look up one topics on Youtube and end up in a deep dive about 15th century history or how Da Vinci designed a helicopter. Some steps that help me are having Co-pilot or something like chat gpt to do an internet search. The interfaces lend themselves to staying on point. For other things that I might need to look up, I will use a tried and tested approach. Pen and paper. If something random pops into my head, I just jot it down on pen and paper. I can just look it up later.

5. Keep a tally of deep hours completed

You can get "good enough" at almost anything in 20 hours of focused effort. The problem is, most people spend years delaying the first hour".

• Alex Hormozi

This quote cuts through so much noise. If you find yourself not progressing as much as you would like, start counting the hours you are directly spending on that thing. Deliberate practice is where you are working on a task that is right at your limits of ability. Once you have 100 hours of deliberate practice done, you will notice the needle moving. I am the same on this as anybody. Plus having a way to tally an input each week is a great way to think about beating it the next.

6. Batch tasks

How many times a day do you check email at work? I wouldn't like to estimate. Most of us are the same. But every time you ping off a quick reply, you suffer from task switching and lose your train of thought. I've already discussed this above. Most emails are shallow work. By batching tasks like that together, you are limiting their effect on work areas that actually move the needle.

The Pragmatic Programmer is a ‘must read’ engineering book and I can see why.

For me, I find technical books hard to read. It’s often worth re-reading books over time as my knowledge grows from previous experience gained. I think The Pragmatic Programmer is that type of book and one that I will revisit over time.

Here are some of my notes and takeaways from the book.

Favourite quote:

“We who cut mere stones must always be envisioning cathedrals - Quarry worker’s creed”

• Andy Hunt

Practice to take away:

Kaizen - a Japanese term that captures the concept of continuously making small improvements

Favorite idea:

Don’t leave “broken windows” (bad designs, wrong decisions or poor code) unrepaired. Fix small bugs as soon as they are discovered. If there is not time to fix it properly, then board it up. Take some action to prevent further damage.

Biggest takeaway:

Your most important strategic asset: learn to learn

Other ideas from the book worth a mention

Preface

There is no best solution. Think about software engineering as craftsmanship.

Chapter 1 - Pragmatic Progamming

Team trust is essential. Provide options, not excuses. Tip 5: no broken windows. Good enough software. Learn to learn.

Chapter 2 - A Pragmatic Approach

Good design is easy to change. Tip 21: Prototype to learn. Give estimates in relative terms, days, weeks, months. Keep track of estimates, find out why they went wrong.

Chapter 3 - The Basic Tools

Tip 25 - Keep knowledge in plain text. Keep an engineering book

Chapter 4 - Pragmatic Paranoia

Tip 42 - Take small steps. Go slow to go fast.

Chapter 5 - Bend or break

All programs transform data. Converting input to output. Figure out what’s the input and what’s the output. Draw them if needed. When we think of programs as something that transforms input into output, many of the details we previously worry about just evaporate. The structure becomes clearer, the error handling consistent and coupling drops way down.

Chapter 7 - While You are Coding

When stuck, ask the duck Tip 34: Don’t assume, prove it. Tip 65: Refactor early, refactor often Test Driven Development

Chapter 8 - Before the Project

Tip 75: No one knows what exactly they want. Tip 76: Programmers help people understand what they want. Tip 78: Work with a user to think like a user.

Chapter 9 - Pragmatic Projects

Tip 84: Maintain small, stable, teams. Tip 85: Schedule it to make it happen. Good communication, instant and frictionless.

All these lessons are taken from the book.