For my final blog post for the semester, I wanted to pick a topic that was different from project management, since I had already written about that a few times. Since our most recent topic in class revolved around GitHub and git commands, I wanted to explore a blog post that aligned with that topic. I came across a blogpost by GitHub staff engineer Sarah Vessels, from the github.blog page, about code review.

In this article, code reviewer Sarah Vessels discusses some practices to help improve code reviewing and make it more useful and efficient for everyone involved. She advises constantly checking your GitHub notifications inbox, anytime you have a spare moment. She also recommends using GitHub Slack Integration. Certain queries can help filter a slack group for finding outstanding pull requests that need review. We used Discord for our class instead of Slack, but as I understand it, Slack is more common in the professional world. I believe Discord has equivalent queries that can be used, anyway. The next piece of advice she gives is to use reviewer teams to manage notifications. While catch-all code owner teams can be okay as a fallback, it’s better to keep the number of code owner teams your own small, so that anything you get pinged for or anything that shows up in your inbox feels relevant to you, and not just something to ignore.

The next part she discusses, which I feel is the most important advice, revolves around giving good, constructive code review that doesn’t across as lazy. Good code review focuses on specifically saying,” I have a problem with this, maybe you should try xyz instead” instead of saying “I don’t like this” or “This won’t work” and leaving it at that. It’s good to ask questions, because the person who authored a pull request has more context for their changes, and gives them a space to explain and justify their reasonings. Personal preferences are fine, but approval should be about the overall integrity of the code. If the changes won’t break anything or affect production, leave the feedback with a comment but still approve the pull request anyway to keep the process moving. This is something I personally appreciate from the author, because while I don’t mind receiving feedback and improving my part of the process, I hate the feeling of holding back the overall process. This allows opportunities to open discussion without causing a holdup.

She has a few other suggestions in her blogpost, like being gracious and using draft pull requests, but I believe the most important things are her advice about the giving good feedback and managing notifications so you feel compelled to give every notification your full attention. I don’t know how much code I’ll be reviewing in the near future, but if I’m ever in this situation, on either side, this is good advice for me to keep in mind and remember.

Link: https://github.blog/developer-skills/github/how-to-review-code-effectively-a-github-staff-engineers-philosophy/

From the blog CS@Worcester – Site Title by Justin Lam and used with permission of the author. All other rights reserved by the author.

I’m writing this blogpost about Scrum, specifically about the Sprint Retrospective(although the author refers to it as a Scrum Retrospective) that takes place after a Sprint Review. This blogpost(possibly article?) caught my eye while I was browsing through some blogs, as it directly references something we’ve learned about in class, but from a different point of view. Does ‘fun’ and ‘silliness’ have a place in a professional setting like a Sprint Retrospective? My initial thought after reading this introductory question is that yes, a little playfulness is fine as a means to relieve tension and stress, so long as it doesn’t hinder productivity, and so long as everyone is comfortable with it. But while it’s fine in moderation, it’s by no means a necessity. If someone wants to maintain professionalism, then that’s completely fine too. But as someone who’s never actually worked on a development team, I was interested to hear an experienced person’s take on the subject.

In the referenced article, Sjoerd Nijland first addresses the common critiques of playfulness, where people call it unserious and unprofessional, and assume that it gets in the way of productivity. He counters by mentioning the benefits of playfulness based on neuroscience. Some of these include: Improving brain function, energy, and happiness, relieving stress, deepens connections and trust, and encourages creativity needed for problem-solving, amongst many other benefits. It’s something that everyone, even introverts, can benefit from. It’s a mindset. It provides psychological safety. It puts people in a comfort zone, leaving them open to new ideas and discussion. It keeps people trusting of one another, instead of checking and inspecting each other. And so he counters the common by saying that not only can it be beneficial in a professional environment, but that “Discouraging playfulness at work is profoundly UNprofessional”. When applied intentionally, it can be a great mechanism for helping your team deal with what would otherwise be a stressful environment.

I like the way he views playfulness, because he thinks of it in a different way than most people would. Playfulness isn’t slacking, it’s a tool, one that benefits team dynamic and productivity in the long run. Too much of it can be detrimental, and people shouldn’t be neglecting work for play, but ideally it should exist in some capacity. He references existing scrum environments and scrum professionals, and addresses how it’s helped in certain cases, and how some of the scrum critics aren’t viewing it the way they should. Playfulness and seriousness complement each other, and when used correctly, is a great tool for improving your team’s relations, stress levels, and ultimately, productivity. I’ve changed my mind playfulness being unnecessary. A little levity is important for the mind and body, and I’ll definitely keep that in mind when I’m in a professional environment.

Link: https://medium.com/serious-scrum/a-serious-look-at-playful-formats-in-retrospectives-73aed21aa083

From the blog CS@Worcester – Site Title by Justin Lam and used with permission of the author. All other rights reserved by the author.

