It was a big paradigm shift for me. Navigation stack instead of URLs and browser history. App lifecycles. Platform quirks, and trying to solve platform-specific issues with no Kotlin or Swift experience was a daunting task.

I could certainly build something functional after a few tutorials, but I couldn’t build solutions to problems I’d never seen. And that’s why brownfield work has been the most valuable experience in my career.

Questions I Didn’t Know to Ask

My first real Flutter work wasn’t building something new. It was working in existing apps, what developers call brownfield work. And there was a lot in them I didn’t recognise. What was runZonedGuarded, and what did it do? It turned out that a lot more could go wrong in a Flutter app than I was used to, and this was the last line of defence, catching anything that slipped through everything else so it didn’t fail silently.

When using plugins, there were errors that could hide at the platform level. Rendering issues could replace an entire page with an error screen instead of failing quietly. And don’t get me started on migrating legacy code to null safety. That certainly teaches you why all those layers of error handling are needed when a null assertion sneaks in without a null check.

Seeing the layers in an existing codebase prompted me to ask the questions, and experience working in that code taught me why they were important.

Someone Else’s Code

I think packages are great (no, not the ones from Amazon). Why reinvent the wheel when someone has freely chosen to share their work? But every package you add to your project is now code that you’re responsible for. Like brownfield work, you have to work with something you didn’t create and don’t quite understand.

This makes them an invaluable learning tool, for better or worse. Well-supported packages from highly regarded sources can show you how to solve a common problem. The less polished ones still have value, even if it’s in learning what not to do!

A colleague was looking at a package to meet a client’s design request rather than building something from scratch. When testing, the performance slowly degraded as the list of results grew. Digging into the source, I found it relied on IntrinsicHeight, a widget Flutter’s own documentation warns is expensive and should be avoided where possible. With traditional page navigation, it would have been fine. With infinite scroll, every new batch of results made it worse. I advised removing it, and we looked for another solution. The package wasn’t bad. It just wasn’t built for the way we were using it.

Why Wouldn’t You Update?

Something I was slow to understand was why anyone would pin package versions. Why wouldn’t you update to the latest version with bug fixes, security patches, and new features? I update my laptop, my phone, why wouldn’t I update my code?

Later I realised there were constraints you don’t see in the code. That’s exactly what Architecture Decision Records are for. Language updates and packages would frequently drop support for older Android and iOS versions, which would take the app away from a number of loyal users. We had the analytics to show how many, and for the client, it was too many.

It wasn’t a long-term solution. There was always the risk that a critical security update might force our hand. We would need to update it eventually. But for now, we had to make a compromise.

Brownfield work teaches you that compromises happen all the time. The skill is understanding why they were made, and recognising when it’s time to undo them.

The Clean Slate

Realistically, no one is giving free rein to the newbie. You’ve got to show you can handle yourself in messy, real-world code, where decisions were made for you years before, and there’s no one left who entirely understands it. It’s a lot easier to follow best practice when you’ve got a clean slate and you’re making all the calls.

And the scary truth is that the clean slate is getting rarer. When code generation and AI tools can scaffold a new project in minutes, even more of the work will be understanding and building on code you didn’t write. You’re still the one responsible for the code, and the one who has to fix it when things go wrong. If you don’t understand it, be prepared to spend your afternoons swearing at a chatbot.

Kindred Spirits

Brownfield work isn’t the runner-up prize. It’s where some of the best learning happens, if you’re willing to see it. And sometimes it’s so much more rewarding to find a solution when there’s no easy answer.

For me, it did something more. I was scared of greenfield. Being responsible for a whole project, what if I got it wrong? Brownfield work actually helped me get over that fear. Nobody was writing the “perfect” code I thought was expected of me. If you feel the same way, perhaps you’ll find some kindred spirits in the codebase you work in.

What has brownfield work taught you that a tutorial never could?

And it turns out that there is a way - Architecture Decision Records.

What are they?

Architecture Decision Records (ADR) are actually a surprisingly simple solution to a common problem in software development. They are a short formal record of architecture decisions made for a software development project. This could be the choice to use one package over another, or a feature scoped down due to technical limitations. They can even be used more broadly to document project decisions, like deferring a feature due to time constraints.

The specific details recorded can depend on the organisation, the size of the project etc. but the important thing is recording the decision, the context and constraints around it, and the consequences.

What are they for?

Their core purpose is to record the context and consequences of important architecture decisions about a project. It answers the question "why did we do it this way?", but also "what happened next?".

We're not trying to understand decisions made months or even years before, when the original authors have moved on. We're not rehashing debates we've already had. We have a clear record of the trade-offs we considered, and can judge whether they're still relevant now. Can we now pick up that feature that was parked waiting on a package update? Can we replace that clunky workaround that was supposed to be only temporary?

And just as important, we can see the consequences of those decisions, and use them to better inform future choices. As with most documentation, we're building a project that outlasts us.

How to Use Them

They're refreshingly simple, which is why I'm still flabbergasted I'd never heard of them before now.

Each ADR lives as a short, numbered record, one decision in each one, with a descriptive title. A handful of fields hold the important details.

Status - usually something like proposed, accepted, or superseded. Most important in a team where you aren't solely responsible for the decisions needing made.

Context - the situation as it stood at the time. Any constraints that could affect the decision, whether these were technical, logistical, or even broader business or client constraints.

Decision - what was actually decided.

Consequences - what the decision costs, and anything you're accepting as a trade-off. This field is where a lot of value lies for future planning.

Some teams add more - alternatives considered and why they were rejected, who was involved, links to related ADRs, dates. The size of your team, the responsibilities and accountability they have, any standards the business aligns with, may require additional fields, but the four above do the heavy lifting.

Where you keep them isn't important, as long as it's a consistent, centralised place that everyone knows to check. A folder in the repository, or in whatever documentation tool you use. If you're also documenting broader project decisions, make sure the people who need to know can find it!

How does this benefit you?

If you've read my thoughts on building a portfolio, I talked about how difficult it is to demonstrate engineering thinking in code. A finished feature shows what you built. It doesn't show why you built it that way, what else you considered, or what you deliberately left out.

This is where a simplified version of ADR can still be useful, even on a project where you're the only person who'll ever read it.

Most of what's in a full ADR exists for a team's benefit. Status matters when someone else needs to know if a decision is still under discussion. Who was involved matters when there's more than one person to ask. On a solo project there's no one to update and no one to consult.

Context, decision, and consequences. The restrictions you faced (even if self-imposed), the decisions you made, and the effect it had on the outcome of the project.

In my own project, I recorded a decision to defer image performance optimisation to keep momentum, rather than stalling while I figured out the best way to do it in a new language framework. That one line showed that I knew of its importance to the user experience, and made a deliberate decision to come back to it after I had a complete feature to refine. A far better alternative than simply omitting it, or leaving a feature half-finished while I tried to find the "perfect" solution.

When I discovered ADR, it was a revelation. It was the solution I didn't know I was looking for, and strangely few people seem to know about it. I mentioned it to a few colleagues along the way, and most had never come across it either. It barely gets a mention in most of the Agile literature.

Did you know about Architecture Decision Records? Have you been reaching for a solution to documentation woes?

