Good my fellow readers!

Today I will be discussing an individual Apprenticeship Pattern from the book, Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. The pattern I would like to discuss today is naturally the first one, Your First Language, because where else is there to start but at the beginning?

The pattern starts by defining itself as a pattern for those who have surface knowledge of a couple of languages. It suggests that this particular pattern is for those who need to learn a language to solve a problem at work for example, or need to know a language for a job interview. It then launches into the solution, through execution of the pattern. To put it plainly the pattern is to pick a language and learn it. Having a problem to solve helps the process by giving you a goal to work towards and a drive to keep learning. It is also advised to take things slow and in small steps. It is also suggested to find a community and learn from its members as some methods or teachings may only be spread by word of mouth. It ends by reminding the reader to not get stuck with one language and to spread out into other languages.

I will admit, with this being the first pattern in the book I expected it to be for total beginners but it is aimed at just about everyone. What I find interesting about this pattern is that it seems to cater well to those who have never really picked up coding before or someone who, like myself, have had years of high school and college education in coding. I will admit that the amount I know about all the languages I have learned about is somewhat shallow. Some go deeper but many are probably not that far off from just surface knowledge. I might just try following this pattern after graduation. At first, I would have only recommended this pattern for only beginners who haven’t had formal schooling but after reconsidering, I think even those like myself who have had formal schooling can benefit from this pattern.

That’s all I have to draw from this first pattern and I hope to get more from future patterns. Until next time readers!

From the blog CS@Worcester – Computer Science Discovery at WSU by mesitecsblog and used with permission of the author. All other rights reserved by the author.

Link to the article: https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch06s03.html

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

I decided to read “Record What You Learn” for this week’s post. This one is pretty self explanatory, record what you learn. The pattern says to do just this, and explains that this is a way to review key learnings throughout your journey of software development craftsmanship. The pattern also notes that it is important to not let your writings become a graveyard for what you have learned. By this, they mean that you should consistently go back and review what you’ve written in the past to possibly amend the posts, or to find links to other notes you have written.

I agree that this is a very valuable “study” technique and it works for all facets of learning. The most difficult part of this, is that this is a very time intensive way to remember everything. As you learn more, the bigger the library of written lessons gets. This mean that every time you learn something, that review session gets longer. I think that this means that it is important to acknowledge that you simply will have to relearn things from time to time, but documenting what you’ve learned for higher level topics, is a great way to save time in the future.

While I do see how this could be difficult for an individual who is learning vastly different and often irrelevant topics when compared to each other, this is definitely something that can be used as part of a company project wiki. Large companies are constantly hiring new personnel who have to play catch-up to learn a code base as well as the coding styles of their peers. Having some sort of blog or wiki for the project could help these new-hires get acquainted with how the company functions and how to solve problems that are specific to the particular stack and business logic that the company is utilizing.

