The pattern I decided to read is titled “Expose Your Ignorance” from chapter 2 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern starts with throwing out a hypothetical problem where the reader is working for an employer that is expecting the reader to deliver a product but the reader is unfamiliar with the required technologies. The solution to this problem is in giving an honest response and building a reputation on your ability to learn rather building a reputation on what you know. This pattern also mentions how asking questions is a great way to expose your ignorance because you show what you are learning to your teammates. The pattern ends by discussing how exposing your ignorance is a trait of walking the long road because it means you are open to learning unfamiliar technologies and new domains. Whereas, experts tend to narrow their scope of learning, practice, and projects by specializing in specific things.

There were two instantly helpful pieces of information I gathered from reading this pattern. The first useful piece of information was how as I work on becoming a software craftsman, it is more useful to be known for my ability to learn things instead of being known for the specific technologies I am already familiar with. This piece of advice immediately affects how I think and how I will speak about future projects.

The second thought-provoking piece I read was how becoming an expert is a by-product of the long road I am on. This absolutely blew my mind but also humbled me because I should have known this already since I use a similar perspective for exercising in the gym. My goal of living a long and healthy life means that as a result I will have strong muscles if I am regularly going to the gym. I think one of the reasons this was so striking to me is because I feel like I have such a long way to go before I feel confident enough to call myself an expert in something. Therefore, hearing that becoming an expert is a by-product of the long road showed me how long this long road really is for me.

Lastly, there isn’t anything significant in this pattern that I disagree with. It was an enjoyable pattern to read and one where I learned some valuable information.

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

Malcolm Gladwell published a book about him analyzing how the practice has helped successful people succeed with the 10,000 hours rule. One of the sections in Apprenticeship Pattern Guide for Aspiring Software Craftsman ensures the similar point that practicing is an essential key in making a software engineer become better.
What I found interesting about this is the connection between some of the points in this section and Malcolm Gladwell’s in the “Outliers” are Malcolm shows that practicing was among the factors that led to the Beatle’s success and Bill Gates himself. These people had been able to manage practicing days and nights to the point that they were quite comfortable with the materials similar tools no matter what or where.
Taking the time to practice your craft without interruptions which means to the point where the mistakes are what we are comfortable with as it is mentioned in the Apprenticeship Pattern Guidance . I found it very interesting of how these two authors have the same perspective of spending more time practicing and confronting the problems. Ultimately at a critical time, we might run into those problems again, and being able to solve them would save us time and sources.
To be honest, I’m not a fan of lectures therefore sitting over a lecture in college is somewhat an achievement to me and I’m more like a hands-on person. Fortunately, that is one of the good ways to learn as a Software Engineer.As it was referred to in the book, a beginner should learn by doing rather than reading and sitting through lectures. Besides that, doing and repeating exercises helps us sharpen our skills, our minds, and our bodies to react to the disciplines. Another excellent point in this section that I found helpful is writing a lot and writing code often would help us develop neurons reactions in a good way.
Open to feedback is introduced in this section as well which I completely agree with. Being able to get feedback helps us determine whether we are on the right track. But part of me finds this odd because not everyone could get a good mentor and not everyone can give you good feedback. This also often is hard for people with small circle of relationships and connections. Relying on someone else feedback without knowing ours own issues is not a wise choice.
What I learned from this is finding an exercise and sticking with it until I could solve the problem on my own and then observing the solution that I have made over time as a programmer would have a measurable impact on my abilities to solve any problem later in my career.

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

This apprenticeship pattern discusses how software developers need to chart their own paths. It talks about how a software developer’s career is their responsibility, and they must take an active role in shaping it. The pattern notes that it’s not up to your employer, your career counselor, or your professors to decide what the next step is for you career. You should also not let company culture or expectations prevent you from achieving your goals. Only you can decide what is the right step and what is not.

To make progress in your career as a software developer, first you need to identify an ambitious but logical next step. Then once you have identified your next step, you need to come with up with smaller intermediate steps that will help you reach that next step. The pattern really emphasizes breaking things down. This is because the pattern notes that difference between doing things in a daydream and doing things in reality is the willingness to take that very important first step. The pattern recognizes that this could be a terrifying thing to do, and so breaking your goal into small bite sized, realistic, and achievable steps would help make taking this first step less daunting.