What's a technique or skill you found genuinely useful that hardly anyone around you seemed to know about? Share it in the comments.

Choose Your Solution

It will probably seem a bit counter-intuitive thinking about the solution rather than the problem - most portfolio advice first tells you to find a problem to solve. But what if the problem you find requires a solution using knowledge and skills that don't match with what your portfolio needs to show?

If you have an idea of the kind of solution you want to build, then it makes it easier to find a problem that will fit that solution. For example, I wanted to demonstrate proficiency specifically with React. For me, this meant that the solution would be primarily front end focused, using an existing API or mock data to avoid spending time setting up a full stack.

Start off with an idea of the shape of the solution - full stack, frontend/backend, the specific technology or skills you want to showcase - then start looking for problems to solve.

Finding a Problem to Solve

Even with the shape of the solution decided, this is still the part I find hardest. Knowing that I want to build something frontend-heavy in React doesn't tell me what. It narrows things down a bit, but it's still a blank page taunting me.

The most important thing for me is to find a problem that genuinely interests me. The only thing motivating me is me. Whether I'm truly invested in the solution, or the process itself excites me, there needs to be a hook that keeps me coming back.

Try to start with something you personally want solved. This is the hardest one to find. There are a lot of creative and talented people out there who may have already solved your pain point, and it's hard to find motivation when you know there's a solution already. But if there's a headache in your own life that your chosen stack could fix, give it a go.

If there isn't, try to reverse-engineer something you already use. You already understand the shape of the problem, because you're a user of the existing solution. You know what it does badly, what's missing, what you'd change if you built it yourself. Look at the features you use most, and start there - the ability to take something big and break it down into what actually matters is a skill in itself, and one that shows up more the further along you get. You're not trying to out-build the original. You're proving you understand the problem well enough to solve it your own way.

If you're still stuck, solve someone else's problem that catches your interest. This is the option most portfolio advice defaults to straight away, and it works, but only if the interest is genuine. If it's a common problem, add a twist that makes it stand out, and shows you didn't copy someone else's homework. Avoid picking a problem purely because it sounds like a good portfolio. That's how you end up with something technically competent that proves nothing.

Tried all of the above and still staring at a blank page? That's completely normal, you're not alone. Good teams don't put all the decisions on a single person, and there's no reason your brainstorming process should either. Talk it through with a colleague, a friend, or even AI. I've had useful results by asking AI to interview me about my hobbies and interests, then suggest problems in that space I might want to solve. It doesn't hand you the idea. It asks the questions you might not have thought to ask yourself.

Perfection Is the Enemy of Action

I've talked about how important it is to stop and think before jumping straight in to writing code, but at some point, you have to stop planning and start building.

When you know that someone else will be looking at your work, it's hard to resist the urge to curate that view. You only want them to see the perfect version of the developer you are. But that's not how it works in the real world. A project that shows how you can refine a solution as you go along demonstrates a lot more than one that looks perfect first time.

You don't need the perfect solution. You need a solution - something built, something that works, something you can point at and talk about in an interview. A finished, modest project beats an ambitious one that's still 60% done six months later. Even a partially functional project with a roadmap is more valuable than a project you never started.

Perhaps you'll encounter problems along the way that you don't know how to solve the “right” way yet. Acknowledge the knowledge gap, do it the “wrong” way, and add a comment to come back to it. This happens more than you think in real projects, technical debt is everywhere! An intentional choice to defer an architecture decision to keep momentum going shows more than a stalled project.

Something Is Better Than Nothing

I've focused here on a code-based project, because for most that's the most direct way to prove you can do the job. But maybe your specialisation is in building AI agents, technical documentation and training, big data and analytics - there are so many more roles in the sector than there used to be.

Pick the format that makes sense, but the lessons still apply - think about what you need to demonstrate, envision the shape of the solution, and find a problem that fits. Don't wait for the idea to be perfect, the stack to be exactly right, or the timing to feel ready.

A finished, honest, slightly rough project beats a perfect one that only exists in your head.

Years later, stalling at mid-level, I still had the same problem. I could write code someone else defined, but didn't know what I was supposed to build for a portfolio. I didn't know what direction I was going, I didn't know what my portfolio needed to prove.

It's only now that I have a clearer idea of what sort of engineer I want to be, the direction I want to go, that the portfolio question has finally clicked. Not because I've come up with an incredible project idea, but because I understand now what I'm trying to show, and to who.

That's the piece most advice skips. It'll give you a list of things to build, rather than showing you how to figure out what your portfolio needs.

This isn't a list of project ideas. It's the thinking I wish I'd had a decade ago.

What Is the Portfolio For?

Most portfolio advice fails to ask the most important question, why are you building a portfolio? “Because someone more senior said I needed to” isn't enough. Spending some time thinking about what you're trying to demonstrate and to whom will guide you towards what you should be building.

Coding vs Engineering

Early on in your career you probably just want to demonstrate that you can write code outside of a tutorial or course assignment. A simple, complete, functional project will do the job. Later on you need to demonstrate that you can think beyond the ticket, that you can decompose a problem into actionable tasks. That's something a bit harder to demonstrate entirely with code, but including architecture decisions in your README explaining the why as well as the what, can give a hint of how you think.

Who Is It For?

Recruiters may only spend a couple of minutes on your portfolio, looking for keywords that match their job spec. Talent acquisition could be looking for a hint of the engineer you could become. The hiring manager might be looking at immediate technical aptitude in their stack. An interviewer could ask you to walk through your project, challenge your decisions, and ask what you would improve. Your fellow engineers may be looking for a solution that comes from someone who has faced the same problem.

Format Is Also a Demonstration

Some still repeated advice is to build a portfolio website. If you're a backend engineer, what does this prove? That you can fumble your way through an unfamiliar domain, wasting time on polishing UI rather than demonstrating the skills you already have?

A well-organised GitHub profile - pinned repos, a proper profile README, project READMEs that explain your thinking rather than just your stack - demonstrates the same narrative a bespoke site is supposed to. For a while my blog was solely my portfolio, because it's a much easier medium to demonstrate senior engineering instincts than pure code. Perhaps you create YouTube coding tutorials, or an engineering podcast - link that instead.

What to Demonstrate by Level

Not every company uses the same titles or progression. There's no shared definition of what makes a junior/mid/senior engineer, and titles may vary depending on organisation. Take these categories with a pinch of salt.

Graduate/Junior

At this stage, there's not a lot to prove - only that you can write code without someone dictating the solution for you. This is where a lot of portfolio advice falls down. There are plenty of examples of TODO list apps, solutions to coding katas in a variety of languages, and AI can throw together something workable without much effort. That's not to say you need to create something entirely new, build a simple version of something you're familiar with using, create from scratch something you use a package for, put a new spin on the old favourites - like adding gamification to your TODO list.

The key here is to demonstrate that you can write working code for an unfamiliar problem. Try to avoid third party packages unless proficiency with those is what you want to demonstrate. Same goes for code generation tools and AI. Do it by hand and be prepared to explain what every piece of code does. It's ok if it isn't perfect, no one is expecting perfect, you just need to show that you're trying.

Mid-level

