I would check PR reviews at fixed times, usually around 9 AM, 1 PM, and 4 PM. And I tried to protect two two-hour focus blocks every day.

Was that ever fully real? Not really. Something urgent always slipped through. But even a messy version of that setup helped to get things done.

And I believe that was the point behind all the old context switching talk. If you’re in the middle of a hard problem, interruptions take you out of the zone as an engineer.

If I’m tracing a bug through three services, trying to understand why something only breaks in production, or working through a design decision I still don’t trust, a random Slack ping doesn’t just “take a minute.” It breaks the flow entirely. Then I get to spend the next twenty minutes rebuilding the model in my head.

I used to describe it as being in “the zone,” and I always told people how hard it was to get back into the zone. Not to push people away, but to let people realize that each interruption had a price, and I believe this is becoming more prominent now.

What used to work

Back then, most of the interruptions came from outside the work.

• Slack
• meetings
• PR reviews
• incident noise
• somebody with a “quick question”

Part of the job, yes, but at least the source was clear.

This made me think batch processing these should help here. And in a way it did for a while, since it at least gave enough room to process both the interruptions and the work.

What changed

Currently, the old interruptions are still there, but we added a new category on top of them.

Agents.

And I don’t mean that in some dramatic anti-AI way. I use them constantly, and that’s exactly why I am writing this. I’ve been experiencing it first-hand.

If I have a few agents running in parallel, my day starts looking different fast. One is exploring the next task. One is exploring a refactor. One is looking at the latest tech updates (because who can keep up manually nowadays). Then one of them finishes. Another needs clarification. Another wants me to choose between two directions. Another comes back with a wall of questions because my prompt was missing one detail that suddenly matters a lot.

So now the interruptions don’t just come from Slack and meetings. The work itself keeps interrupting me.

That’s the part that feels different.

In the past, context switching mostly came from other people pulling you away from the task. Today, a lot of it comes from managing the task through multiple half-finished threads at the same time.

Why it feels heavier

What makes this harder for me is that it all feels productive.

Slack is obviously an interruption. A meeting is obviously an interruption. But when an agent finishes a task or asks for clarification, it doesn’t feel like an interruption in the same way. It feels like progress, and often it is progress, but sometimes it’s just another thing that wants a piece of your attention NOW.

That is how I end up with days where a lot happened, and I feel tired by the end of it. Not necessarily in a bad way, but in a different way than I am used to.

When you spend the whole day switching between sessions, reviewing outputs, answering follow-up questions, checking Slack, doing PR reviews, deploying services, and moving tickets, you realize how easy it is to forget or miss things. Not because you’re not trying your best, but mainly because of the constant focus you have to keep up.

That’s why this feels heavier to me now. The old interruptions never left. We just layered more on top.

Deep work still matters

If anything, I think it matters more now.

Agents don’t remove the need to think clearly at all. If anything, we need to think more about how we approach problems, handle evaluation, and make sure we protect our focus.

The focus is required to make sure that we understand what we’re trying to deliver, that we keep critically evaluating changes and requests, and that we break down the work effectively.

What I’m trying now

I don’t have a good solution for this yet. If you do, please feel free to share it with me. But a few things seem to help.

Breaking down your work ahead of time helps. A clear plan for the day helps. Fewer active (meaning executors that need instant feedback) agents help. Batching reviews still helps when I can get away with it, although this one is especially tricky with the current rate of change.

Mostly though, I think the big shift is just understanding that the job changed.

We didn’t make context switching disappear. We found a much more productive-looking version of it, and it’s here to stay.

Some will thrive, others will realize it might not be for them. The only thing you can do to deal with this is adapt and overcome.

The reality is that while code generation has accelerated, delivery pipelines haven’t kept pace. When test suites still take thirty minutes to run, CI pipelines are flaky, and deployments feel like defusing bombs, delivery pipelines haven’t sped up.

Consider this: Systems have been built that work when engineers are putting out 1-2 changes a day, but they break down at 5-10 changes a day. CI still takes 30 minutes per branch, everything needs merging so PRs pile up, and there is typically one deploy to staging every half hour.

This mismatch is often overlooked. Much of the process that’s been layered onto software development comes with speed trade-offs - sometimes intentional, often just organic evolution.

Now that generating code is cheap, one would expect software roadmaps to fly through delivery. But in most cases, that’s not what happens.

We expected the bottleneck to shift to trust decisions: Is this actually the right change? Does it work correctly? Can we ship it without starting a fire drill?

Yet that hasn’t been the outcome. Let’s examine why.

The Bottleneck Phase of AI Adoption

The first hard limit in review is review.

Code can be generated faster than it can be read. That’s where things get tricky.

Small change requests turn into 27-file diffs because AI tools touch nearby helpers, “simplify” abstractions that didn’t need changing, update unnecessary tests, and reformat code on the way out. None of it is obviously broken. Some of it might even be fine. But it still leaves reviewers staring at diffs they don’t have the time to read line by line.

Often, reviewers already have their own work open in three other tabs.

Reviews often become superficial. People start to just skim through changes, and they trust a green pipeline. They approve the shape of the change because tracing every consequence takes time they don’t have. This is not out of bad intention, but rather because it’s the only way to catch up.

These review cycles and safety checks exist for a reason—they protect the production environment. The goal isn’t to scrap them, but to evolve them to match the new generation speed.

That’s one of the real costs here. The goal should not only be ship faster, the goal should be ship faster without lowering quality.

The Three Stages of AI Adoption Maturity

A predictable maturation curve emerges as AI integrates into software delivery:

Stage 1: The Code Generation Boom Teams discover they can generate code faster than ever before for planning, implementation, and even initial review.

Stage 2: The Bottleneck Phase AI gets bolted onto systems that were already slower and messier than desired. Thirty-minute test suites that were tolerable before now become absolutely ridiculous in an AI loop. Changes stack up in a queue, with engineers waiting for things to move through the queue. Flaky CI now becomes even worse, as it not only impacts one change, but ten. Risky deploys create cautious behavior just when tooling is pushing to move faster.

Stage 3: The Automated Trust Phase The real wins come from investing in unsexy but critical infrastructure: fast feedback loops that don’t make you want to scream, clear boundaries so teams aren’t stepping on each other’s toes, boringly reliable deploys, documentation that doesn’t require an archaeology degree to understand, and having enough review capacity to actually keep up with the increased volume.

A flashy AI setup could help move the needle, but lasting improvement comes from evolving systems to match the new pace.

Decision Latency: The Next Bottleneck in the Maturity Curve

Another bottleneck that emerges is decision latency around process and approvals.

Changes get drafted quickly but sit for days due to additional review requests, sign-offs, unclear test plans, and unclear ownership.

This is what we mean by decision latency. The code can be done in an afternoon. The waiting takes the rest of the week.

When it’s unclear who has the final say, when every change needs three sign-offs, or when acceptance criteria only get clear near the end, AI mostly helps teams finish the code and then wait.

This highlights that this isn’t just an engineering structure problem, but more like a process problem that needs evolution alongside AI adoption.

AI rewards decomposition

This is why breaking work down clearly matters.

A sloppy task used to waste one person’s time. Now it can waste one person’s time at much higher speed while producing a lot of plausible-looking output someone has to untangle later.

