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, while exploring some articles, I found one that really caught my attention: Happy Patel’s article titled, “Why Python Is So Popular Even Though It’s Super Slow.” Patel’s post dives into Python’s popularity in the programming world, even though it’s known for being slower than other languages. After a quick look into Patel’s background, I found that he’s a knowledgeable voice in tech, sharing insights into why developers choose Python despite its limitations. His article offers a well rounded look at the unique benefits of Python, such as its simplicity, versatility, and productivity, which contribute to its wide usage in various fields like web development, data science, and automation.

Patel kicks things off by breaking down why Python is generally considered “slow.” For instance, he mentions that Python’s code is interpreted rather than compiled, which can make it lag behind other languages in execution speed. Another reason for this lag is Python’s Global Interpreter Lock (GIL), which only allows one thread to execute at a time within a process. Although these details may seem like drawbacks, Patel points out that these traits also make Python flexible and user-friendly. Its high level syntax closely mirrors human thought, allowing developers to think more about problem-solving than strict coding rules. Patel sums it up well by explaining that Python essentially lets computers handle the heavy lifting, letting humans focus on creative coding.

Then, Patel goes on to highlight the reasons for Python’s enduring popularity, despite the speed limitations. One key factor he points out is that Python’s simplicity and readability make it incredibly productive. Development cycles are often much shorter, which can be a huge plus for companies where employee time is one of the most valuable resources. He argues that for many businesses, development speed and efficiency matter more than code execution speed. Patel also emphasizes that Python’s scaling capabilities, like horizontal scaling, let developers manage performance limitations, making Python adaptable for many real-world applications.

I chose this article because it not only aligns with our course material but also sheds light on Python’s “personality” in the coding world. I liked Patel’s casual and practical tone it’s informative without being overly technical. His points gave me a new perspective on how Python’s user-friendliness outweighs its slower speed, especially in environments where development time is critical. Patel’s discussion encouraged me to think about how Python’s design might be useful in my own coding projects, as it shows how the language’s efficiency and adaptability make it great for rapid prototyping.

Reading this article reinforced why Python is considered beginner friendly and why its productivity makes it so popular across industries. I’m excited to apply what I’ve learned, especially Python’s fast development approach, in future projects where flexibility and quick prototyping will be valuable. Patel’s article makes a strong case for why Python is more than just “slow” it’s practical, versatile, and adaptable, which are all reasons I’d recommend Python to anyone entering the programming field.

Link to the post: https://medium.com/@innvonixtechsolutions/why-python-is-so-popular-even-though-its-super-slow-cedfa2b8fe68

From the blog CS@Worcester – Harley Philippe's Tech Journal by Harley Philippe and used with permission of the author. All other rights reserved by the author.

I recently had a talk with one of my friends about certain ways that software should be constructed. One of the main points of discussion was the structure of classes in Object Oriented Programming, we also spoke about storage systems such as SQL and Flat File storage systems. I wanted to talk about this because it has actually had a huge impact on how I structure most of my projects made in java/C# now. For a while now the format of my code didn’t that visually appealing in the case of class structure and naming conventions. My naming conventions for the past few personal projects were very vague and once my friend gave me feedback on the code, it made me realize that when I re-read the code it came off as confusing, even though it was my project. Every project I’ve made so far after this discussion has come out to be exceptionally clean from my view point, the naming conventions are specific to their use case, the structure for classes interacting with each other is also very efficient now. I plan on continuing to use this methodology for more projects if it can fit into the scope of the project. The reason we discussed storage systems is because for a good amount of projects I’ve done terrible storage management, it was inefficient and quite ugly overall. With some projects needing a lot of data to be handled without anything being lost I would sometimes use YML, overall it is very easy to use but it was slower than other options such as JSON. Once I was shown how to implement JSON instead of YML I noticed significant changes in performance and the along with that process the code became much more readable. In regards to flat file storage, it seems to be very useful for smaller scale projects which is mostly what I work on, but in terms of larger data sets I was shown how to easily use SQL and a little bit of Prometheus to format the project even better. Since configuring and setting up flat files in a project takes a decent amount of code, setting up the database itself was way better. Using tables to grab information instead of having to manually create getters for each entry and key in a flat file was a very good quality of life update that was implemented into most of my other projects that had larger data. All I know now is that for any future projects depending on the data sets, I will be using JSON and SQL as their performance is a significant upgrade.

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

