Category Archives: Apprenticeship Patterns

Apprenticeship Pattern – Unleash Your Enthusiasm

The key focus of this design pattern is the situation in which you have more enthusiasm for software development then the rest of your colleagues. Due to this, you end up holding back to fit with the group. I have a few experiences related to both sides of this. While I’ve never partaken in a software job, I have taken part in software courses. There have been plenty of times when I’m in a group project and the topic is so interesting to me I can just get to town and code almost everything. I guess rather than having it hold me back, I end up usually embracing it.

Then there are situations similar to that which I’m in now. It isn’t precisely a mirror for the apprenticeship pattern, but it’s pretty close. I find that when I have other things I need to do are when I’m most passionate about other things. For example, I’ll most intensely want to theorize about physics when I have an assignment due; however, once I actually have free time, I’m mostly content just wasting my time playing video games. Over the last month, I’ve become fixated with Sea. I had been working on creating a Minecraft Server manager in Node.js for my friends and I, then I moved onto creating a way of backing up my playlists. Then I realized it’d probably be easiest to do it in Python, so I started rewriting the code. In that process, I fell in love with Python.

I had used it before and enjoyed it, but I was almost something of an elitist. It had no strict types, it was easy to write. I treated it as if it were a beginners language. So I never really took the time to learn it. I rewrote my code in Python and learned a lot of the joys of Python such as context managers, list/set/dict/string comprehension, etc. (I just need to figure out the SQL commands and maybe I’ll eventually finish it). I had always been aware of the fact that Python running in a single threaded interpreter will never be able to perform as well as something like C. C by itself has a lot of joy to write in. Every language has its own personality you get to learn. That said, C can be tedious to write in and to read. That began my quest to create Sea – a version of the C language with Python-like syntax. I have become passionate about designing what the ideal language would be. Something modular, with high and low level features, and is easy to write and debug. Sea is just the first step in that.

I have found that I can so easily spend six hours straight coding, debugging, and refactoring Sea code. I can then go to bed and while I’m trying to fall asleep or even while I’m dreaming, I’ll be making design decisions. Classes that are otherwise fine can seem boring by comparison. Being able to just create something functional that has a clear use case feels great. At least sometimes, it can be really easy to share that enthusiasm with other students and it overall helps all of us.

From the blog CS@Worcester – The Introspective Thinker by David MacDonald and used with permission of the author. All other rights reserved by the author.

Rubbing Elbows-Apprenticeship Pattern

In this post, I will be writing about the “Rubbing Elbows” apprenticeship pattern from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Adewale Oshineye and Dave Hoover, 2009. This pattern is for people who typically work alone when it comes to developing software and feel as if they had reached a plateau, not learning superior techniques and approaches.

The Rubbing Elbows apprenticeship pattern suggests that in order to cure this, you should work side-by-side with another software developer to complete hands on tasks. This can help you learn things that cannot be taught in a classroom or online. This is because you will pick up on certain micro-techniques that you can only really obtain through experience or being around/working with another developer. These techniques can add up, providing a significant increase to your skill. An example of this pattern given in this book is pair programming. When used correctly, it can be one of the best ways to learn. Pair programming (especially with a mentor) can help you pick up other skilled developers’ habits and lets you observe how they polish those habits to improve their own skill.

If you do not have this opportunity at your workplace, the book suggests that you find someone who is interested in contributing to open source projects. It suggests you should take one night a week to work with this individual on the project in a sort of pair programming manner, learning from each other as well as motivating each other.

I completely agree with what this pattern says. Working together with someone on a project or tasks, side-by-side, especially with someone with greater skill can greatly boost your skill, and exposes you to certain things that you cannot be taught directly. Not only with coding, but with other hobbies in my life, being around others really helped me pick up on things quicker. For example, I started snowboarding last year. I had three friends who I would primarily ride with, two extraordinarily better, and one the same skill level. I had been motivated by the one the same skill level, and learned from him by observing certain techniques and habits that helped him improve. I had also picked up certain styles, techniques and habits of the ones already at a high skill level, boosting my knowledge and understanding. Now a year after starting this new hobby, I am more skillful than 70% of people on the mountain(not to be smug). This is greatly because of going with my peers.

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

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Share What You Learn -Apprenticeship Pattern

