TL; DR:

• Not knowing everything is completely normal

• Prove or disprove every hypothesis, then write it down

• Disproving is just as valuable as proving

• Join me for the live stream (or watch the recording) on Monday, June 22 at 7:00 PM Pacific!

Debugging When You Have No Idea What’s Going On

Something is on fire. A live service is doing something it absolutely should not be doing, the metrics look wrong, and you’re sitting there staring at it thinking: I genuinely have no idea what’s going on. If you’ve ever felt that creeping sense of shame in that moment -- like a “real” engineer would already know the answer -- I want to talk to you. Because that feeling is incredibly common, and it’s almost entirely self-inflicted.

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

The Shame of Not Knowing Is Almost Entirely Self-Inflicted

This whole topic came out of a post on the ExperiencedDevs subreddit. Someone framed it really honestly: it feels shameful as a software engineer when something is happening that you don’t understand, and you genuinely don’t know what’s going on or how to make progress on it. And I get it. I really do. But I want to say this as clearly as I can: that is completely okay, and it’s completely normal.

No one in the world expects you to know everything. They shouldn’t expect it, and honestly, they can’t expect it -- it’s not possible. Part of being an engineer isn’t having every answer in your back pocket. It’s being curious and working toward a better understanding when you don’t have the answer yet. A lot of this pressure is self-inflicted, and a lot of it is just software engineering culture. We tend to be a group of strong problem-solvers, so hitting a wall where we just don’t know is wildly uncomfortable. That discomfort is normal. It does not make you a bad engineer.

This is also one of the big reasons we build software in teams. If everyone on your team thought exactly the way you do, then the moment you got stuck, the entire team would be stuck right alongside you. Diversity of skill, experience, and perspective is a feature, not a nicety. A lot of the things I wish I understood earlier in my career come right back to exactly this.

Even Multiple Levels Up, We Don’t Always Have the Answer

I was recently talking with one of my engineers who was deep in a live site investigation. For context, the service area my team is responsible for in Microsoft 365 is... a bit outrageous. The sheer amount of traffic flowing through our systems makes it genuinely impossible for any single person to know every detail about everything. Should people on the team get better and better at investigating and understanding it over time? Absolutely -- that’s the whole game. But no single person knows everything all the time. The surface area is just too big.

So there we were, talking it through. A very sharp engineer, and me, several levels up -- and between the two of us, there was no obvious answer. In that moment, as a manager, part of me felt that same pull: man, I wish I just had the answer in my head. But my boss doesn’t expect me to know everything. My skip level doesn’t expect me to know everything. We have to make space for that. If your goal is to never be in a situation where you don’t know the next step, you’re going to fail at that goal. You will end up there. And that’s fine, because what actually matters is that you try to make progress.

If you’ve ever been on the receiving end of someone expecting you to instantly understand everything, this rant about “junior developers who just don’t get it” digs into that expectations mismatch between experience levels.

My Framework: If You Can Prove It or Disprove It, Write It Down

Okay, so with all of that out of the way -- how do I actually approach a problem when I have no idea what’s going on?

Here’s the core of it: most people treat problem-solving as proving a hypothesis right. I treat it as building a matrix of what’s known fact versus what’s still assumption.

When most people debug, they form a hypothesis, go chase it, and if it turns out to be right, great -- they keep progressing. But if it turns out to be wrong, it gets quietly dismissed as wasted effort. “We thought it might be this, we looked into it, it wasn’t, so we got nowhere.” I want to push back on that hard. Disproving something is just as valuable as proving it.

So whenever I can prove a statement true or false -- by reproducing something, by reading through the code, by finding a log that contradicts the theory -- I write it down. On a whiteboard, in a shared doc, wherever the team can see it. Back when we worked more in person, I used to fill entire whiteboards with assumptions, each one marked as proven or disproven. The magic of this is that none of the investigation is wasted. Every hypothesis you resolve, in either direction, shrinks the unknown. While something stays an assumption, it’s a live question hanging over the whole investigation. The goal is to keep converting assumptions into facts.

For the C# side of actually getting useful signal out of failures, I’ve got a guide on handling exceptions in a way that streamlines debugging. For everything else: Build out your matrix of assumptions. Validate them.

There Are No Stupid Hypotheses

One of my favorite side effects of this approach: there are no dumb ideas. When nobody knows what’s going on, someone will eventually say, “This is going to sound kind of crazy, but... could it be something with the operating system?” And the room groans -- “come on, the OS is the last thing that’s going to have a problem.”

But... maybe it is? If you can’t state as a matter of fact that it isn’t, then it’s an assumption, and it’s completely valid to go prove or disprove. Across thousands of machines, could there be something off with a specific OS version in a specific scenario? One hundred percent. Is it common? Nope. Is it possible? Absolutely. So write it down and go check. Often the “crazy” hypothesis is exactly the one worth checking, because it’s the last thing anyone would have looked at -- and you already admitted you don’t know what’s going on.

Watch the Correlations Emerge

Here’s where it gets genuinely satisfying. Once you start turning assumptions into proven facts, patterns start to surface that you couldn’t see before.

You check the OS angle: “Nope, we see it across versions X and Y, so it’s not the operating system.” Fine, that’s a fact now. What about hardware? “We see it on configurations A and B, but not C... so C is still open, but A and B definitely reproduce it.” Now you’re not holding a pile of vague guesses in your head -- you’re drawing a map. And when you lay those proven facts side by side, you might suddenly notice: wait, we only ever see this on these specific combinations. Only this software version. Only this region. Only this traffic pattern.

That’s the moment the investigation stops being vibes and starts being data-driven. You go from “I don’t know, so let’s just guess” into actual experimentation, and then into higher-level correlations between signals you’ve proven are real. For live systems, this is also where good observability and telemetry earns its keep -- the more real signal you’ve instrumented, the faster those correlations show up.

And a bonus point here: get comfortable with AI and MCP servers. Being able to rely on an LLM to pull data and help you correlate it is SIGNIFICANTLY more effective than you being in the weeds just trying to pull the actual data. Let it do the boring work so you can use your brain for what’s more valuable.

Where This Came From: Debugging With Almost No Information

This framework actually goes back to my digital forensics days. The software we built essentially scanned devices -- mostly hard drives at the time -- and turned the data into a structured report so an investigator looking for digital evidence had something readable to work through. Think of it as a giant search engine plus an interactive dashboard.

Here’s the brutal part for debugging: because this was forensics, the data on those devices was highly sensitive material tied to active criminal cases, and a lot of it legally could not be copied or reproduced. So the usual “just send me a repro” was frequently off the table. On top of that, many of these workstations were often air-gapped by design. So when something broke, you might get a terse “it doesn’t work” and maybe a log file -- and you’d better hope there was something obvious in the stack trace, because a lot of the time there wasn’t.

When you’re debugging with limited information and no ability to reproduce the problem, you cannot afford to waste effort chasing hypotheses you’ve already implicitly ruled out. That constraint is exactly what forged this prove-or-disprove habit. It’s the same energy as untangling a gnarly dependency injection debugging nightmare -- you methodically eliminate possibilities until the real cause has nowhere left to hide.

And yes -- afterward, always reflect: if this happened again, could we add better logging, telemetry, or monitoring to catch it faster next time? That follow-up is worth doing every single time. It just usually doesn’t help you in the heat of the moment, so treat it as a separate step.

The Keys Are in Your Hand

One last thing. Sometimes the reason you’re stuck is an assumption you never bothered to prove because it seemed too obvious to check. “Why would I look at that? It’s obviously not the problem.” But did you actually prove it?

It’s like tearing the house apart looking for your keys while they’re in your hand the whole time. I did this constantly as a kid building LEGO -- convinced they forgot to include the one piece I needed, when it was the next piece in the instructions, sitting right in my hand. Investigations have the exact same trap. The thing you “know” is fine is sometimes the very thing that’s broken.

You’re Not a Bad Engineer for Not Knowing

So if you take one thing from this issue, let it be this: you are not a bad engineer because you don’t know the next step. Don’t let the shame paralyze you. Accept that not knowing everything is completely normal -- it has to be, because no one can possibly know everything. The point isn’t to have the answer instantly. The point is to get curious, start writing down hypotheses, and start proving or disproving them one at a time. If you stay curious and keep exploring the problem space, you’ll keep making progress. And that’s all any of us can really ask for.

If you’ve got questions about software engineering or career development, drop them in the comments or head over to CodeCommute.com and write in anonymously. I’m always happy to make a response and share a perspective if it helps.

Leave a comment

Share

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Decision-makers are detached from your code

• “The code is a mess” never wins

• Reframe tech debt as future velocity

• Join me for the live stream (or watch the recording) on Monday, June 15 at 7:00 PM Pacific!

How to Get Tech Debt Prioritized

This week’s topic comes from a post on the ExperiencedDevs subreddit. A developer was asking for perspective on getting their manager to prioritize tech debt. It used to get prioritized, they said, but lately their manager keeps pushing back because the team needs to deliver features. If you’ve been writing software for any length of time, you know this one -- the age-old battle between shipping more things and making the code better. And if you haven’t hit it yet, it’s probably just about to happen.

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

This Is a Prioritization Problem, Not a Code Problem

The first thing I want to get out of the way is that this is genuinely tricky, and it’s tricky because it isn’t really one problem. It’s a prioritization problem, a communication problem, and a perspective problem all bundled together. If you’re more junior and this is happening to you for the first time, it’s easy to feel confused and frustrated by it -- like you’re clearly right and nobody will listen. So it’s worth slowing down and understanding what’s actually going on underneath.

Tech debt almost always accumulates the same way: a few things stack up, and whoever owns prioritization -- a product owner, an engineering manager, some combination of those roles -- has to make a call. And the more removed those people are from the code, the less direct understanding they have of how specific areas of the codebase affect your ability to ship. I don’t mean that conceptually. I mean very specifically: they are not going to know that this class or that module is the thing slowing you down, because they’re not spending time in there.

I’ll be honest about my own seat here, because it’s relevant. I’m an engineering manager at Microsoft -- I’ve been there just under six years, and I’ve been programming for over 20 years. But in my role, I don’t write code. It’s not that I’m not allowed to; it’s that there are enough other things I’m responsible for that it doesn’t make sense for me to spend my time there. So there are absolutely situations where I am simply not aware of where the tech debt is. I have to rely on and trust my team to bring it up. And when they do, I expect them to be able to articulate why it matters. That last part is the whole ballgame, and we’ll come back to it.

The Two Forces Working Against You

When you zoom out, there are two big forces shaping these conversations from the prioritizer’s side.

The first is constant pressure to deliver more, often with less. Before Microsoft, I was at a startup, and there it was a never-ending stream of “how do we get more things done?” There’s truly an infinite amount of work, and a lot of it feels like strategic bets -- things you’re not certain about but believe you have to try. At a big company, it’s a different flavor of the same thing: less uncertainty per bet, but a massive surface area of teams all pushing their own initiatives. Either way, the pressure is “more, faster.” I went deep on how that infinite pile grows as you get more senior in More Experience, More Overwhelmed.

Layer on the current climate -- hiring slowing down, teams shrinking, and the “we made a strategic pivot to AI, so where’s the 10x productivity?” expectation -- and the “do more with fewer people” drumbeat gets even louder. I hear this constantly: leadership bet on AI, and they’re relying on the people building things to show the return.

The second force is detachment from specific areas of the code, which we already talked about. Put those two together -- relentless delivery pressure plus distance from the codebase -- and you have the exact conditions where tech debt loses. Not because anyone is stupid or malicious, but because the people deciding are focused on shipping value to customers, and you’re handing them an argument about classes and methods.

Subscribe now

How the Debt Actually Piles Up

Let me walk through the mechanism, because it’s so common it’s almost mechanical.

Say you want to build feature A in a one or two week window. The north star design is “do X, then Y, then Z.” If you did all of it properly, it might take a month or two. But you look at the window and go: we can definitely get X done, we’ll get partway into Y, maybe finish it with a tweak, and we will not get to Z. But that’s fine -- we’ll ship A on time and come back for Z next sprint.

So you ship. You got X, part of Y, and no Z. The feature works. You’re now in an intermediate state with a bit of debt baked in -- and then the question comes: what’s more important, the next batch of customer value, or going back to finish Z? If the feature already shipped and already works, finishing Z is almost never the higher-value option. If Z had been truly necessary, it would have blocked the release in the first place.

Now multiply that by every feature your team ships -- two, three, five, six of these at once -- and you can see how you just keep bleeding debt. I genuinely believe nearly every line of code we write is debt to some degree, but here I mean the specific, visible gaps you know you left because you took a shortcut to hit a date. And I don’t mean “shortcut” as an insult -- it’s often not “oh my god I can’t believe I wrote that.” It’s just “we didn’t get the full thing done, the feature works, and what’s left isn’t visible to the customer.” The frustration is that it keeps happening, sprint after sprint, and that constant churn is its own kind of tax -- closely related to the productivity drain I covered in The Context Switching Problem Every Dev Faces.

Why “The Code Is a Mess” Never Wins

Here’s where most engineers shoot themselves in the foot. The argument they bring sounds like: “As a software engineer, I think we should focus on this. Here’s why.” And every reason is about the code -- this class is convoluted, we hate touching this module, we want to refactor for cleanliness.

Now put yourself in the prioritizer’s chair. They’re weighing “spend a week rewriting some classes” against “fix these three critical customer-reported bugs and ship these two features the sales team can use to chase five new customers.” Why would they pick the cleanup? The framing was lost before the conversation even started, because it was built entirely around things they don’t focus on and can’t easily evaluate.

It’s almost like you’re set up to automatically lose. And that’s a genuinely lousy spot -- being forced to pit your tech debt against visible customer value, using the one language the other side doesn’t speak.

Actionable Tip -- Before you pitch tech debt, run it through this filter: strip out every reason that’s about the code itself, and see what’s left. If there’s nothing left, you don’t have a business case yet -- you have a preference. Keep digging until you can express the cost in terms of delivery, bugs, or time.

Reframe It in the Language of the Business

The move is to translate. Instead of “this code is a mess,” make it about speed, risk, and waste on the work they already care about.

Concretely, it sounds more like this: “This isn’t some legacy file we haven’t touched in four years and never will. We are actively in here right now. Two of the bugs this sprint are in this exact code, and we keep breaking it because it’s convoluted and we can’t test it effectively. If we slow down for a week and clean it up, the two features you want next -- which we already know live in this same area -- get easier. They’ll take half the time going forward, and we’ll stop bleeding these recurring bugs.”

See the difference? You’ve connected the cleanup to future velocity, reduced bugs, and less wasted time -- and you’ve anchored it to specific upcoming work the prioritizer has already hinted at. You’re not asking them to value clean code. You’re showing them how the debt is actively taxing the roadmap they care about. That’s the same spirit as deciding to talk to your manager about burnout -- don’t lead with the vent, lead with the pattern, the impact, and what would actually help.

The more you can express tech debt as “this will speed us up on related work” or “this will stop these bugs that are clearly hurting our velocity,” the better your odds. “The code is a mess” is a feeling. “This is costing us two bugs a sprint and doubling the time on the next three features in this area” is a business case.

The Manager’s Side of the Table

I want to address the manager dynamic too, because the original poster felt their manager was the obstacle. From where I sit, an engineering manager carries real responsibility not to turn the business’s delivery pressure into a crippling weight on the team. A good manager absorbs a lot of that and provides some shelter -- not by hiding it entirely (the team should understand the context), but by refusing to amplify it. Amplifying pressure isn’t productive and it isn’t helpful.

That shielding role is exactly what I dug into in The Management Trap in Software Engineering -- a lot of management is absorbing chaos so your team can stay focused. But there’s a real risk in being the person who soaks up everything, which I broke down in The Hidden Cost of Being the Team Hero. The point for you as the engineer: your manager is very likely getting this pressure from above, and your job in that conversation is to make it easy for them to advocate for the cleanup to their stakeholders. Hand them the business case, not the complaint.

The Hard Truth: Some of It Will Never Get Done

I’ll close with the uncomfortable part, because pretending otherwise doesn’t help anyone. My entire job is prioritizing things, and at the end of the day you have to accept that some things simply will not get done. There is an infinite amount of work -- I have business-critical features to ship for my teams before you even get to tech debt or bug fixes -- and it is quite literally impossible to do all of it.

That means some of the stuff you talked about, planned, and said “oh, we’ll get to it” about may genuinely never happen. And honestly? That can be completely fine in the end. The skill isn’t getting everything done; it’s relentlessly ordering things by value and working through them, accepting that the bottom of the list might never come up. If that constant triage is wearing you down, you’re not alone -- I wrote about that exact feeling in ADHD, Burnout, and Building a Career That Fits Your Wiring.

So find the opportunities to bring tech debt up, and organize them from the perspective of the person doing the prioritization. What will make it clear to them why it’s valuable? That means framing it around value to them -- not value to you. It’s a frustrating thing to navigate, but reframing your perspective makes it a whole lot easier.

If you’ve got a specific situation you’re wrestling with, you can submit it anonymously over at codecommute.com and I’ll try to make a video response.

Leave a comment

Share

Subscribe now

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Management is a different job, not a promotion

• Not all context switching drains you equally

• Absorb your team’s chaos -- but keep it temporary

• Join me for the live stream (or watch the recording) on Monday, June 8 at 7:00 PM Pacific!

The Management Trap in Software Engineering

This week’s topic comes from a post on the ExperiencedDevs subreddit titled “the management trap.” An engineering manager was reflecting on their career progression and how they’d arrived at a particular realization: they’re missing a lot of the joy -- that deep, hyperfocused, heads-down work they used to get as an individual contributor. As someone who has been a frontline engineering manager for over thirteen years, this one hit close to home, and I want to walk through my honest take on it.

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

Where This One Is Coming From

I want to set the stage a bit, because context matters here. This isn’t a tiny startup with ten people on a single team -- it sounds like this person is in a larger organization. A lot of what they describe about how their time gets spent is the side effect of scale: cross-team coordination, headcount planning, all of that. That stuff exists in small companies too, but the amount of time, effort, and focus it demands varies dramatically based on the size and the stage of the company.

The other detail that stood out to me is that this person is a frontline manager. They mentioned that a senior manager promotion has been talked about but never quite materializes. That resonates with me, because I’ve been a frontline manager for about thirteen and a half years now. Before Microsoft, I was at a smaller company where a director role was on the table -- but that was five and a half years ago. So when someone says they’ve been sitting in the frontline manager seat for a long stretch, watching the “next step” stay perpetually one conversation away, I get it.

