The article I found today that I want to write about is titled “My 5 Biggest Screw-Ups as a Scrum Master”. I chose this article because the title of it really jumped out and resonated with me when I read it. I figured it would give me some good insight on what it’s like to be a scrum master and possibly have some good tips or tricks on how to avoid common mistakes when you’re new to it.

The article mentions his five major mistakes and how he fixed them, which I’ll get into below.

For the first mistake, he mentioned how when he heard differing viewpoints than his own, he would be upset. He fixed this by putting himself in the other people’s shoes, and trying to understand why they were seeing it how they were. For his second mistake, as it sort of ties into the first one, any feedback he got was very tough to swallow. To fix this, he actively sorted out as much feedback as he could in order to get used to it and learn from it. For the third mistake, he pretty much just simply allowed his group to “self-manage” on their own, but it led to a lot more confusion than anything. To fix this, he set goals and clear responsibilities for all members of the group but still allowed for the sense of freedom that self-management implies. As he says “it gives a sense of direction and vision for the state they want to achieve”. The fourth issue was missing out on signs of lack of trust; meaning not realizing the group members may have issues with each other. For his solution here, it really seems he doesn’t really have one. He tried everything he could but, at the end of the day, the two group members were never going to get along. I guess the takeaway here is to just recognize this and either reconstruct the group or direct your energy elsewhere. The fifth issue, working beyond his experience, was simply just that. He thought it would be a piece of cake to be a scrum master, but it was far from it. He learned you must expand your comfort zone by going into uncomfortable situations with the intent to learn, and that honesty is extremely crucial.

Although we learned about Scrum in class, this article did a good job summarizing and explaining the issues you may experience within it, especially as a first time scrum master. It’s honestly probably something I would have never thought of and I probably would’ve made the same mistake as the writer by thinking it would be a piece of cake. Because of this article, I now know a little bit more as to what to expect whenever I have my first big project as a scrum master and HOPEFULLY I can avoid some, if not all, of the mistakes made by the person here.

Link: https://medium.com/serious-scrum/my-5-biggest-screw-ups-as-a-scrum-master-f912be2ed2d4

From the blog CS@Worcester – RBradleyBlog by Ryan Bradley and used with permission of the author. All other rights reserved by the author.

This week, I found a study on adopting design patterns in an IT organization. The study was conducted by the University of Oregon, and a link to the study can be found at the end of the blog. I selected this study due to the fact that it dove a lot into software design patterns and why, if they are implemented correctly, they can be extremely beneficial for a company to use.

The overall purpose of this study was to, as stated in the study, provide a scholarly annotated bibliography that examines software design patterns. It wants to provide IT leaders with proof that the implementation of design patterns can achieve increased operational efficiency or the delivery of strategic benefits.

By the end of this study, you can see some clear benefits of using a good design pattern. Operationally, there is a reduced development time as well as as a reduction of errors. This is due to the development process being streamlined, as well as being reusable with tested solutions. Strategically, patterns can contribute to a system that scales over time without a lot of rework, which is huge for organizations with rapidly evolving needs. Patterns also must create a shared language which inherently allows for better collaboration between different teams working on a project.

The study also goes over how it can be implemented using phased adoption; implementing patterns gradually allowing for people to adjust. On top of this, it mentions periodic review and sharing of documentation/knowledge, two very important ideas in terms of efficiently and affectively using design patterns.

Having read this study, it certainly reinforces a lot of the ideas we mentioned when discussing design patterns. I wouldn’t necessarily say everything I read was new, and the new sounding information may have just been worded in a different way, but the study certainly did a good job as sort of drilling the benefits of why a good design pattern can be highly beneficial.

This study also opened my eyes in the sense that I feel as though in my career I may keep an eye out for how different design patterns could be implemented into any projects that I’m working on. Being able to cut back on time, while still completing different jobs in an effective manner is something that will be very important and possibly put you above other people. If I demonstrate a knowledge of design patterns and can implement them well, or at least suggest them, it may at the very minimum open my companies eyes to different possibilities.

Link to study: https://scholarsbank.uoregon.edu/server/api/core/bitstreams/b5d95a74-77d6-454b-9ed5-1f2af2633f8a/content

From the blog CS@Worcester – RBradleyBlog by Ryan Bradley and used with permission of the author. All other rights reserved by the author.

For this week’s blog, I decided to discuss the pattern from Chapter 2 called “Unleash Your Enthusiasm”. This pattern discusses the enthusiasm for learning that many software engineering apprentices experience and how you should show it because, at this point in your career, you can provide unique qualities. This section discusses the situation where you may find yourself holding back because you may find that you have more enthusiasm than your colleagues. This is because there may be pressure to conform to the norm whenever you work on a team. In addition to this, many teams mainly focus on delivering the next product or improving on the aspects of the development life cycle. It also explains the risk of exposing your enthusiasm to an established team. In this situation, the text explains if the morale of the team is low or if they are not very welcoming to newcomers, you might make a poor impression. In this case, the text mentions that the advice in the section should not be applied blindly because you need to consider team dynamics.

The reason that I decided to pick this pattern is that I have never thought of concealing or holding back my enthusiasm for my craft. Every team that I have gotten the pleasure of joining in some way really valued my enthusiasm and the skills that they could learn from me. I have always been on a team where we all encouraged each other to learn from someone else on the team. Needless to say, I have never thought about the possibility of making a bad impression because of my enthusiasm for the task. In hindsight, I can see how exposing your ignorance of a topic can upset a team that values competence over enthusiasm for learning. I do think this quote from the text holds truth to it because of my own experience: “it is actually healthier for a team to consist of people with varying levels of experience”. Tech is a fast-paced industry so everyone is forced to keep up with new trends. A team that has a diverse set of skills at different levels is bound to create a healthy environment. With that being said, I can’t say that I disagree with anything from this section but I will be more aware of unleashing my enthusiasm on certain teams.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