At this stage, it becomes less about the code, and more about how you got there. Can you break down a vague task into something actionable? Clean, decoupled code demonstrates this up to a point, this is where documentation does the heavy lifting. Explain your architecture decisions, the trade-offs you considered, how you structured the project, and why.

Asking questions and challenging assumptions, thinking rather than just doing is an expectation at this level. It's something else that documentation demonstrates better than code. If you've chosen a non-standard solution, explain your reasoning rather than leaving the reader assuming you don't know any better. If you're building for future scalability, flag it so the reader doesn't assume you've overengineered the solution (something AI is prone to do).

Senior

At this point, the focus is on the engineering rather than the code. Instead of “can you build a thing”, it becomes “can you build a thing that outlasts you”.

Deployment and containerisation start to matter here, rather than working inside an existing CI/CD process, you're expected to build and maintain it. Hosting a working project demonstrates that you don't fall into the “works on my machine” trap.

Architecture decisions become bigger and focused on sustainability, problems are larger and more ambiguous. Documenting these is crucial, as these decisions can't be explained by code alone.

Now What?

None of this tells you what to build. That's deliberate. Knowing what you're trying to prove, and to whom is the real work. Most portfolio advice skips straight to the project idea because the project is the visible part, and frankly, the more fun part. But a technically impressive project built for the wrong audience, proving the wrong thing, is still a wasted weekend.

Once you know what you're aiming at, knowing what to build, and how to build it becomes a bit less daunting. We're not finished yet though, next time I'll dive into the practical advice for figuring that part out.

Before that though, there's a question worth sitting with first — one most career advice skips entirely: where do you actually want to go?

A lot of developers stuck at mid-level are trying to grow without knowing which direction they're trying to grow in. And that matters, because the answer shapes everything that follows — the projects you ask to be involved in, the conversations worth having, the things worth reading. Trying to close a gap without knowing what's on the other side isn't progress.

Do You Know Where You're Going?

Some developers already have an answer. They know they want backend, or DevOps, or mobile, or a particular domain. If that's you, skip ahead — the next section is about building on that. This one's for developers who don't have an answer yet, and have been quietly assuming that's a problem.

The answer is pretty simple: do things. Try as many things as possible until you find the thing that really excites you.

Put your hand up for the project outside your usual lane. The ticket nobody's claimed. The cross-team piece that needs a developer. Ask your manager for opportunities to try something new.

If those opportunities are lacking, there's plenty you can do on your own time - but only if it excites you. Don't spend your down time on a second job. There are plenty of free MOOCs (massive open online course) on a range of topics. Open source projects to explore, and even contribute to. Content creators sharing their knowledge and passion.

You might not find yours immediately, but ruling things out is just as valuable. Once you've got even a rough direction, everything after this gets easier to act on.

Build Your Own Curriculum

Once you have a direction, it's time to find the knowledge and tools taking you that way.

Tutorials are an obvious starting point, particularly if you're focusing on a specific tech. Blogs can be a valuable resource - there are plenty of engineers keen to share their knowledge on how to get started.

Talk to seniors and tech leads, but ask specific questions. Tell them where you want to go and ask how to get there. Most seniors have forgotten what it felt like to be mid-level; giving them a destination is often what unlocks a useful answer. If you don't have the right seniors around you, online communities can fill the gap.

Look at job listings for the roles you want — not to apply, just to read. The skills that keep showing up across multiple listings, regardless of company, are the ones worth paying attention to.

What Nobody Tells You to Learn

Some things matter no matter which direction you pick, and nobody tells you that explicitly because everyone assumes you'll magically pick them up.

Source control, testing, CI/CD, containerisation, cloud technologies, and now AI. Depending on the organisation and your chosen specialisation, you may not need to use all of these, but you should understand how they work, and how they interact with what you do.

Being able to work in a team is a frequently misunderstood and undervalued ability. Writing code and documentation that doesn't need you in the room to explain it. Breaking down features into decoupled tasks that can be worked on in parallel. Being able to resolve merge conflicts, or cherry pick commits. Understanding how to submit a good pull request, and equally how to give a meaningful review.

Sometimes The Way Out Is To Move On

Sometimes the plateau isn't something you can push beyond from the inside. You can ask the right questions, put your hand up for the uncomfortable work, and still find that there isn't a path forward.

A business that doesn't invest in developing its people does both itself and them a disservice. You stagnate. They lose the developer you could have become.

If you've genuinely exhausted what your current role can give you, looking elsewhere isn't disloyal. It's the next step on the same journey. The skills gap you've identified, the direction you've found, the questions you now know how to ask — those travel with you. A new environment with new people, new problems, or simply more investment in your growth can accelerate your progression in ways that staying put never will.

You Were Never Actually Stuck

The mid-level plateau feels like stasis. It isn't. It's the point in the journey where the road stops being obvious and you have to figure out which direction you're actually heading.

The developers who come out the other side aren't the ones who waited for someone to hand them a map. They're the ones who started paying attention, asked better questions of the people around them, and were honest with themselves when the environment they were in had stopped being the right one.

Find what excites you, keep asking questions, make your own path.

If you're in the middle of this right now, drop a comment. Someone else on the same journey might need to hear it.

It was useful to begin with. When I made mistakes, well - I was only a graduate. When I didn’t know something, that was expected. Nobody looks twice at a graduate asking a question they probably should already know the answer to.

The shift happened gradually. I stopped making the mistakes I used to. When I did get something wrong, I owned it instead of hiding behind the title. I was being trusted with bigger clients, and the label was starting to work against me.

So I asked to drop it. They agreed.

And then I started to notice something that hadn't been obvious before.

The Silence That Should Have Been Reassuring

Every performance review was positive.

No criticism. No areas to work on. Not even small things — speak up more in meetings, improve your handovers, anything. I’d only been doing this for a couple of years. Surely there was something I could be doing better?

They must have missed something. I couldn’t be doing this well. At some point someone was going to notice.

But underneath that was a darker thought. If there was nothing to improve, was anyone actually paying attention? Was anyone invested enough in my progression to notice what was missing?

To be fair to the people around me — my line manager tried their best and genuinely cared. But they were as constrained by the business as I was. The issue wasn’t the people. It was that the environment didn’t create the conditions for growth. And without those conditions, positive feedback stops being a green light and becomes a ceiling.

The Job I Had Wasn’t the Job I Wanted

The work was varied — configuring existing software products for clients, writing one-off scripts, managing data migrations, a bit of technical support. Valuable exposure, all of it. But the projects I was working on had no persistent codebase, no source control, no CI/CD. They were delivered and forgotten, because they were never intended to be maintained. I was often working alone, some direction from my manager, but mostly figuring things out by myself.

The variety did mean I worked across multiple tech stacks, dipping into different layers as the project demanded. Web development one week, a Perl script the next, a data migration after that. At the time it felt like breadth. In hindsight it was closer to sampling — enough of everything to get things done, not enough of anything to go deep.

There’s a metaphor I keep coming back to. When you start secondary school, you don’t specialise immediately. You study everything — languages, sciences, arts, humanities — not just to build a complete education, but to discover what you’re actually good at and what genuinely interests you. The specialism comes later, once you’ve had enough exposure to make an informed choice.

