Author Archives: Angus Cheng

Expose Your Ignorance

Hello and welcome back to my blog.

After presenting what we did in this capstone class, the apprenticeship pattern “Expose Your Ignorance” was brought up and I wanted to check out what this pattern was. The pattern “Expose Your Ignorance” in “Apprenticeship Patterns” by Dave Hoover encourages apprentices to embrace their ignorance and actively seek opportunities for learning and growth. Rather than hiding gaps in knowledge or pretending to know everything, the apprenticeship pattern suggests acknowledging what you don’t know and being open about it. Embrace the lack of knowledge and use it as a stepping stone for learning. “Expose Your Ignorance” is about normalizing the learning process. It is about showing your willingness to learn, and acknowledging that the only way to fill gaps in your knowledge is to first admit that these gaps exist.

I can use this pattern in many scenarios, such as during team meetings. Instead of pretending to understand a concept, I should ask questions about it. This would help me learn more about that concept and might also help others too if they had the same questions. I have already done this in our standup meetings for the capstone class. Another example is when learning new tools. I’ve noticed other people in my group using this apprenticeship pattern when we wrote the chai tests. I wrote a chai test and when the other members in the group saw the test, they immediately asked me to explain it since they did not know how the test worked. The chai test scenario can also be applied when problem-solving. Instead of pretending that I know how chai worked, I told the group that I was not sure how to solve it and that I would research how to do it.

“Expose Your Ignorance” will definitely be one of my most used apprenticeship patterns since the world of computer science is very vast and it is hard to know everything from new technologies to every programming language. Embracing imperfection is a large part of the learning process. Using this pattern will speed up my learning process and promote collaboration with my peers and I.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

 Hello and welcome to my last sprint retrospective blog post for CS-448, my capstone class. 

This sprint was a lot less shorter and was more focused on sprint cleanup. Luckily, our team cleaned up pretty well at the end of each sprint so there was not much cleanup left. Instead, we decided to keep working on creating tests for the backend and get the test-runner branch working. Instead of branching out and having everyone writing separate tests, we decided to come together and figure out how to write one test which was a great decision. In the end with some help from Team 1, we ended up getting 2 tests working in the end.

Links to issues: 

For this issue, we fixed a bug where GET inventory was returning an id value instead of a number. 

For this issue, we created the manual addInventory test for the addInventory endpoint. 

For this issue, we created the addInventory test in chai. 

For this issue, we created both the manual test and the chai test for the getAPIVersion endpoint. 

For this issue, we reviewed the current API as well as checked and made sure if everything was correct.

For what worked well, our cross-team communication worked really well this sprint. We would ask Team 1 questions and they were more than happy to answer any questions and help us with our tests. Our scrum master worked together with Team 1 to create a working test-runner branch. Communication between team members has improved a lot. We were all viewing the code together expressing ideas on what to add to make the tests work. We also made sure any guesses on what may be the problem were checked to hopefully get the tests running. In the end, the test runner branch and 2 tests were working.

For what did not work well this sprint, I cannot think of anything that did not work well since we all communicated well. I also cannot think of anything that the team could do to improve since we worked together more this sprint. I guess one thing I could have done better was to work on it more at home like how committed Team 1 worked on their issues.

For any improvements I could have done as an individual, the first thing I could improve on would be to read up on more of the Chai plugins. A plugin that I have not read up on may have made writing the tests easier and more efficient. It was also near the end of the semester and I was juggling a bunch of other assignments, so it was difficult to have enough time to complete issues at home. So a second thing to improve on would be my time management skills.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Reflect As You Work

Hello and welcome back to another week of my blog. This week, I looked through chapter 5 of the book Apprenticeship Patterns by Dave Hoover named “Perpetual Learning.” I was quite interested in the apprenticeship pattern called “Reflect as you work” once I read it. This pattern talks about how important it is to reflect on your own work and what you have learned in order to improve and progress as a computer science apprentice. All computer science apprentices should plan for a time to regularly review their work and see what areas they can improve in. It is also important to see what you accomplished and identify where you succeeded. You should always cherish those successes. “Reflect as you work” recommends you as an aspiring computer science major to draw a personal map for your own working habits and focus on the habits that have not changed in a while. Figure out if changing one habit would make you more productive and adopt that change.

