DEV Community: Adam Belton

I built an engineering capability profile to show hiring managers what my CV can’t

Adam Belton — Wed, 02 Sep 2026 13:07:44 +0000

I've been tinkering with my CV endlessly over the last six months. It started with a decision that I needed a new chapter. And then what followed was a frustratingly slow but necessary process of figuring out exactly what I wanted that new chapter to be. It took time to figure out exactly where I was in my career, what kind of engineer I was, what I enjoyed doing, what I was good at, where I wanted to develop, what kind of challenges I was interested in, what kind of companies I wanted to work for, what kind of teams I wanted to work in, what kind of domains I wanted to work in.

These are not easy questions. Some of them I had answers for; I just didn't realise it until I asked the questions. Some answers took time to reveal themselves. And as I was able to answer more and more questions, my application volume dropped. Today, I have a very specific job profile that I'm looking for, and more confidence than ever that my next role will be where I do the best work of my life, so far.

This evolution lives in the version history of my CV. I think that's natural, because the CV is meant to capture my professional identity in a single document. It's natural to have been applying for roles as I was figuring out what I was looking for, and the CV is something I could keep coming back to. It was a routine process of refining my mental model of who I was and what I wanted, and then comparing that against my CV to see how well it continued to reflect that. As I evolved, so did the CV.

But once I reached the point of clarity and confidence, I realised that I was still tinkering. I was still making small tweaks here and there, as I kept revisiting specific wording, whether I was emphasising the right things, whether my CV was easily "scannable", whether it gave the recruiter or the hiring manager enough gradual substance to keep reading. And I think that tinkering will go on forever if I let it, because while the CV may be a great tool for capturing my experience at a high level, it's never going to be very good at conveying nuance.

I think my engineering profile is difficult to communicate in a conventional CV. And I spend a lot of time thinking about how to overcome that. I also spent time thinking about what it must be like for recruiters and hiring managers, sifting through piles of identical CVs, trying to find the right candidates to strengthen their team. And I'm not convinced that the CV is a great model for answering that question specifically: "Will this person strengthen my team?" The CV is very one-dimensional. It's not optimised to communicate the context or the depth of someone's experience with a skill. It doesn't tell you if they're pushing themselves, or in what direction. It doesn't tell you the kind of work that excites them, or where their personal competitive advantage lies.

When I put myself in the shoes of the hiring manager reviewing my CV, I imagine there are three questions my application needs to answer for them:

Do I have the capabilities to start contributing value today?
Does the work the role requires align with how I want to develop?
How might I offer outsized value over time?

Delivering Value Today

This is the question a traditional CV probably comes closest to answering. My CV is structured into the following sections:

Profile: a high-level overview of the type of engineer I am and the type of role I'm looking for.
Selected Impact: a selection of outcome-led bullets that surface my strongest evidence of delivering business impact.
Technical Skills: a map of hard and soft skills that I possess and technologies that I'm familiar with.
Experience: my relevant commercial experience and details about the types of projects I've worked on.
Current Projects: a selection of personal projects that I'm currently working on to experiment and develop myself outside of commercial work.
Education: a bootcamp. I'm a late bloomer with a previous life.

The skills and experience sections are probably the most relevant for this question, and between them a hiring manager can reason about what I'm capable of. But it's low resolution. If they wanted to understand how substantial my experience with a particular skill was, they would have to pick that skill and then read through my experience looking for evidence. And at best, they would be interpreting based on whatever information I decided to provide. If I haven't explicitly surfaced evidence for that skill, or haven't done it convincingly, that skill is just words on a page.

Development Alignment

I've had the privilege of working with some great servant leaders. One of the pillars of this style of leadership is creating an environment that supports you to develop yourself. Servant leaders encourage introspection and enable self-development by looking for opportunities to get you working on the things that you enjoy and in areas you want to grow. So it stands to reason that a hiring manager would be assessing this during recruitment. The question I need my application to answer is: "Are the things that I enjoy, the things that I'm good at and, crucially, the areas where I'm looking to develop well aligned with the role, its requirements and the opportunities that will become available as the product grows?"

