The Pragmatic Programmer: From Journeyman to Master
By Andrew Hunt, David Thomas
The Pragmatic Programmer: From Journeyman to Master
The Pragmatic Programmer has been suggested to me by almost every source that I’ve looked to for suggestions on development books. Here I will highlight some of the take aways I had from the book.
One of the first things they get into is the idea of not committing to too much work. Be realistic about what is at hand. Don’t tell your boss that you can finish something by Friday, if it is clear that you cannot. Be flexible on the scope of the project.
Along those lines, they spend a lot of time going into the ideas of finding out what you’re working on. Take the necessary time to prototype, to build a solid understanding of what it should do, speak with stakeholders and use a language that you can both understand. Transition that language into the code. Name your development objects after the language you are using with the stakeholders and clients so that nothing gets lost in translation.
In agile/scrum, which we use at work, there is an emphasis on creating small ‘vertical slices’ of fully functional and deliverable product. In the book, they describe a technique of using ‘tracer bullets.’ Build the smallest piece of work that you can, that can aim at what you’re trying to hit. Does not have to be anywhere near fully functional, but lets you know if you are on track.
I really like their mention of the ‘broken window’ philosophy. Clean things up as you go along. As soon as you have bad, ugly, fragile code (a broken window), people are less likely to keep respect for it. When they (or you!) come into your code base, if it already has broken windows, they are more likely to feel comfortable committing less than perfect code as well. If it is all in good order, reads well, works well etc then you and others are more willing and likely to keep following that pattern.
I like their ideas of thinking in the mindset of ‘good enough.’ Scrum also emphasizes this paradigm. It is completely okay to iterate on your work and go back and forth with your users and stake holders to decide when you have met their needs. Deliver fast and often and you will know what is needed and what is not. There is nothing wrong with removing features that you thought were going to be useful, but no longer are. The same goes for the technologies you use. Just because another framework or library is going to do the job ‘better,’ if it’s going to take you twice as long to implement it or refactor to use it, it may not be worth it.
A big part of the book is dedicated to keeping up on your learning. To most of us, this should be a no-brainer. Our technology world is moving very fast. You need to spend time every week keeping up on current technologies and researching new ones. This does not mean you have to learn everything under the sun, but you should be keeping in the loop of what is going on and learning what is relevant.
They spend a lot of time describing how to use a good set of tools. The most important being your text editor. Make sure you are using a powerful, configurable tool. Get good at it. It will make your life much more productive. Spend time learning, using, and getting good at other tools that make your life easier as well. Build, automation, scripting, configuration, generation tools etc.