mfbmina.dev

After reading the book the Goal , I went after the next reading, and I was recommended to read The Mythical Man-Month, from Fred Brooks. This book is a computer science class, which I didn’t know yet, that describes the software development life cycle in the 70s.

The book’s main subject is told at the title: the mythical man-month. Man-month is a productivity metric like the ones that are used today, such as points, t-shirts size or whatever that is being used. The argument is the metric is failed and number of tasks, line of codes or features developed by someone aren’t constant between projects.

Nowadays, a huge part of a developer’s work consists in calling APIs, sometimes to integrate with a team within the company, sometimes to build an integration with a supplier.

The other big role in daily work is to write tests. Tests ensure (or should guarantee :D) that all the code written by us works on how it is expected and, therefore, it will not happen any surprises when the feature is running at production environment.

At the developing world, it is necessary to know how the application that you’re working on is behaving, and the most known way of doing that is by metrics. They can be of several types, such as performance, product, or health. Nowadays, Prometheus is the market way for collecting metrics.

It is an open-source service maintained by CNCF , the Cloud Native Computing Foundation. It works like the following: an endpoint is exposed, and it responds with a desired body format. Then Prometheus calls this endpoint time to time, collecting all the information from there.

At the end of 2023, my squad started its most important project. I assumed the project leadership role, organizing the project, coordinating the meetings, the release process, etc. At the first months, the project went well, as we took some hard decisions, proved a couple of concepts, and started the rollout for the first phase.

However, I always felt that I was holding the team back and being a bottleneck in the whole team. At a 1x1 with the head of the area, I told him about my frustration and got this answer back:

The first time I heard about RPC, I was in a distributed systems class while completing my bachelor’s in computer science. I like it but didn’t fully understand why I should use it instead of REST. Time passed, and I started working at a company where the legacy services use SOAP. I remember thinking: “hm, that’s cool! It is like RPC but using XML instead! Years later, I heard for the first time about gRPC, but I’ve never fully understood it until now!

When I chose to pursue a career in computer science when I was 15 years old, it was basically on liking math and physics. I want to distance myself from writing posts, essays, etc. Time goes by, and now, one of the things that I value at a mature company or team is the existence of technical documentation.

Docs help us to gain historical knowledge of our company, reevaluate decisions, and comprehend the trade-offs between all the decisions. It is also beneficial for the newcomers because it tells them a story. The richer in detail it is, the better it is.

Today it is common for our applications to have a couple of dependencies, especially when working in a microservice environment. It isn’t rare when our app reports errors, we find out that one dependency is down.

One good practice for improving our resilience is to shut down the communication with those apps that are not behaving well. Looking into other fields, we learned the concept of circuit breakers from electrical engineering, where a switch turns off when a failure happens. In Brazil, all houses have these switches that automatically shut down if our electric network becomes unstable.

Building a game is an excellent way of starting programming. Tons of people have started programming because they wanted to create computer games. Even me, back in 2010, had one of my first projects to write a small game when I was still in my Technician course.

In this course, we used Python to develop a slide puzzle. It was very challenging because I had to learn about the game mechanics and GUI, but I could handle the project. When I started to work with Ruby, I also built one to compare with what I did with Python.

Linter is a static code analysis tool used to find programming errors, bugs, leaks of code standards, and even security flaws. These tools help developers because they save time by identifying issues before they happen in the production environment. It also keeps developers from unnecessarily checking if your colleague used the team standards.

Each programming language has their own tools: Ruby has Rubocop , JS has Eslint , and Go can’t be different. Searching at Awesome Go , a curated list of Go software, many tools can lint your code, but my favorite is golangci-lint . It is an aggregator of linting tools, meaning you only need one tool for multiple linters in your project.

Computer and programming languages were born to make our lives easier, as they automatize day-to-day tasks. Programmers and software engineers usually have to build files that are almost the same as others, where the only change is one field or another. For example, there are configuration files, invoices, XMLs, HTMLs or any file which we can use to build other files. There is a simple solution for this problem: we can create a template and change the parts that I need manually! That works, but it is not the best way to deal with the problem because it is scalable. We can use technology to help.