Category Archives: Week 6

Craft over Art

This week I choose to talk about the craft over art pattern. So, what is this pattern about? The book explains that craftsmanship is built upon strong relationships. This pattern is not about doing merely what is expedient. It also encompasses the idea that a useful craft artifact always displays at least a minimal level of quality. When using this pattern, you will have to balance your customer’s desire for the immediate resolution of their problem with the internal standards that make you a craftsman. 
There are many things a developer should keep in mind when he/she develops a program but one thing that we should never forget is that you are primarily building something that serves the needs of others, not indulging in artistic expression. Developers think creatively, experimenting with different solutions to fit user needs and generally are comfortable with design systems. I have been many times in the place where I had to build something that I didn’t feel like it, but it is the customer that you need to satisfy.
Something that I really like from this pattern is when the book explains that You need to do your best work in ways that place the interests of your customers over your desire to display skill or pad your resume, while still adhering to the minimum standards of competence provided by the software development community. Walking the Long Road means you must balance these conflicting demands. If you starve because you are too much of an artist and your creations are too beautiful to be delivered in the real world, then you have left the craft. If your desire to do beautiful work forces you out of professional software development and away from building useful things for real people, then you have left the craft.
When you are making decisions about software, you should guide yourself by always keeping this in mind: How we can help? You can even prioritize feature requests this way. Remember: the purpose of the software is not to show off how intelligent you are.  Your purpose is to help people — Max Kanat-Alexander, Code Simplicity

Reference:

Apprenticeship Patterns by Adewale Oshineye; Dave Hoover

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

Learn How You Fail – Apprenticeship Pattern

Today I will be writing about the “Learn How You Fail” apprenticeship pattern from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Adewale Oshineye and Dave Hoover, 2009. This pattern is for everyone. Everybody has failed at something and will again in the future. If you are not failing then you are not pushing the boundaries of your capabilities, and/or you are overlooking these failures.

The problem addressed in this apprenticeship pattern is that you have enhanced your success through learning, but failures and weaknesses remain. The solution to this is to gain an understanding of the habits, behaviors, and patterns that has led you to failure. With self knowledge, you can make conscious choices to avoid these behaviors/habits or to break them and give you an idea of your limitations. As explained in the book, This can help you make a decision whether to fix a problem or cut your losses. If something is going to be a disproportionate investment of time and money only for a small improvement, it may be time to improve on something else instead. Excepting your limitations is important, seeking for perfection will only disappoint. This could mean letting go of some areas of expertise that cannot benefit you as much if you do not have the time to maintain those skills.

A method recommended by the author is to keep a list of your current skillset and boundaries. This way you can have an organized view of these boundaries and decide which areas you would like to push/explore. I found this interesting because it is similar to the “Record What You Learn” design pattern that I had written about in my previous post. By writing down your experiences, you can gain a greater understanding of what is happening. This way you can grow as a developer. Writing down your habits, actions and patterns which cause you to fail, can help you move forward from the endless loop of repeated actions leading to failure. I like this pattern because it accepts that you will fail sometimes, but whats worse than failing is to not push your boundaries. This pattern helps you understand and map out your boundaries so you can push them in an organized, thoughtful way.

Hoover, D. H., & Oshineye, A. (2010). Apprenticeship patterns: Guidance for the aspiring software craftsman. Sebastopol, CA: O’Reilly.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog – Your First Language

For this week’s blog post, one pattern that stood out to me the most was “Your First Language” I believe that the first language will be the most important one for our careers because for the next few years this will be the main language, we use to solve problems or practice to improve.  My first language technically was HTML that I learned back in a web design class at High School, but my first official language is Java from our CS 140 class. From that class and onward I have been using java for almost everything even for personal projects or in other classes.

As I was reading the rest of the article, I came across a sentence how the author states, “For several years, your first language will be the framework against which you learn other languages. The better you know your first language, the easier it will be to learn your next language.” I believe this is very true, your first language will be the foundation for the rest of the languages you will be learning. I remember when we had the CS 282 class in which we learned the C language, it was much easier for me to learn the concepts faster because I had a good understanding of the first language. Another concept that I thought was interesting is about how your first language can prevent you from learning and using other languages, the author states that “One danger of digging deep into your first language is getting stuck. It likely will remain with you throughout your career as your native tongue.” I agree with this statement, having good proficiency in one language can indeed prevent you from learning and using other languages. However, it is good to have a diverse knowledge of languages, especially in software development as each language provides an opportunity to solve problems using different paradigms.

