Maybe a few people will wonder why I love programming. Right now, I work as a Solutions Architect and a Software and Product Engineer. Maybe no one will read this—but honestly, my mind lights up every time I talk about technology. That’s why I decided to write this—for myself—to try and explain why I love coding so much. So, let me just enjoy this moment and let the words flow.
I’m an Electrical Engineer, and back in 2018, I decided to pursue an MBA to better understand a company’s problems from a systemic perspective. At the same time, being passionate about technology, I dove deeper into programming as a side study. Up until then, my background was mainly in telecommunications, networking, and electronics from my undergrad—things like binary systems, logic gates, registers, and clocks. I had some basic experience with C++, microcontrollers, and a solid foundation in calculus, algebra, statistics, and other core technical subjects.
In my current role, I don’t have to code—but I know that coding can help anyone improve their daily tasks. Take an attorney, for example. Imagine someone who has to review thousands of pages in the office’s main system, which is packed with hundreds of parameters to manage all those cases. Analyzing a financial case could be partially automated with code. But the software is designed for the office, not necessarily for the attorney. That means the attorney’s actual work isn’t always prioritized—the system just needs to manage the attorney and the process.
The same can be said for engineers. While our tools are meant to streamline core tasks like designing projects and building products, we also get pulled into filling out forms, writing proposals, estimating costs, and navigating workflows that are only loosely related to the outcome. These tasks are necessary to keep a company running smoothly—but they can be tedious. And that kind of work? It's really boring to me. A lot.
That’s why I started side programming projects to streamline my own daily tasks. Of course, I didn’t have all the answers at the beginning. But that’s what made it interesting—finding tasks I could automate became my learning roadmap. Not every project turned out as great as I hoped, and not every one had the impact I imagined. But I finished them. And in doing so, I learned about a ton of things I never even knew where to start with. Let me explain how things started to make sense.
I used to work as a Key Account Manager, overseeing the northeastern region of Brazil. My role wasn’t just about sales—it also involved strategy, brand promotion, regional market planning, and more. Around the time I began coding to automate some of my tasks, one of my key responsibilities was to define and present our strategic plan for the year. This included how we intended to approach the market, which I had to present to the sales head and director. Every quarter, we also delivered performance reviews—highlighting wins, setbacks, and lessons learned.
The solutions I sold were aimed at regional ISPs, particularly around FTTx infrastructure, so understanding the market was crucial. I gathered this insight from two primary sources: high-level conversations with customers—CEOs, owners, and directors—and public data released quarterly by ANATEL (Agência Nacional de Telecomunicações).
While ANATEL’s data may not be 100% accurate, it was invaluable in spotting trends and patterns. I actually wrote another article about this—Uma Breve Análise De Dados (Broadband)—where I explored this in more detail. Imagine having to analyze that data every quarter to support your decisions. The insights I gained from it became a solid foundation for my ideas about the broadband market.
This is where my first data science project came in. I used Python and libraries like Pandas, NumPy, Matplotlib, and Plotly to build a tool that could process and visualize ANATEL’s raw data. The goal was to create a tool that would clean the data, generate charts, and provide insights on a national scale, the Northeast region specifically, and even a customized view for my customers.
At the end of the process, the tool exported everything as .html and .png files, ready to be dropped into my reports. It worked beautifully! It didn’t take long to build, and I never had to touch a spreadsheet again. My only job was to download the latest ANATEL report and run the code—everything else was done automatically, and the visuals were instantly ready for updates and presentations.
This project was significant because it allowed me to cross-reference public data with real-world impacts from the decisions our customers made. The connection between raw data and context made all the difference.
Analyzing ANATEL’s data to better understand FTTx broadband trends wasn’t the only way I used that raw information. Once I truly grasped the data, I realized there was so much more that could be done with it.
Another project I worked on—this time as a Presales Engineer—was focused on building a detailed Market Plan. In Brazil, with over fifteen thousand ISPs, understanding this massive and fragmented market was crucial to deciding where my company’s efforts should be focused.
By combining my background knowledge, insights from conversations with customers, and some calculated assumptions, I was able to estimate how much of each product and solution was already deployed across Brazil’s FTTx networks.
The real breakthrough came when we cross-referenced this external market data with our internal sales data. Suddenly, our market share became crystal clear. With that clarity, we could create strategies that weren’t just theoretical—they were data-driven and actionable, all based on the comprehensive market plan we developed.
Like any complex sale, the question "Why should I buy your solution?" doesn’t start when it’s asked—it starts much earlier. As Neil Rackham explains in SPIN Selling, that moment is often more emotional than logical, and the framework focuses on uncovering and shaping needs, not just responding to them. I won’t dive too deep into SPIN here—it could easily deserve its own post—but it definitely influenced how I approached customer conversations.
As a Presales Engineer and later as a Solutions Architect, one of my key responsibilities was to create and deliver custom presentations that truly resonated with each customer. A common request—especially among Brazil’s top 10 broadband ISPs—was a Technical Proposal.
At the time (and still today), there wasn’t a clear definition of what a “technical proposal” should look like. The first time I was asked for one, I just opened Word and started writing. It was painful. So much of the content was stuff I had already written for other customers, but scattered across different decks and documents.
By the second time, I realized this was going to be a recurring task. I had all the core information I needed for every presentation, but I never knew which products or solutions would be involved. That’s when I decided to build a web app to automate the process of generating technical documents based on customer needs.
This was the first project where I worked on both the front-end and back-end—and honestly, it completely changed how I, and my colleagues, approached this task.
My goal was to create an app with access control for my team that would generate customized technical proposals through simple inputs—just a few checkbox selections and text fields. Powerful output from simple inputs.
To get started, I gathered information about our customers’ pain points and internal data on our existing solutions and products. Most of them were already built, and the ones that weren’t, I developed myself. Once everything was mapped out and aligned with customer pain points, I had the core data ready to go.
Building the app required diving into a few new technologies—Firebase for the database, authentication, and deployment; React for the front-end; and several other tools and libraries along the way.
The app was used a few times by me and my colleagues, and it made a noticeable impact by streamlining our workflow. After I changed roles, I didn’t keep it updated with new solutions or refined “pain-to-pill” messaging. Still, during its active period, it saved us a significant amount of time.
For context, generating a Technical Proposal used to take about 240 minutes. With the app, that time dropped to just 15 minutes—a massive time saver, especially in a high-paced presales environment.
Sure, if you add up the hours I spent studying documentation and learning how to deploy the app, it likely exceeded the time saved generating proposals. But here’s the thing—it was my time. And the knowledge I gained in the process? It became fuel for future projects. Totally worth it.
In many of the solutions I’ve worked with, it’s common to face skepticism from C-level executives, directors, and managers—especially when it comes to promises of results. When you're dealing with complex solutions, particularly in the ISP world, the main goal is to ensure that your solution can truly deliver either performance gains or financial impact for the customer.
Mikael Blaisdell, a well-known Customer Success leader, puts it simply: customers buy software for only three reasons:
- To save money or avoid costs
- To make more money
- To comply with legal or regulatory requirements
That framework has stuck with me. No matter how advanced or technically exciting a solution might be, if it doesn’t clearly align with one (or more) of the three main reasons a customer needs it, it’s going to be a tough sell—or worse, a failed implementation.
This concept doesn’t just apply to ISPs—it holds true for any complex solution. The first customers, the early adopters, are rarely your typical buyers. In fact, they’re quite rare. But they’re incredibly valuable. These are the customers who push the limits of their environment, experiment, challenge assumptions, and most importantly—they give you honest, critical feedback. These are the voices you must listen to.
Since 2017, I’ve worked with a disruptive FTTx solution that significantly changed how ISPs connect new users to their networks. It was a game-changer in terms of time-to-market. If you check out my articles Every Engineering Decision Is a Buying Decision and Uma Breve Análise De Dados (Broadband), you’ll see how this solution fit perfectly into a key moment in Brazil’s FTTx expansion timeline.
But speed wasn’t the only benefit. The solution also helped ISPs cut costs significantly during both fulfillment and assurance services. In some cases, it even led customers to renegotiate contracts with their contractors—the ones responsible for building their FTTx infrastructure. The impact went far beyond technology—it touched operations, finances, and business models.
To truly grasp the real benefits of this solution, I had to dive deep into ISP operations—how they handle fulfillment services, build and expand their networks, activate new users, and manage assurance to keep FTTx networks running smoothly after outages.
Gaining this kind of insight wasn’t about complex research—it was about asking the right questions and having meaningful conversations. I needed to get to the root of the problems and pain points they were facing.
And I had plenty of opportunities to do that. In 2017 alone, I spent more than 250 days on the road—giving trainings, hosting workshops, attending industry events, and giving lectures. Talking to customers wasn’t just part of the job—it was the job.
Their feedback wasn’t just valuable—it was essential. It helped me understand not only how the market worked but where it was headed and how our solutions could actually move the needle.
Back in 2017, I developed an Excel spreadsheet that combined all the market and technical information I had been collecting over time. The goal was simple: calculate the Total Cost of Ownership (TCO), Payback, and Breakeven to compare new solutions against legacy infrastructure. It quickly became a valuable tool in our presales conversations.
Fast forward to 2021, when I returned to the Presales Engineering team, and I discovered something that honestly blew my mind—my original Excel file had evolved into version 4. This meant it had been actively used and improved for at least five years.
But with that evolution came a new challenge: every colleague had been tweaking their own version of the spreadsheet to fit their specific needs. Not only was the data inconsistent, but some important team members weren’t using it at all. It was clear that we needed to scale the tool and centralize its use. So, I decided to turn it into a web application.
I built a frontend with visual comparison charts, a backend to serve the app, a database to store all simulations, and an authentication system to manage access across the engineering and sales teams. The new version featured 40 customizable input parameters and 36 output visuals, making it easy to evaluate which solution was truly the best fit for helping our customers scale their business.
This tool wasn’t just my favorite because of the results it delivered. What made it truly special was what it represented at its core: the essence of how to approach customers with new solutions.
For the first time, I was working with a complex business planning tool that didn’t just spit out numbers—it helped stakeholders defend their ideas. It gave them clarity and confidence to move forward with innovation. For me, that’s what great engineering is really about: empowering people to make smarter decisions.
Working as a Solutions Architect made me think about productivity more than any other role I’ve had before. Being responsible for Proof of Concepts (PoCs) and helping customers adopt new workflows—sometimes radically different from what they were used to—forced me to look at things differently. I wasn’t just thinking about the technology, I was constantly asking, how can we streamline their work? And in the process, how can I streamline mine?
There are a few essential tasks that need to be done to ensure our solutions are successfully implemented by customers. But to be honest, many of these are just operational steps—necessary, yes, but often tedious. At least for me, they felt repetitive and time-consuming. That’s exactly why I started building the tools below.
- .KMZ/.KML to .XLSX Converter: A tool that converts standard Google Earth files—used to represent FTTx network elements like FOSC, FIST, NAP, etc.—into structured Excel files ready for analysis
- .XLSX to RF Calculator: This tool takes a spreadsheet containing latitude and longitude info and uses it to query RF coverage data from one of our LoRaWAN partners. The result? A quick and insightful report to help determine the best sensor placement.
- IoT Sensors Alarms to Heatmap: A tool that transforms raw IoT alarm data into an interactive HTML heatmap. This was especially useful at a time when our platform didn’t yet support georeferenced visualization. Fun fact: the results of this tool ended up being so useful that they were included as input for a product requirement document shared with our engineering and dev teams.
A tool that transforms raw IoT alarm data into an interactive HTML heatmap. This was especially useful at a time when our platform didn’t yet support georeferenced visualization. Fun fact: the results of this tool ended up being so useful that they were included as input for a product requirement document shared with our engineering and dev teams.
This was a real challenge. With every new step forward, we had to make sure the tool was generating insights that actually made sense for decision-making.
The most important result? Time saved. This tool likely saved 1–2 hours per day for at least two engineers on my team—and also for the customer’s Product Owner. Over weeks and months, that adds up to a huge efficiency gain.
Writing this article and listing out these projects made me realize just how many tedious hours of work I’ve helped eliminate—whether for myself, my colleagues, or my customers.
Some of these tools started small, just as a way to make my own life easier. But over time, they ended up having a much bigger impact than I expected. Seeing how these ideas turned into something useful—and in some cases, essential—was incredibly motivating.
It reminded me why I love coding: it’s not just about writing software, it’s about solving real problems and helping people work smarter.
These days, getting started with programming is way easier than when I first began. Honestly, it’s even easier than any of the previous times I tried to learn. A big reason for that is the rise of AI, especially tools like GPT. We’re living in a time where you can ask questions, get examples, and debug code in real-time—without ever leaving your browser. It’s like having a mentor available 24/7. For me, that changes everything. It means I can go even deeper into problems, explore more complex ideas, and spend less time stuck. It’s not just about learning faster—it’s about solving better.