For this week’s blog post, I decided to write about this section of the textbook because I feel like this is an issue, I can see myself having when I get into the field. If I were to summarize this section in two statements, it would be “don’t let success go to your head”, and “never let someone take you away from something you love”. In this section, the author talks about what we should or should not do when we get a promotion. The author cautions us to be careful and warns us against blindly accepting a promotion because while in our new position we may never have to code, and if we do not practice on our own time, it can be easy to let our coding skill become dull. In addition, the more we move away from programming, the more we become disinterested in programming. This relates to a previous section in the book about nurturing our passion. If we don’t continually nurture our passion, we may lose that passion. As an alternative to the promotion, the author recommends that we work with our employers to find other ways to reward our hard work such as a pay increase or role change so that we can continue coding.

First and foremost, I agree with most of what was said in this section. Where I see myself having an issue later on in life is I feel like I am the type of person who when they receive a promotion will blindly accept the promotion and not think too much about the implications or effects until it is too late. In which case, I can also see myself having the problem of not being motivated enough to continue practicing programming during my own time and let my skills dull. So, reading this section made me realize that I probably will want to find some way to keep motivated before I go out there and get a job in the field. I am not sure what it will be or what it may look like just yet, but I have time.

After reading this section, I also thought it was really interesting because throughout this section, it seems like the author was making an emotional appeal to our sense of pleasure and focuses on the idea that a lot of people that go into this field go into it because they enjoy the work. That is why I am going into it but that may not be the case for everyone.

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.

Draw your own map is a very interesting pattern. And a pattern that feels relevant to my journey. Draw your own map means that a software apprentice may need to leave his current job, if that employer is not providing the right path. What I like about this pattern is that it forces the apprentice to consider, and write down that path that is best for him. Instead of what his current employer wants.

This pattern feels relevant to me as I am graduating and starting my career in tech. I have worked at a company for a few years, in a mostly non programming role. But I have done some coding work part time. Upon my graduation in the spring, I was offered the oppurtunity to stay at my company, and join the automation department. Where I would be developing software. I was very happy to be offered the role, but I had to draw my own map. I knew that I would be able to grow as an apprentice more effectively at a bigger company, with more resources to train me. So I made the decision to move on.

There are many career paths in tech these days, as there are more oppurtunities that there has ever been. Some people stay in development for their entire career, and many switch to management roles. I don’t think that changing to technical management is a bad thing. But I do agree that each apprentice should draw his own path. Because it can be easy to just follow the road that your employer lays out. But it is much more rewarding and fufilling for an apprentice to draw his own path.

There will be more times in my career where I will change paths. I could change the industry I work in, or the tech stack I use. But the idea behind the pattern is that I should make these decisions for myself. As a developer, I am fortunate to have many possible paths, so it is very important that I consider which path will be the most rewarding to me.

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

The White Belt is a pattern all about expanding your horizons. When learning how to develop software, it is easy to be overly confidant in how experienced you have become. It is easy to become competent at one area of expertise, but that experience should not be translated to other areas. Other areas of expertise have different skills and methods which work best for them, and that may not align with what you already know. You should always take an unexperienced approach when learning new skills, since your previous experiences might interfere with how effectively you learn.

I can personally relate to this one a lot when working on the capstone project. Despite my Java knowledge, I barely knew how to use Docker, API calls, and have never used JavaScript before. Trying to learn JavaScript is difficult since I keep trying to impose my Java habits upon JavaScript. Java and JavaScript are both very similar, but are not the same language.

I like this pattern because it makes you reevaluate your level of expertise. With software development there is so much to learn, and as an apprentice you will never know how little you know. I hope to keep this with me throughout my entire apprenticeship. It is too easy to become comfortable and confidant with your abilities, and I plan to always learn new skills throughout my career.

In my experience, it is scary to learn new things. Once you get comfortable working one way, working any other way is difficulty and confusing. Trying to learn something new is always more difficult than doing what you’re already doing, and staying with what you’re already doing is too easy to do. This is why it is so important to try and learn with an open mind, since trying to force one mindset into another application is not going to work.

Overall I think this is a good pattern but not the most important pattern. It is certainly important, but when working in such a drastically different environment you will almost be forced to work differently. It is definitely important to keep a beginner approach when learning new skills, but I feel as though in most cases it will come naturally. When you are working in a very similar environment, however; it is very important to remember that you are in fact working in a different environment and should work differently as a result.

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