When AI helps most, the task looks like this:

• break a problem into smaller steps that can actually be verified
• draft an implementation plan before touching the code
• execute a scoped change with clear constraints
• review a diff for missing edge cases or weak tests

When it helps least, the request sounds like “clean this up” or “improve the architecture” or “just take a pass at this module.”

Those aren’t real tasks. They’re a good way to get a diff nobody asked for.

Ownership matters more, not less

When code becomes cheaper to produce, the people who actually matter aren’t the ones who can type the fastest. They’re the ones who can properly scope a change, verify it thoroughly, and stand behind the decision to ship it.

This isn’t nearly as exciting as bragging about 10x productivity gains, but it’s closer to what engineering teams actually need to succeed, without reducing quality.

It doesn’t matter whether the first draft flowed from an AI model, a Stack Overflow snippet, or late-night coding. What matters is who really understood the trade-offs involved, who bothered to check the edge cases, and who’s willing to put their name on it when it hits production.

That’s why ownership becomes more critical, not less, when AI handles the initial draft. The machine can spit out options all day long, but it can’t be paged (yet) when something breaks in the middle of the night. It can’t explain why it made a particular trade-off during Friday’s incident review. It can’t look a stakeholder in the eye and say, “I’ve got this.”

What actually helps

Look, the answer isn’t to artificially slow things down for the sake of purity. The answer is fixing the system around the code.

Here’s what that looks like in practice:

First, break work down properly. Smaller tasks aren’t just easier to manage - they’re easier to generate with AI, easier to verify, easier to review, and way easier to toss out when the model starts hallucinating or going off the rails.

Second, make those feedback loops cheaper. When pumping out more code changes, tests need to be fast, CI needs to be reliable, and deploys need to be boringly predictable. If any of those are slow or flaky, they become instant bottlenecks that negate any speed gains from AI.

Third, get crystal clear on decisions. If every meaningful change requires a meeting and three layers of approval, you’re still optimized for a world where code was hard to write. AI just highlights how broken that process is to begin with.

Fourth, treat review like the bottleneck it often is, because it frequently is. If review capacity can’t keep up with the increased volume from AI assistance, you’re just creating a bigger backlog of unreviewed changes. That’s not progress, that’s just creating future problems for yourself. Make thorough reviewing a priority.

Fifth, make ownership obvious. Someone on the team should be able to look at a change and say without hesitation: “I understand this, I’ve verified it, and I’m responsible for it shipping successfully.”

And finally, when the AI tool isn’t actually helping? Stop prompting it. Seriously. Close the chat window, go back to the original problem statement, and rewrite it in simpler terms. Sometimes the best way to use AI is to not use it at all until you’ve clarified what you actually want, because if you don’t know what you want, how do you expect Claude to know what you want?

The upside of AI in software development is absolutely real. It’s a double-edged sword that can be extremely beneficial when the correct approach is taken, but it can produce significant amounts of low-quality output when the wrong approach is used.

What I took from that was simple: stop rebuilding your workflow around the current winner. I care more about having a setup that survives outages, pricing changes, and vendor churn than I do about squeezing out the absolute best capability this week.

So this post is not really about moving from Cursor to Claude Code to OpenCode. That is just the timeline. The whole point is that flexibility matters more than peak capability.

The tipping point

I started using Cursor seriously around March or April 2025.

At first it helped with the obvious stuff. Moving between files faster. Cleaning up code. Refactoring without losing momentum. It made me quicker, but it did not change how I thought about development yet.

That changed a few months later when the first Opus model got good enough for real development work. I think it was 4 or 4.1. AI tooling stopped feeling like autocomplete on steroids and started feeling like something that could move real work forward.

I still dislike the 10x talk around this stuff. For me it was more like 1.1x or 1.2x on a good day. Still meaningful, because no one dislikes writing boilerplate more than me.

After that, AI was no longer the question. The question was how I could rebuild my workflow around it.

Back in the terminal

Later that year, Claude Code got good enough that I could bring that leverage back into the terminal.

That mattered because the terminal is where I actually want to work. I have spent years turning it into the fastest place for me to think. Hundreds of commands. A lot of Neovim muscle memory. Outside pair programming, because I do not want to force Neovim on other people, and the occasional Git diff in VS Code, that is home base.

Claude Code was the first time I got that kind of leverage without having to leave the terminal. I was not trading leverage for comfort anymore.

So the question changed. If the environment finally felt right, what was actually worth optimizing around it?

The workflow became part of the job

From there I started spending a couple of hours a week improving the workflow itself.

Not using it. Improving it.

I tested tools, changed prompts, added skills, cleaned up context, and got more deliberate about where expensive models were actually worth paying for.

That work mattered more than any single model release. The real gain came from building a setup that kept working even while the tools kept moving.

That is when OpenCode started making a lot of sense to me.

Why OpenCode mattered

I do not use OpenCode because it beats every native tool at everything. It does not. Native tools often have an edge.

I use it because it lets me keep my workflow and swap the model layer underneath it more easily. That matters a lot to me.

I do not want to explain to a client that my setup fell apart because one provider had a rough day. I do not want to rebuild my habits every time pricing changes or the leaderboard shuffles.

If your workflow only works when one company is cheap, online, and still winning, that is not much of a workflow. It is a single point of failure.

I use these tools for hours every day. Reliability matters more to me than squeezing out the last bit of capability.

Not every task needs the best model

It also changed how I pick models for different jobs.

Some work really does need the strongest model. Architecture trade-offs. Messy refactors. Unfamiliar systems. Pay for intelligence there.

But a lot of tasks are much smaller than that. Rename this. Move that. Update the tests. Clean up some typing. I am not paying top-tier model prices for chores if I do not have to.

That is partly about cost, sure. It is also about not getting lazy. If the strongest model is always one keystroke away, it gets very easy to stop thinking earlier than you should.

The setup grew out of that.

The setup itself

The setup is honestly boring.

I keep the defaults in my dotfiles: shared AGENTS.md, workflow instructions, and skills that I symlink into the tools I use.

Claude looks for skills in .claude/skills. OpenCode looks in .opencode/skills. I do not want copies of the same setup scattered across repos, so I keep one version and link it where needed. That way both tools behave the same on both my Macs.

Then I add a repo-level AGENTS.md with only the local context that matters for that project. That gives the agent enough to work with without me repeating myself or waiting for a full repo scan.

The actual work happens in Git worktrees. Usually one task per branch, one agent session per worktree.

I am not trying to build the cleverest system here. I want something I can inspect, debug, and change without drama.

That is another reason the terminal still wins for me. My prompt tells me where I am. tmux makes it easy to hop between sessions. Worktrees map cleanly to tasks. Nothing is hidden behind a glossy interface that stops being cute the moment something breaks.

Final thought

I am not telling anyone to move to the terminal. Use whatever environment helps you think clearly.

But if AI is going to sit in the middle of your daily workflow, build for resilience first and keep enough flexibility to pick the right model for the job. Capability still matters. I just do not want everything else depending on it.

A workflow is only really yours when it survives the tool you built it around.

My own experience has mostly been positive. I worked with managers who took these conversations seriously. The good one-on-ones were never a ritual to survive. They helped me think clearly, get unstuck, and leave with a better plan.

