Author Archives: robiciampa

Apprenticeship Patterns: Confront your Ignorance

The ‘confront your ignorance’ apprenticeship pattern talks about what to do when you have discovered a gap in your skillset that you need to fill for your daily work. Though you have identified this shortcoming, you aren’t sure how to begin overcoming it. Hoover and Oshineye recommend selecting a single skill, tool, or technique and working actively on your understanding of it. This can be done in any number of ways, such as by reading introductory articles or constructing breakable toys. You should choose a learning method that works for you. Once you are satisfied that your knowledge has been sufficiently filled in, you can decide to either continue pursuing this topic or move on to another gap in your knowledge. This pattern should be used in tandem with the ‘expose your ignorance’ apprenticeship pattern. Confronting your ignorance in public as well as private encourages an environment that is more tolerant of failure. Focusing too much on developing your skills in private may pull you away from your actual work, and it may become an issue for your team. On the other hand, focusing too much on the ‘expose your ignorance’ apprenticeship pattern may become obnoxious to your team members and prevent you from doing anything meaningful about your lack of knowledge. At the risk of coming off as either arrogant and unwilling to work or passive and unwilling to learn, you must strike a balance between these two patterns.

I think this apprenticeship pattern is really interesting. I have always found it useful to study topics that I feel I am weak in private; it’s nice to be able to focus on learning in a space I don’t need to worry about how that lack of knowledge makes me look. Learning in private can only get you so far, however. It is important to also communicate with people with more experience and who can help you better understand the topic you are pursuing. I think as Hoover and Oshineye suggest, this pattern would be especially useful when employed alongside the ‘expose your ignorance’ apprenticeship pattern. I do agree that these should be used within a reasonable amount. There is no point in expanding upon a skill if it is going to ruin your daily work.

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

Apprenticeship Patterns: Expose Your Ignorance

The ‘expose your ignorance’ apprenticeship pattern addresses the issue of you not being completely comfortable with the technologies your work requires you to work with. Your impulse may be to lie to a customer in favor of appearing competent, but you should curb this impulse. Instead, you should be honest and open about your knowledge or lack thereof and focus on your ability to learn. Asking questions is a good way to let people know that you are both needing and willing to learn. Asking questions of your team may also help your team recontextualize and reunderstand their own knowledge. Your goal should be to expand your knowledge to a variety of topics, especially while you are still new to the profession, rather than focusing on becoming an expert in a handful of technologies. It is important to be able to recognize areas in yourself that could use improvement. It is similarly important to expose those areas and work on learnig from them, rather than hiding them.

I think this apprenticeship pattern has some very useful advice. I think it is great advice to admit your knowledge in an area is lacking and use that as a chance to learn. Hiding your lack of knowledge in an attempt to save face and spare your pride is unwise and will succeed only in stunting your learning process. This is something I try to work into my daily life. I used to be very scared about coming off as incompetent for lacking in a given area, but I find it is much more rewarding to admit that I am weak in an area and use that as an opportunity to expand upon my knowledge.

The only thing I disagree with is the action that Hoover and Oshineye suggest taking. I don’t know if posting a public list of things you don’t understand will help you better yourself, I think it is just going to make you look weird to your coworkers. I think it would be more useful to keep a private list of things to work on, and just keep that list in mind in discussions with others in case the opportunity to develop your knowledge presents itself.

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

Sprint 3 Retrospective

In our final sprint, our team focused primarily on finishing our demo, communicating with other teams about their projects and how they will fit into the cluster, and creating a schematic of the final cluster. I think our final sprint went really well. While we did not finish everything we set out to, we were able to get a significant amount of work done, and I think we have left the project in a good place for whoever will be picking it up next.

I think a lot of things went well in this sprint. Similar to our second sprint, we had a much clearer understanding of what we wanted to accomplish in this sprint, and that made it much easier to divide work into manageable tasks. Unlike the last sprint, much of this work could happen concurrently, so team members were blocked less often by the issues other team members were working on. Additionally, I think we were all much more comfortable communicating with each other, and this allowed our work to go much more smoothly.

The only thing that didn’t go well was how much work we wound up getting done by the end of the sprint. We initially planned for thirty points of work, and by the time the sprint had officially ended we only got through about half of that. I think we underestimated how long some of our issues would take to complete and wound up falling behind. Regardless, I feel that we got a substantial amount of work done.

