Author Archives: Chris

“Study the Classics” Apprenticeship Pattern


This pattern is based on newer programmers that have not had as much experience in the field not having reference to earlier works that were instrumental in the development of the field of software development. The newer programmer will have less reference in understanding the context of how things are the way that they are in the industry, and will be surpassed by his colleagues who know the literature and understand laws and phrases used.

What I find most useful about the studying of classics in a field like software development is emphasis on trends of the industry. Programming languages and projects can come and go, but if classic literature can be used regardless of the time period that is read it implies that there is general education that can be done that transcends simple programming or development.

This apprenticeship pattern has somewhat changed the way that I think. I know that I would probably have to learn terminology that is important to software development, especially when working with teams. This apprenticeship pattern has, at the very least, made me more interested about learning classical literature in the field. Although on the other hand, it seems a bit difficult to me to disambiguate which type of classical book to read, and which type to not read. The pattern references “When you pick up a book and the first thing you wonder is how out of date it is, you’re reading the wrong kind of books”, but I’m not entirely sure how to come to that conclusion. Although I’m assuming that I can gain proper reference via an article.

I do disagree with this pattern a little bit. Studying a lot of classical literature seems to me like a dedication that can take a lot of time and energy. I think if I want to expand my education on classical matters such as Brooke’s Law, it may be more beneficial to read a second hand source that aggregates classical laws and their contexts rather than reading some of the classics cover to cover. While my view here might be ignorant since it is only based on this short pattern, it is the impression that I get from it.

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

Sprint 3 Retrospective

(I’m sorry if some sentences are hard to understand. I am pretty sick at the moment, and it’s hard to make sense sometimes)

Our third sprint had two end goals, deploying a demo locally using minikube then hosting it using AWS EKS, and discussing with the other teams on what they’re working on so we can make a schematic from their work in a hosted Kubernetes Cluster. We ended up discussing it with the other teams and were able to create the final schematic. We were also able to deploy a local demo of the Kubernetes Cluster, but we had issues deploying a demo on AWS EKS.

What worked well was discussing with the other teams to get information on how the final schematic would look like, and how our team worked together in organizing the information from talking with the other teams (1). There were also many regards while working on the final project where we came together as a group to set up a schedule, how we’re going to do the presentation, and when we should do it. Afterwards, we were able to use this information to create a schematic illustrating each of the different team’s works inside of a deployed Kubernetes Cluster (2).

I think part of the reason the third sprint was the most difficult was that it was the last sprint in the semester. For example, I and some of my other teammates had a lot of projects we had to get done while due dates were getting close. This made it harder to focus a lot of time on working on the project. Maybe if we focused more time on this project, we would’ve been able to get a demo out, but it isn’t a guarantee that it would’ve happened.

As a team, I think we could’ve been more communicative and dedicated more time to working together on the project. There was a lot of not knowing towards the end on whether or not someone was working on something because communication on some level broke down, especially when some people in the team were busy with other things. This led to troubles with communication, especially when working on the final project. There were times where we agreed to finish work by a certain deadline, but not everyone finished by it.

As an individual, I was constantly trying to push myself to be more active in communication with my team members about updates. However, this does not mean that I was good at it, or I did it without flaws. From my role as a scrum master during this semester, I think that I need a lot more experience in communicating with my team members and being more assertive in initiating conversations and keeping planned dates we agree on in check. 


  1. – An organized compilation of six issues from our team members’ discussions with the other teams.
  2. – Final Diagram of a Kubernetes Cluster hosting the docker images worked on by the other teams.

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

“Sustainable Motivations” Apprenticeship Pattern


This apprenticeship pattern deals with the practice of working in real-world projects that may be rigorous, frustrating, or exhausting such that it makes the Apprentice question his motivations in the field. There may also be employment issues, bad leadership, or bad co-workers. Whether this programmer hates the job but desires a good income, is in a hiatus for his love of the field, or works on open source projects for a reputation.

One of my greatest fears in my career is a lack of interest in what I’m required to do. If I work at a company that shifts my work into something that I have no interest in or is very different, I run a real risk of burning out. Although, my favorite element of Computer Science and of programming stems from a certain love of creating things, a type that is not universally palpable in different fields. Hence, even though I don’t have a lot of peculiar interest in, say, creating a website, I’d do it if I need to and I’d probably enjoy doing it. 

