If you consider yourself to be a programmer or developer, you are not an artist. Programming is a craft, a type of art, but it cannot be classified as a fine art. It can be more constructive than artistic. As an programmer you will be paid to build something that helps the customers to have … Continue reading Craft over Art
From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.
The apprenticeship pattern “Expose Your Ignorance” refers to the scenario in which you’re assigned a project but you are unfamiliar with some of the technologies that are required. Under the expectations of your colleagues, you may feel pressured to hide your ignorance so as not to seem incompetent as a developer. The best course of action, however, is to tell people the truth.
I can see why people might be uncomfortable with the idea of exposing their ignorance. However, I think that anyone who is more interested in actually becoming a better developer rather than focusing on what kind of developer they’re perceived as would be able to agree with this pattern. Sure, you could choose to pretend that you have the knowledge to complete any task already and then try to learn those technologies on your own, but there’s no guarantee that you’ll be successful. If you promise to deliver something and then later have to admit that you’re less knowledgeable than you initially let on, then you’re going to end up worse off. By admitting that you’re inexperienced with certain required technologies and asking questions, you’re able to show that you’re capable of learning while also being able to learn much faster with the assistance. One common phrase that I see commonly used is to “fake it till you make it”. I don’t doubt that there are some people who will look down on you for exposing your ignorance, but as long as you continue to focus on learning as effectively as you can, then you’ll be much better off in the long run.
One of the things I found interesting in the excerpt was to write down five things that you really don’t understand about your work and to put it where others can see it. This is definitely an extreme way of exposing your ignorance, but if people who see it are able to answer your questions and cross off an item on the list, then you’ll improve far faster than if you were to try to do the research alone. I’m not saying that you shouldn’t try to solve problems on your own, but it’s in everyone’s best interest to seek advice whenever they feel like they lack knowledge.
From the blog CS@Worcester – Dcanton Blog by dcantonblog and used with permission of the author. All other rights reserved by the author.
Hello everyone and welcome back to another apprenticeship pattern blog post. Today blog post is “sweep the floor” which Is basically about what happens usually you’re a newcomer. The task will be simpler than you expect but as the more you learn the more skill you become and eventually you will start to have more complex tasks. I learned that when you are in a team and you don’t know your place on the team and the team is unsure of you, you should try to find some way to contribute so you can earn some trust from the new team. I agree with this completely because when I start with a new team I always try to contribute as much as possible, so I don’t feel like I’m not contributing. I learned from experience that it’s best to contribute early as possible because you don’t want to give a wrong impression even if you don’t mean it. The more you put in to the project the more people will respect you because if you don’t put in any effort, they will all think that you shouldn’t be on the team and you don’t know what you are doing. I learned that its’s really important to volunteer for any task even if the task is not unglamorous but necessary tasks. I agree that it show you can do any job and gives you a chance to display your work. I learned that I should tackle the grungiest task that everyone is putting off because it will show people that you know what you are doing and it’s a way to exceeds people’s expectations. Always try to make the task more creative so that it can be more fun to work on. All in all, I think this individual apprenticeship pattern sweep the floor is really important pattern to learn because it teaches you how to function when working within a new group. I took a lot from this pattern and agree with every information that it gives. I have implemented most these tips in my daily life and benefit from them.
From the blog CS@Worcester – Phan's CS by phancs and used with permission of the author. All other rights reserved by the author.
I am writing this blog post about the “Read Constantly” apprenticeship pattern from the Apprenticeship Patterns book. To summarize the idea of this pattern, it is about spending more time reading about new material and ideas in order to stay in touch and learn about some new things. I think that this pattern is similar in many ways to the “Practice, Practice, Practice” apprenticeship pattern, because it is about taking the time and effort to become more familiar with a new topic. Reading research papers is an example given in the chapter. Any time I read about some unfamiliar topics, I always find that there is a huge depth of information that I have no idea about. Machine learning is one such topic that I spent a while reading about. After I had a good enough grasp of the basics behind the theory of it, I tried practicing implementing a basic multi layer feed forward neural network myself and have it classify some handwritten number symbols. Reading about it and implementing it was an interesting introduction into the field of machine learning, but continuing to read further into deep learning and the theory behind various learning algorithms, it becomes clear that there is still a ton about computer science that I have a ton to learn about. This is the case any time I look more than briefly into any broad topic. I was trying to implement a solution to a variant of the subset sum problem years ago and stumbled into NP-completeness and computational complexity theory. Constantly reading about new things is the only way to learn about different topics. The “problem” section in the book describes that there seems to be an endless amount of fundamental concepts that are unfamiliar despite proficiency in a programming language, and this is inevitable without reading constantly. Continuing to only practice in topics that are familiar makes it nearly impossible to expand into other fields without re-discovering them independently, which is unlikely when the areas are particularly advanced. Reading is like practicing learning. Proficiency in a language can only go so far.
From the blog CS@Worcester – klapointe blog by klapointe2 and used with permission of the author. All other rights reserved by the author.
This week’s blog is gonna be about “The Long Road” pattern. This pattern is all about traveling the long road. No matter how much you try to master anything, it will always be ahead of you. Mastery is a lifetime journey. You got to love whatever it is you are mastering. That is why they said, “Choose a job that you love and you’ll never work a day in your life.”
The book suggests valuing long term growth opportunities over salary and some sort of leadership or managerial role. This long journey to become a master will bring you a rich set of skills. You will become skilled at learning, problem-solving, and developing a good relationship with your customers. You will learn to wield these abilities and technologies. If you go through this long road, you will realize and appreciate what being a software developer really is.
This journey would not be short. It will be a long winding road. You should have a goal. Being on this long road, you will be a software developer even when you’re old. This pattern is not gonna make you filthy rich like the other positions, but it will be rewarding. This pattern is not for everybody, there are more people who will take a higher position without blinking an eye. Everyone wants to achieve something big and probably make more money.
I don’t really agree with this pattern. I think that taking the promotion would be a better path. It is not every day that a promotion would happen or a better position would be available. So why not grab the opportunity. It will also teach you more skills since it would it is a different role, it will also have different responsibilities. You will also learn how everything is run in the company and not get stuck at just creating software. They do talk about in the solution, that this long road does not only apply to being a software developer but for any position.
This pattern is good if you see yourself doing the same thing 10 years from now. Although, in my opinion, that is not a good thing to do. I think we need a bit of variety so that we do not get tired of it.
From the blog cs-wsu – Computer Science by csrenz 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.
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.