Decodifique Blog RSS Feed

My Career Midpoint, Part II

Mon, 28 Sep 2026 00:00:00 GMT

Prologue: Experts and privateers

In my last year of college, talking with a classmate, she told me she had been working at a biometric security technology startup, and that they were looking for a .NET programmer to build software using that technology for service kiosks, web sign-in, and mobile apps.

By then, I was already working at the Forensic and Scientific Police department of São Paulo as a web programmer, on a GED (Electronic Document Management) system built in CakePHP and MongoDB, though already a bit unsure it would have a long life there. Let me explain: I had left a consultancy that had its own in-house framework, only to now work with a technology that also wasn't very attractive to the market, like PHP.

Since the office on Faria Lima was close to the Superintendency's, I negotiated with the biometrics company's manager to work part-time, in the afternoon/evening shift, balancing it with the Superintendency in the morning and early afternoon.

My negotiation went well, and I kept up that double-workday rhythm for six months, until, one day, I witnessed a rather peculiar moment of the public sector at the Superintendency: the bidding process. The outsourced software consultancy's contract was expiring, and a new bid would be opened to decide who would take over the service from then on. That uncertainty over who would win the bid had been hanging over all the outsourced staff for weeks, stirring up all sorts of expectations and fears, especially the fear that the project wouldn't continue. A new company won the bid that had been opened. The winner could choose whether or not to rehire the outsourced staff already there, but that's not what happened. Given that, the company I was contracted through gave me two options: send me to a project in Alphaville, in Barueri, or let me go. I chose the latter.

Uncle Bill, finally paying the bills

Once I was let go, I started working fulltime at the startup, in early 2016, my first experience as an independent contractor too. After an office move to Vila Olímpia, I found myself right in the middle of the startup boom and did a lot of networking with companies across the pharmaceutical, healthcare, and fintech sectors, and other digital products on the rise at the time, like cryptocurrencies, overseas asset brokers, and all sorts of sharing economy platforms, riding Uber's wake, trying to become unicorns, with a lot of private equity capital flowing in.

Unicorn companies "are start-ups (early-stage companies with a repeatable and scalable business model through technology) that have reached a market value of US$1 billion — at least" [1].

Around that time, I also started an MBA (Master of Business Administration) in Software Engineering at the University of São Paulo's Polytechnic School, but I won't go into more detail so as not to open a huge parenthesis in this prologue — it's just worth mentioning that the point of the MBA was to earn a graduate-level lato sensu degree.

During my time at the startup, I ran into much more interesting challenges than before: I started actually using Git in my workflow, and I finally got to work with the whole, and only the, Microsoft .NET stack: Windows Forms, on versions 4.6.x at the time, C#, REST APIs (Application Programming Interfaces / Representational State Transfer) in ASP.NET MVC Web API, and WPF (Windows Presentation Foundation). Let's break it down:

Figure 1. The WPF visual designer in Visual Studio, with the MainWindow's XAML on the left and the interface preview on the right.

.NET Framework: Microsoft's development framework, Windows-only, the foundation for the technologies below.
Windows Forms: framework for building graphical interfaces for Windows applications, drag-and-drop style.
C#: strongly-typed, object-oriented programming language developed by Microsoft.
ASP.NET MVC: web framework for building web pages via the Razor markup syntax; SOAP APIs (Simple Object Access Protocol), through the WCF (Windows Communication Foundation) extension, or REST, through the Web API extension.
WPF: framework for building graphical interfaces meant to replace Windows Forms, also drag-and-drop style, but with a markup syntax through the XAML (Extensible Application Markup Language) language, based on XML.

Figure 2. The evolution of the .NET Framework: each version stacked new libraries on top of the Common Language Runtime.

That's exactly where I found myself, working with the tools I was genuinely interested in, in a period of intense learning in technology, both from working with what I liked and from being in an environment where, with practically no team, it was just me as the backend programmer and one colleague responsible for the Android app development. I had total creative freedom to decide how to apply engineering techniques that were new to me, like automated tests (unit, stress, and integration) and design principles, like SOLID and layered project separation. It was also in those years that I got into a richer set of readings, like the The Pragmatic Programmer series, by Andy Hunt and Dave Thomas, and the books by Robert C. Martin, The Clean Coder and Clean Code. It was also during this period that I attended many tech events, like TDC (The Developers Conference) and several meetups.

A few months later, after running into some personal obstacles, by mutual agreement with the company's management, we decided to end the service contract I provided, and I went back to testing the market once again . With considerably more experience and background under my belt, now fluent in the Microsoft stack, I quickly landed somewhere new: a consultancy whose main line of business was the insurance sector, and I was assigned to one of its biggest clients.

Orchestrating alphabet soup

The change, starting in the second half of 2016, was a big one: leaving the startup world for my first experience in the corporate world, with bureaucracy, processes, decades-old system integrations, dozens of teams just within IT, and technology restricted to a select group of companies, with knowledge just as secretive, like a cult. While I had built up technical knowledge from my previous experience, the lack of a team left me weak in political skills and teamwork. Now I'd have to work with developers far more experienced than me, with knowledge already well established in the business domain, especially when it came to claims rules.

Because I had a good command of .NET and learned fast, I was picked to take part in a high-visibility project at the company: rolling out the Oracle SOA Suite (Service-Oriented Architecture) platform, managing and orchestrating integrations between the various claims modules, and building a workflow interface so analysts and the approval chain could analyze, evaluate, and rule on claims and settlement processes.

This was a fairly complex project, since it involved migrating business rules from a monolithic in-company system, partly built in VB.NET, partly in ASP (Active Server Pages, which I really thought I'd never see again, a relic from the late '90s), over to components on the Java J2EE (Java 2 Platform, Enterprise Edition) platform, like servlets and EJB (Enterprise JavaBeans), and to the middleware itself: the ADF (Application Development Framework) interfaces for Human Tasks (an Oracle take on JSF, JavaServer Faces), the Mediators, for routing, filtering, and transforming data between different components, BPEL (Business Process Execution Language) and BPMN (Business Process Model and Notation) for orchestrating services and tasks, and the Business Rules, for building a set of rules executed at runtime, separately from the application code. Not to mention integrating with legacy systems via SOAP (Simple Object Access Protocol), WCF again, and its whole XML specification: XSD, XSLT, and XPath. I'll admit it: it's an alphabet soup of letters and terms. But it goes even further: all of this connected to on-premises Oracle 11c or 12c databases, versioned partly in SVN (Apache Subversion) and partly in Microsoft TFS (Team Foundation Server), both centralized version control models.

Figure 3. A BPEL process in Oracle JDeveloper, orchestrating calls between services.

The quality leap

