There are some books that I wish were available 4 years ago when I first started working in the software development world, maybe even before I went to college. This book is definitely one of them. It’s not an easy task to concretely outline the practices that are helpful towards improving one’s skill as a software developer but this book does it well as Dave and Ade speak about their experiences as apprentices and how they grew to be journeymen.
I will point out the patterns that resonate the most with me and my quest to be a better developer.
1. Expose Your Ignorance
Context of the problem: Your team/clients/managers are expecting you to know what you’re doing and deliver value to the team but you’re unfamiliar with some of the required technologies or the domain of the project.
This situation happens to me on quite a regular basis every time I switch to a new project. It’s one thing to not know the domain of the application, it’s another to not be comfortable or familiar with the language or tools that are used on the project. When I started my first project at ThoughtWorks, I remember taking about 3-4 months to get up to speed and learn all the right questions to ask when working on a story. I have reduced that learning curve period since then, but it has always been a challenge to have to deliver on my first day on a new project.
Suggestions from the book:
- Show your team and managers that the learning process is part of delivering software.
- Get used to learning. Craftsmen will have to work with different technologies and domains over the course of their career. Those who stick to just one domain/technology are called experts. Expertise is not the goal of the apprentice.
- The most important trait of a craftsman is the ability to learn, identify an area of ignorance and working to reduce it.
2. Confront Your Ignorance
Exposing your ignorance will be of no value if you don’t do anything about it. There will always be tools and techniques that you need to learn and master and you have to start somewhere.
I usually do the following:
- read documentation, APIs and FAQs
- if it’s open source, attach the code so it’s easier to look at what’s going on
Things I should really do more of:
- write a scratch application to use the new tool/library
- actually dive in to the code, if there is any
Things I am currently trying to do:
- start from scratch and learn about a language from the ground up. I recently picked up the book C# In Depth by Jon Skeet to learn about the innards of C# starting with C#1 onwards to C#3. I also was reading Programming Clojure by Stuart Halloway (but sadly that has been pushed to the wayside).
3. Be The Worst
Some people find it discouraging when they realize that they are the least experienced person on their team. I, however, find that exhilarating because I know the opportunities for me to learn will be endless. Being the worst on your team shouldn’t disheartened you, but it should push you to work harder than anyone else because the goal is not to stay the weakest, it is to work your way up.
Enthusiasm and passion can be contagious and I have my coworkers at ThoughtWorks to thank for always pushing me to learn more and be better, either explicitly or implicitly.
4. Kindred Spirits
The journey to becoming a master craftsman can sometimes be a lonely one depending on the people who work with you and the work culture that you’re in. It is very disheartening if your efforts to learn new tools, or languages or platforms isn’t supported by your manager just because “it’s the company mandate that we only use X, Y, Z products and open source tools aren’t allowed“. You need to surround yourself with people who are like-minded about learning and that can be achieved via user groups, mailing lists, etc.
My kindred spirit is in the form of Mark Needham, who is a friend and a coworker at ThoughtWorks. We discuss about everything from what’s the best build tool to use in the .Net world, to why is it so hard to change the way people work. He is constantly challenging me to explore things further like diving into the code for Rhino Mocks to understand how things are done behind the scenes.
5. Expand Your Bandwidth
You have built up a set of skills. You are comfortable doing what you’re doing now and hope things doesn’t change so you don’t have to set foot in unknown territory again.
It’s easy to get comfortable with what you know and ignore what you don’t. But unless you want to do the same thing over and over again for a long time (which is quite impossible in software development these days), there will always be new languages to learn, new tools to use, new methodologies to get used to. I don’t think we can afford to rest on our laurels in the software development world. Things change so frequently and there is always so much to learn.
Tip: Read books, read blogs. Read, read, read.
Other patterns that I think are useful:
6. Breakable Toys – use your favorite tools to build a simple application of your choice. Most work environments don’t allow for failure and experiments so you need to create a safe environment where you can do just that.
7. Use The Source – Seek out code and read it. A lot of the tools we use nowadays are open source so the code is readily available.
8. Record (and Share) What You Learn – I use this blog as a tool to record my learnings and as a platform to share them with others and to solicit feedback from them.
I highly recommend this book to anyone who is seeking to learn how to improve their skills as a software developer.