Early career works the same way. The variety of that first role was my curriculum. I just didn’t know yet what subject I was looking for.

The Glimpse

About three years in, I was asked to join a digitisation project. Part of an initiative to preserve 1.8 million historical films, photographs and sound recordings.

It was the first time the job felt like what I thought the job was supposed to be.

Proper software development. Requirements gathering sessions. Source control. CI/CD. A persistent codebase that would outlast the project. And for the first time, a real team — people to learn from, to share ideas with, to ask questions of without feeling like I was exposing my ignorance.

I also started thinking beyond my own ticket for the first time. My UI was the entry point to the whole system. I needed to understand what every other part required to make sure I was capturing the right information in the right way. The shift from configuring an existing product to building something new — considering the UI and UX, keeping it consistent with an established product suite — was the kind of problem I hadn’t known I wanted to solve.

The Realisation

And then the project ended.

Nothing like it followed. I asked for more variety in the work I was given — more of what that project had felt like. The answer was effectively no.

Looking back, I’d optimised myself into a corner. I’d become so efficient at the work I was doing that moving me elsewhere didn’t make business sense. That’s not malicious — it’s just how short-sighted resourcing decisions get made. You become indispensable at exactly the wrong thing, and the business has no incentive to change that.

Nobody was going to hand me the way out. If I wanted something different, I had to be the one to go and find it.

For me, that meant leaving. It wasn’t the only option — it was mine, at the time, for my circumstances.

It’s hard to progress when you don’t know what you don’t know. I didn’t have a word for what I was feeling yet. I just knew “keep it up” wasn’t a direction — and that nobody else was going to give me one. Whatever came next, I was going to have to be the one to make it happen.

Share your moment of recognition in the comments. Someone earlier in their journey might need to hear it.

I've worked across enough languages and frameworks over the years that I don't dread the switch. The engineering fundamentals travel. It's often just a matter of learning the syntax, and IDEs do most of the heavy lifting now.

What does travel, and what doesn't — that's the more interesting question. Mental models and instincts built in one stack will carry you a long way in another. But they won't always translate neatly, and occasionally you'll hit something that isn't a translation problem at all. It's a new model, and the only way through it is to recognise it for what it is and build from scratch.

Component composition

In Flutter, UI is built by composing widgets. Every element on screen is a widget, and complex layouts are built by nesting simpler ones. The build() method returns the tree.

class ProductCard extends StatelessWidget {
  const ProductCard({required this.title, required this.price, super.key});

  final String title;
  final double price;

  @override
  Widget build(BuildContext context) {
    return Card(
      child: Column(
        children: [
          Text(title),
          Text('£$price'),
        ],
      ),
    );
  }
}

React components map onto this cleanly. A function that accepts props and returns JSX, composed in exactly the same way. The mental model — break the screen into discrete pieces, pass data down, compose upward — transfers directly.

function ProductCard({ title, price }) {
  return (
    <div className="card">
      <p>{title}</p>
      <p>£{price}</p>
    </div>
  );
}

The shift from class-based to functional feels big at first, but the underlying thinking is the same. If you've built a widget tree in Flutter, you already understand component composition in React. You're not learning a new concept — you're learning where it lives in a different framework.

Stateless and stateful

React distinguishes between components that own state and components that don't. A component that just receives props and renders them has no state of its own — it's purely presentational. A component that manages its own data uses useState to do so.

// Presentational — no state, just renders what it receives
function ProductCard({ title, price }) {
  return (
    <div className="card">
      <p>{title}</p>
      <p>£{price}</p>
    </div>
  );
}

// Stateful — owns and manages its own data
function AddToCartButton({ productId }) {
  const [added, setAdded] = useState(false);
  return (
    <button onClick={() => setAdded(true)}>
      {added ? 'Added' : 'Add to cart'}
    </button>
  );
}

Flutter draws the same distinction explicitly in its type system. StatelessWidget for components that depend only on their configuration, StatefulWidget for components that need to manage change over time.

The pattern exists in both because it's not a framework decision — it's an architectural one. Keeping presentational components free of state makes them easier to reuse, easier to test, and easier to understand. If you've been applying this in Flutter, you already know how to apply it in React.

Server and client components

Flutter is client-side. Everything renders on the device. There's no server-rendering step to reason about, no boundary between what runs where.

Server components broke that assumption.

In Next.js App Router, components are server-rendered by default. They run on the server, have direct access to data sources, and send HTML to the client. Client components — anything that needs interactivity, browser APIs, or React hooks — are opted in explicitly with 'use client'.

// Server component — no directive needed, runs on the server
async function ProductList() {
  const products = await getProducts();
  return <ul>{products.map(p => <ProductCard key={p.id} {...p} />)}</ul>;
}

'use client';

// Client component — needs the directive, runs in the browser
function AddToCartButton({ productId }) {
  const [added, setAdded] = useState(false);
  return <button onClick={() => setAdded(true)}>{added ? 'Added' : 'Add to cart'}</button>;
}

Nothing in a Flutter background prepares you for this boundary. It's not a syntax problem — it's a rendering model you haven't needed to think about before.

Knowing when to stop translating

The instinct when learning a new framework is to look for the equivalent. What's the React version of this? Where does this concept live here? It's a good instinct.

But it has its limits. If you force a new concept to fit your existing mental models, you'll never truly understand it, and if you write code you don't understand, how will anyone else?

I've seen this mismatch in practice. I was reviewing a tech task from a React developer transitioning to Flutter. Rather than reaching for Flutter's own state and lifecycle model, they'd pulled in packages to emulate React hooks — effectively trying to write React inside Flutter. The build() method was doing things a build() method shouldn't be doing.

It wasn't a Flutter problem. It was a translation problem that had gone one step too far.

Server and client components caught me in exactly the same way. They were confusing for precisely as long as I was trying to map them onto something I already knew. The moment I stopped looking for the SPA equivalent and started treating the server/client boundary as its own concept to learn from scratch, it started to make sense.

That's the skill worth developing — not knowing everything, but recognising quickly which category you're in. Is this unfamiliar, or is this genuinely new?

What transfers

If you're coming to React from another framework, the instinct to map what you already know is the right one. Use it. The compositional thinking, the component boundaries, the habit of breaking a screen into its smallest meaningful pieces — these travel. The decade you've spent building UI isn't framework-specific knowledge.

The skill isn't knowing everything — it's recognising when you've hit the edge of what your existing models cover, and being willing to set them down and build something new.

You know more than you think, but there's always something new to learn.

If you're mid-transition between frameworks right now — what's transferred cleanly, and what's required a new model entirely? Drop it in the comments.

Not literally. He's a hobbyist coder with a talent for AI, and was curious whether he could distil my engineering knowledge into skills and agents to code like me. The way I think through problems, the engineering principles I value, the instincts that I've built over 10 years. He asked me to articulate them. And I could.

It made me realise that I had a clear idea of the kind of developer I was, and it was something I'd been building over the years. Earlier in my career I didn't know. I knew how to do the job, but I didn't know how I wanted to do it.

This post is about that gap, and why closing it matters.

Adrift

As a fresh graduate, I did whatever the job called for. Configuring a client's product, styling their website, a data migration script. It was all new and exciting, I was getting good feedback, I felt useful.

