DEV Community: Jake Lundberg

Your 1:1s Have No Ticket, So They're the First to Go

Jake Lundberg — Mon, 20 Jul 2026 14:14:01 +0000

There are weeks where I finish my personal work after hours because I wouldn't move three meetings.

Thirty minutes each, one per person on my team. When the week goes bad, that block doesn't move, and something else pays for it.

Everybody agrees you should care about your people. It's easy advice to nod along with.

But when pressure starts to build, the first thing a tight deadline kills is the conversation that isn't about tickets.

What actually gets cut

When pressure is high and the delivery date is ugly, it's easy to throw a bunch of tickets at the team and yell march. That is not leading.

Support doesn't become impossible during crunch...it just stops being prioritized.

And it stops being prioritized for a fairly boring structural reason.

Most of what competes for that half hour leaves an artifact. A ticket closes. A PR merges. Something moves on a board, and at the end of the week you can point at it and say that thing happened. The 1:1 doesn't produce any of that. Nothing moves, nothing logs, and there's no line item anywhere that records the conversation took place, or what result that sync with your team member had.

The value it produces is uncountable in the same way. You can count the incidents you resolved. You can't count the person who didn't quietly check out, or the problem that surfaced in week two instead of week nine because there was somewhere for it to surface. The good outcome is an absence, and absences don't show up in any system you report on.

So the countable work wins by default. Not because anyone decided it should, and not because leadership is dumb about people. The scoreboard only has columns for one kind of thing.

Work that leaves an artifact tends to get protected by incentives, without anyone having to defend it. Work that doesn't leave one comes down to whether you decided it matters.

Encouragement, coaching, teaching, the non-ticketed work that actually develops people...all of it still fits in a chaotic period. There is room. But only if you've decided ahead of time that it isn't optional.

And "decided" is carrying a lot of weight in that sentence. Good intentions don't survive crunch. A defended time slot does.

The practice

So here's the actual practice. At least 30 minutes a week with each person, and it happens regardless of what else is going on. I've been running it this way for months.

I prioritize that time over most other things on my calendar, because that's the only way to keep it from getting bumped every time I get busy.

I've had stretches where I was slammed, and the 30 minutes stayed put.

My team knows how busy I am. They can see it. That's the reason this matters more than it looks on paper. My hope is that watching me hold that half hour while everything else is on fire shows them something about how I prioritize them against the rest of the work.

The one rule about what we discuss

The one thing I push my team on is don't bring ticketed work to this conversation.

That half hour is not for discussing current work. It's set aside for growth, goals, whatever they're finding hard, things they want to learn, things they're curious about, advice they're after.

It's also your single best intelligence gathering tool as a manager. It's where you find out who's a flight risk, who's quietly drowning, who secretly hates the new project...before it blows up in front of you. A status update doesn't tell you any of that.

Get their agenda before the meeting

Before each 1:1, I send the person a document to jot down what they'd like to talk about. It's their agenda, not mine.

The document has three sections.

The first one is "anything you want to chat about," and it's blank space. Their call, sitting at the top of the page above anything I bring.

The second is five questions, under a heading that says they're just there to get you thinking. They're the nudge away from ticketed work. Some of the ones I use:

What feels harder lately than it should?
In your opinion, what matters most over the next 90 days?
What has been your biggest win in the last week?
What is one thing you would like me to do differently?

The third is follow ups, if there are any. Where something from a previous week gets picked back up.

That's the whole document. It's short, and it goes out before every one of these.

Then in the actual conversation, the hard part is shutting up. Don't jump to fix. Just absorb, and take notes on their friction points.

What it costs me

Back to the cost.

When I'm genuinely slammed, holding those 90 minutes means some of my other work gets delayed. On occasion that means finishing it after hours. I'm not going to pretend "protect the time" is free advice.

I don't have a clever way around that. The time comes from somewhere. I've decided where I want it to come from, and then I pay for it.

Why the slot is the thing

The structure is simple to write down. Thirty minutes, their agenda, a few questions, no tickets. Doing it well is a different thing entirely, and that part never stops being work.

The reason I keep coming back to the time slot rather than the technique is that the technique never gets a chance if the meeting doesn't happen. Running a good 1:1 is its own hard skill. But it's a skill that only comes into play in a conversation that actually took place.

So what matters first is whether any of it still happens during the quarter where everything's late and your own calendar has turned against you.

That's the week it counts. It's also the week it quietly disappears, unless you already decided it can't.

So what's the first thing your calendar drops when the pressure comes on? And what would it actually cost you to stop dropping it?

Culture Debt Kills Faster Than Tech Debt

Jake Lundberg — Mon, 13 Jul 2026 12:56:53 +0000

Someone would ask a question in a public Slack channel. Every so often a couple of people would start to answer. Then the manager would step in, say what was going to happen, and the thread would go quiet.

On its own, it looks like nothing. A decisive manager keeping things moving. But it was a team going quietly into debt, and the dead Slack thread was one of the interest payments.

You already know tech debt. You cut a corner in the code to ship faster, and you pay interest on it later in bugs, slow changes, and the one file nobody wants to touch. Culture debt works the same way, except the corners you cut aren't in the code. They're in the norms, the expectations, and the relationships that decide how people actually work together.

But tech debt is visible. You can see it, point at the file, write a ticket, argue about whether it's worth paying down. Culture debt is more dangerous because it gives you none of that. You don't watch it accruing. You see the symptoms, and by the time they show up, the debt has already compounded.

Let me tell you how a team I joined got there.

The reward was volume. The only thing that reliably got praised was pushing a lot of code. The manager was open about it...their whole framing of the job was being able to out ship anyone on the team. Everyone else stayed quiet. Nobody ever stood up and argued against quality. If you'd asked, the manager would have agreed that testing mattered and that quality mattered. Those things just never got prioritized. So over and over, what actually got rewarded (volume) quietly beat what everyone said they wanted. This didn't happen out loud. The reward silently won every time.

You can guess what that bought. Planning went first, so features shipped in half finished states and got abandoned there. Testing basically didn't exist. We had a QA person, but things slipped through constantly. Bugs were everywhere. Plenty of features barely worked, and some just didn't.

The human side hollowed out at the same time. People stopped speaking up in meetings. Those Slack threads kept dying. Engineers never got brought into conversations with other teams...one person owned every cross-team relationship. The few times I did talk to people on other teams, it was obvious none of them trusted what engineering shipped. The bugs, the missed timelines, the features that didn't solve their actual problem. They'd stopped believing us.

Why did it take hold? Because it was a small team. And on a small team, one person can be the entire culture.

There's no HR layer to buffer it, no competing management structure, no other org down the hall running a different norm. Whoever controls what gets rewarded sets the standard for everyone, immediately, with nothing to push back against it. At a big company a bad signal gets diluted across a dozen layers before it reaches you. On a small team there's nothing to dilute it. The manager valued volume, so before long, everyone optimized for volume.

