I tried to go into the Apprentice Patterns with an open mind, but this was difficult as my preconceived notions of an apprentice craftsman generally aligned with the old timey examples the first chapter described as not being what a software craftsman apprentice would look like.

The first chapter did a good job avoiding my worst expectations for the text, advocating for a return to past apprentice master relationships or some other ridiculous notion. These worries were not at the forefront of my mind, but they were at the back hoping they turned out to be unwarranted. Which they were thankfully.

The focus on being determined, hard working, and eager to learn and advance was definitely expected and aligned with what I believed a good software developer would be like. I agree with the assertion that people are not simply talented and skilled to begin with, it takes work to get there and continued work to maintain the level of skill achieved. Being talented or not is often seen as a binary value that you have or do not, stifling some who believe it is simply out of their grasp. I enjoy the text dissuading this line of thinking.

Being a software craftsman means to be skill centric rather than process centric is an idea that I’ve implicitly come to myself, but never really thought about in terms of consequences. The downsides of a skill centric field is petty obvious when it was stated, but I never considered it before. My eyes have opened somewhat and I feel like I will be seeing careers around me in terms of skill or process centric for some time.

When the text described the roles and differences between apprentices, journeymen, and masters it was about what I expected. It was somewhat vague, but that makes sense given how undefined things can be in the real world. What I found interesting was the mention of how some apprentice patterns would not work for a journeyman and that failure for them and masters cause much more harm than an apprentice’s. Failure is not discouraged for an apprentice, it is seen as a learning experience. So the limiting of options as one gains more responsibilities and failure becomes less acceptable was something I did not consider. Obviously as one gains more responsibility and experience failure should happen much less, but it is interesting to consider if the pressure of not being allowed to fail limits growth or not.

Overall, I am quite excited to keep reading the text. It seems to be geared specifically to people in my situation. Having several patterns that give guidance when I might not have any provides a nice safety net I can fall back on instead of guessing what works.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

I read through Chapter 1 of Apprenticeship Patterns a few times and really like the approach of seeing software craftsmanship in different levels.  When I think about it I guess that I’ve always thought of software development as either able to do it or not and getting better at it as you practice.  I like the idea of seeing it as being an apprentice, a journeyman, and a master.  It puts software craftsmanship in the same boat as other skills and trades.  It makes it sound like something that is more attainable to more people who are willing to practice at it.  Many times in just the past three and a half years of school when I tell people that I am majoring in computer science quickly say that they could never do that.  The truth is they could if they wanted to and practiced at it.  It is a skill/trade like plumbing or car maintenance.  You may not know anything now, but if you went to school for it or took the time to learn on your own you will grow your toolkit.  Seeing it as three levels is nice and makes it seem like less of a constant climb, it still is because the field is always changing, but when you reach the next level it is a little accomplishment rather than a constant climb with no specific advancement.  As the book says though that the definitions of apprentice, journeyman, and master are not the same as you would find in a dictionary.  For other trades there are unions set up and standards set in place that dictate when someone moves from apprentice to journeyman and journeyman to master.  There is no such set up for software development.  That would be an interesting development in the field if there was a governing body of some type and software developers created a union type set up.  I don’t believe that it will happen though as it is a new skill/trade and not seem the same as a plumber or an electrician.  For software developers it will be a more gradual and seamless transition rather than taking a test or working in the field for a certain number of hours.  As a portfolio grows and more skills are learned a developer will start to either search for a job at a higher level or start taking on more responsibilities at their current company.  Then without realizing they will be in the role of a journeyman and have a few apprentices that they will be around and either intentionally or unintentionally inspiring them and helping to shape their careers.  Then years later after working on many projects and taking leads they will make another gradual transition to become a master of their craft.  These won’t be as pronounced as your more traditional skills and trades.  I don’t think that it will change anytime soon because it is viewed differently than physical trades.

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

At first, while reading this chapter of Apprenticeship Patterns I was a little skeptical of how software development could be thought of as a “craft” with some kind of software guild made up of apprentices, journeymen and masters. However, after reading the authors’ own definition of what they believe “software craftsmanship” is I started to agree with what they had to say. I actually found their interpretation of apprentices, journeymen and masters, in the context of software craftsmanship, to be pretty interesting. I think that if all developers took on this way of thinking about software development the software engineering community could benefit immensely. By adhering to an apprentice mindset, software development newcomers might be able to avoid making the same mistakes that past generations of software developers have made.

Another thing I liked about this chapter was the values in which the authors believed every programmer should adopt. I think that adopting these values and committing to the idea that the only way to become a true “master” is through continuous learning though trial and error is the best way to progress your skills and career in the software development field. Among the values laid out by the authors’, I saw a common theme in that they think it is important to be open and transparent when it comes to software development techniques. I feel that competition can sometimes discourage companies and individuals from sharing their ideas and innovations, but this is can be detrimental to the software development community.  If all developers shared their work and development experiences, then software in general could possibly become more reliable and efficient.

This reading definitely made me change the way I think about software development as a whole. One thing it has made me consider is my overall career goals. The book talks about how one of the most important parts of becoming a better developer is finding a position that provides good mentors rather than finding the position that simply has the highest paying salary. This is something I didn’t really think about before and it has made me realize that if I want to enjoy what I do for the rest of my working days I should definitely try to find a place that encourages learning and provides many opportunities for mentors to give me feedback and ideas. Also, I think this reading will change how I work in the sense that I will look at failure in a new light. Instead of being mad that I can’t get something to work the first try I will remember that even the best developer out there has made countless mistakes to get where they currently are.

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