Then I was seconded to build something from scratch. A public-facing web front end for museum collections. Lightweight, performant, built in Angular. Nobody else in the business knew Angular, nor did I.

But what followed was one of the most formative experiences of my career, and also one of the loneliest. Every decision was mine. Every problem I hit, I solved without anyone to check my thinking against. And somewhere in the middle of it, I started noticing something. The solutions I was reaching for, the ways I was structuring things... they felt right.

That validation came later, when I encountered those solutions again — in other projects, in other contexts, in a book that gave them names I hadn't known to look for. The realisation wasn't that I'd got it right. It was that I'd been paying attention before I knew it mattered.

That project also showed me the cost of working alone. The product I delivered was good. But I was the only one who understood it. It started to tell me what I actually wanted from the work. Not just to build things. To build things that would survive without me. To leave things better than I found them.

Every time I dipped back into it as new feature requests came in, I recognised the value of clean code. If I couldn't read code I'd written months earlier, how could my colleagues? If I couldn't remember the architecture decisions I'd made, how could I change things with confidence?

And what was I leaving my colleagues? I was building something they would need to maintain, a new product they needed to be able to customise, in a language none of them knew. I didn't want them to have to go through all the same painful lessons I did. I wanted them to be able to use it without needing me in the room to explain it.

Every decision on that project was driven by people. My colleagues. The archivists. Members of the public. Respect for their time, their ability, their security. I was starting to see what sort of developer I wanted to become.

What's the point?

So what's the point of knowing this about yourself?

Part of it is direction. Software engineering covers so many different kinds of roles that the sooner you know which way you want to go, the better. It means you know what you want from your current role, what you're looking for in the next one, and when it's time to make that move.

The other part is recognising fit. Rather than chasing the tech stack or the salary, you can look for the places that will let you do the kind of work you actually want to do. You ask different questions in interviews. Instead of trying to convince someone to hire you, you're finding out whether they can take you where you want to go.

It doesn't mean you'll always get it right. A role can sound ideal on paper and still not fit in practice. Or you find yourself heading in a different direction than the one you started on. But knowing something isn't right means you can do something about it.

Do you know who you are?

If you're reading this and you don't have a clean answer — that's fine. I didn't either, I wasn't even asking the question.

You don't find it by sitting down and deciding. You find it by paying attention to what you keep coming back to. The parts of the job that don't feel like work. The decisions you make that feel right. The things you care about that nobody put on the ticket.

You're not choosing values off a list. You're noticing the ones that are already there.

What do you keep coming back to, even when nobody's asking you to? Share it in the comments. Someone still figuring out their own answer might recognise themselves in yours.

I could never fully relax when I took leave.

Even after a thorough handover, there was always the chance that something might come up that only I could solve. I don’t mean that as a boast — there were genuinely things that only I had the knowledge and training to do. I’d spend the break dreading that something urgent would come up and I’d get the call. And even if it passed without incident, there was the fear of the pile of work waiting on my return.

Sick days were worse. No handover, no planning ahead. I would wake up feeling awful and feel even worse at the thought of my colleagues having to deal with something they didn’t have the training for.

I don’t think I ever truly had a break in that job until I left it.

Good Intentions

I never set out to become a single point of failure.

I was a fresh graduate, lucky to have secured a job, and determined to keep it. Whatever task I was given, I did it without question. If I came across something I didn’t know, I learned it. Every problem that landed on my desk, I solved alone — because I didn’t know any other way. And all the signals I got back reinforced it.

I was praised for my productivity, my willingness to learn, to muck in. It felt good. I felt valued. I’d saved critical projects from disaster. The CEO knew my name. I felt like a celebrity.

It took a while before I realised the cost. To myself, and to the people around me.

Consequences

I felt the cost to myself first. Never being able to switch off, afraid that eventually I’d be given something I couldn’t handle and there would be no one to help me.

When I handed in my notice I realised the impact on my colleagues. I spent my entire notice period training, running workshops, writing documentation. I didn’t realise how much I’d been carrying until I had to put it down. And I didn’t realise how much I’d taken from my team — so many opportunities for someone else to learn and develop. Instead, I’d left them with processes and systems only I understood.

The problem with carrying everything is that it all falls down without you there.

The Other Side

I took a holiday and didn’t think about work once. Not because I’d spent hours preparing a handover, but because the knowledge was already there. I didn’t realise how much I was carrying alone, and I didn’t even realise it was a choice. A choice to do it myself because it was faster than explaining it. Maybe in the moment it feels that way, but it never is.

I didn’t know there was an alternative. Now I do.

Now I write the documentation before it’s needed. I share my knowledge before it’s asked for. I mentor the people around me to share the load I used to carry alone. I finish on time. My notifications are off. And I can truly switch off when I’m not there.

It took me a while to get here. But I did.

Choose Your Path

If you’re a rockstar developer and you’re happy, I’m happy for you. There are plenty of start-ups that need your energy, your willingness to wear multiple hats, build fast, and keep moving.

If you’re not, this is for you. Your value lies in what you bring to the team, not in being an entire team yourself. Skim past the job listing that wants you to build the whole product alone. Document the things that only you know. Suggest that maybe someone else on the team might like to learn that new technology.

It doesn’t mean you’ve stopped caring, or that you’re not contributing. You’re contributing to an engineering culture that will last without you there to maintain it. If that’s the kind of developer you want to be, this post is for you.

If AI is giving you imposter syndrome, my previous post is for you. This one is a bit more practical.

After watching and reading a number of opinions, I found a position that worked for me: offload the less fun parts of the job to AI, so I could spend more time on the interesting things. There’s certainly a lot you can do with it, but here are a few problems you might encounter in your day to day that AI is useful at solving.

Take On a Research Assistant

More time than I’d like to admit is spent trawling the internet. Either trying to find the answer to a problem or hunting for supporting evidence for the answer I’ve already arrived at. It’s not easy. The information might be buried in a support thread or a GitHub issue and pulling it all together can be a huge time sink.

What if I didn’t have to?

AI excels at collating data - pulling together multiple sources, organising them, drawing conclusions. My first forays were simply using Google’s AI mode to find information on very specific problems. More targeted than a standard search, and considerably faster than piecing together a picture from a dozen different tabs.

But it’s not only problems I search for - it’s solutions too. When approaching something entirely new, I used to research possible approaches, evaluate the pros and cons, and work out what fit my context. It worked, but it was slow. Now I have that conversation with AI instead. I describe the problem, the constraints, and work through the options. It doesn’t decide the solution; it gives me the information to make the choice.

Clear the Blank Page

I’ve always been intimidated by a blank page. I know what I need to say, but I don’t know where to start. AI has helped me get over that hurdle many times. I ramble out a stream of consciousness with all the points I need to make, and it turns it into something coherent and identifies the missing pieces. Once I’ve got the shape of it, I can take it from there. Refine the parts missing context, fill in the gaps, bring in my knowledge and experience. The AI draft is just the starting point.

It’s not just documentation that can benefit. I was building out a UML class diagram for a data model. To help plan the implementation, and as a reference for anyone joining the project later. Building it by hand was time consuming and tedious. I wondered if I could feed in some sample JSON and ask AI to generate it. After a couple of prompts, I had the UML. It worked.

