When I read Apprenticeship Patterns, the patterns which tend to stand out to me the most are those patterns which offer a unique perspective and an illustrative focus that is clear and easy to follow. Oftentimes when I am deciding how to proceed with my learning or implementation of code, I get lost in the possibilities, and the guidance the authors provide in this book gives me some much needed clarity.

This apprenticeship pattern is called “craft over art”, because the point of our vocation is to in the end provide a useful product to customers. The value the authors place in this section is on the practical and usable skills that makes up a good developer. The authors illustrate this point well by reasserting and contrasting what it means to be a software craft-person.

At its heart, craftsmanship is making something useful or necessary with an additional style or beneficial features that are added based on the creator’s methods. The authors definitely make this point clear when comparing software development to a craft, and even more so by comparing crafts with the arts. The key difference is that while crafts focus on making a functional product, the fine arts are focused on pure beauty itself.

So what the authors suggest we focus on as apprentices is not the beauty of the product but the functionality of it. Additionally, they describe how often in practice in order to deliver value in time a compromise might need to be made between utility and beauty.

This pattern definitely helped me hone in on which particular skill sets and goals I should be orienting myself around to be successful. Often I worry that I need to be focusing on making the most elegant code or learning the newest fanciest technology, which are definitely good things to aspire for, but in the moment of me beginning my professional journey, it is more important that I pick up practical, concrete skills, and that I focus on delivering the most value and utility. What I gained most from reading this was understanding that bells and whistles will make a product shine, but you famously cannot polish a turd.

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

The Kindred Spirits apprenticeship pattern is about how you need to keep in contact with people who are on the same path as you in order to continue learning and growing your passion. This is important because you may find yourself working in an organization that does not encourage software craftsmanship and does not provide mentors for you to follow. Working with a community provides an environment for exploration and learning that is not as intimidating as working with a mentor. However, when you are working with a community you must continue to think for yourself and not just blindly follow along with what everybody else is doing.

I thought that this pattern was very useful because keeping in contact with peers is one of the most important things that you can do if you want to stay passionate about software craftsmanship. I’m sure that many people find themselves in jobs where they are programming very boring things and start to forget whey they had a passion for software in the first place. If you are in contact with similar people, you can learn about and explore new ideas in a relaxed environment. This will allow you to continue growing and nurturing your passion even though you may be stuck in a job that is stagnant and uninteresting.

I enjoyed reading the two examples about people who followed this pattern because they showed how people were actually able to connect with each other and keep in contact to become kindred spirits. I also think that the recommended action of listing all communities that you could potentially join and going to each is a good idea. There are probably many communities around me that I may be interested in but have never discovered simply because I haven’t sought them out. Reading this pattern has definitely inspired me to find communities to join because now I realize how important it is to be in touch with other people in the field, especially after graduating college. Overall I think that this pattern is very useful and I don’t disagree with anything that was written.

From the blog CS@Worcester – Computer Science Blog by rydercsblog and used with permission of the author. All other rights reserved by the author.

          The “Find Mentors” pattern is explained as the search for when beginners start looking for developed craftsman to show them a specified path. The book explains that the first step is to find someone who is already ahead of you and try to learn as much as you can from them. Eventually, someone will take on an apprentice and you will be able to establish a better idea of your future from there. It can be difficult to get attention from a single master as they try to teach you and try to work on their own projects. This can lead to having multiple people looking over your growth to make sure that there are multiple inputs to your learning experience. The important part of this step is to make sure to not get frustrated or confused with the multiple sources of information. Masters also have their own weaknesses, so make sure that you understand exactly what those weaknesses are and how you would change your learning methods to accommodate those weaknesses such that they aren’t mirrored onto you.

          I found the Find Mentors pattern interesting because it explains the benefits of having someone who can guide you while also explaining how to further enhance your learning with multiple masters. It taught me to understand the issues of having a working mentor when it comes to workloads. I had never thought about how the masters have their own lives to juggle while also trying to teach their students. I found that the idea of getting multiple master was useful but that it could also come with its own drawbacks in some scenarios. It would be tough to find a reliable master and the more masters you have, the more likely it is that one of them may be leading you astray. This idea is what I don’t like about this pattern and I intend to apply it to my own learning. I don’t mind finding a master as long as I feel comfortable double checking them to make sure that everything, I’m learning is correct and won’t harm my growth. Other than those drawbacks, I understood and enjoyed this pattern. It’s repetitive nature of the learning process for students is easy to grasp which makes that much easier to apply.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Similar to last week, I continued to read through Chapter 5: Perpetual Learning. This time, the pattern I am writing about is Learn How You Fail, and I’m finding it extremely relevant to my independent study at the moment. The pattern itself discusses that the path to success isn’t just all about learning and knowledge acquisition, but that it is equally important to pay attention to how your learning progresses and analyze why it stalls when it does — because it will stall. Sometimes we have behavioral patterns that negatively influence our ability to learn and perform. Once we become conscious of these behavioral patterns, we’re faced with a choice. You either accept that you will not change and attempt to collide with the issue forever, or you work to fix the problem. In the world of software development, this pattern may come up where there are gaps of knowledge in things that you have failed learning before. When you come across this, try sitting back and examining the trajectory you were on when you originally attempting to learn it and recognize what caused the interference. Try to reiterate on what mistakes you made originally, and intentionally spend time on those issues.

