There is currently nothing that reigns truer than the “Learn How You Fail” pattern in the Apprenticeship Patterns. Essentially this chapter identifies the role in which failure plays in your career development. I have often heard that failure is not something to be feared but instead embraced and this chapter mirrors that same sentiment. It offers the idea that if someone has not failed then they have actually “avoided pushing the boundaries of their abilities”.

I think this idea heavily resonates with me. I’ve learned that I need to look upon what I am doing with a realistic lens and to be able to recognize the truth in my actions and decisions. The more objectively I can view things the greater the ceiling for growth and further expand the boundaries of my abilities. The chapter puts it as “the goal is to gain self-knowledge about the patterns, conditions, habits, and behaviors that lead you to failure”.

I think that one of the major things that is hampering my success is procrastination.

For a long time, I have been “wallowing in self-pity” from the consequences of my procrastination. There has been a bit of a perspective change as of late that allows me to recognize my strengths through an accurate self-assessment all in an effort to remove the focus on the self-pity and shift it to self-improvement.

I find that from my procrastination I’ve learned how to handle my own self sabotaging self. I have seen that it is something I can improve on as I find myself having instances of being proactive, so I know that it is something that I am capable of overcoming. With consistent effort I can see myself overcoming this barrier to achieve whatever it is I want to achieve. From all my criticization of the education system it wouldn’t be without this system that has allowed me to recognize my strengths and abilities and has enabled me to look upon my weaknesses not as an impossible barrier but as something that I can overcome and climb. On the other hand, even though I can recognize this pattern within myself I learned that nothing is going to be accomplished without a disproportionate amount of time, so that is why it’s going to take consistent effort and not all be accomplished within a day. This kind of self-assessment seems very valuable and is something I actively believe I can improve on and may even somehow adopt as a core value.

From the blog CS@Worcester – Sovibol's Glass Case by Sovibol Keo and used with permission of the author. All other rights reserved by the author.

With the breakable toys pattern, the learner conducts experiments and observes the work of others to improve their own understanding of how to build complex systems. Apprenticeship Patterns suggests a few ways to go about this. You might build a simplification of an existing problem that you’re already facing. By reducing uncontrollable variables or emulating a single possible case, you can come to understand one key interaction, tool, or data flow at a time until you become capable of composing a solution to a broader problem.

Another possibility is building your own projects that are not focused on understanding one specific issue you are already facing. Doing so can build a familiarity with your tools, and can lead to unexpected creativity or interest in learning how others achieved problems you might never have otherwise encountered.

The third variant of this pattern is the analysis of external source code. The abundance of open-source projects provides an effectively infinite learning resource for studying how others design systems and resolve issues.

I think that this pattern is a very important part of long-term learning. It can be easy to build habits when programming: you can usually come to a desirable result either by brute-force trial and error from the bottom up, or by drawn-out requirements planning that gets done before any prototype is built. But I’ve found myself spending far more time invested in one of these two methods than I should have, when remaining flexible and incorporating aspects of the other would have led me to a better solution faster.

In general, I think it’s a shame how often the daily work of software development can feel detached from the playful curiosity of the scientific method. Much of the most rewarding learning happens as a result of developing a question and finding a finding out how you can reach a confident answer to it. Considering we’re working in the one field where rapid iteration and near-zero cost to entry makes the scientific method universally accessible, I’d like to hope I’d take advantage of that by putting myself in many situations that generate spontaneous curiosity.

That’s what I like about making a breakable toy. It’s usually more fun to play with than the projects that we have real responsibility for, and that fun makes us want to understand everything about the toy and how the toy could grow into something else.

From the blog CS@Worcester – Tasteful Glues by tastefulglues and used with permission of the author. All other rights reserved by the author.