I don’t agree or disagree with the action recommended in this apprenticeship pattern, however I feel as though more could be done in a situation like this. On top of writing the things that motivate you, you should try to think to yourself why you are motivated by the things that motivate you, and what is the common connection between all of them that acts as the catalyst. It may be that your motivations are either inconsistent or are the way they are for the wrong reasons. Shifting motivations to be more realistic or to make them fit more appropriately for a given situation can be very useful. On the other hand, if you’re in an untenable situation where you may become burnt out, forcing yourself to be in that situation while attempting to justify it may be harmful.

This apprenticeship pattern has at least caused me to be more aware of a situation that I may be befallen to in my future career. It may be better to move projects or companies if I’m in a situation where I may be burnt out working on something that I don’t like, whereas I could take some initiative and move to where I feel I’d be better suited.

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

“The Long Road” Apprenticeship Pattern


This apprenticeship pattern concerns the long term journey that a programmer / developer will take throughout his or her lifetime. In a society that continuously values decadence, it’s important to find a path that is right for you, no matter how weird or seemingly unusual it may be. As we gain experience as programmers and developers, there will be temptation to mindlessly progress down the path of greater income and short term gain. Instead, this pattern is for those who aspire to progress down a fruitful path in software development, gaining experience in a lifelong career.

What I find most thought provoking about this pattern is the prospect of leaving the field of programming permanently to go down another field of salesmanship or to a high ranking position in a corporation. Software development to me is a very intricate and professional field that requires a lot of research, experience, and experimentation. Someone who progresses far enough into the field only for them to change directions because of their experience seems somewhat confused to me. On the other hand, it at least makes some sense as someone who has a lot of experience in software development can have a lot more skill as a business owner or a salesman in selling software, and recognizing development cycles for a product.

This pattern has indeed somewhat caused me to change my view of my future. I knew that within the software profession there were many different ways that one could go, and that we would need to be experienced with different tools if we needed to create a competent product. I wasn’t sure, however, of the potential of an opportunity arising to shift to a different career

I generally agree with this pattern. The part I agree the most is on the matter of strange roles that one may possibly find himself in in the future. Personally, my work and perspective on planning my future took a drastic turn almost a year ago, where I actively tried to search for a career as a programmer based on the tools that I already knew. Then, I found out that it’s better to learn and gain experience with new things that I don’t know, based on the demands of a job and the industry.

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

Sprint 2 Retrospective

Our second Sprint had the end goal of deploying a demo Kubernetes Cluster. This cluster would most likely be deployed locally using Minikube and Kubectl, and would use a demo so we could understand the process.

We weren’t able to get to the issue that would have us create a Kubernetes Cluster, but we still made a lot of progress and ended up getting close. 

What worked well was the use of teamwork between issues. What I mean by this is, one team member would research something for one issue, and that research would be important for another team member working on another issue after the fact (1). The research and the results of what we produced while working on our issues is informative, and is vital for our goal of our team for this class and what was our goal for Sprint 2. The quality of our work was pretty good, and I think we’re progressing nicely, albeit a bit slowly, to a competent end product.

What didn’t work well was some of our organization during the sprint. As mentioned above, we weren’t able to finish the demo for the end of this sprint (2), and I believe there were a few examples for this. The first reason was spring break. We didn’t progress on any issues during the break, and coming back took time to get back into gear. The second reason was the class cancellation on the 21st of March. This was right after spring break, and it was a bit difficult to get back into it. Even still, we should’ve started working on issues like normal, but it took some time to organize and it caused us to stall for a few days (3). Finally, a lot of work relating to a Kubernetes Cluster is a concept that is new to us, and it involves quickly learning new things. (4) This spring required us to deploy a demo within a relatively short amount of time. As such, I think Sprint 2 was more difficult than the first sprint, and this spike in difficulty was a big factor in our work progress.

As an individual, I felt that I could improve by interacting with my team more. Some of our issues could’ve been worked on concurrently, and it’s very easy to simply keep working on individual issues without understanding the greater context of what we’re doing. Since we’re trying to set up the infrastructure for a Kubernetes Cluster, everyone needs to understand the context of their work in the project (5). I felt like maybe I could’ve started a conversation or two with my teammates about the project. I did it once or twice, but maybe initiating one or two more conversations would have been helpful.

As a team, communication is something that I think we need to improve on. For example, after the break we should’ve started communicating to roll back into action after not working on anything for a while. Another thing that we struggled on was communicating outside of class on setting up some of the sprint issues, which caused us to lose one point on our grade.

By the end of Sprint 2, we progressed and learned a lot. I feel comfortable about this project, and our work for our next sprint as laid out by our second sprint.

(1) – This issue provides a lot of good information about Kubectl, which will be very helpful on deploying a demo cluster.

(2) – This issue is the demo issue. It is not yet done at the time of writing this.