When I asked people about their experience, I heard the same split, and you can see it in the replies here:

Working on a new post about 1 on 1 meetings, and how they can be extremely valuable for one, but worthless for the other.

I'm lucky that I've had great mentors and managers, so in my experience they have been extremely valuable, but I hear different experiences.

What is your...

— Joachim Zeelmaekers (@joachimz_me) February 27, 2026

Some one-on-ones genuinely shaped careers. People felt seen, challenged, and supported. They still reach out to former leaders because those conversations mattered.

Others felt like calendar fillers. Status updates disguised as coaching. A manager trying to track activity instead of improving conditions.

The difference was intent.

The best one-on-ones happened when the manager showed up curious. Curious about what was blocking me, what was slowing me down, and what I needed to grow. The worst ones happened when there was no preparation.

That is why one-on-ones are powerful, even though not all of them are perfect, they give YOU the perfect opportunity to grow.

The question is, will you take that opportunity?

Preparation

The one-on-ones that failed for me were predictable:

• no clear goal or agenda
• no evidence of progress
• no concrete ask

In short, no preparation.

When that happens, the conversation defaults to updates, logistics, and whatever fire happened that week.

None of that is bad. Some one-on-ones should be casual like this. But I am talking about the ones that are meant to help you grow.

The meeting is not where growth happens

I used to think one-on-ones were where growth happened.

Now I think they are where growth is evaluated.

The real work happens before and after the meeting:

• pick a skill to improve
• practice it in real work
• ask for targeted feedback
• adjust based on what you learned

Your manager can support this process. But they cannot run it for you.

What to bring to every one-on-one

Once a one-on-one is properly structured, they get much better. So make sure to structure them. You don’t like the format? Change it.

Here are the four things that worked for me.

1. A short wins list

Not for ego. For evidence.

What did you deliver? What improved? What impact did it have?

You can shortly discuss it with your manager, and at the same time you can use it for future evaluations. Win-Win!

2. One blocker

Not a list of complaints. One blocker that matters.

Maybe your pull requests take too long to merge. Maybe stakeholder alignment is messy. Maybe you freeze in architecture discussions.

Pick one. Make it specific. That way it can be talked about, reviewed and actioned.

A good manager does not need this meeting to track your tasks. There are better systems for that. The meeting is more useful when it focuses on what is preventing good work.

3. One skill gap you are working on (optional sometimes)

This is the part most people skip.

Say it directly: I need to improve at X. Here is how it shows up and this is what I’ll be doing about it.

Examples:

• turning ambiguous tasks into executable plans
• giving clear technical updates to non-technical stakeholders
• writing smaller, easier-to-review pull requests

This will be a way to keep yourself accountable on the next session. Did you really improve, or were these just meaningless words?

4. One concrete ask

This one depends on the frequency of your one-on-ones. If you have a weekly one, asking for something every week can feel very needy.

But a general rule of thumb should be if your one-on-one ends without an ask, do not expect much to change.

Your manager is busy. They cannot read your mind, so if you don’t ask for anything, expect nothing.

Ask for something actionable:

• Can I lead the next retrospective?
• Can we define what senior-level ownership looks like for my scope?
• Can you review my design doc and challenge my assumptions?

The least you can get is a no. So ask what you want to ask, and make it clear.

Development plans that actually survive

Most development plans start strong and then disappear. It’s easy to create a plan, but it’s hard to execute it.

Not because people are lazy. The opposite actually.

I struggled with this a lot. I always prioritized my work over my personal development time. Not because I didn’t want to do it, but more because I felt I had to work harder, do more. But ultimately, it makes you do less in the long run.

What worked better for me was treating growth like a real project, because real projects are exciting and make me want to work on it. You also have something to show for, which gives that same dopamine as finishing tickets, or implementing new features.

So where can I start, you might ask? Build a six-month plan, then break it into trackable pieces.

Six months is long enough to change behavior and short enough to stay grounded.

A simple structure:

• Pick one growth theme for six months.
• Define what “better” looks like in observable terms.
• Break it into monthly focus areas.
• Create one monthly opportunity to practice.
• Review monthly and adjust.

“Become a better leader” is not a plan.

“Over the next six months, lead one cross-team technical discussion per month, write a short recap, and ask two stakeholders for written feedback each time” is a plan.

The uncomfortable part

It is easy to say my manager is not helping me grow.

Sometimes that is true. Some managers are not the best coaches. Some environments are genuinely limiting. Some organizations split people management and technical leadership, which is makes you focus on one or the other, instead of working on both.

But in many cases, the harder truth is this: we expect growth to happen around us, not through us.

We wait for better projects, better timing, better guidance, better recognition.

Meanwhile, weeks pass, then months.

One-on-ones do not create progress by themselves. They reveal whether progress is happening. If every meeting feels the same and something is not moving. That is the moment to reset expectations and change the inputs.

Final thought

One-on-ones matter. Development plans matter.

But they are not magic.

If you’re not coming up with anything, and your manager is not delivering what you’re expecting, you will stay where you are indefinitely.

It’s up to you to make things happen.

Page load dropped from about one second to under 300 ms, the stack cost went to zero, and I finally owned every part of the experience.

This is why I left Ghost and rebuilt the blog from the ground up.

Why I Left Ghost

Ghost is a great product. If you want a managed blogging platform with a clean editor and built-in newsletter support, it does the job well.

My reasons for leaving were not about quality. They were about control and fit.

Since my goal this year is to start publishing weekly, I wanted my blog to feel completely mine: faster, simpler, and shaped exactly to my preferences. Ghost did not allow the level of customization I wanted without workarounds.

The bigger issue was scope. Ghost Pro is not cheap, and self-hosting Ghost means running a server, a database, and ongoing upgrades. For a personal blog with one post a week, that stack felt like overkill.

I expected the newsletter to be the hardest part to replace. It turned out not to be.

Choosing the Stack

I did not spend weeks evaluating frameworks, like I would in the past. The decision was pretty simple.

Lately I heard a lot about Astro and I wanted to try it out. It ships hardly any Javascript by default, supports Markdown and MDX natively, and gives you full control over the output. No hydration overhead, no client-side routing unless you explicitly opt in. Just HTML and CSS.

Cloudflare Pages for hosting. Free tier, global CDN, automatic deployments using GitHub Actions. The site builds in seconds and deploys to edge locations worldwide. No servers to manage, no bills to worry about.

Markdown files instead of a database. Like we all know, lately everything has been about Markdown files, so why not put every post in a Markdown file in a Git repository. I can make changes to it in any editor, preview locally, and publish by pushing to main. Version history comes for free.

For my newsletter, with the full 12 subscribers, I first thought to not include it anymore. But then I found Kit, 10 000 subscribers for free. Perfect for my use case.

The entire stack costs me nothing beyond the domain name, and my time of course.

Performance Results

The page load numbers are the clearest win.

In real usage the Ghost site felt reasonably fast, around one second to visible content. However, Lighthouse mobile simulation revealed much heavier rendering costs, especially LCP. The Astro rebuild reduces both perceived and measured performance costs.

The architecture shift from dynamic rendering to static edge delivery shows up clearly in performance metrics.

Lighthouse snapshot (single run, mobile emulation, default throttling).

Here is a Lighthouse snapshot (single run, mobile emulation) comparing the old Ghost site with the new Astro build:

