DEV Community: Jake Lundberg

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.

Beyond the Bare Minimum: How Software Engineers Can Truly Stand Out

Jake Lundberg — Tue, 22 Apr 2025 14:56:21 +0000

Continuous learning. Ask any accomplished person in the world today and they'll tell you this is one of the keys to success. It's not just a nice-to-have, it's a must if you hope to make anything of yourself in this life...and it's no different for software engineers.

Software engineering isn't static. New programming languages emerge, frameworks evolve, security threats adapt, and cloud services expand at a dizzying pace. If you're not actively learning, you're actively becoming outdated. In this field, staying still means falling behind, and falling behind means becoming irrelevant.

Why does continuous learning matter? It's not just about personal satisfaction, though that's certainly a plus. It's about problem-solving—new challenges often require new solutions. It's about career growth, and staying relevant. But it's not always easy. It requires time, effort, energy, and often stepping out of your comfort zone. However, the cost of not learning is far higher than the effort of keeping up.

But before you start patting yourself on the back for you amazing learning habits, allow me to burst that bubble. In software engineer, continuous learning isn't the exception. It's not the gold standard, or the thing that's going to get you praise (if that's what you're after)...it's the bare minimum. It's just expected of us. No different than the expectation for an athlete to exercise, or an author to know proper grammar.

Recognizing that constant learning is simply the baseline can feel daunting, but it also reframes our perspective on what it means to truly excel in this field. If keeping up with new technologies is merely meeting expectations, then the real question becomes: how do we distinguish ourselves and make real impact? In a profession where everyone is expected to keep learning, standing out requires more than just doing what's required.

So, what does going above and beyond look like in today's software engineering landscape? Brace yourself, because it's a lot more than just staying current:

Mentoring Others: Are you guiding junior engineers or running onboarding sessions?
Open Source Contributions: Are you actively contributing to or maintaining projects, not just using them?
Speaking at conferences: When was the last time you presented at a meetup, webinar, or conference?
Publishing Technical Content: Have you written any in-depth blog posts or tutorials lately?
Developing Internal Tools: Are you building solutions that improve your team's workflow?
Driving Architectural Decisions: Are you leading major technical initiatives or setting coding standards?
Proposing and Piloting new Tech: Have you advocated for and implemented new technologies recently?
Community Leadership: Are you organizing meetups or hackathons? Are you leading or moderating online discussions?
Teaching and Training: Have you run any internal workshops or guest lectured at a coding school?
Contributing to Standards: Are you participating in working groups or helping define industry best practices?

What sets these activities apart?

They require initiative—you're not just consuming knowledge. You're creating and sharing it.

They have impact—your actions benefit more than just yourself.

They demonstrate leadership—you're setting direction and inspiring others.

While continuous learning keeps you afloat, going above and beyond can make you indispensable and highly respected in your field. It's about making a lasting impact, not just keeping your head above water.

So, Where do you go from here? Stay curious. Stay relevant. Never stop learning. But remember, that's just the starting line. If you want to truly excel in this field, you need to push beyond the boundaries of your own knowledge and actively contribute to the growth of your team, company, and the broader tech community.

Will you settle for the bare minimum, or will you strive to be truly exceptional?

The choice is yours.

If you found this useful: I'm an Engineering Manager writing about PR review, merge risk, and EM craft at jakelundberg.dev. I'm also building Merge Lantern, a risk-triage platform for engineering teams. Find me on LinkedIn at https://www.linkedin.com/in/jake-lundberg/.

Busy vs. Productive: Why Prioritization Is the Real Game Changer

Jake Lundberg — Mon, 21 Apr 2025 12:47:48 +0000

Hello hello 👋 I'd again like to start this week's post off with a question. You have your todo list with dozens or hundreds of items on it...

How do you know which action to work on next?

The ability to prioritize the things that need to get done may seem straight forward on the surface, but it's something I very often see people struggle with, or even fail at. It may seem simple to just go down your list, knocking one thing off after the other. And that's all well and good when you only have a dozen things on your list, and none of them are particularly important.

But the reality is, most of us are juggling dozens, or even hundreds of todos on our lists, each with varying levels of importance. So just going down some unordered list checking things off one by one isn't gonna cut it. We could spend hours, days, or more being stressed our, overwhelmed and crazy busy, only to look up and realize we haven't really changed or impacted anything. Which brings me to my first point...

Being busy isn't the same as being productive.

So what's the difference?

Being busy means to fill one's time doing things that may or may not have a larger impact (quite often it's the later). To simply start at the top of some arbitrary list and just try to complete as many things on it as possible.

Being productive, on the other hand, is strategic. It's taking that same list of actions, and plucking the 2 or 3 things from it that really matter and focussing on them. The other items on the list are still there, waiting to be completed, but these 2 or 3 really matter and will have real impact.