– An example of me starting this issue a few days after coming back from break, which should’ve been done by Monday.

– Four examples of different things that we need to know while working with an issue.

(5)- For example, the demo would require us to deploy the projects listed by this issue:, concurrent to understanding and creating anatomy posited by this issue:

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

“Read Constantly” Apprenticeship Pattern


This pattern arises when a programmer is aloof by deeper concepts of a topic, even based on one that he may know, such as a programming language. One of the best ways to solve this issue is digging deep by reading books constantly. Books can offer a huge amount of information about one or more topics, and should be prioritized over blogs as a main source of knowledge.

Branching from the “Unleashed Your Enthusiasm” pattern, this pattern is one of the most important I’ve come across. Even if you are enthusiastic about learning, or are proficient in a skill and or a programming language, the ability to sit down and read to grow your knowledge is what I believe to be the most important skill and behavior. Even someone that is not enthusiastic, or does not know a language, or does not know a tool, if he can make himself sit down and read to learn more about a topic, he has far greater potential than he who doesn’t read.

As such, I strongly agree with this pattern. It also is a strong reminder for me to start reading more, and I tend to not read books to learn more. While I strongly agree with this pattern, I also want to add a note that does not run contradictory to it. Sometimes not reading and getting familiar with something is also beneficial. Reading is extremely important, but getting an intuitive understanding of a tool, like driving a car, is also an important task that should be done concurrently to reading constantly.

As I’ve mentioned before, I am competent with the C++ programming language, and I’m able to use it confidently without having to constantly look things up online or in a book. However, this pattern has me thinking about what I should start reading. One of the things I understand the least of in C++ are Move Semantics. Move Semantics involve utilizing rvalues and rvalue references to avoid creating unnecessary copies of an instance. An rvalue tends to be an immutable value that tends to be on the right of an assignment operator, such as an equal sign (hence rvalue). How this works aloofs me, and I believe this can be a good starting point for me to begin my habit of reading books since I understand the context of its existence.

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

“Unleash Your Enthusiasm” Apprenticeship Pattern


This apprenticeship pattern is concerned with a new developer’s entrance in a team that is both more experienced, and relatively unenthusiastic in comparison. As a newcomer, the new developer has much to learn from the industry and from his colleagues. But with every new iteration begins a chance at change. Depending on the team, enthusiasm can benefit a team that does not have low morale, and is accepting of new perspectives.

I view this apprenticeship pattern as particularly intriguing because I am genuinely enthusiastic about working on a team with other software developers. Someone who is inexperienced in a field may focus and develop skills in things that his future peers will not require. As such, it may offer a perspective that his peers do not have, such as various coding “tricks” or knowledge that may be used as a reference. For example, a new programmer may have to program an algorithm from scratch in school, which can give him ideas about a data structure that a team may either require, or benefit from. In the field, programming a data structure isn’t as important since the language would likely offer it. 

This pattern didn’t so much cause me to change my ways of thinking as it did bolster my perspective of the field. In my experience, it is natural for someone who is good at something in a field to gradually become uninterested in said field because of a sort of coexistence. There is some mental functionality or process in every person that occurs when someone becomes used to something, such as an environment or a smell, which causes him to become somewhat apathetic. In this case, a developer that is used to the field runs a genuine risk of being used to it, and therefore, not excited from it. I personally view unenthusiasm is a strong indication of decline, and any person who becomes unenthusiastic will, all else being equal, perform poorer than his peers.

I don’t disagree with anything in this pattern. As stated earlier, I strongly agree with the role that enthusiasm plays in relation with other team members, and its potential productive results that can benefit a team.

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

“Familiar Tools” Apprenticeship Pattern


This apprenticeship pattern is concerned with a lack of familiar tools that a programmer has on his belt. It’s recommended that the apprentice become very skilled at five tools such that he does not need to read the documentation while also understanding the nooks and crannies of them. As time goes on, and he moves from job to job or project to project, become sufficiently familiar with the tools he learned. This does not mean that an apprentice that is good with these tools means it will be good for others or for the team.

This pattern is similar to the “Your first language” apprenticeship pattern, which states that it’s good to master your first language before moving on to a second language. I like this apprenticeship pattern because of its ideal of mastering and recording the tools that one learns. I also like the idea of trying to find better and more powerful tools available whilst the apprentice writes down the tools he is already familiar with. 

The pattern has somewhat changed my view on my intended profession. However, I don’t have a hardline goal about what my intended profession looks like, I’m completely fine with bending my skills and attitudes based on what my employer wants me to do, and what is required of me. If my team at a future company requires me to learn a new system that I’ve never used before, then that’s what I’ll do. Likewise, if they require me to use what I already know, then I’m also completely fine doing that as well. 