The largest improvements come from removing heavy images and client-side scripts. Total page weight dropped by over 18x, which directly improved Speed Index and LCP.

Design + UX Updates

The better question would be, what did not change. Well, the content.

The homepage moved from a stock template to a focused, branded entry point with clear hierarchy and fewer distractions.

Beyond speed, the design is entirely mine. The goal was a calmer, more intentional experience with room to grow. I can now iterate quickly and add new features without fighting the platform.

The new list view trades heavy thumbnails and whitespace for tighter hierarchy and faster scanning. Smaller images, consistent metadata, and clearer contrast mean you can find a post at a glance without hunting for it.

The reading view moves from a template-heavy page to a focused editorial layout. Better line length, calmer typography, and fewer competing elements keep attention on the text and reduce cognitive load.

The CTA experience is now integrated into the reading flow instead of floating over it. Recommendations feel like a natural next step, not an interruption, which keeps the page focused while still nudging the next click.

The newsletter now feels like part of the site, not a third-party embed. The form is lighter, the spacing is calmer, and the CTA matches the rest of the system, so it reads as an invitation rather than a modal ad.

The benefit of building this site myself is being able to introduce more features to improve the experience:

• Search across every post (full text, fast).
• An About page that actually explains what I write about.
• Dark/light mode that preserves the brand tone.
• One-click code copy for snippets.
• Dedicated tag pages so topics are easy to follow.
• Posts grouped by year for quick scanning.

The Takeaway

If you are a developer blogging on a managed platform, ask yourself what you are getting in return for that convenience. If the answer is "less control and a monthly bill," it might be time to build your own.

It does not need to be complicated. A static site generator, a CDN, and Markdown files will take you further than most platforms. And the process of building it will teach you more than any blog post about blogging ever could.

Including this one.

I have kept features like that alive for years. Not because they added value, but because removing them felt like more work than leaving them in place. They worked. They were not hurting anyone. Why bother?

That reasoning felt pragmatic at the time. I have since learned it is the most expensive form of laziness in software.

The lie we tell ourselves

“It works, so it is free to keep.”

This is what we say when we do not want to think about it. And for a while, it’s true. The features sit there, untouched, collecting dust. Nobody complains. Nobody celebrates. They just exist.

But software does not work like this. Dependencies shift. Frameworks update. Security patches ripple through layers you forgot were connected. Those quiet features are not free. They are accumulating debt.

I learned this the hard way many times. A release went out, and three weeks later a bug report came in from a single user clicking a button I had forgotten existed. Someone had to context-switch, investigate, trace the regression, fix it, and report back. Half a day of engineering time for a feature that served one person who probably would not have noticed if the button had simply disappeared.

That was one feature, one bug report. Now multiply it across every neglected corner of a product.

The weight you stop noticing

One unused feature is manageable. You barely think about it. But products do not collect one. They collect dozens, quietly, over years. A toggle nobody clicks. A report nobody reads. An export format nobody requests. Each one seemed harmless when it shipped. Each one still seems harmless on its own.

But collectively, they change the shape of every conversation. A design review takes longer because the interface has no space left. A dependency upgrade touches code paths nobody remembers writing. A new engineer spends their first week building a mental model of a system where a third of it serves no one.

In some occasions, removing unused features is not even on the table. Not because anyone defends them, but because nobody can confidently say which ones are unused. The tracking might not be there. Or maybe the institutional knowledge had left with the people who built them.

That is how it compounds. Not through any single decision, but through the absence of decisions. The features you never question become the ones that define your constraints.

Why we still keep them

I think the real reason we keep unused features is not pragmatism. It is discomfort.

Removing a feature feels like admitting failure. Someone built it. Someone approved it. Maybe it was your idea. Deleting it means acknowledging that the effort was, in some sense, wasted.

I have felt that discomfort. I have argued to keep things I built, not because they mattered to users, but because they mattered to me. That is not product thinking. That is ego dressed up as engineering judgment.

There is also the fear of the edge case you cannot see. What if that one user depends on it? What if removing it breaks something downstream? These fears are real, but they are also answerable. Usage data exists. Conversations can be had. The fear of finding out is not a reason to avoid looking. And certainly not, when you can just bring the feature back if complaints come in.

When keeping is the right call

I do not think the answer is to remove everything with low usage. Some features serve a small audience that depends on them deeply. Some could exist because of contractual obligations or regulatory requirements. Some are niche but genuinely valuable for power users.

There is a difference between keeping a feature because you evaluated it and decided it still earns its place, and keeping it because nobody bothered to ask the question.

The discipline of subtraction

Every feature has a rent. Some pay for themselves through usage, through value, through the problems they solve. Others just accumulate cost quietly, making everything around them a little harder, a little slower, a little more constrained.

Adding features is easy to celebrate. Shipping feels good. But the products I admire most are not the ones with the most features. They are the ones where every feature earns its place. Where someone had the discipline to ask: does this still serve the people using this product?

The discipline is not in building more. It is in being honest about what deserves to stay.

I hear a lot of complaints about it. It’s harsh, it demotivates people, it slows down shipping. And in some case, that’s true. When code reviews are used to gatekeep or show superiority rather than improve the work, they’re genuinely harmful. That’s not okay, and I’m not going to defend that.

But I think something gets lost in those complaints. Something worth examining.

The woodworker’s table

Imagine you’re a hobbyist woodworker. You’ve spent weeks building a table. In your mind, it’s perfect. Exactly how you envisioned it. But before you let your family sit around it at dinner, you invite a professional woodworker to take a look. Someone with ten-plus years of experience creating tables. You ask for their honest opinion.

They walk around the table, run their hand across the surface, check the joints. Then they give you their feedback.

The leg structure isn’t positioned to distribute weight evenly. The wood hasn’t been treated properly, so the color will fade within a year. The technique works for a shelf but not for something that needs to bear this kind of load.

Your first reaction? Frustration. Maybe even anger. This is my first table. I’m not a professional. Why are they being so harsh?

Then you take a breath. You realize you asked for their honest feedback. And you know that if you use the table as is, it might collapse one evening with your kids sitting around it.

The story is fictional, but I think it maps pretty well to what happens in a code review (give or take). Someone with more context (not always more experience, but more context about that specific area) looks at your work and tells you what they see. Not to be cruel. Only to protect the thing you’re building from the things you couldn’t see yet.

The code review protects us from ourselves

The code review is there to catch what we miss when we’re too close to the problem. Our excitement about a clever solution. Our limited knowledge of a system we’ve only touched for a few days. Our frustration with a task that’s taken longer than expected, pushing us to just get it over with.

I’ve been on both sides of this. I’ve submitted code I knew wasn’t ready because I was tired of looking at it. And I’ve reviewed code where the problems were obvious to me because I’d made the exact same mistakes six months earlier.

That’s the thing people forget. The reviewer isn’t judging you from some position of superiority. They’ve been where you are. Most of the feedback they give comes from their own past mistakes and experience.

Taking it personal

The first challenge I’ve noticed is that engineers take review feedback personal.

This is a completely natural response, especially when you’re not used to receiving direct feedback on your work. But it limits your thinking. When you’re focused on defending what you wrote, you stop being able to see what you could improve.