We all have the same 24 hours in a day (yes, even insanely successful people like Robert Herjavec and Beyoncé), so it's crucial to focus on actions that give you the biggest "bang for your buck", allowing you to go from just being busy, to being productive.

So, how do we turn our chaotic task lists into lean, mean, productivity machines? Here are some methods I've found that work wonders for me:

Play the Consequence Game 🎭

Ask yourself, "What's the consequence if I don't do this?" The more severe the consequence, the higher the priority.
Who's Waiting on You? 🕰️

Consider who you might be holding up by not completing a task. If your delay is causing a bottleneck for others, bump that task up the list.
1 Rock, Many Birds 🪨
How many actions on your list can you complete with a single action? The more todos a single action can resolve, the more impact it can have. So it should be bumped up a priority level or two.
The Eisenhower Matrix ⊹
Ask yourself 2 questions for each task on your list. 1. Is this task urgent? 2. Is this task important? The items that are both urgent and important are likely high priority.
The A-E Method 🔠
Label each item in your list with only one letter, A - E where:
A = Something that's very import. It will have serious consequences if you do or don't do that thing.
B = Tasks you should do. These have light/mild consequences if you do or don't do them.
C = A task that would be nice to do, but there are no consequences if you do or don't do that thing.
D = Tasks you can (and probably should) delegate. Delegate tasks to others so you can focus on the tasks only You can do.
E = Tasks you can eliminate.

Remember, nothing gets accomplished without taking action. Action is the driving force that turns ideas and intentions into reality. However, here’s something important to keep in mind: when your actions are guided by thoughtful planning, you set yourself up for greater success. Good planning helps you clarify your goals, anticipate obstacles, and allocate your resources wisely. As a result, the actions you take are more focused, effective, and impactful—leading to better outcomes than action taken impulsively or without direction. In other words, while action is essential, action informed by solid planning is what truly maximizes your impact.

However, don't fall into the trap of over-planning. Too much planning is like too much salt – it ruins the dish. You have to find a balance between planning and doing.

So, there you have it! Now go forth and conquer those tasks that are going to impact your life the most! I'm off to work on a secret, super big project 😉 see you next week!

The Uncomfortable Truth: You'll Always Feel Behind in Software Development

Jake Lundberg — Tue, 15 Apr 2025 12:56:35 +0000

Let's face it: the world of software development is massive, and it's only getting bigger. With new tools, technologies, and languages emerging at Ludicrous Speed (where are the Spaceballs fans? ) – and AI accelerating this trend even further – it's easy to feel like you're constantly playing catch-up. But here's the truth of the matter: There is no catching up...you will always feel behind. And if you don't, don't worry...we all started somewhere.

No single person can learn it all. The field is simply too vast and evolving too rapidly. Some developers thrive on this constant change, relishing the opportunity to always have something new to learn. Others find themselves overwhelmed by the sheer volume of information to absorb. Some get frustrated and quit. And even worse, some people stop trying and just stick with what they currently know...calling it good enough.

So, what are you supposed to do in this ever-changing landscape? Here's your action plan:

Learn to Learn

It's not just about what you know; it's about how quickly and effectively you can acquire new knowledge. Build good learning habits. Figure out how you learn best, and then leverage that knowledge. Remember, everything is learnable – if you approach it the right way.

Focus on Your Goals

Don't let the hype train dictate your learning path. It's easy to get caught up in the latest buzzwords, but ask yourself: What am I actually trying to do? Focusing on your objectives will help you prioritize what you actually need to learn, rather than what's merely trendy.

Master the Fundamentals

Sure, shiny new tools are fun and make things easier, but do you actually understand what that toy is making easier? Be honest, could you do your job without them? I see a lot of people out there making things worse while using these tools simply because they didn't know the fundamentals. Take the time to learn the basics. Want to work with React? Learn JavaScript first. Interested in building AI models? Brush up on your math. Strong fundamentals will not only enhance your current work but also make it easier to adapt to whatever comes next.

Embrace Being a Generalist

Here's a liberating thought: You don't have to be an expert in everything. Get comfortable with experimenting and dabbling. Expose yourself to different technologies without the pressure of mastering them all. Being uncomfortable is a sign of growth – learn to embrace it.

Remember, the goal isn't to know everything; it's to be adaptable, curious, and resilient. The most successful developers aren't necessarily those who know the most, but those who can learn and apply new concepts quickly.

So, the next time you feel overwhelmed by the latest framework or programming language, take a deep breath. Remind yourself that feeling behind is part of the journey, not a reflection of your capabilities. Focus on building a solid foundation, stay aligned with your goals, and cultivate a love for learning.

In the world of software development, the only way to truly fall behind is to stop learning altogether. Embrace the discomfort and keep pushing forward.

Now, get back to coding, learning, and growing. The future of software development isn't waiting, and it needs developers who aren't afraid of feeling a little behind.