I think that traditional CVs struggle with this, partly because of the recruitment process itself. The CV is a model of your professional identity, and its purpose is to convey your strengths. It tends to present every skill in the same flat way, with very little room to distinguish established practice from active development. And for good reason - you're being screened against other candidates. If your CV tells a recruiter that you're developing a certain skill, and another candidate claims strong proficiency, which candidate will the recruiter prefer? Especially in the early stages, before a hiring manager has gotten involved, how much nuance is there in the screening materials? Are required skills qualified with information about where strong proficiency is genuinely required vs where emerging capability and a strong interest would be just as good?

Outsized Value

I've only seen this language used in one place, but I have a hard time imagining any hiring managers not thinking about it. The best comparison I can think of is elite-level players in sports. In professional sports, success is determined by fine margins. Clubs want to recruit players who are difference-makers. I think this is a useful way to think about recruitment, from either side. For myself, I'm constantly thinking about what makes me unique: "What specific combination of my skills becomes more than the sum of their parts?" This won't include every skill I possess. There are lots of skills that I consider core competencies for any product engineer, but that aren't necessarily where I see my true value.

This also echoes the question from the beginning that I imagine hiring managers are asking: "Will this person strengthen my team?" I think one way that CVs attempt to answer this question is around impact framing. Recruiters and hiring managers look for evidence of the business impact you have already delivered, as a sort of proxy for what kind of impact you can be expected to deliver for them. I understand the reasoning behind this, but I think it's flawed.

I think that impact framing is evidence that you can articulate your impact, and that you think in terms of impact. But I think it's incomplete evidence of how you created that impact, and whether the same judgement would transfer into a different environment. Outcome-focused work is also shaped by the environment around you: the product culture, access to users, instrumentation, decision-making structures and the people you work with. Strong impact evidence can show that you've operated effectively within those conditions, but it doesn't necessarily tell a hiring manager which parts of the outcome came from your own judgement.

I think a much better indicator for what an engineer would give you is understanding how they think. That's one of the reasons I write and publish articles like this one, so prospective managers and colleagues can have a window into my thought process. But none of that really comes through in a CV. CVs are professional marketing materials. They're polish. They're for you to position yourself as a solution to an immediate problem. They're not optimised to communicate your potential long-term value.

Introducing: The Engineering Capability Profile

So what's the solution? Well, I spent a lot of time thinking about different ways to visualise my skills. My first instinct was inspired by sports: the spider graph. I thought about plotting my skills as points around an outer web, with an inner web representing proficiency, or an inner web representing my current focus and interest for each. But I didn't like the implication that I was "weak" or "disinterested" in certain areas.

I needed something that represented my skills across different spectrums of context. And crucially, I didn't want it to be ambiguous. I didn't want a hiring manager to have to do more work to understand what I offer. I wanted to present my skills in an inspectable way, with a simple interface that was also intuitive and flexible, that let someone view them in different contexts and dig deeper where necessary.

What I came up with was the Engineering Capability Profile. It groups my skills vertically, similarly to how my CV does, but it also adds context.

In the default view, each skill is tagged with the type of evidence that supports it (commercial ownership, commercial exposure or applied), where that skill lives inside my current development trajectory (maintaining, deepening or learning), and whether I see it as a core competency or an area of strategic leverage.

The three context views — evidence basis, development trajectory and leverage profile — regroup the same skills around one of those dimensions. Each skill can also be opened to inspect how I define it, the evidence behind it, how I'm developing it and why I classify it the way I do.

This capability profile tells hiring managers significantly more than my CV does, even at a glance:

Distributed systems

Commercial exposure / Learning / Core competency

This says that I've worked with distributed systems commercially without owning them directly, that I'm actively building the mental model needed to take on more responsibility, and that I see distributed-systems knowledge as an important baseline capability rather than a major source of my long-term differentiation.

Domain modelling

Commercial ownership / Deepening / Strategic leverage

This says that I've owned domain-modelling decisions commercially, that I'm deliberately making that practice more rigorous and systematic, and that I see it as a meaningful part of how I could create outsized value over time.

Back to the Three Questions

So let's revisit the three questions I posed before:

Do I have the capabilities to start contributing value today?

The capability profile communicates my skills alongside their context. If the role requires someone with deep technical experience with distributed systems, who can come in and take ownership of them, I'm probably not the right fit. That isn’t a weakness in the profile; it’s an honest answer to the question.

Does the work the role requires align with how I want to develop?

Alternatively, if the role requires someone who is actively developing their distributed-systems capability and will have room to grow into greater ownership, the role could be a strong fit.