The other reason it's so hard to catch is that every single corner disguises itself as speed. Skip the planning, we'll move faster. Skip the tests, we'll move faster. I'll just answer the question myself so we don't stall. I'll handle the cross-team stuff so the engineers can stay heads down and code. None of that announces itself as damage. It reads as hustle. And when you're small and underwater, hustle is exactly what you think you're supposed to be doing. You tell yourself you'll fix the culture stuff once you're bigger and have room to breathe.

So it stayed invisible for a long time. Where it finally showed up was the product...the bugs, the half-built features, the timelines that never landed, and the other teams who'd quietly stopped trusting what engineering shipped.

Trust is something that doesn't snap back. When it's gone, people leave...that part you expect. What you don't expect is that the ones who stay stop trusting the platform and stop trusting each other. Communication drops. Information gets hoarded. People get reluctant to back anyone else's idea. And the real conversations move out of the open and into private messages, where a decision made in public gets quietly downplayed or worked against. One missing norm, and you get all of that.

This is why I think culture debt kills teams faster than tech debt. Tech debt you can refactor on a schedule you control. Culture debt lives in trust, and trust doesn't refactor.

I got to watch the recovery too. That manager eventually left, and the team started climbing back out. The technical stuff came back first. Testing became the norm, planning got sharper, quality climbed. That part was almost mechanical...you decide to write tests, you write tests.

The human stuff took far longer. People learning to speak up again, to trust that answering a question in public wouldn't get them shut down, to believe a decision made in the open would hold. That took over a year. You can rewrite a module in a sprint. You rebuild trust one interaction at a time, and only if nothing knocks it back down in the meantime.

If you're leading a team, you can't ticket any of this, which is what makes it so easy to let slide. But there's one question that surfaces it early, and it's worth asking yourself honestly...”does what you actually reward match what you say you value?” Not the values painted on the wall, or included in some presentation. The ones that get praised in practice. If the only thing that earns praise is volume, your team already knows quality is optional...whatever the values page says.

And watch what goes quiet. When questions in a public channel stop getting answers, when nobody pushes back in a meeting anymore, when the same one person handles every hard conversation...that's the interest coming due.

That team didn't have worse engineers than anywhere else I've worked. It had a reward that quietly disagreed with its own values, and nobody noticed until it showed up in the product.

AI Code Generation Has a Social Media Problem

Jake Lundberg — Mon, 06 Jul 2026 22:52:29 +0000

The morning I announced what I'd been building, a comment showed up on the post. It was friendly. It opened with a compliment, agreed with me, and then walked through a few of the risk signals worth thinking about...who owns the code, what a change actually touches when it runs, whether it goes anywhere near auth or payments. Solid stuff. It was also every point I'd made in the post it was commenting on.

Then it suggested I go build a tool that scores that risk automatically and flags it before a merge.

That tool is the thing the post was announcing. The comment read my post, agreed with my post, listed my post's own points back to me, and then recommended I build the product the post existed to launch.

I'm pretty sure no person wrote it. It had the shape you learn to spot after a while...a compliment, a neat little list, a question at the end to keep me talking, and "experience" that never once said anything the article hadn't already said. So why did I reply? Two reasons. Other people were going to read that thread, and I wanted them to see me being a decent human in it. And on the slim chance I was wrong and there was someone real back there, I didn't want to be the guy who blew them off.

So I wrote a short, warm reply. To a comment that took a machine half a second to generate.

That little exchange is the whole thing I want to talk about.

The comment cost whoever posted it basically nothing. Reading it, working out whether a human was involved, and writing something back cost me real time and attention on a morning I had none to spare. The effort didn't disappear. It just moved off the person who made the thing and onto me, the one stuck dealing with it.

That same move...cheap to produce, expensive for somebody else to sort out...isn't new. We've lived through it once already. We just called it social media.

Here's the shape of it underneath both. When making something gets cheap but judging whether it's any good stays expensive, the judging doesn't get cheaper to match. It gets pushed downstream. Whoever's producing floods the zone, and whoever's downstream picks up the tab for sorting the good from the garbage. Nobody sits down and decides this...it happens on its own the moment producing stops costing the producer anything, because judging was always the expensive part and nothing came along to make it cheap.

Posting got cheap somewhere around 2008 to 2012. All of a sudden anyone could say anything to everyone, instantly, for nothing. Some of it was worth reading. A lot of it was noise nobody thought about for even a second before hitting post. And the cost of all that noise didn't land on the people posting. It landed on you, scrolling, doing the sorting with your own thumb and your own time.

Code generation got cheap 2 or 3 years. And we're seeing the same result. The volume went way up, the thought behind each piece went way down, and the cost of that didn't land on whoever generated the code. It landed on whoever reviews it, and whoever maintains it later, and whoever's debugging it at two in the morning six months from now.

The usual complaint, "there's so much worthless junk now" is just the part you feel. What's actually going on is the cost quietly sliding downstream while nobody's watching it move.

Now, before I turn into every other "AI is drowning us in slop" post, let me be fair about the part those posts skip.

A LOT of code was already kind of disposable. Boilerplate, glue, snippets copy-pasted from the last place they worked. "Ninety percent of everything is junk" is an old line, and it was true long before anyone had an LLM. The ratio of lazy to careful probably hasn't shifted as much as it feels like it has.

Two things did shift, though. One is just raw volume...there's so much more of it now. The other one is sneakier. Generated code shows up looking good. Clean formatting, sensible names, all the little signals you use to tell at a glance that someone thought about what they were doing. Except this time nobody did. And that surface polish is exactly what slips past a quick review, because the usual tells that something got slapped together aren't there anymore.

So is this just something myself and a few other are feeling? It turns out, there's actual evidence...a company called GitClear looked at 211 million changed lines of code from 2020 through 2024, the same stretch AI coding assistants went mainstream. Across those years the share of code that was just copy-pasted kept climbing, and the share that got refactored...actually cleaned up and reused...kept falling. In 2024 the two crossed for the first time. More copy-pasting than reusing. More produced, less considered, and now there's a graph of it.

Here's where code and social media stop being the same story, though, and it's the part that should bug you (I know it bugs me).

A worthless post is gone in a day. It slides off the bottom of the feed and that's the end of it. Social media's flood is exhausting, but it's an attention problem, and attention problems clean up after themselves. Tomorrow the feed is fresh.

Worthless code doesn't slide anywhere. It gets merged. Now it's in your codebase, and the next feature gets built on top of it, and the one after that. And you're the one maintaining it, long after whoever generated it has moved on. You maintain it for years.

A bad post costs you a second of your morning. A bad merge costs you a little more every month until you finally tear it out, long after everyone's forgotten it was ever a shortcut.

This is what has been on mind over the past week. The flood looks the same in both places. The difference is that one of them washes away on its own, and the other one is still sitting in your repo the day you leave.

Sources

GitClear. (2025). AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones. https://www.gitclear.com/ai_assistant_code_quality_2025_research

I'm building Merge Lantern, risk intelligence for small engineering teams. It flags which open pull requests most need senior eyes before they merge, in one short daily digest. It's early, and the first 5 design partners get their first 6 months free. If your team feels this problem, join the waitlist at mergelantern.com.