And here’s the honest tension in their post: it’s not that they hate management. They explicitly said they get genuine enjoyment out of helping people with career progression, promotions, and growth. That part lights them up. But when they zoom out and look at their day-to-day, it feels chaotic -- scattered, sporadic, a lot of context switching -- and they miss the ability to just sink into one hard problem and feel like they’re making real progress on it.

Management Is a Different Job -- Not a Better or Worse One

If there’s one thing I want you to take from this issue, it’s this: a management role is not the same as an IC role, and that difference does not make it better or worse. It’s just different.

That sounds obvious written down, but I don’t think it actually lands for most people until they’ve lived both sides. Engineering management is its own discipline within software engineering -- the same way a product manager or a project manager is something distinct within software engineering. It’s not “senior engineer, but with more authority.” The work itself changes shape.

A lot of people hit a point in their career where the promotion that’s offered to them is a management position. And that can be fantastic -- you might love it, it might fit you perfectly. But I’d urge you to understand what managers should actually be spending their time and focus on before you assume it’s just the natural next rung on the ladder. I went deep on this in I Wish I Knew THESE Before Becoming A Manager, and a lot of it comes down to expectations nobody sets for you up front.

Not All Context Switching Costs the Same

Here’s a nuance I don’t think gets talked about enough. The Reddit thread frames the chaos as the problem -- too much context switching, not enough hyperfocus. And I get that. But when I reflect on my own experience, it’s not the context switching itself that wrecks me. It’s context switching into work that doesn’t engage me.

Let me give you a concrete contrast. When I’m working on security-related problems, there’s often a ton of context switching, and it can get genuinely chaotic. But I don’t walk away from it feeling burnt out, because that work excites me. Jumping in to help one of my engineers work through a gnarly technical challenge? That can be energizing, even though it’s an interruption. On the flip side, sitting down with focused, prepared time to work through interpersonal challenges or career progression with someone -- that feels good. But being rapidly context-switched into that same kind of work, with no runway, is incredibly taxing for me.

So it’s often not even the nature of the task that determines the cost. It’s how much context and preparation I have going into it. I talked about a closely related version of this in last week’s issue on ADHD, burnout, and building a career that fits your wiring, and the mechanics of why switching is so expensive in the first place in The Context Switching Problem Every Dev Faces.

Actionable Tip -- If you feel perpetually drained by your week, don’t just count your context switches. Audit what you’re switching into:

• Which interruptions leave you energized, and which leave you hollow?

• How much of the draining stuff is draining because of the task itself vs because you had zero preparation for it?

• Can you batch the low-context, high-cost work into a window where you’re actually braced for it, instead of letting it ambush your focus blocks?

The Part of Management I Actually Believe In

This is the piece of the conversation I have the most conviction about. I genuinely believe that to be effective as an engineering manager, my job is to enable my team to do their best possible work.

In the short-to-medium term, that often means I have to be the one who gets randomized so that they don’t. When chaos comes in -- an urgent org-wide ask, an incident, a security fire -- I’d rather absorb the initial hit myself than yank three engineers out of their flow. I sometimes describe this as shielding or sheltering the team, and I want to be clear about what I mean: not hiding things from them, but removing distractions so they can stay locked on the work that actually moves us forward.

But absorbing chaos is only a good strategy if it’s accruing to something. Here’s my litmus test: from a pure operations standpoint, I feel successful in my role if I could walk away and my team could keep running entirely on their own. That sounds almost paradoxical -- like I’m saying my goal is to not be needed. From a career-growth standpoint that’s obviously not the whole picture, because I’m here to help every one of them grow. But operationally, the target is a team that doesn’t depend on me to function. I dug into this idea of self-sufficient, autonomous teams in Effective Software Teams: Islands and Autonomy.

The real trap -- and in my opinion this is the actual trap, more than the “I miss being an IC” framing -- is when the chaos I’m absorbing isn’t moving us toward that self-sufficiency. If I’m just perpetually soaking up randomization with no end state where the team gets more autonomous, that’s not sustainable. It’s supposed to be temporary. Take the chaos, let the team build the processes, services, and tools that make us stronger, and then we don’t need me in that spot anymore -- and we move on to the next frontier together. The flip side of this is a real risk worth naming: if you become the only person who ever absorbs the chaos, you’ve built a fragile system around your own bandwidth, which is exactly the failure mode I broke down in The Hidden Cost of Being the Team Hero.

Fan-Out Work Is the Most Unscalable Thing I’ve Seen

Let me give you the specific pattern that’s been on my mind, because it’s the clearest example of chaos that doesn’t accrue to anything good. I’ve been trying to make more noise about it lately: fan-out work.

We’re a platform team in a large organization. Because the surface area is enormous, what happens constantly is that some team owns a thing, a change lands, and the message goes out: “everyone needs to go make this change.” The work fans out to dozens of teams. And it’s not one team doing this -- it’s multiple teams all fanning work out to each other simultaneously.

In my opinion, this is one of the most inefficient, productivity-destroying patterns you can possibly have. And I want to be careful here -- I’m not saying the work isn’t important. I’m not saying we shouldn’t help. I’m saying it is, by a wide margin, the most disruptive kind of work I’ve encountered in my software engineering career. The randomization it injects across an entire org is brutal.

This is where being a manager means more than just personally absorbing hits. If I notice that fan-out work is a recurring theme, I owe it to my team to push back to the broader organization and say, “something has to change here.” That doesn’t mean I’ll have the solution in hand. But if I’m going to make noise about a problem, I need to volunteer to be part of building the fix -- not just complain about it.

Systematize the Interruptions Instead of Just Absorbing Them

There’s an older example I come back to a lot. Back in my startup days, the CTO and founder would come by and say, “this is urgent, we have to do it now.” Especially in the early days, we’d drop everything and get completely randomized. I’d try to step in and shelter the team from it, but over time we landed on something better -- a kind of unwritten contract.

When we got approached that way, the new default became: we don’t just drop everything. We talk about it. We’d explain what we were currently working on, give visibility into the tradeoff, and then if the answer was still “yes, I genuinely think you should drop that other thing,” at least it was a conscious decision made with full context -- not a reflex.

That shift, from reflexive interruption to a deliberate, systematized filter, was hugely important. The team was almost always working on things that made us more effective in the long run, so being able to push back and force the interruption to justify itself protected the work that mattered.

Actionable Tip -- If your team is constantly randomized by “urgent” asks, build a lightweight filter instead of absorbing each one in the moment:

• Make the current priorities visible, so any new ask has to be weighed against something concrete.

• Push the interruption to be an explicit decision: “we can do that, but it displaces X -- is that the call you want to make?”

• Capture recurring interruption types (like fan-out work) and treat the pattern itself as a problem to solve, not just each instance.

Firefighting vs Getting Ahead of the Fire

The other balance I’m constantly trying to strike: how much energy goes into firefighting for the team, versus getting ahead of the fires so they don’t start? When I’m spending all my time absorbing the chaos of the moment, I have nothing left to invest in preventing the next wave of it. And the fires my team isn’t directly working to put out -- those are exactly the ones I need to find capacity to address myself.

I’ll be honest about a compounding factor here, too. When I’m running multiple teams and I don’t feel like I have enough capacity on each one, that’s a huge contributor to exactly the scattered, randomized feeling the Reddit poster described. Fewer people to rely on means I have to context-switch even more. I have genuinely amazing people on my teams -- just fewer of them than I’d want to sustain everything without me jumping into the gaps. That’s nobody’s fault. It’s mostly the side effect of organizational growth, and it’s something I covered from the IC angle in More Experience, More Overwhelmed.

If Management Is the Promotion In Front of You

So let me bring this back to where the Reddit poster started. They framed it as a trap for managers -- losing the ability to hyperfocus the way they could as an IC. And honestly? I do miss some of that. But I’ve also found that I get a lot of that deep-focus satisfaction outside of work, and I genuinely enjoy it there.

The answer is going to be different for everyone, and that’s exactly the point. As you move up, the hands-on, heads-down portion of the job tends to shrink -- I talked about that reality in Senior Engineers Spend Less Time Coding. Management accelerates that shift even further. So if a management promotion is the thing being offered to you, don’t take it just because it’s labeled “the next level.” Understand that you’re signing up for a fundamentally different job -- one with friction coming at you from multiple directions, where success looks less like “I shipped this” and more like “my team shipped this without needing me.”

If that trade excites you, management can be incredibly rewarding. If the thing you love most is the deep technical flow, go in with your eyes open that you’re trading away a lot of it -- and know that there may be other ways to grow that keep you closer to it.

Final Thought

I’ll admit this one is a bit all over the place, because the topic genuinely is. The “management trap” isn’t really a trap in the sense of a mistake you fall into. It’s just the reality that management is a different role, with different rewards and different costs, and a lot of people step into it without anyone being honest with them about that tradeoff.

If you’re weighing this in your own career -- or you’re already in the seat and feeling the scatter -- I hope this gave you a more useful frame than “management good” or “management bad.”

And if you’ve got a specific situation you’re navigating, you can submit it anonymously over at codecommute.com, and I’ll try to make a video response.

Share

Leave a comment

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

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.

Share

Leave a comment

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• When your ideas always get shut down, it’s rarely the ideas

• How you pitch them is the lever you actually control

• Genuine curiosity beats trying to win the argument

• Join me for the live stream (or watch the recording) on Monday, May 25 at 7:00 PM Pacific!

Why Your Ideas Keep Getting Shut Down

Another week, another ExperiencedDevs Reddit post that hit me a little harder than most. This time it was from someone who’s just exhausted from speaking up. They keep proposing ideas, the team keeps ignoring them, and they’ve reached the “why am I even bothering” stage. You can feel the defeat coming through the screen. That’s a pretty rough place to be in your job -- and it’s the kind of thing I think about a lot from the manager side too, because I genuinely need the people on my teams to feel like they can speak up.

But after digging through their post and the comments, I think most of the advice flying around misses the real lever. So let me walk through how I’d actually approach this if it were happening to me.

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

The Reddit Post That Got Me Thinking

The post itself doesn’t give a ton of context. The poster says they’re experienced on the team but not the tech lead, and they keep getting shut down when they propose ideas -- particularly around scoping and design. They feel like people are over-engineering or building things that don’t need to exist. The main concrete example they gave: their team wants to support multiple file formats when, in their view, the system only needs CSV.

That’s basically all we get. So I’m going to do what I usually have to do with these threads -- make some assumptions, walk through the most likely scenarios, and try to be useful even with incomplete information. If you’ve been here before, this is similar to how I worked through the post from someone telling their manager they were burnt out -- there’s only ever one side of the story, and you have to read between the lines a bit.

It’s Probably Not Your Ideas

Here’s the assumption I’m going to start with: statistically, this person doesn’t always have bad ideas. Nobody has only bad ideas. Some are going to be good, some are going to be okay, some are going to be off-base. That’s true for me, that’s true for you, and that’s true for the Reddit poster.

So if their ideas are being consistently rejected -- not occasionally, not in specific scenarios, but constantly -- the most likely explanation isn’t that the ideas themselves are uniformly bad. It’s much more likely that the way the ideas are being pitched is the problem.

I’ll use the file format example to walk through this. Imagine you’re in a design discussion and someone proposes supporting five file formats. You think it’s wasteful and unnecessary. You speak up:

“We don’t need that. That’s a waste of time.”

Now, you might be completely right. Maybe the team really doesn’t need it. But how does that land on the person who proposed it? They’ve now had their idea bluntly shut down with no engagement and no follow-up. They’re going to defend their position. The room is going to side with whoever feels more reasonable and can make a better case for their perspective. And you just lost a conversation you were trying to win.

I see this pattern a lot, and it shows up the worst in technical design debates where the answer genuinely isn’t clear-cut. I wrote about a perfect example of that recently in the Feature Slicing vs Clean Architecture comparison -- both are defensible, both have tradeoffs, and the “right” answer is contextual. If you come into that kind of debate with your mind already made up, you’re going to get rolled by whoever is willing to actually engage with the tradeoffs.

Try Genuine Curiosity Instead

The single biggest change I’d suggest if you keep getting shut down: lead with genuine curiosity, not your conclusion.

Same file format scenario. Someone proposes five formats. Instead of “we don’t need that,” try:

“Interesting -- what’s driving the need for the extra formats? Is this coming from customer requests, or is it more anticipatory?”

What does that buy you? Information you didn’t have before. Maybe they had a conversation with the product owner that you weren’t in. Maybe they’ve seen customer support tickets you haven’t seen. Maybe they’re just optimizing for “we’ll need flexibility later” with no real data behind it. You don’t know until you ask.

Actionable Tip -- A genuinely curious question has a few properties:

• It assumes the other person has a reason that makes sense from their seat

• It is asked before you’ve reached a verdict, not after

• It is phrased as a question, not a leading statement (”Why do we need this?” is leading. “What’s driving the need?” is curious.)

• You actually listen to the answer and let it change your position if the new information warrants it

And this last point is the one most people skip. If you ask a curious question, get new information, and still don’t even reconsider your position -- you weren’t being curious. You were performing curiosity to look open-minded before reasserting your original take. People can feel the difference.

The Goal Isn’t To Be Right

This sounds funny to say but, it’s the part that flips everything: the goal isn’t to win the argument. The goal is to deliver more value to your customers. Those are very different goals, and they pull you in very different directions.

If you’re optimizing to win the argument, you go in hard, shut things down, and protect your position. If you’re optimizing to deliver value, you go in curious, learn what the other side is actually optimizing for, and look for compromises.

In the file format example, that might look like:

“Personally, I don’t think shipping five formats is worth the time right now -- but I hear that flexibility matters to you. What if we shipped with the main format, but we put a thin abstraction over the file I/O so adding a second format later is a small change instead of a rewrite?”

Now you’re proposing a middle path that addresses both concerns. You’re optimizing for time. They’re optimizing for flexibility. The abstraction layer gives you both -- maybe. Now, my contrived solution might absolutely be the wrong move in some real scenarios. Sometimes the abstraction is more cost than the optionality is worth. The point isn’t that I cracked the technical answer in two paragraphs. The point is that the conversation is now productive instead of adversarial.

And from a team-dynamics perspective, this is the kind of behavior that builds trust over time. I wrote about this dynamic in the Effective Software Teams: Islands and Autonomy issue -- teams that work well aren’t the ones where one person is always right. They’re the ones where people actually engage with each other’s ideas.

When You Always Feel Unheard

If you keep walking out of meetings feeling like nobody listens to you, there are two scenarios I generally see:

1. Most of the time, you’re communicating in a way that’s getting in your own way. Your ideas might be great, but they’re landing as attacks, as shutdowns, or as “I’ve already decided and I’m now just informing you.” Fix the delivery and a lot of this changes.

2. Sometimes, the team really isn’t a fit. You can have the cleanest communication style in the world and still be on a team where people genuinely don’t want to listen. I covered the version of this where it’s specifically your manager who won’t engage in the issue on managers who refuse to give feedback -- that one has a different solution path.

The honest answer is that it’s almost always some mix of both. Some of it is on you, some of it is on the environment. The part you control is your delivery. Start there.

Actionable Tip -- Before you bring something up next time, ask yourself:

• Am I going in trying to be heard, or trying to be right? Those produce very different conversations.

• Have I actually asked the other side why they want what they want? Or am I just waiting for my turn to argue?

• If I’m wrong, am I prepared to actually update my view? If not, the curiosity isn’t real.

• Is there a middle path I haven’t proposed yet? Most “either/or” debates have a “both” answer hiding in them.

Don’t Give Up On Speaking Up

The thing I really don’t want anyone to take away from a Reddit thread like this is “well, I guess I’ll just stop speaking up.” That’s the worst possible outcome. As a manager, the people who quietly disengage are the hardest to help -- I can’t address what I can’t see. And as a teammate, that voice going silent makes the whole team worse.

There’s also a flavor of this where the person who keeps speaking up ends up shouldering everything because nobody else volunteers. That has its own downstream cost, and I dug into it in The Hidden Cost of Being the Team Hero. The fix isn’t “speak up less.” The fix is “speak up smarter, and don’t carry the team on your back while you do it.”

If you’re in this spot right now, please don’t give up on it. Try the curiosity angle for a few weeks. Try the middle-path framing. Pay attention to whether the conversations start landing differently. If they do, that’s your answer about what was actually going on. And if they don’t -- after you’ve genuinely changed your approach -- then yeah, you might be on a team that’s never going to hear you, and that’s a different conversation entirely.

Share

Leave a comment

Subscribe now

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Reddit’s “just quit your manager” advice misses the nuance

• The real question is how much you actually care

• Level-set expectations in your 1:1s or stay frustrated

• Join me for the live stream (or watch the recording) on Monday, May 18 at 7:00 PM Pacific!

When Reddit Says Quit Your Manager

I came across a post over on the ExperiencedDevs subreddit where someone was venting about their manager. The usual stuff: incompetent, doesn’t really understand basic software things (the poster mentioned the manager doesn’t seem to know what Git is or what it’s used for), pulls people into endless pointless meetings where nothing gets decided, and ignores everything that comes up in 1:1s. The poster also mentioned this isn’t a one-off -- there are apparently three managers like this on their team. They wrapped it up by saying they’ve started interviewing and asked what else they could do.

The overwhelming response in the comments was exactly what you’d expect: “You don’t quit companies, you quit managers. Get out. Stop wasting your time.” And honestly, I don’t disagree with that as a general principle. But I also don’t love how black-and-white it ends up being when that’s the only advice anyone offers. So I want to walk through where I agree, where I push back, and the questions I think actually matter when you’re in this situation.

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

Where Reddit Is Probably Right

Let me get this out of the way first: a manager’s influence on your career is significant. I’ve been doing this long enough to see the inverse play out plenty of times. There are places I’ve worked where the company was great, the product was great, the people were great -- and a single manager change either elevated the experience or absolutely tanked it. I’ve never personally worked somewhere I thought, “Man, this company is garbage, but thank god I have a great manager.” That just doesn’t happen for me. But I’ve absolutely worked somewhere good and had a manager pull the whole thing down.