How might I offer outsized value over time?

If the role and the wider product engineering culture heavily emphasise domain modelling, this could be an exceptional fit. I have meaningful commercial experience; I'm actively working on deepening my knowledge and capability; and crucially, domain modelling is a key part of how I see myself contributing outsized value long term.

Explore my Engineering Capability Profile

How treating my job search like a product problem helped me see what’s really making software engineering recruitment hard in 2026

Adam Belton — Mon, 24 Aug 2026 15:15:41 +0000

Get ready for a bit of a ramble about looking for a job as a software engineer in 2026.

No, it's not about AI changing the definition of software engineering, although there's obviously some truth in that.

It's about product engineering. Specifically, it's about the challenges software engineers face when searching for new opportunities because of the massive shift toward product engineering practices.

And because everyone is talking about AI, I think these challenges are flying under the radar.

I should preface what comes next with this: Searching for a software engineering job in 2026 is really hard. Scroll through LinkedIn or any software career blog and you'll see plenty of posts about how the recruitment system is broken, how good engineers are being ghosted, how CVs are being filtered out by AI screening for keywords. These frustrations are valid, but... you know what else is really hard in 2026? Being a software engineering recruiter. Being a software engineering hiring manager. And software engineering is about solving problems.

With that said, a problem is harder to solve when you haven't clearly defined it. So to lay the foundation, I want to address some challenges I've recognised before exploring what can be done about them.

The Problem Space

First, the thing that's been haunting me for the last 6 months. Impact articulation.

I suspect this isn't a problem that's unique to product engineering, but it's certainly one I've faced as a product engineer. Earlier this year, I completed full interview processes with two separate companies. I felt confident about both. The roles were the type of engineering I'm great at: sitting close to users, working through ambiguity and owning product areas end to end. But neither resulted in a job offer.

The feedback I received was surprisingly consistent: I demonstrated strong technical execution, methodical problem-solving, clear communication and product judgement, and consistently sought to understand the "why" behind the "how". But also, I struggled to connect my product decisions to business or user outcomes. It was clear that I was a great engineer. But they were looking for more observable evidence of how my work "moved the needle", so to speak.

They weren't wrong. And since those interview processes, it's been a gatekeeping problem too. I suspect it's played a major part in me getting screened out before interview.

But there's irony here. Part of the reason I struggled to articulate my impact was that impact measurement wasn't a big part of the engineering culture I was working in. My product engineering practice was born out of necessity. I was part of a small team working on a complex product with a huge surface area. I owned product areas end to end because I had to, not because the company fostered a particular product engineering culture. And I thrived there because I like deep ownership, I like sitting close to users and building deep domain context. It came naturally to me.

But small teams that scale fast tend to be very reactive. A big part of our workload was building things that new clients needed for their onboarding. What was missing was a culture of defining the problem we were solving, and the metrics that would tell us if and how well we were solving it. How do you measure impact when you don't know what problem you're solving?

Impact articulation was a gap that I was aware of and was deliberately looking to address by searching for different roles. It felt a bit like being a teenager and searching for my first job all over again. How do you gain the work experience that companies are looking for until one of them hires you? Chicken and the egg.

This leads me to another challenge I've discovered: Product culture ambiguity.

Tell me if any of these buzz-phrases look familiar:

"comfortable operating in ambiguity"

"aren't just ticket-takers"

"own products end to end"

When I first started my current job search, I got excited by these phrases. These describe the environment I thrive in, right? My CV is full of descriptions about how I've owned products end to end, made strategic product decisions, worked closely with users, and shipped early and often to deliver steady value.

But job description after job description, I kept seeing these phrases. I thought "product engineering" was a bit of a niche engineering culture that was just starting to gain traction over the last couple years. Suddenly it started to feel like every company out there wanted product-minded engineers. And if that's the case, why were so many of my applications being passed up, or worse, ghosted?

Then I started asking, what do these companies mean by "operating in ambiguity"? Are they looking for engineer-magician hybrids who summon perfect software solutions into existence? And what do you give engineers instead of Jira tickets? If operating in ambiguity just means "less detailed tickets", and product engineering just means "figure it out", that's not really the environment I'm deliberately looking for, is it?

I'm being facetious, but there's some truth here. Many job descriptions give you vague expectations, without describing the environment that they provide to set you up for success. They don't describe what product engineering looks like in their organisation with much useful specificity. I very rarely see job descriptions that mention:

"product discovery"

"domain expertise"

"identifying rules and constraints"

"questioning assumptions"

"modelling the problem"

"comparing solutions"

That last one I find especially interesting. I often do see language like "explaining trade-offs". That's a completely valid expectation, and an important one. But it makes me wonder, trade-offs in what context? What's the point of explaining trade-offs if you haven't specified a problem to be solved and considered multiple solutions?

Finally, the challenge I find most dangerous: Speed ambiguity.

What does "we move fast" mean? Here are some possible interpretations:

We "move fast" and break things.
We cut corners.
We optimise for volume.
We foster a high-pressure environment.
We don't care about work-life balance.

To be clear, I don't think this is what most companies mean when they talk about speed. But there are very different reasonable ways to interpret speed:

We ship small. We scope requirements aggressively to deliver frequent incremental value that can be validated quickly.
We experiment often and learn fast. We optimise for knowledge and discovery to keep us moving forward.
Our codebase is optimised for well-defined boundaries and low cognitive load, reducing regression risk and allowing for safer agentic delegation.

I think the biggest issue is the inherent tension between ambiguous speed and product engineering itself. Product engineering requires more from engineers. Deeper domain understanding, more involvement in product discovery, more critical thinking, more observation and iteration. "We move fast" is meaningless without being clear about how.

The Solution Space

I want to be clear that when I talk about "solutions", I'm not suggesting that I have all the answers. There are nuances to the problems, and I only have one perspective. So for me, a solution is an answer to the question:

"In the face of these challenges, how can I exercise my agency? What can I understand better, communicate better, select more carefully, or change about my own approach?"

Here's what I have done.

I (eventually) recognised that I was collapsing impact into a single concept, and as a result, I wasn't thinking critically about how to overcome the challenge. When I took a step back, I realised that there are actually three concepts.

I created impact with every decision I made that delivered product, user or business value. It certainly would have been helpful to have consistently defined the problem and decided how to observably measure the quantitative value of the solution in advance, but it's equally helpful to at least recognise that gap and take action to address it going forward. Regardless, the impact was still created.

As we've already covered, I did not measure impact very well. At least not quantitatively. I strongly believe that this is largely a symptom of the engineering culture I was part of, although I don't mean that as an excuse. I identified the limitation of my environment and took action. No point in dwelling.

Recognising the difference between the first two was the big unlock, because it helped me figure out how to articulate impact. Before, I felt like I had no meaningful way to describe the difference I made. But the reason I was able to deliver value without a more rigorous product discovery process was because I had built deep domain knowledge and understood the problems intuitively, which allowed me to reverse-engineer the impact retrospectively. That's no substitute for good product engineering practice, but it signals product thinking.

I think ambiguity is a more difficult challenge to overcome, and I wouldn't frame it as a solved problem. However, I think recognising the challenges can go a long way to mitigating them. Here are some questions I ask myself when I'm looking at roles to try and figure out if they're actually what I'm looking for:

"What evidence is there that engineers are expected to own or meaningfully participate in product discovery? What exactly do engineers own or influence?"

"How do engineers understand the domain? Is there evidence of deep domain learning, domain modelling, or working closely with users AND domain experts?"

"What is the team's definition of ready? Are engineers expected to define the problem, the outcome and what success looks like? Are outcomes measured quantitatively?"

"Does the role description consistently qualify its engineering expectations with evidence about how it supports engineers to achieve them?"

"If the team says they move fast, do they explain what fast means, what trade-offs they're making to achieve it, and how they mitigate any risks that the speed introduces?"

I think it's important to try and answer these questions, and in my experience, role descriptions don't cover them consistently. So it's probably worth reaching out to other engineers, the hiring manager or the recruiter. I have a theory that the less the recruitment materials answer these questions, the less well-defined the product engineering culture is.

If you're an engineer with significant experience within a mature product engineering culture, you may well be trained to recognise these signals already. But for engineers that are still navigating this transition, who have strong product instincts but haven't yet found the right environment, I think understanding the difference is crucial, and may go some way to explaining why applications don't get considered.

I suspect that the teams who are still figuring out what product engineering looks like for them are explicitly looking for engineers who already have the experience to help them shape it. And maybe because of that, they bias toward quantitative impact over qualitative impact. I think there's value in being able to differentiate between the two, because role descriptions aren't usually transparent about where they need help, and knowing the difference might save you time and energy.