I did well, and quickly mastering that enterprise stack from Oracle earned me recognition. My situation improved: I got an offer to be brought on staff by the company, in mid-2017, no longer outsourced and now enjoying a career plan and better benefits. Taking advantage of that improvement, it was finally time to leave my studio apartment and rent my first real apartment. I also finished my MBA, and, catching myself reflecting on everything I'd been through, I realized that, at that point, life really had taken a big leap in quality.

Figure 4. One of my theoretical study sources on the Oracle Suite toolset was this small 900-page handbook.

I spent the next two years in a steady routine of hard work at the insurance company, on my Workflows team. Curiously, that skill with orchestrating APIs (Application Programming Interfaces) would turn out to be quite valuable in future projects. The new phases of the SOA project kept expanding into new areas: I built management dashboards and updated some of the company's technologies, at the request of the American headquarters.

But work alone wasn't enough. I kept up a steady study routine, reading about Agile, Microservices, Enterprise Integration Patterns, and other software architecture topics, until I felt challenged to go for Microsoft certifications. To do that, I built a study routine based on Microsoft's own Exam Ref books and supplementary materials from Packtpub. In a year and a half, I earned three: the MCP (Microsoft Certified Professional), the MCSA (Microsoft Certified Solutions Associate), and the MCSD (Microsoft Certified Solutions Developer), in the areas of C#, ASP.NET MVC, and Windows Azure.

Figure 5. My Microsoft Certified Solutions Developer badge, earned in 2019.

These badges may have little practical use nowadays, but the challenge of studying and going deep into topics that often get overlooked is an incredibly rich form of learning. Not to mention that, for me personally, it was my starting point for consuming material in English. Before that, I don't remember ever having read and studied 500-page books in another language. I'm grateful I made that call.

Back to square one, and new uncertainties

With all that knowledge in .NET development, Azure cloud, and also in SDLC (Software Development Life Cycle) tools, like VSTS (Visual Studio Team Services), later renamed Azure DevOps, I was called, in early 2018, by my very first employer, to provide external consulting on a new solution they were building: an omnichannel sales system, built entirely from scratch with Microsoft technology. I took on the challenge and pushed them toward building the architecture for this new solution, based on microservices, already on .NET Core 2.0.

I kept working both fronts in parallel, and in 2019 I opened up a new one: I started a Master's in IT at PUC-SP (Pontifícia Universidade Católica de São Paulo — Pontifical Catholic University of São Paulo), presenting a research project on the Internet of Things applied to São Paulo's basic sanitation, driven by the wish to one day have the chance to teach at a university.

I'd been at the insurance company for 3 years and a few months by then, and I felt a certain disconnect between my career expectations and how I was being valued professionally. I decided that this was the moment for another change, and, a few months later, I'd change contexts completely once again — and, of all things, go back to a startup-flavored company, but now taking on a different industry: healthcare. I could say I was pretty much a senior programmer by then, at least in attitude, with a lot more experience and exuding confidence in my technical skills and my ability to work as an individual contributor, thanks to the intense routine of juggling two completely different projects in technology, scale, and challenges.

I didn't know it yet, but once again the shot would miss its mark. And at an extremely delicate moment, too, since the year was 2020, just a few months after the first recorded case of SARS-CoV-2, in China [2]. From then on, nothing would be the same.

References

My Career Midpoint, Part I

Mon, 21 Sep 2026 00:00:00 GMT

Prologue

In September 2026, I completed 15 years of a career in Information Technology — my Crystal Anniversary. That was enough time to accumulate stories and experiences spanning the job market and academic life. I decided to revisit these memories and write down lessons and curious stories, protecting the people involved as much as possible.

Figure 1. 15 years of career, my Crystal Anniversary.

I could open with a preface about the period before my first formal job — the Technical IT Course and my first experiences with computers — but that chapter is for the future.

This story will have three main parts, milestones I consider important, spanning several years each, with a filler period between them: smaller stories, but no less interesting to recall.

As it couldn't be any other way, we'll start with the call to adventure.

Interns, wind pastries, and cemeteries

In June 2011, having been accepted into the University for All Program (PROUNI) with a guaranteed scholarship in São Paulo to study Information Systems, I made my first major decision: leaving my parents' house in the countryside to live in the capital, at 17 years old. I was already in my first semester of Systems Analysis and Development in my hometown, but nothing compared to the change in routine, scale, and challenges that came in the first months of this new life.

Studying alone wasn't enough. Every day I faced more than 100 km of round-trip travel, from Tatuapé, in the East Zone of São Paulo, to Cotia, in the São Paulo Metropolitan Region (RMSP). In those first months, I was taken in by my aunt on my mother's side, Cida, to whom I owe immense gratitude. She certainly worked as hard as I did and, despite being strict, is an extremely protective person.

This commuting challenge, on top of the routine at home, forced me to go after a job: make use of the daily trip between home and college to earn some income, gain my own independence, and save on commuting hours.

Searching on the sorely missed APInfo site, I sent out résumés for internship openings right in my first month of college. The first interview, luckily, landed me my first paid job, in September 2011: a small software consultancy, but with a big Enterprise Resource Planning (ERP) contract — a business management system — for an importer and retailer of clothing, footwear, and accessories.

As an intern, I earned a salary slightly above minimum wage at the time (R$545.00) and a stipend, a kind of cash meal allowance (VR). For a 17-year-old who previously had nothing, it was a big win.

That said, my productivity and focus — especially in calculus classes and during my ramp-up at the company, where I needed to work much harder to absorb the knowledge — were affected by the long commutes: for a few months, I left home at 5:30am to get to work, in the South Zone, by 10am, where I stayed until 5pm. Before college, I had a mandatory stop at a pastry stand in front of a church: a friendly pastel with some vague memory of a filling, for about R$4.00, always backed up by guava-flavored starch snacks in my backpack. Then I headed to college, in the East Zone. On the way back, the connection to Line 4 was already closed, so I'd catch the bus in front of Cemitério da Consolação and walk the entire length of Cardeal Arcoverde on foot, past sketchy bars and disreputable establishments, all the way to Largo da Batata, where I'd board one of the last two intercity buses, at 11:45pm or 12:10am. I'd get home, lie down, and a few hours later, start all over again.

Bigger than the paycheck, though, was the learning in that consultancy environment, where every developer did a bit of everything: building features, finding and fixing bugs, touching databases and infrastructure, working alongside people around the same age with plenty of willingness to put out fires. The business complexity spanned every area of a mid-sized company: inventory, logistics, tax, price tables, sales, Points of Sale (POS), and accounting.

Windev, French Rapid Application Development

