Category Archives: Week 11

Record What You Learn

You should not also underestimate the power of writing itself….You can lose your larger sense of purpose. But writing lets you step back and think through a problem. Even the angriest rant forces the writer to achieve a degree of thoughtfulness.

—Atul Gawande, Better

This pattern grabbed my attention. It looks interesting, as most of the patterns in this book. Apprenticeship Patterns is a book that in a way, teaches and gives more lessons on how to be a good software developer. In relation to the title, we are also every day recording what we are learning, not only by writing the blog posts of this special book, but even in all the sprints, we are working on GitLab, by solving different issues. All this time we are recording what we are learning.

When I started my studies here in the US, the first thing I faced that was totally unknown to me was the way of teaching and how the class organization works. Firstly, it looked like something I won’t learn, but at the same time, I was trying to fit in with everything. After some lessons, I understood that the professors here try to help with learning, based on different methods of teaching and sharing the materials for the students and making those materials understandable in different ways. The first thing I noticed, was the organization of the class into groups, after that, I remember last fall in software process management we worked on some cards, by using Flowban (Kanban Simulation). Another thing was the blog posts using WordPress, and the last one is the sprints we are working on Software Dev Capstone, as I mentioned before.

The flow ban cards for me were unfamiliar. It was something we were only learning in class, but at the same time, we tried to work for them. Then I understood that we needed for our future job on the companies we will be working on and that its role was to help the teams identify bottlenecks in a workflow process of work. Later on, regarding blog posts, I understood that their role was in one way to make us record better what we are learning during all classes. And also last but not least is the Capstone class that prepares us for our future job. During this sprint, we are working on a software project and learning how to manage it by sharing areas it works in companies.

Atul at this pattern gives some different solutions on how to record while we are learning. But the one I apply for is having my own private records. Perhaps writing everything in my own notebook is something I used to have since I have studied in my country. But it is something that helps me express more what I think than writing on the computer. And I think a notebook will always be the only secure resource, where I can record what I am learning.

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

Reflection on the Learn How to Fail Apprenticeship Pattern

The Learn How to Fail Apprenticeship Pattern is a relatively simple, and yet extremely important pattern to keep in mind at all stages of your professional journey. It states that we should learn what we are not good at, learn where it is that we fail, and learn what parts of that failure are worth learning how to fix and what failure we must just accept as something that we aren’t good at and move on to improve the things that are worth improving. It is about learning what behaviors, conditions, or habits lead us to failure, and learning how to get around them or just accept them for what they are.

I really liked the idea that they brought up about keeping a list of your skillset in your own personal wiki, that way you can always see what skills you have, and what skills you are losing over time. This way you can choose what is worth continuing to work on, and which skills are no longer useful to you. This is such a pivotal step to continuous self-improvement and learning that is a common thread throughout all the apprenticeship patterns. We need to be able to identify our weaknesses and learn why they happen so we can improve, and I think this is a really good way of going about it. I also really liked their action plan, writing code in a simple text editor, writing tests for it, and revising it without ever compiling or running it until it is perfect. I thought this was a really good way of testing yourself and finding the weak points that will follow you throughout every project you work on. I know that I have some weaknesses in my knowledge base, and some habits that will lead me to failure and moving forward I would like to take note of them and work on them as they come up in the future. I accept that failure is inevitable, but continually working on those failures and allowing myself to learn from my mistakes will make me a better developer.

If I disagree with anything in this pattern, it would be that you should drop things that would take a disproportionate investment of time and effort to accomplish. I think that sometimes, even for a little improvement, it is necessary to sink way too much time and effort into certain things that are fundamental or are extremely important to a project. Not all the time, but it is important to be able to make that distinction for yourself and figure out what is really needed to improve, regardless of the cost.

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

The long road

Warren Buffett once said: “The stock market is a device for transferring money from impatient to the patient”. However, I’m not going to discuss stock trading or how the stock market work. This post will concentrate on the similarity between the stock market and software craftsman is patience.

The world that we are living in focuses on overnight celebrity and ephemeral success. The majority of people these days talk about quick rich schemes. Developers back in old days were passionate workers who loved their jobs and dedicate to them. Developers nowadays get into this field because of the tremendous total compensation at big tech like Amazon pays their engineers up to 200 thousand, Netflix is 400 and Roblox is 1 million.

