DEV Community: Jake Lundberg

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.

Ditch the Clutter: Why You Need an Inbox for Your Brain

Jake Lundberg — Mon, 05 May 2025 13:43:52 +0000

Ever feel like you're juggling too many tasks, and letting too many things fall through the cracks? Trying to remember a bunch of things you need to get done, while others are noted in various pages of your notebook, and even more are scattered throughout various emails, texts, and Slack messages? At home you leave out tools and supplies to remind you of those projects you need to get back to. In the front seat of your car you leave boxes and receipts so you don't forget to do whatever it is you need to do with them. Stuff in your wallets, purses, backpacks, notebooks, computers, phones, desks, counters, tables, beds...the list just goes on and on and on.

This week, I'd like to help you overcome this craziness with something exceptionally simple, but also immensely powerful.

The humble inbox.

It's okay, go ahead and laugh or roll your eyes. When I first encountered this idea I did too. I thought, "How can something as trivial as an inbox, the same thing my grade school teachers used for us to turn in our papers and projects, help with something this chaotic and important?" But I gave it a shot...and yowza was I wrong!

Looking back, I've done a lot to increase my productivity and to help the productivity of those around me. But if I had to pick 1 single thing that stands out as the most impactful, it would be the inbox, along with the process of how to use it that I will be sharing with you.

Let's dive into how this simple concept can revolutionize your task management and bring some much-needed calm to your busy life.

What is an Inbox?

In the world of productivity, an inbox is more than just a place for incoming mail. It's a dedicated space where you capture all your tasks, ideas, and commitments. Think of it as a catch-all for your brain – a place to dump everything you need to remember or act on, without having to organize it immediately.

Your inbox is a powerful tool for capturing all the "stuff" in your life, freeing up your mind to focus on what's truly important. It will allow you to declutter your mind, supercharge your productivity, and fill in those cracks things were getting lost in.

Why You Need an Inbox

Peace of Mind: By having a trusted place to store all your to-dos, you free up mental space. No more trying to remember that brilliant idea you had while you were driving or cooking dinner!
Reduced Stress: When everything's in one place, you don't have to worry about forgetting important tasks.
Increased Productivity: With all your tasks in one spot, you can easily prioritize and tackle them efficiently.
No More Cracks: If everything goes through your inbox, there are no cracks for things to fall through.
Simplicity: Unlike other tools out there that are complex and require you to change everything about how you manage your time and tasks, the inbox is easy, simple, and you don't have to change you whole world to use it.

How to Use Your Inbox

The idea's simple...everything goes into your inbox, as soon as possible. Every task, every project, every idea gets added to the inbox as soon as you are physically able to get it in there.

Your boss asks you to do something? Dump it in your inbox.
Need to get cloths dry cleaned for an event coming up? Put it in your inbox.
Want to paint the garage or guest bedroom? You guessed it, inbox!
Need to make a phone call, or call someone back? Do I really need to say it again?

Don't worry about processing how you're going to complete that thing, when it's going to get done, or who all is going to do it. That comes later. What's important is building the habit of capturing everything in your inbox.

Setting Up Your Inbox

Your inbox can take many forms – choose what works best for you:

A folder or binder in your bag
Your email inbox
A dedicated app like BuzyBee (my personal favorite)
A simple notebook

The key is accessibility. Your inbox should be available whenever and wherever you need it.

I personally opt to use a digital inbox that I can have on both my phone and computer. One of these devices is always accessible to me, even when I'm driving or in the shower (thank you voice dictation!).

You should choose something you know you will almost always have access too. If your inbox is not easy for you to regularly access, it will not be as helpful to you, and you will likely not find it as helpful.

The Great Inbox Dump

Ready to get started? It's time for what I like to call "The Great Inbox Dump." Here's how:

Schedule a block of time – you might need an hour, or you might need a day. It all depends on how much you have to capture in your inbox initially, and how spread out it is
Gather EVERYTHING. And I mean everything:

- To-do lists
- Sticky notes
- Emails you've been saving
- Reminders on your phone
- Tasks lurking in your car, desk, or that spare room
- All those mental notes you've been carrying around
- If something can't physically be gathered, write it down on a piece of paper and put the paper in your inbox (only 1 item per piece of paper!)

Write each item on a separate piece of paper or enter it into your chosen inbox system.
Don't overthink it. When in doubt, put it in the inbox. You'll sort through it later.

This can result in a large accumulation of stuff and a big stack of papers. But that's good. Getting everything into a single place is going to set you up for success moving forward!

What's Next?

Now that you have everything gathered into 1 place, the next step will be to empty it. Don't worry, this doesn't mean you have to complete everything in your inbox. It simply means that you're going to process it all so you know exactly what you need to do next for each item, and organize it wherever it needs to go. But don't sweat! The process is WAY easier than you think. And it's what we'll dive into in the next post!

