Jordão Beghetto Massariol

Today I'm the architectural reference on my team: I take part in defining the stack, design patterns and structure of new systems, in feature development and in technical refinement with clients. I lead three nationwide projects for institutional clients (public healthcare, industry and telecommunications), each with its own business rules and technical challenges — in these systems we use TDD from start to finish and an auditing module built with Spring AOP. I also coordinated, together with the team, the construction of a digital financial platform integrated with CELCOIN: a NestJS backend, Redis caching, a Next.js frontend as a mobile-first PWA and a controlled rollout up to general availability. I led two simultaneous rebuilds of legacy state government systems, modernizing Groovy/Grails applications into React, TypeScript and Java Spring Boot — work that required a lot of reverse engineering, since the original documentation no longer reflected the system running in production. I structured the process of defining REST contracts between teams before each sprint starts, which brings architecture decisions forward and reduces rework. Day to day, I write a bit less code than I used to, because I coordinate more of the process: I refine tasks, run the ceremonies, talk directly with clients about deadlines, deliveries and acceptance testing, review code and keep the environments and CI/CD pipelines running. I also onboard new developers to the team and take part in the company's strategic decisions.

This is where I went from executing to deciding: I architected the company's first rebuild projects, defining the stack and repository structure for teams that would grow over the following years. I worked on the development and rollout of systems for state public hospitals, contributing architecture decisions that helped make the project viable, and expanded my work to Angular on a nationwide corporate institutional system. I ran technical hiring interviews and started reviewing other developers' code, as well as writing and refining tasks for the team. I saw my work start to split between code and process, with process taking up more and more of my day, and I kept earning the team's trust to take on bigger responsibilities in sprint deliveries. I also worked on smaller internal projects, automating processes that later proved useful for my own management work.

I took part in my first architecture definition meetings, still as a contributor, not as a decision-maker. I deepened my knowledge of the stack we used on projects at the time — Java Spring Boot and Quarkus on the backend, React and Angular on the frontend, PostgreSQL, MySQL, MongoDB and Redis for databases — aiming to deliver tasks faster without compromising the end result. I started following the full cycle of agile ceremonies — dailies, planning, refinement, reviews and retrospectives — as an active participant, not just someone executing tasks. I also pushed important topics forward in strategic meetings about code review culture and helped put on the table what would later become the REST contracts between development teams.

I earned the trust of the more experienced developers and was assigned to a CRM project more complex than usual — a system that was already a success story before I joined. I started taking part in implementing entire features: I integrated LDAP/Active Directory authentication, wrote stored procedures in SQL Server and built reusable React components in TypeScript, always working closely with the Node.js and Java Spring Boot backend. I worked side by side with the QA team on bugs, bugfixes and hotfixes coming straight from production — I tracked down N+1 queries that were freezing entire screens and wrote unit tests to prevent regressions. I also took my first steps in mobile development with React Native, and was already able to show the team and management my potential and my drive to solve problems.

I started at the company from the basics, working on one or two projects at a time with simpler tasks: fixing visual bugs, small endpoint adjustments, straightforward CRUDs and specific screens. I joined the daily meetings mostly as a listener, reporting my status to the more experienced developers. I did a lot of pair programming with colleagues who had been there longer — that's how I learned the system's business rules and understood, in practice, what a developer's routine looks like.