Greetings! I recently stumbled upon an intriguing concept called “Expose Your Ignorance,” which originates from the book “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. This pattern advocates for individuals to openly acknowledge and address their knowledge gaps by seeking assistance from mentors, peers, or experts. Personally, I found this pattern to be quite relevant and valuable, as I frequently encounter scenarios where I need to acquire new knowledge. I appreciated how this pattern emphasized the importance of seeking feedback and assistance to cultivate both personal and professional development.

What I found intriguing about this pattern is its emphasis on recognizing the strength in admitting ignorance or not knowing something. In the past, I have been guilty of feigning knowledge to avoid appearing foolish or incompetent. However, this pattern advocates for the opposite approach, highlighting the benefits of being forthright about one’s limitations. By doing so, individuals can receive constructive feedback and foster personal growth. Furthermore, this pattern places significant importance on seeking guidance from others, which can be a daunting task, particularly for those who are just starting out. Nevertheless, reaching out for help is a crucial step towards expediting the learning process and avoiding potential mistakes. The pattern emphasizes that seeking assistance should not be viewed as a weakness, but rather as a strength. By doing so, individuals demonstrate their eagerness to learn and advance. I believe that the Expose Your Ignorance pattern offers significant advantages for personal and professional development. It encourages individuals to be transparent about their knowledge gaps and seek assistance, leading to more rapid growth and learning. This pattern has significantly impacted my outlook on my profession, as it has taught me to embrace my limitations and seek help when necessary. I believe that anyone looking to enhance their skills would benefit from adopting this pattern.

In summary, I strongly suggest reading the book “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” and implementing the Expose Your Ignorance pattern. This approach can help expedite your progress and advancement, whether you’re a software developer or working in any other field. By acknowledging your limitations and seeking help, you can foster personal and professional growth.

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

Hello and welcome back to another week of my blog. This week, I looked through chapter 2 of the book Apprenticeship Patterns by Dave Hoover named “Emptying The Cup” and took interest in the apprenticeship pattern called “The Deep End.” This pattern is about pushing yourself out of your comfort zone and taking on challenging tasks that are outside of your current skill set. The best way to learn is by doing, and that taking on tasks that are beyond your current abilities can help you grow and develop new skills. The pattern advises that when you are in the “deep end,” it’s important to ask questions and seek help from more experienced colleagues. It’s also important to break down your tasks into smaller, more manageable pieces and to focus on making small incremental progress over time. The benefits of taking on tasks in the “deep end” include accelerated learning, increased confidence, and the opportunity to demonstrate your abilities and potential to your colleagues and mentors.

As a computer science apprentice, it can be scary to go into the “deep end” since you may think you would be a totally lost person working with experienced people. But I have experienced the deep end myself many times in my everyday hobby, video games. This seems to happen the most especially in competitive video games, when you play with people who are more skilled than you, you start to pick up on the many small helpful habits highly skilled players tend to do. The skilled players don’t need to think about the small habits because they have already mastered them and do them out of muscle memory. The same can be said for computer science apprentices. For a scenario, think about working on a difficult project with more experienced people in the field. You may look like a small fry with not that much experience compared to the others, but this is actually a fantastic opportunity to observe your team members and pay attention to small things and habits like their thought process for example. As you focus on the small habits, you also start to copy those habits and incorporate them into your work as well. This would also be a great opportunity to ask questions if you are confused about anything. I will for sure start diving into the deep end if I find any opportunities to since it will strengthen my skills as a computer science major.

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

The pattern I chose for the blog was the first one titled, “Your First Language”. The pattern is about the process of starting off learning your first programming language and how to progress past that. The solution was to pick one language and spend a couple of years learning it to become fluent. The pattern then went on to mention that  it can be hard to pick just one, and gave some tips on how to choose.

I thought the pattern was great because so many people have trouble trying to decide on what their first programming language to learn should be, and this really does help lay a great groundwork for what they should be doing now in the beginning. The pattern even helps with deciding which language to start learning first, by weighing the options with you. I did not feel like this pattern was not really for me to learn as I have already gone through this process in my first years of college, and am past this point in my learning by now. I feel like this pattern is perfect for somebody just starting their first year as a computer science major in this school, and could really help them pick out what they should be doing.

