Follow these 5 tips in order to become more pragmatic in your approach to software development
Recently, I had the privilege of reading The Pragmatic Programmer by Andrew Hunt and David Thomas. In this article I will share with you my top 5 takeaways from the book. Disclaimer, this is not a replacement for reading the actual book. Instead it is a teaser that will help you understand the value this book provides.
1. Think beyond the immediate problem
As a pragmatic programmer, you must approach problems with the larger context in mind. You should always be aware of the bigger picture. Having an understanding of the the entire problem will enable you to make more informed decisions and compromises.
2. Fix broken windows
Be a firm believer of the broken window theory as it relates to codebases. Fix all minor stuff or else entropy will creep in. When you ignore minor fixes within your codebase, your code will lose its value and its quality will inevitably deteriorate.
3. Build your knowledge portfolio
Your knowledge and experience are expiring assets. You must continuously be learning in order to maintain or grow your value. In order to build a highly coveted portfolio you must do the following:
- Invest in yourself
- Diversify your knowledge base
You can achieve this by learning a new programming language, reading both technical and non-technical books, and participating in local user groups.
4. Tracer Bullets
When working on a new application that lacks an architectural skeleton, tracer code is a good approach to try. Similar to tracer bullets, tracer code is a lean solution that enables you to receive user feedback of a simplified version of the solution. Tracer code is great for testing out architectural changes and user interactions.
5. Estimating
When asked to provide an estimate always say “I’ll get back to you.” Obtaining more time will only help you to provide a more accurate estimate. It also prevents you from delivering on an unrealistic estimate provided during water cooler talk.
Choose your units wisely. The units you use in your estimate dictate the precision of your estimate. For example, an estimate of 7 days will be interpreted differently than an estimate of 1 week. An estimate of 7 days will be expected to be completed within 5–9 days. An estimate of 1 week will be expected to be completed within 1–2 weeks. The weeks estimate provides an extra 5 days to deliver.
While I am not an avid reader, The Pragmatic Programmer was a great read and I would recommend to anyone working in tech. The book touches on interesting topics that are of value to engineers and managers of all levels of experience. The knowledge I have obtained from this book has helped me to be a better engineer, leader, and teammate.