Until then, I encourage you to take a little time and set up your very own inbox. If you prefer pencil and paper, maybe go out and get yourself a notebook, or purchase a nice folder if you want to go that direction. If you think you might prefer to go with a digital solution, explore a few apps (there are many out there) to see if you can find one you enjoy using.

While it's not absolutely necessary, I do recommend you find a solution you enjoy using. When you enjoy something, your brain is naturally wired to want to do that thing more, which makes building the habit that much easier. Who says getting things done can't be fun?!

Embracing Change: The Real Skill Every Software Engineer Needs

Jake Lundberg — Tue, 29 Apr 2025 13:11:08 +0000

Let's face it: in software engineering, change is as inevitable as bugs in a first release. Yet, for some reason, many devs today either struggle with it or actively fight against it. I see it all the time.

Maybe it's an engineer who's been working in the industry for years and prefers the old way of doing things, before all this new technology came around. Or someone who learned just 1 or 2 technologies and doesn't want to work outside of them. Perhaps it's a dev who just doesn't want to spend the time or energy. Or maybe it's someone who's scared they won't be able to keep up, so they avoid trying.

There are a million and 1 reasons (or excuses) to avoid or fight change. But at this point, I think you know I'm here to give it to you straight, so here it is...

Change is going to happen whether you like it or not, so you might as well get on board.

Adapting to change isn't just a nice-to-have skill in software engineering—it's essential for survival and growth in our rapidly evolving industry. And that change is happening at increasing speed these days. But there's good news. With some effort, you can learn to successfully adapt to change. And in the rest of this article, I'm going to share some tips on how you can do just that.

Change Your Attitude

First things first, your attitude matters. I know it sounds cliché, but it's the truth. We can't control the waves of change crashing into our professional lives, but we can certainly control how we ride them. You can choose to be negative, sure. But ask yourself: what good does that do? The change is still going to happen, and you're just making yourself miserable in the process.

Instead, try reframing your mindset. Approach new challenges with curiosity and a problem-solving attitude. That new framework everyone's raving about? Don't groan—find some way to get excited about the possibilities it might unlock for your projects.

Find Purpose and Meaning

Purpose and meaning. Without these, it's all too easy to coast along in our comfort zones, writing the same old code in the same old way. But having a sense of purpose pushes us to venture beyond the familiar, seeking new and better ways to create impact on those things that matter to you.

When we lack a clear sense of purpose, change often feels like an unnecessary disruption—something to be avoided or resisted. But when we connect our actions to a deeper meaning, change becomes less intimidating and more like an opportunity. Purpose gives us a reason to move forward, even when the path is uncertain or uncomfortable. It provides the motivation to push past our comforts and try new approaches, because we understand that adapting isn’t just about novelty—it’s about aligning our actions with what truly matters to us.

In fact, having a strong sense of meaning can transform our entire mindset around change. Instead of seeing it as a threat to our routines or comfort, we start to view it as a necessary step toward fulfilling our goals. This shift in perspective makes us more open to learning, experimenting, and even failing, because we know each change brings us closer to the impact we want to make.

Practice Being Uncomfortable

Here's where the rubber meets the road: you need to actively practice stepping outside your comfort zone. Learn a programming language that's completely different from what you currently work in. Tackle a problem you're not sure you can solve. Take on a project that seems just beyond your current capabilities. Heck, write a blog post on a topic you're not familiar with—force yourself to learn it well enough to explain it to others.

Yes, it's uncomfortable. Yes, it's challenging. But that's the point. The more you train your subconscious to believe that stepping out of your comfort zone is normal, the more adaptable you'll become to change in all areas of your professional life.

Learn to Deal

Now, I'm not naive. I know all this change and pushing yourself can lead to stress. And let's be clear: stress is normal. In the short term, it can even help you perform better. But long-term, unmanaged stress? That's a recipe for burnout and health issues.

So, find positive ways to deal with stress. Go for a walk. Play racquetball. Read a book that has nothing to do with coding. Play with animals. Hit the gym. Pick up a hobby that doesn't involve staring at a screen. Your mind and body will thank you, and you'll be better equipped to handle the constant flux of our industry.

Look, I get it. Change can be scary. It can be frustrating. But it's also what makes our field so exciting and full of opportunities. By cultivating a positive attitude, finding purpose in your work, regularly stepping out of your comfort zone, and managing stress effectively, you're not just adapting to change—you're positioning yourself to thrive because of it.

So, the next time you feel that resistance bubbling up—whether it’s a new framework, a process change, or a shift in team dynamics—pause and remind yourself: the most successful software engineers aren’t the ones who cling to what they know. They’re the ones who embrace uncertainty, keep learning, and see change as an opportunity, not a threat.

Change isn’t just something to survive—it’s something to leverage. Make it your edge. Stay curious. Stay adaptable. And remember: in a world that never stops changing, your greatest asset is your willingness to grow.

Ready or not, change is here. The real question is, are you willing to grow with it?

