When entering the workforce, one aspect that can cause a great deal of frustration is the job title you are given. Many software focused companies will have different titles to differentiate developers of various skill and seniority. Junior developer, developer, senior developer all carry with them an expectation of skill. Depending on which title you are given, it can have an adverse effect on how you view yourself and your skill level.

                ‘Apprenticeship Patterns’ delves into this explaining the common reactions to situations involving being given a seemingly improper title. Those who are given titles such as ‘senior’ or ‘lead’ developer may find themselves frustrated in the fact that they themselves do not feel worthy of such a title. Or on the other side, a person may far surpass their peers in skill and yet be given the same title as them.
Dave Hoover and Adewale Oshineye reflect upon this stating that a title is merely a distraction from the improvement of one’s own skill. Those with a high position of authority should refrain from becoming complacent and those with an unimpressive title must not let fact cloud their judgment.  

The authors explain that the conundrum of titles is a sign that “our industry has a problem” and should be used as a point of judgement for the organization rather than yourself (Hoover, Oshineye pg 51) . Being given a title that seems to be above your skill is often a byproduct of a “shortage of craftsmen in our industry” (Hoover, Oshineye pg51). Being given a title below your skill level can be frustrating but must not distract from your goal as an apprentice. Hoover and Oshineye mention keeping connections with your Mentors (See Last week’s post) and kindred spirits will help keep you grounded in reality.

                I myself have felt at times that my contributions at my old workplace far outpace my current job title. As stated in this pattern, I used this as a measurement of the organization I worked for which clearly did not recognize the skills of those lower in the ladder. Others may feel that their current title implies they are capable of more than they are currently feeling anxious of living up to such a title. All of this comes down to a matter of proper recognition and belonging which is sadly pushed aside in todays fast paced work environments. There is no way to change the industry overnight but having mentors who can reassure you in times such as these goes a long way in ensuring you remain focused on your goals of improvement as an apprentice.

Bibliography

Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Perpetual Learning Pattern: Expand your Bandwidth

This pattern is a very interesting to me. I worked as a software developer from 1980 – 2015. During this time, I found it necessary to take advantage of many resources. Some of these resources were offered to me by the companies I worked for, but more often, it was necessary for me to discover information on my own. I work for over 30 companies. In this 35-year span, I worked as an employee for 15 years, and as a contractor/consultant for the other 20. The employers were usually really generous about paying for tuition reimbursement, computer related conferences, and in-house training. As a contractor, more often I was required to pay for any career advancement benefits myself.

I really didn’t mind this, since they generally paid better, and there is far less politics involved in being a consultant. I was expected to be able to do the work I was hired for, and that usually sufficed.

I was lucky in the sense that I was really motivated to learn new technologies as they came out, and as a result I spend many hours outside of work reading over 100 textbooks, trade journals, attending conferences, and developing my own products.

I managed to gain a large skill-set learning for my own personal development efforts, and this knowledge, along with all I learned “on the job” was parlayed into knowledge, as well as resume entries, making myself more valuable, and allowing my career to “ride the wave” of progress in software as it occurred.

Yes, it is great to expand your skill-set, but if I have any word of caution to those seeking this path, make sure you study a skill as deeply as you can, so as to avoid being a “jack of all trades and a master of none”. I found the best balance to be found in trying to stay with a project for at least a year, but less than 4. In this range, you get deep enough into the peripheral skills they require, as well as sharpening your primary skills.

I worked as a mainframe developer in the 80’s and migrated to being a windows developer by buying my own equipment, teaching myself C and the Windows SDK (with a lot of help from the Boston Computer Society). I made a similar jump in 2008 from C#.NET enterprise level development to becoming an Android developer by jumping at the chance to develop an Android application by my company, but this was only possible because I had already developed the skill-set on my own.

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