The technology we used at the time, Windev, already felt a bit dated: a Rapid Application Development (RAD) environment, in which we built the ERP and the Point of Sale (PoS) applications. The tool abstracted away the more popular frameworks of the time, Java and the .NET Framework, with a proprietary framework: its own IDE, its own language, and its own database, though it came with connectors for other providers. In our case, we used Microsoft SQL Server as the Database Management System (DBMS).

Figure 2. The Windev IDE interface.

Windev is an IDE built by a French company, PCSoft, with an integrated environment for developing desktop, web, and mobile applications: a proprietary language, WLanguage, its own database, HyperfileSQL (HFSQL), and interoperability with other languages and databases via APIs and drivers.

Some of its quirks come from the IDE's own design choices, which are quite an acquired taste, and from its proprietary language, a product of its era: a fourth-generation language (4GL). The idea was to speed up development by automatically generating artifacts once a database was hooked up to the project: the metadata became an abstract model called Analysis, similar to the .NET Framework's Entity Data Model, and from it, reports and screens could be generated with just a few clicks — something like SAP's Crystal Reports, or Oracle's ADF for rich interfaces.

In practice, this meant I didn't need to deeply understand databases to ship a working screen, which, looking back, was both good and bad at the same time.

The language also offered automatic data fetching: you just iterated over collections with bindings to the data model, and the metamodel took care of translating everything into database queries, whether HFSQL or another compatible engine, via OLE DB/ODBC connectors.

A simple example: searching for a customer by name, followed by iterating over the resulting collection, without writing a single line of SQL.

// Look up the first customer named "João"
HReadSeek(Customers, Name, "João")

IF NOT HFound(Customers) THEN
    Info("Customer not found")
    RETURN
END

// Iterate over all matching records
FOR EACH Customers
    sName = Customers.Name
    sEmail = Customers.Email
    nID = Customers.CustomerID
    Info(nID + " - " + sName + " (" + sEmail + ")")
END

Naturally, this created performance problems and hidden database behavior, since this kind of abstraction favors best-effort even at the cost of poor index usage and unoptimized queries. The result was chaotic situations in scaling scenarios, or wherever there were performance constraints, like in user-facing applications at the sales terminals. In those cases, we often fell back on Stored Procedures written in Transact-SQL to run the more expensive operations, like calculating cash flows, reprocessing inventory or price tables, and generating salesperson reports.

During this period, the software we delivered had a fairly artisanal character: specs and bug reports gathered in hallway conversations, over the phone, or in endless email threads. This forced us to build and maintain our own in-house service desk to collect issues and problem reports. Having always had a creative streak, I took on supporting this system to keep evolving it, building features, reports, and dashboards, and improving our day-to-day work.

Although Git had existed since 2005, my experience with source code management was still quite rudimentary: shared network folders with no versioning, and later a centralized version control system (CVS, Concurrent Versions System) from Windev's own vendor, which more than once corrupted our file history and forced us to fall back on physical backups. Deployments followed the same artisanal logic: zipped builds, transferred over FTP, with access configuration in plain-text .ini files. That was our reality for years.

Old-school PHP and other projects

Besides the ERP and its PoS system, the consultancy also worked on smaller projects, like e-commerce sites and hotel management systems. Those had more flexibility around technology choices, and we even used PHP and MySQL on the LAMP stack (Linux-Apache-MySQL-PHP), already on its last legs in the market, which kept moving toward the Node.js and nginx stack, even though we stuck with LAMP.

At the time, knowledge of frameworks in the PHP world was entirely experimental, at least for me. I remember studying CodeIgniter from Ademir Gabardo's book and using it for my capstone project, where I also got a taste of maker culture, using Arduino and a Raspberry Pi to prototype a smart water meter — a project that genuinely earned the highest possible grade. Professionally, though, the PHP I used was straight out of the 2000s: .php files with script blocks mixed into HTML, sharing the stage with iconic plugins of the era, like jQuery, for DOM manipulation, client-side validation, and animations, plus morris.js and chart.js for stylized charts. Bootstrap was still on its early versions, making its way into my projects bit by bit.

Figure 3. The PHP and MVC (Model-View-Controller) book with CodeIgniter, my first web framework.

Studying on my own: the .NET world

A few months later, I was made a permanent Junior Programmer Analyst and, with a bigger paycheck, moved into a studio apartment near a subway station in the West Zone. My quality of life improved instantly: I finally slept full nights.

Just working with Windev and old-school PHP wasn't satisfying. In conversations with my great friend Mark — to me, a programming legend (especially, but not only, in Java) — always tuned into engineering best practices, who taught me software architecture before I even knew the term, I realized that sticking only to day-to-day tasks was pulling me away from where the market benchmark actually was. So I started studying .NET on my own, getting into C# and ASP.NET MVC through the hefty Step-by-Step series volumes by the late John Sharp, and through books from the also sorely missed Casa do Código publisher, like Maurício Aniche's fantastic TDD (Test-Driven Development) book, along with a few Windows Phone books, since I was an early adopter and enthusiast of the Nokia Lumia line 💀. It was still early, but that restlessness to study beyond my day-to-day routine would become the foundation of the repertoire I'd go on to build.

Figure 4. The Visual C# 2008 book by John Sharp — a real brick of a book.

Time to move on

Before I knew it, three years had passed and I was now a Mid-Level Programmer Analyst. There had been many new ERP version deployments, cash-flow optimizations across brand groups, new store openings, features built and eventually rebuilt for various registration flows, integrations with thermal printers, and even setting up event booths at Anhembi. I had made great friends along this journey and was already about to finish my degree, in my final semester.

That's when the urge to make a change came: to step out of my comfort zone and take another risk in search of new challenges. Without much ceremony, I started testing the market again and, in May 2015, received an offer that, at the time, felt like a promise of fresh air. So it was time to say goodbye, at that company, to the friends who had taken me in and taught me so much in that early phase of the journey (years later, I'd return for a new, long-lasting project).

From there I moved on to a new software consultancy, but this time on a completely different project, now at the Forensic and Scientific Police department. Still finishing up college, in that same first half of 2015, that's where I got my first taste of a double workday — but that's a story for the next part.

I dedicate the end of this part to everyone who, at that time, took part in my journey: to Mark, to Vê, to the brothers Diego and Thiago, to Marcão, to Luiz XV, to Adrian 2, to Abel, to Dengo, and to so many others.

My Annual Library: Books Read from 2021 to 2025

Thu, 26 Dec 2024 00:00:00 GMT

Presentation

Reading, for me, before it became work, was and always will be a pastime, going back to school, when I'd read comic books and gaming magazines. Wanting to cultivate that discipline, whether as leisure or to reach personal and professional goals, I've kept an annual list since 2021 of what I've read across those three areas.