The Deep End

As the title describes the deep end is like the deep end of the pool when you are first learning to swim. While of course you need to learn the basics before you reach the deep end, the question then becomes do you make that jump when you have the necessary skills?

The answer is yes of course, and like the deep end of the pool as a young child it can be scary sometimes. I remember when I was younger and had learned how to swim in the deep end as well. I came to another kind of deep end at a local beach by a pond. Just swimming out into the deep wasn’t enough there was a fairly high tower that you could only jump off of if you could swim in the deep end. The only way to advance further was to take that leap. I unfortunately hit my arm on the way down and had it gotten stuck it definitely would have been broken. Luckily I made it just fine with a scrape, but the fear of taking the jump again was gone. I had made a mistake that I wouldn’t make again.

This particular pattern is one that I should really utilize, often you can get to a point where you may not really know where to go next or what even to do when you jump. Placing yourself into a situation that is more difficult than you have been before is critical for improvement and certainly applies to software development. With software development though you can know what you are likely going to face when taking on a new project to grow and adapt yourself. With any problem there is the general assumption to be made about what the solution is. The real challenge is in how you’ll solve it when you arrive at problems that present themselves while you have no solution.

I don’t find myself disagreeing with anything in particular about this pattern, unlike the previous one. It summarizes a problem and gives a solution that is a common theme in life. Sometimes to improve you need to take on a bigger task or place yourself in competition against those who you know are far better than you.

As for applying it towards my career as a software developer, there really is only one thing to do. Find a deep end and go for a swim. Worst case scenario is I’ll not achieve my task, which is only another opportunity to try it again.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

In many crafts, an apprentice’s main goal is to gain the experience and knowledge necessary to succeed in the craft of their choosing. Whether it is art or programming, an apprentice goes through the process of learning not only what techniques exist in their craft, but also how to acquire the techniques they learnt to achieve their goals. Though I personally cannot speak about art due to having no prior experience, I can say that in the field of programming I am aware that I will often be tasked to work on creating solutions for people. What I am also aware of is that we may almost never be on the same page regarding what customers want and what I may think is best for them. Though I personally may want to give a customer a product of code that balances functionality and aesthetics, it is this focus that may hinder the development process rather than help it. This situation is an apprenticeship pattern referred to, aptly, as “Craft over Art”.

A craftsman may encounter this patterns when they are put in a situation in which they are tasked with creating a working solution for a customer, though they may use this opportunity to show off their knowledge of the craft rather than applying the appropriate skills in order to create something viable and useful. In the case of a software developer, the craftsman may choose to put more emphasis on aesthetics by implementing functionality that may look fancy rather than using the proper functionality and techniques in order to deliver a working product that meets the customer’s specifications. Some developers may fall into this pitfall because, they believe, that the quality of the product is best shown only through how “fancy” the implementation looks and not through how the final product itself performs. This pitfall may be especially evident in software development, where the product itself may have to be maintained by other developers in the long run but may struggle with by virtue of how the original developer approached the implementation in the first place.

Though I personally may want to show off my skills by making programs in a creative way or to refine an existing piece of code by implementing fancier algorithms or optimizations, I understand that there is a time and place for that, oftentimes away from the professional environment. In fact, I strongly believe that having useful code to work with as soon as possible is far more important than having code that looks fancy and intricate that fails to deliver on its specifications.

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

This apprenticeship pattern urges apprentices who are going to be entering the workforce to take on the tasks that nobody else wants to do. The tasks on the edges of the project, like documentation or code refactoring. It explains that this is a good way to help out the team without much experience, to ingratiate yourself with your teammates, and show everyone that you are capable and a useful member of the team. It will also help you gain some humility, by doing the tasks nobody else wants to do and learning the importance of these tasks.