This pattern was particularly good for me to read at the moment because I’m attempting to tinker with the MINIX 3 operating system for my independent study and feel as though I’m struggling to make progress. I’m a fairly reflective person and I try to recognize any mistakes I’m making so I can work on them, but sometimes when something causes much stress and feels overwhelming it is very easy to get sucked in and forget the bigger picture. Taking time to step back, create a new plan of attack, and going at things from a different angle is key to overcoming obstacles. There is always an angle that will work, and it does just take finding it sometimes.

This, perhaps above any other patterns so far, may be the most important lesson to take from this book. It can be applied to every aspect of life and is absolutely critical for success in a field. Not only for success, but for staying in the right mindset (and for staying humble) in your advancement. Recognize that everyone, including yourself, has made and will make mistakes. It is precisely how you proceed forward from those mistakes that makes the difference in the long run.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

This method talks about how there are tools that we need to master but we may not always understand how to master them. A lot of the times we try to be a master of all, when in reality that doesn’t necessarily work all of the time. What I mean by this is that when we are faced with  a task, sometimes we think we understand each little aspect of the specifications. However, upon actually tackling that task, we aren’t really sure where to go. Like one of my previous entries on “Exposing Your Ignorance”, confronting your ignorance really focuses on selecting on skill, tool, or technique and really honing in to fill gaps in your knowledge about it. One of the points in this method that really caught my attention was it’s mention of humble, ignorant, and dependent team building. If you are working with a team of developers and each team member has this ideology that everything is “just because of the way it is”. this can lead to a multitude of problems.

One of these problems is bad team building. When you assemble a team of people for some sort of project, you want to be able to work together to share ideas. If a problem arises you all want to be able to come together and understand what the issue is so you can solve it as a team. If you all think that things are just the way they are because they are, this can often lead to disagreements among team members. Some team members might even think you are against them just because you disagree with them on something. It’s this idea of confronting your ignorance that is vitally important to understand. You should learn one thing at a time, that way when a problem arrives, you can put aside  what you know, and focus on what you don’t know. Failure in a public place can be embarrassing, but it is exactly these failures that make it better. If you failed at something, you wouldn’t want to be ridiculed for it. Instead, you should learn from it and always be willing to learn more and more about the issue.

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.

To continue with chapter four “Accurate Self-Assessment”, int his chapter we learn how to assessment ourselves. We learn our value in the team, how to work with each other. Everyone is beginner of craftsman at one point. We all at some point is a new apprentice on a project. This is where you’re unsure of your place on the team, and the team is unsure of you. This is not just when you are new software developer, its also apply to you are new to the group.

“Sweep the Floor”, a job not a lot of people want to do. Everyone in the group should contribute same amount of work, but that’s not always the case. Most people would want to be the best craftsman, but there are other important job that need to do. One way I discover while at school, to get group trust when you are newbie to the group is be active volunteer for work. We want to show our desire to work, it is the easy way for group get to know you. Also, a great way gets to know how the group operate/code design from bottom up. For example in the book, task as “maintaining the build system, production support, responding to maintenance requests, bug fixing, code review, eliminating technical debt, setting up the project wiki, updating documentation, acting as a sounding board for other people’s ideas, and so on.” This is do so for the group benefit. There are also a few negative consequences, your teammate also takes you wrongly as someone who doing job that no one else will do. You will not have opportunity to do changeling one. If we know our value, though our hard work we can earned their trust. With this mentality, we have the flexible to be in any environments. This also apply when there is other new addition to the group, you can understand them and show them the right way.

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

This week, I read all about an apprenticeship pattern titled Be the Worst. This pattern details the benefits of being surrounded by people who are smarter than you and have more experience than you. The idea behind the pattern is that the more time you spend around others, the more information you can learn from them. Why spend your time figuring out a problem somebody already solved when you can learn the veteran’s way of handling it from a colleague? Surrounding yourself with more advanced developers can help build your skills and gain experience in ways you wouldn’t if you were learning concurrently with them.

This is a pattern I can absolutely relate with from experience. Some of my best classes where I learn the most are the ones where there are a few peers above my level to help me learn what they already have. Sometimes, the way someone explains something to you is difficult to make sense of, but another peer can explain it in a way that makes more sense and is easier to understand. Similarly, working with many people above your level gives you a wide variety of different methodologies and ways of doing things, which can help illuminate best practices and start insightful conversations.

The alternative, being the smartest person in the room, can be very unchallenging and doesn’t give you any room for development. It is nice to Share What You Know, but if that is all your doing it can be hard to progress your personal goals. A large disparity in the skill level of developers causes more time to be spent on closing that gap rather than working on the project at hand.

The challenge with this pattern is more the emotional toll it can take on you to be surrounded by smarter people. Being the dumbest person in the room can be beneficial from a self-centered learning perspective, however it can definitely feel a little embarrassing to be so far behind everyone else. Being able to swallow your pride for the development of yourself and the team is a challenge, but the rewards are worth it.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.