I remember at least a dozen of reviews early in my career where senior engineers left a comment saying my approach was “unnecessarily complex” or way too brittle. At first, I’d try to often prove them wrong. But after a while I realized I was compensating for my ego, instead of trying to create the best solution for the problem. This type of compensating often cost me hours, hours that I could’ve put towards other work. Nowadays, a code review for me is a learning opportunity, where I want people to find the things I missed, so that we as a team can deliver the highest possibly quality.

Respecting the reviewer’s time

The second challenge is one that doesn’t get talked about enough: respecting the reviewer’s time.

This is partially driven by delivery pressure. There’s always a deadline, always a stakeholder asking when it’ll be done. But that pressure doesn’t change the reality that someone is about to spend their time reading your code, understanding your decisions, and giving you thoughtful feedback. That’s a gift, not an obligation. And it comes with a cost.

I’ve seen too many pull requests where the author clearly didn’t review their own code before requesting a review. Leftover debug statements. Commented-out blocks. TODO comments that should have been addressed. An entirely broken CI. Things you’d catch in thirty seconds if you just read through it one more time.

My approach is simple. Once I think I’m done, I step away. I go get a coffee or work on something else for a bit. Then I come back and review my own pull request as if someone else wrote it. I leave comments explaining trade-offs I made. I catch the obvious stuff before anyone else has to. This does two things. It shows the reviewer that I value their time as much as my own. And it often catches problems I would have been embarrassed to have someone else find.

A learning opportunity, not a chore

The third challenge is maybe the most important one: code reviews have become a chore instead of a learning opportunity.

A review comment you don’t understand isn’t an interruption. It’s the start of a conversation. An approach you’ve never seen before isn’t confusing, it’s a chance to learn something new or understand something better.

I’ve learned more from asking “why did you suggest this?” in a code review than from most technical articles I’ve read. Those conversations, where someone walks you through their reasoning, where you push back and they explain further, where you both arrive at something better than either of you started with. That’s where real growth happens.

And it goes both ways. Some of the best technical discussions I’ve ever had started with a junior engineer asking me “why?” on a review comment I left. Forcing me to articulate my reasoning made me realize that sometimes I didn’t have a good reason. I was just pattern-matching against habits I’d never questioned. I also might have not explained it properly, because if I make a comment, it should be obvious to the reader be that comment. Otherwise it’s just noise.

Shipping still matters

I want to be clear about something. I understand that shipping matters. Deadlines are real. Business pressure is real. I’m not arguing that every pull request needs a three-day philosophical discussion.

But catching issues early in the process is significantly less painful than a 2 AM incident with four people on a call trying to figure out what went wrong. The code review is one of the cheapest places to find problems. Cheaper than staging. Cheaper than production. Infinitely cheaper than a postmortem.

The thirty minutes a reviewer spends on your pull request might save your team ten hours later. That’s not slowing down. That’s investing.

I’ve been doing code reviews for years now, on both sides of the table. I still learn something most of the time. Not always something technical. Sometimes it’s about communication, about how to give feedback that helps instead of hurts, about how to receive feedback without letting my ego get in the way.

The code review isn’t perfect. But when it’s done with mutual respect, genuine curiosity, and a shared goal of making the work better, it’s one of the most valuable things we do as engineers.

I’ve also been on teams that delivered value fast and consistently.

The difference wasn’t talent. It was something harder to define, and harder to build. I spent years assuming I’d figure it out eventually, that experience would make it obvious.

It took longer than I expected. But I believe I can finally name it.

The best teams I’ve worked with share four traits.

Not methodologies. Not tools. Traits. Ways of being together that make everything else work.

1. They commit fully to decisions they disagree with

You’ve heard “disagree and commit” before. I believe most teams get it wrong.

They think it means: voice your objection, get outvoted, then quietly comply.

That’s not commitment. That’s resignation.

Real commitment looks different. It means putting your all your energy into an approach you wouldn’t have chosen. It means actively trying to make it succeed, not waiting for it to fail so you can say “I told you so.”

I’ll be honest: I’ve failed at this more times than I’d like to admit. Early in my career, I’d disagree with a decision, get overruled, and then just follow blindly. I wasn’t sabotaging anything (at least not consciously), but I wasn’t helping either. That’s a terrible way to work. And it’s a terrible way to be on a team.

I watched an engineer do the opposite. Arguing passionately against an architectural change for weeks. Good arguments, valid concerns. The team decided to proceed anyway.

What did he do? He became the biggest champion. He found edge cases the rest of us missed. Started looking at improvements to actively make the idea better, and started supporting it even more. From that point I understood disagree and commit.

2. They separate ideas from identity

Here’s a pattern I see constantly: someone proposes an approach, another person critiques it, and suddenly we’re not talking about the approach anymore. We’re talking about who’s right or wrong, not what is right or wrong.

High-performing teams have figured out how to argue about ideas without making it personal. They can say “I think this approach has problems” without anyone hearing “I think you’re incompetent.”

This goes both ways. You need people who can give direct feedback without being cruel. And you need people who can receive direct feedback without feeling attacked.

Neither skill is natural. Both can be learned. I’m still constantly learning them, if I’m being honest.

The teams that figure this out move fast. The teams that don’t spend half their energy managing emotions instead of solving problems.

3. They’re pragmatic without being careless

There’s a certain kind of engineer who treats every decision like a thesis. Every choice needs to be the theoretically optimal solution, fully considered, perfectly designed and 17 confluence pages along side of it.

There’s another kind who just wants to ship something, anything, and deal with the consequences later.

The best teams live in between these two. They care about doing things well, but they also understand that a good solution today beats a perfect solution next quarter. They also realize that everything has it’s price. And that they might be building something that is not needed in 6 months.

But (and this matters) pragmatic teams like this don’t use “move fast” as an excuse for sloppy thinking. They make quick decisions, but informed ones. They cut scope, not corners.

Finding that balance is hard. But the teams that find it tend to build things that actually get used, while keeping stakeholders and, most importantly, users happy.

4. They have informed captains

Every decision needs an owner. Not a committee. Not “the team.” One person.

Netflix popularized the term informed captains, but the name doesn’t matter. What matters is this: someone has the context, the authority, and the accountability to make the call.

The key word is “informed”. A captain who doesn’t understand the problem is just a bottleneck. A captain who understands deeply can move fast because they don’t need to ask for details or approval before every decision.

To be clear, informed captains aren’t dictators. They gather input. They listen to concerns. They genuinely consider alternatives (and I mean genuinely, not the kind where the decision was already made before the discussion started). But when it’s time to decide, they decide. And the team commits.

This only works if you’ve already built the first three traits. Commitment requires trust. Trust requires the ability to disagree without damage. And the captain needs pragmatic judgment to know when good enough is good enough.

The uncomfortable truth

None of this is a process you can implement. You can’t mandate commitment. You can’t enforce the separation of ideas from identity. These are cultural traits, and culture is built one interaction at a time.

I used to think the answer was hiring - find the right people and everything clicks. But I’ve seen great individuals form dysfunctional teams, and average individuals form extraordinary ones. It’s not about who’s in the room. It’s about what happens between them.

That’s the thing about these four traits. You don’t notice them when they’re present. Everything just works and you assume it’s because the people are talented or the project is well-scoped. You only notice their absence - in the meetings that drag, the decisions that unravel, the slow bleeding of momentum that no retro seems to fix.