The problem is developers aspire to become master software craftsmen, yet the aspiration conflicts with what people expect from them. We are blinded by the money and promotion package. The job once was to deliver quality and secured pieces of software. But now we tend to distribute soon enough to secure that bonus or to meet the deadlines which allow us to have those bonuses. We sometimes sleep on the job and forget our purposes.

So, what is the solution? Be an outsider. Thinking outside of the box. Focus on the long term rather than get rich quick scheme. Value learning and long-term growth opportunities over salary and traditional notions of leadership. The outcome would be better with a rich set of abilities. We eventually become skillful at learning, problem-solving, and developing healthy relationships. We should keep in mind that it would be a long journey hence we should have low expectations and let them influence the jobs we take and drive the ambitious. Have a strong mindset and “can do” attitude.

With the entire career devoted to the craft, it becomes realistic rather than vain to think about surpassing Bill Gates or Steve Jobs. The opportunities will open as the time comes and we should make sure that when it comes, we will be ready. And the important thing is to love the work that we do, do it with our heart and passion.

From the blog CS@Worcester – Hung Nguyen by hpnguyen27 and used with permission of the author. All other rights reserved by the author.

Rubbing Elbows

Rubbing Elbows is very closely related to Kindred Spirits. The idea is to actively observe the way people around you work, and to seek out people you can learn from. Most of the pattern is centered around pair programming, and it is certainly a very good example of Rubbing Elbows. When pair programming you want to find someone more and/or differently experienced from you. This will give you the greatest opportunity to learn; if you only stick with what you know and are good at, you will never grow as a developer.

This is actually something I am very excited to do. When talking to my classmate about potential job prospects, he suggested to me that I should do a remote job. I am very against this idea. I want my first job to be one where I am physically in the office surrounded by other developers who can help me out if I need the help. Pair programming is something that really appeals to me, especially if my partner is more experienced than me.

I worked at an internship where I was the only programmer. There was one other older guy who did programming, but he was mainly an engineer. I tried my best to learn from him, but the environment was not a professional development one. Working alone, I was not able to consult other people and could not determine if what I was doing was correct.

I cannot wait to enter the workplace and learn from other people. Rubbing Elbows is a great pattern, but honestly did not do much for me. I already wanted to meet people and learn from more experienced developers. In fact, when I wasn’t able to collaborate with others was the worst feeling ever. I think that I did good work, but cannot know until other people look it over.

My biggest fear as a developer is doing things wrong. There are many ways to develop software, and there are many ways to mess it up. I need the guidance offered by others; maybe not explicit guidance, but guidance nonetheless. Having someone to consult and learn from is one of my main goals as an apprentice. I am so new that I do not know what I don’t know. Rubbing Elbows with more experienced developers will help me along my path.

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

Kindred Spirits

Kindred Spirits seems like a good pattern if not taken forcefully. This pattern is all about joining a community of developers who have similar interests and/or skills to you. As an apprentice, your main goal is to learn. Working in a professional environment will not always provide this environment, and the mentors you gain along the way will have their best interests in mind – not your own. This is why it is important, as an apprentice, to seek out communities that you are drawn towards because they all have the same motives as you. The goal of these communities is to learn and experiment, and they will be the best place for you to do the same.

To be completely honest I had no intention of doing this prior to reading the pattern, and still am against it. I get why it is good, and I am not against having friends of course, but I am not sure I want to join a community. I guess the point is that you only go when you want so I could just abandon a community I don’t like. Like I have said in previous blog posts, I do not want to focus on programming as a hobby. I do enjoy it, and I am not against joining a programming community if I want to, but I am not the type of person to code for fun all the time.

That being said, I do see the benefits of Kindred Spirits. Of course it is good to have friends in the industry with similar goals, and I do plan on making friends. Having someone to talk to about something I am working on will give me a new perspective and may solve a problem, and helping someone else will test my knowledge on what I actually know. They say the best way to learn is to teach, and to have someone ask me a question I supposedly know the answer to will help me as much as it helps my friend.