I do not know if I see myself personally following this advice, because this is not really my learning style. I tend to learn something by repetition instead of documenting what I’m doing. However, I do recommend that anyone who learns well via methods like flash cards, studying notes, etc, give this method of learning a try. It could be quite useful to someone who succeeds` when applying these learning methods.

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.

The Deep End in Chapter 2: Emptying the Cup of Apprenticeship Patterns is a pattern that reflects much of how I’m feeling lately. There are several places in life where this pattern pops up — often because you’ve realized that things feel stagnant in your career. Things need to change in order for you to grow and expand your skillset, and your current environment doesn’t reflect one of growth. The solution of this problem is to make a large life change and let the chips fall where they may. It’s scary to do this because you’re so comfortable where you are and with the work you do, but at the same time you’re stuck in a rut and you need some sort of upheaval in order to feel excitement once again.

I’m feeling this pattern quite a bit right now because I’m finishing up my degree at Worcester State. I’m not quite in a rut at the moment, although the next phase of my professional development is going to demand that I move forward at a rapid pace. Going through the interviewing process is tricky, because I feel constantly aware of the areas of knowledge that I lack expertise in. Obviously no one can know everything, and it’s more important that you’re capable of learning and being an essential part of the team. I think that being hired as an entry level developer is going to be interesting because you really do feel as though you’re being thrown into the deep end.

It feels extremely overwhelming to move into a workspace that you have no experience in, especially in my case where I have no current internships. I know what to expect on a general level, however I also know that there will be many things that I won’t fully understand until I’ve worked as a software engineer for some time. In order to learn any of those things, I’m going to have to fail from time to time. That’s exactly the point of “The Deep End”, and that’s exactly what I need to make sure I remember. If you’re never in a place where you’re failing, you’re never in a place where you’re setting and aiming towards goals.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

One thing that was brought to my attention when going through the computer science / software development major, was that many of us suffer from what I was told was “impostor syndrome”; the persistent feeling that I do not know anywhere near enough, and that fear that your are a hack or a fake. While this persistent fear is definitely a symptom of inexperience, it nevertheless is a challenge to gaining confidence in our abilities.

Thankfully the authors of Apprenticeship Patterns have developed a pattern for dealing with this fear in the real world. Their advice is when you feel overwhelmed by the volume of information you don’t understand yet, you should temporarily “retreat into competence”. By taking a short time to work on some problem which you do know well, you can reset your perspective and freshen your resolve to tackle the new challenges, bounding back like “a rock in a catapult”, using the backwards momentum to launch yourself even further than you would have gone originally.

While this is definitely a helpful strategy for compartmentalizing our learning experience, too much reliance on this pattern will result in mediocrity, as you would hardly make any meaningful progress and your skill as a craftsman will stagnate. The authors acknowledge this, and definitely warn against it, suggesting that retreating into competence should only be done with set time restrictions before we move forward again. Time boxing in this way will ensure we can regain our confidence and composure while at the same time making sure that we are always driving forward.

I definitely appreciate this pattern though and will definitely be applying it in the future to keep myself on track. It is remarkably helpful to be able to, as the authors put it “overcome the fear of your own incompetence”. By taking one step back and two steps forward, we can continue the march of progress at a more comfortable pace, and hopefully alleviate some of the fears and overwhelming feeling when facing the vastly expanding world of software development. This is definitely a pattern I have subconsciously been applying previously, but I will definitely make a more conscious effort to use it and time box myself properly to ensure stable progress.

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

The long and short of the pattern is to not accept a lucrative position or promotion if it takes you away from practicing your technical skills. If those skills aren’t constantly honed, they will be lost or become outdated before long.

A family friend was a midlevel manager at a software development company before he was laid off. He had gotten away from doing the technical work. The trouble was that most companies promote from within, so it was hard for him to apply for a job that he had before. It was also hard for him to start a job doing the technical side because those skills weren’t as fresh in his mind. There’s a good lesson to be learned from his story.

I often hear from people complain their manager is out of touch. The pointy haired boss  from Dilbert strikes a chord for so many for a reason. Perhaps more fitting to this pattern is The Office’s (U.S.) Michael Scott. While he has his moments, he is by in large an extremely incompetent manager. However, he does go on some sales calls in the series, and it is clear that he is a brilliant salesman. It seems that it is common that people are promoted to the point where they are inept at that position and advance no further.

Although the pattern does not quite suggest that people are promoted until they aren’t the best managers they can be, it seems to suggest that if you are no longer using your technical skills, you will become more and more out of touch with that side. You will no longer be on track to become a master craftsman when you accept this route.

I do not want that to be me. I would like to continue to grow and learn. I have talked to people who have a technical background and become something else, such as a salesman or manager. I have been tempted to take this route. I am not saying that I won’t do something similar someday, but for the time being, this does not fit into my goals.

My goal is to become a master craftsman. I’m aware goals change over time, but I would like to pursue this for a while before reassessing. I feel as though the reason I would change tracks if I found that this career was no longer what I wanted. I don’t think that will be the case, but it is a possibility. The one thing I know I won’t do is change tracks if I’m happy where I’m at. Sometimes what seems like the logical next step to advance your career can actually be more of a step back. It is best to instead to choose the path that will lead you towards becoming a master instead.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Hello there! For this week’s blog I have decided to write about the chapter of our textbook called “Sweep the Floor”. The chapter caught my attention because of the small description of it. The description of the chapter was something along the lines of you are a new member of a software development team and you need to gain their trust. This is something that intrigued me because I will be starting in a software development team as a new member at the end of May, and I am not quite sure what to expect. I have never worked in a real-life software development team, let alone develop software full-time 8-10 hours a day 5 days a week. This chapter was something I was hoping would help me when it comes time to integrate myself into my new team come May. So the problem that’s set out in this chapter is basically the same as mentioned above, the team doesn’t know you, you don’t know the team, so how can you find your place and find out how you can contribute best to the team? The solution is somewhat elementary and what some would think of as common sense. The first part of the solution is to volunteer for some small, perhaps even mundane task that either nobody else wants to take on or is too busy to take on. Sure, this isn’t a task you went to college for four years to complete. Maybe the task is transferring some physical data into excel, or updating computer software around the office. It doesn’t matter what the task is, what matters is that by taking the initiative and volunteering yourself for the small day-to-day not so glamorous tasks, you are slowly gaining your teams trust and finding your place on the team. They will appreciate that you are taking a step forward and doing things that need to be done; getting in the trenches (so to say) and eventually this will lead to your team trusting you to take on bigger tasks that are more normal for a software developer like pushing things to production and writing major elements of a program. I hope to use this tactic in my workplace to quickly assimilate into my team and find my place.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

This pattern is about the conflict between creating software that is beautiful and creating software that is useful. While you may find opportunities to do something truly fantastic, a craftsman should always focus on delivering value to the customer rather than advancing his or her own self-interests. You must find a way to balance the conflicting demands of creating quality software while still putting your customer’s interests first. Software built for customers can be beautiful, but it must always be useful. Following this pattern means that you must be willing to sacrifice beauty in favor of utility when it becomes necessary.

A craftsman must also produce satisfactory quality even if he or she doesn’t feel like it. Craftsmen can’t wait for inspiration to strike before delivering a product. However, it’s not about simply doing what is fastest. A craft artifact should always display at least a minimal level of quality. This means you must always be making trade-offs between beauty and utility, and sometimes you will make the wrong trade-off. However, by fixing these mistakes, you will learn lessons that are impossible to learn in any other way.

I enjoyed reading this pattern. I have always found it interesting how programming is so technical yet can be incredibly artistic at the same time. This pattern brings up a very valid point that even though you may be able to create something artistic, utility will always be a priority when software is made for a customer. I think the following sentence from the pattern sums it up perfectly: “The things we build for customers can be beautiful, but must be useful.”

As a programmer, it is often tough to decide whether to code something that gets the job done but is ugly, or something that takes more time but is beautiful. It is important to analyze the purpose of what you’re creating to decide which direction you should head in. Reading this pattern made me think a lot about utility vs beauty in software development. I do agree with the main point that as a craftsman creating something for a customer, utility should be prioritized. Overall, I thought this was an interesting and useful pattern.

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