Immediately following the White Belt pattern in Apprenticeship Patterns is the pattern of Unleashing Your Enthusiasm. As the name states, the idea of this pattern is for a developer to forgo the inhibition of his/her enthusiastic tendencies for fear of his/her own inexperience reflecting poorly on him/her within the group. Put more simply: new and inexperienced developers often bring a much-needed drive and passion to a team, which proves to be a vital element of the team’s success. Moreover, the very nature of high enthusiasm contributes greatly to the developer’s personal learning of the technologies at hand. Hoover and Oshineye point out that during this introductory period, there is a rare opportunity to provide a fresh perspective, which allows one to offer useful suggestions for improvement that may otherwise go overlooked.

One of the first relations I could think of to myself was my Fall 2017 semester, when I was taking Robotics. Our group was a 3-person team where each person had a solid foundation in one area, and inexperience in many of the others. We stagnated for about two weeks after receiving the final project – which was tremendously flexible in what we were allowed to construct – because there was a pervasive discomfort felt among each of us when it came to making a decision of what to actually build. When we ultimately agreed on something, and the fear of asking silly questions dissipated, we became staggeringly productive. In many ways, our enthusiasm for the project was the only reason it got done; most notably the final three days before our presentation, where we had to scrap and redesign the entire machine. If it weren’t for the excitement we felt every time we learned something new about the code we were writing, or thought up a more efficient way to construct the robot, we may not have been able to finish in time.

Overall, I can agree with the message of the Unleash Your Enthusiasm pattern. Even sitting here now, I can recall times where my excitement over a project or idea has been contagious, and I can see how that would be a powerful tool on a development team. After all, one tends to put out much higher quality when working voluntarily rather than compulsorily. Going forward, I will be making a greater effort to present my ideas, questions and concerns to people of greater experience, and hope to make strides in my learning through their responses as a result.

From the blog CS@Worcester – Studio H by Connor V. and used with permission of the author. All other rights reserved by the author.

The White Belt Pattern is a simple concept: the idea is that one who seeks to learn must take on the attitude of a beginner. It is the frame of mind that “while the black belt knows the way, the white belt has no choice but to learn the way.” The pattern dictates that one maintains a stance of unknowing, and actively seeks opportunities to “unlearn” the things that he/she is already familiar with. E.g., if you were to write a program in Java, a white belt pattern course of action might be to redo that program in a functional programming language rather than an object-oriented one.

This pattern struck me on multiple levels. I am a martial artist; I have been training since I was very young, and am quite familiar with the notion of emptying one’s cup. However, though I’ve been used to doing it with martial arts for years, it occurs to me that I have a very hard time doing it with programming. I had this problem when moving from a Kenpo school to a Tae Kwon Do school; I would keep trying to do things the way I’d been taught by my Kenpo instructor, in spite of the fact that I’d set out to learn a new style. I wonder if I’m doing the same thing with code.

There have been times when, in my process of learning a new language, I’ve made statements to the effect of “Oh, X language allows you to implement this in a much more efficient way,” or “This type of code would be much more readable in X language.” This, I think, gets to the crux of the issue that White Belt Pattern seeks to address: Excessive comfort in one language, development environment or paradigm can have the unfortunate effect of shrinking a developer’s capacity for pragmatism with less familiar technologies. Comparing two technologies’ level of practicality without giving oneself the proper time to work with and understand each of them is intellectually dishonest, and can avert someone’s eyes from potential advantages of one or both technologies. Going forward, I will be certain to keep these principles in mind as I seek to understand new technologies, both over the course of the semester and in my professional career.

From the blog CS@Worcester – Studio H by Connor V. and used with permission of the author. All other rights reserved by the author.

The introductory chapter to Dave Hoover and Adewale Oshineye’s Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman is a set of definitions for the focal topics of the book – the apprentice, the journeyman, the master and apprenticeship itself. Perhaps more importantly, and certainly of greater impact in my mind, is the brief discussion regarding some of the primary goals that an apprentice ought to have. The role of the apprentice as strictly a learner was one that came as obvious, but I think what made the read novel for me was the methodology suggested. Specifically, Hoover recalls the pivotal moments of his learning, and a majority of them involve having lacking work examined by more experienced developers, having it improved by working with those developers, and taking lessons away from those experiences.

I actually reread Dave’s recollection several times to reprocess it, and I was alarmed at how much it made me think about myself and how I began and, of course, where I ought to be taking myself through the start of my software development career. The shock Dave describes of going from your first language – which you’ve spent ample amounts of time attaining proficiency in – to one that behaves or looks very differently is something I’m familiar with. I count myself very fortunate to have had the weak exposure to programming that I did (Game Maker Language in freshman year of high school, if you were curious), because looking back on it, the task of learning even Java after that first language was especially difficult. I have in fact wondered about this idea over my time in University; I’ve thought for the past couple of years about whether or not we are mistaken to only mandate exposure to Object-Oriented Programming in our classroom. From what I understand, the CS program is beginning to walk students into other paradigms here and there. However, I cannot help but ponder whether my fellow students are able to program in any other paradigm – I know I certainly have a hard enough time with it, and I’ve made a point to try and work out Haskell.

I digress. Where I was intending to go with this was: I recognize and can identify the situations Dave describes in myself and in my own experiences. I find the idea of putting out work with the intent of having it get picked apart to be profound and daunting, but sensible. And, the more I consider it, the more I think that it would be an intellectual dishonesty to do otherwise.

Admittedly, I payed far less attention to the definitions and dissections of the journeyman and master. For the moment, I’m still trying to get myself into the mindset that I think I ought to be now: I want to begin displaying my work for the world to see and have it critiqued. I want to hear of my shortcomings and inefficiencies, then use the ideas of people smarter than I am to turn myself into a peer on equal footing with those people. It is, I should think, rewarding in multiple ways to develop a humble frame of mind that can receive criticism and can be incorrect without feeling some level of inadequacy. Often one’s greatest inhibitor to success is oneself, and I can only imagine that this applies to me just as much as to any other person. Therefore, I should not assume that I can break these barriers on my own; it will take the guidance and wisdom of those who have already attained such success. And so begins the story of the apprentice.

From the blog CS@Worcester – Studio H by Connor V. and used with permission of the author. All other rights reserved by the author.