What I Look For When a Risky PR Lands

Jake Lundberg — Mon, 29 Jun 2026 16:32:43 +0000

A few weeks ago I pointed a hand-built risk digest at unkey, a real open-source auth and API-keys codebase with 58 open pull requests, and asked it one question. If I were the senior on this team, which five would I want to look at before they merge?

Here is what came back at the top.

A billing change pushing month-to-date deploys to Stripe that also carried a database migration, bumped a dependency lockfile, and had failing CI. A second Stripe change, only 265 lines, but it touched subscription deletion...money-handling code where a small mistake is expensive. A 1,720-line database migration with no test files touched at all.

Notice what put those at the top. It was not size. The second one was tiny. They are at the top because of where they land and what they carry: money code, a schema migration, a dependency lockfile, a red build. Blast radius and correctness, not line count. That is the thing I have spent years learning to scan for the second a PR shows up.

The digest was not perfect, and I will be honest about that. It also flagged a dark-theme CSS change as touching authentication, billing, and secrets. It was wrong, for a dumb and useful reason: it matched on file paths that sit under routes named "auth" and "keys," not on code that actually touches auth. Touching a sensitive-named path is not the same as touching sensitive logic. I am still building this thing. But even when it was wrong, it was wrong in a fixable way, and it was right about the ones that mattered.

Here is what I keep coming back to. On a small team, senior attention is the scarcest resource you have. And the review pipe treats every pull request exactly the same...a 4-line config change and a 1,720-line migration wait in the same queue for the same eyes. The risky ones do not announce themselves. So the thing that actually breaks is not that nobody reviews. It is that the scarce attention gets spread evenly across changes that carry wildly different risk.

What I want is easy to say and apparently hard to get. I want the scarce attention to go where the risk actually is.

And once you start looking at it that way, you notice the question "where should attention go?" does not start or stop at the pull request. It starts when the ticket gets written, because some planned work is risky before a single line exists, just from what it will touch. It runs through the PR, the part I just showed you. It shows up in patterns across the team, the areas that keep generating risk, the places where someone is working in unfamiliar territory and could use a second set of eyes. And it rolls all the way up to a question every engineering leader should be able to answer and almost none can: how much risk are we carrying right now?

That is what I am building. It is called Merge Lantern, and it is a risk intelligence platform for engineering teams. One connected view of where risk lives across your whole software delivery lifecycle: from the ticket that gets written, to the PR that gets merged, to the patterns that emerge across your team, to how much risk you are carrying as a business. It does not review your code for you. It tells you where to look first, and how much risk you are holding.

The risk you ship hides in the dark.

The PR risk digest is the piece that is real today: every morning, a short list of the open PRs most likely to need senior attention, with the reasons attached. The other three layers are the roadmap, and I am building them in the open, one at a time.

If "send me that every morning" is something you would want for your team, I am opening the waitlist now. mergelantern.com

The Stale Feature Flag We Deleted That Turned a Feature Back On

Jake Lundberg — Mon, 22 Jun 2026 13:30:00 +0000

Someone on our team was cleaning up feature flags. It was good instinct...we had a pile of them, and plenty were clearly dead. One in particular had been turned off for over a year. It looked about as safe to delete as anything could look. So they deleted it.

And it turned a feature back on.

Here's the part that still makes me put palm to forehead. Deleting the flag didn't delete the feature that depended on it. There was still code out there, half-forgotten, that checked that flag before doing its thing. While the flag existed and was off, that code stayed quiet. When the flag got deleted, the check didn't blow up...it fell back to the code's default value. And the default was true.

So a feature nobody had thought about in a year quietly switched itself on. "Cleanup" turned out to be a deploy.

On its own, that feature wasn't a big deal. The problem was it collided with another, more important feature. The two were never meant to be running at the same time, and when they were, the second one broke too. Now we had a real bug in production. And here's where I'll own a mistake...our observability wasn't as good as it should have been. We didn't catch it. We found out when a user told us.

Then it took us a long time to track down, for two reasons that both come straight back to the flag.

First, the flag didn't exist anymore. So when we went looking for what changed, there was nothing to find. No flag, no recent deploy of that feature, no changes to the code, no obvious culprit. The thing that caused the bug had been deleted, which is a special kind of frustrating...you're debugging the absence of something.

Second, the old configuration had targeted a subset of users. So the bug only showed up for that specific group. We couldn't reproduce it until we worked out which users were affected and what they had in common. A bug you can't reproduce is a bug you can't fix, and we burned real time just getting to where we could see it ourselves.

The lesson I took from it? Deleting a feature flag doesn't remove a decision. It hands the decision to whatever your code falls back to when the flag is gone. If you don't know what that fallback is, for every place the flag is read, you're not cleaning up...you're shipping a change and hoping.

The other way flags bite you is that they get tangled up with each other, and the tangle lives in nobody's head.

Years ago we had the same kind of feature split across two codebases...our API and our frontend. Same feature, basically, but each side had its own flag. They weren't nested. Neither one knew the other existed. But they were completely dependent on each other...the frontend side only worked if the API side was also on.

You can guess what happened. Someone turned on the frontend flag. The feature broke, because the API flag was still off. Two flags, two repos, one invisible dependency, and nothing anywhere told you they had to move together. The coupling was real...it just wasn't written down, because at the time, the feature flags didn't come with a place to write that down.

Put those two stories next to each other and it's the same pattern. The danger of a feature flag isn't the flag. It's that everything you need to know about it...what reads it, what it falls back to, what it's secretly coupled to...fades out of memory over time, while the flag itself sits there looking harmless.

A flag that's been off for a year isn't dead. It's dormant. And dormant is worse than dead, because dead implies someone confirmed it's safe to remove. Dormant just means everyone stopped looking. Unused is not the same as unimportant.

I don't have this fully solved, but a few things I'm a lot more careful about now.

Before you remove a flag, find every place it's read, AND know what the code does without it. Removing the flag is the easy part. Knowing your fallback is the whole job. If the answer is "it defaults to true," well...deleting the flag is how you turn the feature on.

Treat flag removal like a real change, not like tidying. It changes runtime behavior, so it deserves the same scrutiny as the PR that added the feature. Arguably more, because the people who understood it have most certainly moved on.

Make cross-system dependencies explicit somewhere a human will actually see them. If a frontend flag needs an API flag, that relationship has to live somewhere other than the memory of whoever built it. One idea I like...create the flag's removal task at the same time you create the flag, so cleanup is queued instead of remembered. It isn't free...a pile of "remove me later" tasks is its own kind of debt...but it beats discovering the dependency in production.

And have some way to notice when a dead feature comes back to life. We didn't. That's the gap that turned a small mistake into a user-reported incident. It doesn't take much...just something that would have raised a hand and said "this code path hasn't run in a year, and now it's running."

