For this weeks blog post I will be discussing the pattern known as “Sweep the Floor”. Sweeping the Floor is about you starting from the bottom and then getting into the more complex tasks. This being you contributing to simpler tasks, learning from these and becoming more skilled then graduating into larger more complex tasks. Imagine you are an new apprentice on a project, unsure where you stand compared to others on the team and they are unsure about you as well. You want to earn your place on this team, contributing where you can, gaining their trust and growing in the craft essentially. To do this you could simply volunteer for something simple that is necessary to complete. This is a good starting way to contribute to a foreign team and to the teams success early on by showing you can do high quality jobs even for simple matters. Skimping on quality here could lead to trouble later on when it turns out later that this part is actually very important. Some various examples of these tasks include maintaining the build system, production support, responding to maintenance requests, bug fixing, code review, setting up a project wiki and so forth. Basically you would be focusing on the edges of the system where less risk lies rather than the heart of the project where the stress and complexity would be. But this of course could prove tougher to swallow if you have spent a lot of time and money in a computer science degree. The moment leading up to your career in theory has been doing all of the said above tasks almost just without pay. Another negative aspect of this would be you ending up as the teams gopher, condemned to do menial tasks no else wants to do. You may find yourself intimidated by doing anything other than sweeping the floor, feeling only comfortable doing this. There is also danger in that you may not be able to develop appreciation for bigger projects due to the smaller menial tasks you are accustomed to. In short finding the tasks nobody wants to do or complains about and creatively resolving these problems in ways that exceed peoples expectations will allow you to slowly soar above, something that most including myself can get behind.

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

For the tenth and final week of reading, I chose to read the pattern, Use the Source. This pattern focuses on the problem that without the presence of good source code to study, practice, and emulate, you can’t get better, and you might continue developing bad habits you didn’t know you have. The solution provided is to find another person’s code and start reading them. This will enable you to learn how they wrote their code and understand the thought process that made that code. The recommendation includes examining open source projects and examining them for why they work in such a way. Also, to attempt and refactor codebases to understand the decisions programmers make and why they didn’t choose a different way. This process also leads to why there is appreciation for code reviews and pair programming. Having other people read your code, you read theirs, everyone can learn from each other. Allowing yourself to get a feel for good and bad code, you can develop a better understanding of yourself and how to improve.

This pattern is interesting because I never thought about using open source projects as a way of learning. I always took open source projects as a way of getting things from the community and as a way of contributing back to the project. However, using it as a way of reading well maintained code, reading practice, and understanding the thought process is a creative way of using publicly available projects.

This pattern is also useful because once you have seen the code, you might remember it for later as the code is not textbook examples. Examining, dissecting, and understanding code from real world projects allow you to see more, retain more, and most likely apply it in your own code later on.

The pattern has caused me to change the way I think about my intended profession because there are many different ways of improving yourself as a software developer. Being on the look out for readily available information and tools and being creative with the resources you do have access to can make a difference. As such, this pattern is incredibly helpful at showing that sometimes resources for learning can be right in front of you, you just weren’t creative enough to know it was there from the start.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

For this post, I decided to read the pattern “The White Belt”. This pattern talks about the ability of a software developer, and craftsman, to unlearn something and use an entirely different approach to solve a problem in order to maintain the ability to learn. The pattern talks about the idea of getting stuck at what seems to be your peak potential but that this is merely because you aren’t trying something completely new that would force you to try to solve the problem with a new approach.

I agree with the overall premise of this pattern. Personally, I’ve found it incredibly difficult to try to learn new languages without internally trying to write Java in language X. This summer I had an internship where one of my projects was to make a prototype program for a chat bot using Microsoft’s existing AI technology. This meant that I had to veer away from my good friend Java and attempt to use a new language, C#. I honestly don’t remember that much about C# other than that it looks like a lot like Java and I was able to manipulate the code so that it worked. I spent the entirety of the project focused on how it was similar to Java and how to write Java in C# and never even remotely became a master of the language. Granted, it was a short term project (roughly 4-6 weeks and 20-30 hours a week), so mastery was never feasible. The problem is that if I have to work on another C# project at some point in my career, I will have to start over. I never unlearned my Java knowledge to write in C#.

This coming summer, I’ll be starting a position where I will almost exclusively be writing in C++, a language I have never written a line of code in. Before I start the job, I’m giving myself time to learn the basics, but I know that I’ll need guidance along the way from the subject matter experts at this new company. There will most certainly be moments where I am completely dumbfounded about how to solve a particular problem, or what is wrong with my solution. I’ve learned that over the last couple of years of interning, and at those companies I was using a language I thought I was pretty comfortable in (Java).

Being able to put on the white belt and learn from the masters is one of the things you hear about from everyone in almost every field of technical work. I plan to put on my white belt as soon as I walk in the door at my new company.

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.

If my previous blog posts haven’t reflected it enough, I am definitely nervous to step into the professional software development field. This is likely mostly due to my case of imposter syndrome, where I think of myself as less capable or knowledgeable than I actually am. On another hand, though, I have also been overwhelmed by the thought of being behind other team members or colleagues in terms of knowledge and experience, even though everyone will, and should, be aware of this gap.