I chose to write about this Podcast episode in a blog because it’s a topic that resonates with me personally. This episode speaks specifically about the effect COVID had, and how burnout relates to that, which is something that affected me heavily during the COVID year. This isn’t really a topic we discussed directly in class, but Arjun Subramanian is discussing this with Mario Gerard within a technical project management context, which I feel relates to the general theme of what we’ve been discussing thus far in class.

Something Gerard and Subramanian talk about is establishing a boundary between work life and home life. This comes naturally when you’re clocking in to work from 9-5, and forgetting all about work as you come home, but when working from home it becomes harder to mentally separate the two. Working from home in the tech industry has its undeniable benefits, and there’s a reason so many people in the field prefer it, but with increased productivity also goes hand in hand with increased effort, or at least prolonged effort. It becomes harder to create a boundary between work and life when there’s no physical separation between the two. This is something that impacted me heavily, because prior to this I always kept strict separation of my school life and family life. Going to college in 2019 was really the first time I blended school life and social life, and I had the freedom to approach this in whatever way I thought best. Coming home from UMass due to COVID was a huge detriment to that, and having to manage my online courses with my tense familial struggles was something that wore me thin.

The podcast also discusses how toxic environments can contribute to burnout, and the necessity of having the agency to manage and create your boundaries. You can speak up, and you work as hard as you can within your specific timeframe, and you put your heart into it, and once that time is up you come back to earth and you don’t allow work to cross that boundary into personal life.

As far as toxic situations go, that doesn’t necessarily mean a difficult one. As Subramanian talks about, you can have a difficult situation that’s right, and you need to show “grit and tenacity”. But a toxic situation is one you need to walk away from, for your own sake. There may not be a clear way to identify a toxic situation from just a difficult one, but there are signs, and while they talk about some of the signs on the podcast, the bottom line is that you need to have your own well-being in mind as you work.

The discussion about boundaries and toxic situations is one that I feel are a major contributor to the way I was affected by burnout over the COVID years, and something I’m aware I need to look out for, now and in the future.

Podcast Link: https://www.mariogerard.com/tpm-podcast-with-arjun-subramanian-project-manager-burnout/

From the blog CS@Worcester – Site Title by Justin Lam and used with permission of the author. All other rights reserved by the author.

In this blogpost, Rich Rogers, a Testing Capability Lead for Scott Logic, discusses how the people there approach testing as part of their Development and Delivery process, particularly through their 6 principles. He emphasizes context as the first principle, and how when testing, things will always change. You can’t standardize testing, because every project will require different tests. In many ways, this resembles the Agile ideas that we’ve discussed in class, specifically the portion about “Responding to Change over Following a Plan”, and also goes hand in hand with another one of Roger’s principles, which is “Risks over Requirements”. I agree that you may be given a set of requirements as a team, and it may be satisfactory for a customer to fulfill these requirements, but there is value in looking beyond just the requirements and exploring other risks or potential problems that may not have been stated. A plan exists as a guideline, not a strict rule.

Besides those two principles, the remaining ones are: “Value in Tooling”, “Quality for Humans”, “Bring a Testing Mindset”, and “Collaborate and Cross-skill”. To elaborate, the blog discusses Value in Tooling as understanding the tools you have, and taking opportunities to run repeatable automated checks when applicable, so long as they are efficient in terms of cost and effort. Quality for Humans refers to the notion that at the end of the day, humans will be the ones using these tools. The goal is to provide something that humans will be satisfied with, and will be accessible for a person to use. In some manner, this resembles the Agile principle of Customer Collaboration, or even the Individuals or Interactions part of Agile. The Testing Mindset principle is a more broad, referring to a questioning mindset that is aligned with wanting the product to succeed. Every tester has a unique way in which they approach testing, and so long as the end goal aligns, every mindset is valid. Collaborate and Cross-Skill refers to the notion that, while the industry encourages individual testing, understanding your team’s skills and working to complement each other can be helpful.

Ultimately, I think these principles can be summed up as be flexible, similar to how Agile works. A willingness to understand and use tools in testing, taking the human aspect into account, a willingness to approach things with a level of curiosity and questioning, and a willingness to collaborate with others, especially those with skills and expertise that vary from yours, are all examples of disregarding the rigid plans and processes. To do your best work, you must be willing to approach anything in multiple ways and with multiple mindsets. Having chosen this blog post because of it’s insight into testing, I definitely find myself agreeing with the overall principle behind this testing approach. I don’t know how much control I will have over testing in the future, but I would certainly like to apply a similar approach to how I test things in the future.

Blog Link: https://blog.scottlogic.com/2024/10/30/our-differentiated-approach-to-testing.html

From the blog CS@Worcester – Site Title by Justin Lam and used with permission of the author. All other rights reserved by the author.