This way, the record serves both me and anyone else looking for recommendations, as a way to gauge my past and present interests, which guide my choices and life goals.

Books Read by Year

2025

Category	Title	Author(s)	Theme/Genre	Chapters Read / Completed
Leisure	The Hobbit	J.R.R. Tolkien	Fantasy	Completed
Leisure	Barren Lives	Graciliano Ramos	Novel	Completed
Leisure	The Fable of the Island State: How the Economy and Markets Work	José Kobori	Finance	Completed
Personal Development	Life Project: Paths to a Life Worth Living	Clóvis de Barros Filho	Philosophy	Completed
Personal Development	Leadership: Emotional Intelligence in Shaping a Successful Leader	Daniel Goleman	Business & Leadership	Completed

2024

Category	Title	Author(s)	Theme/Genre	Chapters Read / Completed
Leisure	São Paulo in the Skies: The Modernist Revolution in Architecture and Real Estate in the 1950s and 1960s	Raul Juste Lores	Architecture	Completed
Leisure	The Lord of the Rings: Single-Volume Edition	J.R.R. Tolkien	Fantasy	Completed
Functional	Team Topologies: Organizing Business and Technology Teams for Fast Flow	Matthew Skelton; Manuel Pais	Business & Leadership	1
Functional	Unit Testing Principles, Practices, and Patterns	Vladimir Khorikov	Software Development	1 ~ 11
Functional	Site Reliability Engineering: How Google Runs Production Systems	Jennifer Petoff; Niall Murphy; Betsy Beyer; Chris Jones	Software Development	1 - 3 - 4 - 6
Functional	The Leadership Pipeline: How to Build the Leadership-Powered Company	Ram Charan; Stephen Drotter; James L. Noel; Kent Jonasen	Business & Leadership	1 - 2 - 3 - 8 - 9
Personal Development	The Knight in Rusty Armor	Robert Fisher	Adventure	Completed
Personal Development	The Dip: A Little Book That Teaches You When to Quit (and When to Stick)	Seth Godin	Business	Completed

2023

Category	Title	Author(s)	Theme/Genre	Chapters Read / Completed
Leisure	Inédita Pamonha	Clóvis de Barros Filho	Philosophy	Completed
Functional	No Rules Rules: Netflix and the Culture of Reinvention	Reed Hastings	Business & Leadership	Completed
Functional	The Software Architect Elevator: Redefining the Architect's Role in the Digital Enterprise	Gregor Hohpe	Software Development	1 ~ 17
Functional	The Pragmatic Programmer: From Journeyman to Master	Andrew Hunt; David Thomas	Software Development	1 ~ 4
Functional	Code That Fits in Your Head: Heuristics for Software Engineering	Mark Seeman	Software Development	1 ~ 7

2022

Category	Title	Author(s)	Theme/Genre	Chapters Read / Completed
Leisure	Fahrenheit 451	Ray Bradbury	Science Fiction	Completed
Leisure	A Country Called Brazil: The History of Brazil from Discovery to the 21st Century	Marco Antonio Villa	History	Completed
Functional	The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change	Camille Fournier	Business	Completed
Personal Development	The Big Baby Book	Thatiane Mahet	Parenting	Completed

2021

Category	Title	Author(s)	Theme/Genre	Chapters Read / Completed
Leisure	The Engineers of Chaos	Giuliano da Empoli	Politics	Completed
Leisure	Philosophy for Mortals: Thinking Well to Live Well	Daniel Gomes de Carvalho	Philosophy	Completed
Leisure	Brave New World	Aldous Huxley	Science Fiction	Completed
Leisure	Around the World in Eighty Days	Jules Verne	Adventure	Completed
Functional	The Fourth Industrial Revolution	Klaus Schwab	Economics	Completed
Functional	It Doesn't Have to Be Crazy at Work	David Heinemeier Hansson; Jason Fried	Business	Completed

In the coming years, I plan to keep this list updated, aiming to record my reading and share my experiences with other readers. I also hope this list helps me reflect on my interests and stay motivated to keep reading and learning.

See you soon. 📚☕

Tech Coffee: Fundamental Principles of Unit Testing

Sat, 07 Dec 2024 00:00:00 GMT

Presentation

AI-Assisted Programming: Accelerating Development with Artificial Intelligence Tools

Sun, 10 Nov 2024 00:00:00 GMT

Context

I recently came across a mid-sized frontend application written in Angular 6 (yes, which reached EOL back in 2019). The task was to upgrade the project to an LTS (Long Term Support) version of Angular. As a first move, I chose to upgrade to the first available LTS version, 16.2.X. However, I'm not a frontend specialist, nor deeply familiar with the Node.js stack, and I'd need a lot of time or the support of another developer with more knowledge of the framework.

The project had 40 modules and 175 components, broken down as shown in the table below:

===============================================================================
 Language            Files        Lines         Code     Comments       Blanks
===============================================================================
 CSS                     6          334          271           20           43
 HTML                  180        11903        10206          693         1004
 JavaScript              4           78           49           19           10
 JSON                    2           22           22            0            0
 Sass                  247        12575         9431         1284         1860
 SVG                     2            4            4            0            0
 TypeScript            370        36123        27318         2904         5901
===============================================================================
 Total                 811        61039        47301         4920         8818
===============================================================================

Getting support from another developer wasn't an option, and I also couldn't spend weeks on the migration project. So I decided to try an approach I'd recently seen on some YouTube channels: experimenting with an AI Code Assist tool in the IDE. Although I normally use JetBrains IDEA and GitHub Copilot for backend projects, in this case I wanted to try something new, more focused on my goal: leaning on it to make up for my elementary frontend and Angular knowledge, working in a Driver and Navigator style of pair programming [1], alternating between moments where the AI generated code and I reviewed it, and vice versa.

Tools

For this task, I chose to try out the Cursor [2] code editor, which has native AI integration and promises a productivity boost through a number of features. Below, I highlight the ones I used, though there are other advanced ones described in the documentation [3].

Tab: to suggest or edit code based on an existing snippet or a description;
- Cursor Prediction: after an edit made with Tab, Cursor predicts additional snippets that could be fixed the same way and automatically jumps to the next one with another tab ⇥;
Chat: to interact with the AI and understand a piece of code or ask for an implementation suggestion;
- AI Fix in Chat: where an error caught by the linter is highlighted, and the AI opens a popup suggesting a fix;
- Apply: to apply the AI's suggestions directly in the editor;

To use Cursor, a premium subscription is not required, although usage is limited [4]. In my case, I chose the Pro subscription to guarantee unlimited use of the completions and instant apply features.

With Cursor, node version 20.11, and the desired version of the Angular CLI installed, I got to work.

