Category Archives: Week-14

Nurture Your Passion

This week I decided to right about Nurture your passion. As I finish my academic career and move into the professional world, nurturing my passion is something I will be conscious of.

The problem laid out in this pattern is that the craftsmen is working in a workplace where his passion is stiffled. I think that everyone will experience this. For my part, I have gone to long team meetings that felt like they could have been half the time. And that is one of the best problems to have. Work places can be toxic, or there could not be oppurtunities to learn and grow. With this problem explained, Dave sugguests that the craftsmen should look to nurture his passion outside of his job.

There are a few ways to do this. One is my making interesting side projects or Breakable Toys. I could see this being a nice change of pace, where I could focus more on learning instead of meeting the deadline. Another solution is to meet kindred spirits. Dave suggests meet up groups. One thought I have here is that if I am coding for six to eight hours, five days a week. I may not feel like building breakable toys, or going to meet ups. I like writing code, but not everyone has time to write open source in addition to working a full time developer job.

The action Dave recommends is to write three positive ideas down to bring up at work everyday. And bring one up if things turn negative. Finding happiness and positivity at work is important for anyone. So I think is is a very meaningful pattern.

I think the best advice here is that if the craftsman finds himself at a firm that stiffles his passion, it is time to move on. This piece of advice is very relevant now as we are in the midst of “The Great Resignation”. I think finding a job that a craftman can at least partially nurture his passion is very important. We spend so much of our lives at work. So it is very important to find happiness there, if possible.

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

Apprenticeship Patterns: Chapter 4 Part 2

Sweep The Floor

A common stereotype amongst movies and literature when an apprentice first begins their work, they are handed a menial task and told to perfect it. Often sweeping or “wax on, wax off” from the movie Karate Kid, the task being grueling and numbing in a sense. This task assigned to you wasn’t to demoralize you or just give you something to be distracted by, it was to get you ready and perfect a skill by practicing frequently.

As an apprentice you are nearly always going to be on the lower rung of experience and will find yourself doing work closer to your skill level. With programming the metaphorical broom might not be clear, or obvious. Instead of waiting for instruction you should take the initiative and volunteer for things. Take a task that you can complete or learn to complete and lighten the load of others.

This won’t necessarily seem like sweeping the floor but in a sense you are taking the tasks that will help yourself and the team you are aspiring to become an essential part of. I understand this aspect fairly well absorbing this concept through admittedly far more media than I should have, but I agree with this pattern pretty much wholeheartedly. Being apart of the group and not being as skilled as them is fairly demoralizing, but taking the lesser tasks can still make you a vital part of the process while you make the effort to become as skilled as your group members.

While learning and developing your skills you do have to step back and learn the basics. Focusing your skills and learning the essentials is integral and necessary. It’s also usually the tasks that most don’t want to work on. Mind numbing maintenance and formatting is one task that higher level workers dread maintaining. These tasks are necessary and vital to the projects success and someone needs to do it. You might as well put yourself into the problems you can solve and along the way you will learn things vital to improving the project and increasing your skills. To learn the basics is to master them. Sweep the broom before you place the first brick of the new structure. Stack bricks thousands of times before you can build a sturdy wall. This pattern is to take the mindset of the novice within your group and how as an apprentice you can learn while also helping out your group.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Chapter 4 Part 1

Find Mentors

When first understanding how you learn, and the general experience of how human beings learn, you’ll find yourself in a situation where you want to learn something, but you don’t know how to go about learning it. You take your first stab at it and find that you are learning some things but not learning constructively. You blunder around accumulating random knowledge and at some point, you might experience some success and get lucky. But more times than not you’ll blunder around and this effort might demoralize. The fault was not in your but your methods.

Mentor-ship and finding mentors is critical to learning something more specialized within your own skill set. This apprenticeship pattern perfectly describes an issue that I have frequently run into myself. It describes this path as exploring a blind alley, and this is an apt description. During my first sprint during my computer science capstone I made an effort to try and learn HTML. I looked over some example code and learned generally how to write it but fundamentally I didn’t understand how to structure it. I was blindly exploring the learning process and was failing.

