Hello and thanks for coming back to another week of my blog! This week, I took a look at chapter 4 in the book Apprenticeship Patterns by Dave Hoover, called “Find Mentors.” Having a mentor can help you get guidance, support, and feedback to help you get better in your field. This apprenticeship pattern gives tips on how to find a mentor, like looking for people who are respected in your industry, going to conferences, and asking for feedback from your colleagues. It is also important to be open to feedback and find more than one mentor to get different perspectives. The computer science field is still relatively new, so there are not that many truly skilled mentors that excel in all computer science areas that are available to look up to. The pattern also says that you may encounter mentors that you may not be able to talk to, such as people making informative YouTube videos who live overseas. But those people are still mentors who inspire you. The pattern also emphasizes how hard it actually is to find a mentor. While there are many skilled people in the computer science field, not all of them are open to mentoring. Therefore, you should always ask if they are interested in mentoring people because you never know if they will accept being a mentor.

As an aspiring computer science major myself, I should also be on the lookout for mentors. There are several ways I can find mentors. The book says I should pick a tool, library, or a community that has an active mailing list and sign up for it. Other ways include asking faculty members at university, who are definitely more skilled than me and are always open to answering questions. Reaching out to alumni is a great option as well, since they were in the same boat as me when they started out. They could mentor me themselves or redirect me to someone they know who is skilled enough to answer my questions. Attending computer science events could be another option since it is a great way to network with professionals and ask them for advice. I would also have to keep in mind that as I get more experience, others may look up to me as a mentor and I would have to guide them on their long journey as well.

Thank you for reading.

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

Hello and thanks for coming back to another week of my blog! This week, I took a look at chapter 4 in the book Apprenticeship Patterns by Dave Hoover, called “Find Mentors.” Having a mentor can help you get guidance, support, and feedback to help you get better in your field. This apprenticeship pattern gives tips on how to find a mentor, like looking for people who are respected in your industry, going to conferences, and asking for feedback from your colleagues. It is also important to be open to feedback and find more than one mentor to get different perspectives. The computer science field is still relatively new, so there are not that many truly skilled mentors that excel in all computer science areas that are available to look up to. The pattern also says that you may encounter mentors that you may not be able to talk to, such as people making informative YouTube videos who live overseas. But those people are still mentors who inspire you. The pattern also emphasizes how hard it actually is to find a mentor. While there are many skilled people in the computer science field, not all of them are open to mentoring. Therefore, you should always ask if they are interested in mentoring people because you never know if they will accept being a mentor.

As an aspiring computer science major myself, I should also be on the lookout for mentors. There are several ways I can find mentors. The book says I should pick a tool, library, or a community that has an active mailing list and sign up for it. Other ways include asking faculty members at university, who are definitely more skilled than me and are always open to answering questions. Reaching out to alumni is a great option as well, since they were in the same boat as me when they started out. They could mentor me themselves or redirect me to someone they know who is skilled enough to answer my questions. Attending computer science events could be another option since it is a great way to network with professionals and ask them for advice. I would also have to keep in mind that as I get more experience, others may look up to me as a mentor and I would have to guide them on their long journey as well.

Thank you for reading.

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

Hello and thanks for coming back to another week of my blog! This week, I took a look at chapter 4 in the book Apprenticeship Patterns by Dave Hoover, called “Find Mentors.” Having a mentor can help you get guidance, support, and feedback to help you get better in your field. This apprenticeship pattern gives tips on how to find a mentor, like looking for people who are respected in your industry, going to conferences, and asking for feedback from your colleagues. It is also important to be open to feedback and find more than one mentor to get different perspectives. The computer science field is still relatively new, so there are not that many truly skilled mentors that excel in all computer science areas that are available to look up to. The pattern also says that you may encounter mentors that you may not be able to talk to, such as people making informative YouTube videos who live overseas. But those people are still mentors who inspire you. The pattern also emphasizes how hard it actually is to find a mentor. While there are many skilled people in the computer science field, not all of them are open to mentoring. Therefore, you should always ask if they are interested in mentoring people because you never know if they will accept being a mentor.

