Category Archives: Apprenticeship Patterns

Use the Source Luke – Apprenticeship Pattern

In this post I will be discussing the apprenticeship pattern, “Use the Source” written by Adewale Oshineye and Dave Hoover in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, 2009. This pattern is for people who have not developed in environments that have stressed the importance of the ability to read source code. Developers often spend much more time reading source code than actually writing it. Often times developers cannot understand the code and have to rewrite it themselves. As stated in the book, Bill Gates once said, “one of the finest tests of programming ability is to hand the programmer about 30 pages of code and see how quickly he can read through it and understand it”. People who can absorb design patterns, algorithms and data structures through real code become great programmers because they are learning from every good programmer each line at a time.

The authors suggest picking an algorithmically sophisticated open source project and take note of the algorithms, data structures, and design decisions made in the code that are new to you. Then, write a blog post for each new idea you learned. While doing this, download the lates version of the project and try to work out why the developers made certain decisions in the design and architecture and try to work out ways you would have done it. Figure out if your way wouldn’t work or would actually be a better solution. This will cause you to think deeper about the reason the project is coded the way it is.

I found this design pattern very interesting because I would agree that the ability to read code is very important and my lack of experience doing so has caused me lots of problems in the past. Often times I have had to rewrite code I was not able to understand or attempt multiple times to understand a piece of source code before finally getting it. I would say that I have improved, but there is still lots of room for improvement in the future. I like the idea of examining open source projects and I think I will do so very soon.

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.

The Deep End – Apprenticeship Pattern

In this post, I will be writing about “The Deep End” apprenticeship pattern from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Adewale Oshineye and Dave Hoover, 2009. This apprenticeship pattern is for software craftsmen who feel that they need more experience and need to be challenged by complex problems and bigger projects. This pattern suggests that these people jump in at the deep end and just go for these challenges.

Waiting until you’re ready for too long can turn into never taking that next step and therefor never moving ahead. Rather than a plateau where you are consolidating your skills, you can end up in a rut where your lack of growth turns into mediocrity. This book suggests when offered a high-profile role, difficult problem, or large project, accept these offers. Even if you don’t feel ready, there is a reason these opportunities are available to you and you should take these opportunities and hold on tight. As the authors stated, “risks are opportunities seen through half shut eyes of fear”. Growth can only happen when you take on scary, challenging jobs. This does not mean lying to get a job you cannot do or not prepared for as you will definitely be in over your head. It means taking the opportunities as they are presented to you.

An action suggested by the authors to help you get started with this pattern is to think about your biggest most challenging projects. Write down the complexities of these projects as a reference for your new projects. Answer questions such as “what is the biggest codebase you have ever built on your own?” and “what is the biggest, most successful project you have ever worked on?” in terms of number of developers and size of the project. Find a certain way to use these questions on all of your past projects to use them as a metric or index and write it down. This will help you gauge where your next projects fall compared to you past ones. Using this chart or diagram will help you figure out which way your career is going and whether you are growing as a developer.

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.

Breakable Toys – Apprenticeship Pattern

The “Breakable Toys” apprenticeship pattern, written by Adewale Oshineye and Dave Hoover in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman, 2009, is about creating projects on your own in order to learn from them. Experience is more often built through failure than success.

Sometimes, in the workplace, it is not acceptable to fail when people are depending on you. This places a pause on your learning. As the book explained, 3-ball jugglers will not be able to step up to juggling 5-balls without trying and failing first. Only the jugglers who keep trying and failing will be able to move up to juggling 5. This is the same with software development and why the authors recommend you make “breakable toys”. This means creating your own projects on your own time that are fun to work on. During the development of these projects you can fail and not hurt or let anyone down. This allows you to grow and improve your skills.

The authors recommend building a wiki as it helps you “record what you learn” (see my other post) and also teaches you a deeper understanding of web development such as HTTP, REST, data migration and concurrency. This is a great way to learn about web environments. It recommends starting small with just an interface, then as your skills improve you can experiment with things such as tagging and ranking algorithms. Another recommendation is to build a new game every time you learn a new language. These are simple games such as tic-tac-to, Tetris, or Snake. This will help solidify your knowledge of the new language. These projects are meant to be low risk to allow room for failure, and also to be fun. If it is not fun, another project will gain your attention and the one you are currently working on is going to gain dust.

The main point of this pattern is to create opportunities to venture outside your boundaries. If you are stuck only doing what you know then you wont learn anything new. When learning something new, often times you will fail. It is the best/only way to really learn.

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.

Apprenticeship Patterns – Share What You Learn

The problem of this pattern is one of the final ones, as far as I can tell. It is framed around your near-completion as a developer. I mean this in the sense that you’re a rounded-out developer with a lot of useful skills, but not necessarily a significant amount of real-world experience. In order to truly become a journeyman, you need effective communication skills. It isn’t enough to be a good programmer.

In order to gain such skills, the proposed way is to share that which you have learned. One such way is via a blog such as the one you’re currently reading. I pretty much completely agree with this pattern. I think the best way to learn things is to explain them to someone else. Really, the reason that we are tasked to write large essays in high school and college, despite them being annoying, is because writing is thinking. If you are capable of reading these words, then you’re most likely literate. Modern people take literacy for granted. For millions of years, the vast majority of humans were illiterate and as such their brains developed in a different manner to ours.

According to a discussion with Psychologist Jordan Peterson (that I unfortunately cannot find to link here), illiterate people think differently than literate people. Illiterate people think more in images and experiences, similar to how animals think. (Don’t let your arrogance get the better of you; all humans are animals biologically.) Words themselves are abstractions and your brain has to handle abstractions differently. It has to convert from symbols and sounds to the word to the meaning of the word. I would say that tribes of people that rely heavily on the oral are similarly affected. Nonetheless, literacy has a profound effect on your brain and thus how you learn. Writing is a form of thinking. Literate people have the ability to write or type words without really planning it in their minds, similar to how people can speak without thinking. The words are the thinking. So, when you explain something, you need to find the words to describe it and that process is thinking.

That’s why written words can be so messy; we think through them as we write. Thoughts are messy. So, it is essential to be an effective communicator not only to benefit others. Ignoring the existence of other people, being an effective communicator means you are an effective thinker. This is specifically in terms of words, which I would argue programming requires. The concepts dealt with in programming require intense mental abstractions that most of us take for granted. There’s a reason the general population thinks coding is magic. It’s simply too abstract to fully grasp from a single viewing. This means words are the way we handle that abstraction. Thus, make yourself powerful with words in order to become powerful in your actions as a programmer.

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.

Apprenticeship Patterns – Practice, Practice, Practice

The focus of this pattern is the simple idea that practice makes perfect. The problem arises from the fact that every time we code, we’re practicing. We try new things, we make mistakes, and we learn. However, when the majority of our code is for work, making all of these mistakes is sub-optimal in numerous ways.

Similar to previous patterns, the proposed solution is to practice outside of work. Do coding exercises for fun and learn from them so when you go to work, you can make fewer mistakes. I would mostly agree with this. My biggest criticism is the same as in a previous pattern; not everyone has the time outside of work to keep working. Depending on the job, it would require a person to live and breathe programming. They would need to use their free time, which is intended to keep the individual sane as well as give their mind a break so they can keep coding the following day. This could have overall worse consequences. For example, I’m capable of coding for virtually eight hours straight and I have on occasion. However, I almost always feel brain dead afterwards. Sometimes, I need a few days off afterwards to be able to think about coding again. As an athlete as well, I can say do not underestimate the importance of rest.

That said, I fundamentally agree with the notion of purposeful practicing. I started teaching myself programming in middle school and it was really slow and hard. The times I learned the most were when I could follow a well-made guide to create something simple. As I developed as a programmer, however, I was more easily able to guide myself through these projects. When I learn a new language, I often create a primality test. It introduces me to io, iteration, efficiency, data types, etc. in a language. Often, I’m unsatisfied with the maximum size of a 64bit integer and I start trying to create a larger integer object that can run efficiently and store large integers. This leads to learning even more skills in a language. However, there are books of prime numbers that go into absurdity. These projects aren’t really meant to have a utility outside of making them. This is what the author means by deliberate practice. I’ve spent years teaching myself different technologies and the most successful ways have always involved some sort of practice project. If nothing else, they make you really good at researching.

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.

Apprenticeship Patterns – Stay in the Trenches

The problem in this pattern is an extremely simple one; you are a programmer at a company and you are offered a promotion that will take you away from programming. The provided solution is basically to just stay in programming despite the opportunity.

I would say I mostly agree with this pattern. This reminds me of Star Trek Beyond (2016) where spoilers, Kirk is offered a promotion to, what I believe is, Admiral which would mean he would no longer fly. After a long adventure, both him and Spock realize that where they belong is on the Enterprise together with the crew. So Kirk turns down the promotion. I think this situation – in a very decent film that most people seem to overlook – is a great match for this design pattern. The motivations are only partly the same, however. In the film, Kirk chooses the Enterprise because he is driven to explore. This design pattern, however, cares primarily about your future career and skills.

There is obviously an implication that the software craftsman enjoys programming, but the main reason they give for turning down the promotion seems to be that you need as much software experience as possible. If your career goal is to be in software, then being in a higher level position at some company you’ll probably leave in a few years doesn’t help you as much as being in programming. There are also potentially alternatives to a promotion that still accrue you the benefits you’ve earned.

Overall, I would say I’m in agreement with this pattern. You need to focus on your long term goals. In this scenario, that is most likely to become a good programmer. That said, its up to you to gauge the opportunity in front of you and determine whether or not it matches your goals. Perhaps the company you are at is a solid position with little fear of losing the job. Then, maybe you should take the promotion and simply keep climbing up. Its okay to change your plan in the face of new opportunities. The key is that you’re thinking rationally and properly about the situation at hand. After all, its your future.

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.

Apprenticeship Patterns – Craft over Art

The problem of this pattern is a very common situation; virtually any time you are building something for a client. You are tasked with producing something that will solve the client’s problem. While you could follow a basic, common method, you also could explore new solutions and build something more custom. The pattern then determines that the solution to this problem is to rely on the tried and tested method. The justification is that your job is to create something functional and you must prioritize that over all else.

I’m not sure how I feel about the proposed solution to this. I would say I overall disagree. Firstly, just because you’re trying something new doesn’t mean its entirely original. There are varying degrees to which you could try something new. So I disagree with the absolutism of the statement. Next, I don’t think that taking the time to create something new is entirely selfish. Just because you could hack together something functional quickly and deliver it to the client doesn’t mean that they won’t have a successful, or even better product from you creating something original. In fact, I think in a sense it shows how much you care for the client. Rather than giving them something cookie cutter, you chose to think specifically about their problem rather than force it to match some other problem. When it comes to coding, that practice might significantly aid performance, for example. Cookie cutter solutions to intensely computational problems can’t be as efficient as specified unique solutions.

Lastly, not all developers have the time to create original content in their free time. If developers spend all of their time copy pasting the same projects, how will the industry as a whole ever advance? So once again, it isn’t just about advancing your own individual skills. I feel there is a disconnect with this pattern. The author seems to be referring specifically to artifying the job, but their descriptions are much more vague than that and can encompass less “negative” practices. When it comes to treating every job like a unique art piece, I’d generally be against that since I don’t think it is a good business model. However, it depends mostly on what the client wants. Perhaps the client wants that level of connection with the craftsman.

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.

Apprenticeship Pattern – Nurture Your Passion

The key focus of this pattern is founded in the all too familiar scenario where you fundamentally enjoy the subject matter you are surrounded by at your work; however, the work itself gets in the way of your passion for the subject. An example of this would be suppose you are really passionate about software design and you enjoy taking your time making a solid product using good code. While that is your passion, and rightfully so, you may find your job is more concerned about functionality and speed. They might prefer you create shoddy code in a quick amount of time that works, rather than doing the job properly. As you might imagine, if your goal was to be employed to create solid code the way you always have, this might hurt your motivation.

The proposed solution to this predicament is to search around at your work and find something that properly interests you. Involve yourself in it and put in as much time towards it as possible. Outside of work, do the same. Find and work on interesting things that satiate your passion. I would continue the prior example to demonstrate how the solution works, except that its a pretty good example for why it doesn’t. I’m sure that in the right situation, the proposed solutions are good options. In situations such as above, however, it isn’t really possible to change what you do at work to better suit your passion. If you already work in software for the company, and the software isn’t up to your standard, where in the company can you go that is up to your standard?

Many companies have a fixed structure. Often, if you attempt to either move yourself around or change the structure itself, it is easier for the company to simply let you go and find someone else. That’s one of many problems that come from jobs being rare and workers being abundant. If jobs had to compete with one another for workers, overall conditions for workers would improve. As a quick aside: in my opinion, if the government weren’t trying its hardest to support major corporations (due to being bought out by them) and got rid of regulation that solely hurts small businesses, maybe in a more free-market economy where almost anyone can start up a company jobs could be abundant and would have to compete for workers. Speaking of idealistic views that might not actually stand up in real life, a second component to the proposed solution is to work on personal projects in your free time.

This is similarly not a valid option for many situations. Often, people simply do not have the time to work a full-time job and fulfill other responsibilities. Bringing up my example once again, you can work on quality software all week long in your free time, but writing code you know is bad and that you know could be better with just a little bit more time will always drain on you. Sometimes and for some people, it can be pretty easy to work on something you don’t enjoy. It can be easy to create something worthless and bad, but it depends on the situation and, more so, the person in particular. I personally find it extremely hard to work on things I don’t care about; even if I just have to do it badly.

It can be hard to have a strong passion for something and then have other people not allow you to do it. It isn’t even a matter of them letting you do it; it would be enough for them to do nothing. But often times, they directly work to oppose what your soul wants you to do. That said, you can’t just vilify them for it. You ended up in a bad situation but in the previous example, for instance, you wouldn’t be stuck. Maybe you misunderstood what they want or maybe they misled you. But if it’s a matter of your soul, so to speak, you can always leave the job. It isn’t always that simple; we have responsibilities and bills to pay. That’s why I personally believe that if you have the opportunity, build up your savings and investments. Sacrifice some of your standard of living now so you can afford to make a change like this in the future. Do your best to prevent yourself from getting trapped in life.

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.

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.