I felt how I was failing and I knew I needed to reach out to something far more similar to a teacher. Some see the name mentor but what is a mentor but a highly skilled teacher. Yes of course there is more to teaching than just knowing the skill but they have the knowledge of learning the skill you are trying to and the path that helped them succeed. You need to find yourself a path that has been traveled by a human instead of blindly traveling that avenue.

I sought an actual HTML course that is commonly available in YouTube format and learned in a structured manner from a person who understood it as a whole. Now this isn’t to deter you from learning something new without a mentor as you do need the ability to learn new things without help, but something completely foreign to you requires a teacher. Mastery of a subject will require a mentor. Both require a desire to learn and to realize when you should seek other’s help.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

Breakable Toys


I have chosen breakable toys for this weeks Apprenticeship pattern. Breakable toys pattern is about learning through our mistakes. The pattern explains that we work in a high pressure jobs and environment and understandably success is expected or at times even demanded of us. However, pattern also recognizes that failure is the key to success. By failing and discovering our faults, our flaws is a crucial step in the process for us to grow, learn and build on our experience which all in turn eventually leads us to succeed. Pattern emphasizes the importance of step one for any work we are attempting to complete. First step needs to be just that, the first step – a simple README file in Gitlab with a rough structure what we are working towards is as important as every code we write and every feature we experiment on.

Why this pattern?

This is one of the most important if not the most important Apprenticeship Pattern I have come across. There many external factors affect the work that is being done like time restrictions and financial restrictions which prove to be nothing but a hindrance. This year, I had to keep learning new languages like R, python, JavaScript, mocha and chai and services like docker, R studio, VS code, Jupiter, anaconda, etc. I cannot count how many times I have been stuck on some piece of code, spiraled down because I knew failure was unavoidable and start feeling the paralyzing fear take over.

Knowing and remembering that failure is as important as success in a learning environment has helped me lot. Organizing my failures as a software developer proved to be as important as completing building our backend because It’s not wrong to make mistakes, it’s wrong to repeat them. Pattern suggested that we should work on our smaller projects because it gives us the time to learn our tools and a safe environment where we have our freedom to fail. I have written simple codes for calculator and tic-tac-toe in python. Deployed a simple ‘Hello world’ website using AWS. To quote Thomas Edison, “I have not failed. I have just found 10,000 ways that won’t work.” The trial-and-error process has immensely helped me grow and then further implement that knowledge in my projects.

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Blog 6: Share what you learn

The context given here is that You have been an apprentice for a little while. You know a few things and people are starting to look to you as a source of knowledge. Up until now, you have focused exclusively on your own improvement as a craftsman. To become a journeyman, you will need the ability to communicate effectively and bring other people up to speed quickly. A good way to prepare you for that is to develop the habit of regularly sharing the lessons you have learned. This may take the form of maintaining a blog or running “brown bag” sessions amongst your peers. You can also make presentations at conferences or write tutorials for the various technologies and techniques that you are learning.

The books highlight that Being part of a community of individuals where both learning on your own and humbly sharing that newly acquired knowledge are valued is one of the most powerful aspects of apprenticeship. It makes otherwise-esoteric fields of knowledge suddenly accessible, and provides apprentices with guides who speak their language. That being said some lessons should not be shared, and it’s important to keep in mind that there is an ethical dimension to knowledge. Before sharing something, consider whether that lesson is yours to share. It may be a secret, or it may harm others. Things that seem obvious to you because of your current context may in fact be your employer’s “secret sauce” and it is all too easy as an apprentice to overlook the consequences (legal, financial, and political) of sharing that knowledge.

I can personally relate to the content in this pattern because I have worked for 2 years as a tutor for introduction to programming class (java) and it has helped me on so many levels. I remember my first instinct was to decline the job when the position was first offered to me. But then I took “a risk” and started working as mentor and all of a sudden, my understanding in the class material got better. I got comfortable sharing knowledge in an effective way, and I got great public speaking skills

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

