Author Archives: Guilherme Salazar Almeida Nazareth

Apprenticeship Patterns

I am honestly not the biggest reader; it is something that I have not tried to develop as a hobby. Although there were a couple of books throughout my life that caught my attention deeply, I never developed reading as a hobby. Chapter One of Apprenticeship Patterns lit a spark of curiosity in me. And I believe the reason this event happened was the following statement:

“A willingness to experiment and be proven wrong. This means we try stuff. We fail. Then we use the lessons from that failure in the next experiment.”

The statement that I mentioned reflects and describes deeply how I feel about software development in general. This section has brought me back to what made me fall in love with coding in the first place.

Most of the time, we see people choosing the path of Computer Science as a way to make money. And there is definitely nothing wrong with it, although for me, it is not about that. I truly feel like an apprentice, with an aspiration to be a journeyman. Learning new skills and techniques each and every day intrigues me. It is, in my opinion, the broadest subject there is. The text has enlightened me towards a greater understanding of how my journey could be. I understand that this journey is not short by any means, but it will be a long one. And honestly, I would go even further—I believe it may never end. We are always learning, improving, becoming better. Better than our colleagues? No, better than ourselves. This should be our goal: to become a better software developer than we were yesterday.

There was only one chapter that changed my opinion on a topic. Chapter 6, Construct Your Curriculum, showed and answered a question that I have had for a long time. Being part of a new generation that has access to basically any information, I have sometimes struggled to grasp the deep reasoning behind why certain things in Software Development were done in such a way.

Books, books, books—these are the key to understanding the deep meanings behind how everything was built.

My reading of the introduction portions of the book became a journey itself. I started my reading with an idea and ended it with a completely different one. Not being the biggest reader and having never developed the habit in my life, I now find myself more willing to read. To understand and be willing to start a new routine of reading more books.

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.

Introductory Post

Hello World!

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.

Collaboration is key

URL: https://getdx.com/blog/software-collaboration/

During this past semester, I learned more about what collaboration is and why it is so important. Collaboration is something that I personally find essential and key in software development. However, this semester, I learned the hard way how problematic the lack of collaboration from someone can be and how harmful it can be to a team. It doesn’t just divert attention from the focus, but it also disrupts the workflow and creates unnecessary stress. I don’t say this because I am the most collaborative person—believe me, I’m not. At times, I can be a difficult person to collaborate with. But through experience, I learned an important lesson: when team members don’t collaborate effectively, progress is slowed, creativity is hindered, and learning opportunities are missed.

You might ask me, “How would you bring together four or five different people from diverse origins, cultures, and sometimes even languages, and make them work seamlessly as a team?” Well, I don’t expect perfect communication or total synchronization—such perfection is simply unattainable. However, that doesn’t mean that everyone shouldn’t do their best to contribute. Does this mean the solution is cherry-picking people with similar backgrounds, races, and beliefs to simplify communication? The answer is still no. The strength of a team lies not in how similar its members are but in what they can contribute and their shared desire to grow and succeed.

Diversity within a team is also essential for solving complex problems. Individuals with different experiences and perspectives can offer unique insights and approaches that others might never consider. When people bring their varied backgrounds and creativity to the table, the possibilities for innovation and success increase significantly.

Ultimately, what matters most is the effort and willingness of each team member to collaborate and complete the work. Agile methodologies and Scrum are two approaches that I have found particularly effective in fostering a culture of communication and collaboration. Frequent check-ins, meetings, and milestone-based planning make it easier to stay aligned and on track as a team.

One blog post I came across this semester made me reflect on the importance of addressing issues directly. Ignoring problems, whether personal or within a team, doesn’t make them go away; it only exacerbates them. This realization pushed me to focus on self-improvement by being more open to new and different ideas. Even if an idea isn’t the most ideal solution, it can still lead to success.

Finally, open-source software is something I was unfamiliar with before. Now, I’m eager to contribute to such projects, especially those aimed at making a positive impact on the world.

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.

How unpredictable bad code can be…

URLs:
Article on SOLID: https://www.freecodecamp.org/news/solid-principles-explained-in-plain-english/
Video mentioned: https://www.youtube.com/watch?v=j-6N3bLgYyQ

One video has always caught my attention because it clearly illustrates why SOLID principles are so important. I will reference two sources in this post for better understanding, in case you want to explore the topic further. However, I kindly ask you to watch the video linked at the beginning for my comments to make sense.

I chose an article to complement the video because it offers a more approachable explanation of SOLID principles and, as stated, explains them in plain English. The video features a dad following instructions from his kids to make a peanut butter and jelly sandwich. The issue here is that such a task may have become so automatic for us that we no longer think about every single detail involved.

How is that related to programming and SOLID principles? Well, it’s quite similar. At its core, code consists of lines and lines of instructions written for a machine to execute. To achieve the intended goal, these instructions must be precise and correct; otherwise, we can encounter numerous issues. As the video demonstrates, the lack of precision in the kids’ instructions led to some funny outcomes: first, the dad stacked two slices of bread on top of each other without doing anything else. In another instance, he ended up with a piece of bread with a “bit” of peanut butter on it, a whole bottle of jelly, and another slice of bread on top.

Did I just make a typo by saying a bottle of jelly was between two slices of bread? No, that did happen. This highlights what occurs when you assign certain instructions—or, in programming, functions (Single Responsibility Principle)—more than one purpose or intent. While a peanut butter and jelly sandwich recipe might not fully embody all five SOLID principles, the Single Responsibility Principle (S in SOLID) alone is enough to demonstrate the importance of clear and focused design in coding.

The lack of clarity and precision in the sandwich instructions led to various unwanted results. Although the instructions made sense to the kids, they didn’t work well for anyone else. Similarly, when writing code—whether for homework, work, or even personal projects—these principles should never be overlooked. I believe following such practices is part of a developer’s ethical responsibility.

At the end of the day, even if I’m the one reviewing my code a year later, I might struggle to understand it without proper adherence to these principles. You might wonder, “How is it possible not to understand what you wrote yourself?” Well, that’s exactly what happened to me yesterday while refactoring some old code. I encountered several parts that I couldn’t make sense of, so I had to revise and apply these principles to make them comprehensible.

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.

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.