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.
- 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
- 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.