Category Archives: Week-14

Apprenticeship Pattern – Nurture Your Passion

The apprenticeship pattern Nurture Your Passion refers to the problem in which you feel the environment in which you work in is stifling your passion for the craft. Depending on which aspect of work you feel is doing this there may be different solutions for everyone. For example, if you’re in a situation of constant project death marches that are sapping your time and energy, then you need to set clear boundaries and protect your passion. Whether that means to decline working “culturally pressured” overtime to avoid burning out or not would likely depend on how much you feel these death marches are affecting you.

As someone who hasn’t had much if any experience in the industry, this pattern definitely worries me a little. I’ve heard similar horror stories about project death marches from game developers working in the games industry. People who were filled with passion for their craft entering an industry that commonly abuses that passion with forced overtime until they burn out. Then, once you finish the project you’re working on, you’re laid off in an effort to cut costs by reducing headcount because you’re no longer needed, not because you’ve done anything wrong.

Obviously this isn’t the case with every company and the software development industry likely has many differences when compared to the games industry, but they do bear many similarities as well. This problem can be avoided by finding the right company that offers what you’re looking for, whether that be working overtime on something you believe in and enjoy, or somewhere that offers you good work-life balance. I’m always a little bit worried getting stuck in a situation with poor work-life balance because I’m not sure I would be confident enough to put my foot down, so I’ll have to remember in the future that I should focus on what’s best for me because I’m sure most companies wouldn’t think twice to cut costs whenever they can.

Overall, I agree with what the pattern’s saying and hopefully I’ll remember to nurture my passion even if it means getting passed over for promotions or having to find somewhere else to work.

From the blog CS@Worcester – Andy Pham by apham1 and used with permission of the author. All other rights reserved by the author.

Needing a reading list

So for this week, I have decided to read “Reading List”  pattern from the Apprentice Patterns by Adevele Oshineye and Dave Hoover. I chose this one because I believe there is something that should be done on a daily basis. Since that reading is exactly that, it should be wise to read this pattern at least once.

This pattern starts off with the context of having so much information that is needed to learn after developing the language. The problem is that the number of books to read is increasing than that of actual reading them ourselves. There is also the issue of figuring out where to start from the number of books. To solve this issue, one must maintain a reading list that not only helps in remembering the books read but also track the books that are planned to be read. Creating a text file is an option to write the list down as it is under source control and simplest implication of the pattern. For what it is worth, there is a need for a clear understanding of which books to prioritize in reading and in order by the subject.

From this pattern, what I found useful is identifying the books that would be worth reading based on a list given by any book. This will help in finding hidden connections related to the topic or language to an extent.  Mentors may recommend must-read books that even peers can discuss with one other and advise with the aspects. With data gathering over the years, patterns, gaps, and trends is starting to be seen. This pattern has changed my mind in giving suggestions to other people in what to read. I don’t disagree with anything since it does give clarification in what to do with the knowledge gained thus far and all the books needed to be read in due time.

Based on the content of this pattern, I would say this is a great and simple read as a way in reflecting on a reading habit. This pattern has helped me understand in which to read first for what topic I could have next. For future practice, I will try to write a reading list in different ways beside a text file in case anything happens to that specific device.

Link to the blog:

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Use the Source

This week, I’m reflecting on the Use the Source pattern from Chapter 5: Perpetual Learning. We all know the best way to gain expertise in programming is to actually program. However, it’s tough to know what tools are the best ones to learn from. This pattern suggests learning concepts by viewing the works of others — you’ll pick up on tips and tricks and can directly understand how to solve difficult problems if you learn from material from those who are great at solving problems. Even if the work you read isn’t from master software craftsman — just reading code vastly improves your ability to utilize code in your future.

I like this pattern a lot for a few reasons. I have always been timid about contributing to open source projects due to a lack of feeling comfort with handling others’ code. However, recently I started looking at a few open source projects and felt as though I could really contribute to the projects if I wanted to. I get the sense that this comfort has come from me handling and reading code more regularly on a daily basis. Another reason I enjoyed this pattern was reassurance. I’m starting in a Software Engineering position at Stratus Technologies in a month and a half’s time. I’m feeling extremely fortunate that I got hired, and I also know that I have a tremendous amount to learn — both when start the job (about the code they have in place) and beforehand. Their codebase is vast and complex, and in order to be an effective team member, I’m going to need to get used to dealing with large, multilayered, and complex systems.

In the arts, there’s a learning concept where the artist does “Master Studies”. Essentially, the idea is to choose a piece of art from a great artist and try to recreate it from scratch, by using the work as reference. This puts the artist’s skills to the test, but it gives them a framework to work within. I see this pattern and the concept of “Master Studies” as related, in a way. By examining the work of those who have made a name for themselves in the field, we get insight into how their mind works. There are many brilliant “Master” engineers out there, and they’ve written a tremendous amount of code that I can conduct my own “master studies” of. It’s like reading great literature — it will impact your work for the rest of your career.

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