I think that the real strength of this pattern is in laying down expectations for apprentices about to start, or just starting their time on a real team in the real world. We have to humble ourselves and realize that when we first start at a project, we are new and we haven’t earned our chops, or shown anyone what we can really do. By choosing to take on the menial tasks that everyone else has pushed aside, we are choosing to show everyone that we are willing to get our hands dirty, dive into a new project, and prove that we can be valuable besides just as a workhorse on these tasks. Showing the team that you are ready and willing to contribute to the project in whatever way you can shows that you aren’t someone to shy away from a challenge. The pattern also warns about the pitfalls of this though, and they are good things to keep in mind so you don’t get stuck doing menial work forever. I had kind of planned on this since the beginning, I think it is vitally important to show people that you are willing to do what needs to be done, and this pattern has reinforced the need to be ready for that and reminded me that while I am willing to do it, I also need to advocate for myself and make sure that I am getting what I want as an apprentice: the opportunity to learn, and to work on something bigger.

I don’t really disagree with anything from this pattern. I honestly think that it is all just good advice, it is important to be able to earn your place as a valuable team member, and it is equally important to remember that you are valuable, and to use it as a learning experience, and as a way to show your skill. It is a valuable part of being new to a project and is a great way that we can gain experience outside the classroom, and apply what we have learned to something real and tangible.

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

The pattern I decided to read is titled “Record What You Learn” from chapter 5 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern starts out by giving context of a situation I know I have found myself in multiple times. This situation is one where I am relearning the same technical lessons over and over again. The proposed solution to this problem is to keep a chronological record of the lessons I’ve learned. This record can be made in the format of a blog or wiki, to name a few options. Additionally, these kinds of records can be made public or private. Public records are good for building connections since others can read them and private records are good for being painfully honest with yourself about your progress. The last section of the solution ends on discussing how your record keeping tool can be an example of a Breakable Toy and how this Breakable Toy can help you extract lessons from it as one grows from a novice to a more experienced developer. The actionable item this excerpt ends with is encouraging its readers to start immediately because these entries can become the basis for books, magazines, and blog posts in the future.

In response to the question, “Will this pattern cause you to change the way you will work?”, my answer is a resounding yes. I’ve read this pattern multiple times before writing this blog post and have slowly been successfully developing my own personal journal/“Breakable toy”. I think one of the reasons why this has been so effective for me has to do with the following line I found interesting while reading this pattern, “The private record allows you to be painfully honest with yourself about the progress you are making”. In my journal, I get to reflect on how well I truly know certain technologies and what I still want to learn. And whenever I learn something new, I write about it in a way that is meaningful to me (as opposed to doing work for a class deadline). Therefore, I completely agree with the information in this pattern. It has been a super beneficial process for me so far and it is rewarding to physically see the evidence of what I’ve been learning in one localized place. I’m happy that if I have taken anything from this book, it is a journal/“Breakable Toy” I can continue using in my career and life.

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

Christian Shadis

In the apprenticeship pattern Stay in the Trenches, Hoover and Oshineye explore the importance of maintaining a development position in the face of success and the opportunity to progress into management. This is a very important topic, since many developers (and employees of other types too) have their careers reach stagnation once they make the leap into management due to their misconceptions about career progression.

This pattern is counterintuitive to me, as historically I have considered management positions to be the goal of any employee, and the thought of turning down a promotion would not seem to propel a career forward. Upon further reflection, the benefits of the pattern are more apparent. If a developer commits to remaining a developer throughout their career, they remove limitations on their potential growth as a developer and employee. They will continue to grow and evolve with the industry and become masters of their craft. Conversely, a developer who accepts a promotion into management may stagnate quickly. Management is a completely different occupation than development, and the recently promoted manager may find their skill set does not transfer. Similarly, the organization may not have much room for progression beyond middle management.

Remaining in a development position instead allows the programmer to spend their entire career mastering their development skills, increasing their capabilities and qualifications for more intense, higher-paid, senior-level programming positions. The programmer can advance and progress with development-based promotions, but staying out of management lends a significant advantage for attaining more prestigious programming jobs in the future.

I hope to use this pattern throughout my career. Once I had aspirations of progressing through management positions until I am high up at a large company, but progressing through management positions won’t be possible by virtue of programming skills – instead, a more attractive plan is to progress through the levels of development and engineering to finally land at a senior position. Not only will this maximize my potential as a coder, but remaining in a position interesting to me instead of stagnating in a more boring occupation will maximize my job satisfaction.

Reference:

Hoover, D. H., & Oshineye, A. (2010). Walking the Long Road. 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.