So the Reddit answer -- “your manager matters more than the company brand on your business card” -- I actually believe that. And for most people, in most situations, the “start interviewing” advice is probably the right move. Especially if you’re already burnt out and resentful, the amount of energy needed to drive change is energy you probably don’t have. That’s not a moral failing. That’s just reality.

Where I Start To Push Back

What bugs me is the binary on/off framing. Always jump ship. Never try to fix it. If everyone in a thread is piling on with the same advice, my instinct is to share the other angle -- because someone reading that thread might actually be in a different scenario where the right answer isn’t “leave.”

Let me exaggerate to make the point. Imagine you genuinely love the company. You believe in the product, you love your peers, you’ve been there long enough to have helped build the thing, and the opportunity in front of you is real. Then a new manager gets dropped above you and they’re just... not good. You can have bad hires at every level -- engineers, product managers, EMs, VPs, C-suite. People who interviewed great and turn out to be a disaster in practice. The decision-makers above don’t always see it, because the chaos doesn’t bubble up the way the interview signal did.

In that scenario, “just leave” is leaving a lot of value on the table. I’ve had moments in my career where a bad manager situation would have been the easiest excuse to jump, and I’m glad I didn’t. I worked through it, found ways around it, escalated where it made sense, and the long-term outcome was better than running. That’s not me saying I made the perfect choice every time -- I’m just saying that if “leave at the first sign of friction” had been my default, I wouldn’t be where I am today.

For more on the manager-perspective side of this, I dug into what new managers and leads typically get wrong in a previous issue -- worth a read if you want to understand what might actually be going on above you before you decide.

The Real Question: How Much Do You Care?

Here’s the question I’d ask instead of “should I quit?” -- how much do you actually care about this specific job, at this specific company?

Because the honest answer to that question changes everything that follows. If you genuinely care, then you probably do have the energy and motivation to try things first. If you don’t really care or don’t care enough for the amount of effort that goes into driving change, then sure -- the “start interviewing” advice is probably the right call.

And there’s no judgment in that. You’re allowed to not care or not care enough to pour more time and energy into something. People conflate “I should fight for this” with “I’m a good engineer,” and that’s not how it works.

The corollary: if you’re already burnt out and resentful, the amount of energy you have left to drive change is probably zero. I get into this in more depth in the issue on whether you should even talk to your manager about burnout, but the short version is: trying to fix a bad situation when you’re already cooked is a recipe for being even more frustrated. Be honest with yourself about which side of that line you’re on.

Build A Case Before You Burn It Down

If the answer to “do I care enough?” is yes, then the next move isn’t a heroic confrontation. It’s two things in parallel: support systems and evidence.

Actionable Tip -- Check your support systems in both directions:

• Up the chain. Who’s your skip-level manager? Do you have any working relationship with them? Are they someone who would back you up if you brought this to them with substance? Or are they the type to immediately tell your manager you complained?

• Across your peers. Are other people seeing the same things? You don’t want to get into “Bob sucks, let’s hate Bob” territory, but you can ask carefully -- “Hey, I ran into this situation, how have you been navigating it?” -- and see what comes back. If everyone else thinks things are fine and you’re the only one frustrated, that’s actual signal too. That’s not a fun signal, but it’s worth knowing.

The other half is evidence. When you go talk to your skip-level or HR or whoever, you want to be able to move past “I just don’t like working with this person” to “here are specific instances, here are the impacts, and here’s what I’ve already tried.” That’s the difference between a venting session and a conversation that can lead to action.

And just to set expectations: even with great evidence, your skip-level probably isn’t going to fire your manager on the spot. There’s usually a longer, slower process for things like this -- something closer to a performance plan than a phone call -- and often there’s still more observation, investigation, and understanding that goes into things. That’s not a reason to skip the conversation. It just means: don’t expect overnight magic.

There Are Always Two Sides To This

The Reddit post is one side of the story. The manager has the other side. And we have no way of getting that side, ever.

I’m not saying the original poster is wrong or making it up. I’d actually bet they’re doing a fine job and have a manager they genuinely don’t align with. But here’s the uncomfortable thing -- if we could call up that manager right now and ask “tell me about so-and-so and how the 1:1s are going,” we’d almost certainly hear a different story. Maybe a wildly different story. Maybe one where they think they are following up on things and the communication just isn’t landing the way the report thinks it is.

This is exactly why I wrote a whole issue on whether you can even measure manager effectiveness in any meaningful way -- because “this manager is bad” is a much harder claim to substantiate than people assume. And the things you’d use as evidence often look different depending on which seat you’re sitting in.

I’ve also been the person on the other side of “my manager won’t give me feedback” complaints. I unpacked the manager-side of that one in the issue on managers who supposedly refuse to give feedback -- there’s a lot of nuance that gets flattened when only one side gets to narrate the story.

None of this means your frustration is invalid. It just means: be careful about building a complete narrative when you only have half the inputs.

The 1:1 Problem Nobody Talks About

This is the part I think gets overlooked most often. The Reddit post says, “I bring stuff up in 1:1s and nothing happens.” Fair complaint on the surface. But let me walk through what might actually be happening.

You bring up a problem in a 1:1. Your manager listens, acknowledges how you feel, and you move on. Two weeks later, you bring up a similar problem. They acknowledge it again. Move on. You leave the second 1:1 thinking, “Okay, this is the second time and they’ve done nothing.” Meanwhile, your manager might be leaving the exact same 1:1 thinking, “Cool, they raised an issue and we talked about it. Glad they got it off their chest.”

You’re operating on totally different expectations. You think “raising it” means “they will go fix it.” They think “raising it” means “the person needed to vent and now we’ve vented.” Neither of you is technically wrong. You just never agreed on what was supposed to happen next.

Actionable Tip -- Stop ending 1:1s without explicit agreements. Try things like:

• “Can we talk about a plan for how we’re going to address this?”

• “What does the next step look like, and who owns it?”

• “By when should we expect to see movement on this?”

• “If nothing has changed in two weeks, what’s our follow-up?”

I went deep on this in a previous issue on getting the most out of your 1:1s, because honestly -- this is one of those things I see talented engineers under-leverage their whole careers. The 1:1 is your most direct, structured channel to your manager. If you’re walking out of every one of them with a vague sense of “well that didn’t go anywhere,” that’s a problem worth fixing before you start interviewing.

Wrap-Up

If your manager is genuinely bad, has no interest in changing, and your skip-level won’t back you up -- yeah, go interview. That’s a valid call and probably the right one for most people in that scenario.

But before you get there, ask the harder questions: How much do you care about this job? What does your support system actually look like? Have you built a real case with evidence? And most importantly -- are you and your manager actually operating on the same expectations in your 1:1s, or are you just both leaving with different stories about what happened?

Level-setting expectations and clean communication is, honestly, one of the biggest factors I’ve seen play out in software engineering careers. Everyone wants to argue about which language is best or whether AI is taking over. Meanwhile, the people who keep getting stuck are usually stuck on this. Get that right and a lot of the rest sorts itself out.

Leave a comment

Share

Subscribe now

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Your start time isn’t the signal you think it is

• People will model whatever hours you actually keep

• Overcommunicate the expectation -- silence sets it for you

• Skipping the live stream one more week here... But I’ll be back!

What Your Working Hours Signal To Your Team

Someone over on the experienced devs subreddit asked a question that I think a lot of people quietly worry about: when managers or senior people see you coming in late and staying late, or coming in early and leaving early, what do they actually take from that? Is your start time saying something about your work ethic? And honestly -- I don’t think it’s saying what you think it’s saying. But there’s a different signal you’re sending (or that your manager is sending to you) that does matter, and most people miss it entirely.

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

What I Actually Care About As A Manager

I’ll just lead with this and get it out of the way: I genuinely don’t care what time you start or what time you finish. I care that you’re putting in honest effort, that you’re engaged in the work, that you’re asking for help when you need it, and that the output of you in your role is something we can work on together to optimize. That’s it. The clock-in/clock-out timestamps are not the thing.

The one thing I care about that is time-related is overlap. If you’re on a team of eight and seven of them have a sync at a certain hour, can you find a way to make that work? Maybe you literally can. Maybe you can’t and you partner with someone to represent you. Maybe you lean on async tools to catch the parts you missed. The answer almost always exists -- you just have to be an adult about it and figure it out with your team.

I’ve worked with people who needed to shift their schedule because they were taking a class, or visiting family on a different coast, or their parents were in town for two weeks. The answer is always the same from me: how can I help make this work? Because I want flexibility for my team. I think you get more out of people when they have flexibility, and I think they’re more engaged. The opposite -- being rigid about time -- creates resentment, fear, or quiet quitting. Pick your poison. None of those are good outcomes.

So if you’re sitting there worried that your manager is going to judge you because you walk in at 10:30 instead of 9:00, I would tell you: most decent managers don’t care, and the ones who do are usually using time as a proxy for something else they should just be measuring directly (which is its own conversation -- I went into that more in Measuring Manager Effectiveness on a recent issue).

Where The Perception Actually Comes From

Here’s where it gets more interesting, and where I think most people miss the real signal.

The perception around working hours doesn’t usually come from someone’s start time. It comes from the people they look up to. If your senior engineer is online at 10pm, or your manager is firing off Slack messages at 6am, you start to build a quiet model in your head: this is what success looks like here. Maybe nobody ever said it out loud. Maybe the manager would tell you with full sincerity that they don’t expect you to be online at 10pm. Doesn’t matter. The behavior is the message. People emulate what they see, especially from people they respect.

So you start asking yourself questions. They’re getting an extra two hours a day. They’re more senior. They’re probably smarter than me. How am I supposed to keep up? And whether or not that calculation is conscious, it shapes how you work, how you feel about your work, and how long you stick around before you burn out.

This is one of the most common patterns I see in newer leaders too -- they don’t realize the modeling effect their own habits have on the team. I wrote about this in Top Mistakes of New Managers and Leads and again in I Wish I Knew THESE Before Becoming A Manager. The same theme keeps showing up: the things you do without thinking about them become the rules your team thinks they have to follow.

My Own Trap (And What I Got Told)

I’ll be honest -- I’ve been on the wrong side of this. Going back to my startup days before Microsoft, I worked as much as I possibly could. Not because anyone made me. That’s just how I operated. And at some point I got told, more or less, “Hey Nick -- you shouldn’t work that much.” And the part I was hearing was “it’s not healthy” and that part I appreciated.

But there was a second part to it that took me longer to absorb: you’re setting an example, and people will model it whether you tell them to or not. The unspoken expectation on the team becomes the hours the most visible person is working. If you’re modeling 14-hour days and weekends, that becomes the standard people think they have to hit to be considered effective.

My initial reaction, embarrassingly, was “well that’s not my problem -- people are adults, they can make their own decisions.” Which is technically true and operationally useless. As a leader, it is my problem, because I do understand that people emulate behavior they look up to. I do understand that they form expectations I never said out loud. So pretending otherwise is just me being defensive about my own habits.

Actionable Tip: If you find yourself working long or unusual hours, don’t just hope your team interprets it correctly. Tell them, plainly, that your hours are not their expectation. Then back it up by reminding people to disconnect when they’re going outside the norm -- don’t force naything, just make space for them. The combination of explicit words and visible action is what actually shifts the perception. If you have a manager doing this and you’ve never asked them about it, that’s exactly the kind of thing to bring into your next one-on-one -- ask them directly what they expect of your hours and whether they’d actually prefer you sign off when your work for the day is done.

The Manager Who Got It Right

The cleanest example I’ve seen of this done well was from a manager I joined under. He had something in his email signature -- I’m paraphrasing -- along the lines of “my working hours are not a reflection of what your working hours should be” and another note about working with teams in different time zones. If you read that without context, you might think it’s a weird thing to put in a signature. The reason it’s there is exactly the perception problem I’m describing.

He was being very explicit about the unspoken expectation. Every email he ever sent carried that disclaimer. He was overcommunicating because the alternative -- staying silent and letting people draw their own conclusions -- always loses. People will fill the vacuum with assumptions, and the assumptions will skew toward “I should probably be doing what they’re doing.” So you fill the vacuum yourself, on purpose, with the message you actually want them to take.

This connects to a bigger truth I keep coming back to about the people side of this work: the soft skills that move you up are usually about being explicit about things other people leave implicit. Communication, expectation-setting, calling out the obvious that nobody else wants to call out. The stuff that feels almost over-the-top is usually exactly right.

A Funny Coincidence

This whole topic was on my mind because earlier the same day I recorded the video, I happened to be in the office on a Friday -- which not many usually do because, well, it’s Friday. I was making up for a day earlier in the week I couldn’t get in. Someone on my team was on a call with a colleague, and the person on the other end asked who was in the office. My teammate listed a few people, including me, and -- in a way they knew I’d hear -- said something along the lines of “yeah, because he’s a workaholic.”

It’s harmless. They were joking around. But it’s a really clean piece of evidence that the perception is real, regardless of how many hours I actually work (no one is timing me with a stopwatch). And it’s a useful reminder that if I don’t want my team to assume “this is the expectation,” I have to be even more deliberate about saying out loud what the actual expectation is. Otherwise the joke stops being a joke and starts being the standard -- and that’s what you’re trying to avoid.

Wrapping It Up

So if you take one thing from this issue, take this: your start time isn’t the signal. The hours you actually work, especially if you’re senior or in a leadership role, are the signal -- and they will set the bar for your team whether you intend them to or not. The best thing you can do is overcommunicate. Tell people what you actually expect. Send them offline when they’ve put their time in. Put the disclaimer in the signature if that’s what it takes.

And if you’re on the other side -- if you’re the person worried about how your hours look -- then have the conversation. Ask. Don’t carry around a perception in your head that nobody actually holds. The cost of asking is one slightly awkward minute. The cost of not asking is years of working to a bar that doesn’t actually exist.

Subscribe now

Share

Leave a comment

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Manager effectiveness is multidimensional -- technical, project, and people

• You can’t perfectly quantify it, but you can measure signals that matter

• Balancing delivery with people management is the real challenge

• I’m on-call this week -- no live stream. Sorry!

Can You Actually Quantify How Good a Manager Is?

A viewer recently asked me about how quantifiable manager skills are, and I think it’s a genuinely fascinating question. We can all think of managers we’ve worked with and immediately categorize them -- “that person was incredible” or “that person was a nightmare.” But putting numbers on why is a completely different challenge.

I wanted to break this down because I think it matters -- not just for evaluating managers, but for managers themselves who want to understand where they’re doing well and where they need to invest more time.

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

First, Set the Expectations

Before we can measure anything, we need to level-set on what’s actually expected of a manager. And this varies massively -- across companies, team sizes, and seniority levels.

My advice for level-setting expectations applies to managers too. If you’re thinking of moving into management or you’re a new manager, work with your own manager to understand what’s expected of you. That baseline matters because without it, you’re measuring against a target you can’t even see.

The biggest variance I see comes down to how much time you spend as a hybrid IC. At smaller companies or on smaller teams, there’s often more of an expectation that you’re hands-on in the code. It almost wouldn’t make sense to sit back and wait if you have a small surface area of people and technology. But as your scope grows -- more people, more product areas -- the balance shifts. You stop being the person fixing bugs and start being the person planning how work gets delivered and making sure the right skills are applied to the right problems.

I’ve lived this shift personally. Early in my career I managed a bunch of people at a startup on a single product, and I could code in any area because I’d been there since the beginning. Then at Microsoft, I moved into a deployment team -- a more focused scope, a codebase older than some team members -- and many of my hands-on strengths just didn’t apply the same way. The same thing happened when I moved over to the M365 routine plane -- and that’s not a failure. It’s what happens when your role gets more strategic.

The Three Dimensions of Manager Effectiveness

I think about manager effectiveness across three major areas, and the measurability of each is very different.

1. Technical Ability

This one is nuanced. It’s different to have domain knowledge of the codebase versus having system design expertise. I can tell you from experience -- there are potentially junior engineers on my current team who can find and fix a specific bug faster than I can, because they’re working in that code every day. But if you need help designing a system from scratch? That’s where broader engineering experience kicks in.

The measure isn’t “can you out-code your team.” It’s more like: can you take on ambiguous, complex technical challenges and deliver at a level comparable to senior ICs on your team? For some managers, the answer is yes. For others -- especially those managing larger or more diverse surface areas -- the answer is no, and that’s completely okay if other dimensions are covered.

Actionable Tip: If you’re a manager who’s lost touch with hands-on code, lean into AI tools. I’ve found that AI makes it much faster to get up to speed on unfamiliar codebases when you need to jump in. It doesn’t replace daily hands-on experience, but it dramatically shortens the ramp-up time.

2. Project Management

This covers prioritization, tracking progress, managing roadblocks, handling dependencies with partner teams, and making sure work is properly staffed. And not “staffed” in the gross “people as resources” sense -- I mean making sure you have the right mix of skills and experience applied to each problem.

Can you measure this? Sort of. You could look at whether deadlines are consistently hit, missed by a little, or missed by a lot. If you’re always off by 2x on a six-month project, something’s wrong. If you’re off by a week or two? That might be totally reasonable.

But the real signal is less about hitting exact dates and more about what you do when things are off track. The best managers I’ve seen raise awareness at the right time, engage the right stakeholders, and either adjust scope or adjust timelines -- so things still get delivered on an agreed-upon plan even if it’s been shifted. That’s incredibly hard to put a number on.

3. People Management

This is the one most engineers underestimate when they move into management. And honestly, from my experience working with other engineering managers, many still don’t realize this is fundamentally a people management job. That’s alarming to me.

Here’s what falls under this:

• Career growth -- are you helping people advance? Is there a reasonable promotion cadence on your team? Not everyone promoted every cycle, but also not nobody ever.

• Team composition -- do you have the right balance of levels, backgrounds, and strengths? You can’t build a team where everyone has maxed-out stats. That’s not real.

• Single points of failure -- if only one person knows a critical system, you need a plan. That’s the lottery effect (or if you prefer the darker version, the bus effect).

• Engagement -- are people actually interested in their work? Do they feel supported?

That last point is critical. If you’re hyper-optimizing for delivery by always slotting your best person into the next highest-priority task, you’re probably ignoring whether your team is burning out. That person keeps getting siloed. Maybe they don’t even want to do that work anymore. Maybe other people on the team want the opportunity. You can’t ignore the people side just because the delivery side looks efficient on paper.