The “Share What You Learn” apprenticeship pattern, written by Adewale Oshineye and Dave Hoover in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, 2009, is about sharing your knowledge. This is for software apprentices who have solely focused on their own growth/improvement. Sharing what you learn can benefit yourself as well as others. This is because it helps you learn to communicate what you know effectively, but also helps people who are on the same path as you, trying to learn the same things.

Maintaining a blog, tutorial channel, etc. during your early apprenticeship years can be great for your growth as a developer. You may feel like you only have a basic understanding of some topics that you have just learned, but this may benefit others more than you would think. As the book states, your basic understanding will translate to an easy to understand, straight to the point article, blog post, etc. that will help other apprentices who are right behind you in the journey to becoming a master. So don’t think that you need to leave it to someone who has an extreme in depth understanding of the topic, often times what they will give back to the community will not be as beginner friendly. You must be careful when sharing knowledge though and make sure that you are not spilling a companies secrets that can ruin your relationship with your team or get you in legal trouble.

I like this apprenticeship pattern in particular because it benefits yourself and others at the same time. Teaching is a great way to learn for both the teacher him/herself, and the student/learner. A certain part of this pattern really caught my attention and that is to not worry about leaving these posts/tutorials to people who have greater knowledge of the topic. Often times when learning something new, I will go to forums rather than tutorials. On these forums you can often find threads where students are asking the same questions about a topic that you are wondering yourself, and a lot of times other students will respond to these questions with their understanding of the topic. This is a great starting point for learning something new because often times there are basic, easy to understand, straight to the point responses that can kickstart your learning of the topic.

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

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Learn How You Fail – Apprenticeship Pattern

Today I will be writing about the “Learn How You Fail” apprenticeship pattern from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Adewale Oshineye and Dave Hoover, 2009. This pattern is for everyone. Everybody has failed at something and will again in the future. If you are not failing then you are not pushing the boundaries of your capabilities, and/or you are overlooking these failures.

The problem addressed in this apprenticeship pattern is that you have enhanced your success through learning, but failures and weaknesses remain. The solution to this is to gain an understanding of the habits, behaviors, and patterns that has led you to failure. With self knowledge, you can make conscious choices to avoid these behaviors/habits or to break them and give you an idea of your limitations. As explained in the book, This can help you make a decision whether to fix a problem or cut your losses. If something is going to be a disproportionate investment of time and money only for a small improvement, it may be time to improve on something else instead. Excepting your limitations is important, seeking for perfection will only disappoint. This could mean letting go of some areas of expertise that cannot benefit you as much if you do not have the time to maintain those skills.

A method recommended by the author is to keep a list of your current skillset and boundaries. This way you can have an organized view of these boundaries and decide which areas you would like to push/explore. I found this interesting because it is similar to the “Record What You Learn” design pattern that I had written about in my previous post. By writing down your experiences, you can gain a greater understanding of what is happening. This way you can grow as a developer. Writing down your habits, actions and patterns which cause you to fail, can help you move forward from the endless loop of repeated actions leading to failure. I like this pattern because it accepts that you will fail sometimes, but whats worse than failing is to not push your boundaries. This pattern helps you understand and map out your boundaries so you can push them in an organized, thoughtful way.

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

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Record What You Learn – Apprenticeship Pattern

In this post I will be discussing the apprenticeship pattern, “Record What You Learn” written by Adewale Oshineye and Dave Hoover in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, 2009. This pattern is design towards people who end up learning the same lessons over and over again or going through the same experiences or failures but can never get the details or reasons to stick.

The solution suggested is to create a blog, notebook, or wiki that you can treat as a journal and record important things that you learn. This is not to write down and forget about. Throughout your career you should return to this journal to review it and make new connections in your memory. When reviewing you should update what is written as more knowledge and experience is accumulated over time. The authors even suggest creating two blogs, one a public record and one a private. This allows you to share the lessons you have learned and also get feedback on what you have written with the public record and be able to be brutally honest with yourself in the private record. Internal and external feedback allows you to have an honest and accurate self-assessment. The main goal of this pattern is to keep a journal of your path to mastery so that you can reflect on and learn in the future.

I found this particular apprenticeship pattern interesting because this morning I was thinking about starting a notebook in which I can keep any important lessons as well as important details. This way I would be able to look back on it frequently and grow as a developer. This could include important concepts, design patterns or failures that I can learn from as I move forward. This book has provided a useful structure in which I can follow and also has inspired me to follow through with it since I have said I was going to do it a few times already but never have. Also, it has given the idea of two journals in which one can be private and one public. Maybe also different journals for different topics such as one for design patterns, one for lessons learned, one for important topics, etc.

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

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Sweep The Floor