I’m still learning how to build these types of teams. I suspect I always will be.

Looking back, that makes sense. Clean code is an attractive idea. It promises clarity, maintainability, and a sense of control over growing complexity. Back then, I approached the topic mostly from the perspective of an individual contributor trying to write better software.

Five years later, I still agree with the intent of that post. What has changed is my understanding of when and how those ideas should be applied.

This is not a rewrite of the original article. It is a reflection on what still holds up, what feels incomplete today, and what experience added that rules alone could not.

If you want to read the original version first, you can find it here 👇

Clean Up Your Code by Applying These 7 Rules - In this post, I will go over some of the rules that you can apply to improve your code. Every developer on the team, regardless of their skill level, has to be able to understand the code by reading it. This helps young developers to be more confident in writing code.

What still holds up

Several ideas from the original post aged well in my day-to-day, mostly because they are rooted in communication rather than technique.

Readable code is still one of the best investments you can make. Clear naming, simple control flow, and small, focused units of logic make it easier for others to understand what a piece of code is trying to do. That has not changed, or at least not yet.

The idea behind the Boy Scout Rule also still resonates. Leaving code slightly better than you found it is a healthy mindset. Small improvements compound over time, and a codebase benefits from care and attention rather than neglect.

These principles work because they are not tied to tools or trends. They are about helping the next person, which often turns out to be your future self. Or create a path for some LLM to write readable code based on yours.

Where my view has changed

What feels incomplete today is the assumption that cleanup is always the obvious next step.

Earlier in my career, I treated cleanup mostly as a local activity. I saw something I did not like, applied a rule, and moved on. Over time, I learned that cleanup is rarely just about code. It is about context, ownership, timing, and intent.

Refactoring without understanding why code exists can be risky. A piece of logic that looks redundant or overly defensive might be protecting against a constraint you are not yet aware of. Removing it can introduce subtle bugs or undo decisions that were made deliberately. It can also be a costly exercise, when you come to the realization that after refactoring in, you ended up with the same solution because of these unknown constraints.

I also underestimated how often technical decisions are driven by product needs, deadlines, or organizational constraints. In those cases, “clean” was not the primary goal. Shipping something that worked was.

The rules were never wrong, but they were incomplete without context.

What experience added

Working on larger and older systems changed how I look at cleanup. Inheriting code I did not write forced me to slow down. It became clear that understanding usually creates more value than immediately improving aesthetics.

I also started to see cleanup as a shared responsibility rather than an individual one. In a team, even well-intended refactoring can have side effects. Changes that feel small locally can ripple outward and affect others in unexpected ways.

That is where context becomes crucial. Knowing why something exists matters more than knowing how to improve it.

Principles over rules

If I had to summarize how my thinking evolved, it would be this: clean code is not a checklist, it is a byproduct of understanding.

Rules are helpful starting points, but judgment is what makes them useful. Sometimes the right choice is to refactor. Sometimes it is to document intent. Sometimes it is to leave things as they are and revisit them later.

The goal is not perfection. The goal is stewardship, and delivering value to the customers.

Closing thoughts

I still believe in writing clean code. I also believe that respecting what came before is part of that responsibility. Code is a record of decisions made under pressure, with the information that was available at the point of writing it and often under constraints we no longer see.

Revisiting my old post reminded me that learning is not always about new ideas. Sometimes reframing old ones can be even more valuable.

In general, I can say that these rules have helped me write better code over the past 5 years, however, experience taught me when to apply these rules.

These systems were throwaway by design. Longevity was not a requirement, so architecture was not a concern.

Later, I moved into product development. We were building for real users, real usage, and real growth. Architecture suddenly mattered a lot more. But the underlying forces stayed the same.

Deadlines still controlled the decisions. Budgets still mattered. The main difference was that scale entered the picture. Not as an ambition, but as a concrete question: what does this system actually need to handle?

Scale Is a Constraint, Not a Goal

This is where architectural discussions often go wrong. Scale turns into a goal instead of a constraint. Future growth becomes a justification for present-day complexity.

As a part-time freelancer, I have worked with early-stage founders at the very beginning of their journey. Small teams, limited budgets, and often no users at all. Yet it is common to see architectures designed for a future that does not yet exist. Kubernetes clusters, microservices, event-driven pipelines. Not because the product requires them today, but because it might need them someday.

Most of the time, it does not. Certainly not early on, and if you do, it’s a good problem to have!

What Most Products Actually Need

What these products usually need is something that works. A monolith and a Postgres database can go very far. Vertical scaling is often sufficient for years. Adding complexity early rarely buys safety. It mostly buys cost.

Cost in infrastructure.

Cost in development speed.

Cost in cognitive load.

What We Really Mean by Requirements

When we talk about requirements or constraints, we are not just talking about features. Architectural decisions are shaped by multiple types of constraints:

• Business requirements like deadlines, budget, and time to market.
• Non-functional requirements like latency, throughput, availability, and consistency.
• Organizational constraints like team size, experience, and operational maturity.
• Product reality like current usage, realistic growth, real customers, and actual revenue.

If you cannot point to a concrete constraint in one of these categories, you are not solving a problem. You are guessing.

Premature Complexity in Practice

Consider a small product team of four engineers building a B2B SaaS product. At this stage, the product has fewer than fifty active users and only a handful of paying customers. Despite this, the team invests early in a microservices architecture.

The system consists of eight services, a message broker, distributed tracing, and a managed Kubernetes cluster. Every feature requires changes across multiple services. Local development is slow and brittle. Deployments are frequent but risky, rolling back is even worse. A significant portion of engineering time goes into keeping the system running rather than improving the product.

Infrastructure costs alone exceed a few thousand dollar per month. More importantly, development speed suffers. Simple product changes take weeks.

Eventually, the system is consolidated into a simpler architecture. Fewer services, fewer moving parts, and fewer failure modes. Deployment becomes boring and simple. Development speeds up. Nothing about the product’s requirements has changed. Only the architecture has.

Microservices are not the wrong choice in principle. But they can be the wrong choice for that moment.

Pragmatism as an Architectural Strategy

This is why pragmatism is an architectural choice.

Pragmatic architecture optimizes for:

• speed of change,
• low cognitive load,
• controlled costs,
• and the ability to learn from real usage.

It deprioritizes:

• theoretical scalability,
• architectural purity,
• and solutions to problems that have not yet materialized.

Let Architecture Earn Its Complexity

This does not mean ignoring the future. Successful products do outgrow their initial designs. Re-architecture is sometimes necessary. But those changes are justified by evidence. Usage patterns, performance bottlenecks, revenue growth, or operational pain.

They happen because the product has earned them.

Architecture should evolve with the product, not ahead of it.

Honesty Over Hypotheticals

Good architecture is less about preparing for every possible future and more about being honest about the present. Build systems that serve the product as it exists today and can grow based on evidence, not assumptions. Leave room to change when reality demands it.

That kind of pragmatism is not a compromise. It is a responsibility of every software engineer.

There is a myth I used to believe. You might believe it too.

It sounds something like this: “I am a developer, I write TypeScript, computers are incredibly fast now, and I mostly move JSON from an API to a UI. Big O notation is for low-level engineers who write databases or do game development.”

