Although I tend to speak rather broadly about certain apprenticeship patterns, nonetheless many of the patterns I have written about in this blog do apply to the field of Software Development. After all, the book, from which these patterns have originated from, that I have been reading for the past few months is more focused on programming than any other craft. This is the reason why this particular pattern applies to my learning process of Software Development which, ironically, I realise that I have not applied to the degree that I thought I have when learning other programming languages. In fact, a significant part of the learning process is to “unlearn” pre-existing knowledge and approaching learning a craft in a “blank slate”. This notion corresponds to a pattern titled “White Belt” which, though it may seem ironic, it is in fact a very significant pattern.

When a developer faces the need to utilize this pattern, it means that their pre-existing knowledge may be interfering with acquiring new knowledge and skills more challenging, or even impossible. When it comes to programming languages, the know-how that one may be holding on from learning and mastering their first programming language may impair their problem-solving approaches. Oftentimes, they may be expecting to see tools or concepts from one language they already know that are completely non-existent in the language that they are learning. Moreover, the potential differences in syntax can also throw an apprentice off when learning a new language, thus it is easy for us to hit a roadblock simply because the solutions we may want are (or so we think) simply not there. As such, a way to avoid this roadblock is to simply approach the new language that we are learning as its own thing and with a clear state of mind.

Usually, I tend to say that I like or agree with a pattern because in my own experience I tend to utilize such patterns in my own, perhaps roundabout way. However, this pattern is the first that has made me question my own approach to learning, which is contrary to this pattern. I often tend to look for “common ground” between my pre-existing knowledge and the new knowledge before me to “save time” and get to “the good stuff” faster. In a way, this pattern hurts my pride as a software apprentice. And, in all fairness, it should. It is important for me to acknowledge that flaw in my learning process and instead wear the white belt when I pick up a new programming language to learn.

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

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.

Concrete Skills

This pattern is something I’m personally invested in, as the feeling of imposter syndrome is incredibly hard to shake. Depending on the career path I eventually go down, I plan to get as familiar with whatever basic techniques and software that the project will be using. I’ll undoubtedly be inexperienced and unprepared, but to demonstrate a basic level of competency with the most basic of the workload, I want to be as proficient as possible with the fundamentals. My biggest fear would be what the pattern refers to as “day care,” as I would loathe to be babysat in such a professional setting. On top of this, I thought the comment that one’s concrete skills are basically what get your foot in the door was quite insightful for someone like me lacking any sort of hiring experience. I’m also very grateful that the pattern lists a few of the concrete skills with examples like understanding of open source frameworks or basic web design. 

In addition to stressing the importance of the concrete fundamentals, the pattern also goes on to explain how your reputation can be based on the credibility of your portfolio. As you grow from being the new guy into a successful developer, your work will speak for itself and shatter that initial requirement for consistent fundamentals. While the former is still important, you won’t have to work nearly as hard to prove your utility to a team.

For the Action portion of this pattern, I’m certainly on board and will implement this in my future job searches. While considering a few different professionals, there may be consistently noted discrete skills in the CVs, so that could be a great skill to implement regardless of the career path. On the other hand, some of those skills may be niche, but hyper specific to the type of job you’d like to apply to in the future. The pattern recommends regularly examining your own CV and implementing a similar kind of honed skill set for the specific position you may be applying to. On top of this, I would say that engaging with professionals or colleagues in this manner would work to bolster professional relationships, which could lead to advances down the road if they reflect on your tenacity. 

From the blog CS@worcester – Dummies that Code by howbrash 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.

This pattern really focused on the idea of your value as the new guy in a fresh team environment. Each party has no idea about the other’s techniques, patterns, thought processes, or communication abilities. While you’ll naturally get acclimated to the team through experience, it’s always a good technique to pick up some of the menail, but important work. It should show the team that you’re willing to pitch in, and if you take your time to make that menial work look stellar, then that’s an even better indicator of your talent and value to the team. It warns of becoming the team’s “gopher,” which I would say is a valid caveat; I guess I would prefer to think that most people are more professional than that.

For the majority of the pattern, I wholeheartedly agreed with this advice. It should garner comradery with your peers, and an improved understanding of the project – I would apply this to any sort of team effort in general, because if the members operate in good faith then it should promote the team to be a more effective unit (theoretically).  The only thing that I have a bit of a disagreement with is the assertion that you might be relegated to that menial work by default, after trying to sweep the floor for too long. I’d say as long as you engage with teammates about where they are on the project, ask questions, and actually learn from those conversations, you should be at least relatively qualified to work on more challenging tasks. On top of your understanding of the different project parts, I’m confident your peers will recognize your engagement and welcome you to cooperate with different or more challenging content.   

Finally, I can understand the sentiment that one won’t appreciate the bigger picture of the project, or would get uncomfortable attempting new types of work outside of their comfort zone. These are very different problems, and require a good amount of introspection to address in my opinion. I’m going to look at the referenced patterns near the bottom to see if he elaborates further.

I think the most important lesson I got from this pattern is not to make yourself useful initially, but make everything that you tinker with is as close to your best work as you can get it. Who knows who’ll be impressed?

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

A Different Road

You find yourself tired and bored of your work. You have some personal projects to advance your skills that keeps you busy, but you find yourself needing to take a break. To diverge from the road you are on to either just rest for a while or to just see where it goes. Your career as a software developer is not what ultimately defines you. A Different Road describes a scenario where the road you have been traveling on in your programming career is not the road you want to travel along anymore. You might wish to spend more time at home and with your family. You might desire to train for a marathon. You could buy a bit of land, build a barn and become a farmer.

The road of your software development career never truly ends until you decide to end it and even if you do, you can always start back on it again. Just like riding a bicycle you never really forget something that you practiced frequently. So, take the break that you need. Buy that farm and become a farmer. Your career is not what really defines you, and maybe whatever you try will need some kind of optimization that your skill-set can solve.

Ultimately this pattern speaks to the idea of breaking the stubborn mindset most people find themselves in. It’s this mindset of having a path and having no other choice. The path paid your bills and you enjoy it to a degree. It’s hard to accept the idea that this thing you have been spending your time on isn’t right for you. To align with the road analogy, the road you have been traveling has been well paved and barely has any traffic. As you travel further and further you might find it gets even easier and has even more lanes and less traffic. You might also find that this road has potholes and traffic has only gotten worse and worse.

Recognizing when that road isn’t worth traveling on is easy to think about, but harder to act on even when it’s right in front of you. But unlike the road analogy, your skills and motivation are not a car. You can’t sell it and lose it, it can’t be stolen from you, and even if you don’t use it for a while it doesn’t mean it can’t start back up again. The thing to take to heart is do what you want to do, but also stop doing the thing you don’t want to do just because it’s your career.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.