Writing documentation isn’t glamorous, but you feel its absence when you need it. It’s often set aside because it can easily eat up a developer’s time. It was a necessity I’d always accepted and never considered if there was another way. Now there is.

Close the Gaps

Not every project will have a clear brief. Perhaps it’s speculative work, a proof of concept, a brand-new product, or the client hasn’t quite refined their vision for the end result. Going from clearly defined use cases and acceptance criteria to vague requirements - especially if you don’t have a lot of experience in the product space - can be pretty overwhelming.

Use cases and acceptance criteria are crucial to project delivery. They give a clear vision of the expected outcome, inform implementation approaches and test strategies. But building those from scratch takes time, and there will be a lot of unknowns.

I wondered if AI could help me get something workable quickly. Something to give us initial guidance that we could then refine and figure out what questions needed to be asked. I gave it the vague requirements, descriptions of the stakeholders, and it gave me some use cases. It wasn’t perfect - it only considered the happy path - but I knew what good use cases looked like, so I could build on it.

If you’re the sort of person who needs help getting started, or there’s a gap you don’t quite have the skills to close yet, maybe AI can give you a little boost.

Learn on Your Own Terms

I used to struggle in school. The teaching methods of the time didn’t really fit the way my brain worked. I always found it easier to learn by myself, following the threads that interested me, rather than a strict curriculum. As an adult, I can never finish tutorials that touch the surface of a topic - it’s depth I’m after. What I really need is a coach that can work with me, tolerate a million questions, and show me where to find the answer instead of just telling me.

Surprisingly, AI has been a very useful coach. I explained my desire to learn React and my learning style, and it pointed me towards resources to start with. When I went off on tangents, it would direct me towards the answers - asking thoughtful questions to confirm my understanding rather than just handing them over. Self-directed learning can be difficult. Having something give a little direction makes it so much easier.

I need context to really understand a topic. Reading and cross-referencing multiple texts to build that context is a daunting task - and this is where NotebookLM comes in. You can upload your learning material and have NotebookLM do that cross-referencing, becoming an expert source on exactly the topic you’re interested in. Every response cites its sources too, which takes away much of the hallucination risk that makes AI feel unreliable.

If you struggle with self-directed learning, or standard teaching approaches have never quite fit, try building your own personal AI tutor.

What’s Your Problem?

I never really planned to adopt AI. I was curious about this new technology but didn’t know what it could do for me. Many software products emerge to solve a problem, and that’s where I started - problems that were taking my time away from the really interesting stuff, that prompted the question: “I wonder if this works?”

If you don’t know where to start, look at your frustrations. The tasks that drain your time and passion, the blank page that intimidates you. The boring, unglamorous bits of the job that need to be done but are never as exciting as building something new.

Your colleagues and seniors should always be your first port of call. AI can fill a gap when no one else is available, you’re the subject matter expert, or someone needs to close the gap and this time it’s you. It’s there to supplement the talented people around you, not replace them.

And you don’t need to subscribe to anything to find out. Many AI tools have generous free tiers. Try a few, see what works for you, pick your favourite - or use them all.

What pain points do you think AI might help with? Is there a use case I haven’t mentioned?

If you’re confused and uncertain, you’re not alone.

This post is about finding the middle ground. Where you don’t have to sacrifice your agency to the altar of AI, where you won’t be replaced by it, where you can do what you do best.

Not Just a Tool

You may be tempted to think of generative AI as just another productivity tool. Something to handle the boilerplate, the tedious parts of the job you can do in your sleep. It certainly can, but not if you approach it as a simple tool. Tools take explicit input and will give you the same output every time. There’s no guarantee of that with generative AI, even using a detailed prompt.

Instead think of it as a collaborator. A junior developer with lots of book learning but little experience of real-world systems. They understand the theory of clean code and architecture, they understand what design patterns are, but they don’t know how to apply them to real world problems, to legacy codebases with quirks and odd workarounds.

And like many inexperienced developers, instead of admitting when they don’t know something, they’ll give you an answer that sounds so plausible you’ll doubt yourself. Treat it like you would a junior developer. Verify the solution, question the approach, and give feedback until you arrive at the solution that fits.

Instead of being replaced by AI, you’re being promoted. You need to operate as a senior guiding a junior. Give them the context, give them the constraints, and review their work. Move beyond your role as a developer and embrace the challenges of an engineer.

Promote Yourself

Another common refrain is that software engineers will become little more than prompt engineers, but this undermines what prompt engineering actually is. It is defining your problem in terms detailed enough to get a predictable output.

Sound familiar?

Using the junior developer example - you wouldn’t give a junior developer a one line brief and expect a perfect implementation first time. You would break the problem down into actionable tasks, you would give them acceptance criteria, you would describe any context and constraints that affect the task. And if their first try wasn’t quite right, you’d guide them in the right direction.

By delegating some of the “how”, you can focus on the real problem, the “what”. And this is where your skills and experience can’t be replaced by AI. Software engineering is about understanding the problem well enough that you solve the right one.

Own It

For any developer that seeks to progress, the path to proficiency with AI is the same path you’re already on. Defining problems clearly, architecting solutions, guiding junior developers - these skills will enable you to get the best outcomes out of generative AI.

But the most important thing you bring to the table is accountability.

Generative AI doesn’t care about code. You do. You care about the experience for the end users, you care about the technical debt, you want to be proud of the work you produce.

So just like you wouldn’t immediately approve a code review without understanding what the code does and why, don’t accept everything generative AI produces without applying that same rigour and judgement.

Trust Yourself

It’s easy to be intimidated by AI. You might be focusing on one language or tech stack; it has instant access to a wealth of information on all of them. New vibe coded apps pop up daily. How can you compete?

The answer is that you don’t need to. How you add value is with the experience and judgement you have built over years of wading through legacy code, handling specialised client requirements, and recognising problems before they’re an issue.

Trust yourself. Focus on the stuff that really matters.

Still figuring out where you stand with AI? Join the discussion. Someone else in the same place might need to know they're not alone.

Look Beyond Your Team

Most developers understand their own responsibilities. Senior developers understand everyone else’s too. Not to do their job for them, but to understand how the work connects.

A bug was reported. Investigation revealed that a value in the API response wasn’t what the front end was expecting. A team member picked up the task, added some defensive code, and submitted a pull request. Job done. In this example, the bug was actually a mapping error in the middleware which took less time to fix. A few minutes of conversation with another team could have saved hours of unnecessary work.

Sometimes it isn’t as simple as that. There might be a constraint in a third-party platform, or decisions made earlier in the project that can’t easily be changed. Then the question becomes “what’s the best compromise that minimises work and risk for both teams?” But someone needs to ask the question in the first place.

The habit to develop is simple: when something is unclear or doesn’t look right, raise it. Not every flag will turn into something significant. But the ones that do will save far more time than the ones that don’t.

Make the Invisible Visible

First, we took knowledge from outside our team, now we give back. To other teams, other projects, and your future self.

