Throughout our career, we will be faced with various tasks and situations that will require problems to be solved using various different resources. Some of these resources we will be a challenge in themselves because they may not be easy to learn or obtain. It’s all about picking something and sticking with it. Whether or not this is an idea, a programming language, or something else, it is always important to understand core concepts of ideas in order to completely fulfill them for a certain task. From the reading, there are various definitions of certain professions that can actual alter what we do based on it’s meaning. For instance, the reading talks about the terms apprentice, journeyman, and master and their relationship with software. Not only did I find this a very intriguing distinction, but it really opened my eyes as to just how many types of different operations occur in software craftsmanship. The way that the reading described each of the roles really picked my brain in a good way. It made me realize that there are many things that go on in each of these roles that I would have thought to be redundant. For example, when talking about an apprentice, it important to recognize that it is not really someone who works under an “elder” or master of work. Rather, it is more of an actual process. This process is composed of evolving and finding ways to solve issues in certain situations. It is a way that makes you complete issues and tasks on your own using the resources available while not really relying on someone else. This idea on how an apprentice means a type of process makes sense, especially when looking at it through a software developer point of view. This is because it can be a segway into the Jorneyman and and later a Master. The while the Journeyman is discovering and maintaining focus to grow craft, this later evolves into the “final” tier, the Master. But what exactly is a master created with? Similar to the previous roles of apprentice and journeyman, the master takes on all the processes and situation handling of those and finally gains the skill the enhance the skills of others while also figuring out new skills that can surpass your currents. All of this combined is plays a huge role in the later chapters of 2-6 where it discusses where to start, what to do, how to self motivate and much more. But where should you start?

One of the hardest places of tackling any task is the beginning. I agree with how the book approached this topic. Basically, what the book is telling us is that you should pick something and just stick to it for a while. If you need to solve a problem, you should have at least one language that you can be proficient in. By starting with this, you will have a basic building block for working on other task and to familiarize yourself even further when it comes time to working on other projects and/or jobs.  This chapter, Emptying the Cup (chapter 2), seems pretty relevant to me because I often have this issue. Often times I  have trouble choosing a starting position for tasks and don’t know where to begin. But after reading this chapter, the most important thing to do is to just try and stick with one thing and prevent yourself from trying to do multiple things at once and try to do one process at a time.

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.

This is blog post about the introduction of the concept of an apprenticeship pattern from the book “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye”. This first chapter explains what is Software Craftsmanship, what does it mean to be an Apprentice, Journeyman, and Master. The word Craftsmanship is what I expect as programmer, we train our skill though practice and get better overtime. The mindset Craftsmanship is to be an Apprentice, we should have the attitude that there is better/smarter/faster way so our thought progress will always be finding better way. While we learn from our peers and more experienced developer, we also learn how to learn. When we progress through Craftsmanship, another focus would be the connection within and outside of team. As we know, communication play big role in software developer, the journeyman’s responsibilities are wider than those of an apprentice. Mastery involves performing all the roles of an apprentice or a journeyman as well as focusing on enhance the skills.  What is Apprenticeship and Apprenticeship Pattern? Apprenticeship is a way to learn to be a professional software developer, focus on how to be skilled software developers and work with others. Apprenticeship Pattern is the collection of patterns from the experiences of about 30 practitioners, these patterns offer guidance to someone on the way of improving progress of their career.

The introduction the remain 5 chapters we get to see many patterns. These patterns are the important to be Craftsmanship, it is cover from how to be humble, learn to learn others and how much more we need to learn etc.. I think “Empty the Cup”, “Walking the Long Road” and “Accurate Self-Assessment “chapters are good for the beginner and to all software developer. Although I haven’t read most of the patterns, they seem straight forward with the setup: context, problem, solution, and action. I am sure there will be patterns that will help me in the future career. After the reading there is not so much change my opinion, about the topic. I have a mindset about software developer, and this book is make clear, also show me more ideas in this career. Overall the main focus of this book is how to be better at our skill and career. The chapters I mentioned above seem most relevant to me. So far I don’t have any disagree with this reading. This is a good guideline for the aspiring software craftsman, we find the balance in our learning not too full as the cup of tea or become big fish in a small pond.

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

