This pattern is called “Confront Your Ignorance”. The scenario it is meant to address is when a programmer has gaps in their knowledge that interfere with their work. More specifically, they want to master skills and tools, rather than simply be adequate, yet are unsure of the first step towards that goal. Finding the first step or even admitting they need to find the first step is difficult, particularly in environments where there seems to be an expectation to just have already mastered things.

The solution provided is simple. Pick something you need to learn and then learn it. While it sounds simple, it is easier said than done.

An important skill that I have only recently started thinking about, which this pattern touches on, is the ability to know when you’ve learned enough about a subject and that it’s time to turn your attention elsewhere. Without mastering this skill, one might still go out of their way to study something on their own. In the absence of any clear goals, they may simply give up whenever they get sick of it. This is something I used to do a lot, and it led to situations where I had taken time out of my day to learn something, but the knowledge itself was too incomplete to be useful. I wouldn’t go so far as to say that it was wasted time, but I think it could definitely have been better spent.

Different people have different approaches that best suit them for filling the gaps in their knowledge. Something I think is pretty important for me is to figure out what my ideal approach is. I have some ideas. For example, I think I tend to prefer concrete examples, hands-on involvement, and at least a general understanding of how the whole system works. Figuring out what works for me in more specific terms would be a good idea also.

I tend to struggle to seek help from peers. In this pattern, the authors suggest working together to learn things, which is something I think can be fun, productive, and worth trying.

One of the core ideas here, which I will talk about in a future post, is the idea of two extremes when learning, which need to be avoided. In one, ignorance is kept totally private, creating an atmosphere where not being proficient to begin with is extremely discouraged. In the other, no attempt is made to prevent one’s ignorance from interfering with a team’s project. Straddling the line between these is another skill that I haven’t really considered before, but should probably get good at sometime soon.

From the blog CS@Worcester – Tom's Blog by Thomas Clifford and used with permission of the author. All other rights reserved by the author.

I think an apprentice should portray acts of enthusiasm for whatever they are aspiring to learn. I’ve found myself to have copious amounts of enthusiasm for learning how to program and becoming better at it. The issue I run into is finding ways to express that enthusiasm. I get giddy when I think about becoming a great programmer and I certainly wouldn’t want to rub anyone the wrong way because I came off as too much. My current composure and body language around others suggests that I am complacent, although I’m screaming with impatience on the inside. But I wouldn’t want to come across as apathetic for what I’m doing either. As I’ve been skimming over the different patterns in the Apprenticeship Patterns book, there have been many sections that made me feel like the authors were speaking directly to me and this pattern of enthusiasm is no exception.

The authors seemingly think that while being enthusiastic for your craft is an amazing thing, blindly expressing your enthusiasm can actually hurt an apprentice more than it can help them. With this in mind, it is important to curb your enthusiasm to an extent because you do not want to let the excitement you feel for the craft lessen because you don’t want to feel like a nuisance to others around you. As the authors put it, the excitement one feels is “a precious commodity” and I could not agree more.

The sense of discovery can be extraordinarily exciting. It is probable that individuals in well established teams are used to their routines, making discovery likely, but not exactly exciting. The authors mention that this sort of thing is predictable. Developers are always looking for better ways to getting “painful” work done more efficiently. This sounds more like searching for a sigh of relief rather than completing an exciting endeavor, and having with a hyper-passionate apprentice around probably makes tasks like these more grueling.

Finding a team that encourages your enthusiasm is important. An apprentice should be able to recognize a teams dynamic and see where appropriate to show their enthusiasm. If the team doesn’t seem like they would appreciate their apprentice’s ignorance, the authors recommend finding different strategies to nurture your need so that it does not jeopardize your opportunity to learn. However, if the team is open to bright and new fantasy driven ideas, the apprentice may offer new life to the team and boost morale.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

This week, I decided to take a look at the “Concrete Skills” apprenticeship pattern in chapter 2. This pattern describes the problem of potentially joining a team, with the expectation that you will learn more than you already know, and the team not wanting to take the risk on someone who may not be able to contribute to the workload. It is important to acquire and develop “concrete skills.” Concrete skills serve as proof of your competence, as it more so demonstrates your ability to apply the knowledge that you have. The pattern suggested that one should always acquire more concrete skills than just the bare minimum required in an interview. It is always beneficial to have examples on hand as proof of what you can offer to the team. The examples of concrete skills provided include writing build files in various languages and having knowledge of popular open-source frameworks. And so, concrete skills help reassure your future teammates that you are capable of contributing without the need for “day care.”

My immediate reaction to the pattern was that I can see myself in this specific situation. The pattern starts with a quote from Pete McBreen, where he states, “Having knowledge is not the same as having the skill and practical ability to apply that knowledge to create software applications.” That quote stuck with me because we can spend years studying a certain topic, but your expertise shows when you apply the knowledge. And reading through this pattern encouraged me to take a deeper look at the concrete skills I have developed thus far.

For the most part, I think this pattern gives some useful tips on how to build an impressive resume and come off as a capable job candidate. The question: “If we hire you today, what can you do on Monday morning that will benefit us?” is something that I will keep in mind since I will need to evaluate myself before even applying for jobs. I do think this pattern gave me a bit more insight into my intended profession. I never really thought about the fact that teams are more likely to hire someone that can be an immediate help rather than someone they would have to teach. So I think this is more encouragement to further acquire concrete skills. Perhaps I will spend more time with frameworks, especially ones we are working with in class such as Vue.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

The White Belt

This Apprenticeship pattern was about unlearning what you already know in order to learn something new. It is important to do this because, especially with programming languages, what might be a good habit or convention within one language may be inefficient or bad practice within another. I could personally relate to this Apprenticeship pattern a lot because in high school I took an intro to programming class in which we learned the basics of python. I found python to be really confusing at first, but over the course of the school year I became very familiar with it and began to really like the syntax and structure of the language. While this class was very useful and helpful for learning programming, it made it more difficult for me being a computer science major in college.

In college, most of the programming we do is in java. Transitioning from python to java was very difficult for me because they are two very different languages, with different syntax and structure, and different coding conventions. In my experience, it is very difficult to translate from python to java, but somewhat easier to translate from java to python. Although you can translate from java to python, the way of going about things in java is very different from in python, and the direct translation from java to python is likely very inefficient, whereas code written from scratch in python is likely much more efficient in python. This means that in order to learn java, I had to unlearn what I already knew from python. Even things that I felt were general coding practice felt completely different in java than it did in python, which made it really hard to learn java. So, in order to properly learn java, I had to think about the concepts completely independently of similar concepts I knew from python. Even though this was very difficult to do, I find that it actually fortified my understanding of both languages, and helped me to think about them independently of one another.

I couldn’t find anything I disagreed with about this pattern. I think that this is sound advice in general, even outside of software craftsmanship. You can’t be afraid to fail when learning a new skill, because only through failure will you learn to improve. As the Apprenticeship Pattern mentions, this could mean that you will get worse before you get better, as you’d be much less proficient using whatever new skills you’re learning than you were with your old skills. However, the point it’s making is that it’s worth it to see it through, as only then will you expand upon your skillset.

From the blog CS@Worcester – Alex's Blog by anelson42 and used with permission of the author. All other rights reserved by the author.