The pattern also highlights that there is no such thing as a single path or a perfect path to take. Everybody’s career map is different because everybody has different circumstances and values. Your own career path should be based on your own circumstances and values. You should be continuously reassessing your career map as your values and circumstances change. Sometimes this results in your career map aligning with those around you and sometimes it does not, and you must chart a new path.

I think this apprenticeship pattern can be summarized into three simple steps. First, search for and pick a logical but ambitious goal that advances you in your career, break down those goals into small and achievable tasks so you can turn it into reality, and finally make sure that you’re following your own path that’s based on your own values and circumstances. By following these steps, you will have a much easier time analyzing and identifying the next destinations on your career map as well as being able to do what’s necessary to turn your goals into reality.

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

Summary:

This apprenticeship pattern is concerned with a lack of familiar tools that a programmer has on his belt. It’s recommended that the apprentice become very skilled at five tools such that he does not need to read the documentation while also understanding the nooks and crannies of them. As time goes on, and he moves from job to job or project to project, become sufficiently familiar with the tools he learned. This does not mean that an apprentice that is good with these tools means it will be good for others or for the team.

This pattern is similar to the “Your first language” apprenticeship pattern, which states that it’s good to master your first language before moving on to a second language. I like this apprenticeship pattern because of its ideal of mastering and recording the tools that one learns. I also like the idea of trying to find better and more powerful tools available whilst the apprentice writes down the tools he is already familiar with. 

The pattern has somewhat changed my view on my intended profession. However, I don’t have a hardline goal about what my intended profession looks like, I’m completely fine with bending my skills and attitudes based on what my employer wants me to do, and what is required of me. If my team at a future company requires me to learn a new system that I’ve never used before, then that’s what I’ll do. Likewise, if they require me to use what I already know, then I’m also completely fine doing that as well. 

I’m not entirely sure if I fully agree with the fact that all of the tools that an apprentice will learn and be familiar with will become obsolete by the time he becomes a journeyman. What if a student / apprentice becomes very familiar with Java and eventually becomes employed as a software developer who utilizes Java? I know as time goes on, tools change and languages become favored or disfavored as the development landscape changes, but I am having a hard time agreeing with this statement. I know that a lot of different apprentices can have many different skills, many of which can me more useful than others, especially when taking into account what type of work they’ll likely be employed in.

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

The apprenticeship pattern I have chosen this week is the “breakable toys’ pattern which was very interesting to me. The pattern was about failure and how it is usually the best way to learn. There is a problem however when the place we are working in does not tolerate any failure and any such occurrence will have dire consequences. Here with the breakable toys pattern, we are allowed to make our own systems that are still relevant to our work. This way when we work with them and make mistakes, can can apply what we have learned to our workplaces without it hurting other people in the process.

This here is an interesting pattern to think about as so far, most students have been in a environment where mistakes are common and tolerated but later down the line, they will most likely face a much harsher environment than what they are used to including me. This means that later down the line, I will have to invest my time into these side projects in order to obtain failure and stimulate learning. There could even be one used in some of our current projects in which we could make some side projects in order to boost our learning. This also makes me wonder on the tolerance of different places on how much do they tolerate failure which is most likely very little which makes these breakable toys all the more important for one to use. Although that does make me think on whether or not the person would actually have the time to develop these programs. There is the chance that the work this person is working on is already very time consuming and that if their life was a bit too hectic with outside responsibility’s to actually make of any use of these toys in which this pattern might not be for them.

This pattern overall is a good one to learn on failure without it negatively affecting other people, especially if I were to go into professions that were high profile or had any basis in security in which failure is not an option.

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

In this apprenticeship pattern, it talks about the importance of practicing our coding skills and how we should practice. The section starts off by talking about how the reason why people make coding mistakes on the job is because they are practicing and learning the skill while they are doing it. A lot of programmers do not have the time to practice and learn the skill before they have to put the skill to use at their job and with the looming project deadlines that is why there are often so many mistakes made on the job. So, the first thing that the chapter talks about is the importance of finding time to practice coding skills on our own without any deadlines. Without deadlines, it removes the pressure of having to learn a skill before a certain date and we can learn at our own pace. In addition to making time to practice our coding skills, the section also talks about how we should allow time for criticism. This is because if we don’t, we may or may not pick up bad habits without knowing it. The last topic that the section talks about is the importance of not practicing so much that it becomes a permanent habit and that instead we should be careful on what we choose to practice.

