This week, I delved into the Apprenticeship Patterns book once again and explored the chapter on “The Deep End”. The context of this pattern is that you are taking small steps and are left unsatisfied with your learning. You start to fear that you are in a rut, where your skills are decaying. You need to grow your skills, confidence, and your portfolio.

The solution given is to jump right into the deep end. Waiting until you feel ready can lead to never doing it. Growth only happens when you challenge yourself. This can be risky because failure is possible, but without risk, you cannot grow. This does not mean lying about your qualifications on a resume, it means taking promotions or tough assignments when they are offered. Even though taking on risk is advocated in this pattern, it makes it clear that there is a responsibility to offset that risk as much as possible. This could be as simple as having someone who can be there to help you out when you need it.

The action plan given is to think of the biggest project you have worked on and then try to find and measure its complexity. Then use the metrics you came up with to measure every project you have worked on and plot them. When you start a new project, you can compare it to your old ones and make choices based on it.

I chose this pattern because I have felt like I have been in a position where I am only making safe moves. It is a lot easier to stay at your current skill level and never try something new, but it is not sustainable. I need to constantly challenge myself so I can improve my skills as a software developer. Currently, the list of projects that I have on my portfolio is not long. Most of what I have coded has been small class work or homework assignments, but to stand out to employers, I want to get more complex projects under my belt. The takeaway from this pattern is to keep challenging yourself to improve your skills. Do not settle for where you are at because that is when you can slip into mediocrity.

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.

Hello!

For the final pattern blog of the semester, I decided to close off with the “A Different Road” pattern from “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. 

This pattern is related to following your own map but straying from the Long Road in the process. As you spend time following the Long Road, you may come to see that your values have changed. For example, you may value family or money more than before. Your goals may not align anymore and this may cause you to leave the Long Road. However, what you have learned along the way isn’t rendered completely useless–they can be applied in other ways to whatever you choose to do. 

You may realize after leaving the Long Road that you would like to go back. There may be some organizations that would give you a tough time for that gap in your resume, but there are some organizations that aren’t as bothered by that and may welcome your perspective of leaving and returning to the field. The pattern encourages you to not be afraid to go for something different, and either way, your skills can be utilized in a different way. You can take action by making a list of what you would do if you were not a software developer, and what you may enjoy– and reach out to people who are doing those jobs to learn what their experience is like, and compare it to what you like about software development.

I think this was a useful pattern to read. It is recognizing that some people change, and they may shift what their focus is on. I think it’s reassuring to see that it acknowledges the industry may be tough on people who have gaps in their resume but that wouldn’t be a complete set-back. It wouldn’t be the end if we can’t exactly make it back to the kind of position we were in before, but some important skills we gained along the way can be transferred to something new. There’s more flexibility than we think, and I think that I would definitely have this in mind going forward. Sometimes it feels like I may be reaching a dead end if I don’t meet certain deadlines, but of course, we all have different timelines and paths. I don’t have anything I disagree with for this pattern as I agree that diverging doesn’t mean the end of everything or means that everything would be wasted.

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.

The Deep End approach is designed to motivate learners to take on difficult tasks and ambitious projects that may seem intimidating at first. The goal is to immerse oneself in unexplored territories and push past the boundaries of their comfort zone to accelerate learning and personal growth. By tackling challenging tasks, apprentices can gain a deeper understanding of their trade and develop their skills more rapidly.

As a software developer, I find myself identifying with The Deep End approach. It’s all too easy to become complacent with the familiar and continue with what we already know. However, by accepting challenging projects and tasks, we can reap immense benefits. This methodology recalls the saying such as, “Life begins at the end of your comfort zone,” which holds true for personal and professional growth alike.

I particularly value the emphasis on embracing uncertainty within The Deep End methodology. It can be fearful to dive into a project or task that is entirely new and unfamiliar, but by doing so, we are forced to learn and grow in ways that wouldn’t be otherwise possible. This is especially important in the fast-paced world of software development, where new technologies and techniques are continuously emerging. It’s critical to keep up with the latest trends and stay ahead of the game. Furthermore, I value the concept of assuming responsibility for one’s learning and development. Instead of relying on external sources to delegate assignments or undertakings, this approach motivates learners to actively seek out prospects to push themselves and expedite their progress. In my opinion, fostering this mentality is crucial, not only in software development but also in any discipline that necessitates ongoing education.

This pattern serves as a reminder that learning and development do not end with formal education or training. In fact, it is often the experiences outside of our comfort zones that provide the most significant opportunities for growth and development. Therefore, The Deep End pattern has the potential to unlock new possibilities and accelerate personal and professional advancement. As a result, I am committed to applying this pattern in my endeavors and look forward to the growth that it will facilitate.

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.

