disclaimer: this is meant to be a short text. i recommend putting this song on in the background to make the experience more interesting.
where does the complexity come from?
Software is by nature complex work. Building information systems means dealing with multiple layers of abstraction, technical decisions, business rules and people, all orchestrated to look almost magical.
The truth is that this simplicity is deliberately constructed. It hides a chain of decisions, tests and failures. This is where seniority comes in: seeing what is hidden, understanding the invisible, and making decisions that go beyond the screen.
how it started for me
When I decided to learn to program, becoming a software engineer was not the goal.
Like many people, my first impulse came from that hacker imagery: the guy in a hoodie, Mr. Robot style, breaking into systems, finding vulnerabilities, exploring gaps through the night while money magically landed in my bank account. I knew nothing about engineering, processes or architecture. It all looked easy. You just had to "break in".
Our education model does not tend to encourage building abstractions and analogies as a way of understanding. It is more of a robotic thing, where all professional practice is about doing more of the same, and working with technology is still seen that way.
It was no different for me. I started by learning intrusion techniques. But little by little, as I reflected on it, I started asking myself: what exactly does it mean to break into a system?
Every system had a bug, a flaw, a gap. Was inspecting an element and changing what shows up in the browser already "hacking"? I did not even know what was running on my own machine, or what a server was.
That is when I understood something essential: systems are made by people, and a chain is only as strong as its weakest link.
If I wanted to understand how to break things, I first had to understand how to build them.
the need to write my own tools
I soon realised that depending on other hackers' tools left me exposed. What guarantee did I have that those tools did not have flaws of their own? When a hacker broke a system and produced a crack for software that cost 2000 reais, what did they get out of it?
Why did that software cost so much? If the tools I was using were so powerful, what assured me they were not taking some of my information too?
So I started trying to build my own.
If I knew how a website was made, I could build my own website. Would somebody pay me for that?
That is how, in 2017, at 16, I wrote my first lines of code. I started with C++.
I had no idea how to turn that into something useful, but I dove into Deitel's books. It took me a few months just to understand what a for loop was and what all those ;, {}, () meant.
And after a lot of suffering, I ended up on the Python side of things (my deep thanks here to professor Gustavo Guanabara), and consequently passed through several other languages.
When I understood that I could describe a process once and the computer would do it for me countless times, something changed in my head. It was magic. Now I could do anything.
If I could teach a machine to do something for me, that would save me time; it could do the things I did not want to do, or I could do it once, understand the process, and leave it to my little robot.
Back then I thought I would become an electrical engineer. I had this idea of creating things.
I was always one of those kids who, when a toy broke, took the chance to see how it worked. Circuits, gears, tools, all of that was magic.
That is what programming became for me: a way to create, to abstract processes, and to turn the world into data and automated actions.
Building an interface or an algorithm that runs on its own, solving problems, always interested me. Except now I would not need to depend on a factory or a production line to express myself, right?
the illusion of "just make it work"
Over time, I came to understand what being a technology professional actually meant. IT did not mean "the computer repair guy"; it was not only about formatting machines or messing with some kind of electronics.
I went through the process of learning HTML, CSS and JavaScript. My first websites were almost static, they only displayed content, and I still did not really know how to let anyone reach my http://localhost:80. But I still had that mentality of "breaking" websites by changing things in the browser.
Little by little, I understood the difference between assembling a page and building a system. Over time I saw a lot of people selling the idea that with a six-month course you would earn 5 thousand reais a month programming. At university itself I saw an opportunity for growth, looking at all those cars in the course parking lot when those people had not even graduated yet.
But here is a reality check:
Any Computer Science freshman can replicate the ChatGPT interface in a month, but building the real ChatGPT and the entire structure that sustains it takes years, involves thousands of professionals and tonnes of technical, mathematical and computational knowledge.
What sets a senior professional apart is not only delivering a working system, but knowing how to abstract solutions, understand what lies underneath, communicate clearly, and sustain the thing that looks simple.
Thinking about it that way, we get access to the invisible complexity: the ordinary user only sees a little text box. A little robot that answers.
Behind it: absurdly complex mathematical models, terabytes of processed data, a distributed, scalable and secure infrastructure, logic, statistics, that thing called machine learning and artificial intelligence, systems architecture, product engineering, testing, governance, and all of that structure is built to look simple.
So that the non-technical user only has to press a few little buttons on a screen.
An example from iFood: one click is hundreds of systems and integrations.
You tap the screen, choose the food, pay, and shortly after it arrives hot at your table.
But behind that there are several systems for authentication, menus, payment and logistics, integrations with restaurants, delivery riders, internal and external systems. Screens for you, for the restaurant, for the courier, for the restaurant manager, for the iFood manager, network systems, telecommunications, backoffice, dashboards.
And there is still the doorman in your building who calls you when it arrives.
Not to mention what happens before the app: agriculture, transport, supply chain, all of it invisible, and it works because somebody thought about every detail.
the engineering of simplicity
The great art of software engineering lies in making complexity invisible. Making the process fluid, simple and reliable even though it is absurdly complicated underneath, because if you did not think about all of that, somebody thought about it for you.
"If I have seen further it is by standing on the shoulders of Giants". Sir Isaac Newton, 1675.
In the end, building software is about solving problems. But in an increasingly automated world, where everything looks easy, it is worth stopping to ask:
Which part of the chain did you decide to take on?
Which problem did you choose to solve?
Because deep down, that is what separates whoever just writes code from whoever actually builds systems. And despite everything, we are just another brick in the wall.