Our team worked very well during this sprint, but there is always room for improvement. I think we could improve on our time management a little bit. We spent a lot of time discussing how we would like the sprint to go, and this left less time to actually work on our issues. Still, I don’t think this impacted us too heavily; I am happy with the work we did get done.

Personally, I think I could improve on the way I write documentation, especially summaries of research I’ve done. I tend to get overwhelmed by whatever information I’m reading and will forgo some details in my retelling. I want to be able to write more detailed documentation since that would be more beneficial for my team members.


Research Helm – I spent time looking into Helm, which is a package manager for Kubernetes. I researched what it is, how it works, and whether it would be worth using in the final cluster for Thea’s Food Pantry.

Communicate with Team 1: Inventory System – I informed the Inventory System team about our work, and I made sure we understood how their project is structured.

Communicate with Team 3: Food Keeper – This is similar to the previous issue. I informed the Food Keeper team about our work, and I made sure we understood how their project is structured.

Communicate with Team 4: nest Guest Info – This is similar to the previous two issues. I informed the Nest Guest Info System team about our work, and I made sure we understood how their project is structured.

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

Apprenticeship Patterns: Sustainable Motivations

The ‘sustainable motivations’ apprenticeship pattern discusses the realities of beginning a career in software engineering. In the process of developing your skills, you may be stuck working on projects with obscure specifications and fickle clients. This work can be, as Hoover and Oshineye describe, “rigorous, sometimes tedious, sometimes exhausting, often frustrating, and frequently overly chaotic or constraining,” and it may start to wane on your motivations. The trick is to not become wrapped up in your motivations; you should recognize that some days will be harder than others. You should not be driven by a single desire; if you are motivated only by money or a desire to build your reputation, you might burn out and lose that motivation. Your motivation should also come from wanting to master your craft

I thought that this apprenticeship pattern was really interesting. I think it highlights how easy it can be to become disheartened with your work, especially if you are not properly motivated. It can be devastating to invest time and money into a career you wind up losing interest in, and it is helpful to see advice on avoiding this.

I like the suggestion to have multiple motivations for working; obviously, if more factors are motivating you, you are less likely to lose interest in your work. The suggestion to, in addition to your other motivations, be motivated by mastery to avoid stagnating your skillset seems very useful. I also like the advice in this apprenticeship pattern to maintain a good balance between your work and your life. I think a healthy work-life balance is so important; your work should not demand so much of you that you are unable to enjoy other parts of your life.

I don’t agree with the first example discussed in the ‘solution’ section of this apprenticeship pattern. The person in this example hates the programming that their job requires, but they like the money and the reputation. The solution to this example is that they endure the job until it improves. I think this solution sounds absolutely miserable. I realize this is not as realistic a suggestion as it should be, but you should probably switch professions if you hate performing the main task your profession requires.

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

Apprenticeship Patterns: Reading List

The ‘reading list’ apprenticeship pattern supposes a solution to a situation where you are finding books you want to read faster than you can get through them. There are lots of really good resources available for programming, and reading them is a great way to help you improve your programming skills. However, with such an abundance of resources, it becomes difficult to manage everything you want to read. The solution is, as is suggested by the name of the apprenticeship pattern, to maintain a reading list. This list should store both books you want to read and books you have already read. Hoover and Oshineye recommend storing your reading list somewhere public so that other people can see and learn from your list. Keeping a list like this for several years will allow you to analyze your reading habits and pick out spots where there might be gaps in your knowledge. As you work through your list, you can use the bibliographies of the books you read to add new books to your reading list. This can also help you narrow your research down into an area you take interest in.

I think this apprenticeship pattern is interesting, and I think it’s a great way to keep track of what you want to read. I think the advice to read books included in the bibliographies of books you thought were useful is really useful. I also really like the idea of being able to monitor your progress as you work through your reading list. I already kind of do this, just not exclusively with programming resources. I use a website to keep track of the books I want to read and the books I’ve already read. I like being able to see all of the books I have or want to read, because I know if I didn’t store that information somewhere I would forget all about it. It’s also really interesting to be able to analyze my own reading statistics like what genres I tend to read and what days I read more. I use it mostly for pleasure reading, but I think it would be useful to dedicate a section of my existing list to programming resources.

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

Apprenticeship Patterns: Dig Deeper

