I’ve begun rereading The Pragmatic Programmer. It was originally recommended to me by someone at my first job out of college, which was six years ago. Now I’m in a position where I’m the more experienced programmer working with younger programmers. It’s good time to pick up the book again and see if what lessons I’ve forgotten from it and what I can pass on to others.

As I’m read it I’m taking notes, especially around each of the tips. Presented here are my notes, copy and pasted. There will be eight of these posts, as the book has eight major sections and that’s how I’m dividing my notes. Hopefully you find this useful as an abbreviated guide to what the book teaches. If you haven’t read the book, pick up a copy and read it, because no notes can do it full justice.

 

A Pragmatic Programmer is:

Early adopter/fast adapter – ties into Jack of all trades – try lots of new things

Inquisitive – try lots of new things, always learning – never know when you will need the knowledge

Critical Thinker

Realist

Jack of all trades (specialize when need to, but keep abreast of developments)

 

Tip 1: Care About Your Craft

Tip 2: Think! About Your Work

Tip 2 follows from Tip 1

Be a craftsman. You may be part of a larger team, but in your individual work you can leave your mark.

If one builder of a cathedral doesn’t give a damn about his bricks, won’t that stand out when you marvel at the otherwise amazing building?

(To expand on the analogy used in the book)

Learning and improving is a continuous process. You get better one small step at a time.

So too, we’re learning this about software. Small steps lead to large improvements (continuous delivery anyone?)

Always be aware of the big picture in which you work – it informs your work and what you do.

And the big picture changes in scope – it’s your team, your company, your country, the human race, the universe. All apply, but how often do we think of each of these?

 

Tip 3: Provide Options, Don’t Make Lame Excuses

Take responsibility for your work, which means admitting when you are wrong and providing ways to fix things.

Also remember: if the situation you’re in is impossible, you can step away and not take responsibility – but don’t act like you are going to take responsibility only to bail later.

 

Tip 4: Don’t Live With Broken Windows

Simple idea: take care of your code. If you inherit bad code, clean it up. Maybe you can’t right away, but start. Put up signs that you are, so it is clear someone cares.

Then others will care to.

See Tip 1.

 

Tip 5: Be a Catalyst for Change

Sometimes to make change, you have to go rogue, which can be as simple as hiding your larger intentions while getting a project rolling.

 

Tip 6: Remember the Big Picture

The big picture is why you do the work you do. It’s easy to get caught up in the code, but if you don’t put things in context that’s when you build the wrong thing,

or you miss how things are changing around you.

 

Tip 7: Make Quality a Requirements Issue

Let the user decide when a piece of software is good enough – not everything needs to be gold plated.

Corollary: Ship Early, Ship Often

 

Tip 8: Invest Regularly in Your Knowledge Portfolio

Straight forward: Keep learning.

 

Tip 9: Critically Analyze What You Read and Hear

Learning doesn’t help you much if you don’t think about it.

See Tip 2.

 

Tip 10: It’s Both What You Say and the Way You Say It

Effective communication and persuasion take work. You’ll need to practice it just like you would practice a new coding skill.

 

[Author’s Note: This post edited on June 11th to improve formatting for easier reading from the original posting]