The Pragmatic Programmer: From Journeyman to Master

Category: Computer Science
Author: Andrew Hunt
All Hacker News 10
This Year Reddit 41
This Month Reddit 2

About This Book

Straight from the programming trenches, The Pragmatic Programmer cuts through the increasing specialization and technicalities of modern software development to examine the core process--taking a requirement and producing working, maintainable code that delights its users. 


This book covers topics ranging from personal responsibility and career development to architectural techniques for keeping your code flexible and easy to adapt and reuse.


Read this book, and you'll learn how to

  • Fight software rot;
  • Avoid the trap of duplicating knowledge;
  • Write flexible, dynamic, and adaptable code;
  • Avoid programming by coincidence;
  • Bullet-proof your code with contracts, assertions, and exceptions;
  • Capture real requirements;
  • Test ruthlessly and effectively;
  • Delight your users;
  • Build teams of pragmatic programmers; and
  • Make your developments more precise with automation.


Written as a series of self-contained sections and filled with entertaining anecdotes, thoughtful examples, and interesting analogies, The Pragmatic Programmer illustrates the best practices and major pitfalls of many different aspects of software development. Whether you're a new coder, an experienced programmer, or a manager responsible for software projects, use these lessons daily, and you'll quickly see improvements in personal productivity, accuracy, and job satisfaction. You'll learn skills and develop habits and attitudes that form the foundation for long-term success in your career. You'll become a Pragmatic Programmer.


What others in the trenches say about The Pragmatic Programmer...

“The cool thing about this book is that it’s great for keeping the programming process fresh. The book helps you to continue to grow and clearly comes from people who have been there.”

Kent Beck, author of Extreme Programming Explained: Embrace Change

“I found this book to be a great mix of solid advice and wonderful analogies!”

Martin Fowler, author of Refactoring and UML Distilled

“I would buy a copy, read it twice, then tell all my colleagues to run out and grab a copy. This is a book I would never loan because I would worry about it being lost.”

Kevin Ruland, Management Science, MSG-Logistics

“The wisdom and practical experience of the authors is obvious. The topics presented are relevant and useful.... By far its greatest strength for me has been the outstanding analogies—tracer bullets, broken windows, and the fabulous helicopter-based explanation of the need for orthogonality, especially in a crisis situation. I have little doubt that this book will eventually become an excellent source of useful information for journeymen programmers and expert mentors alike.”

John Lakos, author of Large-Scale C++ Software Design

“This is the sort of book I will buy a dozen copies of when it comes out so I can give it to my clients.”

Eric Vought, Software Engineer

“Most modern books on software development fail to cover the basics of what makes a great software developer, instead spending their time on syntax or technology where in reality the greatest leverage possible for any software team is in having talented developers who really know their craft well. An excellent book.”

Pete McBreen, Independent Consultant

“Since reading this book, I have implemented many of the practical suggestions and tips it contains. Across the board, they have saved my company time and money while helping me get my job done quicker! This should be a desktop reference for everyone who works with code for a living.”

Jared Richardson, Senior Software Developer, iRenaissance, Inc.

“I would like to see this issued to every new employee at my company....”

Chris Cleeland, Senior Software Engineer, Object Computing, Inc.

“If I’m putting together a project, it’s the authors of this book that I want. . . . And failing that I’d settle for people who’ve read their book.”

Ward Cunningham


by zonovar   2022-02-09
The Pragmatic Programmer

by Heartomics   2021-12-10

It would be hard to evaluate yourself. It's probably best to link your Github work to someone and ask for their opinion.


The biggest hurdle is to accept that there's a Pythonic way of doing things.

I think a lot of people's first step to becoming Pythonic is by the way of using List Comprehensions.

Then there's generators, decorators, itertools, functools, collections, etc.

What it takes to be an Expert in Python

I'm sure his Python skill is amazing; I was too distracted by his VIM skill to pay attention.

These are language-specific things but it sounds as though you might want to get familiar with proper Software Engineering principles. Recognizing code smells and trade-offs between different Data Structures and Sorting Algorithms. You can start off with this excellent book on being pragmatic.

Pragmatic Programmer

Here are some youtube links where you can follow along and maybe even adopt their coding style. I don't remember if they are Pythonic or whatnot but I would guess that they are. They focus on projects you would have an interest in.


by ElizaTrollingYa   2021-12-10

Operating Systems Foundations

keep yourself busy. virtual labs read tons and tons of information

Valuable book someone recommended to me that I make myself review now and again is:

by busbus   2021-10-21
I can’t tell you what is that website, but the concept of broken window reminds me a book that talked about it:

(No affiliation)

by valbaca   2020-08-14
Here are my three:

"Unwritten Laws of Engineering"