I agree with all the statements about this pattern, it is important to look back and see that starting from “your first language” now we are all learning and getting used to different languages. Especially for me, I have been trying to learn Python since most of the companies use it nowadays and, R to analyze different types of data which I find quite interesting.

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Your First Language – Apprenticeship Pattern

Our first programming language can be similar to the first language we learn to speak or our native tongue. What this pattern talks about is to first pick a language and start to master that language by practicing and solve problems in the specific language. It also talks about having some mentor or asking questions to someone more experienced so they can help guide you along the way of learning the programming language, but also at the same time not becoming dependent on them to solve your problems.

I found this chapter to be very interesting because whenever I think about coding and solving problems, the first syntax or code to use that comes in my mind is Java. The reason for this is because it is my first programming language that I learned and I have the most experience with it. This pattern has led me to confirm my belief that we need to first become better programmers in a specific language. A lot of people try to jump from one language to another and think it will be more beneficial. However, what this results to is not thorough understanding of a programming language, and more simple knowledge of each one. It is much more efficient to pick up a specific language based on your preference, and broaden your knowledge with it. Try out different problems to solve and keep on practicing. Once you feel you are at a level that you are content with, then move on to another language and broaden your knowledge about different types of programming. If you started with an object-oriented language, then learn about a functional programming language. Also, what this does is help moving from one language to another a lot better as well as understand the differences of each. With more experience in languages, we can start to see what languages are better for certain tasks and can examine advantages and disadvantages. In essence, the goal of this pattern is to take things a lot more slowly and in a more efficient way. It will be much better taking time to learn critical details then having front level knowledge. Overall, be open minded when it comes to languages as well and don’t just stick to one and decide that is it.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

The White Belt

Despite your inexperience and precisely because of your inexperience, you bring some unique qualities to the team, including infectious passion. Don’t let anyone dampen your excitement about software craftsmanship, it’s a valuable asset that will accelerate your learning. As a software developer, you will inevitably be part of a team and work on that basis. In any organizational structure, there is a tendency to conform to norms, especially for new people. Most teams don’t have an overheated passion for technology. To be sure, they are all focused on delivering the next project or improving some aspect of the software development cycle that is giving them headaches. As a result, passionate apprentices often succumb to outside pressure to keep a low profile. They either repress their passion entirely or let it manifest itself only in the absence of routine work. Unleashing passion in a relatively well-established team is, of course, risky. If morale is low or the team doesn’t welcome new people, you may get a dirty look behind your back. For those who believe that competence is more important than the ability to learn, there is no doubt that you will leave a bad impression, especially if you expose your ignorance. Like any model, this one should not be applied blindly. Team dynamics are always a consideration. If you find yourself in a group that doesn’t embrace your passion, then you’ll need to do something to nurture it.

Diversity of ideas should be seen as a key element of collective intelligence. An intriguing study of the collective psychology of aircraft carrier fleets shows that newcomers play an important role in the complex, coordinated operations required to safely maneuver a giant ship from which fighters constantly take off and land. The researchers found that a team made up of people with different levels of experience was healthier. When different levels of experience are correlating, for example, when novices with nothing “taken for granted” interact more frequently with old-timers who think they’ve seen the whole picture, everyone’s understanding of the problem deepens. It is true that in a healthy community it is good to be polymorphic.

As you transition into the role of a journeyman, you will become less dependent on those skills and gradually others will start hiring you based on your reputation, the projects you’ve worked on before, and the deeper qualities you bring to the team.

Expertise is a byproduct of the long journey we have taken, but not a destination.

Pursue excellence and success will find you. — Three Idiots

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

The White Belt