It is a comforting idea. It lets us focus on frameworks, state management, crud operations and component libraries. It suggests that performance is somebody else’s concern.

I built Stacksmith to test that belief. I wanted a practical way to re-learn Data Structures and Algorithms after years of neglect, so I spent the past few months revisiting them during my personal development time at DataCamp.

I decided to read and process the theory, and translate the exercises into code. This was also the perfect opportunity to try out a different programming language, Go. To make it easier for most people to understand, I also wrote everything in Typescript, so you get to choose your preference.

Is it perfect? Most likely not!

Is there room for improvement? Always! Feel free to raise a PR at any time.

Is it enough to start your learning journey? 100%!

The Universal Laws of Speed

Stacksmith ships with a small CLI. You can clone the repo, run yarn start, pick a chapter, and watch different algorithms race each other.

In Chapter 2, I compare Linear Search and Binary Search on the same dataset.

Linear Search checks items one by one → O(N)

Binary Search repeatedly cuts a sorted list in half → O(log N)

Binary vs Linear Search

This table clearly shows how the checks change based on the data.

The surprising part wasn’t the difference between Go and TypeScript. It was how insignificant that difference became once the algorithm changed.

Yes, Go’s Linear Search was faster than TypeScript’s in raw milliseconds.

But the gap between O(N) and O(log N) completely dwarfed the gap between languages.

If you pick an O(N) solution where O(log N) is possible, no compiler, JIT, or runtime can save you.

That’s the universal law: algorithms scale, languages don’t.

Where Bad Performance Hides In Your Code

Most of us are not writing search functions from scratch. Our actual work looks more like “fetch data, filter it, merge two arrays, update the UI”. That feels harmless.

Take this very common pattern:

const activeUsers = users.map((user) => {
  const details = userDetails.find((d) => d.id === user.id);
  return { ...user, ...details };
});

It is short, readable, and easy to review. It is also secretly O(N²). If both lists contain around 1 000 items, this friendly looking code performs about 1 000 000 comparisons.

On small datasets you will not notice. But on a page where users can filter, sort, or search, it starts to add up. Suddenly a simple dropdown freeze feels “mysterious”. We reach for useMemo, or we blame the backend, or we start worrying that React is just slow.

If we rewrite the same code to build a small hash map of userDetails first, the cost of each lookup becomes O(1) instead of O(N). The total cost drops from roughly 1 000 000 operations to something closer to a few thousand.

Same feature. Same framework. Same browser. Completely different experience for the person using it, and completely different performance.

Once you start to see patterns like this, you cannot unsee them. They appear in every language: in Python scripts, in Java microservices, in SQL queries, even in infrastructure code.

Becoming a Stacksmith

That is why I picked the name Stacksmith.

A blacksmith learns the character of their materials. Iron is strong but brittle. Steel can bend. They choose the right one for the job.

As developers we work with different materials: arrays, maps, sets, trees, graphs, stacks, queues. Each one has a character. Some are great for random access. Some are great for inserting in the middle. Some are built for fast lookups.

Stacksmith is my workbench to explore that craft:

• Around twenty chapters of exercises, from arrays and linked lists to graphs and dynamic programming.
• Every solution written side by side in TypeScript and Go. (sidenote: the code is not production-grade, and that’s fine!)
• A CLI to run the algorithms, print timings, and feel how they behave under different input sizes.
• A “KB Assistant” where you can paste your own code and get a quick, human readable “Big O audit”. (If it doesn’t have AI, is it even real nowadays?)

The goal is not to create perfect implementations. The goal is to give you a safe place to experiment and to build an intuition for how your choices in data structures and algorithms show up in real performance.

The Dual Language Advantage

Even if you mostly write TypeScript today, I would still invite you to look at the Go implementations in the repo.

TypeScript gives you many helpful abstractions. It hides pointers and most memory allocation details. It lets you resize arrays and objects without thinking too much about what happens behind the scenes.

Go is a bit more explicit. When you build a linked list, you wire together nodes that point to each other. When you create a slice and append to it, you see how capacity comes into play.

Writing the same algorithm in both languages forces you to reconcile the two views. You start to see that the “magic” behaviour in your high level language is still bound by the same low level rules.

You do not have to become a Go expert to benefit from this. Seeing how a few core structures are built in a different ecosystem is often enough. After that, you carry the mental model with you, no matter what language you are using at work.

Why This Matters For Your Day Job

So what is the practical outcome of caring about this?

First, there is the obvious one: speed. A list filter that runs in O(N) instead of O(N²) will feel smooth on devices that are older, slower, or busy doing other things. That is a quiet kind of inclusivity. You are respecting the time and patience of your users.

Second, there is cost. On the backend, more efficient algorithms and data structures usually mean less CPU time and more throughput, which slows down the need for scaling, which in turn reduces infrastructure cost (even if it’s negligible at a small scale). That might not show up on your personal credit card, but it does matter for the teams and companies that pay for the infrastructure (no matter how negligible).

Finally, and maybe the most important, it is foundational knowledge. The exact frameworks and libraries you use will change over your career. The core ideas behind stacks, queues, maps and graphs are not going anywhere.

How To Try Stacksmith

If you are curious, here is a simple way to get started:

Clone the repo: git clone https://github.com/joachimzeelmaekers/stacksmith.

Install the dependencies and run the CLI with yarn start.

Pick a chapter that sounds familiar, like arrays or maps.

Run a benchmark a few times, then change the input size and see what happens.

If you feel brave, paste a piece of your own code into the Knowledge Base Assistant (because what’s a post in 2026 without some AI attached to it?) and see what it says about your current approach.

Note: Make sure to read the README if you wish to use this!

You do not have to go through all twenty chapters. Even spending an evening with two or three of them can give you a strong sense of how much impact “small” algorithmic choices can have.

Conclusion

Performance is not a niche concern for low level specialists. It is part of building software that feels respectful, reliable, and enjoyable to use.

You can switch languages, frameworks, or hosting platforms, and those choices do matter. But underneath all of them, the same rules still apply.

If you want a practical way to explore those rules, take a look at Stacksmith.

Clone it. Run yarn start. Race a few algorithms. Bring your own snippets.

Most of all, use it as a reminder that you do not need to become a “low-level engineer” to write performant code. You just need to take a step back to the foundation, and treat data structures and algorithms as tools in your craft, no matter which language you use.

That attitude tends to disappear when the subject is software.

Taking over an older codebase is a familiar experience for most engineers. You open a project that has been around for years, start reading through the code, and quickly form an opinion. The structure feels outdated, patterns look odd, and choices stand out that you would never make today. The quiet conclusion often follows: this is a mess.

I have had that reaction myself more times than I care to admit. Part of that reaction comes from confidence. We see the code through the lens of what we know now, with better tools, more experience, and the benefit of hindsight. That makes it easy to assume we would have done better, given the same situation.

I remember opening a project like that more than a dozen times. A few minutes in, I was already mentally rewriting large parts of it. At the time, it felt obvious that starting fresh would be easier than understanding what was there.

What we tend to forget is that code is only the visible part of the story. It captures decisions, but not the context in which those decisions were made. Deadlines, team size, available tools, business pressure, and technical limitations rarely survive in the repository. All that remains is the outcome.