This post will be about the “Sweep The Floor” apprenticeship pattern from the book, Apprenticeship Patterns by Adewale Oshineye and Dave Hoover. This pattern is about finding your place on your team, contributing to the teams work to earn their trust and respect, and growing as a developer. The pattern suggests taking on the undesirable peripheral tasks when joining a new team/project. This will help you learn more about the project, development as a whole, and will keep you away from the core of the project. These tasks are often overlooked in education so this can help you fill in the gaps of education while working on something low risk. This does not mean lack in quality though. keep good quality, as bad quality on these portions of the project can become troublesome later on.

There are some problems with this pattern mentioned by the authors that I agree with. One is that you may become the guy who they use to do such dirty work, lacking in opportunity to work on more challenging tasks. Another problem is that you may become intimidated by anything that isn’t the easy yet boring work. Although you learn from this work, there becomes a point where you start to plateau from lack of challenge. The authors solution for these problems are to advocate for yourself and look for every opportunity where you can show them you are capable of contributing to higher tier work. Showing them enthusiasm and skill should make them realize that you are ready and capable to move on to more skillful tasks.

I found this useful because everyone has this starting point where they’re at their first job in a profession and need to gain the trust of their team members. Showing them that you are there to contribute can go a long way and nothing shows that better than when you do the tasks that no one wants to do. Although I already had an idea of this, the book really gave me a solid idea of what to expect to do at my first job as a developer and how to get my team to welcome me.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Finishing Up The Patterns

The final pattern I will be writing about from Apprenticeship Patterns is “Retreat into Competence”.

The “Retreat into Competence” pattern describes how to solve the problem of when you begin having issues as you start working outside of areas you are comfortable in.

I like the ambiguity of the opening quote by Robert Pirsig, I find that it is comforting while being vague at the same time. I agree with the quote about not knowing where I currently am but what I’ve done so far seems to make sense to me. I like the idea and I think I need to think more about what I’ve done so far as a computer science student to find what my “pattern” is so I can use the advice Pirsig seems to suggest and apply my own “pattern” going forward.

The topic that the pattern covers is something that makes me think about what I’ve learned as a computer science student as I am reaching the conclusion of my work for the major. In particular, it makes me think back to a conversation I had with Dr. Wurst and especially when he mentioned the fears of not knowing enough as I approach graduation.

I particularly connect to the idea that the pattern mentions of a deadline problem. The deadline problem was something that I thought would happen on Monday with my work on the UpdateGuest project and I wasn’t completely sure if our group (and I) would be able to finish our project before our review meeting. Additionally, I was having a hard time figuring out how Angular worked towards the end as I was trying to finish the issues I needed to for the project to be done. I got past the problem though with the help of my teammates and one awesome article my teammate found which helped us to get our Angular form implementation working.

I think the advice offered in the pattern is important and I agree that it is good to occasionally remind yourself of what you’ve learned and what you can already do, especially when you can’t solve a problem you are working on.

I found the “Retreat into Competence” pattern to be a fitting final pattern to write about as I finish up my work in the software development capstone course and as a computer science student. I am making it a goal to finish the rest of the patterns in the Apprenticeship Patterns book over the summer as I have found the advice to be helpful and I am curious about the remaining patterns as they are frequently mentioned in the current and previous patterns I have read.

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

Improving as a Developer

Today’s first pattern in Apprenticeship Patterns is “The Deep End”.

“The Deep End” pattern describes how to avoid getting stuck at the same level of being a developer and how to take risks to improve yourself.

As far as the “Context” area of the pattern goes, luckily, I don’t think I’m in a “rut” right now. Currently I’m still learning about lots of new things and tools at the same time and although I would like to make more progress, I think I’m still moving forward.

The “Problem” section makes more sense to me than the “Context” area and I agree, and I would still like to improve my knowledge and keep on learning about the tools I am currently working with. I agree with wanting to have additional projects I have worked on for when I apply for a job and I would like to have these shown on my GitLab account.

I think the part of the “Solution” for the pattern that describes “Waiting until you’re ready” is one of the most relatable parts of any of the patterns so far. I agree with that statement and I feel like I should just start learning new tools or adding work to a project instead of continuously waiting until I really feel like doing it. I feel that I should schedule regular times for learning or working on implementations to help avoid the problem of not feeling ready.