We had a problem with a feature in a third-party package. The fix in the immediate project was straightforward. But I also reported the issue in another project using the same feature, advised a third project not to use it, and updated our best practice documentation with the issue. The bug was fixed once. The knowledge was fixed permanently.

It’s not just about the code. Share with the backend team how the data is going to be used to help inform their decisions. Inform the project manager if an architecture decision adds technical debt to the project. Flag to the technical lead when a dependency is approaching end of life. Document decisions and why they were made so you’re not doing the work twice, or trying to understand a decision made months ago.

That last part is what many developers skip. Not out of carelessness, but because the ticket is closed and the next one is already waiting. Investing in institutional knowledge is invisible work. It doesn’t show up in a sprint review. But it compounds, and teams that do it consistently are far more effective than teams that don’t.

Pass It On

Many senior developers have huge depths of knowledge, but that knowledge serves no one if it isn’t shared. When you’re the only one who understands a particular system or technology, there’s no one to help you, no one to learn from, and you risk being trapped by your own success. I’ve come back from leave to a mountain of work that no one else could tackle, pigeonholed in roles that I’d become too good at.

You don’t make yourself indispensable by growing your knowledge, you do it by growing the team’s knowledge. You don’t need to be a manager, or have a formal mentoring role, there are things you can do every day. When you research a new technology or tool, document it, run a workshop. Ask questions in code reviews, suggest improvements not just for the code, but for the developer. If you find an interesting article, share it. Loan out your books. Small investments which can lead to incredible growth.

It also benefits you. Teaching something forces you to understand it properly. When I worked through Head First Design Patterns, I made sure I understood each pattern and had built a working example before I shared them with the team.

The developers who invest in the people around them are the ones teams are built around. Their absence would be felt not just because of what they know, but because of what they’ve given away.

What You Don’t Have to Do

Not every senior skill is for every senior developer. The role is broad enough that two people with the same title can have genuinely different strengths, different preferences, and different ways of contributing value.

There will always be parts of the job you don’t enjoy. That’s fine. The goal isn’t to become a developer who does everything. It’s to be excellent at the things that matter most to you and your team, competent enough at the things that affect your work, and honest about the things that belong to someone else.

I can talk to clients. I’ve done it, and when I have to I handle it well enough. But the project manager has far more experience in it, and the work is better for it being theirs. Recognising that isn’t a gap in my seniority. It’s self-awareness. And a team where everyone is playing to their strengths is a more effective team than one where everyone is performing a role they’re not suited to.

Know your strengths. Be honest about your preferences. Don’t fill gaps indefinitely that belong to someone else. Give yourself space to do your best work.

Direction of Travel

If there’s a single thread running through all of this, it’s this: seniority isn’t a level you reach, it’s a direction you travel in. There’s no moment where you arrive and stop. There’s no perfect version of the developer you’re trying to become. There’s just the next step.

The title, when it comes, will be the least interesting part of the story. What matters is that it's already true before you ask for it.

And if I had to distil everything across this series into a single instinct to carry with you, it would be this: pay attention, show up for the people around you, and leave it better than you found it.

That isn’t just advice for your codebase. It’s my philosophy for most things.

What's the one thing you wish someone had told you earlier in your career? Leave it in the comments. Someone earlier in their journey might need to hear it.

A client wanted to explore adding biometric login to their app. Months earlier, a penetration test had flagged the risk of rooted devices. We made recommendations, the client reviewed them, implemented, moved on.

But biometric data, stored on a user's device, that changes the risk. No one else had made the link yet. Flagging it early changed the conversation from "how can we do this?", to "how can we do this securely?".

That's what this post is about. Not just paying attention, but seeing how things fit together.

Stand Up and Listen

Standups are a huge learning resource that you may be overlooking.

In the example above, I wasn't assigned to investigate biometric login. But when my colleague mentioned the strands they were exploring, I made the connection. If I had simply treated it like a daily update, zoned out and gone back to work, I would have missed so many opportunities to learn and contribute.

Look for areas of overlap, look for similar problems that might share a solution. Have you already solved a problem someone else is struggling with? Take notice of what the rest of the team is saying. Did they flag a connection you didn't see? Think about how they got there, or ask them later if you still don't understand.

Seniority doesn't come without experience, but it doesn't just have to be YOUR experience. You don't need to have all the answers yet, the important thing is that you're looking for them.

Physician, Heal Thyself

Code reviews are not just about improving the quality of the code, they're also about improving the author. Read reviewer comments with an open mind, ask questions, and take those lessons on to the next task.

Look beyond your own code reviews. How have others approached their tasks, what feedback did they receive, do you understand the reasoning behind it? Ask questions!

Take the lessons you learn from reviewing other's code back to your own. Look at it with a critical eye. Would someone else be able to read and understand it? What would you raise if it wasn't yours?

Reframe

The tech doesn't matter, it's the thinking behind it that lasts. Focus on books that teach you how to solve problems, rather than give you the solution.

My personal recommendations to get started with:

• Clean Code by Robert C. Martin - Make your code readable for those who come after.

• Head First Design Patterns by Freeman, Freeman et al. - Start recognising the repeating patterns in your and other's work.

• The Pragmatic Programmer by David Thomas and Andrew Hunt - Building the habits and instincts that will stick with you throughout your career.

• Refactoring by Martin Fowler - Navigating and improving existing code.

As with the code, read them critically, translate them to your context. Some concepts may not map cleanly. Bridging that gap is where the journey to senior begins.

Not My Problem

As a frontend developer, when investigating a bug, my job is to figure out where it lives. If the data coming from the backend is correct, the fix lies with me. If it isn't, the issue belongs somewhere else.

For a long time I would keep going. Checking logs, sending Postman requests, digging into middleware code. Trying to hand over a diagnosis rather than just a problem. I thought I was being helpful.

What I was actually doing was taking longer than they would, and taking the learning opportunity away from them in the process.

Now I give them the cURL, the timestamp, and the response. That's everything they need. They diagnose it faster than I ever could, and they thank me for it.

Knowing where your expertise ends isn't a limitation. Listen to the backend developer. Listen to the subject matter expert. Listen to the person who has spent years in the problem you've just wandered into. You'll learn more, and the work will be better for it.

What have you noticed today? Join the discussion.

I noticed most of these signals in myself first. But it wasn't until I watched for them in someone else that I was certain of the change. Seeing senior thinking in another person teaches you more than you'd learn alone.

This is what it looks like. In the code, in the decisions, in the conversations. Whether you're wondering if it's happening to you or watching for it in someone else.

Thinking Beyond the Ticket

There's nothing wrong with picking up a ticket, building the thing, and moving on. In a lot of organisations that's exactly what's needed, and a lot of developers are happy there.

I was working through designs and noticed a widget that looked identical to something I knew my colleague was building. I flagged it. We created a shared component instead of two separate ones. It saved time, ensured visual consistency, and meant any future changes only needed to happen in one place.

I've also been on the other side of that moment. Watching a developer that I was mentoring catch the same kind of overlap before anyone else did.

It starts with the habit of asking: who else is affected by the decisions we're making right now?

Choosing Standards Over Complexity

