Category Archives: Week 5

Exposing The Ignorance?

Exposing ignorance is apart of the learning process, and assuming that the person that this pattern is for is a apprentice, it’s safe to assume that having ignorance is apart of the learning process. What I disagree on when it comes to this pattern specifically is that it is hard to imagine that if your an apprentice, it would be hard to be in a situation where the fellow co-workers or employee assume that you have everything under control, that’s if the pattern in context is being aimed at apprentices. In my opinion, this pattern seems to be more for the journeyman if anything. A position where a person has the experience of a craftsman, but doesn’t know everything about the craft or like the author mentions, they will mistaken expertise for good craftsman, which seems to be two different things.

Although, what I do like about the pattern is that the author emphasizes that learning how to do something isn’t enough- its about how one learns the task that is more important than anything really. In his quotes alone the author explains that “Expertise is a by product of the long road we’re on all on, but it is not the destination.” This make me have a different perspective of the learning process, it can be a tough road, but that seems to be the point. Many times I tend to find shortcuts of how I can get something done faster because, like anyone, it’s relief to know that something is completed and out of the way, but I never end up truly understanding the task. Sometimes getting things done faster and without obtaining substance is a good thing, and needs to be done with good reason, and with that being said if I’m in a situation where I have to get something done, then afterwards I’ll spend some of my free time trying to fully understand it. Learning how to fully take advantage of the learning process is how one becomes a good craftsman.


Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

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

Apprentice Pattern: Expose Your Ignorance

This week I continued with chapter 2 of Apprenticeship Patterns once again. The pattern I read was Expose your Ignorance. The context this pattern gives is the people paying you to be a software developer are depending on you to know what you’re doing. The problem with this is your team members and manager need confidence that you can deliver but you are unfamiliar with some of the technologies.

The solution to this problem is to show the people depending on you that the learning process is part of delivering software and to let them see you grow. Software developers build strong relationships with clients and colleagues so telling the truth about being in the learning process instead of telling them that you know how to do something you don’t is important. Doing this will build your reputation on your ability to learn and not what you already know. Asking questions is a good way of exposing your ignorance. Those who do not take on the process of exposing ignorance become experts in one domain and develop a narrow focus that is important for the industry to have experts but it should not be the goal of an apprentice. 

The action suggestion is to write a list of five things you don’t understand about your work. Put the list somewhere others can see it. Then get in the habit of refreshing this list as your work changes.

The reason I chose this pattern is that I am expecting to run into this situation when I get my first job as a software developer and will probably face this problem during my whole career because there will always be some new technology I do not understand. I found the solution given to make sense and it brought up some good ideas but the action plan I disagree with a bit. I think it is a good idea to list off things that need to be worked on but I don’t think it needs to go in a place others can see. As long as the list is refreshed frequently and the skills are being worked on I think it’s fine to keep it to yourself. Of course, the part about being honest with others about not understanding things and asking questions should still apply.

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


I want to say hello in the fifth week of my blog and write a new entry. March is my favorite month, so I’ve enjoyed myself as much as possible. In Boston, there are many things to do, including drinking and attending social and entertaining events simultaneously. I have an upcoming spring break relatively soon. It will be enjoyable to go over everything and take care of tasks in preparation for the impending graduation from college.

Now that I’ve finished the information presented in chapter 4, I will go on to the fifth chapter, which is about ongoing education. Throughout my research, I encountered an important theme: “Reflect As You Work.

This pattern appeals to me since it is relatable to anyone who puts in the effort and gets things done; that way, people may reflect on what they’ve learned and how they’ve improved. This pattern appeals to me since regular introspection and questioning of one’s practices are vital to preparing for elevation to senior posts. Regular introspection and questioning of one’s courses are something I do. Even with explicit reflection and noting changes in one’s set of methods, it is possible to develop fresh ideas by observing more experienced developers and reflecting on their rules.

But, I disagree with other components of the practice by not believing that experience automatically equates to expertise; becoming proficient should be the aim.
On the other hand, it is possible to urge individuals to sketch out a Personal Practices design to investigate and challenge existing practices and contemplate the possibility of adopting alternative methods of accomplishing goals.

Have you noticed that the way you think about the work you want to do in the future or the career path you want to take as a whole has changed due to the practice?

In engaging in the “Reflect As You Work” exercise, I can get insight into the things I have accomplished, the shifts I have made, and the areas where there is room for improvement and enhanced quality of life. When it comes to employing this strategy sets the stage for my future profession, as it will allow me to save some time and avoid some hassle while also providing me with a fresh learning experience that I can share with others who face the same challenge.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.