What I found interesting about the introduction chapter would be what it meant to become a software craftsman. It meant going through three different stages, apprentice then journeyman then master. But way before that, there is a heap of values that must be upheld in order to successfully start the process. These values can be summed up to, willingness to learn, succeed, fail, try something new while setting aside past experiences, and so on. Individually, many of these values are strong and correct in its own way. When they are brought together under software craftsman, I can definitely tell how the mindset of a true craftsman should look like. First you start out as an individual that is constantly looking to grow and absorb all the information and techniques from the more experienced members of the community. Then you take that and apply it, in order to constantly improve and grow their portfolio of things they have done. Lastly, they will likely end up a seasoned software developer that can have an impact on the community as a whole while still learning as an apprentice and building their portfolio like a journeyman. This concept is short and sweet but is practical in describing a person that has the commitment and dedication to his/her craft to rise to the top.

The chapter that resonated with me the most would be chapter two from the interactions between the master and the philosopher. The interaction in question would be how the young man would not let the master show him his methods of techniques that he might have already been taught. This creates a picture of how the master and apprentice relationship should not be. As the apprentice should be willing to put aside his past experiences while digesting new methods of the master, he is currently seeking teachings from. As a human being, you are bound to encounter people who are more experienced in a field that interests you. While you might be somewhat experienced or knowledgeable in that field, especially in software, there are always more than one way of accomplishing any task.

Another chapter that resonated with me would be chapter four, accurate self-assessment. The main point can be summarized as never get too comfortable at being successful short term. You must think about the long term, which also taps into chapter three about the long road where you can’t get to become the best at anything overnight. These two chapters can for example describe any sports player, they definitely did not become professionals by being content of what skill level they are at, they must have practiced for many years and constantly seeking improvement to get to their current state. These values are agreeable and applicable to people looking to become better software developers. Overall, I believe the readings reinforce ideas and values that could make anyone successful at any craft they are interested in and not necessarily software developer related but in this context, it will be an extremely useful resource to have.

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.

First of all from just the introduction chapter I like how everything is written, making it feel nice and easy to read without being overburdened by new things to newcomers but takes it slow. The beginning part where they provided an example of someone who decided it would be best if they were to reveal their ignorance on their programming language knowledge to their mentors was an interesting and relatable topic. This is something I agree with a lot, its harmful to not say anything in the face of your pride alone when you could speak up and face it head on.  Throughout the reading it seems to stress the ignorance of your own that could hinder your development. It also stresses the importance of finding a friend or someone you know who is knowledgeable in programming to help you. The reason for this is that if someone close to you gives you assistance the return rate of said assistance would be faster than that of someone who is not close to you, allowing maximum growth. I also like how the reading stresses craft over art or rather how programming is a craft rather than a fine art. The example they use is a perfect one, where a solution is already been proven and is readily available, but the customers problem offers you to do something unique or “fantastic” as they say. Essentially creating something new rather than going down the tested and true path. Honestly chapter three and four were pretty insightful into a mindset that is needed in the programming field, at least one where you become a better version of yourself. The idea of perpetual learning is something I agree with completely, the example they give right at the beginning of chapter five is a good one. Essentially becoming narrow-minded or solely focused on “low-level” details of what you only work on a day to day basis can be harmful for your growth. But by stepping out of these bounds and trying to “perpetually learn” things is something you should do as it can only be beneficial and not harmful to your growth. They give some examples on how to start this but of course the easiest way is to simply go online and look at the hundreds of readily available sites whether they be academic based sites, podcasts, YouTube videos or a blog from some high end developer and more. Chapter six was almost a reaffirmation of some of the ideas talked about in five with you constructing your own curriculum, something that goes hand and hand to perpetual learning. Again this is something I agree with a lot as having your own set curriculum whether it be reading a book related to your field, watching videos/podcasts or doing research and more these are all important to improve one’s self. All and all I thought this reading was pretty good and straight forward, a good almost pep talk to those who may not know what to do or how to improve your self in the field.

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

In my Software Development capstone class this semester, we’re reading Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Adewale Oshineye and Dave Hoover. I’ve read the first chapter and the introductions for chapters 2-6, and I’m hooked on this book so far.

