Category Archives: Week-2

Apprenticeship Patterns: Finding Mentors

We all have people we look up to, those who we see as guiding lights in the unpredictable lives we all live in. These special few, these mentors can be anyone, from friends, to family, to anyone in between. Having a mentor does wonders to the process of learning as well as providing a source of motivation and consultation when you find yourself struggling or at a dead end.

In ‘Apprenticeship Patterns’ by Hoover, Dave H., and Adewale Oshineye we see the pattern of seeking mentorship described in detail. Consider being an inexperienced software developer who has run into dead end after dead end while developing a new piece of software. Often we turn to those more experienced than us for insight into our problems and this case is no different. We seek out anyone who has had a similar issue and ask what they did in that situation.

Finding a master craftsman and learning from them is the goal of all aspiring apprentices and an ideal that we all seek. This however is often very rare today so many of us will find mentors who we can gather advice from regarding their own past experiences. Our field is relatively young and often changing, leaving few master craftsmen to teach those who are just starting out. Along with this many of these masters may not be physically available to you. This is where the mentors arrive to fill in the gaps.

Weather they are a coworker, a dear friend, or an anonymous individual online, a mentor can mean the difference for many software developers out there. They can offer insight on their prior experiences that may mirror your own, expose you to new ways of thinking, or just offer genuinely good advice. It is just another way to break your coding block when you find yourself stuck with a nonfunctional or misbehaving program you are attempting to get working.

With that said however, we all ‘walk the long road’ at the end of the day (Apprenticeship Patterns Ch 3). and finding someone to guide you can be hard so I will leave you with a recommended course of action by the authors. Find a library, or community with an active mailing list and being observing any messages left there. Over time you will pick up on the values of the community and which members are patient and willing to teach others. At the next opportunity, seek them out and establish that first connection with them in order to see if they would be interested in offering any informal advice or lessons they have learned over their time.


Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Craftsmanship Log #1 – My First Language

In the first Craftsmanship post I made, I mentioned that I am reading through Hoover and Oshineye’s book named “Apprenticeship Patterns”, which outlines certain patterns that inexperienced software developers may adopt so that they may overcome any potential hurdles during their personal learning experience rather than providing technical solutions. In fact, in that very post I mentioned (though not by name) two of such patterns, namely “Craft over Art” (introduced in chapter 3) and “Record What You Learn” (introduced in chapter 5). Though I may expand on these two particular patterns in a later post, I want to first address my reactions to one of the very first patterns that are introduced in the book, namely “Your First Language”.

            Briefly put, “Your First Language” is a pattern that is meant to address a software developer’s potential issues that may arise due to the fact that, though they may know multiple languages, they lack sufficient fluency in one of them. As such, such lack of fluency may put the developer in a difficult position when they are needed to work on a project that needs to be in a specific programming language. In this case, the book suggests picking a specific programming language to learn and master, preferably one that is used by any experts one might know. Now, it is important to specify that “learning a language” is not simply achieved by reading some resources related to a specific language, but by using that language to solve problems and actually apply what has been learned. Thus, by continuous application, a software developer may hone their problem-solving skills, which then may help them in learning other languages as well.

            While I personally found this pattern to be particularly helpful when I first started studying Software Development, I feel like my experience has changed the way I approach specifically learning a programming language. Though becoming fluent in a language is important, I believe it is also important to be proficient in the learning process itself. In my case, while I was learning my first language, I also made sure to internalize what that language was composed of in terms of concepts and structures I could use so that, when there is a need for me to switch to a different language, I would have some expectations as to what concepts I should expect to encounter and only worry about syntax while learning the new language.

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

Find Mentors

Self-learning is one important quality of any programmer; however, self-learning is not always useful since the learner might not know what is waiting for them and if their approach is good or not. In this case, every learner needs mentors, those who already achieved what we are working on or at least, they have deeper knowledge about the topic that we are learning.

Whether a beginner starts out with a training course or is self-taught, the first step on the path to software craftsmanship is finding a craftsman to apprentice himself to”

–Pete McBreen, Software Craftsmanship, p.96

