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.

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.

While forms of craft and art may seem similar to one another, sometimes it is important to note the distinction. This is the exact distinction that Craft over Art outlines in Chapter 3. The point is that crafts have utility, and works of art are made for beauty and reflection. It’s important that, if you’re crafting something, that you treat it that as it is meant to be treated — because it is something that may be used in the future by someone else. Sure, there is room for artistic expression in your craft, but they shouldn’t be anything more than decorative or stylistic touches. As they point out in the book, craftsmanship is built on relationships. It’s about delivering value to a customer and using that to earn your living. Art is usually something that comes from a very personal, self-reflective place that others may connect with. “After all, there’s no such thing as a starving craftsman.”

I like this pattern because it encourages the reader to focus on doing something useful as opposed to something beautiful, as stated in the action paragraph. I feel as though this is important because as of late, I’ve been focusing on this a lot myself in anticipation for upcoming coding interviews. Although I may not be working on things I find myself feeling extremely passionate about, I do feel happy working on what is expanding my skill set. Practicing the language fundamentals of both Java and C, doing interview-style questions, and my independent study have been a blessing in terms of knowledge and learning. They’re all things that will allow me to push the boundaries of my skillset for my future projects.

I will disagree partially with one thing about this pattern, though. I feel as though with the degree that web development, specifically front end, revolves around design choices, that programmers with an artist’s mindset have become extremely valuable. With the amount of emphasis placed on good website and app design, there is absolutely a place for those programmers who seek to make beauty with code where there may have been less of a place for them in the past. Granted, these are UI/UX designers who are partaking in a craft themselves — their art has utility and is meant to be used by others.

Regardless, I found this pattern fairly interesting as a reflection of what programming is and what it is meant to be. Placing yourself in the mindset of a craftsman makes a world of a difference (at least, to my geeky brain) in terms of how you should conduct yourself in the work environment.

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

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

We all want to get better at something but we often don’t really know what to do to get better. Sometimes, we can find ourselves repeating the same mundane tasks in hopes that something will just magically change or snap and we will be better at whatever it is we are doing. However, this couldn’t be further from the truth. When trying to get better at programming, you often have to practice things that you are not comfortable with. That’s just how learning works. In order to learn something new or get better at something that you need to improve on, you need to step out of your comfort zone in an environment that you feel safe doing so. Although practice may not make perfect, it does make permanent. Even if you are trying something new and you don’t quite get it right away, all that practice beforehand and grinding will not be of waste. You will just be reinforcing your skills, enhancing you previous knowledge. This pattern is great because it tells you to just keep working at whatever task you want to get better at. It also points out that just because you are repeating the same thing, that doesn’t mean you are not getting better at it. Choosing the right thing to practice every day is just as much as a skill as repeating something a lot. They are both important in that you are learning and reinforcing at the same time. Some of the books that the article pointed out that are good ways to ensure you have interesting exercises are Programming Pearls, More Programming Pearls, and Etudes for Programmers. The authors of these books understand that getting fundamentals deeply ingrained does not stop being useful. Practicing anything, as long as you understand what you need to do, you will always get better at something. That is just how practice works. Even if you think you are not getting better, you are still simply reinforcing already known ideas. This pattern is a great example that you can still try something without the fear of failing, because you just get better at it regardless of the outcome.

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