Building a Career That Fits Your Wiring

Dev Leader Weekly 142

Jun 01, 2026

TL; DR:

The list is infinite -- accept it and prioritize accordingly
Lean into the work that actually energizes how you’re wired
Pick the easiest task to break paralysis when overwhelmed
Join me for the live stream (or watch the recording) on Monday, June 1 at 7:00 PM Pacific!

ADHD, Burnout, and Building a Career That Fits Your Wiring

This week’s Reddit thread is from the ExperiencedDevs subreddit, and it asks a question that I think a lot of people quietly wonder about: if you have ADHD, anxiety, depression, or some combination of those things, do you feel “nerfed” compared to your colleagues?

I want to be careful with this one. I’m not lumping these together because I think they’re correlated. They’re not. They’re distinct things that show up very differently in different people. But the question is real, and I have my own answer for parts of it, so I want to walk through what I’ve actually learned -- specifically as it applies to engineering work -- rather than offer abstract reflections.

I’m also going to be upfront: I’ve been diagnosed with ADHD. I’ve gone through periods of depression at earlier points in my career. I don’t have an anxiety diagnosis. I’m not a doctor, I’m not telling you what to do, and the words I use here come from my lived experience as an engineer and engineering manager. Take what’s useful and leave the rest.

You can check out my full thoughts on this in the video below:

Where This Is Coming From

When I made my video response to this Reddit thread, I just wrapped a two-week on-call rotation. On paper, my on-call shift is only six hours a day, Sundays off. In practice, between the team I manage and some adjacent security work that doesn’t really respect rotation boundaries, I ended up putting in 12-hour days for stretches of it. I’d wake up at 5:30 AM, dismiss the notifications on my phone, realize a few of them were actual things I needed to deal with, and effectively start work right there in bed. By the time my actual on-call shift kicked in at noon, I’d already been at it for hours.

By the time it ended, I was cooked. Sunday night I’m sitting at my desk -- the time I’m supposed to be working on the things I genuinely enjoy -- and I’m just holding my head in my hands. Nothing left. My wife walks in and asks what’s going on, because she can see it.

That conversation is what kicked off the reflection that this article is built on. So fair warning: a lot of this is from the freshly-burnt-out version of me. But honestly, that version of me probably has more useful things to say about this than the rested version.

The Infinite List Problem

Here’s the thing I keep crashing into: my life is lists. Whether it’s a whiteboard, a notes app, a backlog, or just in my head, that’s how I keep track of what needs to happen. And the lists never stop growing.

For most engineers, this is just reality. There’s no shortage of work. AI hasn’t shrunk the list -- it has expanded what’s possible to ship, which means more things go on the list, not fewer. The total work to do is effectively indefinite. I’ve made this point in the broader context before, in the More Experience, More Overwhelmed issue. The more senior you get, the more the list grows and the less of it you can personally close out.

This becomes a specific kind of problem if you’re wired the way I am. My natural posture is “get through the list.” And when the list is mathematically impossible to ever finish, you’re essentially walking around in a perpetual low-grade state of failure. My wife actually surfaced this one and it landed hard: she said the reason I struggle with this is that I take a lot of pride in my work. So an infinite, never-empty list becomes a constant admission that something is incomplete. It’s a treadmill that doesn’t stop.

I don’t know if there’s a clean fix for that. I haven’t found one. But what I have found are tactics that take the edge off.

Actionable Tip -- A few things that have actually helped me operate inside the infinite-list reality:

Stop measuring success as “list empty.” Measure it as “right things done this week.” The shift is from completion to prioritization.
Have a visible “top 3 today” outside the master list. When the master list is overwhelming, working only off the top-3 view for the next few hours is sometimes the only way to start.
Pick the smallest task on the list when paralyzed. Yes, it’s the wrong task by priority. But the worst outcome when you’re frozen is doing nothing, and three small wins in 30 minutes often build the momentum to take on the big one.
Audit the list itself periodically. Things on the list for 90+ days that you’ve never started are probably never going to get started. They’re noise. Move them to a “maybe-later” file and stop letting them haunt the active backlog.

The Paralysis Trap

The thing nobody warned me about with an overflowing list is that the most intuitive response -- “I have so much to do, I better get moving” -- is actually the opposite of what often happens. The brain can flip in the other direction and just freeze. You sit there, totally aware of how much there is, completely unable to start any one specific thing.

This is the part that feels backwards. If you have ten things you need to do today, doing zero of them should be the absolute worst outcome. And yet, when the overwhelm hits, zero is exactly where you can end up.

My only reliable counter to this is going small. Not “the most important thing.” Not “the highest-leverage thing.” The easiest, fastest, get-it-off-the-list thing. Even if it’s tiny. Even if it doesn’t matter much. Once one item is checked off, the next one feels possible. Once a few are done, sometimes the big one suddenly stops feeling like a wall.

This is related to the broader context-switching pain I talked about in The Context Switching Problem Every Dev Faces. The same thing that makes context switching expensive for everyone is what makes the “start small to build momentum” trick work for me -- once my brain is engaged on something, the cost of starting the next thing drops.

The Chaos-Is-A-Superpower Thing

Reading through the Reddit thread, the comment pattern I found most interesting was people with ADHD saying, basically, “put me in the firefighting role. Don’t put me in the planning meetings. I want the chaos because chaos engages me.” And then a wave of replies going “this is me, this is exactly me.”