While looking through my blogs, I came across a familiar acronym that I used all the time when it comes to developing software and system. The acronym is called “YAGNI”, which stands for “You Ain’t Gonna Need It” according to the blog “Automation Principles – YAGNI/Premature Optimization, It’s the principle of extreme programming that states a programmer should not add functionality until deemed necessary. The blog takes about how many engineers will spend multiple hours trying to build the “right system” the first time. In some cases, trying to build a flawless system in the first go can be rather difficult to achieve. The problem is that programmers spend too much time worrying about efficiency in the wrong places and having that premature optimization can cause more harm than good. The blog goes over Big- O notation which explains that it does not care about constants but the long-term growth rate of functions. This is a good rule to consider because having to introduce something before a fraction of the code is even written can make a program a lot more difficult to support as explained, it would increase design considerations, the likelihood of race condition, and the ability to troubleshoot. Optimizing certain processes might not lead to any time savings or real optimization. In fact, it could do the exact opposite, a good example that the blog states are when using Python, constructing lambdas and list comprehensions over simple for loops. The blogger has mentioned that in his personal experience he would add non-functional requirements, such as authentication and logging, too early, adding features before needed. With that being said, I remember spending so much time on adding the ability to connect my bank to my finance application, that I didn’t have the time to code the application itself. The blogger talks about network automation which explains more about how networking is all about speed and not creating YAGNI isn’t really in the cards. They would go into detail about real-world examples when it comes to the network automation process, explaining issues about multithreading, in which he explains that overloading the TACACS server with too many requests at once is very problematic, or scaling wide too fast can cause processes to slow down and too much resource utilization, overall, it’s very inefficient. Configuration Generation takes too long and is very inefficient, and with all these in mind, the blogger isn’t trying to not consider tomorrow’s problems but is more in line with building things up as they go.

“Automation Principles – YAGNI / Premature Optimizations” :

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

Use the Source: Blog # 5

This pattern explains the benefits of reading real world source code. If you are on an assignment and are asked to write a small component for the project, your most important task should be to read through the code-base and understand as much of the source code as possible, given the time constraints you are under. It is important for you to understand the intent of the application at a high level before studying the code, but then to immerse yourself in how the code works, how it is structured, what design patterns are used, how the class hierarchy work, and which developers were involved in the project. In most cases, it would be a mistake to try to learn all the project’s code, unless it were quite small. Consider understanding the code involved most closely to your intended assignment with the most priority. Most projects you will encounter are medium to large scale applications, and some would take you months to adequately understand.

Try meeting with the developer who wrote code most similar to what you are being assigned , and ask for tips and tricks on methods they used to build their pieces.

If you are asked to write, for example, an android activity that calls REST API’s, look for related YouTube videos, Google documentation, related code on GitLab or GitHub, textbooks, posts, and college library references, but most importantly, look directly at the code-base you are working with to find if similar code has been written which can be cloned, modified, and sometimes improved. I have worked on projects where the same basic code had been written more than once! Refactoring an application to remove repeated code, or to consolidated similar code is a huge time saver. There is nothing like management giving you a month to write something, and you come back in two days with it done. This is the type of “magic” you can accomplish if you are observant of the resources that already exist in your project, and the Open-Source world in general.

I also think it is important to read through code you have previously written. If you have resume entries stating you know a particular language or technology, a more than rudimentary understanding of it is really important for your next review or interview. As your career develops, the list of these items will increase, and some will become somewhat obsolete, so it is much more important to understand the most recent skills best. If you can’t recite a paragraph or two on any given entry, I would consider removing it from your resume.

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

Post # 4 – Construct your Curriculum – Make a reading list 

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.

Reflection on the Record What You Learn Apprenticeship Pattern

This apprenticeship pattern encourages apprentices to record what they are learning, in either a public or private place (or both). Either in a blog or wiki or even just a personal journal. Each has its pros and cons, but in each instance, they allow you to look back and reflect on what you have learned, what you were having trouble with and can give you a map of where you have come from.

While I was reading this pattern, I couldn’t help but think of this blog itself. While at the beginning I thought of this as something I would only ever use for class, I can see myself updating it in the future to be a far more professional blog space where I can record my experiences in my professional career. Even in the past year, I have found myself checking old blog posts about other patterns I read about to form connections between them. Like the Breakable Toy pattern, where I talked about starting a wiki being a good idea. That feeds right back into this pattern, already showing its effectiveness as a tool.

I never really thought about writing being a part of this field, but as someone with an innate interest in writing, and who has gone so far as to minor in it, I am really excited to see that this is a larger part of the lifestyle of other software developers. I hope to be able to continue writing, either professionally or as just a part of my own journey to mastery of the craft. It is something that has always been a big part of my life and being able to do it in conjunction with software development is really important to me. I think that this is as good an outlet as any for that seemingly unrelated skillset.

