This week I am jumping to chapter 6 of Apprenticeship Patterns. The pattern I read was called Reading List. The context of this chapter is now that you have become proficient in your first language, you start to see the massive amount of information you still need to learn. The problem with this is there is more information that you need to learn than you can keep up with.

The solution for this is to track the books and other sources you plan to read and remember which ones you have already gone through. This pattern mentions it might be a good idea to store it in a place that will allow other people to benefit from it. Not only is this pattern used to manage books you are reading but it also helps with reflecting on your past reading habits. One of the most valuable things you can get out of a book is finding other books in the bibliographies that will be good information.

The action plan given to help with the problem is to create a text file and put in all the books you are currently reading. The text file will be your reading list and make sure you keep it up to date. 

I chose this pattern because I thought it would be good to know what to do after I have really mastered my first language and am ready to move on to new things. This will probably be a little while before I am ready for these next steps but being prepared will help with the transition. I will make sure to try out the solution for this pattern but use more than just books. Books are useful but there are plenty of other good resources that I can learn a lot from such as articles, videos, and blog posts, as well as learning from other people. A takeaway I get from this chapter is there will always be more to learn so having a solution to track what you are doing will be a big help with getting through as much as possible.

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.

“Emptying the cup” is one of the most important and interesting chapters of the book “Apprenticeship Patterns” by Dave Hoover. This chapter is a call to all aspiring software developers to unlearn their preconceived notions, beliefs, and biases that may have been learned from past experiences, learning other programming languages, or etc. and become open to new perspectives. In the context of software development, the phrase “emptying the cup” means being open to new ideas, technologies, and practices. It means being willing to unlearn old habits and ways of thinking that might be blocking your growth as a developer. New software developers should be aware of the importance of curiosity and a willingness to learn from others so that they can grow into exceptional software developers.

This apprenticeship pattern revolves around clearing your mind of everything you know and opening yourself to new and different approaches to the problem. Clearing the mind of previous knowledge would get rid of old habits that the programmer may have picked up on while coding in the past. What works in one language might not necessarily work in another language, and there may be more efficient solutions to a problem in another language that may be the most efficient in the original language. What I found interesting is that emptying the cup is much like the metaphor “thinking outside the box.” Rather than using traditional or old habits to solve a problem, you should drop the old habits and think differently and incorporate new perspectives to solve the problem. Most people may fall back on a traditional or the most popular method to solve problems they may encounter while programming because it has shown to work in similar situations. But when programmers solve problems by thinking outside the box, they try to find untraditional ways to solve problems, or find unintended ways to solve them. Thinking outside the box and emptying the cup are similar since they both require the programmer to deviate from the usual methods of problem solving that programmers do and find a more creative way to come up with solutions.

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

When I was in trade school, I had a carpentry teacher who always emphasized the importance of having some sort of competence in whatever is being taught. Having this knowledge is the difference between knowing what to do in a certain project or being absolutely lost. The teacher would advise the other carpentry students, and even myself, about recollecting knowledge of what has been learned or what is fundamental. This pattern talks about what someone can do when faced with being overwhelmed by a project. For the most part, what I learned back in trade school is similar to how this pattern is explained. Although the statement that this pattern is for people who have stretched themselves far beyond their abilities is something I disagree with. In most cases, this can be applied to almost anybody, whether they are an apprentice or journeyman.

Even though it’s hard to put an apprentice in a position that sees them stacking opportunities, it’s not impossible. From there, it is fair to assume that the apprentice is not completely lost in the water and must come back to some prior knowledge to complete the task at hand. Many times I’ve been faced with a project, especially one that seems outside my expertise, and for the most part, all I needed to do was recollect everything that I know, and it usually ends up working out. I’m sure that I haven’t stretched myself far beyond my abilities, but it’s also possible that I’m misunderstanding what the author is trying to say when it comes to explaining how much knowledge one can have to be considered competent in any area of the craft.