As an aspiring computer science major myself, I should also be on the lookout for mentors. There are several ways I can find mentors. The book says I should pick a tool, library, or a community that has an active mailing list and sign up for it. Other ways include asking faculty members at university, who are definitely more skilled than me and are always open to answering questions. Reaching out to alumni is a great option as well, since they were in the same boat as me when they started out. They could mentor me themselves or redirect me to someone they know who is skilled enough to answer my questions. Attending computer science events could be another option since it is a great way to network with professionals and ask them for advice. I would also have to keep in mind that as I get more experience, others may look up to me as a mentor and I would have to guide them on their long journey as well.

Thank you for reading.

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

Hello and thanks for coming back to another week of my blog! This week, I took a look at chapter 4 in the book Apprenticeship Patterns by Dave Hoover, called “Find Mentors.” Having a mentor can help you get guidance, support, and feedback to help you get better in your field. This apprenticeship pattern gives tips on how to find a mentor, like looking for people who are respected in your industry, going to conferences, and asking for feedback from your colleagues. It is also important to be open to feedback and find more than one mentor to get different perspectives. The computer science field is still relatively new, so there are not that many truly skilled mentors that excel in all computer science areas that are available to look up to. The pattern also says that you may encounter mentors that you may not be able to talk to, such as people making informative YouTube videos who live overseas. But those people are still mentors who inspire you. The pattern also emphasizes how hard it actually is to find a mentor. While there are many skilled people in the computer science field, not all of them are open to mentoring. Therefore, you should always ask if they are interested in mentoring people because you never know if they will accept being a mentor.

As an aspiring computer science major myself, I should also be on the lookout for mentors. There are several ways I can find mentors. The book says I should pick a tool, library, or a community that has an active mailing list and sign up for it. Other ways include asking faculty members at university, who are definitely more skilled than me and are always open to answering questions. Reaching out to alumni is a great option as well, since they were in the same boat as me when they started out. They could mentor me themselves or redirect me to someone they know who is skilled enough to answer my questions. Attending computer science events could be another option since it is a great way to network with professionals and ask them for advice. I would also have to keep in mind that as I get more experience, others may look up to me as a mentor and I would have to guide them on their long journey as well.

Thank you for reading.

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

In software development, surpassing the expected work is very essential. This means going above and beyond the project specifications to create a product that not only meets but also exceeds the product owner’s expectations. When you see software development as a craft, you approach it as an art form, which requires imagination, innovation, and meticulousness. This approach is particularly crucial when designing user interfaces, as the visual appeal of software can significantly impact the user experience. Therefore, striving for excellence in software development can elevate it from a mundane task to a creative endeavor that delivers results that stand out.

Personally, I try putting extra effort to go above and beyond when working on class or personal projects. This mindset not only promotes personal growth but also adds value to my portfolio. I especially take pleasure in crafting user interfaces that are not only visually attractive but also user-friendly. However, it’s crucial to be mindful of the balance between adding valuable features and spending excessive time on details that aren’t necessary. As software development requires careful planning and prioritization, focusing on what’s essential and avoiding distractions can save precious time and effort.

Balancing extra effort on client projects with their needs and requirements is essential. Adding unnecessary features can waste effort, and spending too much time on one project can harm others. Still, going the extra mile on critical projects can bring significant rewards and boost one’s reputation. Effective communication and understanding client priorities are crucial in making informed decisions on where to devote extra resources and attention. Ultimately, delivering work that satisfies the client’s needs while exceeding their expectations is key to success in software development and this is something I will be using in my future endeavors.

In conclusion, exceeding expectations in software development can yield positive outcomes and personal and professional development. Thinking software development as an art form can help produce anything that’s visually appealing and user-friendly interfaces, enhancing user experience. However, it’s crucial to maintain a balance between investing extra effort in projects and fulfilling clients’ needs and specifications. Ultimately, effective communication and understanding clients’ priorities are crucial in creating informed decisions on where to devote additional resources and attention.

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.

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.