Category Archives: Week 6


Hello, and welcome to week six. I’m on spring break this week, so I will experience some activities like going to a resort or doing wild things for fun outside my comfort zone. However, I still need to complete the complex and lengthy tasks of studying and returning to school for some exams and schoolwork related. After finishing the fifth chapter, I’ll continue with the book’s sixth chapter. I read and picked what stuck with me was the reading selection “Dig Deeper.”

This pattern connected with me since it applies to everyone who has engaged themselves in a subject that might be thought-stimulating. Workers may want assistance with code maintenance and clarification of skill levels due to the issue of developers needing a basic understanding of the tools and methodologies. It can stand the resources and knowledge support while putting them above the creative process. One can prepare to support the time and effort necessary to read primary sources, comprehend ideas’ historical and cultural context, and practice what they have learned.

However, I can only partially agree with aspects of that technique; it provides a comprehensive understanding of software development features, which is essential when analyzing current open-source implementations. Together with a blog post, it has some gaps in the papers and articles.

Have you noticed that the practice has altered how you think about the work you want to do in the future or the overall career path you want to take?

Learning how to tackle and troubleshoot complicated problems, this activity can help me become a better problem-solver. Also, they can better pinpoint areas where deep thinking might enhance performance through code optimization. The practice can boost my self-confidence and capacity to produce value early with solid expertise in a particular field to take on new challenges and offer quick answers, such as finding pieces and enhancing the project. It can combine improved teamwork and communication by explaining challenging concepts and ideas to other team members and stockholders. Even more job opportunities to stand out, looking for developers with deep knowledge and the ability to provide expertise in specific industries.

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.

Falling Down the Deep End

I’ve always had this feeling of wanting to do more and challenge myself to reach the potential that I so desperately want to reach. In this pattern, the deep end is one that all aspiring craftsmen want to reach, and any apprentice or journeyman needs to gain that experience or take on a project that will finally take them to the next level. I know when I’m faced with a new challenge it can sometimes grow into fear because I’m not going to lie I have a really bad case of Atychiphobia, well it’s not that bad but failing in any task can put me down and so it’s easier for me to take an easier task when I can rather challenging myself in something that will benefit me in the long run. The most reassuring thing that’s even mentioned in the book itself is that when working in the field, taking risks will rarely result in destroying one’s career, especially when it comes to the IT world. So, reading this out loud makes me feel better about failing a task, no matter how I perform, I will still end up learning something in the end and I can take my failures in stride to create better solutions for the next big challenge.

Although taking some risks should be encouraged to take one to the next level, it is important to recognize whether the risk will pay off for the individual, it’s important to communicate with other people or a mentor and get their feedback on whether or not it’s wise to take on the risk and whether the benefits outweigh the disadvantages. The book will emphasize that if the risk and challenges seem to be too out of the ordinary then it’s important to create a “Feedback Loops” the options are laid in from of you when need be. And for me especially, I tend to fall back on this quite often when trying to make big decisions for myself. It’s also important to save yourself once taking the risk. As the book refers to it as “drowning”; being able to bounce back when things don’t work as the plan is important hence why the feedback loop is Important.


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.

What is the Abstract Factory Design Pattern?

Learning new design patterns can be interesting because, for the most part, it explores a new way of coding that I thought I would never have to use. This week I’ve been refactoring design patterns in my code, such as the Singleton pattern. The Singleton pattern is a design pattern that is supposed to restrict the instantiation of a class to one object. Basically, it’s used so that when that object is created then we don’t have to recreate that object. Recreating that object would wipe clear the information that you want that object to hold. That is where the Singleton Pattern shows up! But for now, I want to go over the Abstract Factory Design Pattern. The Abstract Factory Pattern is almost like the Factory Pattern but according to the blog “Abstract Factory Design Pattern in Java” published by Pankaj, the Abstract Factory Design is like a factory of factories.

If familiar with the factory design pattern, it uses a single Factory class, this factory class returns different subclasses based on the inputs provided and the factory classes use if-else or switch statements to find out the class it’s supposed to bring up. In the Abstract factory pattern, the if-else statement or switch statements are thrown out the window and instead, we have a factory class for each sub-class. And then we have an Abstract Factory class that will return the sub-class based on the input factory class. So the Abstract Factory uses multiple sub-classes of the factory class which is then implemented into a superclass which would be the abstract class.

The Abstract Factory will use a more interface and extension approach rather than implementation. In contrast to the factory method, all the subclasses are basically put into one class which would be the factory class, and that one factory class was the class to call if a subclass needed to be reached. Now we have all these classes that represent these subclasses that can be changed or coded to our liking. So it’s a lot more robust because we don’t have to be hammered down by conditional statements, but since we don’t really have that simplicity anymore, things do tend to be a lot more complicated. It’s a lot more complicated because of the many classes that can be involved in making a factory and plus the many specifics and ideas that have to go into those sub-factory classes I guess you could call it.

It would be really interesting to implement this in one of my projects. Right now I’m making modifications to a game called Minecraft, you might have heard of it, it’s a pretty popular game. It would be interesting to create an Abstract factory design for the many tools or blocks that I’ll be adding to the game. It might seem complicated but it could help me better organize the mod a lot better.