Despite your inexperience and precisely because of your inexperience, you bring some unique qualities to the team, including infectious passion. Don’t let anyone dampen your excitement about software craftsmanship, it’s a valuable asset that will accelerate your learning. As a software developer, you will inevitably be part of a team and work on that basis. In any organizational structure, there is a tendency to conform to norms, especially for new people. Most teams don’t have an overheated passion for technology. To be sure, they are all focused on delivering the next project or improving some aspect of the software development cycle that is giving them headaches. As a result, passionate apprentices often succumb to outside pressure to keep a low profile. They either repress their passion entirely or let it manifest itself only in the absence of routine work. Unleashing passion in a relatively well-established team is, of course, risky. If morale is low or the team doesn’t welcome new people, you may get a dirty look behind your back. For those who believe that competence is more important than the ability to learn, there is no doubt that you will leave a bad impression, especially if you expose your ignorance. Like any model, this one should not be applied blindly. Team dynamics are always a consideration. If you find yourself in a group that doesn’t embrace your passion, then you’ll need to do something to nurture it.

Diversity of ideas should be seen as a key element of collective intelligence. An intriguing study of the collective psychology of aircraft carrier fleets shows that newcomers play an important role in the complex, coordinated operations required to safely maneuver a giant ship from which fighters constantly take off and land. The researchers found that a team made up of people with different levels of experience was healthier. When different levels of experience are correlating, for example, when novices with nothing “taken for granted” interact more frequently with old-timers who think they’ve seen the whole picture, everyone’s understanding of the problem deepens. It is true that in a healthy community it is good to be polymorphic.

As you transition into the role of a journeyman, you will become less dependent on those skills and gradually others will start hiring you based on your reputation, the projects you’ve worked on before, and the deeper qualities you bring to the team.

Expertise is a byproduct of the long journey we have taken, but not a destination.

Pursue excellence and success will find you. — Three Idiots

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

The White Belt

Despite your inexperience and precisely because of your inexperience, you bring some unique qualities to the team, including infectious passion. Don’t let anyone dampen your excitement about software craftsmanship, it’s a valuable asset that will accelerate your learning. As a software developer, you will inevitably be part of a team and work on that basis. In any organizational structure, there is a tendency to conform to norms, especially for new people. Most teams don’t have an overheated passion for technology. To be sure, they are all focused on delivering the next project or improving some aspect of the software development cycle that is giving them headaches. As a result, passionate apprentices often succumb to outside pressure to keep a low profile. They either repress their passion entirely or let it manifest itself only in the absence of routine work. Unleashing passion in a relatively well-established team is, of course, risky. If morale is low or the team doesn’t welcome new people, you may get a dirty look behind your back. For those who believe that competence is more important than the ability to learn, there is no doubt that you will leave a bad impression, especially if you expose your ignorance. Like any model, this one should not be applied blindly. Team dynamics are always a consideration. If you find yourself in a group that doesn’t embrace your passion, then you’ll need to do something to nurture it.

Diversity of ideas should be seen as a key element of collective intelligence. An intriguing study of the collective psychology of aircraft carrier fleets shows that newcomers play an important role in the complex, coordinated operations required to safely maneuver a giant ship from which fighters constantly take off and land. The researchers found that a team made up of people with different levels of experience was healthier. When different levels of experience are correlating, for example, when novices with nothing “taken for granted” interact more frequently with old-timers who think they’ve seen the whole picture, everyone’s understanding of the problem deepens. It is true that in a healthy community it is good to be polymorphic.

As you transition into the role of a journeyman, you will become less dependent on those skills and gradually others will start hiring you based on your reputation, the projects you’ve worked on before, and the deeper qualities you bring to the team.

Expertise is a byproduct of the long journey we have taken, but not a destination.

Pursue excellence and success will find you. — Three Idiots

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

Breakable Toys: Improvement Through Experimentation

Photo by Polesie Toys on Pexels.com

In software development/programming related projects, much of the time making a mistake can feel like the end of the world, or at the very least a major inconvenience to everyone else around you. Yet by failing we often tend to learn more than we do by succeeding, since success seems to come most often from familiar and comfortable subjects or ideas which we might already have preexisting experience working with.

This is why I find the Breakable Toys pattern, described in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman as a way to work within a “safe space for failure” to be an interesting and largely relevant idea in the context of software development. The pattern describes the practice of building “breakable toys”, these being smaller, self-contained projects making use of the same toolsets you might use during professional or otherwise high-stakes development.

