Author Archives: Guilherme Salazar Almeida Nazareth

Takes on how to become an effective team

URL: https://www.youtube.com/watch?v=7zDX8VqvBa0

I came across another interesting podcast episode from Beyond Coding. This time, the episode I watched focused on Effective Product Teams, featuring Anne Kooijman, currently a Product Owner at Coolblue. The conversation between her and the host covered various topics related to team management and ways to build an effective product team.

The reason I chose this resource is that it provides real-world solutions to straightforward questions. The host, Patrick Akil, mentioned that he recently took on an assignment as a Project Manager. He asked many interesting questions, some of which I had myself.

A couple of specific points caught my attention, and I’d like to share them with you. The first was Anne’s perspective on what is required for a team to deliver quality work. She said, “Give them the necessary tools and the theoretical background.” I found this fascinating because you shouldn’t give developers half-baked solutions or dictate how to solve a problem. Doing so might make it harder for them to translate someone else’s idea into code. Instead, provide them with the necessary knowledge and tools to figure out solutions on their own and let them do it.

Another topic Anne discussed was how companies sometimes deviate from the core principles of Scrum and the potential outcomes of those deviations. She pointed out that there’s no issue with straying from what the “constitution” of Scrum dictates if it leads to improvements. This is intriguing because Scrum is meant to provide a framework, not a rulebook. Different teams consist of different people who may respond differently to certain changes. Personally, I imagine that I wouldn’t react well to constantly changing sprint durations.

They also discussed goal-driven teams and how having goals is essential for team effectiveness. This resonates with me, as it aligns with a practice, I adopted this semester. This isn’t meant to criticize how others manage their responsibilities but to connect the podcast’s ideas with my own experience. For the first time this semester, I decided to only consume entertainment during my free hours once all my tasks were completed. It sounds simple and cliché, but it works—just like Scrum. Teams need a singular goal, and the focus should remain on that goal.

This brings us to the final topic: timelines, and how even flexible and inconsistent timelines can be better than having none. This concept challenged something I’ve always believed—that if you’re going to do something, do it right and to the best of your abilities, or don’t do it at all. However, I realized that some flexibility in timelines is necessary to allow for adaptation and growth.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

Was it really all about frameworks?

What’s a Framework? All About Software Frameworks is an article written by Luke Stahl. I found it on dev.to, but it can also be found on the Contentful Blog. Links to both blogs are available in this post. The reason I chose this article is that I’ve heard a lot about frameworks since I started exploring web application development, and they always confused me. I used to struggle to understand what they were and what they were built for. Luke Stahl’s article answered both of these questions for me, though it also left me with a few more.

The article provides a general overview of frameworks for software development, web development, and working with APIs. However, it then pivots toward web development frameworks, which left me wondering about the differences between them. While it clearly explains the distinctions between backend and frontend frameworks, it misses covering some other differences I initially expected.

The author also includes a fairly extensive list of the benefits that frameworks bring to development, along with a brief list of challenges. For me, it’s always a bit concerning when something presents itself with so many benefits and so few downsides. Still, the benefits outlined are appealing and useful for developers.

Frameworks, as explained by Luke Stahl, are essentially blueprints or templates for a particular final product. They provide the essential building blocks and materials required to create your software or web application. A framework offers a skeleton for your application, allowing you to build functionality on top of it.

Halfway through reading the article, I began to wonder about the difference between a framework and a code library. Thankfully, and to my surprise, it seems Luke anticipated this question. He includes an explanation from two outside sources, David Fateh and Alvin Bryan. Both summarize that frameworks act as templates, while code libraries serve as tools you can use to build on top of that template.

One point that caught my attention—and that I believe is very important—is that most frameworks are FOSS (Free and Open Source Software). Being free and open source brings many advantages. Such products undergo extensive testing by a diverse group of programmers, across various applications, which increases the test sample size. This added testing leads to greater reliability, as it helps ensure that any new functionality works as intended. Another benefit of free and open-source products is the large community that often forms around them. This means that if you encounter questions or difficulties, it’s likely that someone else has already addressed them.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

Fecophiles and their stinky code

