From Brazil to Building in the U.S.

My path into tech wasn’t linear. I grew up in Brazil, moved to the U.S. for school, picked up a math degree somewhere along the way, and somehow ended up doing cybersecurity while also being a full stack developer. If that sounds like a lot of context switching, it is. And honestly? That’s the part I like the most.

This is the post where I actually talk about who I am and what this blog is going to be. Buckle up.

Growing up in Brazil

Brazil does something to the way you solve problems. When you grow up in a place where resources aren’t always guaranteed, where systems are unreliable in ways you can’t predict, you learn to improvise with a kind of confidence that’s hard to explain until you’ve had to do it. You get very comfortable not having all the pieces. You build anyway.

I didn’t grow up surrounded by tech culture the way a lot of American developers did. There was no “learn to code at 10” pipeline, no robotics club, no startup ecosystem in my neighborhood. What there was: curiosity, a lot of math, and the internet. That was enough.

When I got to the U.S. for school, the culture shock wasn’t just about language or food or the fact that you apparently need a car to do literally anything. It was about how people framed problems. In the U.S., there’s a lot of emphasis on systems and process. In Brazil, there’s more of a “figure it out right now because waiting for the system isn’t an option” energy. Neither is better. Both are useful. Being fluent in both is a genuine advantage.

I say all this because it shaped how I code. I don’t wait for the perfect architecture before I start. I don’t assume the infrastructure will behave. I write code that degrades gracefully, that handles the weird edge case, that doesn’t fall apart the moment something unexpected happens. That’s not just good engineering practice. For me, it’s instinct.

Math was never optional

I have a math degree. Not a minor, an actual degree, from an American university. People sometimes find this surprising when they find out I’m also a developer, as if the two things are supposed to live in different boxes. They don’t.

Math taught me something that programming classes alone don’t: how to be rigorous about what you actually know versus what you’re assuming. When you’re writing a proof, hand-waving doesn’t compile. You either have a valid argument or you don’t. There’s no “this probably works” in a proof. That discipline transfers directly to software.

When I’m debugging something subtle, I’m not guessing randomly. I’m forming hypotheses, identifying what would falsify them, and testing one thing at a time. That’s just how mathematical reasoning works, and it’s a much faster debugging loop than vibes-based trial and error.

The other thing math gave me is comfort with abstraction. When you’ve spent time thinking about vector spaces, group theory, and probability distributions, the abstractions in software feel much less intimidating. Generics, type theory, functional patterns, they’re all just math with different syntax. The underlying structures are often things I already met in a classroom first.

Some specific areas that come up constantly in my work:

Linear algebra shows up everywhere in graphics, ML, and cryptography. If you’ve ever had to reason about matrix transformations or dot products, you understand why AES works the way it does at a much deeper level than someone who just memorized the steps.

Discrete math is basically the foundation of CS. Graph theory, combinatorics, logic, modular arithmetic. The Caesar cipher I wrote for a recent lab assignment is just modular arithmetic with a terrible key space. Understanding that isn’t just academic, it’s what lets you immediately recognize why it’s broken.

Probability and statistics matter in security more than most people realize. Risk scoring, anomaly detection, understanding what a p-value actually means when a vendor shows you their false positive rate. These are not optional skills if you’re doing serious security work.

Computer science as the connective layer

I’m still in the middle of my CS degree, and I want to be upfront about that: there’s a lot I’m still learning. But CS has given me the framework to understand why things work the way they do, not just how to make them work.

Operating systems, compilers, networking, algorithms. Each of those areas fundamentally changes how you read code once you understand what’s happening underneath. When I look at a slow database query now, I’m not just thinking about the query. I’m thinking about the storage engine, the index structure, the memory access patterns, the I/O cost. That’s a CS way of thinking about a problem.

The overlap with security is constant. Every vulnerability is, at its core, a misunderstanding between the programmer’s mental model and what the system actually does. Buffer overflows happen because someone thought about strings at the application layer and didn’t think about memory at the systems layer. SQL injection happens because someone thought about input as data and didn’t think about how the query parser would interpret it. CS gives you the second layer of thinking that prevents a lot of those mistakes.

Cybersecurity and the VintageSec work

I work at VintageSec, and security is the lens through which I look at pretty much everything now. Once you’ve spent enough time thinking about how systems get broken, you stop being able to look at a piece of software without mentally poking at it.

That’s not paranoia. It’s pattern recognition. You start noticing when authentication logic is in a weird place, when a serialization boundary isn’t being validated, when a permission check is missing or misplaced. These things become visible in a way they weren’t before.

The part I find most interesting about security is that it’s fundamentally about adversarial thinking. It’s not enough to think about what your system is supposed to do. You have to think about what it can be made to do. That’s a different mental posture entirely, and it makes you a much more careful developer across the board.

Security also has this interesting relationship with trust. Every system is built on a trust model: this component trusts that input, this boundary assumes that invariant holds, this token proves that identity. Making trust models explicit is something good security practice forces you to do. And explicit trust models make for much better architecture, even in systems where security isn’t the primary concern.

C++ and the thing about caring how hardware works

I love C++. I know that’s a somewhat controversial position in 2026. But here’s my reasoning.

When I write C++, I can’t pretend the hardware doesn’t exist. Memory layout matters. Cache behavior matters. Whether I’m copying or moving matters. The language forces a level of honesty about what the machine is actually doing that higher-level languages let you ignore. Sometimes ignoring it is fine. Sometimes it’s the source of a bug you’ll spend three days not finding.

C++ also has genuine expressive power when you use modern features well. Templates, move semantics, RAII, constexpr, the standard library algorithms. It’s not the same language it was in 2005, and people who write it off based on that era are missing what it’s become. It’s verbose, yes. The error messages are famously unpleasant. The build system situation is its own kind of chaos. But the control it gives you is real, and for systems work and anything performance-sensitive, that control matters.

I also use Lua, but that’s mostly for fun and small scripting things. Lua is what I reach for when I want to think about a problem without being slowed down by tooling. It’s the “let me sketch this out” language in my rotation. No CMakeLists.txt, no headers, no linker complaints. Just lua script.lua and the problem.

What this blog is going to be

I’m not trying to build a tutorial site or a “learn to code” resource. There are plenty of those, and most of them are better than anything I’d write for that audience.

What I want this to be is an honest record of what I’m thinking about and building. Posts about projects I’m working on, ideas I’m turning over, things I learned the hard way, and occasionally opinions I’ll probably still hold in five years. Some posts will be technical and detailed. Some will be more like this one.

I’m a Brazilian developer working in security and full stack in the U.S., studying CS, and genuinely interested in the craft of building software that works well, holds up under pressure, and doesn’t embarrass you at 2am when something breaks. That combination of backgrounds and interests is what this blog reflects.

If any of that sounds interesting to you, stick around.