I definitely agree with the advice given as instead of trying to learn multiple languages at once, new people should really try to become proficient in one language, and that in turn will make learning new languages easier. This is due to the fact that starting your first language requires more time to learn the basics of what to do with the language, while with all the languages afterwards, it is sort of like translating what you already know most of the time. I think people new to programming really need to take this advice, and they will be set on the road to success.

This pattern was about how to start off learning your first programming language, and how to decide which language to learn. It did not teach me much as a computer science senior, but I feel like it would really help people in their freshman year. This was a great first pattern to read, and I can not wait to see what I can learn from the ones coming up after this.

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

The Principle of Least knowledge also called the law of Demeter, as explained in Eric Feminella’s blog “Principle of Least Knowledge”, is a design principle that provides guidelines for designing a system with minimal dependencies.  It is summarized in short as “Only talk to your immediate friends.”

A client should have knowledge of an object’s member, and not have access to properties and methods of other objects via the members.

The example shown in the blog has three classes: ClassA, ClassB, and ClassC. ClassA has an instance member of type ClassB and ClassB has an instance member of type ClassC. This shows that all the classes are connected one by one, and this can be extended further ClassC if need be. Now believe it or not this example violates The Principle of Least Knowledge because it creates multiple dependencies, thus reducing the maintainability because if ClassA needs some work so would all the instances of ClassA. This creates like a domino effect and keeping up with the client could pose some trouble.

Now, like the blog explains, in software development there might be some trade-offs. If the program runs better optimally with the above method, then maintenance might need to be pushed aside for just that. But it’s an important goal for the software developer to minimize dependencies, and by following guidelines provided by The Principle of Least Knowledge this becomes much easier to accomplish.

The Principle of Least knowledge is very important when it comes to coding because when it comes to programming a client itself, it becomes very easy to callback other dependencies to make things easier. But this creates more classes that, in a before blog would be referred to as “master classes” and more redundant code is created, and other dependencies are brought into the mix.

In code it seems like it’s better off if some classes don’t know the inner working of their other class, I’ve seen many programs break entirely because of one class. These classes are dependent of other classes. When one class falls all the other classes fall with it. So, It’s important to implement these dependencies so that they can be changed easily. And it’s also remembered to implement in such a way that they don’t require these chains of dependencies involved. All in all, it’s best to create a program that easy to modify and refactor so that the code is easy to work with in future development.

Link to Blog: http://www.ericfeminella.com/blog/2008/02/02/principle-of-least-knowledge/

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

Refactoring is an important concept in software development that refers to the process of modifying and improving the internal structure of existing code without changing its external behavior. This can be a useful technique for improving the readability, maintainability, and performance of a codebase, and it is often an essential part of the software development process.

There are many reasons why a developer might choose to refactor their code. One common reason is to improve the readability and understandability of the code. Over time, as a codebase grows and evolves, it can become difficult to understand and maintain. Refactoring can help to clean up the code and make it more organized and easier to read. Another reason to refactor code is to improve its maintainability. As a codebase grows and changes, it can become more difficult to make updates and modifications without introducing bugs or breaking existing functionality. Refactoring can help to make the code more modular and flexible, which can make it easier to make changes and updates without breaking the code. Refactoring can also be used to improve the performance of a codebase. As code is written and optimized, it can sometimes become inefficient or slow. Refactoring can help to identify and remove bottlenecks, and to optimize the code for better performance.

I chose this blog post on refactoring because it is a crucial concept in the field of computer science. As I read through the post, I found it to be very informative and well-written. The post clearly explained what refactoring is and described the various benefits it offers, such as improving readability, maintainability, and performance. I found the discussion of different techniques for refactoring code particularly interesting. Techniques like extracting methods or functions, renaming variables and functions, and restructuring code can all be effective ways to make code more modular, readable, and maintainable. I also appreciated the emphasis on maintaining the external behavior of the code during refactoring. This is something I will keep in mind as I continue to learn software development. Although refactoring wasn’t required in this class, I plan to use what I learned on future projects and when working with others on a team. I will refer to this resource as I continue to improve my skills and knowledge in the field.