The blog post I chose comes from a widely known programming blog, The Clean Code Blog. The Clean Code Blog is written by Robert C. Martin (Uncle Bob). The post we will be discussing today was posted on January 20, 2012, and is called “Fecophiles”. The post focuses on two subjects: refactoring and code smell. It talks about a section of code that was refactored by someone and, oddly enough, received negative feedback from some of his coworkers. To clarify the rest of the post, Uncle Bob refers to “Fecophiles” as people who like to “smell” code. Amidst many harsh, and perhaps aggressive, comments about the coworkers’ reactions, Uncle Bob goes through 13 points proving that the original code under analysis “smells.” Screenshots of the initial code and Uncle Bob’s refactored solution can be found on The Clean Code Blog.

This post caught my attention for a couple of reasons, including how refactoring is helpful and how it addresses code smells. Refactoring is a technique that demonstrates how coding in teams or practicing peer coding is a good practice. Often, the way I see a problem and the solutions I come up with could be completely different from someone else’s. Not only that, but refactoring may also improve runtime, thereby increasing the code’s efficiency. There is always the possibility of a better way to solve a certain problem. A new solution might involve using different or more efficient techniques. A statement I always remind myself of is: “Two heads are better than one.”

On the topic of code smells, I will point out a couple of issues the code in question had. The code exhibited needless complexity and unnecessary repetition. The original code, before refactoring, checked the same condition two or three extra times. Because it repeated the same thing too many times, it became more complex than necessary.

But is such code really that problematic? I don’t think so. I could call it a different way of reaching the same point. Sometimes, the original code was simply an expression of the solution as the developer initially conceived it. The biggest issue is that it should not have been left that way. After writing down the solution to a problem, it may become easier to visualize a different, better approach. This is something I will apply to myself in the future—writing down the solution or coding it, but always reviewing it with the intent of making it cleaner and more functional.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

Performance Testing – should never be overlooked

URL: https://blog.scottlogic.com/2024/09/17/performance-testing-the-often-overlooked-ingredient-in-web-application-success.html

Performance testing—the often overlooked ingredient in the success of web applications—was written by Andrew Whitmell. In his post, Andrew explores a certain type of software testing method that he claims is sometimes overlooked. He also discusses various topics to show that performance testing is vital. One of his main points is that, over the years, users and companies have been seeking more and more performance. As Andrew demonstrates with various external data, better software performance leads to better business performance. The different topics presented by Andrew relate to the various benefits that performance testing brings.

I always try to break down my process of selecting something to read or listen to into steps. I do not like to base my decision solely on an article’s title, as it can be misleading. However, I tend to read the article’s title, open it, and also read the subheading. First, Andrew’s title caught my attention because he considers performance testing something that is often overlooked. In my opinion, performance testing should be a priority among testing methods. I chose to write about this post because it presents a different point of view from mine. An application, or the idea of an app, always arises from a need to resolve some kind of issue. Taking this into consideration, we can say that performance should always be a goal of any application.

I would like to highlight a couple of topics covered by Andrew, namely the identification of bottlenecks, the optimization of resource utilization, and SEO boosting. I had not heard of bottleneck identification as a method for improving application performance. Interestingly enough, I was talking to a friend of mine a few days ago about software runtime complexities. We discussed a well-known programming problem called Two-Sum, and he mentioned that utilizing hash maps for this problem improves the runtime complexity from O(n²) to O(n). Just as Andrew points out, the identification of existing bottlenecks in an application can enhance its performance.

The optimization of resource utilization involves testing the program under extreme conditions that are not expected to occur daily. The results from such testing will allow us to identify whether we can better utilize what we have or if we are overspending on certain services. I would also like to mention that SEO boosting is vital for large companies, but not as much for small or local ones. I have seen many local or small companies that do not necessarily provide a web application but have a website for their product. Most of those companies overlook SEO boosting. The amount of time users spend on a certain page depends on its performance, and SEO rankings are highly affected by performance.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

High Quality Software Development

Podcast URL: https://www.youtube.com/watch?v=alUfh7Nk4eE