Overall, I do like Kindred Spirits. Friends and community are always a benefit. I don’t like the feeling of being forced into friendship and community, but I don’t think that’s what the pattern is saying. I believe it is saying to keep yourself open to new opportunities, find people who you get along with, and use your fellow apprentices to your advantage.

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

Confront Your Ignorance Pattern

For this week’s apprenticeship pattern, I did a reading on “Confront Your Ignorance”. Confront Your Ignorance is about how to start the process. What I mean by this is to pick a tool, skill, or technique and use it to fill in the gaps of your knowledge about it. Confront Your Ignorance is overcoming your lack of knowledge in an area and doing your best to learn more about it to become knowledgeable about it. This pattern ties close together with Expose Your Ignorance pattern. However, implementing this pattern is a bit more doable since it is less of a challenge on your pride since it can be done privately. Other solutions besides learning on your own would be to ask your mentors or anyone that you know that may already have the skill and is willing to share what they know.

My initial reaction after reading this pattern is that it is a reflection of what I am currently experiencing. I have mentioned before that I have limited experience in the professional field of software engineering, I am constantly trying to fill in any gaps of knowledge to make me more of an ideal candidate to companies compared to those who have multiple internships under their belt. The reading was quite interesting and very useful. Interesting because I can relate to what it is talking about and useful because it helps me with my current job hunt and figuring out ways to tackle this issue. Even before reading this pattern, I’ve been trying to find ways of attaining skills and knowledge that I haven’t gained before.

The pattern has not changed the way how I view my profession because I know going that transferring from school life to being a professional Software Engineer, there will be a gap of knowledge I won’t have. I know that I am going to be required to research and learn new things in my career. Therefore, I am constantly practicing my skills and working on side projects to help myself get a good grip on how each technology works and how to incorporate it in what I want to do with my professional career.

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

Apprenticeship Pattern: Concrete Skills

Christian Shadis

In the apprenticeship pattern Concrete Skills, Hoover and Oshineye explore the importance of developing discrete, demonstrable skills with specific technologies. This is an important pattern to implement as a young programmer because often in the hiring process, your skills are often more surface-level, and your value lies in your potential. Developing concrete skills makes you a more valuable candidate and thus more likely to receive an offer.

This pattern makes a lot of intuitive sense. My skills (outside of specific languages) are top-level, and I do not have a lot of projects to demonstrate specific skills and value that I can immediately provide to the company/team I am joining. Currently, my appeal as a candidate lies primarily in my successful academic career and ability to quickly learn, and secondarily in the skills I already possess. In order to successfully find a job, supplementing my portfolio is necessary.

This pattern coincides well with the Breakable Toys pattern in that building those personal, low-stakes projects will allow the developer to demonstrate their skills in a discrete, specific, and demonstrable environment. The toy can then be used in the hiring process, or to develop a demonstration for the hiring process. Having that project available to demonstrate during the interview process will reassure employers that not only does the candidate have potential to contribute greatly as time passes but can also contribute immediately.

I hope to use this pattern throughout the next several months while trying to secure my first career position. I have identified the biggest weakness in my resume to be my lack of full projects to display my skills. I have worked on multiple programming projects that I can use, but they all seem too simple to truly impress a hiring manager. I have a great academic record, but little to concretely prove my development skills. In conjunction with the Breakable Toys pattern, I will look to develop a full-stack project over the coming months that I can add to my portfolio and increase my chances of being hired.


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

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

Stay in the Trenches

This apprenticeship pattern talks about how software developers should stay in the trenches. As software developers gain experience, they tend to gain a reputation for being exceptional at delivering software. Many organizations tend to reward with promotions in the hierarchy. However, such promotions might end up leading apprentices away from their craft. This pattern elaborates how apprentices should not confuse promotions into management with success. Being promoted might seem like a good sign that you are on the right path, however, one should understand that they will not remain a “technical” manager for long.  A craftsman who strays from their craft will have their mastery over it fade. The more time you spend not programming, the further away you are moving from being a journeyman.

If an apprentice wants to remain in the craft, then they need to draw their career map accordingly. For example, one could try to discuss with their employer the possibility of finding different mechanisms which they may find rewarding. This could come in the form of higher compensation, or it could come in the form of nontraditional technical leadership roles such as internal consultancy. In the case where the employer is inflexible, then perhaps it might be best to look at other opportunities elsewhere. This way you will remain in the craft and prevent yourself from being promoted away from it.