The ‘dig deeper’ apprenticeship pattern imagines a scenario where you have familiarized yourself with a number of tools but only enough to be able to implement them into your own system. You do not take the time to properly engage with these tools, and you only ever learn enough about a tool to get through your own individual work. This superficial understanding of your tools can lead to issues, and you may have trouble recognizing and solving bugs that arises because of a given tool. The solution is to take the time to acquire a more in-depth understanding of these tools and technologies. This will give you a good foundation to build off as you learn other tools and will give you a more holistic understanding of the systems you work on. You should learn enough about the tools you used to be able to solve any issues, but you should not completely devote yourself to becoming a specialist in those tools.

I think this apprenticeship pattern is interesting. I am interested specifically in the Hoover and Oshineye recommendation to become familiar with debuggers that show you your running program, become familiar with wire-level debuggers, and be willing to read specifications. I knew that different types of debuggers exist, but I was never sure in what situations you would use them. I should follow this advice and do some in-depth research on at least the debuggers they mention. I also thought it was interesting that they recommend reading through specifications for tools; I do try to do this whenever I am introduced to a new tool.

I am definitely guilty of only learning a tool enough to use it in my own project, but I want to get better about understanding the tools I use. I think the advice in this apprenticeship pattern is very useful in this way, particularly the advice to obtain information about your tools from primary sources. I think being able to read through, parse, and fully understand specifications and defining theses would be beneficial to my career. I would feel a lot more confident working on a system with tools that I can comprehend the workings of. I think this is a good way to develop my skills and prepare for my future career.

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

Apprenticeship Patterns: Craft over Art

The craft over art apprenticeship pattern becomes relevant when you are hired to build a solution to a client’s problem. Building this would give you the oppurtunity to try something new, however a standard and stable solution already exists and is readily available. Hoover and Oshineye suggest focusing delivering to the client what they need rather than indulging an interest. It is better to build something functional for a customer over something beautiful, and you should work to balance the desire to create something artistic with the need to create something useful.

I think this apprenticeship pattern is interesting. I think, especially in a professional environment, your priority should be to create something your customer can easily use over something cool. It this pattern could be really useful if used in tandem with the breakable toys pattern I wrote about previously. I don’t think it’s bad to want to do cool and artistic things with your projects. Building something you think is beautiful sounds like a really good way to expiriment and develope your skills. However, if that interest interferes with your ability to deliver functional products to your customer, it may be wise to indulge that interest outside of work.

Reading through this design pattern has helped shape my expectations for my future profession. It highlights for me how focused the industry is on utility. I was not expecting to be able to use work projects as expressions of creativity, and this has confirmed that. I know to keep my personal and professional endeavors separate.

I do disagree a little with the way Hoover and Oshineye discuss creating beautiful works. In sections of this chapter, they talk about wanting artistry in your craft as if it is a bad thing. I agree that you should be able to recognize when it is appropriate to invest time in making a customer’s product beautiful, but I don’t think that urge should be shut down completely. That energy could easily be channeled into a personal project; you shouldn’t stop trying to use your skills to make beautiful things just because it might not benefit your employer.

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

Sprint 2 Retrospective

My team is about to move on to our third sprint, so I want to spend some time reflecting on how our second sprint went. Our plan for this sprint was to build a working demo of a Kubernetes cluster that we could deploy to AWS EKS. While we did not get everything done that we wanted, I am happy with the progress we made during this sprint. We got very close to deploying our cluster; the cluster is nearly set up, and AWS EKS has been configured for it. We are prepared to finish our demo at the beginning of our third sprint.

I think for this sprint, we had a much stronger idea about what we actually wanted to accomplish. Compared to our first sprint, this second sprint was much focused more on creating something than on research. It was easier to divide tasks into manageable issues, and it was clear what had to be completed with each issue. Not that the research we focused on wasn’t important, but it was satisfying to be able to apply that research to an actual demo.

In the same vein as the above discussion, having a more streamlined idea of what needed to get done did make it a little more difficult to work. A lot of the issues we decided on depended on the completion of others. It was difficult deciding which issues to take on individually; I felt bad doing nothing while waiting for whatever issues needed to be completed first got done, but in some cases it was necessary. As we complete our demo and move on to focus on communicating with other teams about our project, however, I think this will be less of an issue.

As a team, I think we could still improve our use of Gitlab for communication. I think we were definitely better about it during our second sprint, but our communication was largely remained on Discord, Zoom, or in person. It would be nice to have a more permanent record of our discussions, especially when those discussions are about the work we’re doing and the direction that work should be leading us.

