Joseph Hallenbeck

The Pragmatic Programmer

Recently, I’ve been running a book club to cover the contents of the Pragmatic Programmer by Andrew Hunt and David Thomas. One of those volumes that has been held up, forever, as a text that any good Software Engineer should have read. The text itself is rather sound, although starting to show it’s age in the era of software-on-the-browser.

Probably not going to do much of an articulated look at the book. Rather, I think I will simply post my cliff notes as I, or we go through each chapter.

Chapter 1

  • Take responsibility for actions, career advancement, project, and day to day work while being honest about your shortcomings
  • Understand that responsiblity is something you actively agree to.
  • You don’t directly have control over the success of things that you take responsibility for.
  • You do have the right to not take responsiblity for an impossible task, but if you do accept responsiblity, then you are accountable for it’s success
  • Provide options, avoid lame excuses
  • “Broken windows” in the code encourage the code base to degrade over time
  • “Start up fatgue” sets in when you make a greenfield request too big. Start small, and work to larger
  • Keep the big picture in mind to avoid creep
  • Software needs to be good enough for the the user; the maintainer, and lastly; for yourself
  • Ask the users how good they want their software to be
  • Great software today is often preferable to perfect software tomorrow
  • Know when to stop making improvements
  • Your “Knowledge Portfolio” is your most important asset, but it has a half-life. Invest in it regularly, manage high and low risk skillsets, and keep a diverse portfolio
  • Some ideas to keep on top: learn a new language each year (particularly ones that introduce new paradigms), read a technical book each quarter, read non-technical books, participate in user groups and conferences, stay current on industry trends
  • You’re communicating only if you’re conveying information. Know what you want to say, know your audience, choose your moment, choose a style, make it look good, involve your audience, be a listener, and get back to people

Chapter 2

  • We are always maintaining software, it is a routine part of the development process
  • “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system” (DRY)
  • Wrong comments are worse than no comment at all
  • Keep code orthogonal, that is eliminate dependencies such that internal changes in a module do not change the external interface.
  • Orthogonal code reduces risk by isolating bad code, allowing for agile development, easing tests, and reducing vendor lock-in
  • Avoid excessive team overlap
  • When designing architecture, ask if you were to dramatically change the requirements how many modules must then change?
  • Develop shy code that doesn’t reveal it’s internal impelementations
  • Avoid global data
  • Use the stategy pattern to avoid functions with similar bodies
  • Do not approach projects with notion that there is only one way to do it
  • When a critical decision is made it narrows the pool of future possible decisions; put off such critical decisions until later by making code reversable
  • “Tracer Bullets:” start with a small, single aspect of the final system and complete the piece first. Iterate upon that piece to fully flesh out the system. Integrate daily, rather than building a single monolith and then integrating
  • Prototyping generates disposable code. Stakeholders must be made plainly aware that a prototype is not a finished product and cannot contribute to the final production product
  • Prototypes are creates to analyze and expose risk. They are designed to explore a single aspect of the software
  • Use prototypes for things that haven’t been tried before, critical systems, and anything unproven or experimental
  • The language of the domain suggests the programming solution
  • You can implement the domain language into an interpretive language
  • When estimating use the units of the quote to suggest uncertainty, e.g. a project doable in a sprint is quoted in days, a project doable in a month or two in weeks, a project doable in over a quarter, in months, etc.
"The Pragmatic Programmer Chapter Notes 1 & 2" by Joseph Hallenbeck is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.