I have a common problem: I own too many books (both physical and on my Kobo) and a terrible memory for which ones I’ve actually finished. To fix this, I decided to build a simple tracking web app. Usually, a full-stack project—even a “simple” one—is a week-long commitment. I used this as a benchmark to see how far I could push AI as a coding partner. I managed to go from zero to a deployed PostgreSQL/React app in a single Saturday afternoon. ...

I recently had a conversation with a colleague that highlighted the widening “perception gap” in our industry. There is a distinct divide between engineers who experimented with LLMs six months ago and those integrating the latest frontier models into their daily workflows. The epiphany for my colleague didn’t come from the AI writing code—we’ve seen that movie before. It came when he asked the AI to perform a peer review on another developer’s PR. The AI didn’t just find syntax errors; it provided a more nuanced, architectural critique of the logic than he had prepared himself. When the tool begins to exhibit better systemic judgment than the builder, we have to acknowledge that the nature of our craft has fundamentally shifted. ...

A younger friend recently asked me a question that, for the first time in my career, I didn’t have a ready answer for: “Does it still make sense to study Computer Science?” They wanted to know if it’s still a “good investment.” I sat with that for a moment. AI is clearly the elephant in the room, and while we know the role of humans in this industry is changing, predicting the what and the how feels like trying to debug a race condition in the dark. ...

Dogfooding—the act of using your own product—is a simple, foundational principle in software development. But the most valuable lessons in dogfooding aren’t learned during a daytime demo. They’re learned when your system breaks and you have to truly live with the consequences. This takes me back to 2010, when I was at Nokia working on a crucial telco monitoring system. The Phantom Failure at 2 AM The system was running, but a peculiar and frustrating issue kept cropping up: the operator was complaining about consistent failures every day at approximately 2 AM. We couldn’t track the problem through our usual diagnostic tools, which left us baffled. This is a common failure mode in software: a problem that is simple on the surface but impossible to replicate in a testing environment because it only exists in the wild, interacting with the real world’s strange physics and operational schedules. With no clear path forward, I ended up deciding to spend the night in the Ops Center to try and figure it out. I recall that my colleagues were hesitant about this kind of commitment, but I took the opportunity. Sometimes, to truly solve a bug, you have to become a co-operator. You have to remove the abstraction layer between the developer and the user experience. ...

The “Nokia Test” and the Golden Age of Scrum The last post, The Death of the Agile Industrial Complex: A Full Circle, made me nostalgic for 2008. At the time, I was at Nokia (NSN), and the company made a massive pivot to Scrum. We even had Jeff Sutherland, the inventor of the “Nokia Test”, guiding us. Transitioning from waterfall to Scrum was challenging, but the impact was undeniable. My team’s score on the Nokia Test jumped from a 3/10 to a 9/10 in just a few months. In that era of massive 4G telco transformations, Scrum wasn’t just a framework; it was a lifeline that helped huge teams navigate immense complexity. I truly liked it—it brought a human spirit back to software development. ...

“Agile is an attitude, not a technique with boundaries.” — Alistair Cockburn When I started my career as a developer we were a lean team of three, building TV ratings software. There were no “sprint commitments,” no “PI Planning,” and certainly no “Release Trains.” We sat in a room, we understood the domain, and we shipped code. Communication overhead was effectively zero. Meanwhile, things changed. Last years (decade?) we’ve been living in the era of “Uppercase Agile.” We traded the original manifesto’s spirit for the safety of massive frameworks—SAFe, LeSS, and various “Enterprise” incarnations of what was meant to be a simple feedback loop. We built these scaffolds to solve a human problem: communication at scale is expensive. But as we move into 2026, the tech landscape is shifting under our feet. We are moving from a world of “Managing People” to one of “Orchestrating Outcomes.” And in this new world, the heavy frameworks aren’t just redundant—they’re a liability. ...

If you stay in this industry long enough, the “unprecedented” starts to look very familiar. History doesn’t repeat itself, but it often rhymes Lately, the air feels thick with the same electricity I remember from the late 90s. Back then, I was already a few years into my career, watching the world lose its mind over the “Dotcom” revolution. Today, I see history rhyming with the AI boom. The Era of Slideware In 2000, we had “slideware”—products that only existed in PowerPoint decks, backed by valuations that assumed we had rewritten the laws of physics. People were throwing millions at companies with no revenue and “growth at all costs” manifestos. Sound familiar? Today, I see the same pattern. I see “AI startups” on Reddit and LinkedIn claiming to automate entire engineering departments with a single prompt. I see investors rushing into “wrapper” companies that have no moats, no unique data, and—most importantly—no accountability. ...

The Natural End of Software Development: Speaking English Lately, my feed is full of panic about AI “replacing” software developers. The narrative is always the same: “If a machine can write the code, why do they need us?” This fear stems from a misunderstanding of what we’ve actually been doing for the last 70 years. We weren’t hired to be “syntax experts”; we were hired to be translators. The History of Compression Software development has always been a game of reducing the friction between a human thought and a machine’s execution. We’ve just been climbing a ladder of abstraction: ...

In the recent decades the business model for the IT industry in Portugal was mostly a nearshoring model, much of the industry profits from the difference between IT salaries in Portugal vs central Europe. Knowing that the average salary in Portugal is roughly 50% lower than Germany and it’s just 1h time difference, it’s easy to understand that this can be a very lucrative model. Things start to change during the Portuguese debt crisis during the early 2010’s, due to the dim opportunities at home many Portuguese youngsters moved to other European countries – moving abroad was particularly easy for the “IT crowd” given that their skills were in high demand abroad and usually it’s not a job requirement to know any other language besides English. This together with the fact that Portugal is a member of the EU and people can basically just decide to move other country and work there without much hassle. ...