It is worth mentioning that the author also keeps checking one’s limit and how far one should retreat once they are met with a challenge that is far beyond their comprehension. This is a good point because, believe it or not, this does happen from time to time. For example, the finance application that I worked on some time ago involved a lot of skills that I wasn’t quite familiar with, such as how to implement an API or how endpoints work. It was quite a lot to understand, but it also taught me to back off when necessary so that, once I’m ready to come back, it will be more familiar.

Sources:

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.

This pattern focuses on the idea of establishing yourself in one language that you may be able to base your career in the future, to better prepare yourself for when you get to the career you want to obtain. The most fundamental aspect from the pattern was the community side of learning a language as it states that you become a part of a much larger community of programmers who share their knowledge and even their code for the sake of helping each other learn and grow as developers.

            In my Experience I thought if I learned a lot of different languages, I could have the experience needed to land any job I wanted too as I had my foot in more languages than one, but what I didn’t realize is that being a good at one language is better than being decent at many. This was not only reenforced by the pattern discussed here but when I met with a family friend who is a developer at staples, he also dropped that bit of wisdom on me as he too thought that was but as he got closer to starting his career, he focused on mastering java, and it has steered him into a very lucrative job.

            Going back to the community aspect the reading mentions how having such large community that works from the same language allows for beginners to have more experienced programmers share the small tricks that they have learned in their experience to give the newer developers a boost in learning. There is a sense of passing the torch in a community like this which you rarely see in other industries, and it is refreshing the lengths that people will go for the sake of knowledge.

            Another useful aspect in the reading was the use of testing early on into learning a new language, as I was relatively new to coding when I started my degree, I went based on what the curriculum that the classes had for what projects I worked on. If I had started testing my knowledge earlier on and working on my own projects based on the language that we were learning on my own time I would have accelerated my experience with java.

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

Instead of solely focusing on the short run, it’s important to strike a balance between short-term and long-term goals. While it’s essential to plan, it’s also crucial to set achievable goals that can be accomplished in the short term, which will motivate you and keep you focused. Furthermore, the focus should be on continuous learning and growth, rather than just becoming a master at the craft. With the constantly evolving technological landscape, it’s important to keep up with the latest trends and advancements in programming. Additionally, it’s essential to maintain a work-life balance and not let programming consume all your time and energy, and staying motivated at the same time.

As a programmer, it’s easy to become distracted over time. I remind myself to stay focused on my passion and aim to become a master of the craft by balancing my work life and goals. The Long Road pattern taught me to stay motivated towards achieving long-term success in programming reminding me that money is not important at the same time. I believe that having a consistent routine and a long-term outlook is essential for staying motivated in programming. Prioritizing becoming a master of the craft, rather than just making money, is crucial for personal growth. I focus on developing a love for programming and continuously learning to maintain motivation and achieve success over wealth. I have a uncle who works as a software developer, and I have heard him express his dissatisfaction with his job. He mentioned that he is only in it for the money and does not enjoy programming or continuing to learn new skills. This attitude of solely working for financial gain can hinder personal and professional growth in programming. Instead, it’s crucial to prioritize developing a genuine passion for the craft and continuously learning new skills. This approach leads to greater fulfillment in the job and the ability to achieve long-term success.

I honestly agree with this pattern, staying focused on learning programming is crucial. While having additional motivations such as becoming a project manager or CIO is possible, prioritizing a genuine passion for programming is essential for long-term success and fulfillment.

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!

Welcome back to the blog. Today I’m discussing The Long Road pattern from the book “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye.

The context of this pattern is that our culture values quick rises to fame and holds material values.

The problem relating to this pattern is that we have a main goal for what we want to become–for example, a master software craftsman–but there are other people and outside factors that expect differently from you. You may be offered a great promotion and are urged by others to go for that rising opportunity, even though it would derail you from your “end goal”.