In this first apprenticeship pattern, it talks about how a person may have realized they have gaps in their skill set and walks us through ways we can resolve this issue. I decided to do this apprenticeship pattern as my first one because I feel like I relate to this topic. Throughout my undergraduate career, I bounced around from major to major mostly because I am an indecisive person, but also because I am a person who has very diverse interests. I wanted to learn and do everything despite how unrealistic that may all seem. I often took classes out of order so that they would all fit in my schedule. As a result, for some of my classes, I felt like I was always playing catch up because I did not take the previous class that the class was built off or was either taking that class concurrently or at a later date. Because I was taking the classes out of order, I was always trying to learn things that I already should have known before taking the class. This left gaps in my knowledge because I wasn’t always sure that I learned everything that I needed to learn for the class.

One of the topics that the author talks about in this apprenticeship pattern is that often times when a person identifies the fact that they have gaps in their knowledge they don’t know where to start. This was how I felt sometimes when I realized I had a gap in class. In the book, it talks about how everyone learns differently and how we just need to find a way that works best for ourselves. For others it may be going online and reading a lot of articles and working through problems. For me, when I get stuck, I find myself staying late after class or going to my professor’s office hours and working through problems step-by-step with others. One thing that I found really interesting about this section is the topic of finding a balance between trying to hone your skills to confront your ignorance and fulfilling the needs of the team. I found this topic to be interesting because it was something that I never really thought about before. It is important for a person to confront their ignorance and hone their skills because that will make them a better programmer, but it is also just as important that you are mindful of others that you work with because in whilst in the process of honing your skills, you may inadvertently drag your team down. This made me realize this is something I need to think more about and work on in the future.

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.

No matter the area, everyone must start from somewhere. In Apprenticeship Patterns, the author addresses this concern for learning to program in his patten “Your First Language.” Your first language will determine your career direction, and it is essential to make sure your initial language aligns with your desired career path. For instance, an individual who aspires to be a Game developer should learn C++, whereas someone interested in data science should learn python as their first language. For someone who wants to be a software developer, their first language is flexible and can solve as many problems as possible that their work demands. The author also suggests that tests should be used frequently while learning your first language to check your understanding of the language over time.

While reading this pattern, I reflected on how I learned my first language, JavaScript, using NodeJS. I personally related to the pattern’s recommendations. This pattern is beneficial for individuals who have yet to learn a programming language or are still on the fence about which one to dive into deeper. I found it interesting the pattern recommends focusing on learning testing libraries to check your knowledge of the language while you are also learning to program in it.

Doing this would be challenging at first but prove to be beneficial in the long-term because of how necessary testing is in the software world. I have created software in the past while completely excluding testing from the project, and I did this from lack of knowledge of how to test and not understanding the importance of testing long-term. If I had known this pattern earlier, I would have incorporated testing into my process of learning my first language.

I slightly disagree with the pattern’s suggestion that you choose your first language based on whether you have someone in your network who can act as a teacher to guide you with learning that language. I think it would be beneficial in some situations, but if someone cannot network with a person who knows about the language they want to learn, I do not think this should be a limiting factor. There are many online resources and forms that can act as learning opportunities that can stand in place of a single person who can act as a teacher or a guide.

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

This Apprenticeship Pattern deals with a beginner programmer trying to enter the field by learning his first programming language. The pattern suggests various ways the beginner programmer can increase his experience, including but not limited to: learning a programming language from a friend, reading books based on it, and or joining a community around that language.

One of the things I find particularly surprising that is mentioned in this pattern is utilizing “test-driven development techniques”. While I have used testing before as I was learning my first programming language, it may have helped me learn features about the language and development in general that I haven’t yet thought of. For instance, if I create a class and I need to test it, creating test cases allows me to break down a class that I understand and view it from a different perspective.

This pattern has somewhat changed the way I think about my profession. Much of the changes in my thought about my career have to do with an explicit acknowledgement from reading this pattern, especially in relation to things I’ve known but never completely acknowledged. Mastering a programming language really does make the most sense to me, and it is something I’ll recommend when others who want to get into programming ask me.

