I’m currently a student apprentice at 8th Light. I’ve been working directly with a mentor to learn the ins-and-outs of software engineering, starting with Ruby. And I recently read Apprenticeship Patterns by David H. Hoover & Adewale Oshineye.
This book gave me a better understanding of what it means to be an apprentice in software engineering, or any type of apprentice. I’m lucky to be starting my path through a formal apprenticeship, but this book explained what it means to be an apprentice, journeyman, or craftsman throughout my career, whether I’m in a formal apprenticeship program or not.
The Journey to Crafstman
The modern apprenticeship model for software engineering came from a similar model used in Medieval Europe. In that time, guild controlled masters and masters controlled their own workshops. Masters worked to improved their craft and oversaw journeymen. The journeymen were nomadic, and were the only means by which new techniques could pass from city to city. As well as bringing in new techniques, journeymen supervised the day-to-day activities of the apprentices. The apprentices worked for one master for several years until they graduated to the ranks of journeymen by proving they had absorbed the basic skills and values of their craft. A person who did not fit into the guild’s hierarchy could not legally practice his craft.
Now, this formal guild structure is obviously not present in today’s software engineering world. But to some extent, the roles of apprentice, journeyman (or early craftsman), and craftsman are similar.
Apprentice: Being an apprentice means being in a constant state of learning and growing as a software engineer. You realize that there is probably always a better/faster way to be doing something and you strive to acheive that. This is the first step on the path to becoming a software craftsman.
An important thing to realize is that your apprenticeship path is up to you, whether or not your have a formal process. It’s yours to mold and determine the outcome.
Journeyman: You take what you’ve learned as an apprentice and spread that knowledge throughout the community. You try to learn other ways of doing things and gain connections in the community. You build a larger portfolio and are given more responsbility. You also hold onto the traits of an apprentice and never stop learning.
Craftsman: Craftsmen not only try to improve their craft, but the move the industy forward as well. You try to teach apprentices and journeymen better ways of doing things. In short, masters view the acquisition, usage, and sharing of superior skill as the most important part of being a software craftsman.
Design patterns are general reusable solutions to commonly occurring problems within given contexts in software design. Design patterns provide names to common problems/solutions so that engieers can discuss these solutions across different projects.
This book provides solutions to common problems in certain contexts on the journey from apprentice to craftsman. It turns out that many software engineers and apprentices face similar problems are their learning journey. Everything from not being sure how to learn a new language, how to motivate yourself, and how to deal with unsupportive teams.
Here are a handful of apprentice patterns that I think I’ll come back to time and time again on my journey:
Context – You are seeking a role on a talented team of craftsmen that will provide you with better learning opportunities than you currently have.
Problem – The team can’t take the risk of hiring someone who may not be able to directly contribute.
Solution – Build up your base set of skills to get pass hiring managers and be able to directly help in some way. While you might not know everything when you get hired, you at least have a solid set of skills that will allow you to contribute.
Laura’s Tip – The book suggests that you look at resumes of software engineers to see what skills they have. That’s definitely a good idea, but it might be tough to ask someone to see their resume. I think you should reach out to a recruiter at three to five firms you’re interested in and ask them what skills you would need for a job with their company. It’s their job to answer people like you and you’ll hear about the skills you need directly from the person you’ll want to get back in touch with.
Craft over Art:
Context – You are being paid to build something that will solve a problem for a customer.
Problem – You could solve your customer’s solution easily or you could challenge yourself and solve it was a beautiful solution while impressing your colleagues.
Solution – Use the proven solution instead of building something beautiful. Craftsmanship is built upon strong relationships. Focus on delivering value to your customer over advancing your own self-interests. As a craftsman, your primary duty is to build something that serves the needs of others, not indulging in artistic expression.
Laura’s Tip – This kind of shocked me to see this. But then I realized it makes total sense. We are talking about a craft here — a means to make a living and serve others well, not about a hobby. Software engineering can ALSO be a hobby, i.e., you can build beautiful things in your spare time, but when you’re doing it as a craft you should serve your customer first. Build breakable toys (see below) or masterpieces after hours to fill your creative needs.
Find a Mentor:
Context – You have realized that you’re not the first person to walk the path and that you are spending a lot of time exploring blind alleys.
Problem – You need help and guidance.
Solution – Seek out those who have gone ahead of you and strive to learn from them. It’s really important to have someone who knows more than you guide you along your journey. Your learning will be significantly accelerated if you have feedback, help, and guidance. Especially in software engineering, it’s easy to spin your wheels or work on stuff you already know. You need someone to ask for help and someone to push you.
Laura’s Tip – This sounds pretty challenging to me. If you’re not in a formal mentorship program, it seems like it’d be pretty awkward to ask someone to be your mentor. My advice is to structure it informally at first. Ask a friend of a friend for help with your code or head to a local meetup to meet some friends in software engineering and ask them. First, ask them to help you with a current project your working on, and then invite them to coffee and lunch. Eventually this could naturally turn into a mentor/mentee relationship if you’re both interested. Just make sure you find someone who really challenges you to be a better software engineer.
Context – Experience is built upon failure as much as (if not more than) success.
Problem – You work in an environment that does not allow for failure. Yet failure is often the best way to learn anything.
Solution – Build toys on your own that you can feel free to break. Take risks by trying to build something really challenging and allow yourself to fail. You’ll pick up new skills and be prepared to take on harder projects at your day job.
Laura’s Tip – Build something hard that you really want to use. This will keep you motivated to keep working on it during your off-hours. Even better, tell someone that you’re building it so that you’ll feel pressure to finish.
Context – You have opened lots and lots of doors.
Problem – There seems to be an endless stream of deeper and more fundamental concepts that are eluding you, despite
your proficiency at your first language.
Solution -Focus your thirst for learning on consuming as much of the written word as possible. Emphasize books over blogs. Read the classics, even though you might think that newer books will be better.
Laura’s Tip – At first I didn’t understand why reading whole books would be better than specific blogs. But I love reading actual books. Say you have something specific that you’d like to understand, like how to set up a Ruby class. Sure you could google that and read a blog article about it and perhaps you’d find your solution. But if you dove into an entire book to find the answer, you would come out with an answer AND your knowledge would be significantly increased. Books introduce you to new concepts and new challenges. They also tend to explain programming solutions in much more depth than blogs would.
Keep a reading list or ask other apprentices or crafstmen for book ideas and never stop reading!