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.

For this weeks Blog Post I will discussing the pattern known as “Sustainable Motivations”. The Sustainable Motivation pattern is almost what it sounds like, where you require motivation to keep going. Anyone who knows programming knows that if a programmer is given the chance to do it there way, that is there biggest motivation. The context behind this is that you must develop your technical skills because of this you will find yourself working in a messy reality of specified projects for customers with different demands. The problem that arises is that when working in the real world trenches of projects you will find rigorous, tedious, exhausting, frustrating and constraining effects. The solution to this is that you need to ensure your motivations for craftsmanship will be able to adapt and survive through the Long Road ‘s (pattern) trials. For the most part there will be days and more that you love your job, getting paid to develop software and such. Where the work will just come natural to you without much effort. These days wont be ordinary days, because most programming jobs you will face tedious, vague definitions, and overly complex problems. You could even face some spotty leadership problems, difficult coworker personalities and other troubles. Because of this you may begin to question your commitment to the craft. When faced with these problems its almost imperative that you are aligned with the Long Road. Some examples could include you hating your programming job and are only motivated by the money. Where you value climbing the corporate ladder over honing the skills of your craft. But also are motivated by your reputation as a technologist, allowing you to survive and endure to the sun shines once more in your job. Another example could be you are motivated by your enjoyment of actual programming, where you then come up on a length of time where you cant find the love. But you are motivated by the money, and that programming is financially the best option right now, causing you to be motivated. All of these are good examples of how to be motivated but the best way to figure out yourself is to write down some motivations for you. Keeping this list somewhere safe where you can come upon it when times get tough. This pattern is something 96% of people can relate to, in almost any motivational situation and one I will see myself using down the road.

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

I have some very exciting news to share: I have recently accepted a software engineer position to start after graduation! I can’t wait to get started with this company, and I’m counting down the days until my first day there! My final interview involved talking with different members of the engineering team, and there was time allotted throughout the discussions for me to ask my own questions. There was one question that I asked everyone: “What is some advice that you would give a new graduate from a computer science program who is just getting started in the field?” There was one answer that came up the most, which was to not stop being eager to learn new things. This brings me to the apprenticeship pattern for this week, “Expand Your Bandwidth.”

This pattern exactly reflects the advice that I was given during my interview. Expand Your Bandwidth provides context with a possible problem of software developers’ knowledge potentially being focused to the type of work that they take part in on a daily basis. The solution is to simply begin absorbing more new knowledge at a faster, deeper rate. While the developer may find this process to be overwhelming, it is crucial that they can improve their ability to increase the level of learning new concepts and applying them to their own work. This process of expanding bandwidth includes actively seeking out knowledge, possibly through blogs, podcasts, courses, and contact with others who are as passionate about the topic as the apprentice is.

I couldn’t agree more with the suggestions and solutions that this pattern provides. I already have a list of several projects and practice exercises that I hope to complete throughout my career. I am so fortunate that the company that I will be working for seems to be ever-changing with the type of engineering work that is being done. I am confident that I will not run into the problem of work becoming stale or too routine. Nonetheless, I will be sure to continue to keep on taking in new information and building my field knowledge.

Thanks for reading!

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.