Retreat into Competence is an apprenticeship pattern that focuses on the idea that when you find yourself in a situation where you are overwhelmed with new information, it is alright to withdraw back into something you are more comfortable with. By doing this you allow yourself to gain back your mental composure, and gives you the opportunity to reflect on how far you’ve come as a developer.

I believe this apprenticeship pattern is incredibly true and helpful, as I have frequently found myself in situations where I do not feel confident in my abilities and as a result I get overwhelmed and stop being productive. When I first started my internship last summer, I was expected to use Python as the primary language. Up until that point I only had limited experience with Python, so I had many moments when I felt like I was in over my head with trying to learn a new language and also meet deadlines for the projects I was working on. During those moments I would often get a pretty bad case of imposter syndrome, and start believing that I wasnt good enough for the job. What helped me push through this was a similar technique to what is taught in this apprenticeship pattern. Whenever i felt overwhelmed with a certain aspect of the project, I would go back to a part of that project I felt comfortable with and work to improve on what I already built. By doing this I was able to stop the mental block, and by working on familiar material I felt like I was making progress. This in turn helped me figure out issues I was having with other parts of the project and slowly push through them to finish everything up.

Since I have used this apprenticeship pattern in the past with success, I am almost certain to use it again in the future. Since I just graduated and am about to start my new career, I am sure plenty of situations will pop up where I again feel overwhelmed. When those situations arise, I now have a strategy I know will work, and I can rely on it to help me get through whatever issues might come my way.

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

Expand your bandwidth is an apprenticeship pattern that teaches the idea that as well as learning and improving at tasks that we are comfortable and familiar with, we need to be able to learn about completely new and novel ideas in order to excel in our fields. The pattern mentions signing up for online blogs, newsletters, and online forums as a way to learn about new ideas. The authors also mention that while this pattern is important in order to excel in software development, its also important to know when to use it, and when you should instead focus your efforts on the task at hand. Their approach to this is to try to designate time every now and then to learning new things, but don’t spend more time than necessary on that learning.

I agree with this pattern and I think it is a good approach to the idea that people are meant to be lifelong learners. It isnt realistic to expect us to always be learning new things, as that constant influx of new information can be jarring and oftentimes unnecessary in the things we are currently pursuing. This approach teaches us that its important to set aside time for learning new things, but not in a way that it interferes with our current tasks. As a college student I have been introduced to plenty of novel concepts throughout my undergrad program, so I understand the importance of learning new ideas. Likewise, once I go out into the work force I will most likely specialize in a specific set of tools, and my learning will narrow down to mainly encompass those tools that I will end up using. Looking forward into this future I can see the issues that the authors mention in this pattern, where not expanding your knowledge base can prevent you from becoming the best you can, and I agree that the solution is to periodically go out of your way to learn about new ideas and concepts.

I have not really applied this apprenticeship pattern much in my life as of yet. A lot of my learning has come from my undergraduate program, and as such I have had the privilege of being exposed to a wide knowledge base. I do however, plan on incorporating it in my future career, since I believe that acquiring new knowledge will be important if I want to have a successful career as a developer.

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

Practice Practice Practice is an apprenticeship pattern that focuses on the idea that deliberate practice is the best and most efficient way to learn and master a craft. This apprenticeship pattern is similar to breakable toys, but it is more focused on the actual act of practicing rather than the consequence free ability to make mistakes. The pattern talks about doing challenging tasks repeatedly, and noting on what improvements and takeaways you have each time you complete the task. The authors liken it to a sort of programming dojo, similar to that of a martial arts studio, where repetition of motions without opponents is essential to excel in the martial art.

I absolutely agree with this apprenticeship pattern, and believe that practice is realistically the best way to actually learn to become a better programmer. While lectures at school are useful to learn about the subject matter, to truly understand it and begin to master it you need to be able to apply it yourself. I have first hand experience with this thanks to the internship I did last summer. While I do learn a lot in school, lectures and assignments only go so far. Being exposed to real world code and having to learn a lot on the job taught me a lot of practical skills that I otherwise would not have quickly learned. I was also surprised by how quickly I picked up on these things, and that even a little bit of repetition managed to ingrain new information into my head.

While I agree that this apprenticeship pattern is very useful, it can be hard for me to implement in my own life. If I am directed and given tasks to do then I will happily do them and learn new things in the process. The issue comes in when I need to self direct, and that can be difficult for me at times, especially with projects or activities that don’t necessarily peak my interest. For example, in order to practice for interviews I did leetcode questions as often as I could. While I did learn new things through the repetition that came from that, as time went on it became more of a chore and less of something I wanted to do and as such I began to do it less often. I hope to improve on this over time, and be able to stick to repetition for the sake of practice and improvement. Because while I can learn a lot at work, Ill have a harder time improving quickly if I also don’t practice on my own time.

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