Source:

https://maddevs.io/blog/code-refactoring/

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

The Blog I read this week focusses on the the different Types of software architecture that we had discussed in previous classes as well as the different situations that these different patterns are useful and for what type of situation they would be ideal for. One of the important ones discussed and the most interesting ones that applies to my everyday life is the client server pattern.

In this pattern a central server offers one or more services are offered to one or more clients, allowing for all of the work to be done at the central server while all of the users can use the Data independently. This is very relevant for the world at large as many of the sites that we use on a day to day basis use this type of pattern such as twitter, where the Application provided the under interface for the user and the servers to interact. this type of pattern is used for many different applications we use today such as facebook and many other types of social media, where the user takes the information from the server and the selections made on the users side will then be sent to the server and update the information on that side of it. it is interesting how our small interaction impacts the overall system as a whole and how the entire process occurs for something so simple as updating your twitter bio.

Another pattern discussed in the blog is the layers pattern, which we discussed in both classes related to Cohesion as well as design patterns. it is described as the most widely used and promotes low coupling and high cohesion, much of what we discussed before hand in class is gone over such is how it is utilized for the most part smaller projects with different teams working on different parts of the project in parallel with other departments in order to keep the system active for users as well as allowing for updates to be spit out more often without shutting down the rest of the system. this was an important aspect of release principles as allowing for these releases to happen frequently in order to push updates to users as often as possible while other developments were also in progressed proved beneficial to the user but strained the developers, with the different teams it allows for less stress on devs to release patches or updates in select parts of the projects.

O, Williams. “Fundamental Software Architectural Patterns.” Medium, Medium, 14 June 2022, https://medium.com/@liams_o/fundamental-software-architectural-patterns-663440c5f9a5.

From the blog cs@worcester – Marels Blog by mbeqo and used with permission of the author. All other rights reserved by the author.

For this week, I chose to read the pattern ‘Create Feedback Loops’ from Chapter 5: Perpetual Learning. The name is pretty self explanatory as to what the pattern will be on, finding feedback on your progress. I chose this pattern because chapter 5 had the best info to digest, in my opinion, because I’m at that stage in my software craftsman career that where these patterns are the most relatable to me and will only prove to be more useful to me as time goes on. The context for this pattern is, not being able to tell if you’re unaware of how unskilled you actually are. By being unaware of your skill level, you are worse at assessing your own skills and when you do receive feedback, it’ll come as a surprise to your self assessment instead of a support mechanism to help you improve. I thought the context of this problem was spot on, the Dunning-Kruger effect came into my mind when I read this, sometimes people are too falsely confident of their own skills and clearly haven’t been told their real skill level on a certain subject matter. Ever since I became aware of the Dunning-Kruger effect, I’ve been trying to be more open minded to discussion and debate if I’m wrong on something.

For the problem of this pattern, it says your self assessment is only relative to the abilities you used opt have, you will always lack objectivity. I was not sure what this meant at first and I still don’t, however the next few parts that it describes I can relate to. It describes how being in a above-average team will make you feel like a superstar when in reality you’re more of a back up dancer, and how being on a below-average team will make you feel complacently smug. I can relate to this because in class, the backend team for the guest info system, they are definitely gonna go far in life as software craftsmen, I feel like they know what they’re doing which in turn makes me feel like I should know what I’m doing but, I’m just a back-up dancer.

For the solution of this pattern, you want to create mechanisms to regularly gather more or less objective external data about your performance. You will also want to be able to process the raw data from these mechanisms in order to get useful feedback about yourself. Honestly, the solution for this pattern was kind of confusing at first, I didn’t understand some of the mechanisms described but I’m sure in practice it is better than it is described.

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