As an individual, I want to take on more challenging work. The issues I worked on during this sprint were pretty simple, and two of the three of them were very easy to complete. I think it would be a better learning experience for myself if I tried to focus on more complicated issues. I also want to get better at communicating with my team. I think I should be talking more to my team members about my progress on whatever I am working on.


Add commitlint to gitlab-ci.yml to demo repository – I added a gitlab-ci.yml file to the repository that will host our demo.

Look into IAM Roles for EKS – In order to deploy a Kubernetes cluster to EKS, it (along with its nodes) must be assigned an IAM role. This post details the roles Amazon recommends using, and it has links to instructions on setting them up properly.

Determine what projects we are using for the demo – We decided to use a simplified version of a frontend/backend/API project for our demo.

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

Apprenticeship Patterns: Breakable Toys

The breakable toys design pattern proposes a solution to working in an environment that does not welcome failure. Since failure is such a huge part of the learning process, it is important to create a private space outside of work where failure will not damage anything. Hoover and Oshineye recomend building a simple system that is relevant to your work and easy to build upon. For example, you could build your own wiki and use it to learn HTTP, databases, and web design. You should enjoy the thing you are building so that you are motivated to keep building and breaking it.

I think this design pattern is really interesting. I can see how it would be useful to have a private project to mess around with and not have to worry about breaking it. This seems like a very good way to build up your confidence in an area while also being able to experiment with new skillsets. I also think it is useful to build a project you are personally interested in. If you are interested in the project you are using to learn, you are more likely to keep experimenting with it.

I probably will wind up adopting this design pattern once I enter my professional career. I like the idea of having a private project to experiment with; it would be nice to have the chance to get more comfortable with concepts I’m less familiar with in an environment where failure has few consequences. I am specifically interested in the example the book mentions of creating breakable games. Especially if it’s a project I’m interested in and enjoy working on, I think it would be easy to keep myself interested in working on it.

I do disagree with this being the solution to a work environment that doesn’t allow for failure. I think any work environment should be able to tolerate failure; if your work expects you to succeed all the time, you should not be working there. Rather than taking on extra work in an effort to avoid failure, you should find a healthier work environment.

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

Sprint 1 Retrospective

As my team moves on to our second sprint, I am reflecting on our progress so far. Our project, deploying LibreFoodPantry to AWS EKS, is new this semester. My group is essentially starting from scratch. As such, we spent most of our first sprint researching and compiling information about AWS EKS, Kubernetes, and other relevant tools.

Overall, I think my group did a very good job during our first sprint. Since it was mostly research, I think it was easy for our team to excel. We were able to complete all of the work we had laid out at the beginning of the sprint and now have a better idea of where our second sprint will lead. Everyone was very efficient and got their work done in a reasonable time. It felt like everyone was doing an equal amount of work; it didn’t feel like one person was doing the bulk of it. We all worked well together and were able to communicate when we needed to.

My team did struggle initially trying to break down the work we needed to do into smaller issues, and I can see this may be a problem going forward. No one on our team has extensive experience with AWS EKS, so it can be hard to tell what needs to be done and what is worth researching. I think this will get easier as we become more familiar with our project and how we want it to progress. But this did make it difficult to plan our first sprint.

Something I think my team could improve upon is communication, especially on Gitlab. Most of our conversations about our project were held either on Discord or in person. This sometimes makes it difficult to review what we had talked about afterward, and I imagine it will make it difficult for the group that takes over this project next to understand what we did. It would probably be more useful to have these conversations in the comments of a relevant Gitlab issue.

In addition to communicating more on Gitlab, something I feel that I personally could improve on is time management. I was still able to get my work done in a timely manner, I would not plan out my time well. I am not good at predicting how long a task will take me to complete. I would underestimate how much time a task would take and leave it until the last minute, or I would overestimate the amount of time it would take and wind up with nothing left to do. I want to plan my time more efficiently for the next sprint.


Look into how to set up AWS access for us – I worked on this issue to get our team access to an AWS account so that we could start learning the tool.

Research AWS EKS – This issue provides a set of resources for someone looking to familiarize themself broadly with AWS EKS.

Research and report best practices for Kubernetes – This is a listing of some best practices to keep in mind as our team begins to work with Kubernetes.

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