I still remember the day in 2005 when a technical support manager called me about a consultant position. My background was thin for the job: I was an enthusiastic C++ programmer, but I was missing most of what the role actually required. Luckily, they also needed someone in Buenos Aires who could speak English and French. That phone call was the start of my career at the company where I still work today.
People sometimes ask how anyone stays 21 years in one place. The honest answer is that I didn’t stay in one job. I’ve had several, and most of them started with me knowing less than I needed.
On the road
It was fun from the start, and I took every chance I had to learn. After a while I moved from technical support to professional services: I started visiting customers and traveling around the world. Our customers back then were mostly banks, credit card processors, huge factories and large laboratories. Every one of them taught me something.
Those years also gave me the habit that shaped the rest of my career: say yes first, then learn whatever it takes on the way.
One of my first trips, in 2008, was a proof of concept at an internet provider. Our monitoring products could watch IBM WebSphere Application Server, and my boss asked who could help with that part. I had never used WebSphere, but I said “I can do it.” I spent the whole flight, and the weekend in the hotel, reading the printed WebSphere manuals. By Monday our monitors were connected to their servers and everything was configured.
The paper manuals are long gone. The habit isn’t: I’ve needed it every few years since, and never more than in the last two.
The job kept getting better, and there are many more stories like that one. But after almost ten years, just as I was starting as a solutions architect, I realized that what I really wanted was to build software.
As a consultant I had worked more and more closely with the R&D team, and one day, over a coffee with the company’s COO, we agreed it was time for me to move to development.
It was a huge change: no more customers, almost no more travel, and no more fun… well, a different kind of fun.
The other side
The first months were hard. I was finally doing what I had always loved, creating software, but I missed the customers. On this side there is very little contact with them, apart from the occasional call when support needs a hand.
Agile was the other shock. As a consultant I had planned my own weeks, usually alone at a customer site. Now there was a daily stand-up, sprint planning, a retrospective, and estimates in story points. At first I resented every one of those meetings. With time I started to see what they were for, and after a while I couldn’t imagine working any other way.
I still miss the customers. But that background made me a better developer. I understand what customers need, I think about the product the way they use it, I design with their needs in mind, and I know their frustration when something doesn’t work. Customers also taught me that when something is broken, nobody cares whose job it is to fix it. When I led a team, I always tried to pass that on: there is a real person using our software, and a support request from a customer comes before almost anything else on the list.
From defense to offense
On the engineering side I walked the whole path: software engineer II and III, senior, team lead, and now principal software engineer.
My first five years as a developer were on Powertech Event Manager, originally Tango/04 VISUAL Message Center: security and infrastructure monitoring. I worked on the monitoring agents, the collectors and the correlation engine that decides which events, out of a flood of them, deserve a human’s attention. That was security work already, from the defending side: watching systems and spotting what an attacker leaves behind.
In 2019 I moved to Core Impact, a penetration-testing product, and I crossed to the other side: from detecting attacks to running them, the way a real attacker would, so that security teams can see how far one would get.
That was a real challenge. Knowing what defenders watch for helped, but exploits, attack paths and vulnerability scanners were a new world, and I had to learn them from the inside.
What surprised me most was how little a compiled program hides. With a disassembler and some patience, an attacker can work out how your code works, find an ordinary mistake, like an unchecked length or a buffer one byte too small, and turn it into a way in. None of that takes exotic tricks. It only takes code written without thinking about who else might read it. I took a few reverse-engineering courses after that, less to break things than to see what my own code looks like from the other side, and how to make it harder to exploit.
It was a lot of fun.
Then came the agents
A couple of years ago AI changed the job again, and this time it changed it for everyone at once. My team started using coding agents early, and we moved our development to them step by step. Once more I had to learn a new way of working, and this time nobody had printed the manual yet: we were writing it as we went.
The work itself changed more than I expected. I type much less code than I used to, and I read much more. A good part of my day is now deciding what should be built, explaining it precisely enough for an agent to build it, and reviewing every line that comes back. The agents are fast, and sometimes surprisingly good. They are also confidently wrong often enough that reading the diff is never optional.
I learned that on my own project, AfterNight. More than once I handed a feature to an agent, trusted the tests because they were green, and moved on, only to find out later that some of those tests weren’t really testing the new feature, or covered only a small part of it. Tests written by the same agent that wrote the code prove less than they seem to. Now I read the tests as carefully as the code.
I’m not complaining, and I keep using these tools. But what I never delegate, and why, deserves a post of its own.
Why I started this blog
That weekend with the WebSphere manuals is a good picture of how my generation learned: slowly, from the bottom up, one manual and one crash at a time. The main reason this blog exists is simple: I think we may be the last generation that learned how software works that way.
New engineers can get a long way without knowing what a memory allocation is, how a race condition happens, how to read a memory dump, or what actually travels through a socket. They’ll describe a feature in a prompt, and the model will handle the rest.
And that’s fine. Hardly anyone writes assembly by hand anymore either, and every new generation of tools has let more people build things. But getting code that runs is not the same as knowing why it runs.
An agent will happily write a cache that never evicts, take two locks in a different order in two places, or trust a length field it just read from the network. The code compiles, the demo works, and the bug shows up weeks later. Catching that in a review has little to do with writing better prompts. It comes from knowing what a memory leak, a deadlock or a buffer overflow looks like, usually because you caused a few of them yourself.
That’s the difference between letting an agent write code and engineering with one. Those of us who learned it the hard way usually know how to check what the AI is doing, correct it and steer it. The models will keep getting better, and I’m glad they will. I’d still rather know what is going on underneath, and write it down while I’m at it.
So that’s what this blog is for: my research, my findings and my questions. It goes from software engineering to astronomy and astrophotography (AI is reaching that art too, and I’ll write about it), and it’s for anyone who wants to read a human writing about programming, fun experiments, astrophotos, and a lot of low-level image processing.
A note on how I write here. Everything on this blog starts with me: the stories, the ideas, the experiments, the numbers and the photos. I write in English, my second language, and I use AI as an editor to tighten the wording. I treat its suggestions the way I treat an agent’s code: I read every line, and nothing goes out that I don’t agree with. No picture on this blog is generated by AI.
Still here
In twenty-one years, the industry reinvented itself more than once. There was an acquisition that felt almost like starting a new job without changing desks, many happy memories, and a lot of friends.
And the story isn’t finished. I’m still on Core Impact, still working with people I like, and still learning something new almost every week. Most mornings I open the laptop wanting to see what the day brings, which after twenty-one years is probably the best thing I can say about a job.
Not bad for a phone call in 2005.