The reason this stuff is so easy to get wrong is that none of it looks risky. A flag that's been off for a year is the least threatening line in your config. No alarm on it, no recent change, no owner paying attention. It looks like nothing.

That's exactly what makes it dangerous. The risks that get you are rarely the ones that look risky. They're the ones that have sat quietly long enough that everyone forgot they were risks at all.

The Real Reason Your PRs Get Big

Jake Lundberg — Mon, 15 Jun 2026 16:07:57 +0000

I once worked in an org that shipped massive pull requests as the default. Not occasionally...as a matter of habit. A single PR could sit open for days (or even weeks in some cases), because reviewing it meant holding an entire subsystem in your head at once. Bugs piled up. Deadlines slipped, again and again. And it ended the way these things tend to: we eventually had to rebuild a big chunk of the system, because it had gotten into a state nobody could safely change anymore.

Here's the part nobody said out loud. The engineers weren't bad. They were smart people working hard. The PRs got big for a much more boring reason...and it's probably the same reason yours do.

Nobody ever taught them how to cut the work down.

Big PRs are a skill gap, not a character flaw

We talk about large PRs like they're a discipline problem. "Just make smaller PRs." As if the only thing standing between a 1,500-change diff and a 150-change one is willpower.

It isn't. Breaking a big piece of work into small, self-contained, independently reviewable chunks is a real skill. It takes time to build, and almost nobody is explicitly taught it. You get handed a ticket that says "add billing," and "add billing" genuinely feels like one thing. Seeing the seams...where this PR could safely end and the next one begin...is the hard part, and it's the part no one trains you on.

I know, because I used to ship big PRs too. When I was younger I wrote sprawling changes all the time. I wasn't being careless. I just thought that was what "done" looked like: you take the problem, you solve the whole problem, you put the whole thing up for review.

It took me years to learn that smaller was simply better, and there was no single moment where it clicked. No disaster, no lecture. It was a slow migration...a little better this week than last week, over and over.

What changed my mind wasn't someone telling me to keep PRs under some number. It was watching what actually happened every time my PRs got smaller:

More bugs got caught. A reviewer can actually reason about 200 changes. They cannot truly reason about 2,000...they skim, they trust, and they approve.
They got reviewed and merged faster. Less time sitting in the queue blocking everyone, including me.
They stopped being overwhelming. I could focus on one piece instead of trying to keep the whole system in my head at once.
They made me a better planner. To ship small, you have to break the work down first...which means actually understanding the shape of what you're building before you build it.

That last one snuck up on me. Small PRs forced me to start seeing systems as a stack of Lego bricks...small pieces that snap together and build on each other...instead of one giant thing I had to swallow whole. And once you can see the bricks, cutting the work down stops feeling like overhead. It's just how you think.

What it looks like when a team gets this right

The team I lead today ships small, manageable PRs as the norm, and the difference isn't subtle:

Our average open-to-merge time is about 1.5 days.
We get far fewer bugs reported, and the ones that do show up, we can usually find and fix quickly...because the change that introduced them was small and legible in the first place.
Our delivery timing is much more consistent. We say something will land, and it lands.

I'll be honest about one piece: I still do a lot of the up-front planning and decomposition myself. Breaking work down is THE skill, and it's the one I'm actively coaching. Everyone on the team is working on it...but it's learned, not assigned. You don't fix big PRs with a rule. You fix them by teaching people to see the bricks. (The number we aim for is under 300 changes a PR. The number matters less than the habit it builds.)

And then AI showed up

Here's what makes all of this more urgent than it was even a year ago.

For most of software history, there was a hidden governor keeping PRs from getting too big: writing the code cost the author real effort. Hand-writing 2,000 changes was painful enough that, on some level, you didn't want to. Size was self-limiting. "Keep PRs small" was advice that the sheer friction of typing partly enforced for you.

AI deleted that friction.

It now costs the author almost nothing to generate an enormous change. Type a prompt, get hundreds of changes back. The effort didn't disappear, though...it moved. It landed squarely on the person reviewing it. The author pays almost nothing; the reviewer eats the entire bill.

Which means the one thing that used to keep PRs reasonable...the cost of producing them...is gone. "Make smaller PRs" has stopped being something the workflow quietly enforces for you. It's now something you have to enforce on purpose, every single time, against a tool that will happily hand you a thousand changes you never really thought about.

So the skill I picked up slowly, over years, isn't just nice-to-have craft anymore. It's the thing standing between your team and a review queue that has quietly stopped catching anything.

The part worth sitting with

If size no longer signals effort...if a giant PR no longer means somebody thought hard and did a lot of work...then size on its own tells you less than it used to about which changes are actually risky.

And that's the real question hiding underneath "why do PRs get big?" Not every PR deserves the same scrutiny. Some are trivial. Some can quietly take down production. The skill was never just cutting work into smaller pieces. It's knowing which of those pieces actually deserve your most careful, most expensive attention.

Most teams don't have a real answer to that yet. They review everything at roughly the same intensity, which means they under-review the dangerous changes and over-review the boring ones.

That's the problem I think about most these days. But it starts somewhere much simpler: learn to cut the work down. Teach your team to see the bricks. It's still the highest-leverage habit in engineering...and AI just made it matter more, not less.

One honest question to close on, because I haven't fully solved it either: once size stops telling you which PRs are risky, how does your team decide which ones get the careful read and which ones get waved through? I'd genuinely like to hear how you handle it.

Merge Standards That Actually Get Followed

Jake Lundberg — Mon, 08 Jun 2026 13:20:50 +0000

When a PR on my team crosses 500 changes, it gets the same response every time: this one's too big...let's break it down.

I don't enjoy being the line-count police. But I've learned that consistent pushback, with the reasoning attached, is the difference between merge standards that exist and merge standards that actually work.

Here's the thing. Just about every team has a merge standards page sitting in a wiki somewhere. Small PRs. The right reviewers. Tickets linked. And most of those pages? Decoration. Not because the standards are wrong, but because nobody is actually following them.

So instead of handing you another list, I want to show you the honest state of my team's. And I'll be upfront about the list itself...it isn't completely original. It's a collection of pieces I've picked up over the years...from talks, workshops, articles, and the teams I've worked on. Most of them just put words to rules I was already following. The list was never the valuable part. The valuable part is being honest about which standards my team enforces with real mechanisms, which ones run on culture, and which ones we still don't meet.

Let's dig in.

The standards we're strict about