Link to Blog “Abstract Factory Design Pattern in Java” by Pankaj:

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

Accurate Self-Assessment: Be the worst – Blog # 6 

As a developer, I have always thought that “being a small fish in a big pond” rather than “a big fish in a small pond” was a great advantage for career advancement, both as a way to advance your knowledge, skills, salary, and position. I learned an incredible amount from other developers at EMC, Nuance, and Kodak, because these companies had teams where many of the engineers were brilliant and knowledgeable yet had no problem meeting with me to share information, and help with difficult design and debugging challenges. Although I usually obtained more from these teammates that I taught them, enough situations came up when I was helpful to them that they were happy to help me when I needed them.

I usually took the approach of only “bothering” them when I was really stuck on an issue. This had the benefit of making me fully understand the problem, and therefore taking less of their time. Before I would ask for a meeting on such an issue, I would take notes on what the problem was, and then write down a list of questions to ask. I found that some of the time, when I did this, I was able to get the answer on my own. Another interesting phenomenon would occur quite often. I would actually be able to come up with the answer to the problem on my own as I was going through the issue with them. I would then get a response like “See Joe, you already knew the answer. You just didn’t know you did”.

The whole concept of “sink or swim” is quite interesting. When working in a challenging environment, I was always more motivated to learn the skills necessary to produce solid code than when I was one of the more advanced team members. Since most of my career was as a consultant/contractor, sinking at a company was less problematic than when I was working as a corporate employee. The expectations of working as a consultant were usually higher. You were treated less as a team member by some also.

I found, though that I really liked both worlds. About a third of my career, I worked as an employee, and enjoyed the benefits of “being part of the team”, getting paid vacations, going to conferences for free, and the obvious sense of security. The other two thirds of my years in software either contracting as a 1099 or W2, or when I hung my own shield with my corporation “Twinstar Enterprises Inc”.

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

Breakable Toys

In breakable toys of Apprenticeship Patterns, the authors clarify that developers should have room for failure, and failure makes greatness. Good experience is built upon failure as much as success like in the saying “Rome was not built in a day” which means there is no overnight success. Mistakes are made, but learning from mistakes is a way to help us gather deeper knowledge and also aid us in collecting further experiences.
What was interesting in Breakable Toys was the close bridge between learning and failing. Failure is part of a software developer and without failure, there would not be a great developer as well as great software. What I agree is developers should be given space where they can seek out failure to train their mindset and to develop their practical involvement. The example was Steve Baker (a teenager working in Nova Scotia), people looked upon him as a leader and an expert within his small development organization. Thus, he could not afford to be wrong and obviously could not walk away from his people who were depending on him. The solution that he later found out was using a breakable toy. Breakable toys were the tools that he used to help him learn by failing.
What I have learned is that when implementing the breakable toys pattern, I should make the system relevant and useful to my life as an apprentice. The examples were building my projects such as a to-do list or expense tracker. At first, the solution would somehow be overengineered and failed. Yet, these are the type of projects that were designed to be backslid without any bothersome. They are used to develop my ideas and techniques and could be a disaster but that is a part of learning. By building these projects, they give me a deeper understanding of designs, data structure, and language. Furthermore, not giving up on problems would help me eventually get them right. Beyond constructing things myself, consider team efforts as one of the alternative ways of learning.
The point that the authors try to make in this chapter is by building things will help developers learn better than listening to plain lectures. Allowing space for failures is a way of improving and expanding knowledge as well as experimenting to learn deeper and to understand thoroughly.

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

Expose Your Ignorance

The apprenticeship pattern Expose Your Ignorance is about the importance of feeling comfortable with showing your ignorance. Asking questions is how you learn and shows that you are good at understanding. The difference between an expert and a craftsman is someone who broadens their range of knowledge rather than only sticking to digging deeper into a single domain. The action the author recommends is to write down your

The quote included in this pattern from David H. Hoover was thought-provoking. “I actually had grown attached to feeling ignorant on a daily basis; it let me know I was in the right place. I was growing.” The quote reminded me of the Daoist view of yin-yang where on one side there is chaos and on the other side, there is order. To grow as an individual, you need to be in the middle of the two. As Hoover’s quote says, feeling ignorant means that you’re exposing yourself to new material and are learning. If you never feel challenged, then you are not doing anything new and therefore not gaining new experiences. If you are uncomfortable with feeling the unknown, then it means you are uncomfortable exposing yourself to new things.

This pattern made me realize it is not only okay to be in the presence of the unknown but that it is also necessary for personal development. Personally, I do not act as if I know everything or that my solution is always the best option. I make what I know heard but leave plenty of room for others’ opinions. There are times when what I recommended is ignored and then later those recommendations are then incorporated into the project. It is better for that to happen naturally than for me to force my ideas into the project without the full acceptance of the other people involved. I do not disagree with anything in this pattern, I agree with the author fully on his opinion.

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

Draw Your Own Map

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.

“Familiar Tools” Apprenticeship Pattern


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.

Breakable toys – Apprenticeship patterns

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.

Apprenticeship Pattern “Practice, Practice, Practice”

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.