DEV Community: Mark

Smart Developers Ship Bad Code Too — Here's Why

Mark — Fri, 03 Apr 2026 06:03:25 +0000

Let me tell you something nobody puts in the job description.

The codebase you're about to inherit — at this company, the next one, the one after that — is a mess. Not a little messy. A decisions-were-made-at-3am-under-deadline-pressure kind of mess. Somewhere in that mess is code a smart person wrote, shipped, and quietly hoped nobody would ever read again.

That smart person might be your tech lead. It might be the engineer who interviewed you. It might eventually be you.

Welcome to software engineering.

What You Think This Is About

You heard "smart developers ship bad code" and some part of you went — finally, someone's going to tell me it's okay to stop stressing about my PR.

I get it. That's a reasonable read.

But that's not what this is.

The junior developer's version of shipping bad code is:

It works for now. I'll clean it up later. Nobody will notice.

The senior developer's version is completely different. And the gap between those two versions is where careers either compound or stall.

The Comfortable Lie the Industry Tells You

The industry loves "move fast." Ship it. Iterate. Done is better than perfect.

Real principles — genuinely useful when applied correctly — that get twisted into cover stories for not thinking.

In practice, for a lot of junior developers, "move fast" means:

Open ticket
Find function
Write code
Ship

Minimal reading. Maximum doing. Dopamine delivered.

Sometimes it works. Which is the worst possible outcome. Because it teaches you the approach is fine.

It isn't fine. It's a loan you haven't been asked to repay yet.

The industry doesn't reward speed. It rewards not breaking important things.

Those are not the same target. And which one you're aiming at will define the kind of engineer you become.

What a Senior Engineer Actually Means When They Ship Imperfect Code

They made a deliberate trade-off.

They looked at the deadline, the scope, the risk, and the cost of delay — and they chose to borrow time. Consciously. With a note, mental or actual, of what's being deferred and why.

That's technical debt as a business decision. Not a failure of discipline. Not laziness in disguise. A calculated choice with full awareness of the interest rate.

Junior developers accumulate technical debt accidentally
Senior developers take it out deliberately, like a loan they intend to manage

That shift — from "I'll fix it later" to "I'm choosing to defer this and here's why" — is one of the most important things that happens between year one and year five.

Most people stumble into it. You don't have to.

The Time I Broke Something for Eleven Days

Let me tell you about a Tuesday that felt like a Friday.

We had a feature going out. I'd been in the codebase three weeks — long enough to feel dangerous, not long enough to be safe. I found the logic, understood what my change needed to do, and wrote something clean. Elegant, even. I was quietly pleased with myself.

What I hadn't done was read carefully enough to notice the function I was modifying had two callers with two different expectations. My change satisfied one perfectly and silently corrupted the output for the other.

No tests caught it. Code review didn't catch it because my change, in isolation, looked correct.

It went to production. Sat there for eleven days before a downstream team flagged something strange in their data.

Eleven days of wrong, quietly compounding.

Fix: 6 lines.
Cleanup: weeks.
Conversation with tech lead: the quiet kind. No raised voices.
The kind that stays with you.

The code wasn't bad because it was imperfect. It was bad because I didn't understand what I was touching before I touched it.

After 25 years in this industry, I can tell you — that mistake has a pattern. And I've watched hundreds of developers repeat it.

Boring Code Is Senior Code

Writing clever code feels like a flex. The elegant one-liner, the neat abstraction, the recursive solution. It shows you know the language.

What it doesn't show is that you understand the team.

Senior engineers write boring code. Deliberately, consciously boring.

Not because they can't do clever — because they've been paged at midnight to debug someone else's cleverness and decided, firmly, never to author that particular problem.

Readable code isn't a compromise. It's evidence that you've thought past the moment of writing.

Bad code that's readable is more valuable than elegant code nobody can safely modify. Because at some point, under pressure, someone has to change it.

Make sure they can.

What Most People Learn About Git Too Late

Git isn't a collaboration tool that tracks history.

Git is a safety net that enables collaboration.

Senior engineers ship with confidence not because their code is flawless — because they trust the net. They know how to branch, isolate, roll back, and recover. Shipping feels less like a leap and more like a controlled experiment.

If you're hesitant to ship because you're afraid of being wrong, the answer isn't more certainty before you ship. It's more confidence in your ability to recover when you are.

Certainty before shipping is a ceiling.
Recovery skill is a ladder.

Three Upgrades You Can Use on Your Next Ticket

Not concepts. Actual changes in how you approach your work.

🔁 Upgrade 1 — Change the Question

Instead of...	Ask...
Where do I add my code?	What breaks if I touch this?

The first question is about your output. The second is about the system. Same ticket. Completely different engineering. The second question is what separates a clean ship from eleven days of silent corruption.

⏱️ Upgrade 2 — Change Your Time Horizon

You're not solving today's problem. You're setting the conditions for everyone who touches this next — including yourself in six months when you've forgotten everything.

Junior developers optimise for the next hour
Senior developers optimise for the next on-call rotation

Ask yourself: would I want to inherit this code? If the answer is no, that's your answer.

📊 Upgrade 3 — Change How You Define a Good Week

Not the week you shipped the most.

The week where:

Nothing broke downstream
Your changes held under real conditions
PRs came back with questions instead of rewrites

Consistent delivery, communicated clearly, over time — that's what gets you trusted with harder problems.

Your reputation isn't built on your best day. It's built on what people expect from you on an average one.

The Identity Shift Nobody Talks About

You came into this thinking the goal was to write good code. It is.

But good code isn't what you think it is when you start.

You think good code is clever, efficient, elegant. You think bad code is the thing you're embarrassed to show in a PR.

What 25 years in this industry has taught me — and what experienced engineers everywhere will tell you — is this:

Good code:

Solves a real problem
Ships on time
Holds under load
Can be understood by the next person
Can be recovered from when it goes wrong

That's the whole definition. Almost none of it is about being clever.

The perfectly refactored code sitting in your branch, untouched by real users, is teaching you nothing.

The imperfect code in production — with actual edge cases, actual failure modes, actual feedback — is where you become an engineer.

Done and deployed beats pending and pristine. Every time.

Before You Write Your Next Line of Code

Spend thirty minutes understanding what you're about to touch.

Read the callers
Trace the data
Ask why it's built the way it's built
Find what breaks if your assumption is wrong

Then ship something honest, readable, and recoverable.

Smart developers do ship bad code.

The difference is they know exactly what they're shipping, why they're shipping it, and how they'll fix it when the time comes.

That's not an excuse. That's engineering.

I've spent 25 years in the IT industry — from junior developer to senior engineer — and the single biggest lever I've seen for career growth isn't technical skill. It's understanding systems before you touch them. If this resonated, follow for more straight-from-the-trenches advice on what it actually takes to grow as a software engineer.

Note: This article was written with AI assistance to help structure and articulate 25+ years of debugging experience. All examples, insights, and methodologies are from real-world experience.

How to Talk to Managers (So They Actually Listen to You)

Mark — Fri, 27 Mar 2026 22:40:26 +0000

The fastest way to feel invisible as a developer isn't to do bad work.

It's to do great work… and communicate it wrong.

You're probably thinking — "my code should speak for itself."

I thought that too. For an embarrassingly long time. And I've been in this industry for over 25 years — so that's a lot of time to be wrong about something.

They don't teach the real world in bootcamps. Get 25 years of production-grade experience on my YouTube: 🛠️👉 https://www.youtube.com/@lessonsfromproduction

What This Is Actually About

Here's what nobody tells you when you're starting out.

You think talking to managers is about communication skills. Being more articulate. Slowing down when you're nervous. Making eye contact. Saying "synergy" with a straight face.

That's not it.

It's this: your manager lives in a completely different reality than you do. Until you understand their reality, you're shouting across a language barrier and wondering why nobody responds.

This isn't a soft skills article. This is hard-earned, slightly battle-scarred advice from someone who has shipped at scale, managed teams, and watched genuinely talented engineers get passed over — not because their code was bad, but because nobody knew how good it was.

The Story That Embarrasses Me Every Time I Tell It

Let me show you what I mean.

Junior me had just finished a refactor I was genuinely proud of. Cleaned up a service that had been a mess for two years. Better performance, less complexity, the works.

I walked into my one-on-one ready to explain it. And I did. All of it. The before state, the approach, the tradeoffs, the three patterns I evaluated, why I picked the one I did.

My manager nodded. The way you nod when someone's telling you about a dream they had.

Then she said:

"So is it done? And did anything break?"

That was the entire conversation she wanted to have.

I had the right information. I just buried it under fifteen minutes of architecture monologue nobody asked for.

The Actual Insight

You think talking to managers is about explaining your work clearly.

It's about translating your work into their currency.

Their currency isn't technical elegance. It isn't even correctness.

It's outcomes. Risk. Time. Trust.

Managers are running a different simulation. Deadlines, team commitments, what breaks if this goes wrong, how they explain it upward. They need to know: is it safe, is it done, does it matter?

Everything else is noise — not because they're not smart, but because seventeen other things are already making noise.

1. Lead With What They Care About — Not What You Did