The pattern brings up as a solution to recognize that it might not seem like you would match with your end goal, and to also keep looking forward to your end goal. You should prioritize learning opportunities and any other growth opportunities that would help in the long-run rather than taking the higher-salary position or a leading position. For people hoping to hone their skills for something specific, they should be prepared for it to be a lengthy process.

For action, the pattern discusses thinking about your future–what role you may have a decade from now, and what experiences you want to have under your belt decades from now. Imagine you have to write about your professional history four decades from now, what would you want to see? Use that to plan out your career path. 

I think this was an interesting pattern to read about. This is meant for someone really dedicated to having a specific range of skill sets rather than someone aiming to quickly get promoted and become managers or someone higher up. I was thinking about what I would do–do I have a specific thing I want to become, like a master software craftsman? Not really. But it was interesting for this pattern to get me thinking. I do agree that if I wanted to become a master software craftsman, it would be important to not take on a role that is unrelated to using skills relevant to programming or being hands-on with software utilization. It could make you stray away from your path too much and could take away major opportunities for your growth for your career goal. If I end up having something in mind that I really want to become, this pattern will surely be on my mind–to make sure I stay on a path that will help me hone my skills and gain experience necessary for my career plans. I don’t disagree with the pattern since it’s meant for a specific end goal in mind.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

Often when writing a function, we want it to be generic enough that it can operate in different ways for different inputs. Different languages will provide different ways to do this. Object-oriented solutions might include interfaces and polymorphism. Procedural languages might suggest template specialization or function pointers.

I’m going to talk about how functional programming languages use first-class functions to solve this problem in a satisfying way without any pointer syntax. Here’s some F#:

let rec filter fn lst =
    match lst with
        | [] -> []
        | head::tail -> 
            if fn head then [head] @ filter fn tail
            else filter fn tail

We’re defining a function named filter here which takes a boolean function and a list. The filter function will pass each element of the list to the function and eventually return a list of the elements for which the boolean function returns true. Let’s look at the result of passing some simple arguments.

let numbers = [0; 1; 2; 3; 4; 5; 6; 7; 8; 9]

let isEven i = 
    i % 2 = 0

filter isEven numbers
[0; 2; 4; 6; 8]

Usually when we see functions in the argument lists of other functions, we expect them to be glorified values. But in this case, isEven is not returning some value that gets glued to a parameter of filter. When a language has first-class functions, it’s perfectly fine to have functions themselves be the inputs or outputs of other functions. Here, isEven is itself an argument, and it operates on the head of each sub-list as we recursively cut our list down to one with zero elements.

In functional programming languages, it’s harder to write programs that aren’t reusable. If we want our filter to cut out any numbers that aren’t part of the Fibonacci sequence, we just write another boolean function and pass it instead.

let rec isFibHelper n x y = 
    if n = x then true 
    else if (y < 0) || (x > n) then false
    else isFibHelper n y (x+y)

let isFib n =
    if n < 0 then false
    else isFibHelper n 0 1

filter isFib numbers
[0; 1; 2; 3; 5; 8]

filter isFib (filter isEven numbers)
[0; 2; 8]

Because filter operates on a list, to filter a list of some other type we can just steal some documentation code for another boolean function.

let strings = ["abc"; "DEF"; "gHi"; "jkl"]

open System

let allLower s =
    s |> String.forall Char.IsLower

filter allLower strings
["abc"; "jkl"]

Functional programming is all about composition and modularity. You start with tiny Lego pieces and need to attach them until you have a gigantic ninja castle. In its most dogmatic form, that means sacrificing creature comforts like loops and mutable data that we use to quickly slap together solutions that can never be reused.

If you learned to write procedures or call constructors, I recommend giving one of these languages a try. It even makes recursion fun, so what’s not to like?

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