To apply “Reflect as you work” to myself, I am going to make an analogy to playing video games again. No matter what video game I play, I always reflect on my actions, both when I succeed and fail. If one strategy fails, then I look back and try to identify points of failure and see how I can correct those mistakes. If my strategy succeeds, I celebrate that I’ve won (mentally in my head) and then look back and see if I can make the strategy better or make it more efficient. This is just a habit I’ve developed over years and years of playing video games. The same can be applied to being a software apprentice. If I fail to write working code, then I will try to identify the errors and try to correct them. If the code does work, then I will analyze it to see where it can be more efficient. In the future, I will always reflect as I work. As an example, look at this code:

int count;

count = 0;

while (count < 3){


count = count + 1;


This code can be condensed down into:

int count = 0;

while (count < 3) {



Which can be further condensed down to: 

for (int count = 0; count < 3; count++) {



Reflecting on my work as I go will greatly help me as a software engineer apprentice.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

The Deep End

Hello and welcome back to another week of my blog. This week, I looked through chapter 2 of the book Apprenticeship Patterns by Dave Hoover named “Emptying The Cup” and took interest in the apprenticeship pattern called “The Deep End.” This pattern is about pushing yourself out of your comfort zone and taking on challenging tasks that are outside of your current skill set. The best way to learn is by doing, and that taking on tasks that are beyond your current abilities can help you grow and develop new skills. The pattern advises that when you are in the “deep end,” it’s important to ask questions and seek help from more experienced colleagues. It’s also important to break down your tasks into smaller, more manageable pieces and to focus on making small incremental progress over time. The benefits of taking on tasks in the “deep end” include accelerated learning, increased confidence, and the opportunity to demonstrate your abilities and potential to your colleagues and mentors.

As a computer science apprentice, it can be scary to go into the “deep end” since you may think you would be a totally lost person working with experienced people. But I have experienced the deep end myself many times in my everyday hobby, video games. This seems to happen the most especially in competitive video games, when you play with people who are more skilled than you, you start to pick up on the many small helpful habits highly skilled players tend to do. The skilled players don’t need to think about the small habits because they have already mastered them and do them out of muscle memory. The same can be said for computer science apprentices. For a scenario, think about working on a difficult project with more experienced people in the field. You may look like a small fry with not that much experience compared to the others, but this is actually a fantastic opportunity to observe your team members and pay attention to small things and habits like their thought process for example. As you focus on the small habits, you also start to copy those habits and incorporate them into your work as well. This would also be a great opportunity to ask questions if you are confused about anything. I will for sure start diving into the deep end if I find any opportunities to since it will strengthen my skills as a computer science major.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

Hello and welcome back to my blog. 

This is the second and last sprint retrospective blog post for my computer science class CS-448. For this sprint, our group needed to continue working on the epics created by the professor. The tasks included updating JavaScript code to modern JavaScript, converting all Docker images to multi-architecture images, and writing tests for the backend of the InventorySystem. I worked on these issues in the CheckInventoryFrontend and in the Inventory Backend. 

To update the JavaScript to modern JavaScript, I had to replace “var” with “let” and use “const” whenever possible. This required me to research how JavaScript’s “var,” “let,” and “const” work.

  • Issue #1: Update JavaScript to modern JavaScript

For this issue, I checked every JavaScript file and added “use strict” to the beginning of them as well as checking if there were any “var” variables.

Continue reading

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Record What You Learn

Hello and welcome back to another week of my blog. This week, I looked through chapter 5 of the book Apprenticeship Patterns by Dave Hoover named Perpetual Learning. One particular apprenticeship pattern I found interesting was “Record What You Learn.” This pattern is about taking notes and keeping track of what you learn in your journey as an apprentice or a learner. The idea is that if you write things down, you can look back on them later and remember what you’ve learned. Plus, by sharing your notes with others, you can improve your communication skills and help others learn too. There can be several ways to record what you have learned throughout your journey, such as constantly updating a journal, personal wiki, or writing a blog, such as me writing these blog posts when I learn about the different apprenticeship patterns. Those listed have only writing involved. Other ways you could record down what you have learned include making a drawing or even making video recordings of yourself. No matter what way you choose to record what you have learned, it is important to keep a date on them. This way, your recorded notes will be organized and sorted in chronological order.

I should start following this apprenticeship pattern especially since I tend to forget things that I have learned such as a stack versus a queue in Java. Sure, I could just look up what the differences are online, but actually writing it down in my own style would help me remember it more easily. In addition, if I forget anything in the future, I could always just refer back to my old notes. When I start incorporating this apprenticeship pattern into my journey, the main way I would like to take notes would be to find something digital and write stuff down in it. I prefer writing stuff down with a stylus, like using an Apple Pencil on an iPad, since I tend to remember things more when writing notes down rather than typing them out. I hope to start using “Record What You Learn” because it will be highly beneficial to my computer science career.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Find Mentors

Hello and thanks for coming back to another week of my blog! This week, I took a look at chapter 4 in the book Apprenticeship Patterns by Dave Hoover, called “Find Mentors.” Having a mentor can help you get guidance, support, and feedback to help you get better in your field. This apprenticeship pattern gives tips on how to find a mentor, like looking for people who are respected in your industry, going to conferences, and asking for feedback from your colleagues. It is also important to be open to feedback and find more than one mentor to get different perspectives. The computer science field is still relatively new, so there are not that many truly skilled mentors that excel in all computer science areas that are available to look up to. The pattern also says that you may encounter mentors that you may not be able to talk to, such as people making informative YouTube videos who live overseas. But those people are still mentors who inspire you. The pattern also emphasizes how hard it actually is to find a mentor. While there are many skilled people in the computer science field, not all of them are open to mentoring. Therefore, you should always ask if they are interested in mentoring people because you never know if they will accept being a mentor.

As an aspiring computer science major myself, I should also be on the lookout for mentors. There are several ways I can find mentors. The book says I should pick a tool, library, or a community that has an active mailing list and sign up for it. Other ways include asking faculty members at university, who are definitely more skilled than me and are always open to answering questions. Reaching out to alumni is a great option as well, since they were in the same boat as me when they started out. They could mentor me themselves or redirect me to someone they know who is skilled enough to answer my questions. Attending computer science events could be another option since it is a great way to network with professionals and ask them for advice. I would also have to keep in mind that as I get more experience, others may look up to me as a mentor and I would have to guide them on their long journey as well.

Thank you for reading.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Draw Your Own Map

Hello and thanks for stopping by to read another round of Comfy Blog. This week, I read up on the apprenticeship pattern “Draw Your Own Map.” I was interested in this pattern immediately once I read the title since I myself am not sure how to walk the long road down the computer science path. For a short summary, this pattern emphasizes the importance of creating your own career path as a software developer and having an understanding that others are not supposed to hold your hand down the path. 

In this pattern, the first step is the most important step, since it is the one that creates all the momentum to your career goals. But what exactly is the first step? Is taking computer science courses in university the first step? Or does the first step skip university classes and is just apply for jobs you are interested in? For me, the first step was realizing my passion for computer science. That passion led me to taking classes in university, and led me to today, my capstone class here at Worcester State University.

Another element that this apprenticeship pattern emphasizes is to set small goals for yourself, rather than set high-level goals and expectations. I think many people’s goals would be to be an employee of a large computer science based company, such as Google, Facebook, or Microsoft. But working there as an apprentice is highly unlikely since you would lack the experience you need. Instead, set small goals and use those small goals as a plan and road map for your career. A small goal would be for example to work at a startup company and develop skills there. Then, maybe move onto a new company down the road that is slightly bigger since you have more skills. There is not a set path that every apprentice should take. Everyone’s path will be different. It is important to note, however, that your small goals roadmap may change as new opportunities open up. My roadmap that I will eventually make may need to constantly change and I may need to go into unfamiliar territory in order to progress.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Emptying The Cup

“Emptying the cup” is one of the most important and interesting chapters of the book “Apprenticeship Patterns” by Dave Hoover. This chapter is a call to all aspiring software developers to unlearn their preconceived notions, beliefs, and biases that may have been learned from past experiences, learning other programming languages, or etc. and become open to new perspectives. In the context of software development, the phrase “emptying the cup” means being open to new ideas, technologies, and practices. It means being willing to unlearn old habits and ways of thinking that might be blocking your growth as a developer. New software developers should be aware of the importance of curiosity and a willingness to learn from others so that they can grow into exceptional software developers.

This apprenticeship pattern revolves around clearing your mind of everything you know and opening yourself to new and different approaches to the problem. Clearing the mind of previous knowledge would get rid of old habits that the programmer may have picked up on while coding in the past. What works in one language might not necessarily work in another language, and there may be more efficient solutions to a problem in another language that may be the most efficient in the original language. What I found interesting is that emptying the cup is much like the metaphor “thinking outside the box.” Rather than using traditional or old habits to solve a problem, you should drop the old habits and think differently and incorporate new perspectives to solve the problem. Most people may fall back on a traditional or the most popular method to solve problems they may encounter while programming because it has shown to work in similar situations. But when programmers solve problems by thinking outside the box, they try to find untraditional ways to solve problems, or find unintended ways to solve them. Thinking outside the box and emptying the cup are similar since they both require the programmer to deviate from the usual methods of problem solving that programmers do and find a more creative way to come up with solutions.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective Blog Post

This was my first instance of using and being a part of the scrum workflow. Even though I knew how scrum worked from learning it in a previous class, I was still shocked at how enjoyable and manageable the scrum workflow process was. Our group was assigned the InventorySystem component of Thea’s Pantry. For this sprint, I focused on the CheckInventoryFrontend part of the InventorySystem. Our group did a sprint pre-planning, and we created issues for the “Convert all InventorySystem projects to new project structure” epic. I first made a sub-epic, made each bullet point its own issue, and then linked those issues to CheckInventoryFrontend (Link: I will now go into more detail about what I have accomplished during the sprint. 

Evidence of Activity

Issue #1: Update devcontainer files

For this issue, both the devcontainer.json and Dockerfile files in the .devcontainer folder were compared and updated to match the same files in the GuestInfoFrontend.

Issue #2: Update Pipeline/CI files

For this issue, the .gitlab-ci.yml file, the Dockerfile, package.json, and Header.vue found in ./src were updated to match the already updated and working pipeline found in the GuestInfoFrontend.

Issue #3: All documentation, licensing, linting configuration, .gitignore, .gitattributes files must be updated or added

In this issue, docs/developer and linting files were added, and the .gitattributes file was updated.

Issue #4: Revise directory structure:

For this issue, bin was renamed to commands, files were moved from the top level into src, new commands such as were added, and some files and folders were deleted to match the GuestInfoFrontend.

I reviewed, approved, and merged the following issues:

What worked well?

Working as a team went really smoothly during this sprint. Our team had three frontends that were very similar, so once one person who was working on a frontend was able to figure out how to solve an issue, they would be able to help the other members working on frontends. Communication between team members was also great. When one member needed help, myself and other members would communicate over discord to discuss and fix the issue.

What didn’t work well?

I feel like there wasn’t much that didn’t work well. Very rarely in class we would get off topic and start a conversation about something else like discussing what computer parts are good. That time could have been better spent working on the issues.

What changes could be made to improve as a team?

We split the work so that basically one person was assigned to a part of the InventorySystem. We could have picked up issues in other parts of the InventorySystem to diversify our knowledge on how the InventorySystem works as a whole.

What changes could be made to improve as an individual?

Changes that I could have made to improve as an individual would be to actively search for a solution to problems that may have arised. When updating the pipeline, the program was giving me an unknown error and the professor said that he would look into the problem. Instead of trying to solve the issue myself, I waited for the professor to figure it out. Instead, I should have been also trying to find the solution to the error.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.