Interacting with Cursor's AI

The first thing I did was generate a new project with version 16 of the Angular CLI and compare the differences between the old project and the new one. I noticed that some files were no longer needed, like angular-cli.json, while others needed to be created or adjusted, like angular.json, tsconfig.json, tslint.json, and tsconfig.app.json. I delegated the task of fixing these files to the AI through prompts in the following format:

Update the angular-cli.json file (in context) for Angular version 16.

With the following result:

Figure 1. Chatting with the AI to update the angular-cli.json file

And the changes suggested by the AI were applied directly to the target file:

Figure 2. Result of the AI-suggested changes using the Apply feature

Once the project's base files were updated, I moved on to the dependencies. Naturally, many no longer existed, or had been renamed. So I had to manually fix a few dependencies based on searches on npm.js — for example, angular-http, which was folded into angular-common, or angular2-fontawesome, which was discontinued and replaced by @fortawesome/angular-fontawesome.

Once the dependencies were updated, and after many npm install runs, it was time to try running ng build and face the first errors.

Backend build phase

Angular projects are split into two major parts: the backend, made up of components, modules, and services; and the frontend, made up of templates, directives, pipes, and UI modules.

In five years, a lot changes, and when it comes to frontend projects, the changes were even bigger.

My approach was to run ng build to compile the backend first, and, as expected, plenty of build errors came up, especially due to the strict setting in tsconfig.json, which now required every variable to be typed. While I could have disabled that setting, I preferred to fix the typing errors in each file with the AI's help, using the features listed at the start of this article. On top of that, many dependencies had their namespaces changed, one of the main examples being the splitting up of Angular Material components, which used to live under the @angular/material namespace.

Hundreds of Tabs later, ng build finally compiled without errors, and I could move on to the frontend build phase.

Frontend build phase

Now ng serve needed to compile the frontend. Naturally, many directives had changed, like property and event binding, which needed fixing.

Here's the explanation Cursor's AI gave for an error during the event binding migration:

The change you mentioned in the Angular directive from maxlength='100' to [maxLength]='100' reflects an update in how properties are bound in Angular, especially around the use of property binding.

Explanation of the change:

Property Binding:

Before (Angular 6): The directive used standard HTML attribute syntax, where maxlength was set as an HTML attribute with a literal value. This means the value was treated as a string.

Now (Angular 16): The new [maxLength]='100' syntax uses Angular's property binding. This lets the value be treated as an Angular expression, meaning you can pass variables, expressions, or dynamic values.

The advantage of having the AI provide both the fix and the explanation for the change was that I could use the Search All and Replace feature to fix all similar snippets that needed the same change at once.

Another frequent error was the lack of handling for null values when accessing object properties, which TypeScript didn't accept and needed fixing. This is a recurring problem in legacy projects, and the AI was able to fix it through Tab suggestions.

After a while, ng serve finally compiled without errors, and I was able to access the application in the browser.

Publishing the app and opening the Pull Request

With the application working, all that was left was to update the pipeline file to use a newer version of Node.js and open the Pull Request on the repository.

Here's the final result on the enhancement/bump-up-angular-16 branch:

 397 files changed, 20290 insertions(+), 19788 deletions(-)

Conclusion

The term "AI-Assisted/Guided Programming," and others like it, will become increasingly present in the day-to-day work of software engineering teams. Gartner studies predict that, by 2028, 75% of developers will use AI tools to write code [5]. This shift is already visible across the software industry; Mercado Livre, for example, already uses AI tools to support its more than 9,000 developers [6].

In this brief account, I found that, even though I wasn't deeply familiar with a specific stack, productivity on the task increased significantly. An effort that would previously have taken weeks was reduced to a few days. That said, the developer's knowledge and experience remain indispensable, since, as I showed, it's often still up to the developer to decide which approach best solves the problem. So critical thinking, judgment, and experience were essential, not replaced.

References

SPA: Azure App Services or Static Web Apps?

Sun, 11 Aug 2024 00:00:00 GMT

Context

I recently came across a SPA (Single Page Application) written in Angular that had been running on an Azure App Service for a long time.

App Services are fully managed platform-as-a-service (PaaS) offerings, used to deliver web applications across various languages, frameworks, and operating systems. Because they're managed, they come with several ready-to-use capabilities, such as automatic scaling (scale up and scale out), custom domains, custom SSL, deployment integrations with GitHub Actions, Azure DevOps, and more.

But is a PaaS with so many capabilities really the best option for distributing a SPA? Probably yes, but maybe not the most efficient one. Any modern SPA boils down to a set of static files, which are typically downloaded in full by the client's browser. Because of that, there are more efficient ways to distribute these static files, taking advantage of what CDNs offer.

A CDN (Content Delivery Network) is a network of geographically distributed servers, designed to efficiently deliver static content by bringing those assets closer to the end user.

CDNs like Akamai, Verizon, and others are highly cacheable and relatively cheap, considering the volume of traffic, compared to the cost of web server infrastructure and the outbound traffic of storage solutions like S3 and Azure Blob Storage.

With that in mind, Azure built a solution that combines some of the capabilities of an App Service with a geographically distributed network for serving assets: the Static Web Apps service.

Figure 1. Static Web Apps or App Services for distributing static content?

Static Web Apps

Besides being able to distribute SPAs built with frameworks like Angular, React, Vue, Blazor, or even plain HTML with CSS and JavaScript, Static Web Apps also allows for quick integration with Azure Functions, which serve as the backend for the SPA, easing CORS restrictions and simplifying the infrastructure, since there's no need to maintain a full web server [1].

Some of SWA's key features include (check the service quotas [2]):

Easy integration with GitHub Actions and Azure DevOps Pipelines.
Global asset distribution.
Free SSL certificates.
Support for custom domains.
The first 100 GB of outbound traffic/month included.
Integration with authentication providers like Microsoft Entra ID and GitHub.
Creating and publishing multiple environments.
99.95% SLA.

You could argue that a distribution solution using Blob Storage and Azure Front Door could achieve the same result, but Front Door comes at a higher price, since it's a more robust product offering advanced distribution and cross-region routing features that may be unnecessary for use cases where you simply want to deliver a web app's static content.

Here's a cost comparison table for each solution:

Solution	Has a free tier?	Starting price
Azure App Services	Yes	Starting at USD 73.00 on the Standard plan
Static Web Apps	Yes	USD 9.00 per app
Blob Storage + Front Door	No	(BS v2 LRS) Starting at USD 22.00 + (FD) Starting at USD 46.00 on the Standard plan

In short, Static Web Apps is a simple, cost-effective, and reliable alternative for distributing SPA applications compared to other models Azure offers.

References

The Leadership Pipeline — The Path to the Tactical Level