It's probably worth asking yourself one more question:

"Is this team looking for someone to participate in its product engineering culture, or to help create it?"

Closing Thoughts

So back to chicken and the egg.

I think the first job metaphor summarises my thoughts about the massive shift toward product engineering cultures pretty well. Teams are moving toward product engineering. They want engineers with product engineering expertise. But how do you gain the product engineering experience they're looking for until one of them hires you?

Again, searching for software engineering jobs is hard right now. So is sourcing software engineering talent. So is deciding who to hire. But software engineering is about defining problems and then finding solutions. Maybe none of us can fix recruitment on our own, but we can each make small changes that have an outsized impact: candidates can be more thoughtful about the impact they can evidence and more selective about where they apply; recruiters can look beyond polished metrics for signs of real product thinking; hiring managers can be clearer about what product engineering actually looks like in their teams. None of that solves the whole problem. But it might make it a little easier for the right engineers and the right companies to find each other.

Which, for a bunch of people who claim to be good at solving problems, feels like a reasonable place to start.

P.S. One small thing I believe in strongly is offering a little guidance when an unsuccessful candidate asks for it. Detailed feedback isn't always practical, but a short note about what experience would make someone more credible for a future role can be genuinely useful. It helps candidates grow and companies build a stronger talent pool, while giving someone the chance to come back later having closed the gap — which probably tells you something useful about them too.

How the Socratic method and cathartic journaling helped me see ThoughtForm’s real purpose as a conversational thinking workspace

Adam Belton — Sat, 15 Aug 2026 08:11:28 +0000

ThoughtForm started out as a writing tool.

I'm the type of person who struggles to get my ideas out onto a blank page. I know what I want to write about, I know what I want to say, I've built 99% of the argument in my head. But I stare at the computer screen and nothing comes out. I don't seem to have this problem talking about my ideas, so why is writing about them so hard?

I think it's because feedback is missing.

When I'm talking to someone, I start with a couple of sentences. I watch their eyes, their face. I can see if they understand what I mean. They can ask questions, or I can check in with them to gauge their understanding. Critically, I'm learning as I speak. Questions can challenge my ideas, force me to reconsider or double down. I gain perspective, gain clarity, gain confidence.

None of that happens on the page. Not right away, at least.

I started creating ThoughtForm to try and replicate that conversational experience. AI as a conversational thinking partner. And a light copy editor. I didn't want AI to write for me, but I wanted it to help me shape my ideas into something coherent. To help me explore them, refine them, and discover the best way to express them. My goal, broadly speaking, was to have the same type of conversation I might have with a colleague, and end up with a piece of writing, my own writing, my own words, composed from that conversation.

That's what ThoughtForm does. But it's not a writing tool. You can use it that way, and I probably will. But that's not where I see its value.

Before I explain why, let's consider where the ideas behind this project originate.

You may already be familiar with Socrates. He was an ancient Greek philosopher known for teaching through conversation rather than simply giving people answers. He would question what someone meant, test their assumptions, and push them to examine whether their ideas really held up.

That approach became known as the Socratic method: using questions to help someone think more clearly for themselves. Socratic questioning is the practical technique behind it — asking for examples, clarifying vague ideas, challenging assumptions, or introducing another perspective.

Socratic writing applies that same process to writing. Instead of jumping straight into a draft, you question and develop the underlying idea first, then write from a clearer understanding of what you actually want to say.

Sound familiar?

Here's the thing. I'm reasonably sure that Socrates never conceptualised his method as a writing aid. He was interested in teaching people. More accurately, he was interested in teaching people to think for themselves. Just because the practical technique can be an effective way to produce balanced, nuanced writing doesn't mean that's where its true value lies.

I recognised from the beginning that the friction I experienced during writing wasn't really a writing problem, it was a coherency problem. I knew what I wanted to write about, I knew what I wanted to say, but it was all jumbled up inside me. I needed a process to extract it, examine it, and compose it. And what I was looking for was that "aha" moment where I get to read it back and shout, "Yes! That's exactly what I mean", in my own words.

But you know what's not necessary for that? An audience.

And if you're not writing for an audience, do you really need a writing tool? I don't think so. I think what you're really looking for is a conversational thinking partner. You're looking for a tool that helps you learn about your own thoughts and your own feelings.

