The “Find Mentors” pattern from Apprenticeship Patterns by Oshineye and Hoover is one that has relevance no matter how far along on your software craftsman journey you are. Whether you are opening an IDE for the first time or are a seasoned veteran who has contributed endless amounts of knowledge to the field of software development, it is important to seek and learn from those who’ve been through the trials and tribulations that you have yet to face. There is a stereotype that programmers are these hermit-like creatures that rarely see the light of day and seldom speak to other humans. In their dark caves, they churn out program after program in a vacuum-like environment. This is simply not the case and every single person who calls themselves a software developer can benefit from collaboration, specifically seeking out those who have already made the mistakes and can expedite the growing process for them.

All of the patterns that were carefully curated to appear in Apprenticeship Patterns have relevancy in practically all software developers’ professional careers. “Find Mentors” is no different as the knowledge that can be learned from a mentor can potentially be far greater than that learned alone because of the simple fact that they have walked the road and generally know the “path of least resistance” in their given field of expertise. This is why I feel this pattern is so important. Not only do mentors hold massive amounts of knowledge waiting to be tapped into for your benefit, having a mentor that you can show your work to can force you to hold yourself to much higher standards than otherwise. I think the realism the authors bring to the pattern when they explain that “no one knows everything” is important because it can be tempting to rely on a mentor too much and lose confidence in them when they don’t have an answer to a given problem. They are only human too, therefore they have gaps in their knowledge just like the rest of us. Note also that the mentors one needs throughout their career change and shifts just as much as one’s own knowledge does.

This pattern has made me desperately want to seek out people I can learn from who are further along in their careers. The benefit of having mentors to obtain guidance from is far greater than the fear of ridicule that has been generally holding me back from finding mentors that can help me excel in my career.

From the blog CS@Worcester – Creative Coding by John Pacheco and used with permission of the author. All other rights reserved by the author.

I feel like most people have been in this situation: you have passion for a hobby and decide that you want to take your craft to the next level. In doing so, a mountain of unforeseen stress and complications arise and at some point along the way you might even forget what motivated you to get to where you are in the first place. Sustainable motivations are important no matter what you are applying this pattern to. This pattern is especially important in the life of a software craftsman.

In an industry where it is all too easy to retreat into competence because the pay is “good enough”, it is easy to lose sight of the motivation that made you decide to devote your life to becoming a software developer. I can’t even describe the joy I felt as a sophomore in high school when I set out to make an, albeit shoddy, clicker game in JavaScript, and after slaving over the code for days I finally understood exactly how a game loop had to function in order to make the game playable. I proceeded to spend that weekend glued to my screen implementing all of the features I had only dreamed of days before, barely remembering to relieve myself periodically. It is that entering into a state of flow and  working through complex problems with the end result being something I created that made me fall in love with the craft. Sometimes I fall victim to forgetting what it is about programming that I love since it feels like I have been in school for a long time and the future in regards to employment and making ends meet is up in the air. To quote David Wood, “do what you love and the money will follow”. Making sure to never let your motivations become misguided is important into keeping energy and creativity levels as high as they can be.

An important distinction between motivations can be made. That is intrinsic versus extrinsic. The more intrinsic your motivations, meaning doing so because you find it personally rewarding, versus extrinsic motivations, doing so because you seek a reward, the more sustainable your motivations will be. I know I am extrinsically motivated by money and the desire to succeed for my family and teachers, and I am intrinsically motivated by the desire to create, the desire to increase the complexity of life, and the desire to solve problems. I find this pattern important because motivations truly change your outlook and mood when facing life. This pattern applies to everything in life and I think writing down motivations is a good exercise for my software development career and in life.

From the blog CS@Worcester – Creative Coding by John Pacheco and used with permission of the author. All other rights reserved by the author.

As I near the end of my college career I am giving more thought daily to what exactly I need to put forth to land my first job as a Software Engineer. Will companies value the fact that I am very creative minded and enjoy collaborating on projects or is are they only looking for the cold hard skills that I have gained over my years of study. The Concrete Skills pattern from Apprenticeship Patterns highlights the fact that, while soft skills are important, the ability to apply knowledge in order to provide value to the companies you are applying to is paramount. Why should a company take a risk on a candidate who doesn’t show that they have the skills the company needs when they can hire someone who does.

This pattern is all about identifying exactly what skills the job you want is looking for and gaining the skill. What may be even more important than learning the skill is building a project using that skill in order to prove your adequacy. While the ability to learn quickly is a great skill, having the foundational skills companies are looking for is important when searching for landing a job. It is important to research which skills are relevant to the positions you are applying for rather than trying to learn everything, since that is an impossible task.

I have recently started my job search and more and more I’m realizing the benefits of having projects that prove my competence in relevant skills for the jobs I am applying to. This pattern has made me realize that it would be a great idea to ask people in my network who are further on in their careers about what skills they put forward that helped them land a job. I can then use this list of skills I gather to slowly pad out my resume with projects that prove that I can provide value to the companies I am applying to. Since I am in my last semester I am pretty packed with coursework, but I am going to set out to learn at least one relevant skill every weekend. By the end of the school year my GitLab will be a place where all of my skills are shown off with well crafted, yet small in scope projects. Concrete Skills is a pattern that every software developer should read and implement because of the huge benefit that it gives you in your career as a Software Craftsman.