The pattern suggest building simple games or programs as a way of learning a new programming language. Building simple games such as Tetris or Checkers in order to get to grips with the language seems like it would be a fun experience, I think game development is an extremely interesting field, and focusing on your interests is an effective way to speed up familiarization with a new language by making use of something fun and engaging as a sort of “practice project”.

I have always enjoyed the idea of self-building software; the idea of having a usable program or application which is self-built is appealing. Similar to how a woodworker might feel sitting in a rocking-chair hand built from their own shop, the idea of building something which is demonstrably useful, or even just as an experiment to see what happens is a great opportunity to express creativity and explore a new topic. The added benefit of experience and potential to learn something new makes it a worthwhile experience in my opinion.

In terms of putting this particular pattern into practice, my first course of action would most definitely be to make a few simple games and applications, an image editing program or simple web browser seem like reasonable small-scale projects to work on as a learning experience.

Building something out of personal interest can make learning the required skillset a relatively painless experience, as by the end of it you will likely have something which you can be proud of and enjoy for many years to come.

Text Referenced: https://learning.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch05s03.html

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

Apprenticeship Patterns Blog Post #4

The fourth pattern that I plan on discussing is titled “expose your ignorance” in the book. The reason I want to choose this pattern to learn next is because I believe that it relates to me one hundred percent of the time I am in school. The idea behind this pattern is that if you do not speak up when you are lost, you will inevitably hurt your learning process. Many people, including myself, get into the habit of not vocalizing questions and concerns for fear of being disruptive, time-wasting, and possibly getting even more confused. It is very easy to simply keep your head down and struggle through a course or project without getting everything you need out of it. Basically, in situations where you do not know what you are doing, protecting your pride is often a bad solution, and exposing your ignorance is likely your best option. The book does a great job explaining why this is and it has good examples of times where it is a needed apprenticeship pattern to pick up. Even in jobs, it is important to expose your ignorance. The easiest way is by asking questions. Not only will it help you learn faster and more, but it will also ensure that you are doing everything right and in the way that your employer expects you to get your work done. The book has other solutions for this as well. In fact, the main action that it tells you to carry out is to “write down a list of five things you really don’t understand about your work. Put that list where others can see it. Then get in the habit of refreshing this list as your work changes.” Personally, I feel like in my years of schooling I have not reached out enough with questions for fear that I would look like I do not know what I am doing. It is not going to get any easier for me when I try to get real jobs, so it is important for me to learn to put my ego aside and expose my ignorance in a way that will allow me to learn and get better everyday.

From the blog CS@Worcester – Tim Drevitch CS Blog by timdrevitch and used with permission of the author. All other rights reserved by the author.

Concrete Skills

The “Concrete Skills” pattern in Apprenticeship Patterns can be understood, at a baseline level, to be the process of obtaining skills to achieve acceptance into a group of software professionals. This pattern elaborates on how the acquisition of skills has both intrinsic and extrinsic value in differentiating you as a potential candidate for the position in question.

Upon reading the Context and Problem section of this pattern, my brain immediately conjured up a preconceived notion as to what I should expect from the rest of the article to follow. In many respects that notion was correct; I was anticipating a description of the courting ritual between the gatekeeper(s) and the applicant. In the previously mentioned ritual, the applicant admits to humility but shows sufficient competence and desire to improve to the gatekeepers who either make an affirmative judgment leading to the conditional induction of the neophyte, or a rejection leading to the applicant walking away with redoubled determination to step back into the fiery crucible of honing their craft so that they may be better prepared the next time for the acceptance ritual. I embraced this struggle personally in my desire to create music; having been composed of solely aspiration and perspiration, I fell below the musical competency threshold during the audition process several times but I came back with a vengeance and was able to squeak out acceptance.

In the context of software development, Hoover and Oshineye are designating the in-group as a software development team who has a hiring manger that will be vetting your technical skills rather than several bandmates vetting your musical chops. The authors make mention of the concept they borrow from someone else called “day care”, and this is to illustrate the mentality of the gatekeeper who will ultimately be held responsible for the hiring and subsequent failings of the neophyte in an environment where time is software and software is money. I also appreciated that, aside from the intrinsic nature of possessing the technical skills, the authors made sure to mention that the need to develop these skills is also for the extrinsic value of passing human resource applicant filters and “managers who construct teams by playing buzzword bingo”.

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