I don’t think I disagree with any part of this pattern really. I guess if I had to pick something it would be uploading it for everyone, but even then I think that way of doing it has some value, I just think you should have something private as well. Overall, it’s a fairly straightforward pattern and aligns with what I enjoy doing anyway. I’ve been looking into using Obsidion as a wiki-creation software, and I think that it has potential for this sort of activity. Clearly, this is a fairly common practice within the industry and I hope I will be able to find the motivation to keep up with it as my career goes on.

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

“Breakable Toys” Apprenticeship Pattern


This apprenticeship pattern deals with a software developer that cannot afford to learn by failure. This software developer may work at a company that must get things correct, and thus cannot experiment and learn from his mistakes. Thus, this pattern recommends the developer to create his version of his work’s program in private, to experiment so he can learn.

I want to say off the bat that I do not disagree with anything stated in this pattern. In fact, the most I’ve learned has been from practicing and failing repeatedly, so I strongly believe that this is a very important pattern for all developers.

This pattern has helped me greatly in my understanding of development. For example, in one of my homework assignments that required me to implement an algorithm that sorts operating system “jobs” by time to process, I wanted to use what is called a “MultiMap”, that is to say, a Hash Map that allows duplicate keys that could then be sorted, by key or by value. After this assignment, I spent hours trying to figure out its implementation, and I eventually figured it out. By following this pattern, I was able to figure out more about Java types, and I taught myself how to use hashing algorithms. 

I find this apprenticeship pattern very interesting. I bring the above example up because what I find interesting about this apprenticeship pattern is that I never thought to apply it to my work projects. There is a lot of information that I’m learning about when I’m working outside of school, and this pattern has indeed changed the way I think about how I will work and what my profession will steer me towards, and vice versa. 

I will try to create a private project with homework or work in which I implement the project differently, and try to see if I come up with any valuable results. There are many things I’ve learned from applying this principle to a few homework assignments or free time projects, but I can feel that this would be very beneficial in trying this with new systems, or alternate pre-existing ones from school or work.

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.

Retreat into competence

The context of this pattern is that when you realize how little you know, when you get out of your comfort zone and try new things. I think everyone who has done programming has gone through this problem. When you are writing code, nothing works on the first try then you try again the next day, and it still does not work the way you want it to be, at that time you feel like you don’t know anything at all. Then after a couple tries, the solution starts to come to you and everything starts to make sense, then you connect every idea and make it work. Just when you feel like you know everything and move to the new issue/project then the cycle repeats, once again you are introduced to the vast reaches of your ignorance, and you are overwhelmed.

The solution to such problem is to take a step back to jump two steps forward like a slingshot in carnivals. As the pattern says apprenticeship is a roller coaster ride as you thrive to learn new technologies, leveraging your knowledge and creativity to deliver value to your customers but if you compare yourself to someone who knows more than you or is an expert in the field then you will feel terror of perceiving just how little you know of things. A pattern like this is relevant to people (such as myself) who have pushed themselves beyond their ability, where they are constantly trying to learn new things, one after another, and there will be a time when this pattern kicks in. When such things happen, you retreat back to your competence to regain your composure. Take some time to build something that you already know how to build then use that experience to recognize how far you have come, then use that recognition to boost your confidence. For example, pick something self-contained that you know really well and reimplement it to remind yourself of your own capabilities. There is also a way to prevent from overwhelming, you can accept that his pattern is only a short time fix. You can set yourself a time limit. For example, I will refactor this code for half an hour before I jump into making another function or adding another feature.

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

Confront Your Ignorance

Continuing from last week, “Confront Your Ignorance” is also the next section in the book where I find some similar patterns to my current state with the context of identifying gaps in my skill set.

According to what was written

“There are tools and techniques that you need to master, but you do not know how to begin. Some of these are things that everyone around you already seems to know, and there is an expectation that you already have this knowledge”. 

The only difference is not everyone around me seems to know it, except the YouTube algorithm, but I should meet the team’s “expectation” to have my part working on time. The situation can be described as I currently have a sample to refer to my work, but I do not want to abuse it because if I do so, I learn nothing from it. It feels like I can understand everything in the sample, I’m still curious on how it was done and since the programming language is too versatile, is there other way that I can do it without “copying” the sample?! Since the sample has a good structure and is written in a comprehensive manner, I would happily learn it, but the code, I don’t think I can write it that good just by looking at the documentation.

I consider myself a competitive person and sometimes my curiosity makes me feel unsatisfied in many cases. I always want to be as good as that “person” in a particular situation and when I can’t, the feeling is quite uncomfortable. Hence, I think my biggest ignorance is trying to achieve too many things but not concentrating on a certain topic. A solution was given in the book, it’s also obviously the only way for me to get rid of my bad habit, which is to strive to learn each one, maybe in important order.

In conclusion, I think it’s not bad at all to have so many interests at the same time, but I should figure out which one I should prioritize learning it first. Back to my current problem, I think I would go over the commit history to see how it was initially done and proceed from there.

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