I personally think that this apprenticeship pattern is useful for people with a specific set of values. It is useful for anyone who values their passion for staying in software development and wants to stay active in the craft. If you are someone who loves software development and want to continue However, some people might value things like status, compensation, and greater responsibility more than remaining active in the craft, and therefore, going into management might be the right move for them. Since different values can lead to different career paths, it is important for software developers to constantly reevaluate their career map to see whether the path that they chose is aligned with their values and circumstances or if they need to consider a different path.

From the blog CS@Worcester – Fadi Akram by Fadi Akram and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog Post 1

This week I would like to look at the “Confront Your Ignorance” pattern. I feel like this is always a good one to look at as despite how good of a programmer you might be, there is always something more to learn, and there is always something you don’t know.

This pattern means there are things you still need to learn/know, and some of these things are things that many others may already know, so it is expected of you to also have this knowledge.

I feel like it is always important to confront your ignorance, as there is still much to learn, even when you have seen a lot. This pattern is very similar to the “Expose Your Ignorance” pattern, but this one is about learning in private, so you do not need to hurt your pride by making others aware like in “Expose Your Ignorance”. However, it is still important to know to expose that ignorance as well, since always learning in private can have some negative side effects, like having failure be unacceptable instead of just another step of the learning process. You need to be able to learn and grow in a way that will positively affect you and those around you.

But should you choose to not learn in private, a great way to confront the ignorance is to ask questions, as many people may have already had the problem you are currently facing, and are hopefully happy to help you overcome the issue. A common cause of ignorance is focusing too heavily one one particular skill or context, which causes you to become ignorant of the other skills. One must be able to learn, and identify the areas of ignorance, and actively work towards reducing those areas.

You must also always be able to admit your faults, in this case admit that your knowledge is lacking, as how will anyone know your knowledge is lacking unless you tell them? This way, everyone can work together to achieve better learning. Of course, it may hurt your pride in the short term, but it is always better to be known for your willingness to learn more, than to know a lot about a few things.

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

Sprint Retrospective – Sprint 2

I think that we as a team, as well as me as an individual, improved during this sprint compared to the first sprint. While for the first sprint we had no experience working with scrum sprints or in any sort of team development environment, so the whole thing was completely new to us, whereas at least now with the 2nd sprint we had at least a tiny bit of experience. This means that we were able to improve upon some things from our first sprint, because we could see what we did wrong and could change our plan in order to avoid our previous mistakes and optimize our workflow overall.

The first thing we optimized and improved upon was our sprint planning. From our first sprint, we could better judge what we could get done during a sprint by how much we got done during our first sprint. This way we could efficiently work on items, getting as much done as possible during the sprint and not assigning too much during the sprint to the point that we end up not getting most of it done. We could also better assign weight to each of the items because we could better judge how long it would take for us to get each item done, and better judge the importance of each item to the overall project and current objective.

The second thing we optimized and improved upon was our overall communication. We still did most of our communication in class, but we now made sure to communicate through the issues on GitLab. When an issue required additional clarification or explanation, we could leave a comment on an issue and ask the creator of the issue for more details, and the creator could easily respond right on the issue. This not only improved upon the frequency of our communication, but it also helped us to differentiate and easily see what string of communication was pertinent to what issue, helping other team members to see what was discussed respective to what issues. This way, if a team member was working on an issue similar to or previously worked on by another team member, they could easily see what kind of issues that team member faced while working on it, and that could help them work through it without even requiring more help from the team. This makes the workflow as a whole much more efficient because any communication is saved, categorized, and easily searchable.

For the team as a whole, we could still improve upon our communication. Although it is efficient communicating through GitLab issues, and it does have some benefits, it is also good to have some non-official communication that doesn’t directly relate to a particular issue. Leaving this communication on GitLab would be messy, so it would be better if we did this additional communication through discord. For me as an individual, I think I could’ve helped more with the sprint planning, and better assisted my team members. For the spring planning, I could’ve better helped with coming up with weights for issues and assigning them. Finally, I could’ve better helped my teammates by being more active responding to open issues with comments and helping them finish open issues if I’m done with all of my issues.

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