From my own experience, I find this statement can’t be more accurate as I find myself learning more productive when I have mentors to show me what I should do compared to learning by myself. However, as in the book illustrated, as an apprentice, it can be difficult to tell who is truly a master craftsman. Therefore, an apprentice should follow a set of mentors that each one will show them a bit of a huge picture. And the set of mentors here counts not only “real” people who we should have already considered them as our mentors to learn, our friends and our professor, but also the active community we could find online to exchange information with people on it.

Besides, according to what was written in the book, an apprentice shouldn’t expect their mentors to know everything and get disappointed if mentors don’t know what we are seeking for as the current mentors could be other’s apprentice, we are all walking on a long road. Because our field is huge, a person who can guide us through 10 in-built React hooks may not be able to show you how to design the API route and vice versa, these twos are completely different topics and what we probably need is to master a specific set of skills that we desired; but it’s obviously the more we know, the higher opportunities we’ll have.

In conclusion, what I learned from this chapter is that I should find a community and actively communicate with other members there. Luckily, I found myself on a discord channel of one of the biggest Vietnamese tech forums, J2Team, having a community of developers exchanging lots of quality contents.

A channel in J2Team server

Now, I should consider posting my first message here and seeing where it will lead me to. 

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

Unleash Your Enthusiasm Pattern

This week I decided to read about the apprenticeship pattern ‘Unleash Your Enthusiasm’. The meaning behind unleashing your enthusiasm is that there may be something that is holding you back. Just like the pattern says, you have so much enthusiasm that’s ready to be release. The example that the book uses, is that software developers, you will more than likely be working as part of a team. Usually when working in groups, there is something called a norm which is what everyone follows. No one tries to stand out or if they did, they would find themselves in an uncomfortable position.

My initial reaction to this pattern is that it can relate to more than just software development. It can be compared to the outside world. For example, who you choose to have as your friends. In my instance, I used to have a circle of friends I used to ‘confine my enthusiasm’. Eventually I learned that they were holding me back from furthering my life from being greater. Once I started being myself, things naturally got better for me. My life got overall got better ever since I hold myself back. Just like how some new software engineers that start their first professional jobs confine with the norms. They become held back because they don’t want to speak up and voice their own opinions which then results in them becoming an ordinary worker who doesn’t stand out.

After reading the pattern, it has definitely made an impact to how I view myself working in a professional environment. I tend to be a quiet person when working in teams but lately have been more active and more vocal in the teams I am in at school. By doing this, I believe it will help me get out of my comfort zone and allow myself to ‘unleash my enthusiasm’.

This pattern can be applied to not only for software developers, but to their personal lives as well. I would agree with what have been said in this pattern because the meaning behind it, is to just let loose your ambitions. In order to grow and further your career, you can’t become a person who holds themselves back. There are times when staying in the norm is okay, but overall, it’s better to stand out because that is how you will get recognized.

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

Breakable Toys- log 3

This week, I read a pattern called Breakable Toys. This pattern occurs when an apprentice needs an environment where the apprentice is allowed to fail and redo his projects as many times as possible. The main purpose of this environment is to make apprentices or software developers feel free to make mistakes and they can learn from failures until they succeed or until they have a deep understanding of a concept. To solve this problem, the author recommends to his readers a solution called Breakable Toys which can be broken many times; and the consequences of the failure will not affect anyone else, except the person playing with the breakable toys. The breakable toy here can be anything that an apprentice can use to practice techniques, try out new ideas, or to learn new things. Furthermore, breakable toys should be relevant and useful to your life, such as building a wiki, calendar, address book, or game. A breakable toy also should be fun to ensure that you enjoy playing with it and can stick with it long enough to learn everything you need and to enhance your essential skills.

For myself, this pattern is really interesting because it is similar to a method I have taken to learn a new concept or to practice a technique. However, after reading this pattern, I think I have used breakable toys to learn computer languages ​​in the past. To learn the Java language, I wrote some programs that are used to manage a coffee shop or a bakery. My programs would take input from the customer to place an order, then print a receipt, but at that time I didn’t know any tools to store those data into a system. Fortunately, I had the opportunity to learn about MySql, a tool that helps me store and manage data of a system. So, I tried to develop those programs to link them to the database in MySql. That way, I can play with the Java language and also gain a deeper understanding of how to use MySql tools. Furthermore, I have also applied the breakable toy method to learn python language. I wrote some of my own games in python with simple ideas after watching a few tutorial videos on YouTube. Although they are just simple games, it is a great environment for me to play with what I want to learn. On the other hand, I can also freely break the code at any time without worrying too much about the consequences. In conclusion, I believe that breakable toys is a good method for software developers to learn and to experience any tools from zero to hero.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.