Blog 5: Use Your Title

The context given here is that as a result of your dedication to learning, you have been hired or promoted (formally or informally) into a position with a title containing words such as “senior,” “architect,” or “lead”. The problem is then that your job title doesn’t match what you see in the mirror. When you introduce yourself in a professional setting, you feel as if you have to apologize or explain away the difference between your skill level and your job description. The solution suggested is not to allow your title to affect you. It is a distraction that should be kept on the outskirts of your consciousness. Use your title to gauge your organization, not yourself.

Impressive titles and responsibilities do not indicate that your apprenticeship is over. They only serve to remind you that there is a shortage of craftsmen in our industry so we should not be fooled by an impressive title. Another variant of this theme is informal versus formal titles. For instance, you may have grown into a position of authority on your team, despite your formal title remaining the same. These informal titles can be hard to ignore, because they are constantly reinforced by your peers, even if they conflict with your self-assessment. During these times, your connections with your mentors and peers will be critical to keep you grounded in reality.

I was really glad to see that the title subject was tackled in this book. So many times, I have found myself in jobs doing way more than what my title said sometimes even doing something completely different. In my current position, I am doing my job and some part of the data analyst job and at first, I got slightly annoyed but I have now realized that I would try to learn from it as much as possible rather than complain about it

I also really liked their action plan which is to Write down a long and descriptive version of your job title. Make sure it accurately reflects what you really do at work and your skill level. Keep this updated, and from time to time imagine how you would view a stranger who had this job description.

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

Blog 4: Dig Deeper

This pattern encourages us to go beyond the surface level work. The context given is that You live in a world of tight deadlines and complex software projects that use a multitude of tools. Your employers cannot afford the luxury of employing enough specialists to fill every role. You learn only enough about any tool to get today’s job done. You select a handful of tutorials on the language or library that you’re working with today and consequently You make decisions without taking the time to understand the issues, and copy the toy examples provided with the tools. The problem is then that You keep running into difficulty maintaining the code you’ve written because it turns out that the tutorials you followed cut corners and simplified complex issues. You find that your superficial knowledge of a thousand tools means you’re always floundering whenever a subtle bug arises or you have to do something that demands deep knowledge.

The solution suggested is now to Learn to dig deep into tools, technologies, and techniques. Acquire the depths of knowledge to the point that you know why things are the way they are. Depth means understanding the forces that led to a design rather than just the details of a design. In other words, it also means understanding type theory rather than simply parroting the things you’ve heard others say. I agree with what is being said because the areas where you have deep knowledge feed your confidence and they indicate places where you can deliver value early in your time with a new team. More importantly, this depth of knowledge is something you can fall back on to give you the strength to tackle new areas.  I have mentioned before how I usually run straight to google or StackOverflow in time of doubts but 95% if the time the website only provides “quick fix” type of answers and there is no real learning happening. I have understood that applying this pattern regularly, will help me truly understand how my tools work and I will no longer just be gluing bits of code together and depending on other people’s magic to do the heavy lifting.

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

Use the Source

Programming involves applying the right pattern to a wide variety of scenarios. A way to learn how to apply those patterns is to analyze how other people have done them. One of the best ways to do this is by reviewing the publicly written code by someone who has published open-source code. Reading and understanding the craft a master has created, it will spawn ideas within you as to how to improve your own programming patterns and creations.  

I find it interesting that it gets easier to read someone else’s code the more that you read it and that the faster you can comprehend code is an indication of your level of mastery. I also found it to be an interesting recommendation to use git to track the history of code over time to view how it is improved. Doing this will help you identify the type of errors that passed inspection but eventually needed to be fixed or modified. In the future, you will be able to apply the patterns you observed to the code you write yourself.

I often program using TypeScript and open-source npm packages. Oftentimes with smaller node packages, they lack full documentation of the entire codebase. When this happens, I use my IDE’s source inspection tool to look at the function within the node package to understand how the package classes and functions work. There are also times when there is a node package written in JavaScript that does not come with predefined TypeScript type definitions.