I do disagree with two parts of this pattern. The first is in relation to which programming language one should choose. This may cause difficulty due to the issue of a complete beginner not having appropriate context to the uses of a language, and thus if left alone he could make a decision that could limit his beginning programming experience, and thereby causing a ripple effect down his career. 

The select part I disagree with follows up from the first. If he decides to learn a programming language based on his friends, this may cause a similar issue. If he decides to learn JavaScript from his friends, which he could eventually master, he could have a hard time contextualizing other features present in other languages. Thus, even though the pattern mentions not to be pushed towards a “one-size-fits all approach”, learning a more general programming language like C++, though fairly dense, can give more context to other languages, from JavaScript to x86 Assembly. 

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.

The pattern I decided to read is titled “Craft over Art” from chapter 3 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. The line that best summarizes this pattern is the one that states how the programs we create can be beautiful, but must be useful. This pattern starts off with a quote by Richard Stallman in “Art and Programming” that defines programming as, “a craft, which is a kind of art, but not a fine art.” This distinction is important because it shows how making beautiful programs is a good thing, but how its beauty should never outweigh the utility of the program that has been created. This pattern ends by giving us two tasks. The first task asks us to find something to do where we can prioritize usefulness over beauty. The second task is a reflective one that has us think about times we have chosen artistry over utility in our craft.

One of the sentences that I found interesting was the one that described how “utility and beauty are not opposed to each other, but interdependent.” This sentence stood out to me because although there is no denying that programs must be useful, it reminded me that I can not completely neglect the aesthetics of my program either because it goes hand in hand with how it is used practically.

As far as how this pattern has caused me to change the way I think, I would say that this pattern has made me be more mindful about the kinds of choices we make in our capstone project. We have already had a couple of conversations around this topic and I’m happy to say that our team has erred on the side of practicality over aesthetics. One of the things we have said in our team is that we should focus on setting the foundation of our project, and if we have enough time, we can come back and worry about our application’s appearance some more.

Overall, there isn’t anything that stands out that I strongly disagree with. It was a reassuring chapter to read after reflecting on some of the decisions my capstone team has already made on this topic. Additionally, it is a great message to instill early on in my programming career.

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

This week, I decided to look at the next apprenticeship pattern in chapter 2, “The White Belt.” This pattern describes the dilemma of a programmer being confident in their skills of a language but has reached a plateau in their personal development. This pattern offers a solution to those who feel that they are not acquiring new skills fast enough. After reading through the previous pattern, I’ve gathered that it is important to keep learning and honing your skills. And this pattern directly addresses an issue that one would encounter when doing so.

The solution provided in this section is to put aside your current knowledge when approached with new knowledge. While this will potentially affect productivity in the short term, it will allow time for new knowledge to sink in. In the pattern, it states, “wearing the white belt is based on the realization that while the black belt knows the way, the white belt has no choice but to learn the way.” This can be applied to learning anything because it can be beneficial to approach something new with the mindset of a beginner. The example with Dave the therapist was an example of when the mindset could apply outside of learning code. Dave found that taking a “not knowing” stance when working with clients opened up a new door of unforeseen possibilities and solutions. He put aside his expert knowledge on the subject and approached clients with curiosity.

Another example that I would like to refer to is that of the 10-year industry veteran Steve. He mentions that after reading “Working Effectively with Legacy Code,” his codebase improved into a better tested, adaptable system that was more fun to work with. While Steve did not go into detail, it was interesting to know how much more a 10-year veteran could grow. I certainly don’t have that many years of experience, but when learning new things, we are all starting at this hypothetical white belt. For the most part, the languages I have learned thus far are all based on similar logic. It would be beneficial for me to take one of my existing programs and implement it in a vastly different language. Not only would it give me a chance to learn a new language and the idioms, but it could also improve my coding skills in general, as mentioned by the 10-year veteran Steve.

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