The Expand Your Bandwidth pattern gives advice that makes suggestions based on how the title sounds, broaden your horizons.

In learning how to traverse the field of software development there are many tools one must learn to become a successful developer. One type of solution will not work for every problem that a developer faces and that’s why it’s important to never stop learning. The problems will never stop changing and that means that sometimes the application in dealing with or recognizing the problem might change too. The authors mention that an apprentice “must develop the discipline and techniques necessary to efficiently absorb new information, as well as to understand it, retain it, and apply it.” Ways to start applying this pattern include signing up for software development newsletters, following “software luminaries” on Twitter, and even taking free courses online.

I aspire to be a better developer everyday and sometimes finding the energy to become better doesn’t exist. These moments are the most crucial in terms of my own development. I remember being a part of a mailing group where you would pledge to setting aside a dedicated 15 minutes to learning something new in the software development field or use the time trying to write a part of a program. During those 15 minutes your attention should be undivided, and you should be hyper focused on the thing that you are working on.

I agree with the sentiments of this pattern. Being able to “to be able” in this field comes with a lot of knowledge that needs to be drawn upon. Even if you are not knowledgeable about something you should be able to have the skills to know where to look to find information related to problems you are trying to solve. Once the fountain of information has been located, being able to consume it and properly nourish one’s mind is also a skill that one must obtain. Just knowing where to look is not enough. One thing the authors do mention that I may have overlooked is knowing when to stop expanding your bandwidth. This is really important because if you spend all your time trying to learn everything it will actually have a negative impact on your everyday life, in terms of work and possibly even family. This is why I think the 15 minutes a day example is a good starting point to figure out what kind of balance you need to “stay frosty”.

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.

The craft over art apprenticeship pattern becomes relevant when you are hired to build a solution to a client’s problem. Building this would give you the oppurtunity to try something new, however a standard and stable solution already exists and is readily available. Hoover and Oshineye suggest focusing delivering to the client what they need rather than indulging an interest. It is better to build something functional for a customer over something beautiful, and you should work to balance the desire to create something artistic with the need to create something useful.

I think this apprenticeship pattern is interesting. I think, especially in a professional environment, your priority should be to create something your customer can easily use over something cool. It this pattern could be really useful if used in tandem with the breakable toys pattern I wrote about previously. I don’t think it’s bad to want to do cool and artistic things with your projects. Building something you think is beautiful sounds like a really good way to expiriment and develope your skills. However, if that interest interferes with your ability to deliver functional products to your customer, it may be wise to indulge that interest outside of work.

Reading through this design pattern has helped shape my expectations for my future profession. It highlights for me how focused the industry is on utility. I was not expecting to be able to use work projects as expressions of creativity, and this has confirmed that. I know to keep my personal and professional endeavors separate.

I do disagree a little with the way Hoover and Oshineye discuss creating beautiful works. In sections of this chapter, they talk about wanting artistry in your craft as if it is a bad thing. I agree that you should be able to recognize when it is appropriate to invest time in making a customer’s product beautiful, but I don’t think that urge should be shut down completely. That energy could easily be channeled into a personal project; you shouldn’t stop trying to use your skills to make beautiful things just because it might not benefit your employer.

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

The idea of Breakable Toys is that you can only really learn when you are given the ability to fail. When you are working in a real environment, you cannot afford to break anything. This limits how much you can learn, since the best part about messing up is learning from your mistakes. The main suggestion of Breakable Toys is that you should work on your own personal projects where you are able to make mistakes without affecting anything important.

If I’m being completely honest, I don’t like the idea of this pattern. I understand it, I realize why it is a good pattern, but I am not the person to work on programming in my free time. I have done it before, and the personal projects I worked on were fun, but I enjoy doing other things with my time. I enjoy being able to turn off work when I get home, and feeling like I need to continue to work is going to haunt me.

I do realize what this pattern is trying to say though, and I am not against that at all. The pattern says that you should work on something that you enjoy, and it shouldn’t be considered work but more of a hobby. I have been thinking about this ever since I began programming, but I feel like most of my ideas are outside of my skill level. Breakable Toys suggests that you should create a wiki about whatever you want so that it is personal to you, but as of right now I don’t want to do anything.

I am not too worried about the fact that I don’t really work on personal projects; I do when I feel like it. It is great to practice in an environment where you can try experimental things and build things for your own personal use, but I really do not want to feel obligated to do work on my own time. Overall, I think this is a very good pattern which is a hard pill for me to swallow. I know it will be good for me, but I cannot shake the feeling that I feel like I need to work on my own time.

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

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.