I started thinking about when someone else might want a tool like that. I recently spent some time in counselling. I would talk about the things that were happening in my life and how I was experiencing stress because of them. I was always being asked how certain events or circumstances made me feel. And truthfully, I didn't know. I think most people, myself included, tend to just try to get through discomfort instead of inspecting it. I personally bias toward strategising. "How can I control the situation? How can I resolve it?"

I think the moment I knew that pivoting ThoughtForm away from being a writing tool was the right decision was when I discovered cathartic journaling. I already understood that sometimes just expressing uncomfortable thoughts and feelings was enough to make you feel better. Just saying something out loud, or writing it down, can release you from it. Cathartic journaling is an uncensored form of expressive writing: the act of putting deep, heavy, or hidden feelings onto paper to gain emotional relief. That's what I wanted. That was the "aha" moment I was after. Not just the emotional release, the catharsis, but the release amplified by Socratic insight. Not just getting words out, but expressing them coherently and truly understanding them.

So, what is ThoughtForm, exactly?

ThoughtForm is a conversational thinking workspace where an AI assistant helps you explore, organise and articulate what you think or feel. The assistant uses focused questions, examples, clarification, challenge and alternative perspectives to help you examine what is there without deciding the answer for you. As the conversation develops, ThoughtForm helps you build an evolving Idea Map of the thoughts, feelings, tensions and questions that emerge. You can inspect it, correct it, dismiss what does not fit, and choose what deserves more attention.

When you're ready, ThoughtForm then brings that developing understanding together into a coherent first-person expression. Your thoughts. Your feelings. Your words. You can read it back, correct it and continue exploring until it accurately reflects where you stand.

I built ThoughtForm around the idea that technology, and AI, should support your judgment, not replace it. It's not meant to think for you, to find answers for you, or to write for you. It's meant to make you more capable.

And it's the first of many products I plan on building that I'm calling human capability software. Technology that helps people do more for themselves.

How a shopping-centre mental model lets me see my personal website's ports-and-adapters architecture with my eyes closed

Adam Belton — Sat, 15 Aug 2026 08:11:27 +0000

This website serves two purposes:

It's where I write about how I think.
It's where I showcase what I build.

Soon, I'll be releasing my first demo product: ThoughtForm.

ThoughtForm is a conversational thinking workspace where an AI assistant helps you explore, organise and articulate what you think or feel. Through focused questions, examples, clarification, challenge and alternative perspectives, it helps you develop an evolving idea map you can inspect and correct. If it would be useful, it can then bring that understanding together into a coherent expression, in your own words. It is useful when something is bothering you, but you cannot quite put your finger on why.

It's not quite ready to show you yet, though.

In the meantime, I thought I'd tell you how this website works under the hood. Its architecture.

But instead of just talking about its architecture, I'm going to talk about how I think about its architecture. Architecture is inherently technical, and what interests me about building things is simplifying complexity.

Technically, the website uses a version of something called ports-and-adapters architecture. It has a host, delivery and application layers, capabilities, ports, adapters and composition.

I designed the architecture around those ideas. The technical language is useful because it gives each part a precise name. But knowing the names of things isn't the same as having a mental model for how they fit together.

I understand technical concepts best when I can see the underlying model with my eyes closed. It's a tool I use whenever something has lots of moving parts: I turn it into a picture I can hold in my head, move around and explain without relying on the technical language.

This is the picture I use for the website's architecture.

Here we go.

Imagine AdamBelton.com is a shopping centre. I'm Adam, and I own it.

There is a big unit at the front where I display my writing. Down a corridor are some smaller units where my projects operate. One of those projects is ThoughtForm, but we'll get to that later.

These projects could have their own buildings in different locations. But I like having them here, so you can visit them in one place instead of driving all over town.

One benefit of having them here is that they can share the shopping centre's resources. These include:

Security.
Storage.
Cutting-edge AI.

Right now, you're inside the shopping centre. You're in the main unit, looking at my writing. You haven't passed security because you haven't needed to. The writing is open to everyone.

If you were visiting one of the private project units, you would have to pass security first. They would ask you to sign in and check whether you were allowed through.

Then you get to ThoughtForm.