Apprenticeship Pattern “Sweep the Floor”

I skimmed through a few apprenticeship patterns before I found on the one that hit home with me, “Sweep the Floor.” The “problem” it presented was something that I am faced with starting every new venture at this stage on my journey. It stated, “You are a new apprentice on a project.” No matter where I go, this will describe me.

I have talked in my last apprenticeship pattern blog that I am starting as an intern at a friend’s start up, and I will be taking the advice presented here and applying it to this and the next venture I go to afterwards.

The solution advocates for doing the “simple, unglamorous, yet necessary, tasks.” It is tempting to do the opposite and try to do the “fun,” “exciting” things, but it stresses to not to, and prove yourself through the small tasks.

I have had the thought that in most fields that you don’t need a degree for, one would start at an entry level job. From there, they would work their way up. The stories friends have told me about their grueling interview processes scare me. I would prefer to start at an “entry level” position over starting off with a position that I feel way over my head.

I know I have talked here in the past about apprenticeship patterns that advocate for taking on big assignments even if you don’t feel ready — the pattern “diving deep” in particular. However, I think that diving deep comes after you have laid out the foundation with this pattern. I’m going to try to not let the bigger tasks intimidate me, but i won’t think that the small tasks are beneath me.

On the contrary, the small tasks are incredibly important — not just for the use of the company, but for learning new skills. The pattern did make a point to say that many who have spent a lot of time and money getting their degree might consider this beneath them, but I don’t feel that way. A little over a year ago I was working fast food, taking out the trash, and literally sweeping the floor. I was happy to literally do it then, and I will be happy to figuratively do it for any company that accepts me as part of the team. I want to be a team player, and I will be glad to do small tasks that are important to the team. Moreover, I will volunteer for them.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Pattern 10 – Draw Your Own Map

For my last pattern for this blog, I wanted to do one that I’ve been waiting to do until the end. This being potentially the last formal software engineering class I will take, I wanted to read “Draw Your Own Map”. This pattern talks about the importance of working in an environment that will help you reach your personal goals. It also makes it very clear that the person who has sole responsibility for taking the first step in each of the small goals that lead to the high level goals that make up every “goals” list, is the reader. We need to take responsibility and not blame any company, or position that could potentially be holding up back from reaching our goals.

I’ve always been a goal oriented person, whether it be in terms of finances, academics, career, or personal. So far I’ve done a relatively good job at achieving my goals and hope to continue this trend throughout my life. In relation to career goals, since I started my college career I knew that I wanted to be involved in software development in one way or another. Through my internships, I’ve learned what I look for in a company and the position that I will be starting upon graduation. I consider it drastically important when interviewing with companies to ask the employees what their goals are. If they’ve been with the company for years and their goals are similar to yours, it should mean that the company is a good fit. For me, I looked for companies that value mentorship, are current with today’s team-based practices, and allow for good work-life balance. On top of all of these, the ability to “be water” and move around within the company if my goals change is also important to me.

Everyone’s map is going to be different but it is important to stay fluid in your mindset of what is important. Do not allow yourself to be pigeonholed to a position that you may one day hate and also makes it difficult for you to find work if you decide to move on. Find a position where the company values your work ethic and desire to learn over the specific skills you have coming into the position, while they are important, they aren’t what will make your relationship with the company last for the long term.

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Dig Deeper

This apprenticeship pattern discusses the importance of digging deep into the tools, technologies, and techniques that you use. If your knowledge is superficial, you will have trouble fixing subtle problems and won’t even be aware of how little you know. You must have the depth of knowledge to understand why things are the way they are. This will allow you to actually be able to explain the details of what is going under the surface of the systems you work on.

This pattern discusses several things you must do to acquire a deeper knowledge of whatever you’re working on. You must have a shift in perspective that involves wanting to follow a problem through the layers of a system to understand the root of what is actually going on. You should be familiar with various kinds of debuggers and must also be able to read specifications. It is also important to get your information from primary sources. For example, instead of learning about something from a blog post you found online, you should read the thesis paper that defined the concept that the blog post is discussing. By applying this pattern, you will be able to truly understand how the tools and systems that you use actually work.

I agree with the idea of this pattern. You should try to dig as deep as you can whenever possible in order to understand how things work. However, I question how realistic it is for a working software developer to actually follow this pattern. If you are asked to implement something for work that has a deadline, you won’t have hours to spend reading academic papers when a quick Google search will get the job done most of the time. This pattern warns that you should take care to not accidentally become a narrow specialist, but if you are truly diving deep into everything you learn it would be hard not to. There just isn’t enough time in the day to learn the fundamental concepts behind every tool or technique that you use. While I agree with the idea behind this pattern, I don’t think it is a very realistic goal for the majority of people.

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

Sweep the Floor












Link to the blog:

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

Reflecting on “Apprenticeship Patterns” – Kindred Spirits