I’m not entirely sure if I fully agree with the fact that all of the tools that an apprentice will learn and be familiar with will become obsolete by the time he becomes a journeyman. What if a student / apprentice becomes very familiar with Java and eventually becomes employed as a software developer who utilizes Java? I know as time goes on, tools change and languages become favored or disfavored as the development landscape changes, but I am having a hard time agreeing with this statement. I know that a lot of different apprentices can have many different skills, many of which can me more useful than others, especially when taking into account what type of work they’ll likely be employed in.

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

“Breakable Toys” Apprenticeship Pattern


This apprenticeship pattern deals with a software developer that cannot afford to learn by failure. This software developer may work at a company that must get things correct, and thus cannot experiment and learn from his mistakes. Thus, this pattern recommends the developer to create his version of his work’s program in private, to experiment so he can learn.

I want to say off the bat that I do not disagree with anything stated in this pattern. In fact, the most I’ve learned has been from practicing and failing repeatedly, so I strongly believe that this is a very important pattern for all developers.

This pattern has helped me greatly in my understanding of development. For example, in one of my homework assignments that required me to implement an algorithm that sorts operating system “jobs” by time to process, I wanted to use what is called a “MultiMap”, that is to say, a Hash Map that allows duplicate keys that could then be sorted, by key or by value. After this assignment, I spent hours trying to figure out its implementation, and I eventually figured it out. By following this pattern, I was able to figure out more about Java types, and I taught myself how to use hashing algorithms. 

I find this apprenticeship pattern very interesting. I bring the above example up because what I find interesting about this apprenticeship pattern is that I never thought to apply it to my work projects. There is a lot of information that I’m learning about when I’m working outside of school, and this pattern has indeed changed the way I think about how I will work and what my profession will steer me towards, and vice versa. 

I will try to create a private project with homework or work in which I implement the project differently, and try to see if I come up with any valuable results. There are many things I’ve learned from applying this principle to a few homework assignments or free time projects, but I can feel that this would be very beneficial in trying this with new systems, or alternate pre-existing ones from school or work.

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

Sprint 1 Retrospective

For our first sprint, our goal was to familiarize ourselves with the different components of a system that we need to work with and that we don’t know. Most of the issues present in our first sprint dealt with researching these aforementioned components, for instance, RabbitMQ, EKS, and Kubernetes. As such, most of our issues were researching the anatomy of what we’d be working with via AWS EKS. I believe our main difficulty was determining what we needed to research, and what was useful or not.

To get what did not work best out of the way first, some team members, myself included, missed the deadline on some of the issues. In my case, this was due to the fact that we are unfamiliar with much of what we’re researching, thus, the issue I dealt that I’m referencing with was denser than I expected it to be because it’s difficult to project precisely how long each issue would take, or if we need to split it up into several smaller issues1

What worked well was our team’s communication with each other in class, and in some of the issues. It took a few classes to warm up to each other. I think the descriptions and how we formatted our research also worked well. In general, we used markdown to break down our research into more digestible sections that made it easier to understand2. Another thing I thought worked well was the description of what we may be looking for in the issue descriptions. While difficult to be too specific, it helped as a starting point for the other team members to begin once they finally started on the issue3

As an individual, I think I could improve on meeting issue deadlines in a more timely manner. While I mentioned earlier that the issue was denser than I thought it would be, I also should’ve managed my time better, and started working on this earlier to fully understand the time it would take, so that I might’ve been able to mention it in the next class. I also think that I should’ve talked more through the GitLab Issues / Epics rather than other means. While I did communicate using the aforementioned means, it may be better to discuss more, especially as our future sprints will more than likely demand it.

As a team, I think we should institute a better application of rules throughout the issues. While writing this, I realized the issues implement markdown format differently than others4 5. I don’t think this is a big deal, but it may be better to implement some form of standard across the issues. I also think that we may need to communicate a little more via the GitLab Issues / Epics. In this first sprint, most of the issues were independent research that usually didn’t cross over into other issues very much, hence there was little need for communication between team members. However, given that the second and third sprints will involve deployment, it is both required and vital that we communicate on GitLab.


  1. – A note left by me explaining why it took extra time.
  1. – An example of research using markdown to partition the different parts of research as mentioned above.
  1. – Example of an issue’s description that includes a brief description and several points of interest.
  1. – An issue description using spacing to separate sections.

5. – An issue using titles in markdown to separate sections.

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