The draw-your-own-map pattern talks about how people should take control of their career paths and not rely on others to define their path. This pattern talks about identifying the next logical steps, visualizing how to achieve those steps, and continuing to evaluate their goals and values. Draw-your-own-map pattern suggests that getting help from like-minded people and being open to adjusting one’s map to any changes that came up. This pattern shows stories about people who go into programming despite challenges from employers and orginizational limits. Draw-your-own-map encourages people to set a specific goal rather than setting a goal that isnt reachable. That step not only helps provide feedback but it also makes you seek guidance from like-minded people, those people can give you resources and support when trying to achieve your goals. One of the key ideas of this pattern is flexibility, it supports the idea of one’s mind to keep reassuring themselves that it’s okay to make changes. This pattern promotes an approach to career development and make sure to empower people to find their way through there careers with a purpose.

I thought this pattern was interesting because it encourages people to be creative and not rely on other people to define our paths, it should be our decision. I also thought the steps that the pattern talks about was very helpful, it’s important to set realistic goals so that you don’t overwork yourself to reach that goal. Visualizing the steps to achieving those goals also help make sure you don’t rush through the process and able to have a set plan. Evaluating your goal and values are also important as you go on to make sure that you can still reach your goal and be okay with any changes that come. This pattern has changed the way I think about achieving my goals, I know now to set a more realistic goal for myself and not be scared to get help from people who think like me. I don’t disagree with this pattern because I feel like this will help a lot of people with reaching their goals and make them think more realistically while getting support from others.

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

The “Be the Worst” pattern encourages you to surround yourself with individuals who excel in their craft, even if it means being the least skilled person in the group. By doing this, you engage yourself in an environment that fosters continuous learning and growth, as it exposes individuals to new perspectives, challenges, and techniques that may not occur otherwise.

I find this pattern both interesting and thought-provoking because it challenges the traditional notion of seeking out environments where one is the most skilled or experienced. Instead, it encourages the embracement of discomfort and for individuals to seek out opportunities for improvement, even if it means initially feeling inadequate or out of place.

Embracing this pattern has caused me to reconsider how I approach my career and professional development. I have been inclined to seek out roles or teams where I felt confident in my abilities in the past, always fearing the possibility of struggling or being overshadowed by more experienced peers. However, I can see the value in seeking out environments where I am the weakest member after my reflection on this pattern. This will give me the chance to push myself to learn and grow at a faster pace, ultimately becoming a stronger and more versatile developer.

While I generally agree with the principles outlined in this pattern, I do acknowledge that it may not be suitable for everyone or in every situation. Some individuals may thrive in environments where they are the most skilled, finding comfort and confidence in their expertise. Additionally, constantly being the least skilled member of a team can be emotionally challenging and may require a certain level of resilience and self-confidence to navigate successfully.

Overall, the “Be the Worst” pattern serves as a reminder of the importance of humility, curiosity, and continuous learning in one’s professional journey. By seeking out opportunities to surround oneself with individuals who are better than them, individuals can unlock their full potential and achieve greater success in their chosen field.

4. Accurate Self-Assessment | Apprenticeship Patterns (oreilly.com)

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.

This week I decided to discuss Unit testing because although we have finished a few activities on the subject, I would like to read up on it to get a better understanding of it. While searching for a blog to discuss, I found this blog called “Unit Testing Best Practices: 9 to Ensure You Do It Right” from Testim. This blog also discusses what a unit test is, why we write them, the benefits of unit testing, how to achieve testable code, who creates them, and the difference between unit testing and integration testing.

The text begins by explaining that unit tests focus on very small parts of the application in complete isolation and compare their actual behavior with the expected behavior. In this section, the idea of complete isolation is thoroughly explained with the idea that “you don’t typically connect your application with external dependencies”. This is what makes unit tests so fast and stable.

The next section explains why they are created in bullet points and have the main ideas bolded. This structuring is helpful to simplify the ideas for the reader and make sure that the main ideas stick out for them. These were the bolded parts of the bullet points in the section: unit tests help you find and fix bugs earlier, your suite of unit tests becomes a safety net for developers, unit tests can contribute to higher code quality, unit tests might contribute to better application architecture, unit tests can act as documentation, and detect code smells in your codebase. I think a lot of the ideas presented were easy to comprehend based on the bolded part but I had to read more about the last bullet point because the term” code smells”(signs that something is wrong with your code ) was not obvious to me. 

The section that explained the difference between integration testing and unit testing was fairly short because they narrowed the main idea down to a few sentences: “It’s all about the level of isolation. While unit tests have to be completely isolated, integration tests don’t shy away from using external dependencies….integration tests offer a more high-level view of the application than unit tests do. Because of that, the feedback they provide is both more realistic and less focused.”

The 9 best practices at the end are titled: Tests Should Be Fast, Tests Should Be Simple, Test Shouldn’t Duplicate Implementation Logic, Tests Should Be Readable, Tests Should Be Deterministic, Make Sure They’re Part of the Build Process, Distinguish Between The Many Types of Test Doubles and Use Them Appropriately, Adopt a Sound Naming Convention for Your Tests, and Don’t Couple Your Tests With Implementation Details. These tips are easy to understand based off of the title alone but throughout each section, the author uses bits of code as examples and bullet points to thoroughly explain each idea. In the future, I will refer to these tips when I need to write tests for a project I will work on.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.