The Pragmatic Programmer is a book by Andrew Hunt and David Thomas written in 1999. I have been reading it over the last few months and my final impression is that I am sure that any programmer out there can learn something by reading it. Novice or experienced, this book is packed with good advice. I have tagged the very best tips with a chili pepper (🌶), for reference.

If you enjoy this article, get the book

So, what do you need to do to become a Pragmatic Programmer?

1) Early adopter/fast adapter

2) Inquisitive

3) Critical thinker

4) Realistic

5) Jack of all trades

6) Cares about the craft

7) Never runs on auto pilot

8) Pragmatic Programmers think beyond the immediate problem, always trying to place it in its larger context 🌶

9) They take responsibility for everything they do

10) Isn't afraid to admit ignorance or error 🌶

11) You need to have a broad base of knowledge and experience to pull all of this off. Learning is a continuous and ongoing process

12) When you accept responsibliity for an outcome, you should expect to be held accountable for it

13) Before approaching anyone to tell them why something can't be done, is late or broken, stop and listen to yourself. Will they ask "have you tried this..." or "didn't you consider that?..." How will you respond? 🌶

14) We need to decide what to test at the unit level. Typically programmers throw a few random bits of data at the code and call it tested. We can do much better using the ideas behind design by contract. This style of testing requires you to test subcomponents of a module first. Once the subcomponents have been verified, then the module itself can be tested.

15) By designing code to pass a test and fulfull its contract, you may well consider boundary conditions and other issues that wouldn't occur to you otherwise.

16) Constantly review what's happening around you, not just what you personally are doing 🌶

17) Many users would rather use software with some rough edges today than wait a year for the multimedia version

18) You must invest in your knowledge portfolio regularly

19) Having the best ideas, the finest code or the most pragmatic thinking is ultimately sterile unless you can communicate with other people 🌶

20) When you are faced with an important meeting, jot down the ideas you want to communicate and plan a couple of strategies for getting them across

21) You are communicating only if you are conveying information. To do that, you need to understand the needs, interests and capabilities of your audience 🌶

22) Make what you are saying relevant in time, as well as in content. Sometimes all it takes is the simple question "Is this a good time to talk about...?"

23) Programmers are constantly in maintenance mode

24) Imposed duplication: Developers feel they have no choice - the environment seems to require duplication.

25) Inadvertent duplication: Developers don't realize that they are duplicating information

26) Impatient duplication: Developers get lazy and duplicate because it seems easier. 🌶

27) Interdeveloper duplication: Multiple people on a team duplicate a piece of information

28) Bad code requires lots of comments

29) We all know that in the heat of the moment with deadlines looming, we tend to defer the updating of documentation

30) Appoint a team member as the project librarian, whose job is to facilitate the exchange of knowledge

31) Two or more things are orthogonal if changes in one do not affect any of the others

32) We want to design components that are self contained: independent and with a single well defined purpose. When components are isolated from one another, you know that you can change one without having to worry about the rest.

33) You get two major benefits if you write orthogonal systems: Increased productivity and reduced risk 🌶

34) Single components can be designed, coded, unit tested and then forgotten. There is no need to keep changing existing code as you add new code.

35) An orthogonal approach promotes reuse and will probably be better tested, because it will be easier to design and run tests on its components.

36) When teams are organized with lots of overlap, members are confused about responsibilities. Every change needs a meeting of the entire team, because any one of them might be affected.

37) If I dramatically change the requirements behind a particular functions, how many modules are affected? In an orthogonal system the answer should be "one"

38) Avoid global data 🌶

39) Keep your code decoupled 🌶

40) Avoid similar functions

41) Building unit tests is itself an interesting test of orthogonality. Do you have to drag in a large percentage of the rest of the system just to get a test to compile? If so, you've found a module that is not well decoupled from the rest of the system.

42) The first part of any time estimation is building an understanding of what is being asked. Estimates given at the coffee machine will come back to haunt you. 🌶

43) Be strict in what you will accept before you begin, and promise as little as possible in return.

44) When debugging, don't gloss over a routine or piece of code involved because you "know" it works. Don't assume it - Prove it. 🌶

45) Is the problem being reported a direct result of the underlying bug, or merely a symptom? Is this bug really in the compiler? Or is it in the OS? Or is it in your code? If you explained this problem in detail to a coworker, what would you say? If the suspect code passes its unit tests, are the tests complete enough? What happens if you run the unit test with this data? Do the ocnditions that caused this bug exist anywhere else in the system?

46) You could convince yourself that the error can't happen and ignore it. Instead, Pragmatic Programmers tell themselves that if there is an error, something very bad has happened.

47) A dead program normally does a lot less damage than a crippled one. 🌶

48) Will this code still run if I remove all the exception handlers? If the answer is "no", maybe exceptions are being used in non-exceptional circumstances.

49) The routine or object that allocates a resource should be responsible for deallocating.

50) Deallocate resources in the opposite order to that in which you allocate them.

51) A good way to stay flexible is to write less code. 🌶

52) Do you depend on the "tick" coming before the "tock"? Not if you want to stay flexible.

53) Always design for concurrency

54) Separate views from models

55) Fred doesn't know why the code is failing because he didnt know why it worked in the first place. Always be aware of what you are doing. Fred let things get slowly out of hand, until he ended up boiled like the frog. 🌶

56) Attempting to build an application you don't fully understand or to use a technology you aren't familiar with, is an invitation to be misled by coincidences. 🌶

57) If you don't have fundamentals or infrastructure correct, brilliant bells and whistles will be irrelevant.

58) Don't be a slave to history. Don't let existing code dictate future code 🌶

59) All code can be replaced if it is no longer appropriate

60) Next time something seems to work, but you don't know why, make sure it isn't just a coincidence.

61) Rather than construction, software is more like gardening 🌶

62) Don't try to refactor and add functionality at the same time.

63) Make sure you have good tests before you begin refactoring. Run the tests as often as possible. That way you will know quickly if your changes have broken anything.

64) Test your software or your users will

65) No matter which "best practices" it includes, no method can replace thinking. 🌶

66) Good requirements documents remain abstract

67) The team speaks with one voice -- externally -- Internally we encourage lively and robust debate.

68) Ask yourself if the software meets the performance requirements under real world conditions -- with expected number of users or connections or transactions per second -- Is it scalable?

69) On documentation, we like to see a simple module level header comment, comments for significant data and type declarations and a brief per class and per method header