I read that and went, really? But the more I thought about it, the more it tracks for me too. Security incidents and on-call escalations are exhausting, but they’re not boring. There’s urgency, something concrete to chase, a problem with a real shape. I find that engaging in a way that long quiet planning blocks aren’t. That’s not a moral statement. It’s just how my brain reacts.

The actionable version of this is: pay attention to which kinds of engineering work actually energize you vs drain you, and don’t assume the conventional wisdom about “good work” matches your wiring. Some examples of pairs I’ve noticed for myself and people I’ve managed:

Deep architectural design vs. incident response -- both legitimate engineering. Some people light up at one, some at the other.
Greenfield builds vs. complex production debugging -- some engineers go after these very differently.
Long planning meetings vs. short focused syncs -- same content, different cognitive cost.
Solo deep work vs. mob/pair programming -- some people get energized by one and depleted by the other.

None of those are wrong. None of them mean you’re a worse engineer if one drains you. But if you ignore the pattern and structure your week around the work that depletes you, you’re going to burn out faster -- and you’re going to do it while assuming the burnout is your fault, when really it’s just a workload mismatched to your wiring.

Don’t Confuse Burnout With “Just Tired”

One of the things I had to learn the hard way is that burnout doesn’t always feel like sadness. Earlier in my career, before I really had vocabulary for any of this, I thought depression looked like obvious sadness. It doesn’t always. Sometimes it’s just emptiness, or paralysis, or the feeling of having nothing left to give to the things you normally love.

Right now I’m not depressed, but I’d be lying if I said I’m not carrying some of the same flavor of that from the on-call burnout. The signal I look for: am I sitting down to do the work I genuinely enjoy and still feeling like I can’t engage with it? When the answer is yes for more than a couple of days, that’s not “I’m tired.” That’s something I have to actually address with rest, not push through.

This is where the Should You Talk To Your Manager About Burnout? issue becomes relevant. The short version of my answer there is: yes, but with framing. Don’t go in with vague “I’m tired.” Go in with “here’s the pattern I’m seeing, here’s the impact, here’s what I think might help.” That conversation goes very differently from the vent.

The same point applies for promotion timing, by the way. I covered that in Promotions Without Burnout -- the pattern of grinding yourself into the ground to earn a promotion and then arriving at the new level with no fuel left is one of the most common career failure modes I see. If your wiring is already prone to overwhelm, that path is even more dangerous.

The Randomization-Absorption Move (Manager Perspective)

This one is specific to engineering managers, and I think it’s the part of this conversation I have the most conviction about.

I want my team focused. I want them not getting randomized constantly. I want them clear on priorities so they can make their own decisions without me being in the middle of every call. That’s just good engineering management, and I talk to my team about minimizing context switching for them all the time.

But here’s the part that took me a while to admit: for me to protect them from randomization, somebody has to absorb it. And often, that somebody is me. When a security incident hits during their focus time, I’d rather take the initial triage hit myself than yank three engineers off what they were doing. When a request comes in from another team that’s going to derail an afternoon, I’d rather have the meeting myself than route it to someone who’s mid-flow.

This isn’t scalable forever, and it’s not the only tactic. But when push comes to shove, if my job is to protect their focus, then absorbing some of the chaos is part of that job. Which means I have to be honest with myself about my own energy budget -- the same things I tell my engineers about not running themselves into the ground apply to me too.

The related caution here, and this one is for both ICs and managers, is the Hidden Cost of Being the Team Hero. Volunteering to absorb chaos is a service to the team -- but if you become the only one who absorbs it, you’re building a fragile system around your own bandwidth. That’s a separate problem worth being honest about. By absorbing the chaos, you’re ideally creating more opportunity for the rest of the team to move past situations where you need to be absorbing that kind of chaos -- that’s how you scale out of it.

So Are You Nerfed?

Back to the original Reddit question.

My honest answer: not nerfed, but mismatched in certain contexts. Engineering work is wildly varied. Some of it lines up with how my brain operates and some of it actively fights against it. The job is not to fix my brain to match the work. The job is to understand the wiring, lean into the work that energizes it, build coping mechanisms for the work that doesn’t, and -- as a manager -- design roles where the people I work with get to do more of the former and less of the latter.

Actionable Tip -- A short reflection exercise. Spend 10 minutes thinking through this:

Which two or three types of engineering work in the last 30 days made me lose track of time?
Which two or three left me drained even though they were short?
Is my current week structured more like the first list or the second?
If it’s the second, what’s one thing I could shift this week to get closer to the first?

You won’t be able to fully optimize this -- the job has what it has. But even a 20% shift toward work that fits your wiring tends to compound over months.

Final Thought

I don’t have a clean wrap-up for this one. I’m sharing because the Reddit thread was honest and I think it deserves honest engagement back. If you’re someone in this space -- whether that’s ADHD, anxiety, depression, or just chronic burnout that you haven’t named yet -- I’d rather you know that the patterns I’ve described are real, you’re not making them up, and there are tactics that help. They’re not magic. They take attention. But they might help you out in your situation.

And if you want to send me a more specific scenario you’re navigating, you can submit anonymously over at codecommute.com and I’ll try to make a video response. I find these conversations a lot more useful than the abstract “advice for software engineers” stuff -- so the more specific, the better.

Dev Leader Weekly

Discussion about this post

Ready for more?