When we judge old code without understanding its context, we are judging with incomplete information.

One reason context disappears so easily is that we are rarely intentional about preserving it. Code tends to outlive conversations, whiteboards, and Slack threads. Sadly, even pull request descriptions rarely include the decisions that were made.

This is where things like Architecture Decision Records can help. Not because they enforce structure, but because they capture intent. A short note explaining why a decision was made, what alternatives were considered, and which constraints mattered at the time can make a huge difference years later.

The same is true beyond architecture. Many technical decisions are driven by product choices, timelines, or business realities. When that context is missing, the code can look arbitrary or careless, even when it was neither.

Writing these things down is not about justifying the past. It is about giving future readers a chance to understand it.

It is also worth turning that lens inward. The code I write today feels reasonable and well structured to me now. Given enough time, it will not. Someone else will open it years from now, without the benefit of my assumptions or constraints, and wonder why certain choices were made. In that sense, none of us write timeless code.

Experience in people earns respect because we understand that learning happens over time. We accept that earlier decisions were made with less information, different priorities, or under pressure. Code deserves the same generosity. It is not a monument to perfection, but a snapshot of understanding at a particular moment.

The urge to rewrite is understandable. Rewriting feels productive, clean, and decisive. Understanding takes longer, and it rarely comes with the same sense of progress. But skipping that step often means repeating mistakes rather than learning from them.

Respecting old code does not mean defending every decision or avoiding change. It means starting from the assumption that the people who worked on it were solving real problems as best they could. It means reading before rewriting, asking why something exists before removing it, and assuming rational intent instead of incompetence.

Most of the time, the code is not the problem. Missing context is.

When we approach older code with curiosity rather than judgment, we give ourselves a better chance to improve it responsibly. More importantly, we acknowledge that we are part of a longer story, not the first chapter and certainly not the last.

Respect, in software as in life, is not about agreement. It is about understanding what came before.

Titles!

A title is just a label to define the role of an employee. Some companies might use Software engineers and others might use developers or programmers. “Potayto, potahto”. But be aware, whatever the title may be, this doesn’t necessarily represent the knowledge or skill level that this person has.

You might be thinking, why is this important? It’s not, but that’s the point.

What I’ve learned is that I should consider everyone as equal, whatever the title the person may have, and ask those questions that might sound dumb. In the end, you should treat an intern with the same level of respect as your CEO.

Pick tasks that scare you!

We’ve all been there… New team, a new way of working, 15 new tools to explore and learn, and a whole new business to get accustomed to. This is pretty scary, certainly when some tasks on the board involve talking to different teams within the organization…

These tasks are the ones that help you learn the most. Don’t pick up the tasks to change the color of a button because they look small and easy. Pick the tasks that require you to step out of your comfort zone, even if you need 3 times the estimated time. This doesn’t mean that you should blindly pick big and complex tasks but you should try to coordinate with your team in order to pick these types of tickets. If anything, it will give you a great introduction to the organization.

Learn concepts, not syntax

A classic, but such an important lesson that should never be forgotten. In 5 years I’ve used MongoDB, PostgreSQL, MySQL,… as databases. I’ve written projects in Spring Boot, Python, Nodejs, and even C#… Used Google Cloud, AWS, and Azure as a cloud platform. This is not bragging or anything that I’m proud of. This will likely happen to you as well when you’re working on short-term projects as a consultant and that’s perfectly fine. As long as you stick to learning concepts and not syntax.

Don’t get me wrong. I do understand that syntax is important and sometimes you need to focus on specific technologies, but technologies are ever-changing and this won’t stop. Most concepts will not change at the pace technologies are changing, which gives you the ability to adapt better to difficult situations. All of these concepts that you learn on the way will potentially help you solve your next big problem.

Before undertaking his craft, the artisan first sharpens his tools

We as engineers are constantly working on our computers, and it’s invaluable to know as much as you can about it. This goes from learning a bunch of shortcuts while writing code to getting used to navigating servers via the command line. Every tool that you use on a daily basis should be sharpened before undertaking your craft.

This of course doesn’t mean that you can’t use tools that you don’t know well. I’m just saying that you shouldn’t be cutting 5000 trees with a blunt ax. If you’re looking for this specific challenge, don’t let my advice stop you from trying!

Adding value

Adding value, as far as I know, is what employers want you to do the most. You should always try to add value to the project that you are working on. Adding value could mean increasing revenue for a product, improving user experience, streamlining processes, you name it. But it will not be easy since it might require you to speak up in tough situations or be silent in others but the outcome should stay the same.

I’m not just sharing this so that your employer is pleased with you, but this can also help you to prove your own value to the company in performance reviews. If you continually add value and improve at what you’re doing, it’s very difficult for employers to ignore it.

Stick to your values

This might be confusing, but we’re talking about different kinds of values here.

I have a few values that are very important to me in my work. I want my work to be challenging, I want to learn new things, and I want to contribute by helping others within or outside of my team.

We all need money to survive, but I try to stick to the values that I think are of most importance to me, and if my job is no longer in line with these values, I should do something about it. I either search for a way to fit my values within my current role, or look for a new role within or outside the organization.

Breathe, Think, Execute

Early on in my career, I used to immediately start executing tasks before creating a blueprint in my brain or on a piece of paper of what the task involves. I would even say that I took the acceptance criteria (if the task had any) and started building on a solution for it, without thinking about the future of this piece of code or solution. Most of the questions came after the “completion” of the task.

A few of my favorite ones were:

• Can we deploy this proof of concept to production tomorrow?
• Will there be any problems if a lot of users are using it?
• Did we add the ability to support French, Dutch, and English interfaces?

You get the drill. Don’t over complicate everything you build, but make sure you anticipate the future of your solution in a pragmatic manner. It will reduce the headaches, long hours at the office, and projects that go over budget by a significant amount.

Sidenote: Make sure to try and ask these questions as soon as possible in the process, certainly before making estimates.

Learn to say no

This is something that I struggled with and still do, but it’s important to say no to things. Doing 4 extra hours of work a day for an extended period of time can cause tremendous issues to both your mental and physical health. It’s great that you want to help the company, but those 4 extra hours (where only one hour is likely to be productive) won’t fix the problem when you are out for 6 months due to burnout.

Feedback

One of the things that is often taken for granted is feedback. I’m very quick in giving someone a positive comment about something they did, and that’s something I love to do. Positive feedback is great. Everyone loves to hear positive comments about their work every now and then.

Positive feedback is only valuable when there are multiple types of feedback. If you’re not receiving constructive feedback, positive feedback is adding less value to you, which often makes it more difficult to process.

This feeling is normal since not all feedback is fair, but get used to receiving feedback by asking for it regularly. If you ask for feedback often, you’ll be able to adjust and improve and if you don’t, you’ll eventually receive feedback that might be much harder to digest if you didn’t ask for it yourself.

I could go on and on about the lessons that I learned in only 5 years, and I hope it helps you with navigating your first years as a software engineer (or whatever your title might be 😉). You might disagree completely with everything that I said here, and that’s totally fine but I hope at least one of these points can help you improve your career or serve as an affirmation for you. I think this blog post is also perfectly in line with my values to try and contribute positively to or help others.

Let’s see what the next 5 years bring!