I agree with this section and think that practicing is very important. I think this is something that I personally need to work on. Often after I learn a skill in class, I don’t touch that skill again until it is brought up again in another class and usually by then, I had let that skill become stale. Another thing that I agree with from this section is the importance of not practicing too much and that we should be careful of what we practice. I agree with this because I was guilty of letting this happen before. A while back when I was practicing coding with my cousin, we were both working on the same problem, and I coded it how I normally would. My cousin asked me why I was coding it that way and I told him that it was how I always coded it. Then he showed how he did it and his way was very different from how I did it. So, he showed that I was letting practice become permanent and that I was coding the same way whenever I see a similar problem. So, my cousin reminded me that there may be more than one way to solve a problem and that we should consider the best way.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

This pattern describes the benefits of maintaining a reading list of books on Computer Science. It suggests that you list of “Long Lived books” you have already read, as well as listing books you plan to read in the future. It reminds me of a number of books I have read that are essential reading for any developer. I have read “Code Complete”, “Writing Solid Code”, “The C Programming Language” by Kernigan and Richie, and a few others that are truly “Long Lived Books”. It is interesting that these books have stood the test of time in such a strong way, considering the accelerated progression of technologies. Most technical books and periodicals do not fall into this category. An example of this from my own experience is the plethora of books that appeared on the market when OLE, COM, and ATL became popular in the late 90’s. I bought at least 6 of these books, and they became obsolete rather quickly. As soon as a new release of these technologies occurred, a number of relatively poorly written books were pushed onto the market, having been written by authors who were more concerned with “time to market” than quality of information. Ultimately a “Best in Breed” book would appear, but this usually came out months after the release.

Your list should also contain books that you plan to read, sorted in order of importance to what you need to know currently, as well as those that you have discovered fit the category of long-lived books. Strongly favor the ones that have been recommended to you by mentors or peers but do your own research to find others. I have been helped over the years by periodicals. The better of them tended to have the better quality of writing at times of product release than most of the books being pushed at us. Some of my favorites are (were) MSDN Magazine, Microsoft Systems Journal, BYTE, Wired, PC magazine, and Computerworld. Keeping up with the mags was more helpful to my career than any of the books, with the exception of a dozen or so of them.

I kept a list of the books and magazines I had read I thought were important on my CV. This way, I was able to update my reading list whenever I was updating my resume. This kept the list fresh and up to date.

Now that we are exposed to audio books, blogs, podcasts, and YouTube videos, I tend to get most of my knowledge from them than from traditional books and periodicals, but the basic concepts of this pattern stand firm.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

For this week, I read a pattern called Nurture Your Passion. This pattern will occur when you work in an environment where you are exposed to hostile conditions, such as “demoralizing corporate hierarchies, project death marches, abusive managers, or cynical colleagues.” These conditions will sap all your time and your energy. If you do not have a proper way to against that negative energy and protect your passion, you will burn out after only a short time walking on your long road. Furthermore, you may not want to continue to walk on that long road anymore because you are exhausted and completely uninterested in your passion. To prevent that from happening, this pattern will provide you with some solutions to nurture and maintain your passion when you actually encounter those hostile conditions.

First of all, you need to work with yourself. You should find ways to grow your passion and enhance your knowledge over time, such as building some breakable toys to dig deeper, reading timeless books to open your eyes to a different world, joining a group to learn and share your knowledge, or drawing your own map to look for organizations that can offer you suitable career paths. Second, external factor is another important element that you need to care about to protect your passion. You should have a clear boundaries about the types of environment that you want to work in. You should be willing to say “No” or to refuse anything that might destroy your passion. One of your responsibilities as a software craftsmanship is to keep your passion strong, track on your improvement every day, and try to find a suitable environment to develop yourself.

In my opinion, the Nurture Your Passion pattern is one of the most essential pieces that apprentices should know to help them prepare mentally to avoid burn out in the face of hostile conditions. For myself, this pattern is very useful for my future career. I believe that in the process of going on a long road, there are many problems that will drag my passion down and at some point it will stop my progress. So, knowing this pattern in advance is one of the advantages that helps me avoid or eliminate most of the negative energy to protect my passion. As long as my passion remains, I can overcome anything that stands in the way of my progress and continue on my long road.

From the blog CS@Worcester – T's CSblog by tyahhhh and used with permission of the author. All other rights reserved by the author.