Keep changes small. The goal I've set for my team is to keep PRs under 300 changes. The actual ceiling is 500. That gap is deliberate...the goal is what we aim for, and there's room for judgment in between. But once a PR goes past 500 changes (and isn't one of the few exceptions we allow), I push back and ask for it to be broken down. Not sometimes. Every time. The moment you let one slide, the standard starts becoming a suggestion.

I also keep a close eye on the numbers here: each engineer's average PR size, the team's average, and every individual PR that gets opened. Why so strict? Because a reviewer can actually reason about a 300-change PR. Much past that, and the "review" starts turning into a skim with a green checkmark at the end. I've seen it. You've seen it. We've all done it.

Don't let PRs sit. Open-to-merge in under 2 days. A PR that sits around goes stale. The author's context evaporates, conflicts pile up, and by the time someone finally gets to it, the review is worse for the wait. Idle time is where good changes quietly rot.

Link a ticket to every PR. The only exception we make is the rare high-priority hotfix (and everyone knows when one of those is happening). Why does this matter? Because the reviewer gets context before they read a single line of the diff by first reading the requirements and source context included in the ticket. And six months from now, when someone asks "why does this code even exist?"...there's an answer.

Automate the arguments away. Linters and formatters run in pre-commit hooks, then again in CI. Nobody negotiates with a formatter. That frees up reviewers to hold authors accountable for the things automation can't check: patterns, naming, the shape of a solution, etc. Every argument you automate is review attention you get back for the judgment calls.

The standards that run on culture

The right reviewers (informally). For certain areas of the codebase, like access control and auth, my team requests my direct review. For areas where one team member has the most experience, the developer pulls them in. They don't have to be the formal approver...they just need eyes on the change. Because the wrong reviewer doesn't just lack context. They can focus on the wrong things entirely.

Extra brains on complex changes. I'd love to tell you we have a mechanism for this...but we don't. The team just pulls people in when the work gets hairy. It works because the norm exists, and norms survive because people keep modeling them. The important piece is instilling a culture where this kind of thing is encouraged and accepted.

Break the work down before it ever becomes a big PR. This one is coaching, not enforcement. Early on, I broke the work down myself. I wrote the tickets small and showed the team what the expectation looked like. These days, I hand each team member a ticket with the requirements listed, and they do the breakdown themselves. Small PRs don't start at review time...they start at planning.

The standards we don't meet (yes, really)

DevSecOps review for high-risk code. We don't have a DevSecOps team. This standard came from an enterprise context, and I kept it on the list anyway. Our small-team adaptation turned out to be the informal rule above: high-risk areas get senior eyes (mine included). If you're at a startup, odds are you can't meet this standard as written either. That's okay. Adapt it instead of pretending.

Required documentation. Our tickets usually carry the PRDs and context docs. "Usually" is doing a lot of work in that sentence. I'm talking with the team right now about additional documentation requirements (like including spec files with changes), but we haven't landed on a process yet. I'm including this one because every honest standards list has a section like it.

Auto-merging safe changes. Documentation, tests, non-functional formatting...these don't need the full ceremony. Today they move through quickly because we apply looser expectations, but I'll be honest: that's just how it shakes out, not something we've automated. Eventually I want tooling (something like LinearB) that can auto-approve or even auto-merge these.

Deprecation automation. We only recently deprecated our first APIs, so automated change requests for deprecated usage are just now starting to matter for us. Standards can sit dormant until your codebase grows into them. Write them down anyway.

What actually makes standards get followed

So what's the difference between a wiki page nobody reads and a set of standards a team actually lives by? For my team, it came down to three things. None of them are items on the list.

The expectation is explicit. I say it plainly, and I repeat it often: this is the standard. This is how we work. A standards page that leadership never says out loud stays a wiki page. Your team can tell the difference between documentation and an actual expectation...and they respond to the one that gets said in the open.

I meet my own bar. My PRs stay small. My changes link tickets. If I expect it from the team, I expect it from myself first. The fastest way to kill a standard is to exempt yourself from it.

Pushback is consistent. Every oversized PR gets the same response. Every single one. And not just by me. The entire team is encouraged to push back on violations of our standards. The first time you wave one through because it's Friday afternoon and everyone's tired? Your standard just became a coin flip.

And underneath all three of these: my team knows WHY each standard exists. When someone understands why small PRs matter, they want to write them...they can see the benefit for themselves. When all they hear is "keep it under 300 changes," you get bare-minimum compliance and some very creative line-counting. I spend way more time explaining the why than enforcing the what. Honestly, that ratio is the whole point.

The standard underneath the standards

Here's a pattern worth noticing. Look at which standards survived contact with reality on my team: they're the ones that point attention at the changes most likely to hurt. Auth paths get senior eyes. Big diffs get broken down. Complex work gets extra brains. The only thing that ever skips a ticket is a hotfix...and a hotfix, by definition, is something that already hurt.

The list is the easy part. The real standard, the one underneath all the others, is deciding where your team's attention goes...and making sure it gets there before the merge, not after.

Three Targets I Set for My Engineering Team

Jake Lundberg — Mon, 01 Jun 2026 15:49:13 +0000

A while back I set three targets for my engineering team. Not velocity. Not story points. Not "things shipped."

Just three numbers.

Together they tell me whether the work is moving the way it should, or whether next week is shaping up to be a fire-fighting week. I check two of them most days. The third I used to watch closely...until we lost the tool that measured it.

Here they are, and why they earned their spot.

Why these and not just velocity

The first metric most engineering managers reach for is velocity. Story points completed, tickets closed, work merged.

Velocity is worth watching. It is a lagging indicator...it tells you what already happened...but it still shapes what comes next. When a sprint's work doesn't get finished, it rolls into the following one, and that rollover eats into whatever you had planned.

What velocity doesn't tell you is how the work moved...whether it moved in a way that's going to come back and bite you. For that you need numbers that describe the shape and quality of the work, not just the amount of it...ideally ones that flag a problem while there's still time to act.

These three do that.

1. Average PR size

Target: under 300 lines changed per PR.

What it tells me: how well the team is decomposing work.

A team consistently shipping oversized PRs isn't producing more... they're producing PRs that no reviewer can read carefully. Big PRs get rubber-stamped. Rubber-stamped PRs are where production bugs hide.

The 300-line target isn't magic. It's roughly the size below which most reviewers will actually read every line. I tell my team to aim for under 300 changes and to treat 500 as a hard ceiling, give or take a handful of genuine exceptions. Past 500 changes, I consistently see quality, review time, and thoroughness all drop sharply...the PR stops getting read and starts getting skimmed.

When the team's average creeps up over a few weeks, I have an early signal that one of three things is happening:

Stories are too coarse. The work doesn't break down cleanly into small PRs.
Engineers are batching changes. Often a review-avoidance pattern..."I'll just put it all in one."
Capacity mismatch. The team is shipping faster than the review queue can keep up.

All three predict trouble. None of them show up in velocity.

The fix usually isn't a directive. It's more hands on. It's syncing with whoever's writing the biggest PRs, helping them understand how they could have broken down the work differently so can take that lesson forward...work decomposition is a learned skill, and most engineers were never explicitly taught it.

2. Average PR open-to-merge time

Target: under 2 business days.

What it tells me: how fast the team is closing the review loop.

A 2-day average means PRs are getting attention and moving. When the average climbs toward 3+ days, something in the pipeline is dragging. In my experience it's rarely that a PR got forgotten...it's usually one of a few specific things:

Lots of back-and-forth. The review turns into a long feedback thread, and each round adds another day.
PRs sitting idle. Nobody picks the review up for a stretch longer than a working day.
Unclear requirements. The work opened before the requirements were nailed down or the open questions were answered, so review stalls while everyone figures out what it's supposed to do.
Stacked PRs. Open five dependent PRs in quick succession, each taking a day to merge, and part five is sitting for five days no matter how fast anyone moves.

Whatever the cause, a PR that drags gets expensive. The author moves on to something else. The context goes cold. The merge ends up rushed when someone finally needs it shipped... and rushed merges are one of the leading sources of production bugs I've seen.

The fix isn't more meetings about PRs. A few things help most:

A blocked calendar slot for review. A few hours per day per engineer, on the calendar, treated like a real meeting. Not "I'll get to it when I have time."
An idle-time SLA. No PR sits unacknowledged for more than 8 business hours. Acknowledgment isn't approval...it's "I see this, I'll review it by X."
Pair review for anything risky. Two reviewers on the same PR, at the same time, in the same room (or call). Faster and catches more than two separate reviews.

If this number creeps up, the team is accruing review debt. It gets paid back, with interest, by whichever engineer has to rebase a five-day-old branch onto a main that's moved underneath them.

3. Change failure rate

Target: under 10%.

What it tells me: how often our changes cause something to break.

This is the target I set for the team that I can't currently measure... we lost access to the tool that tracked it, and I'm exploring new options to start tracking it again. But it still matters, so it stays on the list.

The definition is the standard one: change failure rate is the share of changes that result in a failure, calculated as failed changes divided by total changes, times 100. If 2 of 30 changes in a month had to be fixed or rolled back, that's a failure rate of about 7%.

Below 10% is healthy. Between 10–20% means something specific is going wrong...usually missing tests, unclear requirements, or rushed reviews. Above 20% is a process problem, not a people problem.

On its own, change failure rate is a lagging indicator (like velocity). The damage is already done by the time the number moves. But cross-referenced with the first two, it becomes leading: oversized PRs plus slow merges plus a rising failure rate is the signature of a team about to have a bad month.

When all three trend together, I take it seriously. I sit down one-on-one with the engineers involved, and I bring it to the whole team so we can course-correct together. It's almost always solvable...but only if you catch it in the leading indicators, not in the post-mortem.

What these three cover together

PR size tells me about decomposition. Merge time tells me about review discipline. Failure rate tells me whether the first two are working.

Together they trace the SDLC from "ticket → working code in production"... three checkpoints along the path the work actually travels.

If one is bad and the other two are fine, I have a specific problem to investigate. If all three are bad, the team is in trouble and I still have a few weeks to fix it before anyone else notices.

That's the part most metrics miss. They tell you what already broke. These three tell you what's about to.

How I actually use them

I don't keep a spreadsheet or a dashboard. I check the first two most days and let them shape the calls I make... where to spend review time, which work to break down further, when to slow down. The numbers are decision inputs, not a report I file.

The hardest part of being an engineering manager isn't deciding what to ship. It's noticing when the team is about to ship something that's going to hurt... early enough to change course.

These are the numbers I watch for that.

The Code Review Checklist I Actually Use

Jake Lundberg — Mon, 25 May 2026 14:17:12 +0000

Every code review checklist I've ever seen...in books, in onboarding docs, in Twitter threads...covers the same six things: tests, naming, style, error handling, complexity, and "did the author actually think about this."

Those things matter...they're table stakes. But they're not what catches the bugs that actually hit production.

For years now, I've kept a personal code review checklist. Every time I miss a real issue in review, I add the thing that would have caught it. The list has grown, then gotten cut back, then grown again. At this point it has five items the standard checklists don't, and they catch most of the problems the standard ones miss.

Here they are...

1. Observability changes

When a PR adds a new code path, my first question isn't, "does it work?" It's "will I know when it doesn't?"

Specifically I look for:

New try/catch blocks that swallow errors without logging them
New endpoints, jobs, or queue consumers with no metric attached
New async work that won't show up in tracing
New failure modes that won't trigger an alert

When a code path has no observability, you don't not have a bug...you have a bug you won't notice for weeks or months. The cost is real; it's just deferred.

This is a pattern I've seen play out in different forms: a silent failure that sits for weeks before a customer flags it. The code was fine. The review was fine. Nobody had asked "will we know when this breaks?"

2. Backward compatibility of public surfaces

Most teams check API compatibility for external APIs. Few check it for internal ones.

Things to check on every PR:

Function signatures in shared modules or libraries
Database columns: dropped, renamed, or type-changed
Environment variables: new ones marked required
JSON keys in any payload anything else consumes
Message queue payloads
Config file shape

Anything any other system or service depends on is a public surface, even if you don't think of it that way. If the new code is rolled out before the old consumers stop depending on the old shape, you have an outage in waiting.

This one shows up in deploys, not reviews. The PR looks clean. The merge looks clean. The first 20 minutes of staging traffic look clean. Then the consumer service rolls and everything catches fire.

3. Migration rollout/rollback strategy

If a PR touches a database migration, I ask three questions before approving:

Is it forward-only and backward compatible? The old application code has to be able to run against the new schema, at least for the duration of the rollout. Add columns nullable. Don't drop columns in the same PR that stops writing to them.
Is it idempotent? Can the migration run twice without breaking anything?
Is it zero-downtime? No exclusive locks on big tables during peak hours. No blocking changes on the hot path.

A lot of failed migrations I've seen failed on question one. The author wrote the migration assuming the app would already have shipped, but the deploy order doesn't actually guarantee that.

I treat any PR with a migration as automatically higher-attention. The cost of getting it wrong is hours of downtime; the cost of asking three more questions is five minutes.

4. Idempotency, concurrency, and timeouts

This is the bucket that quietly swallows the most production bugs.

For any PR that introduces:

A new POST/PUT/PATCH handler
A new background job or queue consumer
A new outbound call to a third-party service
A new write path of any kind

I look for three things: what happens if this runs twice with the same input? What happens if two of these run at the same time? What's the timeout, and what happens when the timeout fires?

Most engineers know about these concerns in the abstract. They forget about them in practice. A retry handler with no idempotency guard processes a payment twice. A background job with no timeout hangs forever and blocks the queue. A new endpoint with no rate limit becomes the next abuse vector.

Junior code rarely fails on logic. It fails on what happens when something else fails.

5. The PR description itself

This isn't a code check. It's the check that has to happen before the code check.

A good PR description answers:

What problem does this solve?
What solution did the author choose?
What alternatives did they consider?
How can a reviewer test this manually?
What ticket does it link to?

If those answers aren't on the PR, I don't review the code yet. I ask for more context.

The reason is simple: once in every three to five PRs I review, I'm asking the author for context before I can evaluate the code at all. Without that context, I produce nitpicks instead of catches.

Asking for the description sounds like overhead. In practice it saves time, because the rewrite cycle on a misunderstood PR is much longer than the description cycle on an understood one.

And the comment grammar

Everything I flag uses Conventional Comments. It's a small grammar that makes review intent explicit. Each comment leads with a label, and the most consequential ones carry a decoration.

The labels I reach for most: issue (a specific problem), suggestion (a proposal for change), question (clarification I need before I can finish the review), nitpick (trivial preference), todo (small but necessary), praise (something worth calling out).

What actually moves the review forward is the decoration: (blocking) must be resolved before merge, (non-blocking) is the author's call, (if-minor) asks them to fix only if the change is small.

A real comment looks like:

issue (blocking): This handler has no idempotency guard. If a client retries, the payment runs twice.

This sounds small. It isn't.

Reviewers who don't label intent train authors to ignore them. When every comment carries the same weight, none of them carry any. Engineers learn quickly that all your feedback is negotiable.

When the (blocking) comments actually block and the nitpicks announce themselves as nitpicks, authors stop arguing. Reviews get faster.

The checklist isn't the hard part

I've handed this list to people before. They write it down. They use it for a week. Then they stop, because they can't run a ten-item checklist on every PR. Nobody has time. With anywhere from 10–50 open PRs at any moment, the math doesn't work.

So in practice you triage. Most PRs get a quick read. A few get the full pass. The trouble is, the PRs that need the full pass aren't always the ones that look like they do.

The 1000-line refactor with three reviewers and multiple hours or days of back and forth conversation? Usually fine. The 50-line config change that touches the auth path? That's the one that breaks production.

Figuring out which PRs need attention...without reading every line of every diff...is the actual problem. Lately I've been building something for it. More on that soon.

Your MVP Should Embarrass You (Here's Why That's Good)

Jake Lundberg — Fri, 05 Dec 2025 03:23:04 +0000

Building software is like traveling between destinations. In our case, it’s traveling from Problem City to New Solution. The software is the road that connects the two. But too often I see developers trying to build a 12‑lane interstate before they even know if the road reaches the right destination!

(If you’re not familiar with roadwork: building an interstate highway can take months or even years, requires tons of planning and manpower, costs a fortune, and disrupts pretty much everyone around it while it’s under construction.)

But it’s okay to build a simple one‑lane gravel road at first!

Sure, it has potholes, big rocks in the way, and you can’t go very fast on it. But despite that, it’s faster than walking (manual work) and lets you quickly figure out whether you’re even going to make it to New Solution. At this stage, it’s only a one‑way road, it’s not pretty, it’s slow to drive, and every now and then you have to worry about a fallen tree blocking the way or a car breaking down on it...but it gets the job done quickly and for WAY less money than that interstate would cost.

Here’s the great part: we never lose the ability to make the road better. With the initial gravel road, you discover that lots of people are trying to get to New Solution. So now we can lay a little asphalt and fill in those potholes so more people can get there faster.

A couple of months go by. You can now determine whether this road is fine or if we need to upgrade it. If traffic isn’t getting backed up and everyone can get to New Solution in an acceptable time, no upgrades are needed. But let’s say more and more people are coming and traffic is getting backed up.

Now is the time to improve the road (remember, the road is our software).

Let’s widen the road and make it two lanes so more people can travel at the same time. At the same time, let’s move some of those trees that are too close to prevent them from falling onto the road during storms.

And again we monitor. We fix potholes when they pop up. We help get broken‑down cars off the road. We add a shoulder on either side so people can pull off instead of having to stop in the lane. Things are working great.

A few more months go by. We can now see if our upgrades are working and our software is serving drivers’ needs, or if we need to make more changes. If things are good, we can continue to maintain the road as it is and start to look at where to build the next road. But let’s say that as New Solution gets more popular, we start to see traffic backing up again…

You guessed it...now we upgrade.

We widen the road again, this time to four lanes. We’re starting to cross other roads now (integrating with other systems), so we add some traffic lights, road signs, maybe a bridge or two, and we increase the speed limit.

Vroom vroom! More people than ever are heading to New Solution...and getting there even faster!

The cycle continues: we improve, we confirm the improvements solve the current issues, and we monitor. At some point, we no longer need to upgrade the roads. We can ease off construction, maintain the road as it is (because it meets current driver demand), and send our resources over to the next road we’re building.

This is how you should build software.

You don’t need super powerful, sophisticated, complex systems right out of the gate. More often than not, you don't need Kubernetes, you don't need expensive database and infrastructure services and support. Like the interstate example, these things take lots of time, effort, and money. Instead, we can start small: a few features that solve the immediate problem (and do it well). The software can run on a single server (or a simple serverless setup if that fits the need). Then monitor.

While you monitor, clean things up. Take care of some of that tech debt you accrued. Or look for new roads to build.

Don’t invest more until you know people are going to use it. While you monitor, maintain it. Fix bugs; address issues as they arise. Wait until you actually need to upgrade to multiple servers with a load balancer in front of them. When that starts to get bogged down, then step up to more sophisticated infrastructure solutions.

Sometimes all you need is a gravel road to start.

Productivity Unlocked: Your Guide to Daily Inbox Processing

Jake Lundberg — Tue, 13 May 2025 13:20:07 +0000

Hello, hello! So last week we learned about using your own inbox to capture all your to-dos into a single place? Well, if you followed my advice and did "The Great Inbox Dump," you're probably staring at a mountain of tasks and wondering, "Now what?" Don't worry, my friend. This week, we're diving into the next step of processing everything in that inbox!

The goal for this part is to get your inbox to 0, meaning there is nothing left in it you need to process. This will actually be your goal every day (ish) moving forward...but more on that later.

Before we dive in, you're going to need a couple of things:

A trash bin. You'll likely be tossing a bunch of stuff throughout this process, so make sure it's big enough.
A next actions list or stack. As you process everything, you'll be identifying what you next actions are. Instead of having to organize all of them at the same time, it's way more efficient to do that separately. During this process, it will be better to have a dedicated place to list or stack each of them (physically or digitally...whichever you prefer).
Some folders to group next actions. As you'll see, there are cases where multiple actions will need to be stored together. Some people like to use manilla folders, or digital folders on their computer. Either way, have a way to group and store 2 or more actions together.
A place to keep reference materials. You may find some of your items don't require you to do anything with. Some of them may just be information you want to keep around for reference. Some people like having a filing cabinet in their office for stuff like this. Or they store this information in digital folders on their computer or in the cloud.

Now it's time to dive in. For each item in your inbox, we're going to play a little game of 20 Questions. Okay, it's more like 5 questions, but who's counting?

Question 1: Is it actionable?

This is the big one. Is there some action you need to take to address this item?

If the answer is "No," don't toss it just yet! Ask yourself:

Will you want or need to take action later, just not right now? Pop it into a "Maybe/Someday" list/context. This allows you to keep it on your radar, out of your head, but not have to do anything with that item right now.
Is it useful information? Add it to your reference materials stack. We will organize this later.
Neither of the above? To the trash it goes! Be ruthless – clutter disrupts productivity, so either organize it, or toss it!

If the answer is "Yes," move on to...

Question 2: What's the next action?

Here's where we get specific. What's the very next individual, physical action you need to take?

Does it require multiple actions? Congratulations, you've got yourself a project! Create a project folder and break that item down into bite-sized actions. For example, say your task is to "paint the bedroom". Instead of this being a single, daunting action, break it down into the actions it will take to complete. First you have to measure the room and figure out how much paint you're going to need. Then you have to run to the store to get (or hop online and order) the supplies you're going to need (painters tape, paint, brushes, etc). Then you need to move all the furniture away from the walls. Next you need to tape the edges and trim so you don't get paint on anything but the walls. Then you finally paint the walls and wait for the paint to dry. Lastly you remove the tape, put the furniture back, and put away all those left over supplies.

As you can see, a single item on your todo list could actually be a project that requires many actions!

Can you do it in under 2 minutes? Don't even bother writing it down – just do it now! You may remember this from Tip #4 in this series, Productivity Unlocked: The Two-Minute Rule.

Can someone else do it? Delegate, baby! It's not lazy, it's efficient. Save your energy for the things only you can do!

Does it need to be done on a specific day or time in the future? Add it to your calendar. Just make sure there are no additional actions you need to do before that date/time. Like if the task is Attend board meeting on May 23, but you need to prepare a performance report for you team to take with you to that meeting, this would be a project where you would need to gather information a week before the meeting, compile a report, and then attend the board meeting.

Always think in terms of individual actions.

If none of the above apply, add it to your "Next Actions" list. This is where the magic happens!

And that's it! So simple. Just go item by item, asking these questions for each one. By the end, everything will have been processed and either be in the trash, your filing system for reference, or have a Next Action associated with it.

A Couple Rules to Follow

While this process is very simple, there are a couple rules you should always follow as you're going through it to avoid falling into some traps.

Nothing goes back into the Inbox - Once you grab an item for processing, it should never be put back in the inbox. This can be tempting, especially for those complex or difficult tasks you just don't want to deal with right now. Avoid this urge at all costs! You have to process everything in your inbox anyways. It's far better to just do it now.

Focus on individual actions - Every one of your tasks can be broken down into 1 or more individual actions you need to take. There may be a lot of actions listed, but there is a reason in the madness. It's easy for us to avoid a large, daunting task like, "Clean the house before mom comes to visit", which is made up of lots of individual actions. However, it's much more approachable to tackle a single action like, "Dust the mantle above the fireplace" or "Sweep the living room". You still may not want to do it, but it's a much easier pill to swallow.

Organize into Contexts

Alright, you've gone through all the tasks and reached Inbox 0. Now what? You have a full trash bin, a pile of reference materials, and a stack of Projects and Next Actions. What are you supposed to do with them? Let's go step by step:

Take out the trash. You don't need it anymore.
File your reference materials somewhere. Whatever system works for you. Just make sure it's organized clearly so you can retrieve the materials when you want or need them. I personally like to use a digital version of the Zettelkasten system for my notes and reference materials (if you're interested, I highly recommend Sönke Ahrens' How to Take Smart Notes and Tiago Forte's Building a Second Brain)
Organize all your next actions into contexts. If you look back to Tip #7, The Art of Context: A Game-Changing Approach to Task Management, you'll find all the info on how to make use of contexts to organize all your Next Actions!

