The Pragmatic Programmer: Your Journey to Mastery, 20th Anniversary Edition

by Andy Hunt

Of course, none of this is true. There are no easy answers. There is no best solution, be it a tool, a language, or an operating system. There can only be systems that are more appropriate in a particular set of circumstances.

Pragmatic Programmers get the job done, and do it well.

It’s not the most pleasant aspect of programming, to be sure, but it will happen—even on the best of projects. Despite thorough testing, good documentation, and solid automation, things go wrong. Deliveries

Above all, your team needs to be able to trust and rely on you—and you need to be comfortable relying on each of them as well.

You have the right not to take on a responsibility for an impossible situation, or one in which the risks are too great, or the ethical implications too sketchy.

When you do accept the responsibility for an outcome, you should expect to be held accountable for it. When you make a mistake (as we all do) or an error in judgment, admit it honestly and try to offer options.

Before you approach anyone to tell them why something can’t be done, is late, or is broken, stop and listen to yourself. Talk to the rubber duck on your monitor, or the cat. Does your excuse sound reasonable, or stupid? How’s it going to sound to your boss?

don’t cause collateral damage just because there’s a crisis of some sort. One

Your ability to learn new things is your most important strategic asset. But how do you learn how to learn, and how do you know what to learn?

you need to change an object’s state, get the object to do it for you. This way your code remains isolated from the other code’s implementation and increases the chances that you’ll remain orthogonal.