The podcast I chose is presented by Patrick Akil, and this specific episode features Eugene Fidelin. Eugene, as described on his LinkedIn profile, is an Engineering Manager and Frontend SME at eBay Advertising. The two participants discuss many subjects related to high-quality software development, including topics like bug prevention, testing, the balance between speed and quality, team performance, and many other subjects. One piece of advice, in case you would like to listen to the podcast, is that its timeline on YouTube is broken down into various topics, making it easy to find a specific subject

Many times, I start reading an article or listening to a podcast, and it does not hold my attention. However, this podcast kept my attention throughout its entire length for two reasons: the way it is produced and the way the topics transition from one to another. It is not very technical, which makes it easy to understand, and it dispenses the need for visual aspects deliver all the information. It feels very much like a conversation between two people who enjoy what they do.

While listening to the podcast, I took notes on a couple of topics and phrases that caught my attention. Right in the first few minutes of the podcast, Patrick and Eugene discuss resilience and predictability. They make a great point, stating that every program’s goal should be to be both resilient and predictable. However, creating software that is completely resilient can make it difficult to modify, meaning that adding or changing something could break a certain part of it.

The last three topics that caught my attention are all about testing. I believe they interested me most because I have not delved deeply into any kind of testing. The first topic is about good practices for testing programs, which includes testing the frontend and the API separately, and then running tests on both together. Another interesting topic related to testing is observability over prevention in edge case tests, meaning that sometimes observing behavior over time might be more beneficial than running tests on edge cases, especially since continuous testing of such cases may slow down the testing process. Another great comment was about which type of test to use for either frontend or backend; not every type of test will fit every backend, and not every type of test will fit your frontend design.

I plan to use this advice and these practices in my career to achieve better results. I would also like to highlight another topic mentioned at the end of the podcast: not every person fits every team. It takes more than just a resume to determine if someone fits the team’s style.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

Week 2 – Clean Architecture

Article URL: https://dev.to/moh_moh701/part-1-what-is-clean-architecture-4bn1

The article chosen, written by Mohamed Tayel, discusses a software design philosophy introduced by Robert C. Martin (Uncle Bob) called Clean Architecture. Mohamed’s article explains what Clean Architecture is and why it could be a good software design option. The goal of Clean Architecture is to create and build systems that are easier to understand, flexible in terms of scalability and modifications, and easy to maintain. Initially, he presents the main objective of Clean Architecture and later discusses the design’s principles, benefits, and key components.

Interestingly, Robert C. Martin’s (Uncle Bob) blog was one of the blogs I discovered a couple of weeks ago while searching for articles on Object-Oriented Programming. His blog contains a lot of great content and well-written articles on various Computer Science subjects. However, that is not the reason I picked this specific article to discuss today. After reading the first paragraph, I found myself engrossed in the article until the end. I have always been interested in finding ways to make my own code more readable and easier to maintain. I have been amazed by how Object-Oriented Programming, based on its principles, is very organized, making it easy to understand and modify. Clean Architecture seemed to me like a way to achieve similar benefits from Object-Oriented Programming in programs not built with languages that support it.

I honestly believe that Clean Architecture’s goals can be applied to any program. I am not trying to undermine Clean Architecture’s merit as an excellent way of designing programs, but I truly think that every program should be planned and built to achieve the five benefits Mohamed Tayel mentioned in his article about Clean Architecture:

  1. Improved Testability
  2. Flexibility
  3. Maintainability
  4. Reusability
  5. Scalability

I plan to incorporate its objectives and main characteristics into my next programs. Especially by applying two of Clean Architecture’s principle, flexibility and improved testability. Flexibility consists of building a software that can support changes to it (e.g. replacing a database or a web framework) with minimal impact to other parts. And Improved Testability consists of “decoupling the business logic from external dependencies, to achieve higher test coverage” (Mohamed Tayel).

Clean Architecture seemed to me as an attempt to implement certain Object-Oriented Programming principles in software built with languages that do not support it. Clean Architecture breaks down software into four layers: Entities, Application Core, Infrastructure, and User Interface. By breaking down the software and having each layer encapsulate another, it is very similar to OOP design.

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.

Hello World!

This is my personal blog…

From the blog CS@Worcester – CS Today by Guilherme Salazar Almeida Nazareth and used with permission of the author. All other rights reserved by the author.