The Pragmatic Programmer
These are my personal reading notes and are mostly written in my own words. Please reference the book for the original text as intended by the authors.
Chapter 1 - A Pragmatic Philosophy
Being a pragmatic programmer is about your attitude and how you approach various problems.
- Take responsibility. Acknowledge failures and shortcomings. Provide multiple options for how to resolve an issue.
- Software gets worse over time when left unmaintained. Leave the code better than you found it. Use common sense for how much time to spend.
- To help bring about change, actually do/build something - even just part of it. Make sure to do so gradually so it doesn’t get rejected.
- Users should be involved in deciding what functionality is good enough. Share the trade-offs with them - the project can be done sooner if some errors are acceptable.
- Constantly build up and invest in your learning. The industry can change quickly, and our knowledge needs to stay relevant.
- Understand the audience when choosing when and how to communicate something with them.
Chapter 2 - A Pragmatic Approach
Some practices and approaches will help you develop better code.
- Reduce duplication when possible. Limit documentation to only live where it is most relevant. Share common code in an easily accessible manner.
- Keep things decoupled and independent. Keeping layers of a system in separate modules enables easily changing just one part.
- When making a decision, don’t get locked into a certain way of doing it. Plan ahead so that parts can easily be removed or changed later.
- Use tracer bullets to test that all parts of system work together. Create minimal project that utilizes all parts of the system. This project is kept and added onto.
- Use prototype to learn / answer specific question / test ideas. Throw away after.
- When applicable, offer a higher-level language to abstract away unimportant details.
- Learn to estimate how long things will take. Convey accuracy with choice of units. Update project estimates as you go.
Learn to use multiple tools to better perform daily tasks.
- Keep underlying data human readable by using plain text.
- Increase productivity by learning to use a shell.
- Become proficient in a single editor, and try to use it for all editing.
- Use source code control (versioning) to track changes. This is not limited to just source code.
- Keep calm and focus on fixing bugs instead of who caused them. Utilize a debugger to see the state of the program.
- Learn a text manipulation language that allows quickly trying out ideas and creating simple tools.
- Generate code to reduce duplication of effort.
Chapter 4 - Pragmatic Paranoia
Summary
- placeholder
- placeholder
- placeholder
- placeholder
- placeholder
Chapter 5 - Bend, or Break
Summary
- placeholder
- placeholder
- placeholder
- placeholder
- placeholder
Chapter 6 - While You Are Coding
Summary
- placeholder
- placeholder
- placeholder
- placeholder
- placeholder
Chapter 7 - Before the Project
Take care of certain needs before even beginning work on a project.
- Keep requirements abstract with simple statements. Use cases help document goals. Keep track of injections. Ensure terminology is consistent between developers and stakeholders.
- When facing a seemingly impossible task, find the real constraints of the problem.
- If you don’t think you are ready to start, identify the reason - perhaps by beginning a prototype.
- Don’t spend too much time getting extremely detailed in specifications. These may change as you begin coding.
- Use formal methods to help specify a project, but don’t overdo it.
Chapter 8 - Pragmatic Projects
Summary
- placeholder
- placeholder
- placeholder
- placeholder
- placeholder
- placeholder