This week’s apprenticeship pattern, Expose Your Ignorance, further reassured me that learning new things and not necessarily knowing everything right away on the job is a normal occurrence. Everyone on the team is under pressure to submit work by a certain time, and when there is a “weaker link” who may not be on the same page as other team members, it can certainly cause some tension and perhaps anxiety for this team member. However, in order to best confront this issue, the team member should break down their walls hiding their ignorance toward the subject of the project, as well as let everyone else know about of how much they know and how much they still need to learn. It is suggested that one of the best ways to show this ignorance of any topic is to ask questions, as well as remain transparent when working with others so that the team member’s level of expertise is not misinterpreted. The apprentice should not only disclose this information, but also emphasize their willingness to learn and catch up with the rest of the team.

I already had a feeling that upon entering the workforce, senior developers and other colleagues would have some sort of understanding that I will not have as much experience as them, and that I will need to spend time catching up to what they know. This pattern was great to allow me to realize that I shouldn’t be afraid to let everyone know where my knowledge of our work stands, even if it requires further progress to strive towards everyone else’s level of understanding.

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.

Use the Source is about the importance of reading other people’s code. Reading code is important because it is the only way to truly understand a system. Without studying and emulating examples of good code, you may never realize the bad habits that you have. A good practice is to read the code of the applications and tools that you use every day. By doing this you will learn good programming practices and start to understand the systems that surround you. It is also important to have other people read your code. Taking feedback from others will help you become a better programmer. Thanks to the large amount of open source projects available, it’s possible to read or contribute to a wide variety of projects built by the global community of software developers.

I enjoyed reading this pattern and found it to be extremely relevant. It is true that the only way to really understand code is to read it. I found it interesting how the author said that working programmers spend far more time reading code than writing it. If your only experience coding is what you’ve done in school, that might be hard to believe. But it makes sense for a number of reasons. Professional developers work on projects much larger than those that students work on, and all of that code must be read in order to understand it. Developers also don’t want to reinvent the wheel for every project, so a lot of time is probably spent reading implementations that others have created. Being able to quickly understand what a piece of code does by reading it is an important skill that isn’t taught in school. To become a great developer, you have to spend a lot of time reading other people’s code. This will introduce you to new ideas and better coding practices.

I thought that this pattern was very useful. When I have wanted to improve my coding skills in the past I have always tried writing new programs. I never realized that reading code is just as important. This is a great pattern that I will definitely try to implement in my life.

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

The Rubbing Elbows pattern is a solution to the problem of productivity reaching a plateau. If you always develop software by yourself, you may eventually get the feeling that there are superior techniques that you don’t know about. In order to fix this, you must rub elbows with another software developer. This means you must work on a hands-on task, side-by-side. This is necessary because there are some things that can only be learned when you are sitting with another software developer working to accomplish something.  There are many little techniques that can only be picked up when collaborating closely with somebody. The author uses pair programming as an example of this pattern. Apprentices should always look for opportunities to work on teams that use the technique of pair programming. However, pair programming isn’t the only application of this pattern. You can collaborate on a number of things such as a presentation, academic paper, or an open source project’s sprint. The goal of this pattern is to find ways to expose yourself to the working habits of other skilled people so that you can pick up on those habits and refine your skills.

I think that this pattern makes a lot of sense. If you are programming by yourself all the time, you will almost certainly reach a plateau because you aren’t being exposed to new ideas and techniques. Reading this pattern made me realize how important it is to work side-by-side with other people. It is true that by doing this you will pick up on the small techniques that the other person uses, and will learn things that can’t be taught in a book or classroom. I really liked the Richard Sennett quote about the ideal craft workshop. It captures the idea that gaining knowledge isn’t just about listening to words, but absorbing the thousands of little techniques that make up a skill. After reading this pattern I have a greater appreciation for pair programming, as I now realize the benefits of working on a task right next to somebody. Overall I found this pattern very useful and it has inspired me to rub elbows with fellow software developers.

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

Hello again! For this week’s blog I have chosen to write about the chapter from our textbook entitled “Practice, Practice, Practice”! The reason I chose this is because I saw it in the table of contents and it looked like something relateable and interesting to read. So without further ado, let’s jump on in to the chapter “Practice, Practice, Practice”.  The problem set up by this chapter is that you are always switched “ON” which never gives you a chance to learn from your daily programming mistakes. The book says its almost as if you’re always on stage. I feel that this can happen easily especially in a fast paced work environment like software development. Things in this field are always growing and changing and twisting and turning. Monday you might get assigned a project with requirements ABC and by Wednesday those requirements have changed form ABC to XYZ and the project now no longer holds any resemblence to the original project. In this case it is quite easy to get lost because you don’t have time to learn from your daily mistakes if you’re always trying to play catch up. The solution set forth by the book is interesting, however quite elementary and almost common sense. The main objective of the solution is to practice coding in an environment with zero pressure and in a place that you are comfortable and it is okay to break things. In other words, make a personal project at home or someplace other than work where the end objective does not matter, there is no customer or end user on the other side, and you can be free to break things and learn why they broke, then fix them at your own pace, allowing you to learn more so than if you were to be pressured and rushed to fix breakages in the field. There are many different ways to practice without interruption at your own pace where the actual environment does not matter. I think that it is one of the strongest ways to learn. Not only because you are teaching yourself (because you know how you learn best!) but because the environment in which you’re learning is truly stress free and problem free. Did it break while you were working? Who cares! It isn’t effecting anyone other than you. So take your time, work through the breakage, and fix it at your own pace and learn why it broke and how it was fixed!

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.