The Pragmatic Programmer: From Journeyman to Master

Author: Andrew Hunt
4.5
All Hacker News 10
This Year Reddit 41
This Month Reddit 4

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

The Pragmatic Programmer: From Journeyman to Master

4.5

Review Date:

Comments

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

Employment

Language-Specific

C

Python

C#

C++

Java

Linux Shell Scripts

Web Development

Ruby and Rails

Assembly

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'. https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...

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: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...

Vaughn Vernon, various: https://www.amazon.com/Code-Complete-Practical-Handbook-Cons... 2

Clean coder: https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...

Hitchhiker's Guide to Python: https://www.amazon.com/Art-Readable-Code-Practical-Technique...

John Ousterhout, A Philosophy of Software Design: https://www.amazon.com/Philosophy-Software-Design-John-Ouste... This one looks particularly interesting, thanks AlexCoventry!

Kent Beck, Test Driven Development: https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...

Dan Bader, Python Tricks: The Book: https://www.amazon.com/Software-Engineering-10th-Ian-Sommerv...

Svilen Dobrev, various: http://www.svilendobrev.com/rabota/

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 models.py 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: https://toptalkedbooks.com/amzn/020161622X

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 eemiiilyy   2018-02-16

Yes. Read The Pragmatic Programmer by Andrew Hunt. This will take you from "script kiddie" status to "engineer" status, and will change your mindset from "I can hack things together" to "I can engineer a solution." It's not hugely technical, but requires technical background to understand the context. I'd say it's a very appropriate guide on "how to think like a programmer."