From the blog CS@Worcester – Creative Coding by John Pacheco and used with permission of the author. All other rights reserved by the author.

I am not lying when I say I have been avoiding delving into this pattern from Apprenticeship Patterns, for fear that it would hit close to home. Upon reading “Craft over Art”, I’d argue that this pattern is full of more enlightening information than any I have discussed so far. Oh yeah, and it also hit very close to home.

The context for this pattern is very general, as it states that you are being paid to deliver working software to a customer. The pattern argues that delivering working, useful software is paramount to building some magnificent thing in order to display skill or artfulness. We are trying to become craftsman not artists, and while there is a time and place where making the most beautiful code and software is appropriate, a line must be drawn. As explained in the pattern, it is important that a bottom line for quality is determined and met at all times, even under pressure. It is important to note that the authors argue that “utility and beauty are not opposed, but interdependent.” This means that we have to constantly choose a balance of the two that work for any given situation, and this will change constantly.

As I am an extremely creative minded person I find myself often trying to create “art” when I am trying to deliver working software, especially when I am working on self-directed projects. I find myself working on all of the frivolous parts of a project, expending all of my energy on minimal functionality. The end result tends to be me giving up on self-directed projects because I get burnt out working on all of the bells and whistles, while minimal actual functionality is present. A conversation between me and an observer tends to go like this:  “Wow that looks awesome! But what does it do?,” the observer exclaims. “Nothing but it looks cool right??,” I say, sweating slightly. My point is historically I tend to put valuable functionality lower than fancy technology and fluff. After learning about the Agile principles and Scrum frameworks I have been getting much better at reflecting and making sure what I am working on is valuable to the customer.

This pattern is packed with information that I will continue to think about in my career. It is fun to have a romanticized idea of what being a software craftsman is, but at the end of the day the most important thing is that utility is what I’m getting paid for.

From the blog CS@Worcester – Creative Coding by John Pacheco and used with permission of the author. All other rights reserved by the author.

When a software developer gets overwhelmed by the complexity of their current project or the fact that there is so much they don’t know, it is okay to “retreat into competence”. In the face of a challenge that seems insurmountable, taking a step back to see how for you’ve come and what you have accomplished is okay. While retreating into competence can be the right prescription for times like these, it is important to use the traction gained while retreating to propel yourself beyond where you first had stopped.

The title of this pattern almost seems contradictory to the whole concept of becoming a software craftsman. A software craftsman should always seek to move forward in their knowledge and career, why would the authors be telling us to retreat? While being able to continuously march forward indefinitely, steadily increasing project complexity and your responsibilities would be ideal, it almost never works like this in the real world. I find this pattern to be quite important, because without it, it seems that one would be going directly against the principles of a software craftsman to step back from a problem and retreat into competence.

One thing to note is I feel like it is especially easy to fall back on this pattern too much. If you consistently find yourself pressing the “eject” button whenever you reach a problem you might not know how to solve yet how will you ever go forward. It is important to set constraints on how long you can retreat in order to protect yourself from truly going against the principles of software craftsmanship and living a career filled with mediocrity. This is a powerful pattern, use it responsibly.

I feel like this pattern can be used in many situations in order to get over hurdles in one’s career that seem too great. Allowing yourself to create things you feel comfortable developing can help you regain faith in yourself and software development as a career. This is a pattern I have used myself and have seen great success with. When I find myself lost or over my head with a given problem, I like to solve small programming challenges, sometimes referred to as kata, in order to instill confidence in myself and remind myself how much I have improved over my career.

From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.

“Confront Your Ignorance” is another pattern that struck a chord with me from the Apprenticeship Patterns book. I chose to talk about this pattern now because of its strong relationship with the “Expose Your Ignorance” pattern which I talked about in a recent post. As a developer who is relatively early in their journey, I realize that there is some skill or tool that I should know that I may be unfamiliar with almost daily.

Confronting your ignorance is all about taking the list of skills and tools that one creates when exposing their ignorance and setting aside time to learn that skill. The approach with which one learns a given skill or tool is unique to the individual. The main goal of this pattern is to be able to confidently say that you understand how to implement a given skill or effectively use a tool after confronting that gap in your skill set. It is important to reflect often and decide, once you have reached satisfactory knowledge in an area, whether you should switch topics or delve deeper into the current one. If a developer does a great job of exposing their ignorance without ever confronting it they can never take the step to being a software craftsman. They will find comfort in their ignorance and rely on others to fill in the gaps. Conversely, if a developer always confronts their ignorance without exposing it, it creates a work environment where everyone pretends to have a skill and then learns it in hiding to appear adequate. This would be a bad application of this pattern and should be avoided as much as possible.

For myself, I find that my learning and application of a skill tend to go hand in hand. I find myself confronting my ignorance at the same time as trying to deliver a product which tends to end in frustration and a sense of failure. In employing this pattern I can save myself the frustration by setting aside time to toy with a tool and learn a skill. Inevitable failures when learning how to use a tool no longer equate to failures in being able to deliver a product. After reading “Confront Your Ignorance” I will immediately start to employ this pattern in daily life. I will expose my ignorance and then give myself the time to fill those gaps in my skill set.

From the blog CS@Worcester – Your Friendly Neighborhood Programming Blog by John Pacheco and used with permission of the author. All other rights reserved by the author.