In this Apprenticeship Pattern “Craft Over Art”, it explains the relationship between the craft and the art of a craftsmen’s work. As an apprentice, it is important to understand how much of an impact both aspects have for the work that they produce for their customer. In the software development field, most of the work that you would produce would be for the customer or client that requests the product. With this being said, the customer or client that requests the product will have certain specifications that they want you, the craftsmen, to make, or they could ask for you to make a product that is useful for them.

“Craftsmanship is built upon strong relationships. Focus on delivering value to your customer over advancing your own self-interests. As a craftsman you are primarily building something that serves the needs of others, not indulging in artistic expression. After all, there’s no such thing as a starving craftsman. As our friend Laurent Bossavit put it: ‘For a craftsman to starve is a failure; he’s supposed to earn a living at his craft’. You need to do your best work in ways that place the interests of your customers over your desire to display skill or pad your resume, while still adhering to the minimum standards of competence provided by the software development community. Walking the Long Road means you must balance these conflicting demands. If you starve because you are too much of an artist and your creations are too beautiful to be delivered in the real world, then you have left the craft. If your desire to do beautiful work forces you out of professional software development and away from building useful things for real people, then you have left the craft.”

This idea of deciding craft over art is understandable and this idea stood out to me the most. The software that you make as a software developer must be useful to the customer, otherwise it is a meaningless piece of work.  It is okay to implement the special touches on your work once it has fulfilled its usefulness to the customer and their needs. However, it is not okay to primarily focus on the art aspect over the needs of the customer. You are called craftsmen for a reason, not an artist, and that’s how I view this pattern’s main idea. I completely agree with this pattern’s idea of craft over art and I feel that every software developer should consider the “craft” a priority over the “art” of their work first.

From the blog CS@Worcester – Ricky Phan by Ricky Phan CS Worcester and used with permission of the author. All other rights reserved by the author.

This week, I read the apprenticeship pattern “Learn How You Fail”. To quickly summarize, this pattern asked you to stop looking at your successes and start actively seeking your failures and weaknesses in order to learn from them. I really liked the message behind this pattern because it is different from what we are accustomed to. It is normally very easy to focus on getting better at something you are mediocre at, and even easier to focus on getting better at something you are great at, but it is really difficult to confront your shortcomings and approach what you are terrible at. My interpretation of this pattern was that it doesn’t seek to discredit the good aspects of your skills but rather putting a focus on the bad as to make you a better engineer overall.

This is another applicable pattern for me personally because I still have a few areas of weakness in my development skills, even in some of the technologies and languages that I’ve been using many years. I have caught myself opting out for a simpler but worse performing option because I didn’t want to confront an area of weakness needed to implement the better solution. The other key aspect of this pattern in accurate self assessment, asking yourself “am I really this good at X, or is there major room to improve there”. I often find that we normally give ourselves the benefit of the doubt and say “Yes we are that good”, and this closes out any potential opportunities to actually improve. What this pattern teaches is to really ask and assess deeply and even ask for an external opinion (via peer review) for areas of weakness.

I agree with this pattern and I plan on implementing this going forward in my career. This pattern should be fairly easy to apply because of its practicality. If you are weak in a skill that will no longer needed, the pattern suggests that you shouldn’t waste your time with that and focus on more important areas of weakness. The only challenge to applying this pattern will be the reluctance to do what we are not good at, but I believe that overcoming this will be much easier if we think about the benefit that will come from fixing our weakest links.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

The pattern “Breakable Toys” can be found here: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch05s03.html

This pattern is a little longer than some of the other patterns I have looked over. Long story short, Breakable Toys is a pattern designed to help you learn. Kind of like Be the Worst but is more focused on you as an individual. The problem is that you are working in a company that can’t afford errors to destroy their data/program/whatever (who can afford that?).  However, the other half of the problem is that you are just learning this stuff and need a safe space to practice. You should create your own safe space project that relates to the problem you need to solve in the company, just at a smaller scale. This pattern tells you you need to build these breakable toys from the ground up to learn the insides and outs. Once you have these breakable toys, they are yours forever to use with other jobs and problems.

I thought this pattern was very useful. I was always told that if I want to learn, I have to do. That’s what this pattern is saying. You have to take the initiative and build these projects in order to learn. The best part is, failing only harms your breakable toy, which you built specifically to be broken!

The first line says “If experience is built upon failure as much as success, then you need a more or less private space where you can seek out failure.” (Oshineye, Hoover) I love this first line because it tells you that failure really is okay. That is how you learn. Being successful on the first try only teaches you what works for this situation but not for others. If you fail, you can learn a whole bunch about what doesn’t work and what does work. I don’t think you should intentionally fail, but failing will help you improve your skills and knowledge (so don’t feel too bad). The most important part about failing is getting back up and trying another approach. I could definitely see myself using this in my intended profession. I get worried all the time about breaking things that are important and this pattern gives you a way around that.

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.

I wasn’t sure if “Share What You Learn” would be applicable at my current level of experience for exactly the reason the writers give for why apprentices might have doubts about the pattern: I assumed this sort of thing should be left to people who know exactly what they’re doing. They brought up points I hadn’t considered in response to this. An apprentice’s minimal knowledge will make their explanations short and to the point, and they won’t make the mistake of assuming the people they’re sharing with have prior knowledge that they don’t. This makes their explanations, in some ways, more useful to other apprentices than an explanation from a journeyman or master.

The benefit to the apprentice sharing what they’ve learned is something I acknowledged in my blog on “Record What You Learn”: the best way you can learn something yourself is to teach it to someone else. The writers mention this benefit, but they also warn of several ways that applying this pattern can end up doing more harm than good which I hadn’t considered. Sharing your knowledge might get you into legal trouble if what you’re sharing is a trade secret, or sharing particular information may actually be harmful to others. You should be careful about what you choose to teach others, and if no one else seems to have explained it, you should consider why. Other concerns include that people might feel as though you’re bragging or explaining concepts in condescending ways if you’re not sharing with humility, or they might assume you have an ulterior motive. Conversely, the writers assert that it’s selfish to seek ways to better your own learning and not consider how others could benefit if you were to share what you know.

They suggest developing a habit of applying this pattern early on, but I still don’t feel like I’m ready to offer anything substantial. If in the near future I learn something I identify as significant enough to record it, I will remember to apply this pattern as well and write an introduction to the topic that others might find useful.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.