The example provided with Enrique’s email is especially impressive. I don’t think I’m quite ready to do something like Enrique did, however I do think that the email illustrates the success that following the pattern can get you and that there was a lot of value in including it.

Answering the “Action” questions I think the largest project I’ve worked on as far as team size goes is with my current work on the UpdateGuest project. As far as size goes, I think my own personal project might have the most amount of code (although the size may be tied close with UpdateGuest). I think the idea of different project “metrics” is interesting and I think some other useful ones could be total time spent working on a project and how automated the project is as far as CI/CD goes.

I think that the pattern offers valuable advice, especially with avoiding a “rut” and I would especially like to think of more and keep track of the different project “metrics” as I continue to work on old and new projects.

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

How to Learn about New Tools

The second Apprenticeship Patterns pattern I looked at today is “Confront Your Ignorance”.

This pattern explains how to improve your knowledge in areas you aren’t as experienced in. The pattern also provides possible drawbacks of focusing too much on self-improvement.

The “Context” and the “Problem” sections of this pattern are relatable to me currently. I can clearly see that I have a problem with my knowledge of Angular and I need to learn more about this in order to develop frontend applications. I do somewhat disagree with the part of the problem area that says I “do not know how to begin”. I think at this point I have a decent idea of how to learn about new tools. Although maybe it is correct as I have still yet to feel like I have a good understanding of Angular after trying to learn more about it.

I do like and use both of the suggested methods for learning about new tools. Usually I like to read documentation and introduction guides on a tool’s website, but I also like to follow along with example projects. Additionally, I have found that watching a video tutorial series (mainly on YouTube) on a particular topic can help a lot with learning about something new. This is how I learned about a lot of the backend tools my team used this semester and I am especially a fan of the YouTube channel one of my teammates found. This suggestion is something that I feel should be included in this pattern as I have found this method to be one of the most valuable ways of learning about new tools, especially if there isn’t much documentation for it.

If I had to pick only one thing to learn more about it would be Angular. This is something I have consistently been trying to learn about for a while, ever since I first learned about it, and it has been something I’ve tried to improve on this semester but I am still not satisfied with my knowledge with this tool.

I did find the provided downsides to be the more intriguing part of this pattern as these are points I wouldn’t have thought to be in a pattern about how to learn new skills, but they do make sense after reading about them.

I do think that this pattern provides some good general information about learning about new topics, but for me I wish it was a bit more specific as I find that I was familiar with most of the information provided in this pattern about learning about new tools.

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

The Value of Asking Questions

This morning’s pattern in Apprenticeship Patterns is “Expose Your Ignorance”.

This pattern helps explain to early developers how to get over their initial lack of knowledge in the field by asking questions and seeking out knowledge and the importance of doing this instead of pretending to know everything.

To me this pattern and especially the “Problem” area feels very relatable right now with where I am this semester, especially with another attempt at learning how Angular works.

I do find that this pattern provides me with some valuable reassurance, and it is more comforting to know that this problem happens to other people.

Lately with my work this semester I have apparently been following the advice this pattern gives and trying to ask others in my group for help when I don’t understand something that I have been trying to do. This is important in our group, especially as different team members in our group have their own areas of knowledge from what they’ve learned this semester. Reflecting back on this more I wish that I asked more questions (especially during meetings) and focused more about how something works instead of just the solution as this would have had a far greater benefit in increasing my knowledge.

I agree with the idea that answering questions helps to understand the problem better. I can think of many times this semester where I either asked questions that helped find errors in something or when answering someone else’s question made me think more about it.

I do like the idea that the “Action” section presents, although it does feel somewhat exposing to visibly have on display things I don’t know. I am trying to think of a good digital place to put something like this, perhaps on my GitLab account. As I’ve probably alluded to in my posts so far, I think my top items (although this isn’t five items as the pattern suggest, these are things that are particularly holding me back) with my current work would currently be: Angular (and specifically forms), HTML, and Jasmine (this is especially a rather new one for me). I would like to refine this list some more and pick more specific topics to work on learning in each one of these broader items.

This pattern provides helpful knowledge and helps explain the importance of learning from others. Again, as I said before in my previous post, I wish I read this pattern earlier as the ideas presented in this pattern would have improved my learning this semester.

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