To use these node packages with type safety, I write my own type definitions by inspecting the source code for the open-source package I am using. To some degree, I have already been reading the source, but not with the sole purpose of reading and learning the patterns of the software’s author. In the future, I will spend more time appreciating that I am looking at someone else’s craft that they fine-tuned to the best of their ability. Making sure to learn and take away as much as I can from their programming. I do not disagree with anything in this pattern, as viewing the source is something that I have already made a habit of doing.

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

The Long Road Pattern

For this week’s apprenticeship pattern, I did a reading on “The Long Road”. The Long Road pattern is about your future. In this pattern it talks about trying to imagine yourself 10 years, 20 years, or even 40 years from now. They want you to think about that and possibly write down a summary of your profession. By doing this, it will enable you to think how you would want your professional path to be like and allows you to plan how things could go. The problem in this pattern is that you want to become an expert in what you want to do however, things may get in the way like that such as promotions and just always picking the highest paying job and by doing this, it takes away the goal you had originally which is to do something that you enjoy doing but instead doing jobs that in reality sucks.

My initial reaction to this, is that it is an interesting pattern to read about. It is interesting because I never thought to look past 5 years into the future and just thinking about the future and where I want to be in general. Obviously, everyone wants to make six figures, but the main goal is to make that much by doing something you love or enjoy doing. After reading this pattern I did take a moment to think about where I would like to be down the road and it made me realize what I really wanted to do with my future. Of course things happen, and the future isn’t exactly set, but it gives me a good idea of what I need to do and what I have to do to accomplish it.

The pattern has changed the way I view my profession because I never thought about needing to take a step back and think about the distance future of where I would like to be. Do I still want to be programming all my life or would I like to do something different by the age of 40? It was an eye opener to me because it really allowed me to set goals that I want to achieve by a certain age. Sure, programming is fun and all but there’s much more to life than sitting around a desk and creating programs and such. I want to create memories that will last a lifetime and explore the world.  If I can find a career that would enable me to do that then that would be the ideal job.

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.

Apprenticeship Patterns: Nurture Your Passion

Christian Shadis

In the apprenticeship pattern Nurture Your Passion, Hoover and Oshineye explore the importance maintaining an interest, curiosity, and passion for computer science despite hostile conditions. They discuss the ways hostile work environments, boring projects, and cynical coworkers can bring down the morale of programmers, especially those in a developer position rather than an engineer position. They discuss the ways in which the developer can resist these negative external conditions to maintain their passion for the subject and continue growing as a developer.

This pattern coincides well with the Breakable Toys pattern, which discusses using interesting personal projects to supplement your development skills to avoid stagnation. Using this pattern would be an excellent way to Nurture Your Passion. Working on fun and interesting projects is an intuitive way to gain appreciation for a skill and spending the extra time working and learning on your own is an excellent way to supplement your knowledge in the subject; a win-win!

The pattern makes a lot of sense – in my non-CS jobs, I often felt uninspired and bored. While the work was not as engaging or creative as development, I was completely devoid of passion for my work. This made the day drag, led to resentment for the company, and caused an overall poor experience working. Working in a field that I am far more interested in will give me the opportunity to have passion for my work, but I must try my best to ensure it does not fizzle out due to stagnation. If I lose passion for coding, my development job will become as unfulfilling as my previous jobs.

I hope to use this pattern throughout my career, but especially so over this coming summer. I am likely most qualified to be a software developer, which is not as exciting a job as an engineer but using this pattern will ensure that my passion for development does not disappear before achieving a more desirable position. Specifically, I plan to rebuild my website in a full-stack capacity to fill in web-dev knowledge gaps, but also just to have fun working on a type of project I have not before.


Hoover, D. H., & Oshineye, A. (2010). Perpetual Learning. In Apprenticeship patterns: Guidance for the aspiring software craftsman. O’Reilly.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.