This week, I will be talking about “cheating,” or at least what some consider to be such when solving problems. Looking at the answer to a problem while learning, especially as a beginner, can be a valuable tool when used with thought and care. While some might argue that relying on solutions stifles problem-solving skills, it is important to recognize that learning is a repetitive process. When approached with the right mindset, checking the answer can enhance your understanding of the material and increase your chances of retaining that information.

First, looking at the answer can help clarify misunderstandings. Sometimes, learners might approach a problem with a misconception, incomplete understanding, or flawed method, which often leads to frustration and confusion. I can recall several times where I was required to solve a tough problem and hitting a wall when everything that I knew didn’t work for me. However, by reviewing the correct solution, they can pinpoint where their approach went wrong, gaining insight into both the problem-solving process and the underlying concept. This prevents the reinforcement of bad methods and allows for a more efficient learning experience.

In the podcast, John says, “If you’re trying to ride a bike, you’re not going to go without the training wheels on for the very first couple of runs–it’s totally okay to peek at the solution to get past whatever wall, or to see what new technology you just weren’t even looking at because you didn’t know it was a thing.” Additionally, seeing the correct answer like this can serve as a model for solving future problems. It provides an example of how to think critically and apply things in practice.

However, for this to be truly beneficial, you need to treat looking at the answer as part of the learning process, not the end. It’s important for learners to first make an honest attempt to solve the problem on their own. After reviewing the answer, they should take the time to understand each step fully, perhaps reworking the problem from scratch without referring to the solution. This ensures that they’re not just memorizing answers but are internalizing the concepts and strategies necessary for independent problem-solving.

In conclusion, looking at the answer to a problem is okay, and even beneficial, as long as the goal is learning. When used properly, it helps clarify misunderstandings, serves as a guide for future problems, and promotes deeper understanding. The key is to approach it with curiosity and a willingness to engage deeply with the material, ensuring that it enhances, rather than replaces the learning process.

This episode can be watched in full, for free here on YouTube: https://www.youtube.com/watch?v=T7AaBcNj-mA&ab_channel=noobs%2F%2FaNetworkChuckPodcast

From the blog CS@Worcester – Owen Santos Professional Blog by Owen Santos and used with permission of the author. All other rights reserved by the author.

Link to blog: https://codingsans.com/blog/clean-code

Clean code has been a major topic in our discussions for the past few weeks, as we’ve seen plenty of examples of both clean and bad code. We’ve learned the reasonings for why someone would write bad code, as well as the importantance of clean code. While those discussions enhanced my understanding of clean code, I wanted to take a deeper dive into it and get another person’s viewpoint on the topic. Through my research, I found Clean Code: The Manager’s Guide to Building Quality Software by Gábor Zöld.

Throughout his blog, Zöld provides a deep dive into what clean code is and why it is important, as well as general principles one should follow when writing code. He also provides advice for managers who may be looking for ways to encourage their team members to prioritize the use of clean code in their projects. He also provides an overview on the current state of software development as well as the ethics that a developer should be following when writing code.

I chose this resource because it applies to what we have been learning for the past few weeks, and it provides insight on how clean code operates in a workplace. The blog is based off of the clean code principles from Robert C. Martin, which we went over in class. This blog is also very well organized and easy to read, which shows that Zöld clearly knows what he’s talking about.

The key takeaways that I would have from reading this blog post would be to esnure that the functions that I write are as small as possible and contain descriptive variable names. I also came away with the fact that clean code actually makes you work faster, as if you are trying to push code out to meet a deadline you won’t be as efficient coding in an unorganized workspace. From an employee’s point of view, it is very important to focus on the quality of your code, as well as to understand the human aspect of it and to be trustful and understanding of other developers.

This material made me more aware of some of the bad habits that I have when writing code. I now notice that sometimes I will rush code just to try to finish it fast, but it ends up leaving a messy chunk of code that I have to reorganize later. However, if I followed the principles of clean code from the beginning, it would’ve saved a lot of time and also would’ve been more beneficial to my learning. Moving forward, I’m going to apply these principles to all of my future coding projects by focusing on the names and sizes of functions, ensuring that the names are descriptive and that they don’t take up too much space. I’m also going to apply some of Zöld’s comments regarding the workplace in the future, specifically his points of being understanding towards your other developers and coworkers.

From the blog CS@Worcester – Coding Canvas by Sean Wang and used with permission of the author. All other rights reserved by the author.