Originally meant for mechanical engineers, it provides specific and general non-technical career advice. It focuses on what we call “soft” skills today. This field puts so much weight into technical prowess that we often think of these “soft” skills as somehow beneath the “hard” skills. Nothing could be further from the truth. If you don’t spend time on learning how to navigate your career, you’ll be as well off as a dragster on the backroads: you’ll get nowhere fast. I only wish I could have read this book sooner; it would’ve saved me a lot of trouble early on.

"Becoming a Technical Leader"

Don’t let the title fool you: this is not just for people planning on becoming a “Tech Lead.” It’s for anyone in the tech field, period. If you pickup this book you must work through the exercises to get the full effect. It will be worth it. It’ll be like having your own therapist, life coach, and mentor, except that it’s just you and a notebook answering very important questions.

"The Pragmatic Programmer"

I consider this book 10x better than Clean Code and Code Complete combined! (Though that may just be because I read PragProg first?) As the name suggests, this book provides more tactics advice but also gives great career advice too. The most famous is to “learn a new language each year.” This kind of advice seems a bit much, but over my career I’ve had to write in over a dozen different languages, even though 90% of the code I’ve written has been in just one language, the ability to pickup new languages quickly and easily is a solid skill to have. And that’s just one particular tip from this book.

(These are excerpts from my suggested reads blog post:

by jdmas   2019-11-17

Maybe this will help.

by BinxyPrime   2019-11-17

you could probably just read one good book about code architecture, the truth is no architecture is perfect, you always make trade offs between time, money, readability, performance.

I hear this one mentioned very often on the podcast coding blocks pragmatic programmer

But i would definitely ask around before dropping $50 on a book. Maybe read some of it at a book store and see if you like it first.

by anonymous   2019-07-21

To be honest, if all of your experience is with PHP, you probably want to focus on OOP (Object-Oriented Programming) in general, rather than the specific syntax and frameworks of C#. The language itself shouldn't be massively alien to you, but the idioms and standard approaches to many problems likely will be.

Two books I would recommend for anyone starting on an OOP language:

  • The Pragmatic Programmer - An invaluable reference for any programmer, but it really does focus on static OOP languages such as C#.
  • Head First Object Oriented Analysis and Design - A java book, ironically, but the concepts taught within are perfectly applicable to C#, and it's an excellent, clear, easy to follow introduction on the proper design of object oriented software.
by anonymous   2019-07-21

Short term help: Check your output, do the values of x and y vary as expected? are they actually used during plotting? Use a debugger to step through your code. Then come back with a more focused questions.

Mid term (within the next two days): Please buy and read the following two books:

Classes as long as the one you posted are not acceptable, and make it next to impossible to understand the revlevant part. This is the reason why you received the down votes I'd guess.

by anonymous   2019-07-21

In general for the first version I write the class file in the .h and when done I copy the method declarations to the .cpp and there change them into definitions (i.e. methods and their bodies). In this phase I declared only the public methods of the class, because I'm more concerned about its interface than the internals.

Later, when I'm implementing the public methods, if I need a new private method I begin by calling it wherever it's needed, so I get the parameters well defined. Then I write its declaration in the .h and go back to the .cpp to write its body.

It may be of interest to you the concepts of Tracer Bullet Design, which fits well with this workflow. It's described in the book The Pragmatic Programmer:

This page contains a brief description

by scarface74   2019-01-03
(None of these are affiliate links)

And just because it’s asked at every interview.

I’m focused on AWS these days, but a lot of these principals are universal.

by TheSaurfangDogma   2018-11-10

The Pragmatic Programmer

I read this book after learning my first language (Python) and it really helped generalize what I knew and instill a mindset that made it much easier to ground myself in other languages.

by fijiproggit   2018-11-10
by samort7   2018-11-10

For anyone looking for general book suggestions, I always recommend they go with the classics:

EDIT: Updated with some more books I forgot initially, and links to the latest versions

General Computing

Computer Science

Software Development

Case Studies








Linux Shell Scripts

Web Development

Ruby and Rails


by tenpoundhammer   2018-09-23
Adding to projects without authorization, is extremely popular all around, if the commit/pr is useful. My boss sees it as taking initiative, helping others, and broadening my skill set. Other teams see it as getting free work.

Even when my contributions suck people think of it as a positive and often teach me the right to do the code or explain why the change is not necessary.

As far as books go I don't have anything to recommend. For me improving fundamentals was really about figuring out what I didn't understand and diving in to learn it. I prefer online materials over books but one book I have read that I thought was great is 'the pragmattic programmer'.

by fdsvnsmvas   2018-09-13
Thanks everyone, the comments are much appreciated. Here's a list of books and other media resources recommended so far in the thread:

Robert C. Martin, Clean code:

Vaughn Vernon, various: 2

Clean coder:

Hitchhiker's Guide to Python:

John Ousterhout, A Philosophy of Software Design: This one looks particularly interesting, thanks AlexCoventry!

Kent Beck, Test Driven Development:

Dan Bader, Python Tricks: The Book:

Svilen Dobrev, various:

by PM_me_goat_gifs   2018-03-19

First read this blog post about UI design. A codebase is a UI. It is the UI you use to get your job done.

It seems to me that the problem is that you don't have a good mental model of the codebase and its pieces. Part of this is that the codebase could be better structured. It always can be. But part of the problem is that it takes deliberate effort to build a clear mental model. It is easy to spend a bunch of time fruitlessly poking at things if you don't know how to spend that effort. So What is the shape of that deliberate effort?

It depends on the framework. If you're working on a Model-View-Controller "CRUD" app, you want to start by looking at the API interface: what paths/HTTP methods do what? The reference docs for your external stakeholder should say this. Then, you'll want to look at the models. Print out the structure.sql or all the files and draw out a crows foot diagram. From there, look at the controllers/routes and tell the story of what they do. Use the automated tests as a guide.

If you're not doing a CRUD app, you want to find some advice that is shaped like it. What files to read first? What diagrams are useful to draw? etc.

> I also take a lot of notes and write down what people say, seems to have been helping

This is a pointer toward a different approach you can take to solving your problem. Make yourself a set of indexed notes that you can refer back to, as if you were studying for an exam.

  • When you ask for help, write an email rather than tapping a senior dev on the shoulder. This has 3 benefits:

1) In the course of writing the email, you make your question more coherent and by doing that, you stand a good chance of realizing the answer.