A bridge is a structural design pattern that lets you split a large class or a set of closely related classes into two separate hierarchical abstractions and implementation- which can be developed independently of each other. The blog from refactoring guru explains bridges a way of using more object composition rather than inheritance. Which means that we can extract one of the dimensions into a separate class hierarchy, so that the original classes will reference an object of the new hierarchy, instead of having all the behaviors with in one class.

Using this design principle, we can extract the code into its own class with two subclasses. And then we can have a reference field pointing to one of objects. That reference field will act as a bridge between one class to another and let’s say we needed to add another color for a shape, then we don’t have to go out of our way to create a PurpleCircle Class, we can just add the color, reference it with the shape and we’re done.

The blog has gone out of its way to explain real world applications for the Bridge pattern. One being used to help divide the monolithic code of an app that mages devices and their controls. The Device classes act as the implementation, whereas the Remotes act as the abstraction. The remote-control class declares a reference as explained in the description and that links it with a device object. All remotes work with the device via the general device interface.

Bridges are important because sometimes it can get hard to see what is contained with in a class especially if the class is gigantic. And making changes with one aspect of the class could require you to make changes in other aspects of the class. So, the bridge helps split the monolithic class into several class hierarchies. Which makes it different then most patterns like the Factory Design pattern or the Singleton pattern. The Bridge pattern would be mostly compared to the Strategy pattern where it plays a bigger role in how the code is being structured rather than adding some small commodities. It’s important to use the Bridge pattern to help extend the class in several orthogonal (independent) dimensions. It helps delegate the original class into related work to the objects belonging to those hierarchies instead of doing everything on its own.

The Bridge is very useful to help organizations within the code, I always tend to fill my classes with code with the use of implementations or inheritance so this would be a good way to get myself started on it.

Link to Blog: “https://refactoring.guru/design-patterns/bridge”

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

This week I read about frameworks by reading “What’s a framework? All about software frameworks” by Lucas Stahl and Sean Higgins. Sean and Lucas did a great explaining what a framework is by making it easy to understand and giving many examples.

A framework is like a template that can be used to build your code on top of. Frameworks are premade code that take care of some aspects of the program. They are also reusable functions that make programming easier. Most programming languages have at least one framework that use them. The content of a framework can be very different, and it depends on the needs of the programmer for which one they should use. Many frameworks are open source that are maintained by the community of programmers but there are some from large companies like Microsoft or Meta. Frameworks might sound like code libraries but there is a difference. A quote by David Fateh helps explain the difference. Fateh said, “A framework,” he says, “is like a construction blueprint: A template that defines a basic structure for your build. A code library is more like a carpenter’s tool belt: It has tools designed to perform specific tasks”.  Lucas and Sean go on to explain the benefits of using a framework. Some of the benefits are being able to focus on one area of development, easier testing, development speed, reliability, documentation, and better security. There are many benefits to using frameworks but there are a few challenges as well. These challenges are structural limitations because frame works can’t do everything, having to learn the framework and the language it is based on, as well as having to pick from the many frameworks that are available today.

I learned a lot from this article, and I think frameworks could be a useful tool to use when programming. The diverse selection available seems like they could help in many situations. Being able to use a framework to cover a part of a program like the backend for example so another part like the front end can be focused on sounds interesting. Being able to focus on your area of expertise is a major benefit of frameworks. Although there are some limitations of frameworks the benefits seem to outweigh the cons. After reading this article I am now curious about all these frameworks and how I could use them to better my development skills. In the future I suspect that frameworks will be a common use for me.

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.

This week, I decided to look at an article based on the GRASP principles, and found this insightful article from Kamil Grzybek, an experienced designer in the .NET Framework. The GRASP concepts essentially explain how to assign certain responsibilities to different classes within a project. Each principle is derived from a problem, and the principle solves the problem. The first principle, Information Expert, decides which class will take the responsibility for a certain operation. In his example, his Customer class takes the responsibility of compiling an order since it has all the necessary information to do this. The next principle is Creator, which asks the question who creates an object? The answer according to the principle to assign a class to create this object, only if said class is closely related to the object. The next principle Controller decides who is the first object beyond the UI to control a systems operation and delegate information. The fourth and fifth principles are Low Coupling and High Cohesion, which solve the issue of keeping classes independent and to keep them focused on minimal tasks. The sixth principle is Indirection, which solves the issue of avoiding direct coupling between objects. The seventh principle is Polymorphism, which helps control flexibility within the code. The eighth principle, Pure Fabrication, solves the issues of what do to when there is an intermittent task that needs to be completed and avoiding more direct coupling between classes. The final principle, Protected Variants, is argued to be the most important principle. It helps to keep code available to change.

