The pattern I decided to read is titled “Familiar Tools” from chapter 6 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. The problem that this pattern presents asks the reader how they plan on completing a work project if there are so many new things to learn with each project (from the technical to non-technical aspects). The solution to this problem starts by informing the reader that they should have a reliable set of familiar tools to use for each project they start. However, the reading goes on to explain that readers should be weary about how they use these tools and how dependent they are on these tools. A larger message stresses the importance of how in the process of becoming a journeyman, we may need to painfully abandon some tools and learn new, better, more effective tools in their place. The text ends by encouraging readers to either build a toolbox they can bring to a project, or if they already have a toolbox, examine potential replacement tools.

Reading this pattern was surprisingly encouraging. I don’t think that was an intention of this reading but the reason it had this effect on me was because as someone who is in the beginning of their journey in software development, it can feel pretty intimidating to just be starting out when there are people who have been working in this field for years. And yet, that person and I may be in the process of learning some of the same things today. While the other person is likely to have much more experience in using tools than I am, it is comforting to know there are things we will be learning at the same time.

This pattern has changed the way I think about my work because it has gotten my wheels turning as to what five tools I would like to have in my toolbox and what tools I think I need to continue exploring.

Lastly, there isn’t anything significant in this pattern that I disagree with. This is another pattern I enjoyed reading.

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

Breakable toys is an apprenticeship pattern similar in spirit to Be the Worst. They both encourage us to improve by failing in one sense or another. While the Be the Worst apprenticeship pattern focuses on joining a team where you are the worst in order to learn from others on your team, Breakable Toys emphasizes working in an environment where failure is not only possible but even encouraged. Such an environment usually means working on your own projects where any mistakes you make have little to no consequences and allow you to learn from them.

Overall I think that this pattern makes sense, and is a good way to improve ones skills as a developer. I whole heatedly agree with the idea that failure is integral to improving in anything, and especially when applied to programming. I know that whenever I make a mistake I tend to remember that mistake and in most cases I am able to learn from it and improve myself. When writing code for class projects or assignments I frequently screw up certain feature implementations and as a result I learn of a better way to do what I failed to do. Be it through personal research after the fact or direct guidance from someone more experienced than I.

Personally I haven’t really created an environment for myself where I can comfortably fail. While I definitely learn a lot from mistakes I make at school, I wouldn’t go as far as to call that a safe place to fail frequently. Ive had a few personal projects in the past, but I never really thought of them as more than things to slap on a resume or to pass the time. Having read this apprenticeship pattern however, I definitely have a different outlook on those past projects, and will also have a different outlook on future ones. I will likely try to work on projects that heavily involve tech stacks I am not familiar with in order to attempt to learn from my failures working with them. It will be difficult at times as I can be impatient, and the slow initial progress with some of these projects might be discouraging, as well as any screw ups that might come along. But since I will be more aware of the fact that these setbacks are actually helping me in the long run I hope it will help me keep pushing forward.

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.

Summary:

This apprenticeship pattern is concerned with a new developer’s entrance in a team that is both more experienced, and relatively unenthusiastic in comparison. As a newcomer, the new developer has much to learn from the industry and from his colleagues. But with every new iteration begins a chance at change. Depending on the team, enthusiasm can benefit a team that does not have low morale, and is accepting of new perspectives.

I view this apprenticeship pattern as particularly intriguing because I am genuinely enthusiastic about working on a team with other software developers. Someone who is inexperienced in a field may focus and develop skills in things that his future peers will not require. As such, it may offer a perspective that his peers do not have, such as various coding “tricks” or knowledge that may be used as a reference. For example, a new programmer may have to program an algorithm from scratch in school, which can give him ideas about a data structure that a team may either require, or benefit from. In the field, programming a data structure isn’t as important since the language would likely offer it. 

This pattern didn’t so much cause me to change my ways of thinking as it did bolster my perspective of the field. In my experience, it is natural for someone who is good at something in a field to gradually become uninterested in said field because of a sort of coexistence. There is some mental functionality or process in every person that occurs when someone becomes used to something, such as an environment or a smell, which causes him to become somewhat apathetic. In this case, a developer that is used to the field runs a genuine risk of being used to it, and therefore, not excited from it. I personally view unenthusiasm is a strong indication of decline, and any person who becomes unenthusiastic will, all else being equal, perform poorer than his peers.

I don’t disagree with anything in this pattern. As stated earlier, I strongly agree with the role that enthusiasm plays in relation with other team members, and its potential productive results that can benefit a team.

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

As a developer, I have always thought that “being a small fish in a big pond” rather than “a big fish in a small pond” was a great advantage for career advancement, both as a way to advance your knowledge, skills, salary, and position. I learned an incredible amount from other developers at EMC, Nuance, and Kodak, because these companies had teams where many of the engineers were brilliant and knowledgeable yet had no problem meeting with me to share information, and help with difficult design and debugging challenges. Although I usually obtained more from these teammates that I taught them, enough situations came up when I was helpful to them that they were happy to help me when I needed them.

I usually took the approach of only “bothering” them when I was really stuck on an issue. This had the benefit of making me fully understand the problem, and therefore taking less of their time. Before I would ask for a meeting on such an issue, I would take notes on what the problem was, and then write down a list of questions to ask. I found that some of the time, when I did this, I was able to get the answer on my own. Another interesting phenomenon would occur quite often. I would actually be able to come up with the answer to the problem on my own as I was going through the issue with them. I would then get a response like “See Joe, you already knew the answer. You just didn’t know you did”.