The Roadmap to Real Impact: Goal-Setting for Productivity

Jake Lundberg — Mon, 28 Apr 2025 12:52:44 +0000

Once again, I'd like to start this week's post off with a question. After last week's post we know that to be productive we need to focus our energy on those actions that will have real impact. But I ask you...

What is it you want to have an impact on?

There are an infinite number of things each of us can have an impact on in this world. So how do you know which things you should be impacting? To put it plainly...you have to know your goals.

These could be short term, like wanting to buy that new gaming console. They could be long term, like wanting to retire in some foreign land decades from now. Or anywhere in between. But regardless of their timeline, you have to know where it is you want to go, and then execute on the actions with big impact that will move you in that direction.

If you don't know what your goals are, it's like getting in the car and driving in a random direction. Sure you could pick the road with the most lanes, or go buy a super fast sports car (ie. pick actions with high impact) but it's more than likely that you'll be cruisin in the wrong direction. And the longer you do this, the further and further you get from where you really wanted to go.

So, how do we avoid this scenic route to nowhere? It's simple: We need to set clear, defined goals.

This week, I challenge you to do something radical: Block out some distraction-free time and write down what it is you want for yourself. Yes, actually write them down! It's not just about having them floating around in your head – getting them down on paper (or screen) makes them real and actionable.

As simple and cliche as this sounds, you would be amazed how many people honestly don't know what they want for themselves. Don't believe me? Try asking a few of your friends what their current goals are. Note how many give you vague, obscure answers, and only list 1 or 2 things. Not that there's anything wrong with only having 1-2 goals. But in my experience, once they figure it out, most people want more out of life than that.

Now, I know what you're thinking: "Easier said than done!" Don't worry, I've got your back. Here's a practical approach to goal-setting, inspired by the wisdom of Brian Tracy in his book "Eat That Frog":

Decide what you want: Short term, long term, and everything in between. Think about what it is you really want. Many people find this challenging, so here are a few things I like to do that help me personally:

- Imagine someone gives you a huge sum of money. What are 3-5 things you know you would want to buy?
- Imagine your school or work gave you 6 months of paid vacation. What is it you would want to do with your time?
- Imagine 10-20 years from now, you're invited to have dinner with someone you deeply admire and respect (a celebrity, hero, ancestor, mentor, anyone). What kinds of *true* stories about your life would you hope to be able to tell them?
- Imagine you're nearing the end of your natural life. You're looking through photos and mementos from the various adventures of your life. What adventures do you want to be included?
- This one's a bit silly, but are you a Harry Potter fan? What would you see if you looked in the Mirror of Erised? (did you notice *Erised* is *Desire* spelled backward?)

Write it down: Get your goals out of your head and into the physical world. Make them tangible!
Set a deadline: I like to think of the wise words of Robert Herjavec, "A goal without a deadline is just a dream." Decide when you want that thing to be real in your life. And if you can't point to it on a calendar, it's not a good deadline. So if you wrote down "someday" or "eventually", try again!
Make a list: Write down every single thing you know you'll have to do in order to accomplish each goal. From the most difficult things, to the easiest and mundane, create a list of everything you would have to do in order to accomplish that goal. Add these all to your todo list!

 - It's okay if you don't think of everything. Think of as much as you can today, and as you think of more actions later, add them to your list.

Create a plan: Figure out which of the actions you wrote down have to be done first or that block other actions. Figure out the order things need to be done, and which things can be done at the same time as others.

 - A lot of people find doing this visually using hand drawn boxes, a Kanban board, or something similar is very beneficial.

Take immediate action: Do something...do anything! Don't wait until after dinner, or until tomorrow. Take any action toward a goal right now!
Take action every day: Every single day you should take action toward at least one of your goals. You should never allow a single day to pass where you can't look back on it and see that you completed some kind of action toward a goal.
Review your goals daily: Keep your goals fresh in your mind. I like to start by day by taking just a couple minutes to read my list of goals and imagine what it would be like if I accomplished each one that day. Let your mind wander a bit. This little visualization exercise really helps me to get in the right headspace as I'm starting my day.

Now that you know the things you want for yourself, and what you have to do to achieve them, you can now start picking the actions from your todo list that will have real impact on things that matter. This is the productivity that allows ordinary people like you and I to do great things.

Remember, the key is to spend your time wisely: Focus on those actions on your todo list that have big impact and support your goals. And minimize time spent on tasks that don't align with your aspirations.

Setting clear goals isn’t just a productivity hack—it’s the foundation for building a meaningful, purpose-driven life. When you know exactly what you want and take consistent, focused action toward it, every step you take brings you closer to the impact you truly want to make. So, don’t let your days be dictated by distractions or tasks that don’t serve your bigger vision. Instead, let your goals guide your actions, and watch how your productivity transforms into genuine progress. Remember: It’s your journey, your impact, and your goals—make them count.