Sustainable Motivations is an apprenticeship pattern that touches on the idea that despite loving programming issues such as frustration, lack of motivation, and in extreme instances burnout are still very possible. This apprenticeship pattern discusses how to deal with issues and attempt to mitigate them before they even really begin. One way to go about this is to make sure you keep a healthy balance between your work life and personal life. The apprenticeship pattern also gives anecdotes about times other developers dealt with an issue regarding a loss of motivation or uncertainty about what direction they want to take their careers.

To be honest this apprenticeship pattern did not click with me as well as the other ones I have read about so far. While I agree with the overall statement that you need to keep your ambitions and work in check to ensure you can maintain a steady level of motivation, it doesn’t really go into too much detail on how to go about it. The example I mentioned in my initial paragraph is one of very few where the authors actually talk about ways to manage this issue. They do reference another apprenticeship pattern called walking the long road, which discusses similar issues; but as an over all approach to trying to solve the specific problem they presented in this pattern the solutions given were mostly abstract and anecdotal. There is not too much that I can clearly take away from this pattern. Regardless there is still some lessons that I think are valuable, mainly the example I mentioned earlier regarding balancing time.

In my own life I have struggled with healthy balance of time. I tend to fluctuate between two extremes, either over focusing on work and sacrificing my personal life, or over focusing on my personal life and having my work suffer. Given this I can understand what this pattern is trying to say in that regard. While I was aware of this balancing issue in my life and have improved on it over time, reading through this pattern emphasized the importance of a good work life balance through anecdotal examples of issues other developers have also gone through.

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

Breakable toys is an apprenticeship pattern similar in spirit to Be the Worst. They both encourage us to improve by failing in one sense or another. While the Be the Worst apprenticeship pattern focuses on joining a team where you are the worst in order to learn from others on your team, Breakable Toys emphasizes working in an environment where failure is not only possible but even encouraged. Such an environment usually means working on your own projects where any mistakes you make have little to no consequences and allow you to learn from them.

Overall I think that this pattern makes sense, and is a good way to improve ones skills as a developer. I whole heatedly agree with the idea that failure is integral to improving in anything, and especially when applied to programming. I know that whenever I make a mistake I tend to remember that mistake and in most cases I am able to learn from it and improve myself. When writing code for class projects or assignments I frequently screw up certain feature implementations and as a result I learn of a better way to do what I failed to do. Be it through personal research after the fact or direct guidance from someone more experienced than I.

Personally I haven’t really created an environment for myself where I can comfortably fail. While I definitely learn a lot from mistakes I make at school, I wouldn’t go as far as to call that a safe place to fail frequently. Ive had a few personal projects in the past, but I never really thought of them as more than things to slap on a resume or to pass the time. Having read this apprenticeship pattern however, I definitely have a different outlook on those past projects, and will also have a different outlook on future ones. I will likely try to work on projects that heavily involve tech stacks I am not familiar with in order to attempt to learn from my failures working with them. It will be difficult at times as I can be impatient, and the slow initial progress with some of these projects might be discouraging, as well as any screw ups that might come along. But since I will be more aware of the fact that these setbacks are actually helping me in the long run I hope it will help me keep pushing forward.

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

Be the worst is an apprenticeship pattern from chapter four that focuses on surrounding yourself with people who are better than you in order to constantly keep improving yourself. The chapter argues that if you are the best in your respective group then you will not grow and improve as a person.

I whole heatedly agree with a majority of the points made in this apprenticeship pattern. From personal experience alone I know that this idea holds true. While in a classroom environment I am definitely not the best, but I am also not the worst. I tend to work with people at a similar skill level to me when I work on group assignments or in class work. While I still learn things in these environments, I know that I miss out on more nuanced knowledge that’s gained by experience. In an environment where most if not everyone is better than me, I could learn things from people that I would most likely not learn in a classroom environment. During my internship I was surrounded by talented programmers, and as such I was taught many different tips, tricks, and skills that I probably would not have otherwise learned.

Another thing I really resonated with in this pattern is the fear that being the worst in the team will result in lower overall performance or cause me to hold others back. This idea is daunting, but it also lights a fire under me and forces me to improve in order to keep up. One thing I do not necessarily agree with is the statement that joining a team as the worst member is selfish. I do not thing that is true, as long as you join that team with the intention of working harder than everyone else to keep up and improve. The team also may benefit from you joining, since because you may be inexperienced, you can potentially learn new ideas quickly and the team may be able to mold you to their needs as a result. This can be a win-win for everyone, you continue to improve yourself while the team gets to mold you to their needs.

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