Actionable Tip: If you think supporting your employees detracts from delivery, you’ve got it backwards. A team full of people thinking “screw this place, no one cares about me” is not going to deliver great work regardless of how cleverly you assign tasks.

So How Do You Actually Measure This?

Here’s my honest answer: there is no single tool or system that gives you a clean numeric value across all of this. But there are signals you can look at.

• Promotion cadence -- are people progressing at a reasonable rate? If it’s zero or 100%, something’s off.

• Employee satisfaction surveys -- at Microsoft we have a signals survey with a “thriving score.” It’s not perfect science, but it gives you a quantitative read on whether your team is engaged.

• Deadline accuracy -- not whether you hit every deadline perfectly, but whether the variance is reasonable and whether you course-correct effectively.

• Technical contribution -- if you’re still expected to be hands-on, can you handle complex work at a level that matches your most senior ICs?

• Team resilience -- do you have the right mix of experience levels and no single points of failure?

The important thing is that you’re not measuring to game a target. You’re measuring to understand where you need to invest time. If nobody’s getting promoted, that’s a signal. If everyone is but your delivery is suffering, that’s also a signal.

It’s Going to Look Different for Everyone

Is it possible to come up with some type of assessment for manager effectiveness? Sure, I think so. But it’s going to look different depending on your seniority, your team composition, the lifecycle of your product, and a dozen other factors.

And that’s actually fine. The point isn’t to come up with a universal manager score. The point is to be aware of the different dimensions, check your signals, and course-correct where things are off.

These are my opinions from 13+ years of frontline engineering management. Your experience might tell you something different, and I think that’s a valuable perspective -- so leave me a comment to let me know!

Share

Leave a comment

Subscribe now

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• AI career anxiety is shifting from “replaced” to “left behind”

• Tool usage gaps and product integration gaps are different problems

• Your engineering fundamentals are more transferable than you think

• I’m on-call this week -- no live stream. Sorry!

The AI Career Conversation Is Changing

If you spend any amount of time in developer communities, on social media, or just talking with engineers in your circles, you’ve probably noticed that the AI conversation has shifted. It’s not the same conversation we were having a year or two ago -- it’s evolving. And I wanted to share some of the patterns I’ve been picking up from conversations I’ve been having with developers at various stages of their careers.

Obviously, everyone’s going to have their own bias on this based on where they’re working and who they’re interacting with. The same goes for me. But I think it’s genuinely valuable to share different perspectives so we can all get a broader picture of what’s actually happening out there.

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

“I’m Going to Be Replaced by AI”

Not surprisingly, the overwhelming narrative I hear -- and I’m guessing you’re hearing something similar -- is this fear of being replaced by AI. That hasn’t gone away. If I had to guess, it’s probably still the most common concern, especially on social media and from people I interact with outside of my direct team.

But here’s the thing: it’s not just people already in the industry. A huge chunk of the fear is coming from aspiring software developers -- people who haven’t even broken into the profession yet. They’re looking at AI progress and wondering if the job they’re trying to get is going to exist by the time they’re ready for it.

I do think this fear is starting to shift, though. It’s not disappearing, but the shape of it is changing. And that’s what I want to dig into.

The “Being Left Behind” Fear

The narrative that’s been ramping up the most in my conversations is less about replacement and more about being left behind. And it breaks down into two very distinct categories that I think are important to separate -- because the solutions for each look completely different.

Not Using AI Tools Effectively

The first category is around developer workflow tooling. People are looking around at their peers and seeing them use Claude, Copilot, Cursor, or whatever the latest tool is -- and they’re seeing (or at least perceiving) these people being incredibly effective with these tools. The side effect? This creeping feeling that everyone else is accelerating and I’m not keeping up.

Now, I want to be clear -- I absolutely use AI tools in my development workflow as much as I can. But I think there’s an important nuance here. You’re almost always going to see outliers on social media that exaggerate this effect. You don’t hear about the person who got a totally respectable 20% productivity boost. You only hear about the people claiming they’re 10x or 100x what their “former peasant selves” were. And that exaggerates the gap you perceive.

Actionable Tip: If you feel like you’re falling behind on AI tooling, start small. A lot of people I’ve worked with have been using AI for doc writing or smaller code changes, but they haven’t explored things like using AI to put together a comprehensive plan, execute on most of it, or collect and compare data across multiple design options. If you’ve been trying to one-shot perfect outputs and getting disappointed, that’s probably not the most effective way to use these tools. Iterating is key.

Not Building AI-Integrated Products

The second category is subtly different but equally real. These are developers who are building software across any domain and any tech stack, but they’re not integrating AI functionality into what they’re building. No agents, no LLM tool calls, no RAG pipelines -- there’s just no AI in the product or service.

This is fundamentally different from the first category. One is about your developer workflow (how you build things), and the other is about the product itself (what you’re building). And when people express this concern, these two things often get mixed together in a way that makes the anxiety worse.

Here’s the reality: you might be building something where AI genuinely doesn’t make sense. Take a high-performance reverse proxy, for example -- you’re not going to route requests through an LLM. That would be absurd from a performance perspective. But that doesn’t mean you can’t find peripheral opportunities. Data analysis, service health monitoring, on-call workflows -- there are likely adjacent areas where AI integration makes a lot of sense even if it can’t be on the hot path.

And if your product could benefit from AI but it’s not on the roadmap yet? I think you should advocate for it. Seriously. You might not be the final decision-maker, but I think everyone should speak up when they see an opportunity. That’s not overstepping -- that’s being a good engineer.

Subscribe now

The Cutting-Edge FOMO

This one is the newest thing I’ve been hearing, and it’s the one that’s been ramping up the fastest. It’s not about using AI tools or integrating AI into products. It’s about wanting to be the person building the AI technology itself.

How do I get to be part of putting the models together? How do I work on the agentic harnesses? How can I be involved in creating the technology that other developers are going to use -- whether that’s developer tooling or components for building AI-powered services?

I think there’s a hyper-awareness forming around this because of how much attention AI is getting. If you’re not at the core of it, it can feel like you’re going to become obsolete -- like you’re barely a consumer of AI things while other developers are literally assembling the fundamental building blocks.

Whether or not people felt this way about previous tech waves, I’m not sure. But the speed and scale of AI advancement is exaggerating everything. Every other tech shift I’ve lived through feels smaller by comparison.

How I’m Navigating This as an Engineering Manager

For the tooling gap, I feel like that’s the most actionable one. It’s very situational -- different people hit different hurdles. What I’ve been leaning into is spending time in one-on-one or small group sessions, not just showcasing success stories (though those are great) but addressing the other side: the people who are watching the demos thinking, “Cool, but that’s not me -- what do I do?”

I’ve had some success with this approach. People often go, “Oh, I didn’t know I could do that!” when shown different ways to use AI. There’s a lot of low-hanging fruit that people just haven’t explored yet -- using AI to evaluate and compare approaches, generate comprehensive plans, or make sense of large amounts of data.

Actionable Tip: If you’re a manager, don’t just run demos of AI success stories. Find the people who are struggling and work with them directly. Ask what they’ve tried. Show them alternatives. And for scale, do a few small group sessions and then let people help each other. It’s literally your job, and honestly, it’s one of the most rewarding parts.

For the product integration gap, that’s trickier. I can’t create artificial opportunities for AI integration in a codebase where it doesn’t make sense. But what I can do is encourage people to think beyond their direct service. There are almost always peripheral systems, workflows, or analyses where AI can add value.

For the cutting-edge FOMO? That’s the hardest one. My approach has been:

1. Acknowledge the feeling is valid. I’m not going to tell someone their concern is dumb. That’s how they feel, and it’s not for me to dismiss.

2. Provide perspective. Tech waves aren’t new, but this one is genuinely exaggerated in speed and impact. Acknowledging both of those things helps.

3. Support career decisions. If someone genuinely wants to go deeper into AI as a career direction, I fully support that. It’s not my decision to make -- it’s theirs. I can share perspectives, but ultimately people get to chart their own path.

Subscribe now

Your Skills Are More Transferable Than You Think

Here’s the thing I keep coming back to: the general skills we build as software engineers are incredibly transferable. Design patterns, system design, debugging, performance analysis, code organization -- all of that translates regardless of whether you’re building a traditional service or an AI-powered one.

It might mean catching up on new tech. That’s always been true in software engineering. But the fundamentals? Those don’t expire.

Do I have some of these fears myself? Sure, a little bit. But I also know that the core engineering skills I’ve built over my career have been applicable across every tech shift I’ve navigated. I don’t think this one will be any different in that regard -- even though the speed is unlike anything we’ve seen before.

Actionable Tip: Don’t make career decisions purely out of a fear reaction. Take the time to actually sit down and identify what specifically is bothering you. Is it the tooling gap? The product gap? The cutting-edge gap? Because each of those has a very different path forward, and lumping them together just makes the anxiety worse.

Share

Leave a comment

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Context switching is costly but never fully avoidable

• Give your manager context before they re-prioritize

• Limit work in progress to stay focused

• Join me for the live stream (or watch the recording) on Monday, April 20 at 7:00 PM Pacific!

Context Switching -- The Tax Nobody Budgets For

I went into the ExperiencedDevs subreddit and found a discussion about task switching that I wanted to dig into. This is probably one of those topics where if you’ve been a software engineer for any length of time, you’ve felt the pain of being pulled in multiple directions. And if you’re an engineering manager, you’ve been on both sides of it -- getting randomized yourself AND being the person asking your team to switch gears.

I wanted to talk about this from a few different angles: as someone who was a software engineer constantly dealing with context switching, as an engineering manager who has had priorities shifted on my teams, and as the person who sometimes has to be the one delivering the new priority to my team. As usual, I’ll throw this disclaimer in -- anything I say comes from my own lived experience. It’s not the only way to look at it. Just my perspective to hopefully give you some different insights.

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

The Overhead Is Real -- And It’s Never Going Away

Here’s the thing about context switching: it’s not free. When you do a context switch, there’s mental overhead, there’s tooling overhead, there might be a completely different codebase or problem space you need to load into your brain. And the unfortunate reality? You’re never going to eliminate context switches entirely. That’s just not realistic.

The goal is twofold. First, minimize context switches. Second, when they do have to happen, make sure they’re understood. The person doing the work and the person injecting the new priority need to be on the same page about why the switch is happening.

Startup vs Big Company -- Context Matters A LOT

One thing I’ve noticed throughout my career is that context switching pressure varies dramatically based on where you work. The industry, the type of product, and even the company stage all play a role.

At a bigger, more established company with stable products and services, the disruptions tend to happen less frequently. That’s been my general experience, at least. But there’s a huge caveat -- live services change everything. A live service is this living, breathing thing where anything could go wrong at any given time. If you’re working on a service that’s running 24/7, you’re more likely to get pulled into an incident bridge or a security-related fire drill.

On my team at Microsoft, for example, we handle a lot of security-related work. If something security-related comes up where we can help, that’s going to randomize someone -- and it’s extremely high priority. As much as possible, I try to put myself into that situation to shelter my team from having to context switch. I’d rather that the people building things and moving the product forward can continue doing that. But there are absolutely cases where that’s just not realistic and I have to pull people in.

On the flip side, at a smaller company, I’ve noticed way more context switching. Even without a live service, if you’re actively talking with customers and always chasing the next opportunity, it feels like there’s always something new you have to go chase. Especially in the early stages of a company, that could be absolutely critical -- if you don’t chase those things, you might not have a company. I’ve talked about the differences between startup and big tech planning before, and it’s worth noting that the cost of context switching at a startup isn’t just one developer changing what they’re doing. As the company grows, it becomes the entire team -- engineering, UX, product, marketing, sales -- all having to pivot. That kind of context switching absolutely does not scale.

What You Can Actually Do About It

So what do you do when your manager keeps throwing new priorities at you? This is probably what most people want to hear, right?

Actionable Tip: Provide context back to the person giving you the new task.

This is one of the most helpful things I’ve ever learned. When someone comes to you with “Hey, got something new” -- instead of just quietly accepting it, provide them with visibility into what’s currently on your plate.

Here’s what that looks like in practice. In my startup days (and I’ll always put this disclaimer in -- loved working for the CTO and wouldn’t change a thing about it), the founder would frequently come to us with new ideas and new priorities. We needed to start pushing back, and what that looked like was:

“Hey, look -- we just talked about these three things that are all supposed to be top priority. We’re actively working on them right now. Now you’re giving us a fourth. There’s only so many people and so much time. Do you truly feel that this fourth thing is more important than making progress on these other ones? Because if so, understood -- we’ll do what needs to happen. But given what I just told you, is this really the most critical thing?”

Over time, these conversations became much more natural. And I want to be clear -- it wasn’t confrontational. It was just about awareness. I’ve found that a lot of the time, the person assigning work doesn’t have the same level of visibility into what you’re doing. That just makes sense -- they’re removed from the day-to-day details. When you raise that awareness and ask them to think through the priority, more often than not they’ll say, “Actually, no, you’re right. Those other things are more important.” It was more rare that they’d insist the new thing took precedence.

The key takeaway here is that even when the answer was still “yes, switch,” at least we were aligned on why. And that alignment makes all the difference. I’ve written before about how communication is the biggest gap between good and great developers, and this is a perfect example. Being able to clearly communicate what you’re working on and ask clarifying questions about priorities is a massive skill.

The Same Principle Works at Big Companies Too

I’ve seen the exact same dynamic play out at Microsoft. Using the security example again -- there are times when security teams bring things that are clearly “must fix now.” And we go fix them. But periodically, something comes up in the mix that isn’t really a “must fix now” -- it’s more of an enhancement or a feature request.

So we started having more conversations where we’d ask clarifying questions: “Hey, we just want to make sure we understand the severity and criticality of this. Is this a right-now thing, or is this something that can be planned for?” And a lot of the time, just asking those questions helped everyone realize that the new thing wasn’t as urgent as it initially seemed.

This ties into something I talked about in a recent issue about whether you should talk to your manager about burnout -- the foundation of these conversations is trust. If you have a good relationship with your manager and stakeholders, these priority-check conversations become natural rather than adversarial.

How I Manage WIP on My Teams

From the management side, I like to limit the number of items in progress for each team member. If you’re familiar with concepts from Kanban, this is basically about managing your WIP -- your work in progress. I’ve had really good experiences where limiting the number of things going on at once helps people maintain focus.

But here’s where it gets nuanced. At Microsoft, a lot of the changes we need to make don’t lend themselves well to a strict “one item at a time” cadence. When you deploy changes across the entire planet, we purposefully do it at a staged, controlled pace. That means it goes slower -- not because the technology can’t handle it, but because we consciously choose to roll things out carefully. The side effect? If I only gave someone one thing to work on, they’d be sitting idle waiting for their change to deploy.

So what I’ve found works across the teams I’ve managed -- from new hires to principal engineers -- is that people actually prefer to have a few things going on at once, as long as the priority is clear. A more junior engineer might have one or two things in flight. A more senior engineer might have three or four, including design documents and multiple features at different stages of rollout.

The critical part is making sure everyone is aligned on which thing takes precedence. And we also have to watch for the downside: when you have multiple things in progress, it’s easy for items to sit blocked and get forgotten. Someone context switches away from a feature that’s rolling out, and two weeks later nobody remembers it needs attention. So staying on top of awareness and tracking is essential.

Document It If Your Manager Isn’t Getting It

I briefly skimmed through the Reddit comments on this one, and some people made a point I wanted to echo. If you’re trying to convey the impact of context switching to your manager and not having a lot of success with conversations alone -- try documenting it.

Actionable Tip: Keep a record of what you’re working on over time. When context switches happen, write them down. Then, when you want to have the conversation, you can show a visual of you bouncing between tasks and never actually finishing anything.

It’s just more context and visibility for the person assigning the work. I think a lot of the time, managers aren’t being malicious -- they’re just missing context. And if you’re feeling like company alignment isn’t quite where it should be, providing that documented proof of constant task switching can be a powerful way to start the conversation.

Sheltering Your Team -- The Manager’s Role

If you’re in a leadership position, I think one of the most important things you can do is act as a buffer between your team and the constant stream of incoming priority changes. Your team’s ability to stay in flow and actually ship things depends on you filtering out noise before it reaches them.

Here’s how I think about it in practice:

1. Absorb the disruption yourself when possible. I mentioned the security example earlier -- when something high-priority comes in that’s going to randomize someone, I try to put myself into that situation first. Yes, it means I’m the one getting context switched, but I’d rather take that hit than pull an engineer out of the middle of a complex feature. My job as a manager is to enable my team to do their best work, and sometimes that means shielding them from the chaos even when it’s inconvenient for me.

2. Find natural transition points. One of the better examples I can think of is when someone was literally finishing up their current work and about to start the next thing. Right before they began, we were able to redirect them to a different work stream, and a new team member picked up what they would have originally started. That kind of timing worked really well because nobody was being ripped out of something mid-thought. The cost of switching at a natural boundary is dramatically lower than mid-task.

3. Batch and filter incoming requests. Not every “urgent” request that comes from stakeholders is actually urgent. Part of the manager’s role is to ask those clarifying questions on behalf of the team before the request ever reaches them. If I can resolve a priority question in a five-minute conversation with a stakeholder, that’s infinitely better than disrupting an engineer’s entire afternoon.

4. Be transparent about what you’re sheltering them from. I’ve found that teams appreciate knowing that you’re actively protecting their focus -- not because they need to be grateful, but because it builds trust and it helps them understand that when you do come to them with a context switch, it’s genuinely important. It changes the dynamic from “my manager keeps throwing random stuff at me” to “if my manager is asking me to switch, this must really matter.”

What I try to avoid at all costs is the “drop everything you’re doing” scenario. That’s just disruptive in every way. And as I mentioned in the recent issue about staying technically sharp when your role gets more strategic, sometimes that means I absorb the context switch myself so my team can keep their flow.

The Bottom Line

Context switching is never going away. The goal isn’t elimination -- it’s minimization and alignment. Whether you’re a developer being asked to switch tasks or a manager making those calls, the single most impactful thing you can do is provide and ask for context. Give your manager visibility into what you’re working on. Ask clarifying questions about the urgency and priority of the new thing. Document the impact when words aren’t enough.

And if you’re a manager, try to shelter your team when you can, find natural transition points for switches, and make sure everyone is on the same page about what matters most. A lot of frustration around context switching comes not from the switch itself, but from the feeling that nobody is aligned on why it’s happening.

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Staying technical starts with knowing what “technical enough” actually means for your role