It's easy to mistake complexity for competence. The deeper you go into your stack, the more exciting tools you discover. The temptation to use them everywhere is hard to resist. I'm guilty of it. Nested ternary operators, chained function calls, complex logic squeezed into a single line. I thought I was being clever, until my poor colleague had to review my code.

Standards-compliant code isn't a compromise. It's a form of empathy. When you stay close to established conventions, you're making a promise to everyone who comes after you: this will behave the way you expect. You won't need to reverse engineer my thinking. You can just read it, change it, and trust it won't fall apart.

Not Every Problem Has a Technical Solution

Sometimes the most impactful thing you can do is write a document.

We had a problem with branch management. The instinct might be to reach for a technical enforcement mechanism. Commit hooks. Automated checks. Rules baked into the pipeline. Those things enforce behaviour. They don't change it. A developer who understands why a process exists will handle the situation the process didn't anticipate.

We created documentation explaining the what and the why of the new process, ran a training session, and asked for feedback as it bedded in. Before long, it was as though we'd always been doing it.

Documentation that seeks to guide rather than dictate is far more valuable than any technical solution.

Opening Dialogues

I almost never say no to a client.

With a flat no you halt the conversation. You position yourself as an obstacle, that may get overridden anyway. And you miss the point, because what the client needs isn't always what they've asked for. Understanding that gap, and finding a way to meet the underlying need, is where the real value is.

So instead of no, I prefer "yes, but."

"Yes, we can do that, but it will push the release date back. Do you want me to flag that with the project manager?"

"Yes, we can do that, but it uses non-standard functionality which may not be maintainable long term. How about this alternative?"

"Yes, we can include that, but it may have a performance impact. Here's another alternative worth considering."

Each of those responses does the same thing: it keeps the relationship intact, it's honest about the constraints, and it offers a path forward. The client feels heard rather than blocked. And you've protected the work without ever having to say no.

It's a form of technical diplomacy. And it does take practice. Early on, the instinct is either to say yes to everything to avoid conflict, or no to anything that feels out of scope. The middle ground, where you meet the client's real need while being honest about the cost, is where senior judgment lives.

Ideally this conversation belongs to your project manager. But senior developers know how to handle it when it doesn't.

Letting Go

You could build a whole product from start to finish. But should you?

There are a lot of things I can do outside my core specialisation with a reasonable degree of competence, but competence doesn't build great projects. I can write acceptance criteria if needed, but I will never do it as well as the person with the deep knowledge of who and what the product is for. I would take so much longer to build a robust and scalable backend than the developer who has specialised in it for years.

Knowing who is best for the job, and stepping back to let them do it, is one of the least visible and most valuable things a senior developer does.

Leave It Better Than You Found It

Leave it better than you found it. The codebase, the process, the team. Not dramatically better. Not perfect. Just a little better, consistently, over time.

It's an underrated form of seniority. It doesn't show up on a CV particularly well. It doesn't always get noticed in a performance review. But the developers who operate this way are the ones teams are built around.

It doesn't happen overnight. It accumulates, the same way the recognition does. Small decisions, repeated consistently, that have a lasting impact on the code and the people in it.

If you recognise this in yourself, or in someone you're working with - share it. Someone earlier in their journey might need to hear it.

Senior means something different depending on who you ask.

For some it's years of experience. For others it's technical breadth - the ability to spin up a full stack project from scratch, own the architecture, make the infrastructure decisions. For others still it's simply a rung on the promotional ladder, assigned when the structure says it's time.

What follows is one perspective. Mine. It's not a framework, and it's not a checklist. It's an honest account of what the shift actually felt like from the inside, and the signals I almost missed because I was too busy looking for something more dramatic.

The Promotion I Almost Didn't Ask For

I didn't wake up one morning and decide I was ready to be a senior developer.

For a while I was feeling a confidence I wasn't showing on the outside. Not out of false modesty, but because I genuinely wasn't sure it was justified. I kept waiting for the moment it would be tested and found wanting.

Then I started noticing something. In code reviews, in technical discussions, there was a pattern. They weren't correcting me. They were highlighting what I'd written as examples of best practice. Pointing at my instincts as the benchmark.

Eventually the practical case made itself. I was already guiding and mentoring the team, but without any official capacity to do so. My opinions carried weight in practice, but not on paper. The title wasn't about validation. It was about utility. A tool to give my input the implicit authority it needed. And yes, it would look better on my CV.

So I asked. They agreed. Nothing really changed, because I already had.

You Were Already Doing It - You Just Didn't Have the Words

At some point I picked up Head First Design Patterns.

I expected to learn something new. Instead I found myself recognising things I was already doing.

Not all of them. But enough to give me pause. I'd been applying patterns without knowing they had names, solving problems in ways that had already been formalised decades earlier. It was one of the most validating moments of my career.

Some developers read the theory first and then spend time learning to recognise it in their own work. Others build up the habits first and discover the vocabulary later. Neither path is objectively better than the other. But both lead to the same place. A moment where something you've been doing instinctively becomes something you understand deliberately.

You Stopped Trying to Know Everything - And Started Knowing What Mattered

There is an impossible standard stalking most developers. The idea that a good developer should know every language, every framework, every paradigm. That being caught without an answer is a failure. That admitting uncertainty is a weakness.

I carried that for longer than I'd like to admit. And it was exhausting.

The shift came in stages. First, the uncomfortable acknowledgement that the industry is simply too big, and too fast-moving for any one person to keep up with all of it. Then the liberating realisation that followed. I didn't have to. I could pick a lane, go deep, and stop apologising for the edges of my knowledge.

I chose frontend. I built enough context around the rest of the stack to have informed conversations, to understand how my work fitted into the bigger picture, but I stopped pretending to be something I wasn't. A specialism isn't a limitation. It's a decision.

The shift was most noticeable in client calls. Early on, being asked something I didn't know felt like a trap. Over time I developed a phrase that changed how those moments landed: "let me take that away". Not a deflection. A commitment to find the answer and come back with something useful.

And that's when I discovered: the client didn't expect me to know about their specific integration that hadn't been mentioned in the agenda. My manager wasn't silently disappointed when I didn't have an immediate answer. Nobody was holding me to the standard I was holding myself.

The only person expecting me to know everything, was me.

There is a particular kind of hiring process that still hasn't figured this out - the kind that tests for encyclopaedic recall over genuine judgment. Or building solutions that you'll never face in practice. That's a frustration for another post.

The Signs Are Quiet

Seniority doesn't announce itself. There's no single moment where everything clicks and you think - right, that's it, I've done it. It's more subtle than that, because all of the changes happen internally.

They're shifts in how you think, not things you did or certificates you earned. And that makes them easy to miss, especially when you're still measuring yourself against an impossible standard that nobody else set for you.

If you're mid-level right now and none of this sounds familiar yet, that's fine. It's not a checklist to work through. But if you're reading this and nodding at things you recognise in yourself - you might be closer than you think.

The title, when I finally asked for it, turned out to be the least interesting part of the story. It was a practical tool. Something to make official what was already true.

In part two, I'll get into what senior thinking actually looks like in practice - in your code, your communication, and your team. But that's the external stuff. This was the part that happened first.

If any of this resonated, share your moment of recognition in the comments. Someone earlier in their journey might need to hear it. Join the discussion here.