Mon, 04 Mar 2024 00:00:00 GMT

Presentation

Any company, regardless of industry, size, or geographic location, shares two things in common: some kind of structure, whatever form it takes, and an organizational culture, whether deliberately built or emergent. These two things are linked in defining how hierarchical the company's structure will be and how many levels are needed to accommodate the management of its different areas, as well as determining which areas are responsible for which parts of the business. While these structures may seem permanent and fundamental at first glance, they aren't always healthy or unobstructed, since that requires carefully organizing leadership passages, with clearly established duties and responsibilities that, as much as possible, don't overlap.

Figure 1. Pipeline refers to the sequential, progressive structure through which individuals grow their leadership capabilities, from entry-level roles up to the highest level of management within an organization.

The book "The Leadership Pipeline: How to Build the Leadership-Powered Company" [1], written by Ram Charan, Stephen Drotter, and James Noel, presents a model for understanding and developing the different layers of leadership within an organization. It suggests that developing effective leaders requires a clear understanding of the requirements, challenges, and transitions associated with each stage of the structure.

This structure, referred to as the "pipeline," resembles a ladder the professional climbs, made up of seven levels. At each level transition, a new leadership passage occurs, with each level represented by a given role within an organizational structure, as listed in Table 1.

Pipeline Level	Representative Role	Brief Description
1. Managing Self	Individual Contributor	Focused on developing technical and professional skills, managing their own time and tasks.
2. Managing Others	Team Leader / Supervisor	Responsible for managing the work of others, motivating the team, and evaluating performance.
3. Managing Managers	Manager of Managers / Director	Focused on coaching other managers, developing their leadership and strategy skills.
4. Functional Manager	Department Manager	Oversees a specific area of the company, such as finance or marketing, implementing functional strategies.
5. Business Manager	General Manager / Business Unit CEO	Responsible for a business unit's overall performance, including profitability and market strategy.
6. Group Manager	Group CEO / Vice President	Manages multiple business units or regions, ensuring strategic and operational alignment.
7. Enterprise Manager	CEO / President	Leads the organization as a whole, setting corporate vision and strategy, and shaping organizational culture.

Table 1. Pipeline levels and their corresponding role in a traditional company.

The levels and their respective leadership passages are represented by the authors through the pipeline illustrated in the figure referenced below. Figure 1 shows the progression of each stage within the organizational structure.

Figure 2. Leadership progression through the pipeline. (Adapted from: CHARAN, Ram; DROTTER, Stephen; NOEL, James, 2011, p.27)

In this review, I'll summarize the main ideas behind the first two passages, along with some reflections on why each one needs to be firmly established.

From Individual Contributor to the Tactical Level

Business management has long established that, broadly speaking, there are three organizational levels within companies: the operational level, tied to day-to-day, short-term tasks; the tactical level, which translates strategic guidelines into medium-term action plans; and the strategic level, which defines the organization's overall direction and long-term goals.

Figure 3. An organization's levels.

Well-defined, with a clear starting point, early-career professionals will spend their first years in an organization as individual contributors, usually assigned well-defined, short-duration tasks with very clear goals.

At this stage, the professional will be focused on shaping their skills, their time management, and their professional values, along with other traits that demonstrate the ability to take on responsibility and respect the company's values. Once these three areas are reasonably developed, this professional is typically promoted to a first-level leader or manager.

"To develop effective leaders [...], organizations need to identify leadership candidates early, give them growth assignments, provide them with useful feedback, and coach them. (p.31)"

It's worth noting that the job title can vary from company to company — it might be leader, coordinator, first-level manager, and so on — but the key point is that, in this first leadership passage, the new leader will be managing not just themselves, but other people too, which requires a behavioral shift and a fundamental change in skills and values for success in the role.

These new skills, described in Table 2, include planning the work, assigning tasks, motivating, and critically evaluating the work done by others — in other words, not just completing the work assigned to them, but also helping others reach an expected level of performance. At this point, it's crucial that managerial work be valued, not merely tolerated, since making time to address the team's needs, clarify doubts, and pursue contact and dialogue with other teams, departments, and vendors is essential for helping their reports reach their goals — and, in turn, for determining the leader's own success.

For new leaders, letting go of the tasks and skills that got them promoted into a leadership role can be challenging, but it's necessary to understand that, at this new level, results are achieved through others. Direct reports' success reflects the leader's own success. So, it's essential to see yourself as a manager, one who defines the work to be done and lets it be carried out by their reports, with trust and accountability, teaching rather than just correcting mistakes, and staying close to the problems and failures the team faces. Leaders at this first passage must, above all, be accessible and available, both physically and emotionally, showing that, through that accessibility, they've mastered managing their own time.

Aspect	Individual Contributor	First-Level Manager
Skills	Technical/functional mastery, teamwork, building relationships for personal benefit, using tools/processes	Planning, job design, staffing, delegating, monitoring, coaching/feedback, performance evaluation, motivating, communicating, building relationships for the department's benefit, acquiring resources
Time Management	Daily discipline, meeting personal deadlines, managing their own time	Annual planning, availability for direct reports, setting priorities, time spent communicating with other areas
Professional Values	Getting results through their own proficiency, high-quality work, embodying the company's values	Getting results through others, direct reports' success, the department's success, integrity

Table 2. Traits of the first leadership passage. (Adapted from: CHARAN, Ram; DROTTER, Stephen; NOEL, James, 2011, p.64)

When leaders lack an aptitude for time management, they run into trouble planning tasks and setting priorities for the team. As a result, they'll often lack the time to support their direct reports, which will clog up the flow of work and probably overload both themselves and everyone else. Likewise, the absence of proper professional values leads to difficulty delegating tasks. These leaders often choose to do the tasks themselves rather than plan the work. This leads to a lack of proper managerial methods, making the work environment chaotic and relationships and communication with other teams unstable or ineffective.

The second passage — to manager of managers — should mark a complete shift from operational focus to the tactical management of teams, while also prioritizing the development of new leaders. This includes mentoring, coaching, ongoing feedback and evaluations, and delegating tasks that push them to practice time-management skills suited to leading a team.

When these leaders are poorly trained or coached, certain management problems can surface, signaling that these managers of managers may be in the wrong role, or that they haven't yet fully developed their skills, time management, or professional values. Among these problems are difficulty delegating, poor management of first-level managers' performance, an inability to build a strong team — perhaps the biggest problem of all, especially when favoritism is at play and there's a lack of proper evaluation based on competence — an excessive focus on doing the work themselves, and a tendency to select people who are clones of themselves, rather than choosing for diversity and competence.