• Design reviews and code review exposure are your minimum baseline -- they keep your surface area alive

• Trust is not a weakness: as your scope grows, being deeply expert in everything is impossible and trying will break you

• Join me for the live stream (or watch the recording) on Monday April 13th at 7:00 PM Pacific!

The Technical Tightrope: Staying Sharp When Strategy Starts Eating Your Calendar

There’s a Reddit post I came across in the ExperiencedDevs community that asked a question I’ve heard a hundred times: “How do you stay technically sharp when your role becomes more strategic?”

It sounds simple. It’s not.

This is one of those things that sneaks up on you gradually. One day you’re writing code most of your day. Then the meetings start. Then the strategy conversations. Then you look up and you’re spending maybe two or three hours actually touching code out of an eight-hour day. And a quiet panic sets in: am I losing it?

I’ve been there. I was a startup engineering manager about a year into my career. I was coding for long stretches -- probably unhealthy stretches -- and then my role started pulling me toward strategy. Over time, I could feel the gap forming. So I want to share what I’ve learned about staying sharp without trying to pretend your role hasn’t changed.

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

First: Know What “Technical Enough” Means for Your Role

Before you panic about losing your technical edge, step back and ask yourself: what does your role actually require from a technical perspective?

This is different for everyone. For some people in leadership or management positions, technical depth means being able to hold your own in an architectural discussion. For others, it means knowing enough to ask the right questions and direct the right people. For others still, it means being able to jump into the codebase when needed.

My litmus test is this: if you find yourself constantly deferring in technical conversations -- like every single time the discussion gets technical, you’ve got nothing to contribute and have to say “let me get back to you on that” -- that’s a signal worth paying attention to. It doesn’t mean you need to be coding eight hours a day. It means there’s probably a gap forming that’s going to cause problems in your strategic conversations too.

Understanding the expectation is step one. Once you know that, you can be intentional about what staying sharp actually looks like for you specifically.

The Minimum Baseline: Design Reviews and Code Review Exposure

If I had to name the minimum surface area for staying technically engaged, I’d say two things: design reviews and code review exposure.

Design reviews are valuable even when they’re outside your direct area of ownership. I manage multiple sub-teams, and I make a point to get pulled into design reviews for teams I don’t directly manage when I can. I’m not there to make the decisions -- I’m there to maintain context. Even if a design discussion is in an area I’m not an expert on, the more often I’m in the room, the more I can say “I’ve seen this pattern come up before” or “I know who to loop in on this.”

Code reviews work the same way. The goal isn’t to gate every single pull request. The goal is to be automatically on the exposure path. If you’re never included in code review cycles, you’ve got to go out of your way to discover what’s changing in your codebase. That friction is enough that most people just stop looking. Being looped in -- even just as a passive observer on some reviews -- keeps the surface area alive.

Neither of these requires you to be the approver or the decision-maker. They just keep you in the conversation so you don’t fall completely off the map.

Pull in the Experts Early -- and Work With Them

One situation that comes up constantly in strategic roles is being in a conversation that slowly slides into a technical design discussion. Maybe it starts as a product conversation. And then someone draws a box on a whiteboard. And suddenly you’re three levels deep into architecture.

If you’re in those moments and you know you’re not the right technical expert, there’s a wrong way and a right way to handle it.

The wrong way: try to bluff through it, make design decisions you’re not qualified to make, and figure it out later. This is how technical debt disguised as strategy gets born.

The other wrong way: immediately hand it off entirely and walk away. “Not my area, talk to Bob.” This protects you in the short term, but it means the next time this exact situation comes up, you’re in the same position -- or worse.

The right way: identify early that this conversation needs technical depth you don’t have, pull in the right people, and work alongside them rather than delegating and disappearing. The distinction matters. When you work with the expert instead of just handing it off, you pick up context. You learn the codebase area. You understand the tradeoffs they’re weighing. And the next time this topic comes up, you’re not starting from zero.

I’ve experienced this recently with a team member moving to a different team. He took deep codebase expertise with him, and the immediate reality for me is that I probably need to step more directly into some of that code for a period -- not to become the expert, but to reduce the gap while the team adjusts. That’s not comfortable. But it’s the right call given the context.

Side Projects Are Still on the Table

This one is contentious and I want to address it directly.

If there’s a technology area where you feel like you’re falling behind and your day job isn’t giving you exposure to it, side projects are still a valid option. I know people push back on this. You shouldn’t have to work outside of work hours. That’s a fair perspective.

But I separate “should” from “can.” If there’s a genuine gap that matters to you, and the path to closing it is available outside of work, it’s worth at least considering. It doesn’t have to be something you ship. It doesn’t have to be polished. Just build something with the technology. I built a website with Astro recently just to get my hands on it. I tried deploying something with Kubernetes just to understand it better. These low-stakes explorations build real intuition even if the project goes nowhere.

You can do something similar with design patterns and software architecture -- building an extension system in C# using a plugin architecture approach is exactly the kind of hands-on project that builds the kind of deep understanding that strategic conversations rely on. Small things, real exposure.

The Part Nobody Wants to Talk About: Trust

Here’s the uncomfortable truth that I think a lot of people avoid: as your scope and responsibility grow, it becomes literally impossible to maintain deep technical expertise across everything you’re responsible for.

Not difficult. Impossible.

If you’re a deeply technical individual contributor today and your role evolves into one where you’re responsible for three different teams across three different technical areas, you won’t be the domain expert in all three. That’s not a failure. That’s the math of the situation.

The shift you have to make -- and it’s genuinely hard -- is trusting that other people on your team do have that expertise. This isn’t about abdicating responsibility. It’s about recognizing that your value in the role has shifted. You’re not valuable because you know every line of code. You’re valuable because you can make good decisions with the technical input you receive, connect the right people, and remove the right obstacles.

I’ve seen leaders try to stay so technically involved in everything that they become bottlenecks. Every decision routes through them. Every pull request waits on them. Every design needs their approval. It feels like technical leadership but it’s actually the opposite -- it’s a scaling failure dressed up as technical rigor.

If you find yourself doing that, or being tempted to, it’s worth asking whether the drive to stay deeply technical is serving your team or serving your ego. Sometimes it’s both. But being honest about that distinction matters.

What This Actually Looks Like in Practice

To bring it together: staying technically sharp as a strategic leader isn’t about reclaiming your identity as an individual contributor. It’s about maintaining enough surface area that you can be useful in technical conversations and make good decisions when they matter.

For me personally, that means:

• Getting invited to design reviews, even when they’re adjacent to what I directly manage

• Being on the exposure path for code reviews without trying to gate every change

• Pulling technical experts in early and working with them rather than just handing things off

• Being intentional about exploring areas where I feel gaps forming

• And most importantly -- knowing where the line is between “I need to understand this” and “I need to trust someone else here”

The plugin architecture patterns I’ve been covering on the blog are a good example of this kind of intentional technical exposure -- even if you’re not shipping plugin systems at work, understanding the design principles keeps your architectural thinking sharp.

Don’t panic about the shift. It’s natural. The people who handle it well are the ones who stay honest with themselves about what they know, what they don’t know, and who to bring in when the gap matters.

Subscribe now

Share

Leave a comment

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Copilot CLI finally pulled me from Visual Studio

• Cross-repo AI customization still feels like an unsolved problem

• Roslyn analyzers are surprisingly effective AI guardrails

• Join me for the live stream (or watch the recording) on Monday, April 7 at 7:00 PM Pacific!

Have I Finally Moved Away From Visual Studio?

I have been a Visual Studio person my entire career. Not VS Code -- the “real” Visual Studio. The classic one. The big, beautiful, opinionated IDE that .NET developers have lived in for decades. I’m a UI guy. I like a visual git tree. I like clicking things. That’s just how my brain works, and I’ve never apologized for it.

So it is genuinely strange for me to say: I’m barely opening Visual Studio anymore.

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

Why Copilot CLI Clicked For Me

Over the past year I’ve tried a lot of things -- VS Code, Cursor, Claude Desktop, GitHub Copilot with cloud agents. And I want to be really clear here: I’m not saying Copilot CLI is better than the others, or that what worked for me will work for you. What I can say is that Copilot CLI is the tool that got me glued to it right now, and I think I’ve finally figured out why.

The cloud agent workflow I was using heavily before let me queue up work and check on it whenever. Truly async. That was a game-changer for parallel productivity. But sitting and watching a local agent chew through things on my computer while I wait? That pattern never really clicked for me. Copilot CLI hit a different sweet spot -- it brought the productivity I wanted back to the terminal context in a way that finally matched how I think.

Honestly, it might just be timing. The tool has matured, the integrations around it have improved, and it caught me at the right moment. That’s a real thing. Don’t dismiss it.

If you’re curious how Copilot as a platform compares to other frameworks like Semantic Kernel for building your own AI applications in .NET, I went deep on that comparison recently -- check out GitHub Copilot SDK vs Semantic Kernel: When to Use Each in C#.

The Cross-Repo Problem Doesn’t Feel Fully Solved Yet

Here’s where things get philosophically tricky for me. As I’ve leaned harder into Copilot CLI, I’ve been building up a decent library of skills, MCP servers, and custom agent definitions. And they’re useful -- genuinely useful. A skill that remembers how I like to structure tests, an MCP server that talks to a specific API, an AGENTS.md file with project conventions. All good things.

But I work across multiple repos. I have a social media scheduler, my blog, a dependency injection library, some MCP helpers, and a vibe-coded game framework I’m building purely for the learning experiment. These projects are completely different. And yet my guiding principles are almost entirely consistent across all of them -- I want composition over inheritance, I want certain naming conventions, I want a specific approach to async code.

Right now those cross-cutting principles live in project-specific files. That’s not right. I’m duplicating intent in every repo.

GitHub Copilot does support repository-wide custom instructions via .github/copilot-instructions.md, path-specific instruction files in .github/instructions/, and AGENTS.md files anywhere in the repo tree -- and VS Code is moving toward an agent plugin marketplace that can bundle customizations into installable plugins. That’s directionally right.

But right now it still feels clunky. There’s no clean answer for “here are my global developer principles that apply everywhere I work, regardless of repo.” I’m starting to move my reusable skills into a shared repository and pull them in as a plugin -- but we’re still early, and the tooling around this is evolving fast.

Actionable Tip: Start separating your Copilot customizations into two buckets right now: repo-specific (your architecture decisions, your test patterns, your naming conventions for this project) and cross-cutting (your general coding principles, your preferred patterns, your communication style with the AI). Even if the tooling to share the cross-cutting ones isn’t perfect yet, having the separation in your head will make it much easier to migrate when the ecosystem matures.

Build a Habit of Turning Wins Into Reusable Skills

One thing I’ve been deliberately trying to do: every time I finish a session that worked well with Copilot, I stop and ask myself -- “Am I going to want to do this again?”

If the answer is even maybe, I ask Copilot to turn the approach into a skill.

It’s not about capturing everything. Most things aren’t worth it. But when I grind through something painful and finally get to a clean result -- a refactoring approach that worked, an analysis workflow that surfaced useful insights, a code generation pattern that saved me hours -- that’s exactly the kind of thing I want to be able to invoke next time without rediscovering the process.

The pattern I ran into recently is a good example. I had Copilot attempt a sweeping test refactor across a codebase with some concurrency problems. It didn’t solve the problem -- I honestly didn’t expect it to. But by the end I had a clear list of what didn’t work, which let me identify the real root cause and design a more targeted incremental approach.

That incremental approach is something I want to formalize. When I go to do a sweeping refactor again, I want a skill that structures the approach: small changes, consistent reporting, flag outliers, don’t try to boil the ocean in one shot. I haven’t nailed that skill yet, but that’s the kind of meta-workflow capture I’m working toward.

Roslyn Analyzers Are Surprisingly Good AI Guardrails

Here’s the most genuinely useful thing I’ve discovered in this vibe coding experiment: when AI keeps making the same mistake, the right fix is a Roslyn analyzer, not more prompting.

The game framework project is intentionally hands-off for me -- I’m letting AI build the whole thing to learn about architectural drift and where guardrails matter. And it ran into two serial offenders that it could not stop doing on its own.

Mistake 1: DTOs with multiple constructors. The AI was building data transfer objects with three or four constructors. The JSON serializer would try to guess which one to use and fail -- every single time. Hours of spinning on this. Once I saw the pattern, I did two things: created a Roslyn analyzer that makes it a compile error to have a DTO with multiple constructors, then fixed all the existing violations. Problem did not come back.

Mistake 2: Wrong collection injection type. The AI kept debating with itself -- in the chat window, while thinking -- about whether it could use IEnumerable<T> for dependency injection or not. It can. But it would sometimes try IList<T>, sometimes IReadOnlyCollection<T>, and sometimes just get confused and do something broken. So I put a Roslyn analyzer in place: always use IReadOnlyCollection<T> for injected collections. Anything else is a compile error.

The pattern is: identify the class of mistake, make it a compile-time impossibility, then let Copilot continue knowing that failure mode is structurally ruled out. It’s not just about AI -- this is good software practice in general. The Microsoft Roslyn SDK makes writing these analyzers more approachable than you might think -- you can author a diagnostic that fires in the editor and a code fix that resolves it, all in C#.

For a deeper look at how source generators and Roslyn-based code generation work in practice, check out Real-World C# Source Generator Examples: ToString, Mapping, and Serialization and C# Source Generator Attributes: Generating Code with ForAttributeWithMetadataName -- same Roslyn SDK, different angle.

Actionable Tip: When an AI agent makes the same mistake three or more times in a session, that’s a signal. Don’t write a longer prompt. Write an analyzer. It permanently encodes the constraint in the codebase and removes the failure mode from the AI’s decision space entirely.

Managing Multiple Parallel Sessions Without Losing Your Mind

At any given time I have somewhere between three and eight Copilot sessions running across different projects. That’s not a flex -- it’s kind of a mess, honestly, and I’m not sure my brain is properly equipped for it long-term.

The context switching is real. Checking in on each session, figuring out where it is in its current task, deciding whether to redirect it, queue the next instruction, and move on to the next tab -- it’s a new kind of cognitive load. The productivity feels genuinely high. The quality is a more honest question.

The vibe-coded game framework is a perfect example of where that quality question bites you. I let it run far enough that it had the client and server so tightly coupled that when I asked it to split out a visual debug layer, it spent hours untangling something that should have been a clean separation from day one. Vibe coding will give you working code faster than you can imagine -- it will also give you architectural debt faster than you can imagine. That tradeoff is real and you need to be eyes-open about it.

For complex multi-agent patterns where you actually want structured, controlled AI orchestration -- not just tabs of chaos -- I wrote about exactly that recently: Build a Multi-Agent Analysis System with GitHub Copilot SDK in C# walks through building a real pipeline where agents have defined roles and don’t just wander off in random directions.

Actionable Tip: Before letting a session run for more than a few hours of iteration, define the intended layering of your code explicitly -- in a comment, in a skill, in AGENTS.md, somewhere. Once coupling creeps in across layers, the AI will replicate that coupling endlessly. The cost of fixing it later is far higher than the cost of naming it upfront.

Share

Leave a comment

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Burnout builds slowly -- it sneaks up on you

• Trust with your manager enables harder conversations

• Know what you want before raising burnout

• The live stream is skipped this week -- I’m on-call for work.

Should You Talk To Your Manager About Burnout?

I came across a post on the ExperiencedDevs subreddit that I wanted to dig into. A developer is feeling completely burnt out -- dealing with bureaucracy, red tape, slow-moving processes -- and they’re preparing for an upcoming 1:1 with their manager. Their question: how do I even start this conversation?

It’s the right question to ask. And getting it right matters. So let me share my thoughts.

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

Burnout Doesn’t Happen Overnight

This is the part a lot of people underestimate. When we talk about burnout, we’re not talking about “it was a rough week.” We’re talking about something that builds over weeks, months -- for some people, years.

Because of that time scale, it has this unsettling ability to creep up on you. You don’t notice it day-to-day. You don’t even necessarily notice it week-to-week. And then one day you’re sitting in a meeting, resenting basically everything around you, wondering how you got there.

I think about this like weight. If I stop actively paying attention to what I’m eating, I’ll pack on weight without noticing -- not daily, not even monthly. But a year in, someone I haven’t seen in a while will look at me differently. That’s what burnout does. The feedback loop is so slow that by the time you’re aware of it, it’s already been compounding for a while.

I work at Microsoft now, and I sometimes notice this with some processes. Certain things I have to do that I’m not enthusiastic about -- combined with the process overhead involved -- the feeling of disengagement grows fast, especially when you stack those things up. I wasn’t immune to this at startups either. The nature of it was different (fast chaos versus slow bureaucracy), but the burnout was still real.

What I actually find hopeful about the person who posted on Reddit is that they noticed. That awareness -- even if it came later than ideal -- is worth something. A lot of people just stay stuck on autopilot and let it bleed into every other part of their life.

Actionable Tip: Build yourself some kind of regular check-in. Not a formal process -- just a moment to ask: is this still just a rough patch, or is this a pattern? If you keep telling yourself “it’ll get better” month after month, take that seriously.

Your Relationship With Your Manager Matters More Than You Think

Before we talk mechanics, I want to zoom out.

The quality of that burnout conversation in your 1:1 will be largely shaped by the trust and respect you’ve built with your manager. That’s not something you can manufacture on the spot when you need it.

From my experience on both sides of this -- as someone who has had these conversations with my own managers, and as a manager trying to create that space for my team -- the goal should be a relationship where a difficult conversation feels like it’s coming from a place of mutual investment, not conflict.

I’ve had employees who could reach out to me between 1:1s when something important came up. Sometimes they’d say something like “if you take your manager hat off for a second, can we talk about this?” That kind of thing is a signal back to me that at least in that working relationship, I was building what I was trying to build.

Not every manager is going to be equally safe to have this conversation with. That’s just reality. But I’d encourage you to keep working towards that baseline -- because when you really need it, it matters a lot.

Don’t Walk In With a Complaint List (Without Context)

Here’s where I want to be direct, because this is where a lot of these conversations go sideways.

You probably do have a list. A list of:

• Things that frustrate you

• Things that feel broken

• Things that drain your energy

And that list is good -- it means you’ve done the inventory work. The problem isn’t having the list. The problem is walking into that 1:1 and unloading it item by item without any framing.

