The Pragmatic Programmer Chapter Notes 1 & 2

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.