In this blog post, I want to go through Hoover and Oshineye’s values of software craftsmanship, and how I can apply them to my work and my development as a developer.  To summarize quickly, they are:

• Talent derives from effort and practice.
• Adapt and change.
• Embrace pragmatism.
• Share knowledge.
• Experiment, and be willing to fail.
• Take control of own destiny.
• Focus on individuals.
• Include the best ideas from everyone.
• Focus on skills over processes.
• Find like-minded people to learn with and from.

I don’t necessarily agree that all talent comes from practice and effort, but practice and effort are the cornerstones of ability; talent certainly languishes without use.  I also don’t think that it’s enough to just do my work for classes or my job.  Improvement requires practice on new things and dedication of time outside of the minimum needed to put food on the table.

Like any machine learning system, we can improve via feedback.  Unfortunately, it’s not always so easy as minimizing a loss function and backpropogating information.  I agree with the authors wholeheartedly on the need to find solutions to my inadequacies.

Pragmatism is great, but I don’t agree that it’s the end-all, be-all; I do appreciate, however, that it’s more important in the context of apprenticeship than it might be later in my life.  I recognize the tendency within myself to become paralyzed by attempts to force “theoretical purity” or “future perfection” from the start, and then never start at all.  This is something I very much want to change, or at least to recognize when it is useful versus times it gets in the way.

One of the things I enjoy most about being a part of a learning community is the ability to share what I know, and learn from my peers.  I will miss that after I graduate, so I may try to bring that kind of sharing to wherever I end up next.

I absolutely agree that progress in any form requires experimentation and failure.  From my experience playing various games, I know that it’s important to take something away from each loss, and also to acknowledge the room for improvement in each win.

I think that many of Hoover’s and Oshineye’s points follow from taking control of one’s destiny.  I agree that conscious choice and involvement in learning and life are key to the improvement of self.

I like the idea of a community of like-minded individuals rather than a blind reliance on hierarchy.  In my gaming life, I’ve found that (sometimes somewhat heated) debate is an excellent way to grow myself and to learn.

Inclusiveness goes hand-in-hand with pragmatism.  If an idea is useful or productive, adopt it.  If a person has value to contribute or simply wishes to share in the learning and information, include them.

My earlier education was heavily focused on skills over memorization, and that different processes may work better or worse for different individuals.  I agree that it’s important to recognize these things, as well as acknowledge that skill is not always equitable.

Learning is communual, and this last value of “situated learning” seems to follow naturally from many of the earlier ones.  I want to continue to align myself with like-minded individuals, even if that requires more effort than just showing up to class.

There is more to unpack in this chapter than what I have covered here, far more than what I could digest and boil down for a single blog post.  I believe that commitment to the values Hoover and Oshineye lay out will help me improve as a software craftsman.

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

This is my first post for the dev capstone

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

On a lay man point of view, craftsman is a person with a defined knowledge of doing something at its very best level. In this case the skills he or she posses and the ability to do well in his trade are very important to his clients. For instance, a building craftsman will be aiming at providing his client with the best and attractive finish building. To some extent, I am beginning to see how wrong I used to think about the term craftsman. If I was asked to define a craftsman without the knowledge after reading this chapter, I would not have think of software as a craft. I will describe craftsman as a highly skilled person who owned a workshop and have people called apprentice who are in the process of acquiring knowledge to enable them set up their own businesses. One may be surprised to see or hear that those practice in the 1900s where apprentices watch and imitate their master still exit. Only a few trades will allow or give the apprentice the chance to learn by doing it themselves. Doing it yourself will enabled you to learn and improve from your mistakes in the past. However, in the perspective of software the term craftsmanship have a deeper meaning attached to it that might affect the meaning. Even though term like craftsman, master, journeyman and apprentice are not new to many, they have difference meaning in difference field of study. In the light of software, many factors have to be taken in consideration; a professional developer who have been earning meet from his work for years will soon realize he or she is yet to undergo an apprenticeship process in his trade. One have to be prepared to learn or work hard for earn credit to his work. In this field, there is bound to be failure as in other trade and as a craftsman, you need to accept those failures as a motivation to improve in your next task rather than seeing them as mere failure or something discouraging. Again, to be successful, one need to be able to adjust to a changing situation and also able to accept criticism as a lesson for improvement.

besides, apprenticeship in this modern day is quit difference from the past where the apprentice just watch their master work for years and at some point learn by imitating what the master does. As an apprentice, you are given the chance to learn by trying it yourself then using your failures as a routine of mastery and improving your skills. In this modern world, even though an apprentice might be in small teams working under the supervision of the master, the outcome of their apprenticeship is solely their responsibility.

Also, a journeyman in this contest is a person with a knowledge in between the master and the apprentice and is able to lead the in the absent of the master. The journey man ideas in this chapter are something new to me and I am yet to see it practically.

Master in the other hand is the person with adequate knowledge of doing all the work of an apprentice or the journeyman and also keeping the trade alive. As a master, you should be very skillful and creative. A master as software craftsman, need to be able to create and share superior skills with his or her apprentice. In the other hand, apprenticeship is a process where new comers in the industry are trying to learn the requirement skills and knowledge that will make them function as developers and to earn living from it. These new comers need someone called the software craftsmen (Masters) or mentor to guide them through this process.

In conclusion, this chapter has been an interesting one I have read so far in this semester because I have drawn a lot of ideas from it and it will help me to take my destiny upon myself to explore the available resource and my professor as a mentor to achieve the necessary knowledge needed to survive in the software industry.

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