In the introduction chapter alone, several ideas really jumped out at me. The authors encourage the reader to place emphasis on self development, preparing themselves to go out and confront the world as opposed to seek to change the world as a route for their success. They talk highly of personal responsibility and “lowering” oneself to the status of apprenticeship until those with greater achievements in the hierarchy of craftsmanship recognize the apprentice’s work. To revel in the fact that you are in the phase of your life where your primary goal is to learn and hone your skills. “This is a time for you to delay your ambitions of immediately maximizing your earning potential in order to maximize your learning opportunities.” Personally, I find genuine comfort in feeling that an apprentice doesn’t need to put on airs in order to look like they know more than they do. A willingness to grow will show for itself, and in practicing that mentality you will find yourself to be a capable and skilled craftsman in no time.

Each chapter in the book outlines a group of “patterns” that can be followed along one’s journey from apprentice to master. I think they’re all full of genuine wisdom so I figured I’d give an outline of each:

Chapter 2, “Emptying the Cup”, contains patterns regarding letting go of the knowledge you’ve gained as to allow yourself to learn as much as possible during your apprenticeships. Chapter 3, “Walking the Long Road”, is about saddling yourself up for the journey ahead. Understand that there are others who are further along the road than you are, and accept that. The only way that you reach that same spot is to keep walking the path that they have previously tread. Chapter 4, “Accurate Self-Assessment”, is similar to “Emptying the Cup”, except this time it is for the purpose of preventing yourself from getting too comfortable. Never become complacent in what you’ve learned — there’s always more to know. Chapter 5, “Perpetual Learning”, is a direct follow up to Chapter 4 because once you’ve assessed yourself, you know that there is more to learn. This chapter discusses techniques for continued learning and the extreme importance of it along the career of a software craftsman, in particular. Finally, Chapter 6, “Construct your Curriculum”, offers advice for the apprentice seeking further education. While resources on the internet are great, acquiring a library (of sorts) of books written by master craftsmen will always offer material that just cannot be found elsewhere. On top of this, it’s important to actually read the material that you acquire. Creating a curriculum, quite literally, to chip away at the vast material at your fingertips will help amplify your skills perhaps more than anything else.

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

After reading the first chapter of Apprentice Patterns, as well as the introductions to chapters 2-6, I have a lot of comments. The first chapter does a great job of setting up the reader with the understanding that this book is for the “little guy” on the ladder of software development. The different pieces that give definitions and explanations for the different roles of apprentice, journeyman, and master, give readers a means to compare the roles in the specific context of software development.

I do have to note that I disagree with some of the points that the first chapter makes. The first chapter talks about the horror stories of first jobs, or early career positions in general for the software developer. I feel that these claims are simply outdated. Because there are so many positions that need to be filled for mid-level developers, companies are doing all that they can to fight for early career, or fresh-out-of-college employees. There are incentives like a guaranteed mentor and open-concept work environments where collaboration is not only encouraged, by a key part of what might be considered the mission statement of the software development department of the company. These open-concept environments lack traditional cubicles that the book refers to as “ small, rectangular stalls with a PC and a crippled Internet connection”. While many, and most likely most companies still have cubicles, the other points have all been existent in every company I interviewed with both for internships and for full time positions before making a decision. One of the reasons why I decided to accept the offer I did was because of the guarantee that I will have a mentor for my first year of employment, as well as the open concept, extremely team focused work environment. While I do think it is important to note that some people might not be so fortunate, it is also just as important to recognize that there are companies that strive for the mentorship situations the book seems to think don’t exist.

One of the chapters that appeals to me the most is chapter 2. The story of the philosopher and the Zen master. I feel that many people feel that they need to learn everything in school and have an overwhelming fear that they don’t know everything that they need to know for their first job out of college. I felt this way before my first internship. After two internships, I’ve learned that you simply cannot be completely prepared for everything that a job is going to throw at you. The best you can do is try to master what you’ve learned and be open to new techniques, technologies, business logic, and entirely different work patterns. Like the journeymen described, who travel from master to master, learning the optimal means of their craft, we will work with different “masters” throughout our careers, and to be successful, we have to be able to identify the “best” techniques and it is our duty to share our knowledge.
Another chapter that I feel furthers many of these points is chapter 4. This chapter talks about the idea of not becoming comfortable with your knowledge and accepting it as your limits. The idea is not to measure yourself on comparing yourself to other developers in an attempt to become better than average. Instead we are always trying to become a better version of ourselves compared to the day before.

I’m overall excited to read through this book, and to relate myself to the patterns in the book. 

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.