For managers of managers to excel in their role, they should focus on selecting and training highly competent new managers, holding those leaders accountable for the managerial work they've done, allocating resources across units as needed, and managing the boundaries between each unit according to the established organizational structure.

Notice that, in the pipeline model established by the authors, there's no overlap of roles. Clearly defining the skills, time management, and professional values expected at each stage of the process creates an environment conducive to the emergence of new leaders. This eliminates the need to hire exclusively from outside for standout talent, allowing internal leaders to be developed so they can carry out their roles properly, without competition between leaders and their reports over the same action.

Finally, by establishing the right requirements for the different leadership levels, succession planning becomes easier, reducing the emotional strain on newly promoted leaders. As the authors point out, "when someone skips leadership passages and is placed in a position for which they lack the necessary skills, time-management mastery, and professional values, the emotional impact is significant. The pipeline model makes skipping those passages unlikely."

Closing thoughts

Establishing roles within an organizational structure is always a challenge. It becomes even harder when those definitions aren't clear and objective, or when there's no formal coaching and development plan led by the upper levels, who, according to the authors, are the ones responsible for developing successors. The absence of these definitions creates gaps in the pipeline, leading to overlapping roles: managers doing operational work instead of managing it is perhaps the clearest symptom of neglecting the skills, time management, and professional values needed to achieve exceptional performance in the role.

While this dysfunction is common, addressing it is essential. Developing leaders at the earlier levels of an organizational structure, who meet the requirements described above, is indispensable. After all, it's at the operational and tactical layers that every company, regardless of size or industry, generates its revenue through the development of products and services. These levels also represent the entry point for new talent, whether through hiring or internal development.

Finally, adopting this model represents a vital strategic step for organizations that want to not only stay competitive in an ever-evolving market, but also secure a strong, sustainable leadership legacy for years to come.

References

Book "The Leadership Pipeline" – Amazon

Additional links

The Leadership Institute — Resources

Navigating Big Numbers: A Professional Journey at the Heart of E-commerce

Sat, 17 Feb 2024 00:00:00 GMT

Presentation

Book review – "The Software Architect Elevator", Part II

Wed, 03 May 2023 00:00:00 GMT

Part II – Architecture

The many definitions of software architecture compiled by Carnegie Mellon University's Software Engineering Institute [1] suggest that the phrase has no obvious meaning when examined on its own. While the terms "architecture" and "software" each have precisely defined meanings, how they combine depends entirely on the specific context in which they're applied.

Figure 1. Software architecture is more than drawing component diagrams.

Gregor Hohpe argues that every piece of software has an architecture, even if it wasn't intentional. That architecture should drive the efficiency of engineering teams by enabling parallel development and evaluation of the components being built. He also argues that no architecture is perfect, and there's always a combination of trade-offs to weigh, with context being the organizing principle behind all of those decisions.

Software architecture documentation should capture the non-trivial decisions and always give the reader the reasoning behind each choice, along with the context that drove it. It should also emphasize what's essential, de-emphasize what's unnecessary, and describe the limitations of any architectural choice. It's essential to recognize that every important decision comes with trade-offs.

The author warns that decisions too costly to reverse later should be made early in the project, to avoid stalling progress by second-guessing every new element introduced. Quoting Martin Fowler, Hohpe explains that one of the crucial jobs of software architects is to remove irreversibility from software design through abstractions [2], patterns, and development paradigms, aiming to minimize irreversible decisions early in the process. If the engineering team's level of familiarity with the technologies involved isn't sufficient, it's possible to adopt an evolutionary architecture, one that develops as the team's understanding of those tools grows.

Software architecture covers more than components and how they relate to each other. It requires a systemic approach, emphasizing relationships and how each structure acts as a means to achieve a desired behavior. In that sense, techniques like negative feedback loops can be applied, acting as a form of self-regulation for systems through the relationships between the designed components. That focus on behavior should also show up in the documentation produced, where it should be the most relevant aspect, rather than static structures.

Taming legacy software is also a challenge in software architecture, and the key to avoiding obsolescence in these systems is keeping them agile. A system isn't agile if nobody can change it. That fear of change is justified when there's a lack of proper operating practices and techniques, a lack of useful metrics, and sporadic deployments. Fowler puts it this way: "if it hurts, do it more often" [3]. In that context, painful tasks should be performed frequently, so that automation becomes unavoidable.

For software architecture operating at large scale, the author stresses the need for broad automation — from bureaucratic processes like infrastructure request approvals, all the way to application deployment pipelines. Whatever can't be automated should be turned into a self-service system, simplifying routine, predictable activities. One possible strategy for automating this kind of system is building interfaces with validations built into the software development lifecycle, including the use of boilerplate code for new applications and infrastructure service configuration. Tacit knowledge should also be codified into scripts and tools, surfacing these processes and making knowledge transfer easier. Finally, automated systems for widely standardized, explicit processes make compliance audits easier.

Software architecture implies making design decisions to prevent developers from exercising unnecessary creativity. This means certain processes should be established up front and kept as standards, simplifying software operations and freeing up engineering teams to focus on what actually drives the company's business differentiation. Standardizing IT components simplifies operations, allows for economies of scale, and saves money thanks to greater purchasing power with vendors.

This standardization should be considered at two levels: the lower level, where the goal is to maximize reuse, since it's rarely what differentiates the company; and the upper level, made up of internally developed software, which provides the real value and competitive differentiation in the market. There's an element of conformity here, where few changes happen at the lower levels, making it easier to standardize around a common set of tools.

When drawing software architecture diagrams — whether using C4 models [4] or other graphical notations — the boxes representing components usually get the spotlight. However, from Hohpe's perspective, these diagrams should be designed with a focus on the functionality and relationships between those components, through the lines and arrows, in order to highlight the communication between the elements that make up the system at different levels. This approach leads to a clearer, more effective understanding of the software's architecture and its dynamics.

Finally, when adopting a set of technologies from a single vendor, it's crucial to question the boundaries of each tool and how they relate to the system as a whole. This makes it possible to establish the boundaries of the proposed solution and ensure a more effective approach to software architecture.

Closing thoughts

The difficulty in precisely defining software architecture comes from trying to tie it directly to software's most fundamental components, like data and code. While topics such as layered architecture, design patterns, and source-code design are related to software architecture, that association is only partly true. As noted, the strategies shaped by the context the software architect operates in are inseparable from the principles that guide the design, implementation, and evolution of these systems.

It's essential to establish the boundaries, responsibilities, and relationships of each component chosen to make up the architecture map, taking into account all the constraints imposed by the environment and the subject being observed, whose systemic representation will be built. In this way, software architecture goes beyond basic components and covers broader, more complex aspects, involving decisions and strategies specific to each context and project.

References

Additional links

