The Pragmatic Programmer: From Journeyman to Master

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

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 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.

by mredding   2018-02-16

I can't speak of a specific book that is a comprehensive history of computing, but I will speak to books that speak of our culture, our myths, and our hero's.

Hackers and Painters , by Paul Graham. People are polarized about the man, whether he's too "pie in the sky" - full of shit and ego, or if he speaks as an ambassador to our most optimistic ideals of our (comp-sci) culture. The contents of this book is a collection of his essays that are inspirational. It made me forego the societal pressures within our culture and reject popular opinion because it is merely popular and just an opinion, which is a virtue no matter who you are, where you are, or what you do. All these essays are on his website, though. If you want to review them, I recommend Hackers and Painters (the essay), What You Can't Say, Why Nerds are Unpopular, and The Age of the Essay; his oldest essays are at the bottom of the page and go up - he writes about what he's thinking about or working on at the time, so you'll see the subject matter change over time. So much of this will have direct application to his middle school and high school life. I cannot recommend this book, and the rest of his essays, enough.

If he wants to get into programming, I recommend The Pragmatic Programmer . This book talks about the software development process. I'm not going to lie, I don't know when best to introduce this book to him. It's not a hard read whatsoever, but it's abstract. I read it in college in my first months and said, "Ok," and put it down. Approaching the end of college and my first couple years in my profession, I would reread it ever 6 months. It's a kind of book that doesn't mean anything, really, without experience, without having to live it, when he has an obligation to his craft, his profession. I tell you about this one since you're asking about books to tell him, because this isn't something someone would normally come up across without being told about it.

The Cathedral and the Bazaar is a telling book about the cultural differences between the proprietary monoliths like Apple and Microsoft, and the Free and Open Source Software communities that back such popular software as Linux (the most popular operating system on the planet, running on all top 500 super computers, most server computers on the internet, and all Android phones) and Chrome(the worlds most popular web browser). Indeed, this book directly reflects the huge cultural battle that was duked out in the field, in the industry, and in the courts from the mid-90s and into the 2000s. It advocates helping the community, contributing to something larger than yourself, and that none of us are as good as all of us. To paraphrase Linus Torvalds(inventor of Linux) "Given enough eyeballs, all bugs are shallow."

It's important to know who the hero's are in our culture, and they are diverse and varied, they're not just computer scientists, but mathematicians, physicists, philosophers, science fiction writers, and more. I would find a good book on Nicola Tesla, since he invented basically everything anyway (Thomas Edison was a great businessman, but a bit of a tosser), Richard Feynman was a physicist who is still celebrated in his field, and he even worked for Thinking Machines, back in the day, which was a marvel of it's time. Seymour Cray founded Cray Supercomputers and they have a lasting legacy in the field, a biography on that would be interesting. A biography on Symbolics and their Lisp Machines will make him yearn to find one still functioning (a rare gem that crops up every now and again, though he can run one in an emulator), and about the "AI Winter", a significant historic era (note: the AI Winter is over, and we are in spring, the history is both compelling and enthralling). Anything Issac Asimov published (in nearly every category of the dewy decimal system) is also compelling, and hardly dated. In fact, he's the originator of a lot of modern sci-fi. Charles Babbage invented the modern computer (though it was entirely mechanical in his day, and it wasn't actually built until 1996-2002) and Ada Lovelace was the worlds first computer programmer. A woman! Speaking of women, and it's worth young men learning this about our history, Grace Hopper was a military computer engineer who invented the term "bug".

And speaking of women, someone I have respect for, especially if your boy wants to get into game development is Sheri Graner Ray's Gender Inclusive Game Design , which may be more appropriate when he's in high school, and I consider it required reading for anyone who wants to enter the gaming industry. The book lays out plainly how video games hyper-sexualize both women, and, for some reason surprisingly to many - men, it's disastrous effects it has for the game industry, the game market, and the gaming community, and insights on how we may combat it. I have seen colleagues (men) become indignant and personally offended at reading this book, but were absolutely humbled when they took the fight to Sheri directly (we had a few phone interviews with her, always fantastic). If your boy found a problem with this book, he would do well to read Paul Grahams essay on keeping his identity small... The subject matter is not a personal attack on the individual, but on the blight, and he would be better served finding himself on the right side of history with this one, it would serve him well if he were to pursue this craft, specifically, but also any forward facing media in general.

And I also recommend some good books on math. Algebra, linear algebra, calculus, and statistics. You can get very far, lead an entire career unto retirement without knowing anything more than arithmetic and basic, basic algebra, but he could only serve himself well if he makes the decision that he is going to like maths and chooses to willfully become good at it. Outside the context of school and terrible teachers, it's actually an enthralling subject. Just get him a copy of Flatland, Flatterland, and Sphereland. Try this , the book is the narrative of some witty laymen who discover a whole branch of mathematics from first principles, the surreal numbers, an extension of imaginary numbers. It's really quite good, but might keep him occupied for a couple years in high school.

I should stop here or I never will.

by Ispamm   2018-02-16

Don't give up just yet, keep looking. Do you have a portfolio? if not try to work on a project of your own so you can have something to show. And if you are considering improving your java skills try work with libraries like:

  • Dagger2
  • RxJava
  • Retrofit
  • Architecture Components
  • Kotlin

With spare time I would also recommend you to read: