The authors began this chapter with a really thought-provoking story of a Zen master and a young philosopher. In this story, the young philosopher sets out to learn the ways of the Zen master but every time the zen master would begin to describe his own practices the young philosopher would cut him short and start talking about how he does things and how it might relate. Essentially, the Zen master is never able to complete any of his thoughts because the young philosopher keeps interrupting and talking about his own experiences. This goes on for a while until the Zen master goes to pour a glass of tea and he keeps pouring until the the cup is overflowing. at this point, the young philosopher tells the zen master to stop pouring to which the zen master replies, “If you come to me with a cup that is already full, how can you expect me to give you something to drink?”

I think that the short story about the Zen master and the philosopher is extremely relatable to learning how to become a software developer. In the field of programming its’s really important to approach problems with an open mind and to not disregard certain techniques or practices due to the fact that they aren’t familiar to you. By emptying your ‘mental’ cup and being upon to new ideas you will inevitably be much more successful in developing and honing down your programming abilities.

The authors go on to describe the best way to get your software development career started. They suggest that you choose one specific programming language and “become fluent in it.” Some of the things they proposed to get help get you started are using that programming language to build a “toy” application, trying to solve real problems using that language, and reading the language’s specification documentation. The authors recommend using tools like git to publish and/or contribute to open source projects. The benefits of contributing to open source projects include the fact that you can get feedback on your code and advice from experienced professionals that already know the language your learning. Overall, I’d have to say that they present some really good advice on how to get your programming career started and I wish that I had read this when I was starting out as it probably would have saved me a lot of headaches.

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

Unleashing your enthusiasm focuses on bringing enthusiasm to your new team.  It emphasizes approaching your new team with energy and readiness to learn as much as possible.  The book explains that a lot of new developers may be hesitant to appear too enthusiastic, thinking that the team that they are integrating into might not be welcoming to the new injection of enthusiasm into their work place.  Enthusiasm is infectious though and in just a short period your enthusiasm to work and learn will spread to the other team members and the overall work environment will rise.  I agree that this works not only in software development, but in any industry.  During my time in the Army there were plenty of days that were miserable at best.  No matter what the condition was though if you had a positive energy and enthusiasm it made the day a little easier.  When one person showed up with this type of attitude they were quickly berated and rejected by those who were determined to stay miserable.  Soon enough though the positive attitude spread to others and everyone had seemingly found what little good and joy there was to find that day.  Work then seemed easier and the day moved quicker.  No one could tell you any specific time or event that the change occurred.  The tone of the team just kind of changed as the enthusiasm spread.  I think that a high morale and enthusiasm for the job will greatly improve the overall morale and performance of the team.  I found the study from the aircraft carrier interesting.  The idea that new employees mixed with seasoned vets of the industry makes sense, but is often overlooked until it is brought up.  The vets share their experience with the new employees while the new employees are able to share the newer ways of teaching and question the way things have been done in order to change procedures if necessary.  When the employee is in the middle of these two extremes is where changes are made and new procedures and policies replace the old.  It’s important to for all to remember that this process doesn’t work without a mutual respect and open mindedness towards all.

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

The White Belt pattern arises out of an issue I’ve encountered — I’ve learned one language fairly well and have some practice with others that follow similar paradigms, but have found it to be more challenging to learn new things.  Tools, skills, and languages that are different from what I know don’t come as naturally as it seems they should.

This apprenticeship pattern seeks to solve that problem through a mindstate and a more practical approach.  It teaches the mindset of a willingness to feel like a beginner again, to fail and maybe look foolish in order to adopt a childlike ability to absorb knowledge.  More practically, it suggests a learning strategy: adapt a simple, known software project from one language to another, using the paradigms of the new language to their fullest rather than trying to write “Fortran in any language”.

As I said before, I have notice that I struggle more and more to acquire new skills.  Whether that’s environment setup, picking up new languages, or adapting to a different set of tools it seems to get harder as I learn more.  That doesn’t bode well for my mental plasticity, and this pattern provides a useful solution.

The most useful aspect of the pattern, for me, are what the authors calls the mindset of not knowing.  Of willingness to ask questions, start from the beginning (whether that’s following tutorials that feel beneath me, or finding help elsewhere).  Of taking a harder road to learn things right and come up with a better and more nuanced solution rather than patching together something that’s familiar and comforting.  This speaks to something I learned in a high school gym class: we learn and grow the best and most successfully just a bit outside of our comfort zones.  I need to push myself into the “learning zone”.

The action advice is also something that I can take away and use moving forward.  While I don’t have a lot of time now, I am interested in refactoring old projects into new languages as a learning exercise, to blend something that I know well already with something brand-new.

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

I decided to focus on the pattern involving feedback loops this week, because I saw it being referenced in many of the various other patterns throughout the text I browsed. Also, because it seems like to be a good apprentice, having lots of feedback to see what one is doing right or wrong seems like an incredibly important step.

The pattern is called Create Feedback Loops. The idea behind it is incredibly simple, but strong. Make sure to set up mechanisms that will give you concrete feedback on how you are doing. There are many various possibilities, from purely technical such as test-driven development to simply asking others for honest criticism of what you have done.

However, make sure the feedback is examined and the good feedback that can be implemented is taken, not bad advice that can set you back in the disguise of feedback. It is important to have positive feedback that encourages you to keep doing good things, and balancing feedback which discourages bad things.

I have realized the importance of concrete feedback implicitly throughout the years, but having it cemented as the important step it is and being explicitly aware of it, I feel, will make things going forward much easier for me. I have experienced the feeling of being completely lost many times and see how good feedback loops would have prevented many of these instances.

I was nodding my head the entire time reading the section on this pattern. Everything stated made sense and I could relate to. The personal story of Patrick’s situation was something I’ve felt many times in and out of software, where any feedback you get is vague at best and it feels impossible to know where you should head or do. Unfortunately, this was a situation I faced with some courses and professors, where after a discussion or question and answer session, I felt like nothing was clarified or it was even less clarified. These situations sometimes worked and sometimes did not, but I was always left with the sense that I did not learn much.

Going forward, I will attempt to avoid this from happening as much in the future as possible by using the techniques and actions the text suggests.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

The “Unleash Your Enthusiasm” pattern from Chapter 2 of Apprenticeship Patterns was interesting to me, because I hadn’t previously thought about what an apprentice might be able to add to a team. I didn’t even really consider that there were things an apprentice could add to the team, apart from the promise of future skills acquired during their time as an apprentice. But according to this pattern, the enthusiasm of the beginner software developer is a valuable asset, as it sparks the enthusiasm of the more experienced developers on the team. The authors encourage you not to suppress it in an effort to blend into the status quo, and in fact assert that it’s an apprentice’s duty to bring their enthusiasm to the work. Moreover, apprentices are comparatively blank slates who are more likely to suggest creative new ideas that developers with more entrenched habits wouldn’t think of. These should be shared instead of held back out of fear.

I did disagree a little bit with their statements about unwelcoming environments, which seemed to undermine their overall point. The last thing someone who’s unsure about sharing their excitement needs is to have it suggested that they’ll be secretly looked down on for it. Even in groups that don’t seem hospitable to a newcomer’s enthusiasm, there might be more inconspicuous ways of introducing it. Maybe enthusiasm can be shared with individual team members that seem open to it. The group’s status quo could be slowly altered from more private morale boosts, but even if it isn’t, you’ve still shared your excitement with someone. And maybe that’s a bad idea for reasons that aren’t obvious to me yet, but as an apprentice with no preconceptions, it’s my responsibility to share maybe-bad ideas.

After reading about this pattern, I have no doubt that it will come to mind in situations where I feel self-conscious about my enthusiasm and suggestions. I’ll have the ability to recognize now that it’s one of the few commodities I can offer my teammates, and that it won’t last forever, so I ought to use it while I can instead of restraining myself for the sake of pride.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

In this post, I will be covering the “Study The Classics” pattern from chapter six. I chose this pattern because it’s title seemed interesting. This pattern is contained within the chapter that focuses on individuals who are not necessarily motivated by learning for a grade, but those who are motivated by knowledge growth. So, this… Continue reading Apprenticeship Patterns: Study The Classics →

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