The way ThoughtForm works is that you have a conversation. You talk about what you're thinking or feeling, and the assistant asks questions to help you explore it. While that's happening, ThoughtForm builds an idea map: an inspectable view of the ideas you establish and the perspectives you explore. If you decide it would be useful, ThoughtForm can help you bring those ideas together in your own words.

We'll get into more detail about how this works and why it exists another time, but for now, let's get back to the shopping centre.

You walk into ThoughtForm, and here's the layout.

There is a receptionist at the front. Somewhere behind the receptionist, there is a floor manager wandering around. Behind the floor manager are three departmental offices with signs on their doors: conversations, idea maps and drafting. Inside each office is a specialist for that department.

At the back are two more doors marked storage and AI. We can't see behind them, but they connect the project unit to restricted areas of the shopping centre.

When ThoughtForm's unit was being designed, it told the shopping centre's fit-out team that it would need storage and AI.

But here is the important bit: ThoughtForm doesn't know how the shopping centre provides either of them. It doesn't deal with the suppliers or know what the restricted areas look like. It just knows what it needs to be able to ask for at each door.

This matters because ThoughtForm might want to relocate one day. It can't take the shopping centre's storage rooms or AI suppliers with it. But it can take the design of its doors. A new building would only need to connect suitable services on the other side.

Before the unit opened, the shopping centre's fit-out team connected those doors to the services it had chosen. If the shopping centre upgrades a service or changes suppliers, it can change what is behind the door without ThoughtForm needing to redesign itself.

Back to ThoughtForm. And you.

When you start a conversation, you speak to the receptionist. She passes your message to the floor manager.

The floor manager makes two copies. One goes to the conversations department. The other goes to the idea map department.

The conversation specialist takes your message through the AI door. A response starts coming back, and it makes its way through the floor manager and receptionist to you.

At the same time, the idea map specialist takes their copy through the AI door. They are not trying to respond to you. They are looking for ideas you have established, corrected or developed. If they find something useful, the idea map is updated.

The work that needs to be kept is passed through the storage door.

There are two important points here.

The first is that the conversations department and the idea map department work independently. They receive the same message, but they do different jobs and finish in their own time. The floor manager doesn't make you wait for the idea map before the conversation can continue.

The second is that this happens over and over again. You send a message, the floor manager coordinates the work, and each department handles its own area of expertise using services supplied by the shopping centre.

If you later decide to bring your thinking together, the drafting department gets involved. It works with the material you have established and helps create a draft in your own words. The draft is optional. You can use ThoughtForm to explore something without ever producing one.

That's the picture.

Like any metaphor, it isn't a perfect representation. It keeps the relationships I need to see and leaves out the details I don't.

Now the technical language has somewhere to live.

The shopping centre is the host. It provides the shared environment and infrastructure.

Preparing the unit and connecting everything before it opens is composition.

The routes and roads that bring you to the right place are HTTP. ThoughtForm's entrance and receptionist are its delivery layer. In another architecture, I might have called this a controller.

The floor manager is the application layer. She coordinates the complete job without doing the specialist work herself.

The departments are capabilities. They own the rules for conversations, idea maps and drafting. The specialists inside them are services.

The storage and AI doors are ports. ThoughtForm designs them around what it needs, without knowing what is behind them.

The connections fitted to the other side are adapters. They translate between ThoughtForm's needs and the shopping centre's actual services.

In shorthand:

Delivery receives.
Application coordinates.
Capabilities decide.
Ports describe what is needed.
Adapters connect the product to real services.
Composition connects everything.

That is not the only way to describe this architecture. It might not even be the metaphor that works for you. But it is the one that lets me see the whole thing at once.

And that matters to me.

I don't think understanding something means being able to repeat its terminology. I think it means being able to turn it around in your head, look at it from another angle and explain it without relying on the original language.

The code already shows what I've built. The repository is open for anyone who wants the technical detail. What I want to show here is how I make sense of it.

When a system becomes complicated, my instinct is to look for the smallest picture that preserves the important relationships. In this case, it was a shopping centre: a host, a fitted-out unit, a receptionist, a floor manager, some specialist departments and a couple of carefully designed doors.

That is how I see the architecture with my eyes closed.

If you ever understand the individual words in a technical explanation but still find the whole thing difficult to hold in your head, try looking for the picture underneath them. It doesn't have to be a shopping centre, and it doesn't have to make sense to anyone else at first.

Find the mental model that lets you see how the parts relate. Then give the technical language somewhere to live.