Put yourself in your manager’s shoes. What happens after “this sucks, that sucks, and this other thing also sucks”? Are they supposed to:

• Fix all of it?

• Escalate everything?

• Nod sympathetically?

If you haven’t signaled what you’re hoping for in terms of support, there’s a decent chance they don’t know either -- and then:

• Nothing changes, and you’re more frustrated than before

• ... Or they try navigating this in ways that aren’t effective for you

The awareness piece still matters. Maybe some of the things on your list are systemic problems your manager is already aware of but can’t directly control. Raising them anyway is useful -- the more signal they have, the better they can prioritize and escalate. But awareness alone isn’t enough if you’re expecting action.

Know What You Actually Want From the Conversation

This is the step most people skip. And it makes everything harder.

Before you go into that 1:1, ask yourself: what are you actually hoping to get out of this? Some legitimate answers:

• “I just want my manager to know this is happening.”

• “I want help solving one specific thing.”

• “I want to know if I have any agency to drive change here.”

• “I want to understand if this is even fixable in this environment.”

These are all fine answers. But they lead to very different conversations.

My recommendation: pick one item from your list -- the one that’s bothering you most -- and make that the focus. Something like: “I’m finding our planning meetings really disengaging. I understand the purpose, but I don’t think we’re getting the value we should be. Can we talk about that?” Then signal your expectations: “Is this something you can help drive? Or is this something I could take some ownership of?”

That framing -- here’s the problem, here’s what I’d like to do about it -- is going to land much better than a grievance dump.

And if you genuinely don’t know what you want yet, that’s okay too. You can frame it as raising awareness: “I’m starting to notice some patterns that are contributing to disengagement, and I wanted to flag it early so we can start having that conversation. I’ll bring more specifics as I understand it better.” That’s still useful. It opens the door without pressure to have everything figured out right now.

What Happens If Nothing Changes

I want to be honest with you here.

If you raise this, frame it well, communicate your expectations clearly -- and still nothing moves -- that’s information. At some point, you have to decide whether this environment is working for you.

I’ve been in that position in my career. My gut is always to lean into it first: if I want to be here, I want to drive change. But if I’m genuinely trying to drive positive change and I’m not getting any support for it, that’s okay. It just means it’s not the right environment for me.

That’s a personal decision. I can’t tell you when the right time is -- it looks different for everyone. But I can tell you that staying indefinitely in a situation that’s burning you out, after you’ve already tried to address it, tends not to end well for anyone.

The first step is still the same: have the conversation. You might be surprised. You might not. Either way, you’ll know more than you do now.

If you’re also questioning whether software engineering is the right path at all -- separate from the current burnout -- it’s worth thinking through what’s actually driving that feeling. I explored something adjacent in last week’s Dev Leader Weekly on whether there’s an ROI on learning C# -- sometimes the burnout isn’t about the job, it’s about feeling like the craft itself isn’t rewarding anymore.

Leave a comment

Share

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Foundations beat language-specific trivia every time

• AI lets you build without knowing a language -- until you get stuck

• Yes, learn C# -- but learn the why, not just the how

• Sorry, no live stream! I will be busy on-call this week for work.

  Subscribe now

The ROI on Learning C# (It’s Not What You Think)

I had a great question come in on one of my Code Commute videos: do I think there’s an ROI on learning C#?

The short answer is yes. But the reason might surprise you -- because honestly, the reason has almost nothing to do with C#.

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

My Obvious Bias (and Why I’m Acknowledging It)

Full transparency: I’m a C# developer. I’ve been working with C# for as long as I can remember -- since my first year of university. The vast majority of my technical content is C# and .NET. So yes, I have an obvious bias here.

But I want to be really clear about something. I’m not a zealot. I don’t think C# is the best language ever created. I like using it because it works really well for me in basically every situation I’ve found myself in. That doesn’t mean it’s objectively superior to anything else. I don’t think “best language” is even a meaningful concept.

So when I say yes, learn C# -- I’m not saying it because I think you should worship at the altar of C#. I’m saying it for a different reason entirely.

The Real Reason: Foundational Knowledge Transfers Everywhere

Here’s my actual argument: the reason learning C# has ROI has nothing to do with C# specifically.

What I mean is this: If you invest your mental energy into deeply understanding things at a foundational level...

• how garbage collection works as a concept

• what it means for a language to be managed

• what design patterns exist and why

• how different types of systems handle memory and concurrency

... that knowledge transfers everywhere. It helps you make better decisions regardless of what language or framework you’re working in.

The trap I see people fall into is treating programming languages like trivia. Like, how well do you know the very specific edge cases of this very specific API in this very specific runtime? I’ve seen “C# interview questions” that I genuinely had to look up answers to, despite having written C# for most of my career. And that tells you something. That trivia-level knowledge has always had diminishing returns.

Compare it to cars. I don’t need to know the exact inner workings of every component in the specific model I drive. But it’s genuinely useful for me to understand what a turbocharged engine means in practice, why different oil viscosities exist, what the difference between a V4 and a V8 actually translates to in real-world performance. That conceptual understanding helps me make decisions. The hyper-specific trivia about a particular vehicle? Much lower ROI.

Software engineering is the same. Understanding patterns like the Singleton pattern or the Strategy pattern isn’t about C# syntax. It’s about learning a vocabulary and a set of solutions to recurring problems -- one that applies no matter what language you’re writing in next year.

Where AI Changes the Equation

With how much AI is reshaping how we build software, I think deep language-specific knowledge is becoming less relatively valuable -- and foundational knowledge is becoming more valuable.

Here’s a concrete example from my own experience. I wanted to build a small MCP server -- literally just a convenience wrapper around an existing API. My goal was that if anyone else wanted to use it, they could download it without any setup friction. No runtime to install, no build steps to fumble through.

I was chatting with GitHub Copilot about it, and it suggested I could build it in Go and ship it as a self-contained binary. It also offered the option of a self-contained .NET executable. So I said: do both.

The result was an MCP server implemented in both Go and C# that parallel each other in features. And I have never in my life read a line of Go code. Not a flex -- it’s a demonstration. I did not need to know Go to ship a working Go program. The AI handled the implementation details. I handled the intent, the architecture decisions, the debugging when things weren’t right.

If you want to explore building your own AI-powered tooling, I’ve been writing a lot about the GitHub Copilot SDK on the blog lately, including building an AI CLI developer tool that’s a great starting point.

But Foundations Are Why I Didn’t Get Stuck

Here’s the nuance though. I could build in Go without knowing Go -- because I have a solid software engineering foundation.

When I hit a question like “do I need compile-time dependencies or runtime dependencies for this?” I could ask that question in a meaningful way. I understood what compile time means, what a runtime is, what the difference implies. Those aren’t Go-specific concepts. They’re foundational. And having them let me ask Copilot the right questions to unblock myself quickly.

Without that foundation, you could still make progress. You could paste errors into an LLM and say “it’s not working” over and over. You would eventually get somewhere. But the effectiveness -- the ROI, since that’s what we’re talking about -- drops significantly.

Actionable Tip: When you’re learning a new language or framework, actively ask yourself: “What is the general principle behind this? Where else have I seen this pattern?” That habit compounds over time more than any amount of syntax memorization.

There Are Still Cases Where Deep Knowledge Matters

I don’t want to wave away deep expertise entirely. There are absolutely situations where it matters enormously.

One of my teams is working on a hyperscale caching system. The performance requirements are extreme. And in that context, not having deep knowledge of how C# and the .NET runtime work at a granular level means you can’t get to the optimizations needed. The stakes are high enough that the hyper-specific knowledge becomes genuinely worth the investment.

But the engineer working on this didn’t arrive with 40 years of deep .NET internals knowledge. They’re a strong engineer with solid fundamentals who is going deep because the situation demands it. The foundations got them there. The depth came as needed.

That’s the model I think works best: strong foundations that let you go deep when you need to, rather than going deep on specifics and hoping they transfer.

The Bigger Picture: AI is Opening Doors

One thing I genuinely love about the current moment in software development is that it’s lowering the barrier of entry. I’ve talked with product managers on my team who, when presented with the question “could you build a small web service using AI tools?”, would say yes -- even though they’d never considered themselves programmers.

That’s amazing. There’s no magic behind the curtain. Getting into software development is hard, and AI is making it more accessible without eliminating the hard parts that actually matter.

My only hope for people entering this way is that they stay curious. That as they start seeing things come together, they don’t just accept “it works” as the end of the inquiry. The developers who get really effective over time are the ones who keep asking why. What does this actually do? Why did the AI make this choice? What would happen if I changed this?

That curiosity is what turns AI-assisted output into actual expertise.

So -- Is There an ROI on Learning C#?

Yes. Absolutely.

But the ROI isn’t really in memorizing C#-specific trivia. It’s in building a mental model of software engineering through the lens of a real, production-grade language with real patterns and real tradeoffs. C# gives you garbage collection, async/await, strong typing, rich framework support, and a world-class ecosystem. Learning those things conceptually -- understanding what they mean and why they exist -- is where the value lives.

The specific syntax? The edge cases? Those you can look up. The understanding of why -- that’s what AI can’t fully replace yet, and what makes every other language and framework easier to pick up.

Learn C#. Learn it deeply enough to understand the fundamentals. Then take those fundamentals everywhere.

Share

Leave a comment

Subscribe now

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Mission alignment shapes how engaged you are daily

• Understanding why your work matters is underrated

• Reflect on what engages you, then align your search

• Join me for the live stream (or watch the recording) on Monday, March 16 at 7:00 PM Pacific!

Does It Matter If You Believe in What Your Company Does?

I came across a post on the ExperiencedDevs subreddit that I found genuinely interesting -- and if I’m being honest, it hit pretty close to home because I was already thinking about this exact topic.

The Redditor described how they used to work at a company in the music industry. They were engaged. The work felt meaningful. They cared about what they were building and why. Then, over time, structural issues at the company led them to move on. Now they’re working in some legacy tech space, and they realize -- almost with some shock -- how much that previous alignment had been fueling them. Without it, they’re just... not feeling it. They don’t care about what the company does. And it’s making it hard to be enthusiastic about the work.

That’s a real thing. And it’s worth talking about.

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

Not Everyone Is In The Same Place -- And That’s Okay

Before I get into the substance of this, I want to be clear about something: I’m not here to tell you what you should value in your career. That’s shaped by your life experiences, your stage in life, your financial reality, and a hundred other things. It’s not my place to say you’re doing it wrong.

If you’re early in your career and your only goal is to get your foot in the door -- I get it. Completely. Your focus is survival, not fulfillment optimization. That’s entirely reasonable. The stuff I’m going to talk about may not be relevant to you right now, and that’s fine.

My point in wanting to explore this is that over the course of a career -- which is most of your adult life -- this stuff starts to matter more. The things that engage and disengage you will shift over time. What you value at 22 is probably not what you’ll value at 42. But if you’re going to spend a massive chunk of your life working, it’s worth at least thinking about whether you’re spending that chunk somewhere that feels meaningful to you.

The “Fulfillment Across a Career” Framing

Here’s the framing I keep coming back to: most of our adult lives are spent working. If you don’t have a shortcut out of that equation -- and for most of us, that shortcut isn’t on the table -- then optimizing for fulfillment over the long arc of your career just makes sense.

Now, I know what some of you are thinking: “Cool, sounds nice on paper.” And I hear you. If you’ve never worked somewhere that felt engaging, you have no evidence that it can be otherwise. Your lived experience says it’s just work, and work is fine, and the fulfillment comes from what you do outside of it. I don’t disagree with that framing either -- if you can minimize time at work and maximize everything else, great. Fulfillment is the goal. How you get there is up to you.

But for me personally, I do want to optimize my career around fulfillment. I like being productive. I like making progress toward things. So I want to make sure that, for a large chunk of my life, I’m doing work that feels worth doing.

What Alignment Actually Looks Like

Here’s something I’ll be honest about: I don’t know that I would have predicted what would feel aligned for me until I was in it.

Early in my career, I got into digital forensics. I was very fortunate that things lined up the way they did -- there was too much serendipity for me to take much credit for it. But that work was deeply fulfilling in a way I don’t think I’ll easily replicate. There was a sense of impact that felt very real and very direct.

Now I’m at Microsoft, working on the routing plane for Office 365. The scale is completely different. Orders of magnitude more scale. And because of that scale, even small things can have massive impact. We were talking recently on one of my teams about a C# optimization -- something on the order of 1% reduction in memory allocations for a particular path. On its own, that sounds like nothing. But at the scale this service runs, that 1% ripples out to millions of users. The numeric impact is way larger, even if the perceived impact feels different.

Neither of those experiences is objectively better. They’re just different ways fulfillment can show up. The question is whether you take the time to notice.

The Manager Angle: Always Explain the Why

I haven’t talked about this in a while, but as an engineering manager, this concept of alignment plays out in a really concrete way for me. And I want to share it because I think it applies whether you’re a manager or an IC.

In most engineering conversations, we focus on the what and the how. What’s the feature? What’s the architecture? How are we going to implement it? What are the constraints? Those conversations are totally valid and necessary. But there’s a gap.

The gap is why.

Why does this work matter? “It moves this metric from point A to point B” is not why -- that’s a measure. The why is what the metric actually represents for users, for the team, for the broader mission.

I’ve told engineers on my team explicitly: if at any point you don’t understand why we’re doing what we’re doing, tell me. It’s not a confrontational thing. It doesn’t have to be “I think this is dumb.” It can just be “I know what we’re building and how, but I’m missing the bigger picture of why it matters.” I want that conversation to happen. Because if people don’t get why, they stop seeing how they’re contributing to something meaningful -- and over time, that erodes engagement.

Actionable Tip: If you’re a manager or lead, don’t just share the what and how with your team. Zoom out regularly and explain why the work matters -- how it connects to users, to the mission, to something real. It’s not about making every task feel earth-shattering. It’s about helping people see the bigger picture.

What Should You Do If You’re Not Feeling Aligned?

Back to that Redditor. They’re not aligned with what their company does, they’re not engaged, and they’re wondering if they should brush up on their resume.

My take: yeah, look around. But that doesn’t mean you have to rush out the door. If the current situation isn’t actively negative -- you’re being treated fairly, the pay is reasonable, it’s not toxic -- then you don’t need to panic. But I’d absolutely encourage shopping around. The only cost is your time, and that’s yours to decide how to spend.

Actionable Tip: Do an honest reflection on what engages you and what doesn’t. Think about the industry, the tech, the team culture, the problem space. Think about what you do outside of work that you genuinely love. You don’t have to go find a job in exactly that space -- but you might notice patterns about what kinds of problems and environments light you up versus drain you. Use that as a filter when evaluating opportunities.

For that Redditor -- and for anyone in a similar spot -- the reality is that if you fundamentally don’t care about what your company does, you’re probably not doing your best work. Not because you’re lazy or uncommitted, but because that underlying engagement isn’t there. The only motivation left is the paycheck, and that sustains you for a while, but it’s not enough to fuel your best output over the long haul.

Wrapping Up

None of this is me telling you your career needs to be your entire source of meaning. It doesn’t. But if you’re going to spend a huge chunk of your life working, it’s worth asking whether the work you’re doing is pointing you toward something you actually give a damn about.

The things that engage you will shift over time. That’s fine -- that’s expected. The goal is to stay aware of what those things are and make deliberate choices, rather than just drifting from one unaligned role to the next.

If you’ve got questions about this stuff -- career decisions, engineering management, whatever -- you can always head over to codecommute.com and submit anonymously.

Share

Leave a comment

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Communication responsibility lands on you, not your audience

• Think from their perspective -- not yours

• Metaphors bridge the technical and non-technical gap

• No livestream this week, sorry!

The Real Gap Between Good Developers and Great Ones

I’ve come to believe that the biggest gap between good developers and truly great ones isn’t technical skill. It’s communication. Specifically, the ability to communicate technical ideas to people who don’t share your technical context. I talk about this topic a lot across different videos and articles, and there’s a reason for that -- I genuinely think communication is at the heart of most of the problems I see in software engineering. Sure, we’re solving technical challenges every day. But the real blockers? The frustration, the missed deadlines, the misaligned expectations? Those almost always trace back to a failure to communicate effectively.

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

The Responsibility Is On You

Here’s the uncomfortable truth: when you’re trying to communicate information, the responsibility for doing it effectively falls on you. Not on your audience.

I see this go wrong all the time. Someone’s trying to explain something technical, it’s not landing, and the reaction is “well, maybe they’re just not getting it” or “I don’t know why they can’t understand this.” We look outward for the problem. But when you’re the one trying to share information, how well it lands is your problem to solve.

Now -- to be clear -- this goes both ways in a conversation. If someone is communicating back to you, they have responsibility on their side too. But when you are the one trying to convey an idea? That’s on you. And I think accepting that is genuinely liberating, because it means the outcome is something you can actually influence.

Know Your Goal -- And Theirs

Before you walk into any conversation with a non-technical stakeholder, ask yourself: what am I actually trying to accomplish here? And I don’t mean “explain a technical thing to a non-technical person.” I mean the actual goal. Are you trying to justify why something is going to take longer than expected? Are you communicating why technical debt needs to be addressed? Are you giving a post-incident readout to someone who then has to relay it upward to leadership?

The goal frames everything.

Actionable Tip: Write down the one thing you want your audience to walk away believing or understanding after the conversation. If you can’t state it in a sentence, you probably need to keep refining your thinking before you open your mouth.

Once you know your goal, here’s the secret: stop thinking about it from your own perspective. Flip it around. Think about what your audience cares about. What matters to them in their role? A project manager cares about different things than a UX designer, who cares about different things than a VP of Engineering. Yes, there’s overlap -- hopefully everyone cares about the customer -- but the lens through which they see the world is different. And the more time you spend with people in different roles, the better your intuition gets for what they’re going to gravitate toward and what’s going to lose them.

Levels of Indirection Kill Technical Detail

Let me use an example. Say there was an incident -- a bug in production. Things were mitigated, code fixes went in, your team worked hard on it. You understand the changes inside and out. Now you need to brief your engineering manager, who then has to represent your team to senior leadership.

This is a double-whammy situation. You need to communicate to your manager in a way they’ll understand, and arm them with enough information that they can relay it one more level up, to people even further removed from the technical details.

