Category Archives: Week 5


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.

Craftsmanship Log #3 – Practice, Practice, Practice

               Many of us have heard or said the phrases “Practice makes perfect” and “Repetition is the mother of all learning.” Though I personally can neither define perfection nor learning, I can say that no one can gain expertise off anything they see once and never apply again in their lives. Even though we may understand a new concept that we learn at first glance, it is when we repeatedly work on it hands on that we can truly experience the nuances that are introduced. Continuous practice is known to help considerably during the learning process, as one works to internalize the knowledge that has been introduced to them. This is also a pattern introduced in the book “Apprenticeship Patterns” by the name “Practice, Practice, Practice”. Though the name of this pattern is rather straightforward, it is important to emphasize what makes this pattern and important component of the learning process.

               Simply put, “Practice, Practice, Practice” is a pattern that is meant to address an apprentice’s potential hurdles that may stem from neglecting to practice their craft hands on and on a frequent basis. As such, apprentices may not have a proper understanding of where their strengths and weaknesses lie, thus their learning reaches a point of stagnation. However, if an apprentice only takes the time to practice what they learn in a work environment, they may end up hindering their own growth since they add the stress of having no room for error on top of learning something new. As a solution to this hurdle, apprentices are advised to find exercises to practice on at their own time and pace and in an environment that treats any mistakes that come up as opportunities for learning rather than signs of imminent disaster. That way, an apprentice can take the time to properly learn and improve their craft. What may also help is communicating with experienced people that can point out any habits that may be counterproductive in one’s learning and provide the appropriate feedback that an apprentice may need.

               With that being said, I want to point out that I have not mentioned the words “programmer” or “developer” when discussing this pattern, even though I believe it is by far, in my own experience, the most crucial pattern stated in this book.  In fact, I personally try to get my peers, as well the people I help at my job, to espouse this pattern and incorporate it into their own learning process. Though I disagree with the notion that “practice makes perfect”, I wholeheartedly believe that actively practicing new knowledge in an environment that allows mistakes can do more to help an apprentice learn in the long run.

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

Be The Worst

Be the worst is an apprenticeship pattern from chapter four that focuses on surrounding yourself with people who are better than you in order to constantly keep improving yourself. The chapter argues that if you are the best in your respective group then you will not grow and improve as a person.

I whole heatedly agree with a majority of the points made in this apprenticeship pattern. From personal experience alone I know that this idea holds true. While in a classroom environment I am definitely not the best, but I am also not the worst. I tend to work with people at a similar skill level to me when I work on group assignments or in class work. While I still learn things in these environments, I know that I miss out on more nuanced knowledge that’s gained by experience. In an environment where most if not everyone is better than me, I could learn things from people that I would most likely not learn in a classroom environment. During my internship I was surrounded by talented programmers, and as such I was taught many different tips, tricks, and skills that I probably would not have otherwise learned.

Another thing I really resonated with in this pattern is the fear that being the worst in the team will result in lower overall performance or cause me to hold others back. This idea is daunting, but it also lights a fire under me and forces me to improve in order to keep up. One thing I do not necessarily agree with is the statement that joining a team as the worst member is selfish. I do not thing that is true, as long as you join that team with the intention of working harder than everyone else to keep up and improve. The team also may benefit from you joining, since because you may be inexperienced, you can potentially learn new ideas quickly and the team may be able to mold you to their needs as a result. This can be a win-win for everyone, you continue to improve yourself while the team gets to mold you to their needs.

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

Apprenticeship Pattern “Concrete Skills”

This apprenticeship describes how even though we may be knowledgeable software engineers, the knowledge we possess may not be enough to convince others to work with us. Instead, we need to show that we have the ability to apply this knowledge in the creation of software applications. Teams most of the time don’t have the luxury to hire someone who can’t contribute to their workload. It is up to us to convince them that we can demonstrate our skill practically in the workplace. It will be beneficial to us if we are able to display our skills in being able to build in various languages and frameworks. As new graduates, when being picked by hiring managers, they are taking a risk on us and our ability in our concrete skills is what should give them confidence in being able to contribute to the team on day one.

What I’ve taken from this is that I need to contribute more time into honing my concrete skills to be able to show others who take a risk on me that I am in practice and that I am capable of providing for my team instead of being a hinderance. Being able to show that I am able to use my understanding of the knowledge I already possess and translating that into other aspects of software engineering is what I should be striving to do. They also explain that what I’ve done in past shouldn’t be overlooked and that the softer skill that I have attained really are bigger than what they seem, and that these skills themselves also help contribute to being a better software engineer in the workplace.

This apprenticeship pattern reminds me that being able to be hired by a company is a testament to my ability and not just being a graduate. In order for companies to trust me, I need to show them that I can use my skills to help the team and not rely on others to help jump start my progression. This pattern also reminds me that the skills that I have acquired in the early parts of my life should not be downplayed. They do provide others that I am capable of many different things and that they can translate to many parts of my job at the workplace. I normally tend to shy away from my accomplishments from other jobs because they’re not software related, but after reading this pattern, it gives me more confidence in being able to embrace those previous accomplishments and use them to my advantage.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.