And that's it! You know everything you need to do, and exactly what the next action is for each item on the list, it's time to start doing.

The Daily Ritual

Now that you have all your next actions organized and ready for you to tackle, don't lose this momentum! Everyday, as new tasks get added to your plate, add them to your inbox. Make this your default, go to, single place to put stuff. Then, at least once a day, process them all and reach Inbox 0. As you build this habit, you will be amazed at how efficient and productive you you become.

The Payoff

Congratulations! You've now transformed your overflowing inbox into a well-oiled productivity machine. By regularly processing your inbox and organizing your tasks into actionable steps and contexts, you'll always know exactly what needs to be done and when.

Remember, this process might feel a bit overwhelming at first, but stick with it. Soon, it'll become second nature, and you'll wonder how you ever managed without it.

So, what are you waiting for? Grab that inbox and start processing! Your future, super-productive self is cheering you on. Until next time, keep being awesome and getting things done!

The Hallmark of Great Developers: Writing Simple Code

Jake Lundberg — Tue, 06 May 2025 13:12:39 +0000

"If you can't explain something to a first-year student, then you haven't really understood." —Richard Feynman

This is one of my favorite quotes. It touches on something I see in the best engineers I've ever worked with, and something missing from many others. Something that's frustratingly illusive in the world of software engineering. A principle valued by most everyone, but executed by few. What is this trait possessed by the very best in our industry, you ask? What is it that great engineers do that sets them apart from the rest?

