This week I decided to take a look at ‘The Deep End’ pattern, which covers the next step on your knowledge gaining journey. The main message of this pattern is to not be afraid and take that next big leap, whatever it may be. The pattern certainly doesn’t suggest taking a risk that jeopardizes your career, but rather taking on new challenges. Software apprentices can apply this pattern to scenarios such as taking on bigger projects, more complex tasks, working with larger teams, or in new places. While these opportunities may seem daunting, learning is all about stepping out of your comfort zone, even if it means failing at times. 

I am surprised that the pattern suggests diving straight into the deep end as opposed to starting shallow and gradually growing deeper. But I suppose if you were doing the same type of work day in and day out, your biggest break would come from a new challenge. Looking forward, when such an opportunity arises, I think the best way to face a new challenge would be to go into it prepared. This is certainly easier said than done. There is of course the mental hurdle of overcoming the fear of failure and the risk of actual failure. But again, as mentioned in this and previous patterns, you should be able to reach out to mentors and kindred spirits to help. I think that is one thing I should keep trying to recognize, that I should not be afraid to take on difficult projects if I know there is a network of people that can help guide me. 

This pattern is a good reminder to step outside of your comfort zone and it reassures you that it is okay to take risks in your professional career. Given that you have the preparation and a supportive work environment, taking on challenges will only help you gain more experience. I would think that currently, I am in the middle of one of these challenges. Up until now, I have only worked on smaller-scale projects with at most two other people. And for this capstone course, I am working with a team of 6, attempting to develop a fully functional inventory system from backend to frontend. So through this process, I have only been gaining experience and I look forward to what else I can learn.

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

This apprenticeship pattern discusses how software developers should read classic books regarding the craft of software development. Being an apprentice means that you are inexperienced and are still learning what means to be a successful software developer. You should expose your ignorance and ask about any concepts that seem unknown to you, and then try to find the books where these concepts came from. An apprentice should have a list of these books on their reading list.

However, you cannot read every book. There is just way too many and there is too little time. So instead of reading every book, you should invest your time reading the good books. The good books are ones that are useful regardless of time. If you find yourself asking if a book is outdated, then you are reading the wrong type of book. Good books hold timeless information and concepts. Being able to determine which book is good and which book is not a skill that you will be able to pick over time. By reading constantly and reflecting on your work, you will be able to distinguish the “long lived” books.

While reading the good books is certainly beneficial, there is such a thing as taking things too far. If you focus too much on the classics, you might end up abandoning or forgetting pragmatic knowledge and information. This is the knowledge and information that enables software developers to improve on their day to day craftsmanship. Therefore, it is important to strike a balance in your reading list between the classic “long lived” books with modern, pragmatic books.

I personally think reading the classics is one of the most important things that an apprentice can do. An apprentice’s job is to learn as many skills, techniques, and concepts as they can about their trade. As apprentices, our inexperience and ignorance means that we still lack core concepts and skills. Reading classic books could help us attain such concepts and skills. It is from these classic books that we can expand our list of concrete skills and build a foundation for our craft.

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

For this week’s post, I wanted to look at a topic that I see myself coming back to at a later date, which is the topic of walking away from software development. This may happen after their first job or 50 years down the line when they are a senior programmer. Regardless, the point is this can happen at any time during a person’s career. In this section, the author talks about some of the reasons why a person may suddenly have a change of heart about the field. Some of the reasons listed were that person may have found something else that had piqued their interest, or they found they did not enjoy the field as much as they initially thought. Another aspect that I noticed about this section was that the author really emphasized the importance of being open-minded and supportive of their colleagues. A person may leave the field now, but that does not mean they will be gone forever. In addition, the author also talks about how companies might not look at that person kindly because they left the field and may not be as forthcoming as they should be when/if that person returns. But as fellow programmers, the author implores us to welcome that person back with open arms and encourage them to try to do something different with their lives.

I found this section to be interesting to read because I have always viewed myself as a jack-of-all trades. I have always had many interests and that is why I took so many different classes not pertaining to my major in college. I wanted to explore as much as I could before I graduated because I have always thought of myself as the kind of people who would have many different careers over the course of my lifetime. This section really made me think because I knew I wanted to change careers at some point, but I did not put a lot of thought about what I wanted to do after I changed careers or what career I wanted to pursue after being a software developer. I think part of the reason why I did not give this topic a lot of thought is because I don’t really know when I might want to change careers or when I might get tired of programming.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

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.