Not every developer started coding at 12. Some of us took the scenic route. This is mine.
The Starting Point Nobody Talks About
My first tech job was in support. Not the glamorous "DevOps engineer who also handles incidents" kind. The real one: answering tickets, resetting passwords, and explaining to users why their report wasn't loading.
It wasn't what I had imagined when I finished my technical course at SENAI. I'd learned PHP, built small projects, and dreamed of writing code all day. But the market had other plans for someone with zero experience.
Why Support Was Actually Valuable
Here's what I didn't realize at the time: support taught me things that many developers never learn.
When you spend months listening to people frustrated with software, you start to understand what actually matters. Not the clever architecture or the elegant pattern, but whether the button works and the page loads fast. This perspective still shapes how I code. Before writing a feature, I ask myself: "What will the support team have to explain if I build it this way?"
As a support agent, I had to understand the entire system to troubleshoot issues. I knew which modules were fragile, which queries were slow, and which features generated the most tickets. When I finally moved to development, I wasn't starting from scratch. I knew the codebase's weak points better than some of the developers who had built it.
There's also the communication side. Translating technical problems into human language is a skill. Developers who can do that are rare, and I got daily practice.
The Transition
The transition from support to developer happened at the same company. My manager knew I had a technical background and gave me a chance to work on some internal tools. Small things at first, like fixing a form validation or adding a filter to a report.
But small wins compound. Each fix proved I could handle more. Within a few months, I was officially a developer.
What Changed, What Didn't
My imposter syndrome got louder (and I learned to ignore it). I started caring about code quality, not just "does it work." I began reading other people's code obsessively to learn patterns.
But some things stayed the same. I still talk to users regularly. I still debug with the same curiosity I had in support. I still believe the best code is the one that generates zero support tickets.
For People on the Same Path
If you're in support right now, dreaming of writing code, here's what I'd tell you.
Build things on the side. Your portfolio matters more than your job title. Every personal project is proof that you can code. Automate your support work too — write scripts, build internal tools, create dashboards. It shows initiative and develops real skills.
Don't hide your support experience. It's an asset, not a weakness. You understand users better than most developers ever will. And be patient, but not passive. The transition won't happen overnight, but it also won't happen if you just wait.
Where It Led Me
Today I work at a fintech, building backend systems with PHP, Laravel, and AWS serverless that process real financial transactions. The path from support to here wasn't a straight line, but every stop along the way taught me something I still use daily.
The developers I admire most aren't the ones who started earliest. They're the ones who understand that building software is about solving problems for people, and that understanding comes from experience, not just code.