The Observer Pattern is a design pattern that allows objects to react to changes in another object’s data while maintaining loose coupling. Loose coupling, for a reminder, is a system in which components are weakly associated with each other.  The pattern as described in Ilyana’s blog “The Observer Pattern” is a pattern that can decide at runtime whether to receive data from the subject-object.

                The blog goes on to say that it is not uncommon for object-oriented programming to run into a situation where you have an object in your code that collects/outputs data and other objects that care about that data. Some objects might care about certain data that the programmer might throw at them, such as measurements or certain temperatures. These objects are the observers. The observers do not care what class gives them the data, only that they receive the data as it changes. Signs that your code might need to be refactored to utilize the Observer Pattern include an object that is dependent on another object or a change to one object that requires a change to many others.

                The Observer Pattern defines a one-to-many relationship between a set of objects. The Observer Pattern defined one subject’s relationship with its many observers. The Observer Pattern will separate the subject from its observers while still allowing the observer to react to changes in the subject’s data. The observers provide a method that allows the subject to inform them of the updates. This pattern allows for loose coupling once again between subjects and observers. As explained in the blog they can interact but don’t know that each other exists, they basically know nothing about each other.

                The pattern is usually implemented using an abstract subject class and an abstract observer class, which a concrete subject and some concrete observers inherit. This pattern would be very useful if I ever needed the objects to receive an update when one object changes. It’s very intriguing to hear the terminology they use within the blog. The subject acts as a publisher which sends out the information and the observer, which acts like a subscriber, basically takes in the information it wants to receive. Obviously with I can see the subject sending information that the observer might not want to receive or have on them. Non the less it’s a very interesting pattern that shows the process of what a loose coupling might look like in a coding environment.

Link to Blog “The Observer Pattern” by Ilyana: https://ilyana.dev/blog/2020-08-07-observer-pattern/

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

The topic I wanted to cover this week is GRASP. GRASP stands for General Responsibility Assignment Software Patterns. I read a blog post by Kamil Grzybek called “GRASP – General Responsibility Assignment Software Patterns Explained”. He does mention his post is inspired and based on Craig Larman’s book “Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development”.

Grzybek explains GRASP is a lesser-known set of rules that can be used in object-oriented programming and there are 9 patterns to follow within GRASP. The nine patterns are the following.

1. Information Expert
2. Creator
3. Controller
4. Low Coupling
5. High Cohesion
6. Indirection
7. Polymorphism
8. Pure Fabrication
9. Protected Variations

Grzybek goes through each pattern, explaining them, and gives some code from Larman’s book to help give the reader a better understanding of the uses of the principles.  The information expert is to assign the responsibility to the class that has the information needed to fulfill it. The creator pattern decides which class should create an object. A class needs to have at least one of the following responsibilities to be a creator, contain or compositely aggregates of the object, records the object, closely uses the object, or initializes data for the object. The controller pattern is to assign the responsibility of controlling a system operation to an object that represents the overall system or use case scenario. Low coupling is a pattern where responsibilities are assigned with the idea of reducing the impact of change by lowering coupling. The high cohesion pattern is used to keep objects focused and easy to use and understand by making sure all responsibilities of an element are related. Indirection is used to avoid coupling by making an intermediate object between two components. Polymorphism is how alternative types of classes are handled by using polymorphi operations. Pure fabrication is making a new class when it is hard to figure out where responsibility should be placed. The last pattern-protected variations is to create stable interfaces around points of variation or instability.

I chose this topic because I thought learning more patterns that could improve my code would be beneficial to me. SOLID and GRASP are the first two sets of rules I have learned about but there are plenty more that Grzybek mentions at the end of his post so perhaps one day I will learn about those too.  I did find GRASP to be a bit more confusing than SOLID to understand but I am glad I had a chance to read about it. The main conclusion I took away from this post is the management of responsibilities in software is crucial to creating a high-quality architecture and code that can easily be changed. Grzybek ends his post with the words “the only thing that is certain is change. So be prepared”, which really emphasizes his point that software must be flexible. I will have to keep this in mind when developing code in the future.

Link: http://www.kamilgrzybek.com/design/grasp-explained/

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.