One of the most important lessons that I have learned from being in a computer science program is to surround myself with people who value computing as much as I do and push me to challenge myself and learn more about the field. When I first started working on my computer science degree, I tended to isolate myself from other people in the major and work on projects or assignments alone. However, over time, I did eventually start to find “my people,” or the people who were also pushing themselves through the program, focusing on improving their skills as well. This week’s apprenticeship pattern, “Kindred Spirits,” emphasizes how essential it really is to have people who not only support your growth in computer science, but also understand what it’s like to go through what you’re going through.

The problem that Kindred Spirits seeks to address is the situation where the apprentice feels like they are “stranded” without help or guidance from mentors or other supporters in the community of computing. They may feel like they are walking the CS path alone, which, in such a huge, rapidly-changing field, can be detrimental towards the apprentice’s success.

The solution is, in short, to get in contact with people who are involved in the same road of knowledge, as well as joining communities that encourage that growth. For some, this form of reaching out may be easy, but for others, it may take more effort to put themselves out there. For me, I tend to have difficulties with joining new groups, especially if I don’t know anyone from the group. But, as I’ve been progressing through the computer science major, I have acquired some great friends along the way who know how difficult this journey can be. For example, one of my pals, James (here’s his blog), and I have consistently collaborated on assignments and projects for a lot of our classes, and getting through those courses definitely would have been more difficult without the support from someone who is also working hard to learn more about CS. I’m also looking forward to meeting and working with my new co-workers, who I’m certain also possess that passion and determination to learn more about computing and want to share that passion with others.

Thanks for reading!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

Use Your Title

For this weeks blog post I will be looking into he Use Your Title pattern. The context behind this one is that as a result of your dedication to learning, you’ve been hired or promoted into a position with a title containing the words senior, architect or lead. The problem that will arise from this is that the job title doesn’t actually match what you see in the mirror. When you introduce yourself into this new setting you feel as if you have to apologize or explain the difference between your skill level in your actual job description. A solution to this is that you shouldn’t allow the title to actually affect you. Its just a distraction that should be kept on the outskirts of your active conscious. Use the title only to gauge your organization not yourself. Don’t get fooled by a fancy title, your mother might think you deserve it but the impressive title and responsibilities mean your apprenticeship is over. They serve only to remind you that there is a shortage of craftsmen in the industry. While on the other side of this coin is an unimpressive title despite the fact that you may have surpassed your colleagues. The frustration that comes from a lack of recognition should remind you that the industry has a problem. Using this as a measurement of your own organization and fitting it rather than allowing the frustration to bog you down. Another variant that comes from this theme is the informal versus formal titles. For example you may have grown into a position of authority on your own team despite the formal title remaining. These informal titles can be hard to actually ignore, because they are constantly reinforced by peers and colleagues. These titles remain even if they conflict with your own self assessment, keeping with your mentors and kindred spirits will be critical to keeping you grounded in reality. The recommended action to all of this is simply write down a long and descriptive version of your job title. Making sure it accurately reflects what you really do at work and your skill level. This is again another pattern that I agree with and can see myself using in the future.

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

Journey into “Breakable Toys” (An Individual Apprenticeship Pattern)

On this Software Development Capstone journey part of my assignment is to choose 10 Individual Apprenticeship Patterns out of 35 patterns among Chapters 2-6 from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsmanby Dave Hoover and Adewale Oshineye. For my ninth individual Apprenticeship pattern I decided to blog about “Breakable Toys” pattern.


When you do not have much experience and you work in an environment where there is no room for failure and mistakes. Meaning mistakes are not tolerable, even if you can build experience from your mistakes/failure and grow and inevitably become successful the idea of failure is not an option allowed. Often the best solution to this problem is to build similar toy systems with a different scope to the one being built at work that will allow you to break it, test it, and budget for failure. This approach is the best solution because as a software developer having a comfortable safe environment where you are free to make mistake without any serious consequences. This approach will help allow you to learn from your mistakes and grow into a better software developer. When implementing this pattern it is important that the systems you build are relevant and useful to you. The book suggest: “For example, build your own wiki, calendar, or address book. Your solutions might be massively over-engineered for the problem they’re solving, and probably could easily be replaced by something off the shelf. However, these projects are where you are allowed to fail.” These are project ideas where only you are affected when mistakes or failure occur. As said in the book, “Breakable Toys is more about deliberately creating opportunities to learn by stepping beyond your boundaries and single-handedly building complete software projects.”

My Reaction

This pattern helps you understand the impotence of building “Breakable toys” because it allows you to build systems that you can break and learn from its failures and mistakes. I agree with this idea because the best way to success is through failure. However; in a work environment failure is not an option so the best way around that is to build your own toy. I found this pattern to be interesting but also useful and thought-provoking. This pattern has definitely changed the way I think about my profession and the way I think, the reason being is that it has made me realize that I need to start working building “Breakable toys” that would give me some experience.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.