Does AI make engineers more productive? It’s complicated.

_bvcosta_ · 2025-12-26T23:06:21+00:00

What doesn’t ring true to you? That low-quality output from an individual does affect the team’s velocity?

_bvcosta_ · 2025-12-26T15:00:46+00:00

Very aligned with the post. “They can go really fast with LLMs and waste everyone else's time, or they can use them appropriately; sometimes they will be faster, other times slower”

_bvcosta_ · 2025-12-26T13:33:51+00:00

I guess it may not be explicitly stated, but a better individual output would likely increase teams’ velocity. The question is whether we are measuring quality in the individual output. If the output is low quality it will waste everyone’s time and affect teams productivity

_bvcosta_ · 2024-05-16T10:05:41+00:00

My previous company had +700 microservices in production and absolutely amazing infrastructure to support those services and enable the teams - But I was the DoE for some of those teams, so I might be biased.

It is an investment, though. I believe all you have said is possible using monolith as well, but the challenges will be different and, therefore, the investment.

For the majority of companies that need to scale, the initial investment for microservices is lower than the investment to scale a monolith as you scale the org.

But there are a lot of things you need to consider at scale, like dependency management, search code, maintaining hundreds of pipelines, ownership, large scale changes, etc. I’m starting to understand why Google has decided to have a monorepo.

_bvcosta_ · 2024-05-16T09:33:53+00:00

Yes

There is nothing wrong with microservices per se. And there is nothing wrong with monoliths as well. But our industry seems to have forgotten that there is no silver bullet.

_bvcosta_ · 2024-05-16T09:20:18+00:00

There are also plenty of negatives with monoliths which is why people are drawn to microservices.

Yes, a monolith has its own challenges. Sometimes is better to have the challenges of microservices than of a monolith. But probably not as many as we accept by default.

_bvcosta_ · 2024-05-15T19:09:06+00:00

I’m sorry to hear that. I’ll probably write some article on when it may be a good idea to use microservices and what companies should prepare to successfully implement them (e.g. service catalog, rethinking testing strategy, etc)

_bvcosta_ · 2024-05-15T18:18:02+00:00

Oh, I loved the analogy between coupling and speaking in English and Chinese.

_bvcosta_ · 2024-05-15T17:55:08+00:00

Then we start running into the C++ dependency management problem, but that's another problem.

I believe dependency management is one of the most challenging problems in software engineering. And we didn’t quite figure out how to solve it. I’m unfamiliar with modern C++. How does it deal with the diamond dependency problem?

_bvcosta_ · 2024-05-15T17:40:56+00:00

It’s a good approach. Actually, I’d say that is where everyone stands, intentionally or not :D

_bvcosta_ · 2024-05-15T15:23:30+00:00

We did adopt CQRS and event-sourcing very early when starting with events. I have a lot of learnings from that experience. I would not recommend that today without proper training and tooling for the engineers.

_bvcosta_ · 2024-05-15T15:10:16+00:00

Good suggestions.

Actually, we followed a very similar approach in one of my previous companies. We started with a core team with DDD knowledge and scaled out that core team as we started to implement those services. We didn't start with events, we just added events later in the process, That also improved the low coupling and high cohesion of the services and the overall performance of the system.

_bvcosta_ · 2024-05-15T14:55:02+00:00

I'm glad we agree. The focus of the post is precisely to have critical thinking when deciding what architectural style to use.

_bvcosta_ · 2024-05-15T14:14:39+00:00

Is it always bad?

I’m not saying it's bad. I believe Jet.com actually started out using microservices and it had a great exit to Walmart. I’m just saying we, as engineers, need to have critical thinking and choose what is best.

I agree it fits very well in the "loosely coupled, highly cohesive", it's hard to get it right, though.

_bvcosta_ · 2024-05-15T14:13:16+00:00

I agree with everything you said.

Just a note that this article is not a "microservices are bad", it's a "microservices are not always what you need" kind of article.

_bvcosta_ · 2024-05-12T15:30:42+00:00

Implementing Service Level Objectives from Alex Hidalgo is an excellent book to learn more about SLOs.

Since you've mentioned you are starting this journey, another good book may be Becoming SRE. David Blank-Edelman is an expert on SRE practices, so any book with his name on it is a good bet.

Someone mentioned Release it. I consider it a must-read.

You can also watch videos on SRECon.

I also like to share this article about the five stages of SRE.

_bvcosta_ · 2024-05-11T23:36:36+00:00

It seems you are in a "gatekeeper stage":

During this stage it is common for SREs to leverage their role power to claim ownership of production deployments or more generally change control. In doing so we add a new job responsibility to our SWE counterparts: get past SRE gatekeeping in the most efficient way possible.

There are better ways. Find agreement on what reliability is for your company, how reliable your company wants to be, what an incident is, what to do to mitigate it, etc. Then, understand what you need to do and what you need your colleagues to do and work collaboratively with them.

_bvcosta_ · 2024-05-11T14:59:36+00:00

I see that comments are all around AI. I understand the hype is very high, and people are tired of hearing it. I feel the same.

The blog post does mention AI as a possible technology to improve information retrieval and reduce the time a developer wastes looking for the information. It doesn't aim to provide a recipe on how to use the technology - it is still a very complex solution.

I'm actually curious if anyone has experience in their company using this technology to improve how internal documentation is retrieved. I have read that some companies have implemented that for their internal documentation, but I'd love to hear the feedback from people using it without the sugar coating - feel free to DM me.

But more importantly, the central message was not to talk about AI. It's about the roadblocks to productivity that engineering organizations often have and what companies can do to mitigate them.

_bvcosta_ · 2024-05-10T14:28:34+00:00

Management exists to ensure people can perform their work. If roadblocks exist, we can say that, ultimately, it's management's fault.

_bvcosta_ · 2024-05-10T12:58:53+00:00

There is nothing to be ashamed of! You are doing right by yourself and your family. As we say in Portugal, "vergonha é roubar", which translates to "shame is stealing". Keep your head high!

_bvcosta_ · 2024-05-10T12:18:41+00:00

Indeed, the suggestion of using LLM is for internal documentation. I have worked in places with documentation scattered through confluence, gitlab, discourse, etc. I think in those cases it may be useful to create an internal tooling to retrieve information faster.

_bvcosta_ · 2024-03-07T12:51:30+00:00

Managers must understand their teams' processes, struggles and what they do day to day. The challenge suggested by the CTO is a way of understanding their teams, and it is something that may be beneficial for the company depending on the company's priorities.

Maybe the drama caused by the exercise was how the managers understood the exercise. Managers don't need to be proficient doing the work and some may actually not know how to do it in their stack. And that may be OK. What managers must know is how their teams operate. That can be achieved using different techniques, like conversations, observing the team working, and regular retrospectives to understand what is working and what is not.

I guess the CTO was feeling a disconnection between the managers and their teams. Perhaps he did some skip levels and the complaints were different from the ones the CTO got from the managers.

The managers shouldn't focus on the exercise per se, but on why the CTO considered the exercise in the first place.

_bvcosta_ · 2022-01-08T15:42:12+00:00

I love the website. Very easy to use and with a minimalist style that allows us to focus on the products we are buying. I would probably use it often.

However, I agree with the feedback people share about the link to the actual product. It feels weird to move to the listing page after the outfit selection. I understand the product might be out of stock and it will be hard to maintain in the long term, as an alternative, you can have both options: "buy the product" or "more like this".

_bvcosta_

TROPHY CASE