The whole concept of “sink or swim” is quite interesting. When working in a challenging environment, I was always more motivated to learn the skills necessary to produce solid code than when I was one of the more advanced team members. Since most of my career was as a consultant/contractor, sinking at a company was less problematic than when I was working as a corporate employee. The expectations of working as a consultant were usually higher. You were treated less as a team member by some also.

I found, though that I really liked both worlds. About a third of my career, I worked as an employee, and enjoyed the benefits of “being part of the team”, getting paid vacations, going to conferences for free, and the obvious sense of security. The other two thirds of my years in software either contracting as a 1099 or W2, or when I hung my own shield with my corporation “Twinstar Enterprises Inc”.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

For my next post, I wanted to write about a problem later in chapter 3 titled Draw Your Own Map, which was referenced in the first problem of the chapter, The Long Road. This problem is about when you do not fit career paths given to you by an employer, and this problem could be applied to any possible employer. It can be a concern that your skillset may not match what your current or potential employer is asking for and you will either have trouble with the work, or have to move on to a different job. This problem stuck out to me because it is also a concern that I have for when I go into the workforce, that I may not be fit for some jobs that I thought I was. I feel comfortable with most of what I have worked on in computer science and think that I can handle it at an official job, but there are some things I am unsure about, or new things that I may have trouble with.

Going into the solution and action, I like the idea of making a roadmap for jobs that start with jobs that you’re first looking at, then jotting down branching jobs that can stem from it, and repeating a few more times until you want to stop and look at the jobs and how to get to that point. Considering other possibilities and keeping in mind that this is your path to choose will also be helpful. I also like the idea of starting with small steps in your planning and working your way to the bigger goals.

The constant idea to focus on this being your path is especially effective for this problem because the main thing to keep in mind is that this is your skillset and it not fitting some jobs is not a bad thing. I also agree that while you can get help or tips from others on how to decide on your path, it is your path to take and your future to decide on. It will also take time to make your map, and it is expected to be changed and updated over time as you continue on your journey.

From the blog Jeffery Neal's Blog by jneal44 and used with permission of the author. All other rights reserved by the author.

Christian Shadis

In the apprenticeship pattern Be the Worst, Hoover and Oshineye explore the dynamics of skill level on a team as a software apprentice. They assert that while it may seem counterintuitive, it is a better plan to not be the strongest developer on a team, for that situation yields less opportunity for growth and learning. However, if you are surrounded by accomplished developers who are more skilled, there is far more to learn from them, and far greater space to grow.

Be the Worst, like The White Belt, seems to go against the average worker’s intuition, and are somewhat related to each other. One might think that being the ‘big fish in a little pond’ is a surefire way to distinguish yourself from your colleagues and get promoted, or maybe compete for more prestigious jobs. However, being that big fish increases your chances of stagnation. If you are already at the top, there is nowhere to go, and you may find yourself plateauing as a developer. It is more beneficial to contribute to a big pond and be a little fish, because the little fish can learn and grow more, and eventually start to grow larger than the fish around it, and eventually may become the biggest fish. Combining this pattern with The White Belt by accepting new methods and techniques unfamiliar to you will maximize learning potential at any position.

This pattern is likely to be rather difficult to me, having gone to a small high school and university, and finding myself as one of the “big fish” in both. It would be very unnatural for me to be the worst member of a team, but it would catalyze the learning process and motivate me to become a better teammate (or even the best). In turn, that growth and learning will open opportunities for more interesting and lucrative positions in the future.

I hope to use this pattern throughout my career, but more specifically I plan to implement this pattern at my first development job. I plan to work at a large tech company, and that company likely would hire largely candidates from more prestigious computer science backgrounds, with more dense portfolios and extensive experience. I could perceive this as a disadvantage in the job market but utilizing this apprenticeship pattern instead would motivate me to improve my contributions and prove myself as a competent and evolving developer.

Reference:

Hoover, D. H., & Oshineye, A. (2010). Accurate Self-Assessment. In Apprenticeship patterns: Guidance for the aspiring software craftsman. O’Reilly.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

Sometimes being the worst is not the worst thing to be recognized as. It can be a scalable thing. In sports for example, being the worst player on the Boston Celtics may seem like a bad position to be in. The reality is that your skills are far more impressive in comparison to the average person who watches basketball, and you should give yourself more credit for even making it into the league. The “Be the Worst” pattern is one that allows those who exercise it to never remain stagnant. While it is nice to admire yourself for all the progress you have made along your journey, you should not bask in these accomplishments for long periods of time.

There have been many times in my life where I’ve felt like I’ve done all that I needed to do and “now I can just chill”. That same attitude has also gotten me in a few binds during my academic career. These things occurred because I felt like I was doing my best at something and would always be the best even if I didn’t continue maintain a certain level of excellence. It seems like the view here is that being the worst is the best and being the best is the worst. In other words, you have nothing to lose if you’re the worst and have nothing but the potential to grow, but if you’re the best then you must maintain being the best and potentially face having to fall from grace.

While I understand the message this pattern was trying to get across, I feel the messaging could possibly be misleading. The author mentions being the worst person in your team that produces good work can “make you feel as if you are performing better” when you could not be performing at all. While I feel like this pattern is helpful for myself, the advice given here should be taken with a grain of salt. To me, the most important part about being the worst is making sure you have the will to become the best and repeat the process.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.