Book review – "The Software Architect Elevator", Part I

Wed, 25 Jan 2023 00:00:00 GMT

Context

Software architecture has been the subject of heated debate among engineers and IT managers for decades. Many works by great authors — Mark Richards, Sam Newman, Len Bass, George Fairbanks, Frederick Brooks Jr., among others — have helped shed light on this vast topic.

This review covers the first part of the book "The Software Architect Elevator" [1], written by Gregor Hohpe [2], who is also the author of the acclaimed EIP, "Enterprise Integration Patterns" [3], a catalog of essential patterns for integrating systems.

Figure 1. Software architects need to travel across different organizational levels.

Part I – Architects

In this first part, the author lists the skills and traits that are desirable in a software architect, and what roles they should play within an organization: broad strategic vision, technical leadership, and being a good people manager. The author states that these professionals need to handle discussions that go beyond the purely technical, such as the situational context they're operating in and certain tacit assumptions, which sometimes hide fundamental contextual information, as well as establishing communication across different organizational levels.

Finding the right balance in design decisions, according to the established goals and principles, is essential — connecting software components so they can work together to achieve the expected outcome, all while managing complexity through governance techniques.

When it comes to communication, the author uses the metaphor of a building's elevator, connecting the lower floors — where systems engineers work on building and maintaining the business's software systems — to the upper floors, where the executives responsible for the business's high-level abstraction sit. This connection is represented by the metaphor of a building elevator. In this context, the architect's job is to move naturally between these floors without losing the essence of the message — in other words, adapting the language used to the specific needs of each audience.

In situations where there's resistance to the software architect's role in communicating across levels, the author argues that it's necessary to work at reducing that resistance. One way to do that is by getting the upper levels genuinely interested in and aware of the projects being carried out by engineering. It's also important to establish frequent feedback loops.

On the technical side, Hohpe describes how architects must ensure that the solutions being built preserve the balance and proportion of the original ideas. This same ability is mentioned by Frederick Brooks Jr. in his book "The Mythical Man-Month", where it's called "conceptual integrity." Brooks highlights how important it is for the architect to work at tying together the ideas that make up the system and preserving the cohesion of the whole.

An architect's experience across projects of different sizes is essential, giving them the sensitivity to spot opportunities for change that go beyond a system's expected functional requirements. These changes might include the need to support shifts in the volume of data being processed, environment changes when the system is moved to a new cloud provider, or the need to implement globalization features so the system becomes available in multiple languages.

Another important technical aspect is promoting the building of tools for building and shipping software to production, increasing the speed of delivering changes while also reducing the risk of errors from manual operations carried out by operations teams. A software architect must ensure their technical judgment stays free of bias, so they need to make sure they're in touch with other experts who can give them information that lets them see past the buzzwords and discern whether a solution is genuinely new, or just "cleverly reheated." This matters, because it curbs the temptation for an architect to stay comfortable with the same set of solutions, or to irrationally adopt new tools without good reasons to apply them.

According to the author, enterprise architecture is the logical organization of business processes and the IT infrastructure that supports them, bringing together the work of business and IT architects. There are various business-process mapping tools that architects use. According to Hohpe, architects should be cautious about using these tools as mere documentation, since the end product can become outdated the moment it's released. However, this static approach presents a recurring dilemma for architects, since it may not accurately reflect the constantly changing interactions within the business environment.

There are different levels of seniority for software architects, which, according to Hohpe, can be identified by applying the tripod of skill, impact, and leadership — where skill refers to the ability to solve real problems with the right tools; impact measures how the architect's skills benefit the company, helping it reach its strategic and market goals; and leadership, which determines the architect's ability to advance the state of their practice, sharing knowledge through talks, blogs, publications, and mentoring other professionals.

Finally, the ability to ask the right questions and identify who makes the decisions — and the motivations behind them — is an indispensable skill for a software architect.

Closing thoughts

The reflections Hohpe presents in this first part are essential for understanding the position the software architect occupies within the complex organizational ecosystem, which involves multiple stakeholder groups, going well beyond purely technical decisions related to engineering or operations.

That said, it's worth highlighting that communication and decision-making ability is the single most important factor for successful management, regardless of the area in question — whether to set a new direction or change the trajectory of a project that has drifted from its plan.

References

Upgrading Sleuth for Spring Boot 3.0

Sun, 08 Jan 2023 00:00:00 GMT

Context

My team and I were recently working on library upgrades for APIs built on Spring Boot. These upgrades were happening in projects running the framework on version 2.7.X, and we wanted to take the opportunity to move up to version 3.0.1, made available as Generally Available in late November 2022.

The upgrade guide available in the framework's official repository went smoothly, with the build and automated tests running without issues.

However, when we ran the project and looked at the logs, we noticed the Trace Id and Span Id were missing from the records, which are normally enriched through the Spring Cloud Sleuth library.

2023-01-06T20:06:46.830-03:00  INFO [my-test-app,<TRACE_ID_HERE_BUT_EMPTY>,<SPAN_ID_HERE_BUT_EMPTY>] 29324 --- [nio-8080-exec-6] c.a.Loren : Loren ipsun

Problem

A quick read of the Sleuth documentation tells us this project was absorbed by Micrometer Tracing starting with Spring Boot 3.0, and therefore appears to be deprecated starting with version 3.1. This is also confirmed on Micrometer's official GitHub, which provides a migration guide.

However, the migration guide doesn't seem complete, since following it didn't result in trace data being printed correctly.

So the goal of the walkthrough below is to help you with this migration.

Solution

Check that the project is using Spring Boot version 3.0;

plugins {
    id("org.springframework.boot") version "3.0.1"
}

Remove the Sleuth dependency;

implementation("org.springframework.cloud:spring-cloud-starter-sleuth")

Add the Micrometer Tracing dependency along with the bridge to Brave, which is responsible for creating the tracers;

implementation("io.micrometer:micrometer-tracing-bridge-brave")

If you don't already have it, add the Spring Actuator dependency. It's required for Micrometer's autoconfiguration;

implementation("org.springframework.boot:spring-boot-starter-actuator")

Finally, following Micrometer's migration guide, add the log pattern property in your .properties or .yml file so that the Trace Id and Span Id get printed;

logging.pattern.level=%5p [${spring.application.name:},%X{traceId:-},%X{spanId:-}]

When you run the project again, the Trace and Span Ids will start working correctly.

2023-01-06T20:16:46.830-03:00  INFO [my-test-app,63b8a986c713b025bfcb74bfc7c64a77,bfcb74bfc7c64a77] 29324 --- [nio-8080-exec-6] c.a.Loren : Loren ipsun

If you have any questions, feel free to reach out through my contacts.

Happy coding, everyone. 😎