Monthly Archives: February 2022

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.

Bibliography:

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.

Week 2: Apprenticeship Pattern Chapter 2

For this week’s reading, I decided to read the pattern ‘The Deep End’ in Chapter 2: ‘Emptying The Cup.’ The context was taking small safe steps has led to unsatisfactory progress and has lead to not a plateau, but a rut. In a rut, it’s worse than a plateau, your competence decays into mediocrity. The problem is you need to progress your skills, your confidence and portfolio. Already, I began to relate to this pattern because I’ve fallen into the trap of being complacent with my skills and not ‘honing my craft.’ It’s a pretty bad place to get stuck in, I really would not recommend falling into this trap. For someone like me, it was really hard to get out of this spot in my life, even now I still feel like I’m plateauing, maybe even in a rut, but the first step to preventing this is to be proactive and push yourself.

The solution was practically the same thing I just said before, to push yourself, jump in the deep end. Basically, try to take the high risk high reward tasks in life that will significantly push you toward a higher knowledge is how I interpreted this pattern. Pushing yourself too hard will only set you back and you won’t have a significant enough takeaway from that high risk task you did. To which I agree with, although I can’t say that I have put
into practice this solution in my life yet. I have been too complacent for too long, it was only recently that I decided to try and push myself. The mental setbacks with myself make it very hard to push through and gain that knowledge that I seek but can’t perserve to but every day I try to tell myself that this is the day.

As for the action for this pattern, it basically says to write your projects down in a chart to path how your career is moving in complexity. At least,
that’s how I saw it. To be honest, I didn’t know what the action meant, I thought it was a second solution but after reading this it kind of makes sense to me but
I still don’t understand it. Perhaps I should put it into practice to see how my progress is going.

From the blog CS@Worcester – Brendan Lai by Brendan Lai 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.

Chapter 3: Walking the Long Road

This chapter has talked about how to start your career with low expectations if none at all. For example, Gustav Mahler, musician and composer has talked about the life of Dave in his career. As I paraphrased like this: Dave had his own cubicle and, despite having even less experience than he does today, he kept a stack of certifications by his desk. The stack began with a Perl “master” certification from Brainbench and grew to include certificates demonstrating he had completed multi day trainings in C, J2EE, Vignette, and ATG Dynamo. This modest stack of pseudo parchment comforted him (and his organization) that he was in control of his situation. He’d been “schooled.”

Meanwhile, through http://perlmonks.org and the comp.lang.perl.* newsgroups, Dave had begun to expand out and communicate with the broader developer community. It was in these groups that he met some of the best Perl hackers he’d ever met. The hackers’ knowledge was intimidating, especially because Dave could tell that they were still learning and learning quickly. It seemed to him that he had just begun to scratch the surface of what it took to be a great software engineer. His stack of training certificates gradually vanished beneath a greater mound of scratch paper and printouts of book drafts and lessons during the next few months.

Dave was captivated by the learning process after observing and interacting with a couple of these excellent hackers. Periodically, he’d catch a glimpse of the hackers’ expertise and be either disappointed or inspired—discouraged by how little he understood yet inspired by the force of these hackers’ abilities. He got into side projects and started reading everything he could get his hands on.

The more Dave knew, the clearer it seemed that he still had a long way to go. Over the next few years, he had the wonderful opportunity to work with some excellent software developers face to face. Even though these extraordinary people were miles ahead of him, Dave saw that they were all on the same path.

The Long Road

There are many different patterns that resonate to me, but The Long Road is the best one to me because it explained what type of expectations you should have when you want to be a master software craftsman, but your ambitions are at odds with what others expect of you. Rather than gradually improving your skills, conventional wisdom advises you to take the highest-paying job and the earliest promotion you can get, to stop programming and move on to more important work. Accept the possibility that you will be perceived as odd for what you desire to become. Second, maintain a long-term perspective. Prioritize learning and long-term growth prospects over money and traditional ideals of leadership throughout your apprenticeship.

From the blog CS@Worcester – Site Title by proctech21 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.

Digg Deeper Learning Pattern

This pattern is a great idea for a beginner such as me. It offers a way to complement the lack of knowledge that comes with the lack of experience. It should be used carefully because of the ease of wanting to just reinforce the skills you are already good at. Knowing a little on a lot of subjects will not help getting things done and knowing a lot in just one subject will get you just as far. The secret as I see it is to have a good toolbox and know how to at least hold each tool. As you need to pick up each of these tools you learn about them more in depth but not too much to hinder your progress. As you shuffle through this toolbox picking up things you need and not obsessing on one tool you build a hierarchy of depth in the knowledge of things you need most. We will handle the same tool more than once and every time we do, we should dig just a little more.

The author presents a more all in version of the dig deeper which I think is the philosophical normalized world idea. It would be nice if we had the luxury of tunnel vision and look for the PhD dissertation of the original design algorithm for every tool we use, but it is also the easiest way to fall into a deadlock. I find that in school it is very hard to get in depth knowledge on every subject as much as I want. Time and time again I see myself compromising and kicking the can down the road, because I do want in-depth knowledge in some subjects, but there are time sensitive co-responsibilities that need immediate attention. Although, as I said earlier, some of these tools that I want to understand better come up again and again over the semesters and I do indeed gain a little more ground on understanding them.

I believe the author is right when he says that we need to learn to dive into ever lower levels of understanding.  By lower I mean from specific to general and by specific, I mean not only the surface high level function you need. The author does throw a little caution which I also mentioned earlier. The risk of becoming what some call a one trick pony.  The balance is really hard to define, and it is very personal. I don’t have my own balance definition yet, but I hope that with time this too will come.

From the blog CS@Worcester – technology blog by jeffersonbourguignoncoutinho 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.