2) By writing down the questions, you can structure them in a way that makes them easier to answer. Given that your questions are likely complex and can have multiple parts, this is pretty impactful. more on asking good questions

3) By writing down a coherent and contextful question, you show respect for the senior dev's time because you've put in your time to make your query well-structured.

4) You can go back and re-read the answer or the question. You can ask follow-up questions when you don't understand things. You can incorporate the answers into your set of notes.

  • Use a program like Anki to make flashcards about the framework. Make flashcards that ask questions about where things go and where you would put things. Also, make flashcards that ask you to explain why certain design decisions were made.

  • Find a good book to read and work through about the framework. Either ask on slack or ask your manager or go to the relevant subreddit. There is great value in personal recommendations.

  • Know that it is normal to still feel that you have lots to learn. This is a craft and you won't be done practicing it until you retire. For a broader look at the craft, take a look at The Pragmatic Programmer .

  • And of course make sure you are getting good sleep and taking care of your body.

by maksa   2018-03-19

To je čest anti-pattern, dovedu se fazani da održavaju stare projekte da bi stare iskusne kuke Pravile Novo. Keč je što su fazani po prirodi stvari nespremni za tako nešto. Zasuti nekoga ko je do tad radio samo na sintetičkim fakultetskim projektima gomilom real life legacyja je ... upitna praksa, ali nije ni skroz glupa pošto je to bitan deo realnog programerskog života. Kako kaže onaj kliše: "prvih 10 napisanih linija su greenfield projekat, sve preko je legacy kod". Sve što te ne ubije te jača. (F. Niče)

Ako nemaš živog mentora, ili ti je mentor go qrac, ovo je verovatno sledeći najbrži put do sledećeg nivoa:

Knjiga jeste malo outdated po pitanju tehnologija, ali su principi i saveti odande svevremeni, dobri, i večiti.

by Pinski47   2018-03-19

There are two books I always recommend to anyone who is starting their Software Engineering career.

The Pragmatic Programmer: From Journeyman to Master

Clean Code: A Handbook of Agile Software Craftsmanship

Both of these books were recommended heavily to me when I joined the industry and I wish I would have read them sooner. They manage to boil down years of insight and experience into a couple of interesting and thought provoking reads. I always buy copies for my interns or college graduate level junior developers.

Also, don't be too embarrassed to ask questions of your co-workers. If someone makes a design decision and you don't know why, ask. Most developers don't mind answering questions if you frame it the right way. Always make it clear it's coming from a place of learning instead of a place where you are questioning their implementation and they will generally be happy to talk about it. The secret is, most developers love to talk about how smart they are. ;)

I would much rather have a junior developer working for me that is constantly inquisitive and shows they want to learn than a junior developer that says they can do something and a week later doesn't have anything to show for their time. Most developers I have worked with are reasonable and realize we all started not knowing how to do what we do. Not knowing something or being ignorant of something isn't a bad thing, we all have gaps in our knowledge. Being too stupid or proud to fix it though is a huge problem. You already recognize that there is a problem and are trying to fix it, that's half the battle right there.