Great engineers build complex systems by writing simple code.

Let's cut to the chase: if you're writing code that takes your colleagues 20 minutes, two cups of coffee, and a string of "What the F%&#s" to understand, you're doing it wrong. Period.

If you can't write code your team (or others) can easily understand, then perhaps you don't really understand the problem, the solution, or both.

The best developers in the industry don't just write code that works; they craft code that others can understand, work with, and maintain long-term. It's not about showing off your intricate knowledge of obscure language features or your ability to chain together complex operations. It's about clarity, simplicity, and consideration for your team.

To put it bluntly...if you're not writing code with your team in mind, you're not a great developer. You might be clever, you might even be brilliant, but you're missing a crucial aspect of what makes a software engineer truly exceptional.

Let's break it down:

Complex code is a liability:

It's difficult to understand, challenging to fix, and a nightmare to maintain. It's the gift that keeps on giving...headaches.
Simple code is an asset:

It's easy to comprehend, straightforward to fix, and a breeze to maintain. It's the foundation of efficient, long-lasting software.

The choice between these two should be obvious. Yet, time and time again, developers (both junior and senior) churn out code that's more puzzle than program.

Now, you might be thinking, "But my code is complex because the problem is complex!" But here's the thing: even the most complex problems can be broken down into simpler, more manageable parts. That's what great developers do.

There's no shortage of resources out there on how to write clean, simple code. Books, articles, videos - many of them free. The information is readily available. So why do we still see so much convoluted code?

The answer often lies in ego, laziness, or a misunderstanding of what truly impressive code looks like. Impressive code isn't about cramming as much functionality into as few lines as possible. It's about solving problems efficiently in a way that others can understand and build upon.

So, how can you start writing simpler code? I'll list out a few of the same things you can find in any "How to write clean code" article out there...

Prioritize readability over cleverness
Break complex problems into smaller, manageable parts
Use clear, descriptive variable and function names
Comment your code, but strive to make it self-explanatory
Always consider the person who will read your code next

Remember, the best developers work hard to write code that other members of their team can read, understand, and maintain. They know that their code isn't just for the compiler - it's for their colleagues, for future maintainers, and even for their future selves.

In the end, the mark of a truly great software engineer isn’t measured by how cleverly they can solve a problem, but by how clearly they can communicate that solution through their code. Strive for simplicity, not as a shortcut, but as a sign of mastery. The next time you sit down to write code, remember: your teammates—and your future self—will thank you for every ounce of clarity you write.