Be the worst is an apprenticeship pattern from chapter four that focuses on surrounding yourself with people who are better than you in order to constantly keep improving yourself. The chapter argues that if you are the best in your respective group then you will not grow and improve as a person.

I whole heatedly agree with a majority of the points made in this apprenticeship pattern. From personal experience alone I know that this idea holds true. While in a classroom environment I am definitely not the best, but I am also not the worst. I tend to work with people at a similar skill level to me when I work on group assignments or in class work. While I still learn things in these environments, I know that I miss out on more nuanced knowledge that’s gained by experience. In an environment where most if not everyone is better than me, I could learn things from people that I would most likely not learn in a classroom environment. During my internship I was surrounded by talented programmers, and as such I was taught many different tips, tricks, and skills that I probably would not have otherwise learned.

Another thing I really resonated with in this pattern is the fear that being the worst in the team will result in lower overall performance or cause me to hold others back. This idea is daunting, but it also lights a fire under me and forces me to improve in order to keep up. One thing I do not necessarily agree with is the statement that joining a team as the worst member is selfish. I do not thing that is true, as long as you join that team with the intention of working harder than everyone else to keep up and improve. The team also may benefit from you joining, since because you may be inexperienced, you can potentially learn new ideas quickly and the team may be able to mold you to their needs as a result. This can be a win-win for everyone, you continue to improve yourself while the team gets to mold you to their needs.

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

The pattern I decided to read is titled “Draw Your Own Map” from chapter 3 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern was about taking ownership of your professional career as a software craftsman. We learned that in many jobs, you may get pigeonholed to do one particular thing when you may be passionate about learning or doing something different. This passage reassured its readers that they had options and didn’t need to feel trapped, or stuck. By spending some time reflecting  and drawing your own map, you can make career choices that feel empowering instead of limiting.

One of the most thought-provoking points that was brought up in this reading, has been mentioned before and I think I have highlighted in a previous blog post but I would like to reiterate it here because it continues to resonate with me. This pattern mentioned how sometimes it is better to “move into a less hierarchically impressive role in order to stay “on the map.””. Especially if staying on the map is, “more congruent with your goals and will lead you to greater heights in the long term.” This resonates with me because I want to make decisions that are aligned with my goals and beliefs in my professional career, even if that means making some temporary sacrifices.

As far as how this pattern has caused me to change the way I think about my profession, it has encouraged me to either make career choices that open up opportunities or help me  pick a specialization I am passionate and confident in. While my first job after graduation is likely going to be something to get my “foot in the door”, after some time in my first job, it is important for me to spend some time thinking about what the next best step is going to be. My first job is likely going to teach me a lot about what I like and don’t like and it is a place where I can see my interests developing as a software craftsman.

Lastly, I’d like to mention that there isn’t anything in this pattern that I disagree with. It has encouraged me to start thinking about my own map and it has made me peek at some new potential patterns for me to read next (e.g. Expand Your Bandwidth, Use Your Title).

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

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.

If you haven’t noticed already, there seems to be a trend of various coding practices that I tend to agree with. This is not merely a case of “kissing up” to the professionals, but rather it is the fact that I know I have been taught from the ground up by well-respected individuals. Many of the practice patterns found in “Apprenticeship Patterns” are ones that I have already been aware of, or still agree with despite their novelty. An additional agreement to add to this repertoire is the importance of “Your First Language”.

For me, this “first language” was C. To be honest, I don’t feel like there is a better option to select. C is an excellent, “mid-level” language that follows many of the practices found within my studies. For example, in “Apprenticeship Practices”, the book warns of becoming stuck within your “native tongue”; I feel as though this is negated (or at least parried) by many of the practices in C. C works closely with hardware, and involves skills found in assembly language, but can also be used to emulate higher level languages such as Java.

When it comes to my professional career, “my first language” is a philosophy that has given me a greater appreciation for the diverse landscape of large-scale projects. The C language has elements similar to Python, such as arrays. While data structures are not an impressive connection (they can be implemented among pretty much any language), it does make crossing the gap easier. Once at Python, I can learn about dictionaries, “key: value” pairs that can have an ideological equivalent found in .yaml files and JSON, and so on.

Interestingly enough, despite the emphasis on programming diversity, the pattern stresses finding a first language and staying strictly to its community. I feel mixed emotions about this philosophy: on one hand, it sounds as though “bridging gaps” found between languages should be avoided. On the other hand, constant practice is the best way to learn a first language, and that practice can be boosted by feedback from a desired community around that language.

Overall, I have an appreciation for the idea that beginner programmers should stick to one language when starting out. However, if I were to make a suggestion for that first language, I would suggest C. While challenging to learn, its connections to other languages and diverse applications can make powerful programmers.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.