In this post, I will be covering the “Study The Classics” pattern from chapter six. I chose this pattern because it’s title seemed interesting. This pattern is contained within the chapter that focuses on individuals who are not necessarily motivated by learning for a grade, but those who are motivated by knowledge growth. So, this… Continue reading Apprenticeship Patterns: Study The Classics →

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

The subject of this blog post is the first chapter of “Apprenticeship Patterns – Guidance for the Aspiring Software Craftsman” by David H. Hoover and Adewale Oshineye.  I found this to be a phenomenal read and I am excited for what the book has to hold.  I now officially consider myself an apprentice software developer; I feel that I possess many of the values that Hoover and Oshineye use to define good software craftsmanship, which has reinforced and revitalized my feelings toward my field and abilities.

I really appreciated that this first chapter was devoted to defining key terms and concepts that will appear throughout the book.  I think these definitions will help me better grasp the concepts and and overall goal of the book, as I continue reading it.  I did not really consider myself an apprentice, until I read the definition provided in the book.  Marten Gustafson, an interviewee from the book, defines apprenticeship as being in the “state/process of evolving and looking or better ways and finding people, companies and situations that force you to learn those better/smarter/faster ways”, which I believe is the state of mind that I am currently in.

Something that really resinated with me, from Hoover and Oshineye’s definition of an apprentice, was the part where they talked about the need to learn how you learn and grow effectively, and how this inward focus on yourself and your need to grow is the essence of being an apprentice.  Up until now, I don’t think I was allowing myself the kind of inward focus they are describing – which is something I want to change.  I now feel that I truly am an apprentice and, as such, I ought to be a little more focused on myself and my progression toward becoming the master developer that I hope to be.

I also really appreciate Hoover and Oshineye’s understanding that the readers of this book will come from all different kinds of situations and circumstances, and they often reiterate the fact that the purpose of the book is not to dictate the right courses of action but to shape your mindset to that of a good software craftsman – “Since most newcomers’ experiences do not resemble the ‘ideal’ apprenticeship, the modern concept of apprenticeship is mainly a frame of mind: you recognize that you are still at the beginning, even if you’ve been programming for several years, and you are prepared to take steps to create your apprenticeship out of the circumstances you are in”.  I really connected with this because, I have been programming for years and have never considered myself  a true apprentice – because I wasn’t.

I have realized that, even though I have a bit of experience, it does not by any means make me an apprentice or software craftsman.  But, I am now prepared to take the necessary steps to create my apprenticeship, and work toward not only becoming a master developer but a master software craftsman.  I am excited to continue learning from this book and I look forward to the journey ahead of me.

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

In Chapter 2 of the Apprenticeship patterns, this chapter provides an overview of how an apprentice starts out into his journey. The chapter is broken down into sections where Hoover and Oshineye layout the details of “Emptying the Cup.” Patterns about understanding your first language, wearing the White Belt, Unleashing Enthusiasm, acquiring concrete skills, exposing your ignorance in a specific technology, confronting that ignorance, taking a chance to dive in The Deep End, and Retreat into Competence are the patterns an apprentice will experience and go through.

One of the patterns that sparked my interest was First Language. In the beginning of this pattern, there was a quote that i strongly agreed with. “By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect increases the mental power of the race.[…T]he technical terms of any profession or trade are incomprehensible to those who have never been trained to use them. But this is not because they are difficult in themselves. On the contrary they have invariably been introduced to make things easy.” This quote from Alfred North Whitehead reminded me on concepts of effective and efficient programming techniques. One of the concepts of effective programming techniques was the acronym YAGNI, which stands for “You Ain’t Gonna Need It.” To be an effective programmer, you need to manage your time wisely and devote that time to parts of your code that are going to matter the most. There’s no need to waste time adding things to your code that aren’t going to matter. It’s the same thing that goes for the brain. If you remove all the unnecessary thoughts in the mind, it will provide more room for mental power to make things easy when you work and conduct your tasks. I feel like that is the message that is being sent by Whitehead and why I think this quote was placed into this section of the First Language.  I find this chapter to be very useful and I agree, especially as a programmer, that efficiency in the workplace is important and that this chapter and pattern highlights that aspect.

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

