Techknowledgy: The Invisible Work Behind Developer Experience

At first glance, developer experience might sound like a question of tools, dashboards, or shiny new platforms. But for João Almeida, Platform Engineering and Site Reliability Engineer (SRE), it's not about what developers see, it's about what they don't notice.

"The best systems are invisible. They guide you, support you by default, and get out of your way. When developers notice the platform, it's usually because something broke."

He's chasing flow, that focused, frictionless state where engineers can actually build without interruptions, delays, or second-guessing.

Designing for Flow

The flow, João explains, is about eliminating the micro-frictions that pull developers out of their zone. It's not about having zero obstacles. It's about making the path to answers so clear, so intuitive, that your brain doesn't even pause to ask, "where do I find this?"

Each tiny decision costs mental energy. Multiply that across every task, every day, every engineer and that's where productivity quietly disappears.

In other words: you don't need flashy platforms. You need systems that respect the developer's attention.

The Real Cost of Fragmentation

If there's one silent killer in developer productivity, it's context retrieval: that endless loop of hunting for a document, pinging someone for clarification, bouncing between wikis, repos, and outdated Confluence pages.

We optimize capability over clarity. Each team picks their tool of choice, but we don't design for how information flows across the organisation.

In the end, there are dozen places where knowledge might live and none where it definitely does.

Eventually, someone just pings a colleague because it's faster. That breaks their flow, too. The friction compounds.

Banning tools isn't the answer. Instead, we should be thinking architecturally: defining a source of truth, designing for discoverability, and applying the same discipline to internal knowledge that we apply to product systems.

The Carl.AI Shift

João's team didn't set out to "add AI" but set out to solve a bottleneck. Developers were wasting time chasing knowledge that already existed. So, they built Carl.AI, an internal RAG-as-a-Service platform, embedding answers directly into workflows: IDEs, terminals, and support channels.

The biggest change? Fewer 'where do I find...?' messages. Fewer context switches. More time actually building.

Innovation ≠ More Tools

For João, innovation has a different definition: it removes more complexity than it adds.

Every new tool should reduce friction. If it adds a new interface, new commands, or new decisions, it better be solving something significant.

More often, the solution isn't a tool, but a naming convention, a decision to deprecate options, or better integration between what already exists. This aligns with the Engineers mindset of building things, but a big challenge remains for the best solutions… they are boring! They have good documentation, sane defaults, predictable behaviour, but… no true integration to their frameworks.

If it makes you say "wow, that's clever", it might be too complex. If you say, "of course it works that way", you've designed for flow.

When asked to define great Developer Experience (DX) in one sentence, João doesn't hesitate:

Developers shouldn't have to think about the platform to use it effectively.

And that's exactly the point. The work João and his team do isn't loud, but it multiplies across engineers, sprints and every "wait, how do I do this again?" moment that never happens because the answer was already there.

The Silent Engine Behind Engineering

"Outdated documentation isn't just unhelpful, it's harmful. It erodes trust, wastes time, and breaks flow."

For João, respecting developer attention is a moral stance. It's about recognising that every minute spent deciphering a wiki is a minute lost in creativity, momentum, and impact.

So yes, sometimes the job is fixing something huge. But sometimes, it's just retiring a Confluence page from 2019. Because that's the invisible work that makes everything else possible.