If you’re looking for a book to help improve the craftsmanship behind the code you write, I highly recommend The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt and David Thomas. What makes this book unique from other programming books is the fact that it addresses how to improve your coding skills on both a technical and personal level.
For example, in addition to having chapters comparing the advantage of plain text versus binary encoding, it also contains amazing bits of wisdom regarding how to work with the less technical members of your team in order to further your project’s success:
You may be in a situation where you know exactly what needs doing and how to do it. The entire system just appears before your eyes—you know it’s right. But ask permission to tackle the whole thing and you’ll be met with delays and blank stares. People will form committees, budgets will need approval, and things will get complicated. Everyone will guard their own resources. Sometimes this is called “start-up fatigue.” ..Work out what you can reasonably ask for. Develop it well. Once you’ve got it, show people, and let them marvel. Then say “of course, it would be better if we added….” Pretend it’s not important. Sit back and wait for them to start asking you to add the functionality you originally wanted. People find it easier to join an ongoing success. Show them a glimpse of the future and you’ll get them to rally around.
Hunt, Andrew; Thomas, David (1999-10-20). The Pragmatic Programmer: From Journeyman to Master (Kindle Locations 413-420). Pearson Education (USA). Kindle Edition.
The quote above is just one of many reasons I fell in love with this book. Hunt and Thomas go out of their way to address the underlying causes of bad code, poor team cohesion, and missed requirements and they do it in a way that doesn’t feel condescending or overly touchy-feely. In addition, they still take the time to help you improve your skills on a technical level. On refactoring:
At its heart, refactoring is redesign. Anything that you or others on your team designed can be redesigned in light of new facts, deeper understandings, changing requirements, and so on. But if you proceed to rip up vast quantities of code with wild abandon, you may find yourself in a worse position than when you started. Clearly, refactoring is an activity that needs to be undertaken slowly, deliberately, and carefully. Martin Fowler offers the following simple tips on how to refactor without doing more harm than good:
- Don’t try to refactor and add functionality at the same time.
- Make sure you have good tests before you begin refactoring. Run the tests as often as possible. That way you will know quickly if your changes have broken anything.
- Take short, deliberate steps: move a field from one class to another, fuse two similar methods into a superclass. Refactoring often involves making many localized changes that result in a larger-scale change. If you keep your steps small, and test after each step, you will avoid prolonged debugging.
Hunt, Andrew; Thomas, David (1999-10-20). The Pragmatic Programmer: From Journeyman to Master (Kindle Locations 3320-3327). Pearson Education (USA). Kindle Edition.
Of all the books I have on my shelf, this is by far the one I value the most. I highly recommend you pick up a copy for yourself. Digital and print copies can be found on Amazon.