“Apprenticeship makes a difference because it instills a lifelong passion to master the craft. It instills a passion for perpetual learning and, in the process, enables the apprentice to become a great developer.” – Pete McBreen

I do agree with this statement that was at the beginning of the chapter. As an individual, whenever I hear the word “Apprentice”, I always wonder and think about the “Master” because that is who the apprentice learns from. After reading through this chapter, I tried to tie all the concepts back to the title of the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. An apprentice should always try to learn and understand the concepts that the master is trying to teach. Understanding and learning the concepts is one thing. Learning how to implement and use the concepts is another. The techniques that you learn from a master can sometimes, if not most times, be found found in textbooks or they can’t be basically self-taught. Every master can have different styles, which is why a “master” is very valuable and special in a sense. To me, that is an Apprentice and Master relationship. When the apprentice is trying to perfect their craft with the aid of their master, it instills something very special within the apprentice’s work and makes them have the desire to want to learn and create more. This quote by McBreen is very important to me and makes sense to me the most. To relate it to myself, I feel that the Master is the contents of which I am trying to learn, and the Apprentice or Journeyman is myself.

There is a quote that also sparked my interest because it is a statement that I fully acknowledge. “One of the lessons we’ve learned from the Agile development movement is that just telling people to do things doesn’t create lasting or sustainable change. When the people you’ve advised encounter a situation that isn’t covered by the rules, they’re lost. However, if those same people have imbibed the values that underpin the rules, they can come up with new rules to fit any situation. Our goal here is not simply to hand people a rule book, but to give them the ability to create new practices for new contexts, which in turn drives the discipline of software development forward.” This supports the thought of critical thinking in a sense that thinking outside of the rules in order to create new ones is the foundation of continuing the evolution of software development. If developers encounter a situation that certain rules do not cover and they become lost, software development cannot progress forward.

As I am currently aspiring to become a future video game developer, I expect that there are going to be new rules that are going to be created constantly. I know that I am going to learn and to develop certain “crafts” to be very efficient in that environment of work because there will be many things to adapt to. As Pete McBreen points out, there are many developers out there today in the field. The important question is are there enough “good” ones? When I head out there in the field, I would want to be recognized as one of those “good” developers.

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

This week’s reading was Code Smells written by Jeff Atwood, on Coding Horror. As the title of the blog suggests, the message that the reader should get from the post is to familiarize themselves on the common smells to prevent design problems. With that, he lists the different type of smells into two categories, “Code Smells within Classes” and “Code Smells between Classes”. The first category deals with simplifying, removing or splitting code where its due to make reading methods easier. This idea is also applied to classes, which should reduce unnecessary classes or makes sure encapsulation is applied properly.

There is no definite reason as to why I chose this topic but it is said that developing your code nose early is useful for the future! From what I have gathered so far, the idea behind this topic is to have a good design where the earlier choices of methods/classes will not have conflicting issues for later additions or improvements to the code. Many of these code smells are already taught in earlier introductory CS courses such as, duplicated code and making useful comments.

After reading about the different types of code smells, I have noticed a couple that code be smells in previous school projects. One would be the overuse of comments, as I sometimes find myself not remembering what a certain function was used for, which compels myself to leave a comment here and there. Another would be oddball solutions, where sometimes issues mysteriously fixes itself as you continue with your code. This usually leads to problems in the future while adding newer functions. However, there are a couple of smells that are useful to remember now then later such as Speculative Generality. After being taught to prepare for future problems in life, it’s also sometimes applied to writing code but is a wrong mindset. Only implementing things when you need it will reduce clutter and seems to apply to the dead code smell, where you should delete unused code.

By exercising or having an open mind to these design problems will help prevent simple problems from appearing while working on projects. Having clean code benefits myself and others while reading the different classes/methods we each produce. Which should entail a better experience for group work, and saves time solving problems that should not have existed in the first place. There is no way to remember all the different smells, but being aware of them will help myself produce cleaner code in the future.

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.