Here’s what typically goes wrong: engineers walk in and start talking about the specific class that had the duplication, the if statement on line 37, the test project that was accidentally excluded from CI/CD. And the manager nods along, maybe, but now they’re expected to take that information and translate it for a VP or an executive. That doesn’t work. The more levels of indirection involved, the more the specific technical detail actually hurts rather than helps.

So what does your manager actually care about in this scenario? They want to know systematically what’s now in place. They want to understand that you’ve got testing coverage where there were gaps. That you have monitoring and alerting. That you’re leveraging the tools available to you. They don’t need to know exactly how many tests you added -- they need to know that the gap in coverage has been closed.

Actionable Tip: One exception: if there’s a single specific detail that is the “smoking gun” -- the one thing that explains why the incident happened -- it’s okay to bring that in even to a non-technical audience. I’ve been in executive-level post-mortems where the right answer was “we had all the right things in place -- monitors, tests, staged rollout -- but this one alert had the wrong threshold, and that’s why we missed it until traffic built up.” That’s concrete, understandable, and builds confidence. Use the smoking gun detail when it exists.

Metaphors Are Your Secret Weapon

So, how do you actually make your communication land? One of the most effective tools I’ve found is metaphors and comparisons. I don’t have a neurological explanation for why this works so well -- but it does. I think it has something to do with how our brains recognize patterns and anchor new concepts to things we already understand. When you can explain something by mapping it to a frame of reference the other person already has, it clicks in a way that a direct technical explanation just doesn’t.

Here’s an example I worked through. Imagine you’re talking to a UX designer. You need to explain that a design change they want is going to be much more complicated to implement than it looks, because the codebase has a lot of duplication -- many places that would all need to be updated individually.

From their perspective, they’re thinking: just go make the change in those spots. What’s the big deal?

Instead of explaining code duplication, try this: ask them to imagine they’re working in their design tool, but without any shared component library. No reusable buttons, no pre-styled elements -- everything is custom-drawn per screen. Now, imagine I asked them to change every button to have rounded corners. They’d have to click through every single design and make the change by hand -- and might not even be sure they’d found all of them.

That’s what I’m dealing with in the code.

Suddenly, they get it. They can feel why that’s painful. You mapped the technical problem to something they live every day. That’s the power of a good metaphor -- once you find the right one, the conversation shifts entirely.

The tricky part is that building good metaphors takes effort. You need to actually know something about the other person -- their role, their tools, what they care about. The more time you invest in understanding the people you work with, the better your instincts get for what will resonate.

Start With the Framework, Not the Steps

I want to be honest: I could give you a step-by-step checklist for communicating with non-technical stakeholders. But I deliberately didn’t go that route here. I think it’s more valuable to understand why the approach works than to follow a script. If you understand that your goal drives your framing, that thinking from their perspective matters more than your own, and that making ideas tangible through metaphors is incredibly effective -- you can adapt that to any specific situation you find yourself in. You’ll develop your own style, your own instincts, your own go-to examples.

That’s going to be better than any step-by-step I could ever write for you.

If you’ve got a specific communication scenario you’re wrestling with, head over to CodeCommute.com and submit it! I’m happy to work through the specifics. Talking about this generically can only go so far -- the real value is in concrete situations.

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Start with the problem, not the solution

• Define success in the role before writing questions

• Hiring is imperfect -- iterate and build the skill

• Join me for the live stream (or watch the recording) on Monday, March 2nd at 7:00 PM Pacific!

How Do You Hire When You Aren’t Even the Expert?

I came across two Reddit posts recently that both circled around hiring. Different scenarios, totally different contexts -- but my instinct for tackling both was the same. And I figured it was worth sharing, because I think a lot of people jump straight to “how do I interview for this?” when they should actually slow down and answer a different question first.

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

The Two Scenarios

The first post was from a CTO with six engineers who was trying to hire their first engineering manager. The comments were... not kind. A lot of people were like, “you only have six people, why do you need an EM?” Which, fair point on the surface -- but we don’t have enough context to know if that’s actually true. Maybe they’re growing fast. Maybe the CTO has other responsibilities pulling their attention away. Maybe they’re just trying to get ahead of the scaling pain before they’re drowning in it.

The second post was someone asking: “How do you hire or interview for a role that you don’t have experience in?” Someone on their team had left, and now they’re responsible for backfilling that gap -- even though they don’t have the skill set themselves.

On the surface, these look completely different. But the framework I’d use to approach both of them is identical.

Step Back and Ask: What Are You Actually Trying to Solve?

Before you even think about interview questions or job postings, I want you to pause and ask yourself -- what problem am I actually trying to solve here?

In the EM scenario, the person is presenting a solution (”I need to hire an EM”) without fully articulating the problem. And that matters, because the right solution depends heavily on what the actual gap is.

Are your direct reports not getting enough time and attention from you? Is coordination of deliverables falling apart? Is there not enough time being spent with customers and stakeholders? Each of those problems might point to a different hire. An EM, a project manager, or even a product manager could all be the right answer depending on what’s actually broken.

If you don’t know what’s broken, you’re optimizing for a job title, not a solution. And that’s a recipe for a hire that doesn’t move the needle.

Actionable Tip: Before writing a job description, write a problem description. One paragraph -- what is not working right now that this role is supposed to fix? If you can’t write that paragraph, you’re not ready to hire yet.

Defining What the Role Actually Looks Like

Okay, let’s say you’ve done that work and you’ve confirmed: yes, what you need is an engineering manager. Now what?

You need to figure out what you actually expect from this person in this role. Because “engineering manager” means wildly different things at different companies, different team sizes, different growth stages. The classic debate everyone loves to have: should EMs code?

My take: if you have a small team, absolutely -- find ways to contribute hands-on. When you’ve got six engineers, there’s a real case for the EM being in the code with the team. It doesn’t scale as the team grows, but at that size it often makes sense. The point isn’t whether they’re technical -- it’s whether the team benefits more from their hands-on contribution or their coordination and people work at that specific moment in time.

So you need to ask yourself: what are the core responsibilities I’m hiring for in the short, medium, and long term? And then structure your interviews around those things.

For example, if you’re hiring an EM at a small startup where you know they’ll be expected to code alongside the team, you’d better have a technical component in the interview. You need to know they can build software -- not just manage the people building it.

If you’re hiring an EM because you’re about to scale from 6 to 12 engineers and you know they’ll be spending a lot of their time recruiting and onboarding, the emphasis shifts. You’re probably less focused on their coding chops and more focused on their ability to build and grow teams, run hiring processes, and develop people over time.

The role definition drives the interview design. If you skip the role definition, you end up asking generic questions and hoping for the best.

Subscribe now

When You Don’t Have the Expertise Yourself

The second scenario is a little more raw -- you literally don’t have the skill set being hired for. So how do you gauge a candidate when you can’t evaluate their technical answers?

Same starting point: what does success look like in this role?

Let’s say you need to hire an Android developer. Your team has never built an Android app. You don’t know Kotlin, you don’t know the Google Play ecosystem, none of it. How do you know if someone’s answer to your question is actually good?

Here’s the reframe I’d offer: are you going to know if their answers are good after you hire them? Probably not immediately either. You’re not going to suddenly become an Android expert the moment they sign the offer letter. So the goal isn’t to design interview questions that prove to you in the moment that this person is an expert -- you can’t do that if you’re not an expert yourself.

What you can do is think through what success in this role looks like, and then ask questions that surface the traits and behaviors that point toward that success.

In the Android example, if success means:

• Going from zero to a published app

• Actively sharing knowledge with the rest of the team

• Owning Android security for the platform

...then your interview questions should probe for those things. Can they talk through how they’ve taught others on previous teams? Can they give examples of how they approached security decisions on a platform they owned? Do they have examples of leading a greenfield platform from scratch?

Actionable Tip: Write out three to five things that would make this person clearly successful in their role six months in. Now ask yourself -- do my planned interview questions actually tell me anything about those things? If the answer is no, redesign the questions.

Subscribe now

This Is an Imperfect Process -- And That’s Okay

I want to be honest with you: this framework doesn’t magically solve the problem. Hiring is messy and imperfect, no matter how well you prepare.

What defining the role and the success criteria does is make sure you’re asking questions in the right direction. You might not nail the evaluation of every answer. You might misjudge a candidate. You might make a bad hire even after doing this work. But at least you’re not going in completely blind, asking generic questions and hoping someone impressive shows up.

And honestly -- hiring is a skill. It gets better with reps. The first time I had to hire for a role I wasn’t deeply familiar with, I made a lot of mistakes. But each time you do it, you get a better sense of what signals actually matter and what questions actually surface them.

The minimum viable step is knowing what you’re trying to accomplish. Everything else -- the specific questions, the interview structure, how you score responses -- you iterate on over time.

So if you’re in one of these situations right now: don’t panic. Step back, define the problem, define success, and then build the interview around that. It won’t be perfect. But you’ll be heading in the right direction.

Share

Leave a comment

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Context shapes everything

• Stop optimizing for the perfect plan

• Know your stakeholders deeply

• Join me for the live stream (or watch the recording) on Monday, February 23rd at 7:00 PM Pacific!

Why Everyone Seems to Have a Different Opinion on Planning

I want to talk about planning in software engineering -- and more specifically, why people seem to have such wildly different takes on it.

Here’s something I’ve noticed. You come across someone who’s had a successful career, and they describe how they do planning. Makes sense, you note it, maybe you try to apply it. Then you find someone else -- equally successful, equally confident -- doing it in a completely different way. And you’re left thinking: how are both of these people right?

The answer is almost always context. When people share their perspective on planning, they almost never include the environment that shaped that perspective. And that missing context is what makes everyone sound like they’re contradicting each other.

Think about someone who spent their career building satellite infrastructure or delivering government contracts. Their planning approach is going to look fundamentally different from someone who built a scrappy startup from scratch. Both of them are right -- they’re just responding to completely different constraints, completely different risks. If you pulled both people into the same room and actually mapped out what they value and what they’re trying to optimize for, I’d bet there’s a lot more overlap than it first appears. The differences come from the environments that shaped their thinking.

I wanted to get that framing out of the way first, because everything I’m about to say is colored by my own experience. Two data points: Magnet Forensics, a startup where I joined at around seven or eight people, and left when we were around 250. And Microsoft, where I’ve been for over five years, working on the Microsoft 365 / Office 365 side of things. These are just two examples -- they do not represent all startups or all of big tech. Keep your own environment in mind as you read.

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

What Planning Looks Like When You’re Drinking From the Fire Hose

In the very early days at Magnet Forensics, planning basically didn’t exist. Everything was the highest priority. A customer requested a feature? Drop everything, go build it. A bug got reported? Drop the feature, go fix the bug. Ship the bug fix and accidentally break something else? That’s tomorrow’s surprise.

It was chaos. And honestly, for where we were, it made some sense. You can’t really plan two weeks out when you’re still figuring out if anyone’s going to use your product.

One of the things I spent real effort on during that era was managing escalations. The CTO cared deeply about his customers -- this was his product, built from scratch out of necessity, and he was fiercely proud of it. When something got escalated to him, it was the most important thing in the world. My job was to come to him with a full picture -- here’s everything on our plate, here are all the other priorities, here are the tradeoffs -- and then ask: knowing all of that, do you still think this is number one? Over time, those conversations got shorter because we built mutual trust and a shared understanding of what mattered. He’d see the full picture and more often than not land at “yeah, okay, carry on.”

Gradually, we introduced sprints. Two-week sprints. And I’ll be honest -- even that felt like overkill at first. Two weeks out? We’re going to be doing completely different things by then anyway. But we built the habit. First two weeks, then a bit further, eventually quarterly.

The goal was never to nail the plan perfectly. The goal was to build the muscle of looking further ahead.

By the time I left, we were working with OKRs -- Objectives and Key Results. I have mixed feelings about the framework itself. People waste an absurd amount of time debating the wording and structure of key results. But the underlying concept is something I genuinely believe in: you’re setting a goal to move a metric, not to ship a specific feature. The how is for you to figure out. The key result is the destination -- reduce latency, improve onboarding rate, move some number from A to B. How you get there can change along the way.

And that’s the thing: the most valuable planning conversations we had weren’t about shipping dates and locked deliverables. They were about alignment. Are engineering and product actually pointing in the same direction? Are we measuring success the same way? What does “done” actually mean here? Those conversations moved the needle. The hours spent trying to lock in dates and enforce commitments? A lot of that was wasted energy.

How Planning Changes at Scale

At Microsoft, planning is a completely different beast. We do semester planning -- six months at a time. And because of the sheer number of teams and dependencies involved, you often need to be thinking about the next semester while you’re still planning the current one.

The reason is dependencies. When you’re working at platform scale, getting anything meaningful done usually requires another team to deliver something first. If you don’t get ahead of that conversation early -- if you’re not on their roadmap before they lock in their plans -- you’re going to be blocked. So you’re always playing this forward-looking dependency game: who do we need things from? Who’s depending on us? How far ahead do we need to start those conversations to actually have a shot at being unblocked in time?

The challenges, though, aren’t that different from a startup.

Plans change. Priorities shift. At Microsoft, if something critical surfaces in the security space, that jumps the queue -- full stop. It needs to. That’s the job. The difference is scale: at a startup, telling someone your plans changed might mean a conversation with one product owner. At Microsoft, it might mean fifteen other teams just got their plans disrupted.

Actionable Tip: Know your stakeholders -- not just who they are, but what they’re trying to accomplish and what they’re depending on you for. When your plans shift (not if -- when), getting ahead of it as early as possible lets you work with your stakeholders to adjust. The surprises that derail projects aren’t usually the changes themselves; they’re the changes people find out about way too late.

I’ve seen this play out firsthand. You’re three months into a six-month plan. A partner team drops something on you: “Hey, by the way, we’re not going to hit our commitment -- just so you know.” And when you dig in, there were signs of this two months ago. The communication just never happened. That lag is what causes damage.

Stop Trying to Make the Plan Perfect

Here’s my biggest takeaway from all of this: the goal shouldn’t be to build a plan that never changes. The goal should be to build a team that handles change well.

I’ve watched organizations pour enormous amounts of time into making the plan airtight -- anticipating every dependency, locking in every date, getting every commitment in writing. And then something unexpected happens (as it always does), and a lot of that effort evaporates.

I’m not saying don’t plan. Plan. Have a direction. Have milestones. Have a roadmap. But be honest about what you’re actually optimizing for. If most of your planning energy goes toward “how do we stick to this plan no matter what,” that’s the wrong optimization.

Instead, here’s what I think is actually worth your time:

• Get alignment on direction and success metrics -- not just which features you’re shipping, but what you’re trying to move and why

• Map your dependencies early -- both what you need from others and what others need from you

• Communicate early and often -- if you’re falling behind, say so now, not three months from now

• Build agility into the plan from the start -- leave room to adjust, because you will need to

The OKR concept captures a lot of this well, even if the framework itself can get annoying. You set a goal to move a metric from A to B. How you get there can flex. What you’re trying to achieve stays consistent. That consistency -- the direction -- is what you’re really protecting when you plan.

Your Environment Is the Variable

Let me close with the thing I opened with: context.

How much planning you need, how rigid it should be, how far out you should look, how much agility to build in -- all of it depends on where you’re working. A ten-person startup looks nothing like a platform team at a large enterprise. A company with physical products and multi-year contracts looks nothing like a cloud security team shipping continuous updates.

Neither approach is right or wrong. They’re both responses to different constraints and different risks.

So the next time you hear two engineers give completely different answers about how planning should work -- and both of them swear by their approach -- before deciding one of them is wrong, ask what environment shaped that perspective. I’d be willing to bet there’s more common ground than it first looks like.

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Legacy systems are some of the most real software engineering

• Saying “AI tools don’t work here” might be a cop-out

• Someone has to bridge the communication gap, and it might need to be you

• No livestream this week, sorry!

Stuck Maintaining Legacy Code -- Now What?

I saw a post on the ExperiencedDevs subreddit that I think a lot of us can relate to. A developer is the sole maintainer of a legacy .NET application. They’re dealing with brittle code, zero test coverage, and a product manager who doesn’t seem to understand the challenges. Oh, and to top it all off? The PM is telling leadership that this developer isn’t using AI tools and that’s why things are slow.

Spoiler: the developer says they ARE using AI tools.

There are a few different angles I want to unpack here, because this scenario hits on so many things at once. Legacy systems. AI tool adoption. And the communication gap between engineers and PMs. Let’s get into it.

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

Legacy Systems Are REAL Software Engineering

Here’s the thing that bugs me when people say, “I’m just maintaining legacy code, it’s not real engineering.” That is sometimes the most real software engineering, because you have some of the worst constraints to work within, and you have to get creative.

Think about it. You’re working in a codebase where:

• There’s little to no test coverage

• Everything is tightly coupled

• You touch one thing and five other things break

• The “tribe” that built it has long since disappeared

And in this person’s case, they’re not just doing bug fixes -- they’re actively developing new features on top of this. That’s a completely different ballgame. If you’re just patching a system that’s end-of-life, you might get away with minimal fixes to keep things running. But if you’re adding features? People are paying for this. The product might be legacy from a code perspective, but it’s not legacy from a product perspective.

If you’re wondering where to even begin with this kind of situation, I’ve written about refactoring legacy code and what you need to be effective -- it’s a good starting point for thinking about how to approach these codebases.

So what do you do?

Start Building Confidence Through Tests

You need to work towards having test coverage that gives you confidence. And that might mean writing tests you don’t love.

Here’s what I mean. I like writing code that can be unit tested -- almost in isolation from everything else. But in a lot of legacy systems, including ones that I wrote that became legacy, the code was not designed that way. Dependencies aren’t mockable. Concerns aren’t separated. That whole class of tests? Just not available to you.

So you go to the other end of the spectrum. Big integration tests. Maybe even UI tests that click through the application. Are they brittle? Absolutely. But if you can get some tests in place that cover your number one use cases -- the things that absolutely cannot break for your users -- you now have some confidence.

I’ve talked about dealing with legacy code and how to make anything more testable if you want a deeper dive on practical strategies for this. The key idea is that you don’t need perfect tests -- you need tests that give you a signal.

And by the way -- don’t be fooled by coverage numbers alone. I’ve written about why test coverage can be misleading and how to avoid false confidence. High coverage with low-quality tests can be worse than no tests at all because it gives you a false sense of security.