Expose your ignorance

This week, I chose to write on the pattern “Expose your ignorance.” This pattern describes how a company pays you to work as a software developer and expects you to know what you’re doing. The issue is that you are inexperienced with some essential technologies, and the manager and staff require assurance that you will be able to deliver the software on time. Everyone around you, including your management, client, and coworkers, as well as yourself, is under a lot of pressure to provide software. When individuals ask how long feature X will take you to complete, you can sense their demand for assurance in their eyes. Asking questions is the most obvious method to reveal your ignorance. This is easier said than done, especially when the person asking assumes you already know the answer.

This pattern, in my opinion, is critical for anyone who wants to or is now working as a software developer. At first, I assumed that becoming a software developer was all about learning which programming languages and which ones are the best.
But, in the end, it’s all about how quickly you can solve the problem and provide the finished software. I liked how this pattern encourages people to ask questions even if it means sacrificing their pride and dignity, and I believe it is the most significant thing I learned from it. One of the most significant skills a craftsman can have is the ability to learn new things, identify areas of ignorance, and seek to eliminate them. Ignorance, like dry areas in a garden, can be reduced by planting seeds of knowledge. Experiment, practice, and reading will help you water your seeds. You can choose to hide these bare patches from the light, embarrassed by their size, covering them to keep your pride intact. Or you can decide to expose them, being honest with yourself and the people who are depending on you, and asking for help. I really liked this pattern as it says to get rid of your ignorance or find your ignorance even if it means to sacrifice your pride. It is all about having the ability to learn new things from others and asking for their help in need. By the end, you will have in depth knowledge of a few threads of technology. With these threads, you can weave together robust software applications on a few platforms and domains.

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

Be the Worst

For this apprenticeship pattern, I chose Be the Worst. This pattern is about joining a team with much greater skills than yourself in order to learn from them, and as to not stagnate your learning by being on par, or more knowledgeable than your other team members. The issue with this concept is that if you join a team of members much more knowledgeable than yourself, you could be seriously behind and unable to complete any of the tasks required by the team, thus becoming deadweight and dragging the team down. The solution it proposes to this problem is for you, as a less knowledgeable member of the team, to do the more menial tasks.

I think this is a really clever solution to this problem for a few reasons. First, it allows you to still help the team, and not just be deadweight or an observer. If you were actively slowing the team down, or worsening productivity, then they would want you off the team, so it’s important for you to still be contributing something worthwhile, even if it isn’t huge. Second, since you’re doing menial tasks, it’s likely stuff that other team members don’t like doing or would rather someone else do. They would be better off using their time for more advanced tasks, so by doing the menial tasks you’re helping them and saving them time. In this way, it actually leads to more productivity for the team. Lastly, by doing menial tasks, as long as they aren’t too difficult, it means that you can still conserve most of your energy towards learning from the other team members.

I think this apprenticeship pattern presents strong and useful information, and I couldn’t find anything I disagreed with. I could relate to this pattern because I have been on teams where I was either the most or least experienced, and I didn’t like either one. Being the most experienced, you will always have to help out the other team members, while you could maybe be more productive doing other tasks. Being the least experienced, you often feel like you aren’t doing or contributing enough. This pattern has changed my view, as I now think that being the least experienced is better than being the most experienced, and I used to think the opposite.

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

Reflection on the Long Road Apprenticeship Pattern

The Long Road is meant to temper expectations. It lays out the path to mastery of software development as one of lifelong learning, and not one of chasing wealth or position. It is about taking jobs and opportunities that will help you continue your journey to gain more experience and knowledge and to prioritize this over promotions and salary raises. It is about finding the knowledge at the heart of software development.

I think that not only is this pattern good advice to software developers but offers good life advice as well. I personally believe that life is about the journey and that new experiences and gaining more knowledge is far more important than gaining more monetary wealth. I don’t care too much about money in general and I think that having this mentality about moving forward in my career lays out a life that will leave me a lot happier and more content when it comes time for me to leave it all behind. I didn’t get into computers to take a middle management job, I came here so I could enjoy what I do and get really bloody good at it. I just found the part about growth over wealth to be such a good way of looking at software development, and I think is kind of the opposite of why a lot of people get into it. I feel like a lot of people get CS degrees because they want to make money, and not so much for the love of the craft, and I think that’s just a path to disaster. I hope I’m wrong, but if you can learn to love the journey I think you’ll have a lot more fun along the way.