There's a significant difference between:

"So I refactored the payment service, pulled out the legacy transaction logic, rewrote the retry mechanism using exponential backoff, and updated the tests…"

and:

"The payment service is now three times more reliable under load. Zero breaking changes. Deployed."

Same work. Completely different landing.

Open with the outcome or the risk. The journey belongs in your PR description. The standup is for the headline.

Get comfortable framing your work in terms of:

Time saved
Bugs prevented
Risk reduced
Business value delivered

That's the translation. That's the whole game.

2. Bring Options, Not Just Problems

Here's where juniors — and honestly some seniors — get stuck.

They walk in with a problem. Just a problem. No ideas, no options, nothing.

And I get it. Sometimes you're genuinely stuck. That's fine.

But there's a version of that conversation that goes much better:

"I've hit a blocker on X. I see two paths — option A is faster but riskier, option B is safer but slower. I'm leaning toward B. Wanted your read."

You've done the thinking. You're asking for a decision, not a rescue.

You don't need the perfect answer. You just need to show you engaged with the problem before escalating it.

Managers remember that. It's rarer than you'd expect.

3. Calibrate Your Level of Detail

This is where technical people go wrong constantly. I still catch myself doing it.

We love detail. We live in detail. Detail is how we think.

Managers need the signal, not the circuit diagram.

A framework that actually works:

One sentence of context
One sentence of status
One sentence of what you need from them

That's it. Example:

"I'm working on the auth bug — more complex than expected, likely two more days. No action needed yet, just flagging."

Twelve seconds. They have everything. If they want more, they'll ask.

Respecting their time is itself a signal — and they notice.

4. Surface Blockers Early — Not at the Deadline

This is the one that actually costs people. I've seen it end careers. I've done it myself.

You're working on something, it starts going sideways, and your brain says:

"I'll figure it out. I don't want to look like I can't handle it."

So you say nothing.

Then it's Friday, deadline's Monday, and now you're having the conversation anyway — but with no time left to fix anything.

Here's what you miss in that moment: managers expect things to be hard. What they cannot work with is surprises at the worst possible time.

When you flag it	What it is
Tuesday: "This might slip a day or two"	A manageable conversation
Friday 4pm: same information	A trust event

Flag early. Even when it's uncertain. Especially when it's uncertain.

5. Make Your Work Visible

Your manager is not watching your commits.

They're not reading your PRs. They don't know about the gnarly race condition you hunted down on a Wednesday that saved the team three days of pain.

If you don't surface it, it didn't happen. Not in their reality.

This isn't about bragging. There's a flavour of self-promotion that makes every standup uncomfortable — don't do that.

But there's a difference between bragging and making your work visible:

"Fixed the intermittent CI failure — race condition in the test setup. The flaky build alerts should stop."

That's just information. Relevant, professional, and it quietly signals: this person finds and fixes hard things.

Invisible good work is indistinguishable from no work.

Harsh — but it's the truth that'll actually help you.

6. Ask for Feedback — Then Visibly Use It

This one is possibly the highest-leverage move on the whole list.

Ask for feedback on how you're communicating — not just how you're doing generally.

"Is there anything about how I give you updates that would make your life easier?"

That question does two things at once:

It gives you actually useful information
It signals a self-awareness that's genuinely uncommon at the junior level

Then when they give you feedback — act on it visibly. So they can see the loop close.

Managers invest in people where the loop closes. That's the whole secret.

The Shift Worth Making

After 25 years in this industry, here's what I know for certain.

The engineers who grow fastest aren't always the most technically gifted. They're the ones who figured out — earlier than most — that being good at the work and making the work legible are two separate skills.

Both matter.

You've been focused on getting better at the technical side. Keep doing that.

But start running the parallel track: learning to operate inside the reality your manager actually lives in.

Lead with impact. Bring options. Calibrate your detail. Surface blockers early. Make your work visible. Close the feedback loop.

Not because it's "soft skills."

Because the engineer who does great work and makes it legible to the people around them gets trusted with bigger problems.

And bigger problems are where the real learning lives.

If this landed for you, drop a comment below — especially if you've got a war story of your own. I read every one.

Note: This article was written with AI assistance to help structure and articulate 25+ years of debugging experience. All examples, insights, and methodologies are from real-world experience.

The Mental Model I Use Before Touching Any Codebase

Mark — Thu, 19 Mar 2026 02:43:00 +0000

After 25+ years in the IT industry, I've developed a mental model that completely changed how I approach any codebase. This is the framework I wish someone had handed me early in my career.

They don't teach the real world in bootcamps. Get 25 years of production-grade experience on my YouTube: 🛠️👉 https://www.youtube.com/@lessonsfromproduction

⚡ Typing First Is a Trap

The fastest way to get humbled as a developer? Open a new codebase and immediately start typing.

I've done it. You've probably done it. And if you haven't done it yet — you will, and you'll remember it for the rest of your career.

Because here's the thing nobody tells you early on: the instinct to just start coding feels completely rational. It feels like the right move. It feels productive.

And that's exactly what makes it dangerous.

Productive-looking is not the same as actually productive. What you're doing is optimising for the appearance of progress. And that confidence? It costs you later.