After reading this article, it seems to be a more expanded version of principles and concepts we have learned earlier in the class. Most of the principles within the GRASP lineup are connected to either another set of principles like SOLID, or directly correlate to a specific concept like loose coupling. The main reason I selected this article was the nice use of physical code examples to show off the principles. Throughout the whole article, Kamil used a Customer project that tracked orders. Each concept was show in a different section of the project, which makes it easier to visualize when thinking about how to apply it to code that I create. This article seems more to be for more experienced software designers, which I enjoyed. Learning new concepts with descriptions that are easy to understand can be helpful, but having a more challenging description given to me challenges me to understand the concepts deeper.

To use these principles in the future I must remember a two different ideas.
1.) All aspects of the code need to be individual and loosely related to avoid breaking the code when adding change
2.) It is easier to assign certain tasks to a separate class than to jam pack a single class with all of the functions

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

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

For this week, I chose to read the pattern ‘Sweep the Floor’ from Chapter 4: Accurate Self Assessment. This chapter is on, as you can read from the name of the chapter, accurate self assessment. I did another pattern from this chapter not too long ago but I think this chapter is easily the most relatable for me at least. For this pattern, the context of it is that you are a new apprentice on a project. I chose this because I could relate this back to when we were first starting our group projects and getting into our teams. It was a foreign experience to me since I hadn’t had an internship yet or anything of the sort. For the problem of the pattern, it revolves around you being unsure of your place on the team and the team is unsure of you. This was relatable to when we first started, we didn’t know each other and our work flows. Luckily, we were doing Scrum so we had a leader basically ease us into things. Additionally, the problem also is wishing to find a means of contributing to the team’s work, earning the team’s trust and growing as a craftsman.

For the solution, it followed the same approach as most of the solutions in this chapter were. Pushing yourself to do tasks in order to grow as a craftsman. With this pattern, the solution was to volunteer for simple, unglamorous tasks. This is ‘sweeping the floor.’ Doing tasks that are mandatory to the program’s success such as maintenance reports, bug fixing, code review, etc. I thought this was interesting because my approach to getting trust from a team is doing the hard work first in order to show I know what I’m doing and to show that I won’t let them down. However, this approach seems more personable than my approach and much simpler, on paper, as well. This solution does come with caveats though, as mentioned in the solution. One problem is you may become the team’s gopher, this means being condemned to doing menial tasks no one else will do. I, for one, don’t think that’s a big problem but I guess it depends on the person and their ambitions. Another problem is that you may find yourself intimidated by doing anything other than sweeping the floor. I can kind of understand where this point of view comes from but for me, I don’t think it would be much of an issue transitioning between hard tasks to relatively simple, menial tasks.

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

Passion is the devotion we invest in of our interest, could be a hobby, sport, or even a profession. Upon reading the book “Apprenticeship Patterns”. There are multiple chapters that are divided up into 35 patterns to give a breakdown of the broad idea of being a craftsman. For example, I have read chapter 3 “Walking the Long Road”, towards the pattern of “Nurture your Passion”. This pattern entails about keeping a strong leveled mentality. Going into our career field as a software developer which the environment would cause an impact on one’s passion. This pattern gives us an idea on how to tackle this situation. 

After understanding the purpose of this pattern, I saw it made sense to find multiple ways to help keep positive during workflow. The section of drawing your map caught my attention because whenever we have a certain goal, dreams, and needs it is separated out from our work goals, dreams, and needs. Two different lives which you try to maintain but eventually it outweighs each other which conflicts you. Personally, speaking we would rather just be selfish and accomplish our own goals and dreams. We are only human. But at the same time, we do not want it to conflict our mindsets when it comes to our profession.

For the type of action, they would want to conduct to keep our passion in check was to write up a list to control a conversation.  It is true you must keep a cool mind and keep your mind positive. But there will be days where things will not work out. For example, what if you had a bad day, the only it will do is put you in a funk for whatever reason It may be. Work related. Personal related. There are many factors you don’t have control like an environment or said workflow. 

I believe that I can take these steps but not all of them. I do agree that you must absolutely make sure the passion is there and do however to protect it because it what makes us motivated to stay concentrated. People are different and should be able to nurture their passion differently. Composing a list can help but nobody would like to compose one before work daily, that can be taxing. Sometimes you must be selfish, such as leaving work while the team are staying late. Just playing it by ear on a daily as it can shift constantly. A road we are set and take the necessary actions. 

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.