Actionable Tip: Start with confidence-building tests, even if they’re ugly. Cover your most critical user flows first. As you refactor, you can replace the crappy tests with better ones. But having something is way better than having nothing. Here’s what I’d actually recommend as a starting point:

1. Identify your top 3-5 user workflows -- the ones that, if they broke, would generate support tickets or lose customers

2. Write end-to-end tests for those -- even if they’re slow, brittle, or ugly

3. Use those tests as a safety net while you start refactoring the code underneath

4. As you refactor, add focused tests at lower levels where you can

The point is: start introducing mechanisms to get confidence. Then, as you refactor and clean things up, you can write better tests and eventually ditch the ones you don’t love. If you’re working in a .NET codebase specifically, check out my article on refactoring C# code with 4 essential techniques for some practical patterns.

AI Tools “Don’t Work Here” -- Really?

Let’s pivot to the AI tool situation. This developer says they’re using Gemini, which is great. But then they mention having access to Cursor and saying something like “Cursor can’t work on legacy .NET projects.”

I have a challenge with statements like this.

Look, maybe Cursor isn’t the most effective tool for this specific scenario. But saying it can’t be used? That feels like a cop-out to me. I’ve used Copilot CLI to build legacy .NET projects -- not with dotnet build, but with Visual Studio tooling on the command line. No UI. It worked.

You can build on the command line. When you start having tests, you can run your tests on the command line. Cursor can go through files on a file system. If you can trigger your build from the command line, there’s a path forward -- even if it’s not the polished IDE experience you’re used to.

I actually wrote a practical guide on getting started with AI coding tools that covers how to think about tools like Cursor, Copilot, and Claude in different development contexts. The reality is that these tools aren’t all-or-nothing -- you can use them for specific parts of your workflow even if they can’t handle everything.

For legacy codebases specifically, here are some concrete ways AI tools can help even when the project structure isn’t ideal:

• Understanding unfamiliar code -- paste a class or module and ask “what does this do?” before you start modifying it

• Generating test scaffolding -- even if the tool can’t run the tests, it can help you write the boilerplate for test setup

• Exploring refactoring options -- describe what a piece of code does and ask for suggestions on how to decouple it

• Documentation -- generate documentation for undocumented legacy code so the next person (or future you) has context

Actionable Tip: Don’t rule out tools because they don’t work the way you expect. Get curious about finding ways to make your tools effective for you. The more familiar you get with what tools are capable of -- and how to use them in different scenarios -- the more options you have.

At work, you might not have the freedom to pick whatever tool you want. I get that. But within the tools you do have access to, there’s probably more you can squeeze out of them than you think.

Bridging The Communication Gap

Now for the part that I think matters the most: the relationship between this developer and their PM.

We have two people saying different things. The developer says, “I AM using AI tools.” The PM is telling leadershi,p “this person isn’t using AI tools, that’s why things are slow.” The truth? It’s probably somewhere in the middle.

This developer is probably using AI tools. But are they using them effectively? That’s open for debate -- and I’m not saying that to be harsh. They’re already acknowledging that some tools don’t work well for their scenario, and I’ve just argued that I think they could push harder on that front.

From the PM side? They’re probably right that things are behind their expectations. The reasoning they’re giving might be wrong, but the core observation -- that delivery isn’t where they want it -- is probably true.

Someone has to bridge this gap. And it sounds like it hasn’t been either person up to this point.

If I knew someone was saying things about me that I didn’t believe were true, I’d confront them. Not aggressively -- but I’d need to get to a point of truth. I’d make time and say something like: “Hey, I will show you how I’m using AI tools. If you think I’m not, let me demonstrate.”

But clearing that up alone won’t solve the problem. These two people need to work together to figure out what they need from each other.

Communication is one of those soft skills that engineers often undervalue, but it makes or breaks your ability to operate effectively on a team. And it’s not just about talking more -- it’s about talking in ways that land with your audience.

Actionable Tip: Before you go into a conversation like this feeling defensive, try preparing with these three things:

1. A demo, not a debate -- Show your PM exactly how you’re using AI tools. Screen share, walk them through your workflow. It’s a lot harder to argue with a live demonstration.

2. An honest self-assessment -- Are there areas where you could be using tools more effectively? Acknowledging that proactively builds trust and shifts the conversation from “are you doing it?” to “how can we do it better?”

3. Questions, not accusations -- Ask your PM what success looks like to them. What timelines are they working against? What are they being asked to deliver? Understanding their constraints helps you propose solutions that actually work for both of you.

Talk About Systems, Not Classes

Here’s something practical: as an engineer, you might totally understand why things are brittle. You know that Class A is coupled to Class B, which is coupled to Class C, and touching any of them cascades. But your PM? They don’t know that. And talking to them about classes and methods is not going to help.

Instead, uplevel the discussion. Talk about feature areas. Draw some higher-level block diagrams. Say something like: “Hey, some of the logic for this feature lives here, but it’s actually spread across these other areas. If I touch one, we’re going to see problems across all of them. And right now, I have nothing that tells me when that’s going to happen.”

That’s something a PM can understand and reason about. It gives them the context they need without drowning them in implementation details.

This is actually the same skill that I see trip up engineers when they’re working with junior developers -- the ability to adjust your communication to your audience. You wouldn’t explain coupling the same way to a PM as you would to a senior engineer. Meeting people where they are is how you actually get alignment.

If you’re dealing with technical debt specifically and need a way to frame those conversations with leadership, I’ve written about how to balance technical debt in a way that connects engineering concerns to business outcomes.

Actionable Tip: Try to understand what your PM needs. They have goals, expectations, and things they need to report on. If you can understand their motivations, you might find that how they’re approaching things isn’t effective for you -- but the why behind it makes sense. And then you can propose alternatives that work better for both of you.

Here’s a framework that has worked for me when bridging these kinds of gaps:

• Translate risk into time -- instead of “this code is tightly coupled,” say “changing this feature has a 50/50 chance of breaking these other two, and debugging that takes 2-3 days each time”

• Propose trade-offs, not ultimatums -- “We can ship this feature in 2 weeks, or we can spend 1 week stabilizing first and ship in 3 weeks with fewer bugs after. Which would you prefer?”

• Make the invisible visible -- track the bugs caused by coupling, the time spent on regressions, the incidents. Data changes conversations.

Wrapping Up

Legacy systems are challenging. AI tools in constrained environments are challenging. Working with someone who doesn’t seem to understand your reality is challenging. But none of these are unsolvable.

Start building confidence through tests -- even ugly ones. Get creative with the tools you have -- don’t dismiss them before you’ve really explored what’s possible. And put in the effort to bridge that communication gap -- even when you don’t want to. Especially when you don’t want to.

If you want to go deeper on any of these topics, here are some resources:

• Refactoring Legacy Code - What You Need To Be Effective

• Dealing With Legacy Code - How To Make Anything More Testable

• Getting Started with AI Coding Tools - A Developer’s Practical Guide

• Software Engineering Soft Skills - 6 Focus Areas That You Need

I wish this person all the best. Legacy systems are a lot of fun in their own way -- lots of interesting constraints and lots of interesting challenges.

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!

TL; DR:

• Software rewrites are almost ALWAYS underestimated

• The “all or nothing” approach is the most dangerous trap

• The Strangler Fig pattern lets you rewrite incrementally and safely

• Join me for the live stream (or watch the recording) on Monday, February 9th at 7:00 PM Pacific!

Why Do Software Rewrites ALWAYS Take Longer Than Expected?

I saw a post on the ExperiencedDevs subreddit that really resonated with me. Someone pointed out that after about 8 years in the industry, every single rewrite they’ve seen has taken significantly longer than teams planned for. And for some reason, people always act surprised.

Spoiler alert: that’s also been my experience.

And I’m not talking about being a little bit off. I’m talking about -- if someone tells me “it’s going to take us X amount of time to rewrite this,” I would at least double it. If they say a year, I’m saying two years. At least. That’s just based on my own lived experience with various rewrites across my career.

Now, my goal here isn’t to say “a rewrite is the devil, never do it, never consider it.” It’s just that I think a lot of the time, rewrites are approached as this silver bullet solution for all the problems we have -- and the amount of time and complexity to pull it off gets grossly underestimated. You can check out my full thoughts on this in the video below:

Why Teams Push for Rewrites

So what motivates a rewrite in the first place? In my experience, it’s usually the engineering team that’s driving it -- not the business. And I think one of the big reasons is knowledge dispersion.

When you have these really large or complex systems, no single person knows everything about the system. As systems grow and scale and age, people on teams change. The knowledge about the system becomes inconsistent -- there are gaps. Some people know some parts, no one knows everything, and certainly everyone doesn’t know everything.

When you have that kind of disparate knowledge, it becomes easy to rally behind the idea of: “Well, if we just start from something we all agree on, we can make this better.” You know there’s a problem. There’s that big god class that’s super legacy and brittle and no one seems to be able to touch it. And so the thinking is: we can solve this. We can be the ones that make it better. We’ll also fix this problem of legacy code that no one really understands.

And look -- it’s hard to argue with that on the surface. It seems logical. Given the severity or complexity of some structural issues in a codebase, I can certainly see why people would be motivated to do that. I’ve literally been part of conversations where I’ve felt motivated to say, “Man, if we just didn’t have this thing here, we could do this so much better.”

The Two Clean Slates Problem

But here’s where things start to fall apart.

When people say “rewrite,” it usually means everything. Starting from scratch. You get this green field from an engineering perspective to go do all the right things -- get it right this time.

The danger from the business side? When you have systems or products that have been around for a long time, there are a lot of features and functionality that exist. Hidden menus that you never thought about. Some users that absolutely depend on those menus, buttons, or workflows. There’s all this knowledge and history that went into getting those flows together.

So what happens is you end up with two clean slates:

1. A clean slate from a code and architecture perspective

2. A clean slate from a feature parity perspective

Engineers focus on how they’re going to solve all the problems technically -- the architecture, the infrastructure. So much attention goes there. But there’s not enough conversation around parity -- what needs to happen in terms of usability, migration strategies, and communicating changes to users. And I feel like that’s a huge miss almost all the time.

Subscribe now

The Resource Split

Beyond that, we’re dividing resources. If you have a legacy system that’s running that users are paying for, and you start a rewrite, you have to split resources somehow.

You could move everyone to the new thing to get it done as fast as possible. But while that’s happening, you have paying users who may have issues, who may be hoping for feature updates on a cadence they’ve come to know and love -- and that’s not getting attention.

Or you keep some people back on the legacy system. Now you’ve got the overhead of managing two groups focused on different roadmaps, different priorities, and you’re not prioritizing the rewrite as much, so it’s going to take longer.

There’s a spectrum of how you split resources -- people and time. I’m not saying there’s one right answer. I’m just saying this is a huge factor in complexity that also gets grossly underestimated.

The Scary Trap

The scariest trap I see with this stuff? Say you go all in on a rewrite. There’s excitement in the beginning because everything’s new. Tons of momentum early on because things are being stood up. Then a bit of a lull. Then things come together and you start getting more momentum again.

But as time elapses, you start realizing: “Hey, I know we said we’d build the architecture perfectly this time, but as complexity gets added with new feature sets... oh, we didn’t factor this part in.” So the architecture has to change a little bit. And it keeps happening. Now your pristine architecture is starting to get some cracks in it.

And then people in product start looking at what’s being produced and going, “Wait, we didn’t account for this feature. There’s a gap here.” One more thing to add back in. And another. And another. The timeline keeps moving out.

And then you hit this point -- maybe multiple points -- where people are questioning: should we keep going?

That is the worst scenario to be in. You’ve made this conscious decision to go all in on something, and now you’re like, “What the hell are we going to do here?” This isn’t panning out to be perfect sunshine and rainbows. Because -- and this is the thing -- it’s software development. It’s never going to be perfect sunshine and rainbows.

To this person’s point in the Reddit post: why are we always surprised? You’re trying to rewrite something from scratch that took years to build. Software systems that took 3, 5, 10 years. We can’t even estimate feature deliveries in the order of days or weeks, and you’ve got a timeline for a full rewrite that you feel confident in? It’s completely crazy to think we’re going to get that right. Doesn’t mean it can’t be successful -- but it’s crazy to think there won’t be surprises.

Subscribe now

The Strangler Fig: A Better Way

So how are we doing this instead? Martin Fowler coined this term called the Strangler Fig a long time ago. He wrote about it in his Strangler Fig Application article, and the naming comes from these types of vines he saw in the rain forests of Queensland. These vines germinate in a nook of a tree, draw nutrients from it as they grow, and eventually become self-sustaining -- sometimes the original host tree dies and the fig remains as an echo of its shape. Martin saw this as a striking analogy for how we can modernize legacy software systems.

And here’s the thing that really stuck with me from his article: he points out that trying to do a simple replacement -- “we know what the old system does, so just build a new one that does exactly the same” -- goes down in flames most of the time. The alternative he and his colleagues prefer is a gradual process of modernization. Like the fig, it begins with small additions, often new features, built on top of yet separate from the legacy codebase. As you do this, you move bits of behavior from the legacy system into the new code.

The idea when it comes to rewrites is: instead of taking your entire product or service and going “we’re starting from zero,” you do it in pieces. You find ways to segment how you can start rewriting things. You build up the new pieces, and then you slowly start taking code paths and pointing them to the new parts. You start replacing parts of your system this way.

Instead of it being a full-on rewrite where you do an all-or-nothing thing, you incrementally rewrite chunks of the software.

How It Works in Practice

Take a set of microservices that all work together. Maybe a single microservice is the granularity of rewrite you go address. You stand up the new service, start sending some traffic to it proportionally, get it tested, get it working. Once you’re confident, you cut over all the traffic and cut out the old one. You didn’t rearchitect your entire system from scratch -- you picked one service.

If it’s not microservices and it’s modules in an application -- same concept, just a different transport. How can you start rewriting a module and cutting things over to it?

But How Do You Actually Break It Up?

This is where people often push back: “Okay, great concept, but how do I actually figure out where to slice?” Ian Cartwright, Rob Horn, and James Lewis wrote an excellent set of Patterns of Legacy Displacement on Martin Fowler’s site that digs into exactly this. They lay out four high-level activities:

1. Understand the outcomes you want to achieve -- Get alignment on what you’re actually trying to accomplish. Is it reducing cost of change? Improving business processes? Retiring old infrastructure?

2. Decide how to break the problem into smaller parts -- Find the seams in your current business and technical architecture. How does your big monolithic solution map to different business capabilities? Can you extract individual needs for independent delivery?

3. Successfully deliver the parts -- Use strategies like canary releases, event interception, or diverting flow to cut over from the legacy system incrementally.

4. Change the organization -- This one is huge. Legacy systems become rigid and brittle because the design thinking and organizational processes that produced them built them that way. If there’s no change in organizational culture, the new systems will end up in a similar mess.

One thing from that article that really hit home for me is their observation that technology is at most only 50% of the legacy problem. Ways of working, organization structure, and leadership are just as important to success. That lines up perfectly with what I’ve seen -- teams that only focus on the tech side of a rewrite and ignore the organizational side tend to end up right back where they started.

They also call out something I’ve lived through multiple times: the Legacy Replacement Treadmill. Organizations go through these 3-5 year modernization programs, and at some point during each one, changing business needs overtake their current tech strategy and trigger the need to start over. If they took a “big bang” approach, that means abandoning most of the work. Sound familiar?

The key insight is that you need to be able to build transitional architecture -- code that lets the new and legacy systems coexist, even though that code will eventually go away. People often balk at this because it feels like waste. But the reduced risk and earlier value from the gradual approach outweigh its costs.

Why I Like This

Is there overhead to developing this way? Yes. But that overhead affords you flexibility. If we can minimize the amount of overhead and still maximize the flexibility we get from it, that’s still aligned with my best interest in software development.

Think about it like waterfall versus agile. The idea with agile is having tighter feedback loops to make sure we keep steering in the right direction. The strangler fig approach gives you more opportunity for feedback. Yes, there could be more overhead, but instead of going completely off-course or misunderstanding your estimates, you do it in smaller chunks, get feedback, and adjust.

Subscribe now

Real Examples from My Career

I’ll give you two examples from my professional experience.

The Desktop Product: We had a SQLite database with a schema that was becoming really limiting. The amount of data had grown orders of magnitude, and our schema made working with that data a nightmare for new features. We started doing this data layer where we could share things in a new format -- kind of like the strangler fig approach for our data layer. But then we also just rewrote the entire product from scratch. We lived the problem: “Oh, users actually use this other thing this particular way and we didn’t think about that.” It was a nightmare. It was successful in the end, but I would do it completely differently if I had to do it again. I would absolutely try to build out modules and move things over to the new pattern over time.

The Service: We had a legacy service where making code changes was quite difficult, and performance was being squeezed to the max. A new service was introduced primarily to address performance constraints. As the new service was built up, scenarios were brought over incrementally. Traffic was directed to the new service, tested, validated. Then the next scenario, and the next one. Over time, all the legacy code paths went from being 100% called down to zero, until you could turn off the old one.

Both of these were successful rewrites. But even the one done incrementally was probably underestimated for how long it would take. The first one? Certainly underestimated.

The Takeaway

Trust that when people are talking about rewrites and estimating the scope, it’s going to be way off. Whatever you say with as much confidence as you have, double it. It’s going to be off if you’re doing a full rewrite.

But what I’d encourage you to do is figure out how to step back from an all-or-nothing approach and see how you can do it incrementally. You might find that you get far enough along and realize -- hey, maybe parts you wanted to rewrite? No one even uses them. Maybe you deprecate them instead of rewriting them. You will learn things as you go, and approaching it incrementally gives you the opportunity to do that.

There is overhead to doing things incrementally. But that overhead affords you the flexibility to avoid cutting off life support for something that’s literally the reason users pay or the reason your entire platform exists.

Incrementally is the way I recommend, if you can.

Share

Leave a comment

• Join me and other software engineers in the private Discord community!

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

• Remember to check out my courses, including this awesome discounted bundle for C# developers:

As always, thanks so much for your support! I hope you enjoyed this issue, and I’ll see you next week.

​Nick “Dev Leader” Cosentino
​social@devleader.ca​
​
Socials:
– Blog​
– Dev Leader YouTube​
– Follow on LinkedIn​
– Dev Leader Instagram​
​

P.S. If you enjoyed this newsletter, consider sharing it with your fellow developers!