🏃 Speed Feels Like Progress (But It's a Lie)

Let's talk about why smart developers do this.

You get assigned a ticket. You open the repo. And instead of slowing down, something in your brain goes: "I'll figure it out as I go."

And honestly? That impulse makes sense. The industry rewards people who move fast. Standups reward people who "made progress." PRs reward people who shipped something. Nobody in a sprint review has ever said, "Wow, great job spending two days just reading."

So you skim. You find something that looks like where your code should go. You start typing. You feel productive.

That feeling is lying to you.

Because what you're actually doing is optimizing for the appearance of progress while quietly increasing the probability that you break something important.

The industry doesn't reward speed. It rewards not breaking important things. Those are not the same game.

🌱 Junior vs Senior: It Comes Down to One Question

Here's the real shift — and this is the thing I wish someone had told me earlier.

Less experienced developers ask: "Where do I add my code?"

They aim at a location. They skip the context. They optimise for speed and skim the system.

Senior engineers ask: "What is this system actually trying to do?"

That sounds like a small difference. It is not a small difference.

One question aims you at a location. The other aims you at understanding. And when you're working inside a system you don't fully understand, location without understanding is just a more confident way to make a mess.

Senior engineers read way more than they write. They spend time feeling unproductive on purpose — because they've learned that the pain of confusion up front is a lot cheaper than the pain of a production incident at 2am.

📋 A Half-Day Ticket. Real Consequences.

Let me tell you about a time I learned this the hard way.

Early in my career, I was asked to add a small feature to a payments service. Nothing crazy — just a new field on an existing form, persisted to the database. I looked at the model, found where the other fields lived, added mine, wrote a migration, opened a PR. Done in half a day. Felt great.

What I did not do was trace where that data actually went after it was saved.

Turns out that model was being serialized and sent to a third-party payment processor. My new field showed up in the payload. The processor didn't know what to do with it. The new field silently corrupted the payment payload.

Transactions started silently failing for a small percentage of users. Not all users. Not in a way that threw an obvious error. Just... some people couldn't check out.

We caught it because someone noticed the revenue graph looked weird.

That was my field. That was my half-day ticket. That cost way more than half a day to fix.

A codebase is not a text file. It's a living, connected system. And systems have consequences that travel far from where you touched them.

🧠 The Mental Model: 6 Steps Before You Type

So now — before I touch anything — here's how I actually think about it.

📖 Step 1 — Read Before You Write

Boring advice. Necessary advice.

I'm not looking to understand every line. I'm looking for the patterns. How do they name things? How do they structure modules? What does "normal" look like in this codebase?

If I write code that fights the existing conventions, I've already created a problem — even if it works.

🗺️ Step 2 — Map the System

What talks to what? Where are the boundaries?

I'm not trying to memorize the architecture. I just need a rough map. You cannot make good local decisions without some understanding of the global structure you're operating inside.

🔄 Step 3 — Follow the Data

This one is underrated.

Don't just read the code — trace what the data actually does. Where does it come in? How does it get transformed? Where does it go?

The logic only makes sense once you understand what it's operating on. Following data flow will tell you more about what a system is actually doing than reading a hundred function signatures.

🚨 Step 4 — Find the Entry Points and Risky Paths

Where does a request land? What are the high-traffic paths? What's the code that, if it breaks, someone gets paged immediately?

I want to know where the landmines are before I start walking.

✅ Step 5 — Read the Tests

If they exist. Big if.

But when they do exist, they are the most honest documentation in the entire codebase. They show you what the code is supposed to do, not just what it does.

And if there are no tests? That's not a greenfield opportunity. That's a warning sign. Proceed accordingly.

🔍 Step 6 — Ask Why Before How

If something looks weird — an unusual pattern, a strange condition, a function that seems way more complicated than it needs to be — do not touch it until you understand why it's there.

There's a 70% chance it exists for a real reason: a business rule, a past bug, an edge case from three years ago. And a 30% chance you're about to find out the hard way.

💡 Three Shifts That Actually Matter

Upgrade #1 — Change the Question

Stop asking: "Where do I add my code?"

Start asking: "What breaks if I change this?"

That single reframe will save you from more production incidents than any linting rule ever will.

Upgrade #2 — Change the Time Horizon

Slow now versus broken at 2am — choose your pain wisely.

Short-term speed is always a trade against long-term consequences. Know which one you're optimizing for.

Upgrade #3 — Change the Incentive Lens

Before you merge anything — ask yourself: who gets paged if this goes wrong?

Is it you? Is it your team lead? Is it the on-call engineer who had nothing to do with this change?

That question will focus your attention faster than any code review checklist.

🎯 The Challenge

Next time you open a codebase — don't type anything for 30 minutes.

Just read. Map. Follow the data. Find the edges. Ask why.

It will feel unproductive. Do it anyway.

Because you've been trying to get better at writing code faster. That's the wrong target.

The actual upgrade — the one that separates senior engineers from everyone else — is getting better at understanding systems before you touch them.

The most dangerous developer in the room isn't the one who writes bad code. It's the one who writes confident code inside a system they don't understand.

Don't be that person. You're better than that. You just needed to aim at the right target.

I've been working in the IT industry for over 25 years. If this helped you think differently about how you approach code, drop a comment below — I'd love to hear what your biggest challenge is when jumping into a new codebase.

Follow me here on dev.to for more no-fluff advice straight from the trenches of a Senior Developer.

Stop Micro-Optimizing Code Nobody Cares About

Mark — Sun, 15 Mar 2026 00:29:59 +0000

Advice from a Senior Developer with 25+ years in the IT industry — to every junior dev grinding away on optimizations nobody asked for.

They don't teach the real world in bootcamps. Get 25 years of production-grade experience on my YouTube: 🛠️👉 https://www.youtube.com/@lessonsfromproduction

You spent a whole day on it. Rewrote the loop. Cached the lookup. Shaved the function call down to almost nothing. You were proud of it.

Then your tech lead looked at the PR and asked:

"This is clever — but why did you do this?"

You didn't have a great answer.

That moment has ended more promising careers than bad code ever has.

The Comfortable Lie the Industry Tells You Early

Here's what you get taught — accidentally — in the early days:

Performance matters
Fast code is professional code
If you can make something faster, you should
If you write something a senior engineer can't immediately reverse-engineer — that must mean you're good

So you go deep. You learn about memory allocation, cache lines, branch prediction. You benchmark everything. You optimize the thing that looks expensive. It feels like craft. It feels like exactly what a serious engineer should be doing.

But here's what nobody tells you:

Companies do not reward technical cleverness in isolation. They reward outcomes. They reward velocity. They reward the ability to make the right trade-off at the right time.

When you micro-optimize code nobody asked you to optimize, you're not demonstrating skill. You're demonstrating that you don't yet know where the real leverage is.

The Core Insight Nobody Gives You

The surface skill is writing fast code.

The deeper skill is knowing which code deserves to be fast — and having the judgment to leave everything else alone.

Less Experienced Engineers	Senior Engineers
Optimize at the micro level	Optimize for system-wide impact per unit of time
Ask: "Can I make this better?"	Ask: "Does improving this actually move anything that matters?"
Focus on what's directly in front of them	Protect team velocity

That is not a subtle difference. That is an entirely different game.

A senior engineer sees a slow-looking loop and runs three questions immediately:

Is this causing a measurable problem in production?
If I touch this, what breaks?
Is this the highest-value use of my time right now?

If the answer to the first question is no — they walk away. Not because they're lazy. Because they understand that attention is a resource, and how you spend it compounds.

My War Story (And Why It Stuck With Me)

Three years into my career, I was working on an internal reporting tool. A backend job that ran every morning and generated summary data for about a dozen analysts.

I noticed the main aggregation query was doing a full table scan. It bothered me. So I spent two days refactoring the pipeline, adding indexes, rewriting the query logic, restructuring the batching.

Got the job down from 11 seconds to 4.

My manager pulled me aside after sprint review. Not to congratulate me. He said:

"That job runs at 3 AM. Nobody is waiting on it. The analysts pick up reports at 9. The eleven-second runtime was not a problem for a single person on the planet."

He wasn't angry. That was almost worse. He was just precise.

"You solved a problem we didn't have. While we had three problems we actually needed solved."

I had been so focused on making the code objectively better that I never asked whether better-in-this-dimension meant better-in-any-dimension-that-mattered.

That's not a technical failure. That's a judgment failure. And judgment is exactly what separates a strong junior from someone ready to operate at the next level.

Three Mindset Upgrades That Will Change How You Code

🔁 Upgrade 1: Change the Question You're Asking

❌ "Can I make this faster?"

✅ "Is the speed of this code currently causing a **measurable problem* for a real user or a real system?"*

If yes — profile it. Don't guess. Let the data tell you where the hot path actually is, not where it looks like it should be.

If no — close the file and find work that moves something real.

👓 Upgrade 2: Readability Is Not a Soft Skill

Code is read far more often than it is executed in its optimized form.

Readability is a direct multiplier on team velocity. A function your teammates understand in 30 seconds is more valuable than one that runs in 30 microseconds and takes 30 minutes to safely modify.

Clever code nobody else can read is debt — the kind that accumulates interest in bug reports, missed deadlines, and onboarding friction.

Write for the human first. The compiler and the runtime will outperform your hand-tuning anyway — and they won't leave landmines behind.

⚖️ Upgrade 3: Think About Who Carries the Risk

Ask yourself: who carries the risk if this optimization introduces a bug, and who actually benefits if it works?

Optimize code that was already fast enough → you own the regression, the on-call page, the trust erosion in review
Ship a working, maintainable feature on time → it compounds; other engineers build on it, the team moves faster, you move faster

Optimization for its own sake concentrates risk with no guaranteed return. Optimization in service of a real bottleneck is engineering. The difference between those two is judgment.

The Identity Reframe

Next time you're about to go deep on a performance improvement nobody requested, stop and answer one question:

"Who is waiting on this to be faster, and by how much?"

If you can't name them and quantify it — you already have your answer.

You've been trying to become a better programmer. The real upgrade is becoming a better engineer. Those are not the same thing.

A programmer makes code do things.
An engineer decides which things are worth doing, at what cost, and when.

Stop optimizing the code nobody cares about. Start optimizing your judgment about which code deserves your best work.

That's the thing that actually gets you promoted.

This article is based on 25+ years of experience working across the IT industry — from junior dev to senior engineer. If this resonated (or if you disagree), drop a comment below. I read all of them.

The Refactoring Trap: How to Stop Wasting Engineering Time

Mark — Tue, 10 Mar 2026 02:51:59 +0000

After 25 years in the IT industry, I've watched this mistake quietly derail more careers than almost anything else.

They don't teach the real world in bootcamps. Get 25 years of production-grade experience on my YouTube: 🛠️👉 https://www.youtube.com/@lessonsfromproduction

You're looking at a piece of code. It works. It's been in production for two years. The variable names are bad, the abstractions are wrong, it violates three things you learned last month.

And you think — I'll just clean this up real quick.

That sentence has killed more engineering timelines than almost any bug ever written.

The engineers who fall into this trap aren't careless. They're the ones who care most. Good taste. Read the books. High standards.

But caring about code quality and knowing when to act on it are completely different skills. Nobody teaches you the second one.

The Lie the Industry Tells You

Good engineers write clean code. Therefore, spending time making code clean is what good engineers do.

Enough truth in it to be dangerous.

The books reinforce it — Clean Code, Refactoring, The Pragmatic Programmer. All brilliant. But read early, without context, they quietly teach the wrong lesson: that clean code is the output your job demands.

It isn't.

Your job produces working software that delivers value. Clean code is a tool toward that end — not the end itself.

Then there's the performance review problem. Shipping features is visible. Refactoring is invisible — until something breaks, at which point it's your fault. Nobody says this out loud. But you feel it.

So some engineers overcorrect. They hold the codebase to standards it doesn't need to meet yet, slow the team down trying to "do it right," and are confused when they don't get recognised for it.

Others undercorrect — carrying debt forward until the system is genuinely unmaintainable, then confused when they can't ship anything.

Both traps come from the same mistake: confusing the tool with the goal.

The Core Insight Senior Engineers Don't Talk About

Here's the real skill that separates senior engineers from everyone else:

It's not writing cleaner code.

It's knowing which code deserves to be clean — and when.

	Less Experienced	Senior
Optimises for	Code quality in isolation	Cost-to-value ratio of the change
Focuses on	This file, this function, this abstraction	Team momentum, shipping cadence, trust
Asks	"Is this code good?"	"What problem does this refactor solve, and is now the right time?"

The senior version doesn't say never refactor. It says: have a reason — one that maps to a real cost, at the right moment.

Because a lot of messy code is messy for a reason. It's been through a hundred business decisions, edge cases, legal requirements, 2am fires. It doesn't look like the textbook because it didn't come from the textbook.

Before you rewrite something, you need to understand it well enough to replicate its behaviour exactly — including the bugs customers have learned to work around. That's a much higher bar than "I can see how to make this cleaner."

A War Story I'm Not Proud Of

Three years into my career, I made a mistake I want to tell you about.

We had a payment processing module. Genuinely messy — procedural, long functions, inconsistent naming. Written fast under deadline pressure by someone who'd since left. I understood it well enough to navigate it. And I had a two-week window with low feature demand.

I pitched the refactor to my lead. He was hesitant. I pushed. He said okay — keep it scoped.

I did not keep it scoped.

Three weeks in: a partially rewritten module, an incomplete test suite, and edge cases I didn't understand because I hadn't dealt with them live. A product deadline landed. I had to freeze it halfway through. We now had two patterns in the same module — the old one and the new one — which was harder to read than the original.

My lead spent three hours untangling it before the release. He didn't say much. He didn't need to.

The lesson wasn't don't refactor. It was this:

I had mistaken my desire to improve the code for a reason to change it. Those aren't the same thing.

3 Upgrades That Will Change How You Think

Upgrade #1 — Change the Question

Stop asking:

"Is this code clean enough?"

Start asking:

"What pain is this messy code causing, right now, concretely?"

Is it slowing feature development? Causing bugs? Blocking new engineers from getting productive? Those are real reasons.

If the answer is "it offends me aesthetically" — that's a feeling, not a reason. It might become one. Write it down, flag it, and come back when you have a concrete trigger.

Upgrade #2 — Change the Time Horizon

The question isn't just "is this a good refactor?" It's:

"Is this the right refactor, at this moment, in this codebase's life?"

Code in active experimentation doesn't need the same standards as settled, battle-tested code. If the business is still figuring out the product direction, the right architecture doesn't exist yet — so imposing one now means refactoring again in six months.

High leverage: stable, high-traffic, well-understood code
Low leverage: volatile code that might be thrown away

Refactoring the first category is a genuine investment. Refactoring the second is usually just waste dressed up as craftsmanship.

Upgrade #3 — Change the Incentive Lens

Before any refactor, ask: who carries the risk if this goes wrong?

Be honest with yourself. Are you refactoring because it's the right call — or for the intellectual satisfaction of a cleaner system? Both motives are human. Only one should get greenlit.

Then ask who benefits:

If you're the only engineer who touches this code and you'll be measurably faster after — that's a real return.
If three teams share it and the refactor triggers a three-week integration effort — the benefit needs to be proportional to the blast radius.

How to Push Back Without Getting Ignored

If you genuinely believe a refactor is necessary and your lead is pushing back, don't frame it as "the code is messy."

Frame it as risk.

"This module is the source of 40% of our bugs this quarter. If we don't address the underlying structure, we keep paying this cost every sprint."

Quantify the cost of inaction. Make the business case. That's a senior engineer talking — not someone who wants their code to look nice.

The Identity Reframe

Next time you're sitting with messy code — before you open a branch and start cleaning — pause.

Ask yourself three questions:

What specific problem does this refactor solve?
Is that problem costing us right now?
Am I the right person to solve it, at this moment, with this scope?

If you can answer all three clearly — go. Scope it, timebox it, ship it.

If you can't — write it down and keep moving.

You've been trying to become better at writing clean code.

The real upgrade is knowing when clean code is the job.

The refactoring trap isn't that engineers clean too much or too little. It's that they make the decision with their gut instead of their judgment.

Build the judgment.

Note: This article was written with AI assistance to help structure and articulate 25+ years of real-world engineering experience. All examples, insights, and methodologies are drawn from production systems and lived experience.

Junior Developers Are Taught to AVOID Failure (That's Why They Stay Junior)

Mark — Sat, 07 Mar 2026 19:48:13 +0000

After 25+ years in the IT industry, I'm going to tell you the uncomfortable truth that nobody in your bootcamp, university, or tech interview prep course ever told you:

Failure is not the enemy of a great developer. It IS the developer.

I've watched hundreds of junior and mid-level developers plateau — not because they lacked talent, but because they were terrified of being wrong. Meanwhile, the best senior engineers I've ever worked with? They fail constantly. Strategically. Deliberately. And they are better for it.

Here are the 8 brutal truths about why the most decorated, highest-paid developers in the industry are, at their core, professional failures — and what you can do about it today.

They don't teach the real world in bootcamps. Get 25 years of production-grade experience on my YouTube: 🛠️👉 https://www.youtube.com/@lessonsfromproduction

1. 🪦 Failure Is the Senior Dev's Most-Used Tool

Every experienced engineer has a graveyard of broken builds, botched deployments, and catastrophically wrong assumptions.

That graveyard is what makes them good.

When you have 25 years of scar tissue, you don't fear the next failure — you've already survived dozens of them. You know that a broken build at 4pm on a Friday isn't the end of the world. You've lived through the end of the world. Repeatedly.

Junior developers often treat failure as evidence that they don't belong. Senior developers treat it as the curriculum.

2. 🔴 Junior Devs Fear the Red. Seniors Read the Red.

Here's something I noticed early in my career that took me years to fully appreciate: the developers who level up fastest aren't the ones who write code that works first time. They're the ones who get deeply comfortable with error messages.

Error messages aren't a sign you've failed. They are the codebase telling you exactly what it needs.

A stack trace is a map. A compiler error is a conversation. A failed test is a gift.

Learning to genuinely love the red output in your terminal is one of the most career-defining shifts you can make. Stop dreading it. Start reading it.

TypeError: Cannot read properties of undefined (reading 'map')
    at UserList (/src/components/UserList.jsx:14:23)

That's not failure. That's precise feedback. Treasure it.

3. 🍝 The Best Code You'll Ever Write Comes After the Worst

You don't learn clean architecture from tutorials. You don't develop a genuine appreciation for separation of concerns from a YouTube video.

You learn it from maintaining your own spaghetti code at 2am, six months after you shipped it, wondering what on earth you were thinking.

I have written some truly terrible code in my career. Code I am not proud of. Code that has woken me up in the middle of the night. And every single piece of it taught me something that no course ever could — because I felt the consequences.

The mess you make today is tuition you're paying toward the engineer you'll be in two years. Don't skip it. Just make sure you learn from it.

4. 🚀 "It Works on My Machine" Is a Rite of Passage, Not a Punchline

Every senior dev has shipped something that broke in production. Every single one. If they tell you otherwise, they're lying or they haven't shipped anything meaningful.

The difference isn't that seniors never break production. The difference is that after they do it once, they build a process around it:

Proper staging environments
Meaningful logging and alerting
Feature flags and gradual rollouts
Rollback plans before deployment, not after

Breaking production is not the failure. Failing to learn from it is the failure. The first time it happens to you, welcome to the club. The third time — with no process change in between — is a problem.

5. ⚡ Speed Comes From Knowing What Not to Try

Here's something that confuses a lot of junior developers when they first work alongside a senior: why are they so much faster?

It's not that they type faster. It's not that they know every API by heart. It's not even that they're smarter.

It's that they have already failed down every wrong path and don't take it anymore.

When a senior developer looks at a problem and immediately reaches for a specific solution, that instinct was bought and paid for by years of trying the wrong solution first. They've already been burned by over-engineering, by premature optimisation, by the wrong abstraction.

Speed is just accumulated failure, distilled into intuition.

6. ⚠️ The Engineer Who Never Fails Is the Most Dangerous Person on Your Team

This one is controversial. Good. It needs to be said.

If someone on your team never breaks anything, they are not some kind of genius. They are not taking risks. They are playing it safe — and safe, in software, means stagnant.

The most dangerous engineer is not the one who ships bugs. It's the one who never ships anything bold enough to create a bug.

Safe code is often outdated code. Safe decisions are often career-limiting decisions. The engineer who only ever works on well-defined tickets, never proposes anything ambitious, never spikes on an unknown — that person is not your role model.

Calibrated risk and the willingness to be wrong is what moves products, teams, and careers forward.

7. 📝 Post-Mortems Are the Most Underrated Career Accelerator

If there is one habit I would go back and instil in my younger self, it is this: write post-mortems.

Not for your manager. Not for a ticket system. For you.

Every time something breaks — a deployment, a feature, an architectural decision — write down:

What happened
Why it happened
What you assumed that turned out to be wrong
What you'll do differently

A blameless post-mortem forces you to truly understand a system's failure at the deepest level. One good post-mortem can teach you more than three months of smooth sailing.

The engineers I have seen grow the fastest in their careers are relentless self-documenters of failure. They don't just survive incidents — they mine them for insight.

8. 🧠 Your Relationship With Failure Is Your Career Ceiling

This is the one that matters most, and the one nobody talks about.

I have seen brilliantly talented developers stall at mid-level for years — not because of technical ability, but because of how they respond when they are wrong.

The developer who treats a bug as a personal attack will always be outpaced by the one who treats it as a puzzle. The one who goes quiet in code review when their approach is challenged will always be outpaced by the one who gets curious.

Your technical skills will grow with time regardless — you'll pick up new frameworks, new languages, new paradigms. Everyone does. But your emotional and psychological relationship with being wrong — that's something you have to actively choose to work on.

That relationship is your ceiling. And unlike most ceilings, it is entirely self-imposed.

The Uncomfortable Summary

After 25+ years, here is the most honest thing I can tell you:

The goal is not to fail less. The goal is to fail better.

Fail faster. Fail smaller. Fail in staging, not production. Fail with a hypothesis, not blind hope. Fail loudly enough that the whole team learns. And when you do fail — in whatever size or shape it comes — fail forward.

The developers who had the longest, most successful careers I've witnessed weren't the ones who were the most talented at 22. They were the ones who were the most resilient and curious at every age.

That's available to you right now. Today.

Start failing better.

Have a failure that taught you something massive? Drop it in the comments — let's normalise it. 👇

Note: This article was written with AI assistance to help structure and articulate 25+ years of debugging experience. All examples, insights, and methodologies are from real-world experience.

Developers, Why Moving Fast Is Actually Making You a Slower Developer

Mark — Wed, 04 Mar 2026 19:45:37 +0000

You finished the ticket faster than anyone expected.

You shipped it. You moved on. And for a moment, it felt like proof — proof that you're good at this.

Then, three days later, someone opens a bug report. Then another. Then a senior engineer has to pause their work to untangle something you wired together in a rush. And the silent cost of that moment — the trust, the time, the rework — never shows up on your PR.

Here's the thing no one told you early enough:

Speed is the most seductive trap in software engineering. And the faster you move, the harder it is to see it.

They don't teach the real world in bootcamps. Get 25 years of production-grade experience on my YouTube: 🛠️👉 https://www.youtube.com/@lessonsfromproduction

The Comfortable Lie

Every incentive in this industry points you toward speed.

Velocity metrics. Sprint points. "Move fast and break things." The entire culture is optimised to make you feel like the faster you ship, the more valuable you are.

And when you're early in your career, you internalise that. You measure yourself by output. Lines of code. Tickets closed. Features shipped. Because that's visible. That's countable. That's what gets you noticed in a standup.

So you learn to rush:

You skip reading the existing codebase because you're eager to contribute
You skip tests because the deadline feels real
You write one massive commit — "fixes stuff" — because stopping to document your thinking would slow you down

And here's the insidious part: it works. In the short term, it works.

You look productive. You feel productive. And for a while, nobody calls it out — because the cost doesn't show up immediately. It shows up three sprints later, in a codebase nobody wants to touch, on a team that's quietly stopped trusting your PRs.

What the industry rewards visibly is speed. What it actually values — quietly, over time — is reliability.

Those are not the same thing. And confusing them is the mistake that keeps smart engineers stuck.

The Real Skill Nobody Talks About

Here's what I've learned after 25 years in the IT industry: the real skill isn't moving fast. It's moving without leaving damage.

The contrast between a junior and senior engineer isn't talent. It's the question they ask when they pick up a new ticket.

	Less Experienced	Senior
Optimises for	Starting	Landing
Focuses on	Writing code	Understanding first
When hitting ambiguity	Guesses and pushes through	Treats it as a stop sign
Measures success by	Whether the feature ships	Whether the feature holds

The junior asks: "How fast can I finish this?"

The senior asks: "What does finishing this actually require?"

Those two questions lead to completely different behaviours. The senior spends the first 20 minutes of a new ticket reading — not writing. They're mapping the system. Finding where the patterns already live. Asking the question that saves three hours of rework:

Has someone already solved a version of this?

That's not slowness. That's precision. And precision compounds.

Every shortcut you take today is a tax on your future self — and on your teammates. Skipping tests isn't saving time; it's borrowing it at a brutal interest rate. That untested code becomes the thing nobody wants to touch, the thing that silently breaks when someone upstream changes an assumption.

The real skill isn't shipping fast. The real skill is staying fast — consistently, over months, across a whole team.

A Story That Cost Me More Than a Day

Early in my career, I was handed a feature that felt simple. A filtering component. Two or three conditions. I looked at the ticket for maybe four minutes, opened a new file, and started building.

I didn't read the existing filter logic. I didn't ask why there was already a utils/filters.js file sitting right there.

I just built.

Finished in a day. Felt good.

PR went up. Senior engineer reviewed it, left one comment:

"This already exists."

Not passive-aggressive. Just factual. And somehow that was worse.

I'd built a duplicate of something that already worked — with slightly different behaviour, no tests, and naming that conflicted with existing conventions. The fix took longer than the original build. And for the next few weeks, I noticed my PRs were getting reviewed more carefully. More slowly. That trust — small as it was — had a crack in it.

The surface lesson is read the codebase. But the real lesson was this:

Moving fast without understanding the system isn't speed. It's just noise with good intentions.

Fifteen minutes of reading would have saved two days of damage.

3 Practical Shifts That Actually Compound

Upgrade #1 — Change the Question

Stop asking: "How fast can I finish this?"

Start asking: "What do I need to understand before I write a single line?"

Before you touch the keyboard, spend time in the codebase. Find the conventions. Find what already exists. Find where the seams are. A few minutes of reading is worth more than hours of rewriting.

Ambiguity in a ticket isn't a green light — it's a question you haven't asked yet. Ask it before you build, not after.

Upgrade #2 — Change the Time Horizon

You're not just writing code for this sprint. You're writing code for the engineer who touches this in six months — which is probably you.

That changes how you commit. Small, intentional commits aren't bureaucratic overhead; they're communication. They make code review faster, debugging cleaner, and rollbacks painless. A commit message that explains why — not just what — is one of the highest-leverage habits you can build early in your career.

Tests aren't a checkbox. They're the only proof that you understood what the code was supposed to do. And they're the only thing standing between the next engineer and a silent regression.

Write them. Not because someone told you to. Because you're playing a longer game.

Upgrade #3 — Change the Incentive Lens

Ask yourself: Who carries the risk of this decision?

When you skip tests, you don't carry the risk — the next person in the codebase does. When you rush a design without asking questions, you don't pay the full cost — the teammate who has to maintain it does.

Senior engineers think about this constantly. They slow down not because they're less capable, but because they understand who bears the weight of fast decisions. That awareness is what separates someone who ships a lot from someone the team actually trusts.

Speed that creates risk for others isn't a skill. It's a liability with good optics.

The Reframe

Here's what I want you to do with your next task.

Before you write anything — take ten minutes. Read the relevant code. Find the existing patterns. Check if the problem is already half-solved somewhere. If anything in the ticket is ambiguous, send one message and get it clarified.

Not because it's best practice. Because your job isn't to type fast. It's to deliver outcomes that hold.

You've been trying to become a faster developer.

The real upgrade is becoming a more reliable one.

Because the engineers who actually move fast — the ones the team trusts, the ones who get the hard problems, the ones who accelerate everything around them — they're not moving fast because they skip things.

They're moving fast because they stopped leaving damage behind them.

That's the discipline that compounds. That's the game worth playing.

I've spent 25+ years in the IT industry working across enterprise, startups, and everything in between. If this resonated, drop a comment below — what's the most expensive shortcut you've ever taken as a developer?

Note: This article was written with AI assistance to help structure and articulate 25+ years of debugging experience. All examples, insights, and methodologies are from real-world experience.

Why Being "Quietly Productive" Is Killing Your Career

Mark — Mon, 02 Mar 2026 04:45:32 +0000

They don't teach the real world in bootcamps. Get 25 years of production-grade experience on my YouTube: 🛠️👉 https://www.youtube.com/@lessonsfromproduction

You think working hard is enough.

You finish your tickets. You fix bugs no one asked you to. You refactor code that was slowing the whole team down. And then you sit quietly and wait.

And someone else gets promoted.

Not the best engineer. Not the hardest worker. Someone who talks more. Someone who "contributes to discussions." Someone who, frankly, ships less than you.

And you tell yourself they're just better at politics.

You're wrong.

I thought the same thing once. I had six months of my best work sit completely unnoticed, while a colleague with half my output got the senior title I'd been building toward.

What I realized wasn't about politics. It was about something far more fundamental — and far more fixable.

The Comfortable Lie We Were All Taught

Here's the lie you absorbed somewhere between your first CS course and your first job:

Write good code. Do the work. Let the results speak for themselves.

Schools teach it. Open source culture rewards it. The entire "10x engineer" myth is built on it — the lone genius whose output is so undeniable that merit alone carries them forward.

And for a while, early in your career, it works.

Because at junior levels, your job is to execute. Ship the feature. Close the ticket. Don't break prod.

But at some point, without warning, the game changes.

And nobody tells you.

The expectations shift from "can you do the work?" to "can we trust you with more?" And trust is not built in silence. Trust is built through communication, through visibility, through making your thinking legible to the people who make decisions about your future.

The industry rewards visible effort. It rarely rewards silent correctness.

Being right, but invisible, is the same as being wrong — from a career standpoint.

The Real Difference Between Junior and Senior Thinking

So what's actually happening when someone gets passed over?

Less experienced engineers optimize for output.
Senior engineers optimize for legibility.

Those are not the same thing.

Output is the work you do. It closes the ticket. It merges the PR.

Legibility is whether anyone understands what your work means — its context, its trade-offs, its impact on the thing that matters to the business.

Here's the same situation played out twice:

A junior engineer ships a feature and closes the ticket.

A senior engineer ships the same feature, writes a clear PR description explaining why they chose this approach over two others, flags the edge case they punted on and why, and mentions what should be monitored post-deploy.

Same code. Completely different signal.

The junior engineer is being productive.
The senior engineer is reducing organizational risk.

And here's what companies actually pay senior salaries for: they don't pay you to write more code. They pay you to make the codebase, the team, and the decision-making process less dangerous.

That only happens if people can see how you think.

Visibility isn't self-promotion. It's professionalism.

Two Mindsets, Side by Side

Let me make this concrete.

Less experienced mindset:

Optimizes for throughput
Measures success by tickets closed
Goes quiet when uncertain
Waits to be asked

Senior mindset:

Optimizes for clarity of impact
Measures success by risk reduced and decisions improved
Surfaces uncertainty early
Creates alignment before it's needed

That last one is the one most people miss.

The engineers who get promoted aren't the ones with the best solutions. They're the ones who brought the right people into the conversation early enough that when the solution shipped, everyone already trusted it.

The Mistake That Cost Me Two Months

A few years into my career, I took on a project that required a significant architecture change. I spent two months on it. Nights, weekends. I was convinced I had solved something hard.

I shipped it quietly. No design doc. No early alignment. Just a massive PR.

And I was convinced I was right.

The review process was brutal. Not because the code was wrong — it wasn't. But because nobody had been brought along for the journey. The tech lead had concerns about operational complexity. The platform team had a competing initiative I didn't know about. And the product manager had no idea what the change was or why it mattered.

Two months of work. Shelved.

Not because I was wrong. Because I had made a decision that affected four teams without involving any of them until the last possible moment.

That mistake taught me something sharp: the time you spend working in isolation is not just inefficient. It's a risk you're loading onto everyone else.

Experience doesn't remove ego. It just makes mistakes more expensive.

Three Concrete Shifts You Can Make This Week

Upgrade #1 — Change the Question

Stop asking "Is this done?"

Start asking: "Would someone reading this PR understand the trade-off I made and why?"

If the answer is no, you're not done. The work isn't just the code — it's the explanation of the code. One paragraph in a PR description is worth ten tickets in your promotion case.

Upgrade #2 — Change the Time Horizon

Quiet productivity optimizes for this sprint. Career growth requires thinking in quarters and years.

Ask yourself: "Am I building a reputation, or just a commit history?"

Speak up in design discussions. Not to hear yourself talk — but because decisions you stay silent on will later be implemented in ways you could have prevented. Your future self will thank you for every alignment conversation you had early.

Upgrade #3 — Change the Incentive Lens

Leadership doesn't promote the most efficient worker. They promote the person who reduces uncertainty for them.

Ask yourself: What does my manager not know right now that would make their job easier if they knew it?

Then go tell them.

That's not politics. That's leverage.

The person who surfaces problems before they become crises, who documents decisions, who mentors a junior engineer and makes that visible — that person is a force multiplier. And force multipliers get promoted.

The Reframe

For your next PR, your next design discussion, your next standup:

Don't just report what you did. Explain what you decided, and why, and what you chose not to do.

One sentence of trade-off reasoning. That's it.

You've been trying to become more productive.
The real upgrade is becoming more legible.

Because in the end, your career isn't built on the code you wrote. It's built on the story people tell about you when you're not in the room.

Quietly productive engineers write great code.

But they let other people write that story.

Don't.

Note: This article was written with AI assistance to help structure and articulate 25+ years of debugging experience. All examples, insights, and methodologies are from real-world experience.

Why Over-Engineering Is a Junior Developer Habit

Mark — Thu, 26 Feb 2026 20:50:07 +0000

They don't teach the real world in bootcamps. Get 25 years of production-grade experience on my YouTube: 🛠️👉 https://www.youtube.com/@lessonsfromproduction

The most complex code I've ever deleted was written by someone who'd been coding for six months.

The second most complex? Written by someone who'd been coding for six months and had just discovered design patterns.

Over-engineering isn't a sign of intelligence. It's a sign of insecurity.

The Controversial Truth Nobody Will Tell You

Not your bootcamp. Not your CS degree. Not even your senior dev in code review.

Writing simple code is harder than writing complex code.

Every junior developer I've ever mentored — every single one — went through the same phase. They learned about microservices, event-driven architecture, abstract factory patterns, and dependency injection frameworks. And then they rebuilt a to-do app using all of them.

That's not skill. That's intellectual showing off. And the worst part? They didn't even know they were doing it.

Here's Where Most Devs Mess This Up

They confuse the map for the territory.

Design patterns, SOLID principles, clean architecture — these are tools. They solve specific problems in specific contexts. But when you're new, you don't have enough experience to recognise those contexts. So instead, you apply the tools everywhere. Because it feels professional. It feels like real engineering.

I've reviewed all three of the following in actual production codebases, written by developers who were genuinely proud of them:

A factory pattern to create a single type of object that never changes
A pub-sub event system for a UI with two components
A microservices architecture for an app with 200 users

The Real Cost (This Is the Part Nobody Talks About)

Let's talk about what over-engineering actually costs — because it's not just code complexity.

It's time. It's cognitive load on every developer who has to maintain that system after you. It's onboarding time. It's debugging time. It's the 2 AM incident when something breaks in a layer nobody understood existed.

I've worked on systems where adding a new field to a database form required touching eleven files across four repositories. That wasn't good architecture. That was someone's vision of what good architecture looks like, implemented without any regard for the actual problem being solved.

The code worked. The team was miserable.

And This Is Why You Stay Mid-Level

There's a psychological trap at the heart of over-engineering, and it goes like this:

Simple code feels risky. What if requirements change? What if we need to scale? What if we need to swap out the database?

So you abstract. You add interfaces. You decouple everything from everything else. And now you feel safe, because you've planned for every eventuality.

But you've actually just shifted the problem. You haven't reduced complexity. You've distributed it. And distributed complexity is harder to see — which means it's harder to fix.

The most important word in software engineering is: yet.

You don't need it yet. Build for now. Refactor when the problem actually arrives.

What Seniority Actually Looks Like

Here's where most devs mess this up — and this one took me years to understand myself.

Seniority isn't about knowing more patterns. It's about knowing which patterns not to use.

The moment I realised I'd crossed from mid-level to senior thinking was when I deleted more code than I wrote in a week — and felt genuinely proud of it.

Pulled a twenty-step deployment pipeline down to five steps
Replaced a complex event bus with a direct function call
Removed three abstraction layers that were solving a problem we no longer had

The system got faster. The bugs got fewer. The team got happier.

Less code is almost always better code.

YAGNI: The Principle We Keep Ignoring

There's a principle in software engineering called YAGNI — You Aren't Gonna Need It.

It was coined at a time when developers were already building for imaginary future requirements. Decades later, we're still doing it.

Every time you write an abstraction for a use case that doesn't exist yet, you're making a bet. You're betting that:

The future requirement will actually arrive
It will arrive in the form you predicted
The cost of the abstraction now is less than the cost of adding it later

In my experience, that bet loses more often than it wins.

Abstractions you add when you need them fit the problem perfectly, because you can see the problem clearly. Abstractions you add speculatively are almost always slightly wrong. And slightly wrong abstractions are the worst kind — they sort of work, so you keep building on them, and the wrongness compounds.

What "Simple" Actually Means in Practice

"Keep it simple" is advice that sounds easy and is genuinely hard to execute. So let me be specific.

Simple means: a new developer can read this code and understand what it does in under five minutes.

Simple means: there is one obvious path through the logic, not seventeen depending on which abstract interface gets injected at runtime.

Simple means: if the requirements change, you can change this code without being afraid you'll break something you didn't know was depending on it.

Simple is not lazy. Simple is disciplined. It takes more thought to write a clear, direct function than to wrap it in three layers of abstraction.

The best code I've ever read read like a very good explanation. No surprises. No cleverness. Just clarity.

// Simple
function getUser(id) {
  return db.users.findById(id);
}

That's it. Readable in ten seconds. Done.

The Three Questions to Ask Before Adding Any Abstraction

This is the rule I give every junior developer I mentor: solve the problem in front of you — not the problem you imagine you might have in three months.

Before you add an abstraction, ask:

What is the specific duplication or coupling this solves **right now? If you can't answer concretely — don't add it.

Before you reach for a design pattern, ask:

What problem is this pattern designed to solve? Do I actually have that problem?

Before you split a service or add a layer, ask:

Who does this make life easier for — me, right now, or some imaginary future developer working with requirements that don't exist yet?

The Flip Side: Under-Engineering Is Also a Problem

To be fair — and this matters — under-engineering is also a real problem.

Copy-pasted logic spread across fifty files. No error handling. No separation of concerns. Business logic embedded in UI components. No tests because "we'll add them later."

That's not simplicity. That's chaos with good intentions.

The goal is appropriate engineering. Not more. Not less. The right amount of structure for the problem you're actually solving. And developing the judgement to know where that line is — that's what years of experience builds.

The Code Review Tell

Here's what I watch for when reviewing code.

When a developer explains their system and the explanation is simple but the code is complex — that's a problem. Good code and a clear explanation of it should look roughly the same.

If you need five minutes to explain why your architecture works the way it does, it's probably too complex. If I have to understand three different abstraction layers before I can read a database query, something's wrong.

The best developers I've worked with write code and then, when asked why they did it that way, they shrug.

"It was the straightforward thing to do."

That shrug is earned. It takes years.

The Question That Changes How You Write Code

The next time you're about to add a layer of abstraction, an interface, an event bus, or a new service — stop.

Ask yourself honestly:

Am I solving a real problem, or am I performing competence?

The developers who build the systems that last aren't the ones who knew the most patterns.

They're the ones who knew when not to use them.

25 years in. Still deleting more than I add. That's the job.

Note: This article was written with AI assistance to help structure and articulate 25+ years of debugging experience. All examples, insights, and methodologies are from real-world experience.

Why Your Code Works But Still Gets Rejected in Code Review

Mark — Thu, 26 Feb 2026 01:10:49 +0000

Have you ever submitted a pull request where all the tests pass, the feature works perfectly, and yet... your code review comes back with "Request Changes" in bright red? Yeah, me too. And it's frustrating because you're thinking, "But it WORKS!"

Here's the thing: working code is just the minimum bar. It's not the finish line.

Let's talk about the hidden rules of code review that nobody tells you about.

They don't teach the real world in bootcamps. Get 25 years of production-grade experience on my YouTube: 🛠️👉 https://www.youtube.com/@lessonsfromproduction

1. Cognitive Load

Your code isn't just read once. It's read hundreds of times over its lifetime. Every time someone debugs an issue, adds a feature, or tries to understand how the system works, they're reading your code.

Consider this:

d = datetime.now()
y = d.year
m = d.month
dy = d.day

This code works perfectly fine. The tests pass. But every single person who reads it has to mentally decode what each variable means. That's cognitive load.

Now look at the better version:

today = datetime.now()
year = today.year
month = today.month
day = today.day

It's self-documenting. The reader doesn't have to spend mental energy figuring out what's going on — they can immediately understand the intent and move on to the actual logic.

Good code doesn't make you feel smart for writing it. Good code makes the next person feel smart for reading it.

2. Premature Abstraction

Oh boy, have I been guilty of this one. You get excited about design patterns, and suddenly you're building a DataProcessorFactory with a ProcessorRegistry and a Strategy pattern for a feature that literally runs once a day.

There's a principle called YAGNI: You Aren't Gonna Need It.

Abstraction is powerful, but it comes with a cost. Every abstraction layer is another place where bugs can hide. Every interface is another thing future developers need to understand.

The better approach? Start simple. Just write a straightforward function that does the thing. When you find yourself copying and pasting that code for the third time, then abstract it. When you have three real, concrete use cases, then build the framework.

Rule of thumb: Don't abstract until you have at least three examples of the pattern. Two is coincidence. Three is a pattern.

3. Missing the "Why"

Comments should explain WHY, not WHAT. The code already shows what you're doing.

// convert to milliseconds
return seconds * 1000;

That comment adds zero value. The code is literally showing that conversion.

But this?

// API times out after 5 seconds, so we use 4.5s to leave a buffer
return seconds * 4500;

Now you're documenting the business logic. Now you're explaining why this specific number matters.

Same goes for retry logic:

// BAD: "Retry 3 times" is obvious from the code.

// GOOD: Third-party API occasionally fails with 503 errors;
// retrying usually succeeds within 3 attempts.
for (let i = 0; i < 3; i++) { ... }

That tells future maintainers why the retry logic exists and helps them decide if 3 is still the right number six months from now. Context is everything. When you come back to this code later, you won't remember why you made these decisions. Help your future self out.

4. Scope Creep

You opened a PR to fix a button bug. Simple, right? But then you noticed the form validation was messy, so you refactored that. And while you were there, you reorganized the components. Oh, and you updated the styling system too.

Now your "simple bug fix" touches 47 files.

Every additional change makes the review harder. It makes deployment riskier. And if something breaks in production, good luck figuring out which of those 47 file changes caused it.

One PR, one purpose. Fix the button bug. Ship it. Then open a separate PR for the form refactor. Then another for the component reorganization.

Smaller PRs get reviewed faster, deployed more confidently, and reverted more easily if needed.

5. Inconsistent Style

Your code works. But it looks foreign in the codebase because you used Promises when everyone else uses async/await. Or you used snake_case when the team uses camelCase.

I get it — you have preferences. I have mine. But consistency beats personal preference every single time.

The goal is for the entire codebase to look like one person wrote it. When someone is reading through the code, they shouldn't be able to tell where your code starts and someone else's ends.

Match the existing patterns. Follow the team conventions. Use the linter. Your future teammates will thank you.

6. Poor Error Handling

The happy path works perfectly. You tested it manually, it works great. But what about the sad path?

async function updateUser(id, data) {
  const user = await db.find(id);
  user.update(data);
  await user.save();
}

What if the user doesn't exist? What if the save fails? What if the data is invalid?

Production code needs to handle failure gracefully. Ask yourself: what could go wrong here? And then handle those cases explicitly. Fail fast with clear error messages. Don't let invalid data propagate through your system. Don't let a null reference crash your server.

The difference between junior and senior developers often comes down to this:

Juniors think about what should happen.
Seniors think about what could happen.

7. Magic Numbers

What does 50 mean? What does 300000 mean? What does 0.75 mean?

if (users.length > 50) paginate();
setTimeout(retry, 300000);
if (score > 0.75) approve();

These numbers might make sense to you right now, but they're meaningless to anyone else — and they'll be meaningless to you in three months.

Use named constants:

const MAX_USERS_PER_PAGE = 50;
const RETRY_DELAY_MS = 300_000; // 5 minutes
const SUCCESS_THRESHOLD = 0.75;

MAX_USERS_PER_PAGE tells a story. When the product manager asks you to change the threshold, you want to find it quickly and change it confidently. Named constants make that possible.

8. Testing Shortcuts

Tests pass, but do they actually test anything?

expect(result).toBeTruthy();

This test will pass if the function returns 1, true, "hello", or literally any non-falsy value. It tells you nothing about whether the code is actually working correctly.

Good tests verify specific behavior:

expect(result.email).toBe("user@example.com");
expect(result.name).toBe("Jane Doe");
expect(result.id).toBeDefined();

They document what the code is supposed to do. They give you confidence that when you refactor, you haven't broken anything. Your tests are documentation for future developers — make them count.

The Real Goal of Code Review

Code review isn't really about finding bugs. Modern testing catches most of those.

Code review is about knowledge sharing. It's about maintaining code quality over time. It's about catching edge cases and ensuring long-term maintainability.

When a reviewer asks you to change something, they're not saying your code doesn't work. They're saying "this will be easier to maintain if we do it this way" or "this matches our patterns better" or "future you will thank us for this clarity."

Before you hit submit on your next PR, ask yourself:

Can someone understand this code in six months when the context has faded?
Does it follow the team's conventions and patterns?
Is it as simple as possible, but no simpler?
Does it handle errors gracefully?

Working code is the minimum bar, not the finish line. Great code is code that disappears — code that's so clear and well-structured that future developers don't even notice it. They just understand it and move on.

You're not writing code for computers. Computers don't care if your variables are named x or userAccountBalance. You're writing code for humans.

Write code for the tired developer at 2 AM trying to fix a production bug. Write code for the new team member trying to understand how the system works. Write code for yourself in six months when you've forgotten everything.

What code review feedback frustrates you the most? Drop it in the comments below.

Note: This article was written with AI assistance to help structure and articulate 25+ years of debugging experience. All examples, insights, and methodologies are from real-world experience.

The Hidden Skill That Separates Mid-Level From Senior Engineers

Mark — Wed, 25 Feb 2026 05:31:59 +0000

Most developers will never become senior engineers — and it has nothing to do with how much code they write.

Here's the uncomfortable truth after 25 years in this industry: the thing that holds most mid-level engineers back isn't a lack of technical skill. It's a lack of judgment.

You can know every design pattern. You can write clean, tested, beautifully documented code. And you will still get passed over for senior roles if you haven't developed this one thing.

They don't teach the real world in bootcamps. Get 25 years of production-grade experience on my YouTube: 🛠️👉 https://www.youtube.com/@lessonsfromproduction

So What Is Engineering Judgment?

It's not experience. It's not cleverness.

It's knowing when not to build something.

It's reading a half-baked Jira ticket and immediately seeing the three hidden problems that will blow up in production in six months. It's walking into a technical discussion and knowing which battles are worth having — and which ones you let go.

Here's where most devs mess this up.

They think senior engineers are the ones who solve the hardest problems. But the seniors I respect most? They prevent the hard problems from ever existing.

They ask one question in a planning meeting that saves three weeks of rework. They spot the dependency nobody thought about. They say "have we considered what happens when this scales to ten times the load?" — and suddenly the whole room goes quiet.

That's not seniority from coding skill. That's seniority from judgment.

The One Question That Separates Junior, Mid, and Senior

Let me show you how three different engineers approach the exact same task.

The task: "Add a new user authentication flow."

Level	First Question Asked
🔵 Junior	"What framework should I use?"
🟡 Mid-Level	"What are the technical requirements?"
🟢 Senior	"Why are we building this? What's the existing auth doing wrong? Do we actually need a new flow — or do we need to fix the one we have?"

That question — why — is the separator.

This is the part nobody talks about.

Senior engineers are comfortable saying "I don't know, let me find out." They're comfortable saying "I was wrong." They're comfortable saying "this solution works, but it's going to cost us later."

Mid-level engineers are often afraid of those statements because they think it makes them look weak. It doesn't. It makes you look trustworthy. And trust is the currency that buys you a seat at the senior table.

The Career Trap: Feature Factory Thinking

Here's a pattern I've seen kill careers.

The developer who ships everything asked of them. Never pushes back. Never questions the spec. Just executes, ticket by ticket, sprint by sprint.

You might think that makes you valuable. Short term, it does. But long term, you become a human Jira board. You get labelled as someone who delivers tasks — not someone who delivers outcomes.

Senior engineers own outcomes. They care what happens after the code ships.

And this is why you stay mid-level.

You're solving the problem you were given — instead of solving the actual problem.

There's always a difference between what someone asked for and what they actually need. Learning to find that gap is what separates the engineers who get promoted from the engineers who get stuck.

Judgment Is Trainable — Here's How to Build It

Here's the good news: this isn't some mystical quality you either have or you don't. Judgment is a skill, and you can develop it deliberately.

1. Ask why before you ask how

Every ticket, every feature, every bug fix. Why are we doing this? What happens if we don't? What's the simplest solution that actually solves the real problem?

2. Read post-mortems — especially public ones

AWS outages, GitHub incidents, financial system failures. They're the best engineering school you've never attended. They show you exactly how smart engineers made bad decisions under pressure. Your future self will thank you.

3. Pair with people who have been wrong in expensive ways

War stories aren't just entertaining. They're compressed judgment. Every story that starts with "we tried that once and it was a disaster" is a shortcut to ten years of hard-won wisdom.

The Three Futures Test

Here's a simple framework I use before committing to any technical decision.

Before you write a line of code, ask yourself these three questions:

📈 Future 1 — What does this look like in six months when the team doubles?
🔄 Future 2 — What does this look like when the requirements change? (Because they always change.)
🌙 Future 3 — What does this look like at 3am when something breaks and whoever is on call has never seen this code?

If the answer to any of those three questions makes you uncomfortable — you've found your actual problem to solve.

Here's the hard part.

Most engineers optimise for writing good code. Senior engineers optimise for maintainable systems. There's a big difference.

A clever piece of code that only you understand is a liability. A boring, obvious, slightly-verbose solution that any developer on your team can debug at 2am — that's engineering excellence.

// ❌ Impressive but fragile
const r = d.reduce((a,c) => ({...a,[c.id]:c.v*c.q}),{});

// ✅ Obvious and maintainable
const totalsByItemId = {};
for (const item of data) {
  totalsByItemId[item.id] = item.value * item.quantity;
}

Complexity is never impressive. Clarity is.

The Hidden Layer: Communication

The other side of judgment that nobody puts in the job description is communication.

After 25 years, I can tell you: the most technically brilliant engineer I've ever worked with nearly got fired because he couldn't explain his decisions to stakeholders. He had the best judgment in the room — but none of it translated into influence.

Senior engineers don't just have good ideas. They know how to bring other people along with them. They speak in outcomes, not implementation details. They know when to go deep on the technical and when to zoom out to the business impact.

That translation layer? Underrated. Career-defining.

Your Challenge — Starting Today

The next ticket you pick up — before you open your IDE — write down in one sentence the actual problem you are solving.

Not the feature. The problem. Then ask yourself: is this ticket the best solution to that problem?

// Before touching your keyboard, fill this in:
const actualProblemIAmSolving = "";

If you can't answer that, find someone who can. That conversation is the start of senior thinking.

The Gap Is Smaller Than You Think

The gap between mid-level and senior isn't a gap in skill. It's a gap in the questions you ask.

Start asking better questions.

Everything else follows.

25 years of building software, watching careers stall, and watching others accelerate — the pattern is always the same. The code is rarely the differentiator.

If this resonated, drop a comment with the last time a single question saved your team from a disaster. I'd love to hear the war stories.

Note: This article was written with AI assistance to help structure and articulate 25+ years of debugging experience. All examples, insights, and methodologies are from real-world experience.

The Code Review Comments That Make Me Hire Someone

Mark — Mon, 23 Feb 2026 21:34:39 +0000

Code reviews are one of the most underrated signals in engineering. Not someone's code — their comments on other people's code.

Because here's the thing: anyone can write code. But the way you review it? That reveals how you actually think.

Here are eight code review comments that are green flags so strong they're practically waving themselves off the screen.

1. "Let's add a test for the edge case."

Most developers think in happy paths. User enters valid data, everything works, ship it! But the developers worth hiring think about what happens when someone enters negative numbers, empty strings, or decides to upload a 50GB file.

These are the people who think beyond "does it work?" to "what could possibly go wrong?"

Without this person on your team? Your app crashes at 2 AM on a Saturday because someone in Australia entered a negative quantity. And now you're debugging in your pajamas.

2. "This could be more readable."

This comment shows someone who understands that code is read way more often than it's written.

They're not chasing clever one-liners that look like hieroglyphics. They know that clever code isn't good code — maintainable code is good code. And they're thinking about the next developer who'll read it, which is usually themselves three months later.

Without this mindset? You spend three hours debugging code you wrote last month, squinting at variable names like x2 and tmp_val_final_v3.

3. "Have we considered performance here?"

This is the developer thinking about scale before it becomes a problem.

They see a nested loop and their spidey-sense starts tingling. Sure, this works fine with 10 records — but what about 10,000? O(n²) looks totally fine until n equals 10,000 and suddenly your users are staring at loading spinners like they're watching paint dry.

Without this mindset? Your database melts down on Black Friday while your CEO breathes down your neck about lost revenue.

4. "Nice! This is much cleaner than before."

This one might seem out of place on a technical list — but hear me out.

Code review isn't just about catching bugs. It's about people. Someone who gives positive feedback understands that. They're building trust. They're making teammates want to write good code, not dread every pull request like a trip to the principal's office.

Without this? Code reviews turn into tense, negative experiences. Morale tanks. People get defensive. Team culture slowly turns toxic.

The best engineers give just as much positive feedback as constructive criticism.

5. "What if this service is down?"

This person isn't thinking about just their function — they're thinking about the entire system.

What happens when the payment API times out? What if the database connection drops? What if that third-party service decides to have a bad day? This is the defensive programming mindset, and it's what separates people who build brittle systems from people who build resilient ones.

Without it? One API timeout brings down your entire application like a house of cards. When one service sneezes, the whole system catches pneumonia.

6. "Could we extract this into a helper function?"

This developer has a sixth sense for duplication — and they spot it before it spreads.

They live by DRY (Don't Repeat Yourself), not as an academic principle, but as something that saves hours of maintenance. Here's what happens without this thinking: you write the same logic once, copy-paste it when you need it again, and again, and again. Now it lives in 12 different places.

When you need to update it? You get 11 out of 12. And that one you missed? That's the one that causes the production bug.

7. "Let me suggest an alternative approach."

Notice the language. Not "you should do this." Not "this is wrong." But "let me suggest."

This is collaborative, not dictatorial. They're offering solutions, not just pointing out problems — and doing it in a way that respects the original author's thinking.

Without this collaborative spirit? Code reviews feel like criticism sessions. Egos get bruised. Your team stops communicating effectively. The best code reviews feel like a conversation between peers, not a lecture from a know-it-all.

8. "Is this backward compatible?"

This question shows someone thinking long-term — about existing users, existing integrations, existing systems.

They understand that breaking changes don't just mean updating your code. They mean pain for everyone using your API. Urgent updates. Angry customers. They're choosing sustainable evolution over quick wins.

Ignoring this? Your deployment breaks 50 client integrations at once. Your support team drowns in tickets. And you're writing an apology email explaining why everyone's app stopped working.

Why Do These Comments Matter So Much?

Because they reveal engineering maturity that goes way beyond syntax and algorithms. They show how someone thinks, not just what they know. And they indicate someone who makes the entire team better — not just someone who writes good code themselves.

Anyone can learn a programming language. But awareness of systems, people, edge cases, and long-term consequences? That's what you actually want on your team.

So Here's the Real Question

Do your code reviews show these qualities?

If you want to level up as a developer, start here. Start leaving better comments. Think beyond your own code. The next time you review a pull request, don't just look for bugs — consider edge cases, ask about failure modes, think about performance, and yes, throw in some positive feedback too.

Great code reviews don't just improve code. They improve engineers.

Note: This article was written with AI assistance to help structure and articulate 25+ years of debugging experience. All examples, insights, and methodologies are from real-world experience.

What code review comments impress you? Drop them in the comments — I'd love to hear what green flags you look for.