However, I do disagree with the notion that this pattern (and this book, as they say) is not However, I do disagree with the notion that this pattern (and this book, as they say) is not for people that want to take different paths. I think it is entirely reasonable to believe that even those who don’t want to continue a software development career for their entire lives still want to master the craft and continue their development journey even if they choose not to continue down a career in it. There are many people who don’t pursue full-on careers in software development, but still love coding and want to continue to grow their skills. Hobbyist game designers or developers are out there, and I think that that choice is completely valid and that this pattern still applies to those that choose something else. I just don’t like the gatekeeping nature of that comment in this pattern. Mastery does not necessitate a career in development. Do what you want, and enjoy the journey.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

Read Constantly

This is the first in a series of short blog posts I will be making about the book “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye, discussing individual patterns from the book. This week I am looking at the pattern called “Read Constantly” from chapter six.

The scenario this pattern covers is one in which a programmer is feeling overwhelmed by new information. This is happening even in spite of a good amount of proficiency and enthusiasm. The proposal here is to read constantly in order to catch up on old developments in the field and stay ahead of new ones as much as possible. This also means prioritizing denser sources of information such as books or occasional research articles over things like blog posts, for example. The authors also suggest keeping a small (and thus easily portable) book on your person at all times to read whenever you have downtime.

I don’t really read as much as I would like to. It’d be good to do more reading, especially about the software field, so I think that is useful advice. I have some issues with the framing of this pattern, though.

I don’t fully agree with the outlook of “catching up” to people like Linus Torvalds, who the authors namedrop here, or with how the authors view people like him. I don’t think, taking Torvalds for instance, that he got where he is purely through effort. This isn’t to say that he’s lacking in talent in any way – rather that he got where he was through a combination of being a highly motivated person and being in the right place at the right time in the industry. I don’t think you can make up the latter part through sheer effort alone. I view it as sort of like the lottery – it’d be nice, and you could increase your chances by buying tickets regularly, but it’s misguided to have winning the lottery as a goal when it’s ultimately out of your control.

I think it’s good to read more, of course. I just don’t agree with constant reading specifically as a way to stay “competitive” in the software industry. I do not have the background to make this kind of claim, but I also suspect there’s diminishing returns when you try to cram as much information into your head as possible.

Having read this section, I think I will actually read more, or at least make some effort to. I’ll also probably try to read more about programming and technology specifically. I just don’t think I will take it as far as the authors recommend.

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.

Your First Language

This week I chose to write about “Your First Language”. The problem laid out in the beginning of the chapter is that the apprentice only knows basic knowledge of a few languages. This is a problem I have spent some time thinking about. But it is difficult for me to pick, which language I want to fully dive into. I have programmed in Java, JavaScript, C#, C++, and Python. I know the Java standard library better than any other language’s library. And I know the data types, and data structures better in Java as well. Java is what I learned in Intro to Programming, and Data structures. Java is also what I use for coding interview prep. Many of my peers are language Evangelicals, but I feel like a man without a country. I have never built anything in Java, that wasn’t an academic project, or a coding interview problem. I have used JavaScript and C# do build web apps. With all of this being said, I knew I needed guidance from this design pattern.

The author suggests that the apprentice choose one language to solve problems with. And stick with that language for years. And that his first language will be the basis on which he solves problems. For me, I think I am going to let fate decide. Whichever language I need for my first job, that language will be my first language. Many entry level software job postings just say ” “proficient in one modern language” and the assessment can be taking in any language. The author suggests that the apprentice seek out an expert in the language, so he learn from the expert. When I am on the job, I will have access to experts, and a lot of time to learn. For now, I will keep practicing LeetCode in Java, and build web apps in JavaScript for this course. I don’t have time for much else. But this design pattern has made me realize how important having a strong foundation in one language is, and I am eager to start working towards that goal.

From the blog CS@Worcester – Jim Spisto by jspisto and used with permission of the author. All other rights reserved by the author.