TL; DR:

• Build the thing for yourself first

• A thin paid layer beats abandonment

• Free tools are still worth shipping

• No livestream this week. Sorry!

Why I Still Build Side Projects (And What I’m Building Next)

I’m twenty-plus years into programming and about fifteen years into my career, and I am still building side projects. That is not an accident, and it is not nostalgia. Building things is still the fastest way I learn, and it is still the advice I give to almost everyone who tells me their resume feels thin.

But something has shifted for me lately. I’ve gotten to the point where if I am going to sink my limited free time into building something, I should at least be open to the idea of charging a couple bucks for it. Not building a business. Not quitting my job. Just putting a very thin layer on the front of something I was going to build for myself anyway.

That small mental shift turns out to be a surprisingly good cure for the “ooh, shiny” problem that kills most side projects.

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

Twenty Years In And I Am Still Building

Whenever someone tells me their resume feels weak -- they’re not employed yet, or they’re junior and applications keep going nowhere -- my answer is almost always the same. Go build something.

It works for two reasons. The obvious one is that it gives you something concrete to talk about instead of a list of technologies you have “familiarity with.” The less obvious one, and honestly the more important one, is that building things is how you actually learn. Reading about a pattern and shipping something that depends on that pattern are completely different experiences.

I have written about this before in the context of why side projects and soft skills keep coming up in interviews, and I stand by all of it. But I want to be clear that this is not advice I give from a distance. I am still doing it.

Most of my side project time goes into BrandGhost, which is my main thing outside of work. It takes up enough of my attention that I have pushed other things aside for it -- including making videos on my main YouTube channel for a stretch. There are only so many hours, and something has to lose.

But there is always a pile of other stuff I want to poke at.

The Free Things I Have Already Shipped

Before I get into what I want to build, here is what is already out there for free, because some of you might actually find these useful.

Needlr is a dependency injection and assembly-scanning library I put together. It is extremely opinionated. I am not planning to sell it, and I am not trying to convince anyone it’s the one true way. I build basically all of my C# stuff with plugin frameworks, and that pattern kept showing up over and over, so I extracted it. If you want to use it, great. If not, that’s completely fine. If you want to see the shape of it, I have walked through building modular .NET applications with Needlr’s plugin architecture.

Homebase came directly out of frustration. If you spend any time on social media, you have clicked a hundred “link in bio” links that drop you on a landing page full of other links. Linktree is one of the platforms that does this, and I was a paying customer for a while. Then I hit a problem where video previews were rendering as black thumbnails. There is no good reason a YouTube thumbnail should just fail to show up. I opened a support ticket, got the runaround for about a month, and eventually thought: I pay for this, and I could just build it myself.

So I did, in roughly a weekend. Homebase is on GitHub, it is free, you can clone it or fork it, and it is optimized for SEO, AEO, and GEO. You can add product links and a bunch of other things. And if you’re wondering how to configure it -- you point Claude or Copilot at the repo, tell it where your stuff goes, and it handles the config files.

A few MCP servers for Google Search Console, Google Keyword Planner, and Google Analytics. Google did not have official MCP servers for these, which still surprises me. Mine are vibe coded, and I believe I have versions in both C# and Go because I wanted to mess around. They’re on my GitHub. I genuinely hope Google ships their own and makes mine obsolete. If you want to understand what is actually happening under the hood in one of these, I have a full walkthrough on building MCP servers and clients in C#.

None of those are businesses. They’re scratch-your-own-itch projects that happened to be useful enough to publish.

The Thin Paid Layer

Here is where my thinking has changed.

I have a problem that I suspect a lot of you share: I could go build this, or I could go build that, and then something shinier appears and I drift toward it. The half-finished graveyard is real. Most side projects don’t die because they were bad ideas -- they die because nothing forces them across the line from “sort of works on my machine” to “actually usable.”

A thin paid layer is the forcing function.

The idea is simple. Build the thing for yourself, because you actually want it. Get it to the point where you would use it. Then put a very thin layer on the front -- pay a couple bucks, here’s a license key, done. If people pay, awesome. If nobody pays, I still have the tool I wanted.

What I am explicitly not doing is turning every idea into a full-fledged business with a marketing site, a support org, and a roadmap. That is a completely different commitment and it is the thing that makes people avoid starting at all.

Actionable Tip: pick the side project you have abandoned closest to “done.” Define the smallest version you would personally use every week. Ship that, and only that. Whether you put a paywall in front of it is secondary -- the point is having a definition of finished that isn’t “everything I imagined.”

What I Actually Want To Build Next

These are all deeply opinionated, and you might read them and think “why would anyone pay for that?” That’s kind of the point. I am building them for me.

A modern MySQL Workbench with an LLM attached. Workbench is being retired, and from what I have read the plan is a lighter-weight experience inside VS Code. That’s neat, but personally I want the actual Workbench form factor -- just less dated. And the thing I really want is to give a read-only connection to an LLM and have it optimize queries with me. Connect with whatever access level you want (admin, write, read-only), poke at your data, and then have an agentic back-and-forth about query plans. I already do a version of this by giving Copilot read-only database access and letting it run EXPLAIN and look for optimizations. I just want it to be a real tool instead of a workflow I re-assemble every time.

A personal finance planner built for two people. My wife and I keep separate accounts but operate with full transparency -- the only exception being gifts we’re trying to keep a surprise. If she asks what’s in my 401k, the answer is just the number. We treat that stuff as ours. So I want something that pulls in financial data read-only across accounts and gives us a shared view plus a shared agentic session. She has really taken to using ChatGPT, so the idea is being able to ask questions like “where is most of our spend going?” or “how do the investments look?” against a central brain that can actually see across everything. If I build it, it will be configurable -- bring your own provider, or run a local LLM if you would rather your financial data never leave the house. I have no idea what the right form factor is yet.

A voice companion for GitHub. This is the one I’m poking at most actively. I feel like the GitHub app should do this and probably will eventually, but it doesn’t today. A big chunk of how I get work done now is creating issues and assigning them to agents. What I want is a push-to-talk companion -- the same interaction model you get in ChatGPT -- that lets me navigate all of that by voice. “What new issues came in today?” I have automation that scans BrandGhost error logs and files issues automatically, so there’s usually something. “Give me more detail on issue 123.” “Cool, assign that to an agent.” And then later: “Check in on that agent session -- did the PR land? Did it add proper tests?” The goal is being able to have that conversation without reading code. Maybe the answer isn’t even a dedicated app -- maybe it’s just wiring an existing assistant to my repositories through an MCP server. I need to play with it. If it does end up being a mobile app, it goes on the app stores.

A photo recovery tool. I used to work in digital forensics, and I spent about a decade building tools for exactly this. Since leaving, people still occasionally come to me with “I think these files are deleted, can you help?” -- and the funny part is I no longer have access to any of the tooling I helped build. I know how to build it again. Is that market saturated? Absolutely. But I have example code, it solves a real problem people bring to me, and there is no reason it can’t live on a website for a couple bucks.

Websites for non-technical friends. This one isn’t a product, it’s a favor I keep repeating. I have a close friend in the trades doing drywall and restoration work who is reasonably technical but would never spend the time to learn web development. He would get real value out of a proper site. I did the same thing for my video editor when he started a business on the side -- he has been fantastic about turning videos around when I hand them over late, so building him a site was an easy yes. The key detail is that I structure them so the owner can maintain them: copy a config file into ChatGPT, ask for the change, paste it back, done. I might start advertising that.

Why I Trust Agents With Some Of This And Not All Of It

The voice companion idea probably sounds sketchy to some people. “You’re just going to let AI do your work?”

Sort of. Here’s the honest breakdown.

There is a category of work where I trust an agent to go end-to-end, and it’s not blind trust -- it’s because I have built a lot of guardrails. File-based instructions that encode how the codebase works. Roslyn analyzers that enforce naming, null checks, and log validation so bad patterns fail at compile time rather than in review. Scoped custom agents and skills in Copilot CLI so each task runs with a narrow, well-defined job. The gates are what make the trust reasonable.

Then there is the other end of the spectrum. Big feature work, architectural changes, large refactors -- I’m not handing those over and walking away. I will still assign them to an agent and let it crank, but my expectation is not that it gets it right. My expectation is that I learn something from watching how it approaches the problem.

Sometimes there are genuine gold nuggets in there. Other times I look at the approach and immediately think “oh, that’s definitely not what I want” -- and that’s still valuable, because I often didn’t have a strong opinion until I saw a concrete option. Getting to “no, not that” without spending my own hours on it is a legitimately good trade.

Yes, it costs tokens. Yes, it costs someone’s compute. But it didn’t cost my evening.

My Best Ideas Show Up When I Can’t Act On Them

I don’t know if this is universal, but it is extremely consistent for me: my best ideas arrive precisely when I am nowhere near a computer.

Not at my desk. Not in a planning session. Walking, driving, at the gym -- suddenly I know exactly how to solve the thing I was stuck on last week, or a feature idea shows up fully formed. And then by the time I’m back at a keyboard, it has faded into something much blurrier.

That is honestly a big part of why the voice companion idea appeals to me so much. Not just “assign this issue to an agent,” but being able to talk through a half-formed idea out loud, argue with it a bit, and then say “open a GitHub issue on this repo with what we just worked out.” I have done exactly that with ChatGPT before, and the friction of translating it into the real repo is the only annoying part left.

Actionable Tip: whatever your capture mechanism is, make it require zero setup. Voice memo, a note that’s one tap away, a text to yourself -- it doesn’t matter which. The ideas you lose aren’t the ones you rejected, they’re the ones you never wrote down.

Might As Well Turn The Fun Into Something

The through-line for me is that I am going to keep building this stuff regardless. That was true before there was any chance of making a dollar from it, and it will be true after.

But I’m at a point in my career and my life where if I’m already spending the time, and the thing I built is genuinely useful, it seems a little silly not to put it somewhere people can find it. Worst case, nobody buys it and I still have the tool. Best case, a few extra dollars show up and I get a nudge to actually finish the next one.

That’s the trade I’m making. Build for yourself first. Ship the smallest usable version. Let the thin paid layer be the reason you cross the finish line instead of drifting to the next shiny thing.

So -- what are you building? I’d genuinely like to hear, especially if you’re leaning on AI to crank out something interesting. Let me know.

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:

• Learn before changing the system

• Clarify your authority and expectations

• Automate recurring release pain incrementally

Tech Lead in a Broken Team? What You Need to Do First

Imagine stepping into your first tech lead role and discovering that every release needs four to six hours of manual testing. Old bugs keep coming back. Delivery dates seem disconnected from the engineering effort. The team is overloaded, and overtime is starting to feel like part of the plan.

Where do you even start?

My answer is not, “Walk in and fix everything.” You do not have enough context yet, and trying to change the whole system immediately is a great way to burn trust before you understand why the system behaves this way.

You need to learn, align, build relationships, and then create momentum with one measurable improvement at a time.

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

Do Not Start By Rewriting The Team

When you inherit a struggling project, the problems are usually obvious before the causes are.

You can see the long manual test cycle. You can see the regressions. You can see the exhausted engineers and the aggressive delivery dates. What you cannot see yet is how the team arrived there, which constraints are real, and which previous attempts have already failed.

So the first move is observation.

Map out:

• How work enters the team.

• Who decides what gets prioritized.

• What “done” currently means.

• Where releases slow down.

• Which defects keep returning.

• What engineers believe is causing the pain.

• What product and management believe is causing the pain.

That does not mean you sit quietly for six months while everything burns. It means you avoid prescribing a solution before you can explain the system.

Your other immediate job is clarifying the role itself. “Tech lead” means wildly different things at different companies. Are you expected to make technical decisions? Can you push back on scope? Are you accountable for delivery? Are you coaching engineers? When should your manager step in?

Ask your manager directly. Keep asking as new situations come up. This is not a one-time onboarding question.

I also think your manager should not be surprised by the problems you are seeing. Share the observations, explain what you are trying, and be clear about where you need support.

Actionable Tip: bring your manager a short list of current risks, the evidence behind each one, and the first experiment you want to run. Ask which decisions you own and where they want to be involved.

Build A Working Relationship With Product

It is easy to walk into this situation and decide the product manager is the problem.

They keep pushing dates. Engineering keeps taking shortcuts. Quality drops. Therefore, product must not care about quality.

Maybe. But that conclusion is not especially useful, and you probably do not have enough information to make it anyway.

The product manager may be responding to customer commitments, revenue pressure, executive expectations, or information the engineering team does not have. At the same time, engineering may be carrying risks that product cannot see clearly.

That is exactly why you need the relationship.

There should be healthy tension between product and engineering. Product pushes for customer value and delivery. Engineering pushes for feasibility, sustainability, and quality. I have written about what happens when that healthy tension between product and engineering disappears.

Your goal is not to defeat the product manager. Your goal is to help both sides make better tradeoffs.

I have had working relationships change when schedules and responsibilities shifted. Even when I already knew the product manager, I still needed to make time to understand what they needed from me and how I could support them better. It is mutual. I want them helping engineering, and I need to help them succeed too.

Actionable Tip: set up a recurring conversation with your product partner. Ask what outcomes matter most, which dates are truly fixed, what risks they are carrying, and what engineering information would help them make better decisions.

Make Release Pain Visible

Four to six hours of manual testing before every release is a giant warning sign to me.

But you cannot simply delete that testing. The team is doing it because it catches defects. If you remove it without replacing the protection, you have not improved the process. You have just hidden the risk.

This is where the team needs to slow down enough to speed up.

Start by documenting every manual release check:

1. What behavior is being verified?

2. How long does the check take?

3. What defects has it caught?

4. Can that behavior be covered at a lower test level?

5. What is the smallest useful slice you can automate?

Do not wait for the perfect test architecture. If the code is tightly coupled and the only practical first step is a clunky behavioral test, write the clunky behavioral test. You can improve it later. The immediate goal is to stop the same regression from surprising you again.

Unit, integration, functional, and end-to-end tests all protect different boundaries. Understanding how unit testing and functional testing complement each other helps you avoid trying to solve every problem with one giant UI test suite.

I have lived this at a startup. We had enough technical debt that we needed UI-level behavioral tests before we could safely refactor parts of the application. A big chunk of that debt was mine, so I am not blaming anyone else. Those tests were not the final destination, but they gave us enough confidence to start changing the code underneath.

The manual release checklist should only get smaller. New regressions should produce new automated coverage, not another permanent item for a human to click through at release time.

Exploratory testing can still be valuable. Just do not make the hour before release the only time anyone explores the product. If you only look for surprises at the release gate, you will keep finding surprises at the release gate.

Dates And Engineering Effort Need An Honest Tradeoff

There is nothing inherently wrong with a fixed release date.

There is also nothing wrong with estimating a body of work and letting the date move.

The problem starts when scope and date are both treated as fixed while quality is expected to remain unchanged. Something has to move.

If a feature needs a month of engineering effort and somebody wants it in a week, you have a few honest choices:

1. Reduce the scope.

2. Move the date.

3. Take a deliberate shortcut and document the debt.

4. Do not build it.

What you cannot do is pretend that a month of work somehow became one week because everyone agreed the date was important.

This is where I strongly prefer smaller vertical slices. Ship one thin, working path through the feature. Let customers use it. Learn from the feedback. Then decide what deserves the next investment. Vertical slice development can help teams deliver useful value sooner without pretending the entire feature fits inside an impossible deadline.

Sometimes you will still choose debt. That can be a valid business decision, but only if everybody understands the cost. If you rush a feature into a shape that cannot support the next iteration, say that clearly. The next change must include paying down the shortcut.

Otherwise, “we will clean it up later” becomes the permanent operating model. That is why technical debt has to be balanced deliberately, not treated like invisible work engineering will somehow absorb.

Actionable Tip: when somebody asks for a fixed date, respond with the smallest scope the team can confidently deliver by that date. Make the excluded scope and any accepted debt explicit.

Overtime Cannot Be The Capacity Plan

If the plan only works when engineers repeatedly work extra hours, the plan does not work.

That does not mean overtime can never happen. Production incidents happen. Unexpected customer problems happen. Teams sometimes make short-term pushes.

But sustained overtime is not additional capacity. It is borrowing energy from future delivery, quality, and retention.

As the tech lead, do not quietly absorb the gap. Make capacity visible:

• Here is what the team can complete safely.

• Here is the work that does not fit.

• Here is the quality risk if we force it in.

• Here is the decision we need from product and management.

If the pressure is already affecting people, talking to your manager about burnout should happen before somebody reaches the point where they cannot keep going.

Pushing back is not refusing to deliver. Good pushback gives decision-makers a realistic set of tradeoffs.

Ownership Means Following Through

One of the most important parts of this role transition is realizing that agreement is not action.

You can explain the testing problem to the product manager. They can nod and say it sounds reasonable. Then everyone returns to the same priorities, and nothing changes.

That does not automatically mean they do not care. It probably means this improvement matters more to you than it does to them, so you need to drive it.

Pick one change. Give it an owner. Put time against it. Define what better looks like. Report the result.

For example:

1. Choose the ten most expensive manual release checks.

2. Automate one of them this iteration.

3. Require a regression test for every recurring defect.

4. Measure the release time and escaped defects.

5. Share the result with engineering, product, and your manager.

6. Repeat.

That first win matters. People support changes more easily when they can see that the change saved time, reduced risk, or made delivery more predictable.

You do not need to repair the entire organization in your first month. You need to understand the system, clarify your authority, build the relationships, and prove that one better way of working is possible.

Then do it again.

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:

• Raise concerns early, without jumping to termination

• Coaching needs observations, support, and follow-through

• Managers remain accountable for the whole team

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

When Should You Tell Your Manager A Developer Is Struggling?

I came across a question from a team lead who had been coaching a junior developer for roughly 20 months. Progress had been difficult, and from the team lead’s perspective, the developer had actually started moving backward. They were less proactive, still needed a lot of direction, and did not seem to be responding to the coaching.

The question was basically: When should I tell my manager this is not working?

My immediate reaction was that this conversation should have started much earlier. But I want to be extremely clear about what I mean by that.

Raising awareness early does not mean asking your manager to terminate someone early. It means sharing what you are observing while there is still time to understand the problem, adjust the support, and give the person a fair opportunity to improve.

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

Raising Awareness Is Not A Verdict

Some people hear “I need to tell the manager” and immediately translate that into “I am trying to get this person fired.”

Those are not the same thing.

A useful conversation with your manager is not:

• “This developer sucks.”

• “They are never going to make it.”

• “We need to get rid of them.”

Those are conclusions. They skip over all the information your manager actually needs.

A better conversation sounds more like this:

• Here is the work the developer has been trying to complete.

• Here is where they are consistently getting stuck.

• Here is the coaching or support I have already tried.

• Here is the progress I expected to see.

• Here is the trajectory I am seeing instead.

• Here is where I need help.

That distinction matters because feedback is deeper than a single verdict. If all you provide is a label, your manager cannot tell whether the issue is skill, unclear expectations, poor coaching, team fit, missing context, or something else entirely.

Actionable Tip: bring observations, not character judgments. Describe what happened, what support was attempted, what changed, and what you need from your manager next.

There Is No Magic Ramp-Up Number

The Reddit discussion had people at both extremes.

Some people claimed they could tell within a week whether a developer was going to work out. Other people pushed back and said new hires need months before anyone should be concerned.

Honestly? I do not believe there is one magic number.

A junior developer learning their first professional codebase is in a different situation from a senior developer joining a familiar domain. A new graduate may need help learning how work moves through the team. A transfer may know the company but not the product. Someone may be technically capable but completely lost in the domain.

The important signal is not whether they reached full productivity by an arbitrary date. It is whether you can see a reasonable trajectory.

Are they asking better questions? Are they retaining what they learned? Are they taking on slightly more responsibility? Are the same blockers repeating without any change? Does the support they need seem to be increasing instead of decreasing?

You may not know the answer after one week. But if you have worked closely with someone for a few weeks or a couple of months and the trajectory concerns you, that is enough reason to share what you are seeing.

You do not need certainty before you communicate.

Your Manager Should Not Be Surprised

If I pair a new developer with a team lead, technical lead, intern buddy, or another engineer, I still expect to check in.

How is the new person doing? Where are they getting stuck? What is going well? Does the person helping them need anything from me?

I do not need a formal performance report every few days. I do want enough communication that the next conversation makes sense.

If a team lead tells me after several months, “This person is not working out,” and that is the first concern I have heard, my response is going to be: Wait, what happened?

The concern may be completely valid. But now we have lost months where we could have changed the coaching, clarified expectations, or added support.

Regular check-ins are one reason I care so much about helping people make the most of their one-on-ones. These conversations should surface small signals before they become enormous surprises.

Actionable Tip: give your manager lightweight progress updates. “Going well,” “still learning this area,” “we are trying a different approach,” and “I need help” are all useful signals.

Clarify What Your Lead Role Actually Owns

“Team lead” and “technical lead” can mean completely different things from one company to another.

In one organization, a lead may be expected to actively coach developers, adjust how work is delegated, and drive onboarding. Somewhere else, the lead may own technical direction while the manager handles nearly every people-related concern.

This ambiguity is one of the mistakes new managers and leads can make. Everyone assumes they understand the role, nobody states the boundaries, and important work falls into the gap.

If you are the lead, ask your manager:

1. What coaching do you expect me to handle directly?

2. What kinds of concerns should I raise immediately?

3. How often do you want onboarding updates?

4. What decisions can I make without checking first?

5. What support can I ask you to provide?

You should feel empowered to help. You should not quietly inherit full responsibility for another employee’s performance without the authority, context, or support to handle it.

Do Not Just Drop The Problem And Walk Away

There is another failure mode here.

You tell your manager, “Bob is not ramping up very well.”

Then... nothing happens.

Did you expect the manager to take over? Did the manager expect you to keep coaching? Is someone changing the plan? Does the developer even know what they need to improve?

Raising awareness without agreeing on a next action is not enough.

Depending on the situation, the next step might be:

• Pairing the developer with someone else for a different perspective.

• Giving them a smaller, better-defined area to own.

• Spending more time on domain context instead of only code.

• Setting clearer expectations for initiative and communication.

• Having the manager join a coaching conversation.

• Identifying training, documentation, or tools that are missing.

• Checking whether the team or role is simply a poor fit.

The point is not that every struggling employee can be turned around. Sometimes the role will not work out. But if the only action is repeatedly saying “they are struggling,” nobody is actually helping.

Make Sure The Coaching Is Not Part Of The Problem

Managers often hear different versions of the same situation.

The junior developer says, “Things are going well. I hit a few blockers, but I am working through them with the senior developer.”

The senior developer says, “This person takes no initiative. I have shown them this five times and they still cannot do it.”

So what is actually happening?

Maybe the junior developer is disengaged. Maybe they are not retaining information. Maybe they are afraid to ask questions. Those are all possible.

But maybe the senior developer’s idea of coaching is screen sharing, clicking every button, writing all the code, and saying, “Watch what I do.” Then they are frustrated when the other person cannot reproduce the process alone.

I have written about how senior developers can accidentally make learning harder, especially when expertise makes the difficult parts feel obvious. Watching an expert move quickly is not the same as practicing the skill.

Actionable Tip: let the learner drive. Have them share their screen, choose the next step, explain what they think is happening, and ask for guidance when they get stuck. It may feel slower, but you can finally see how they reason.

Technical Aptitude Might Not Be The Whole Story

When someone seems unmotivated or passive, it is easy to jump straight to a personality judgment.

Sometimes that judgment is wrong.

Maybe they do not understand the domain well enough to know why the work matters. Maybe every task feels like an isolated technical request with no connection to a user or business outcome. Maybe they are overwhelmed by the codebase and trying not to expose how lost they feel.

Managers and leads often say, “There are no stupid questions. Ask anything.”

I genuinely mean that when I say it. But I also understand that new employees may still worry about looking unqualified in front of their manager. Pairing them with another engineer can create a safer place to ask those questions and build confidence.

That is part of why a manager needs multiple perspectives. Talk to the developer. Talk to the person coaching them. Look at the work. Ask what each person has tried. Do not assume one story gives you the complete picture.

Accountability Still Belongs To The Manager

As a manager, I can delegate pieces of onboarding. I can ask a senior engineer to be an intern buddy. I can give a team lead room to coach someone and adjust the day-to-day approach.

I cannot delegate away my accountability for the team as the manager for the team.

At the end of the day, the manager is responsible for making sure employees have clear expectations, appropriate support, useful feedback, and a fair process when performance concerns exist.

That does not mean the manager personally performs every coaching session. It means the manager remains engaged enough to understand what is happening and act when the team needs help.

This is where accountability without sliding into blame matters. The goal is not to decide which person deserves to be attacked. The goal is to understand the system, clarify ownership, support improvement, and make a responsible decision.

A Practical Way To Escalate The Concern

If you are a lead and you are worried about someone’s progress, you do not need a dramatic speech.

You can use a simple structure:

1. State the observation. What specific behavior or outcome concerns you?

2. Describe the trajectory. Is it improving, flat, inconsistent, or getting worse?

3. Explain the support. What coaching, pairing, documentation, or context have you tried?

4. Share the impact. How is this affecting the developer, the work, or the rest of the team?

5. Ask for help. What do you need the manager to clarify, provide, or decide?

6. Set a checkpoint. When will you compare notes again?

That might sound like:

I have been pairing with this developer on the deployment workflow. They can complete the steps with direct guidance, but they are still unable to complete the same workflow independently, and the same questions are repeating. I have tried written steps and two driver sessions. I would like your help understanding whether we should change the coaching plan or clarify the role expectations. Can we check in again after the next two tasks?

That is specific. It leaves room for investigation. It creates an action. And it does not pretend you know the final outcome before the manager has even joined the conversation.

Earlier Communication Can Be Kinder

Waiting can feel compassionate because you do not want to get someone in trouble.

But silence is not always kind.

If the developer needs different coaching, earlier communication helps them get it. If expectations are unclear, earlier communication gives the manager time to clarify them. If the team is a poor fit, earlier communication creates more options. If a formal performance process eventually becomes necessary, the concern should not appear out of nowhere after nearly two years.

The time horizon for raising awareness is much shorter than the time horizon for giving someone a fair opportunity to improve.

Those ideas are not in conflict.

You can communicate early, coach patiently, gather better information, and avoid rushing to a conclusion. In fact, early communication is what makes that patience more responsible.

The Question Is Not “When Do I Give Up?”

The better question is: When do I create enough visibility for the right support to happen?

My answer is early and regularly.

Do not wait until you are completely frustrated. Do not turn one difficult week into a permanent label. Do not hide the concern for 20 months and then hand your manager a final verdict.

Share the signal. Ask for help. Agree on the next step. Keep checking the trajectory.

Maybe the developer turns things around with better coaching. Maybe they thrive on a different team. Maybe the role ultimately does not work out. You cannot know that from the first concern.

What you can do is make sure the concern is handled with clarity, accountability, and enough time for people to respond.

If you have a software engineering or career question, leave it in the video comments or submit it anonymously at codecommute.com. I would love to hear how your organization divides coaching responsibilities between leads and managers.

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:

• Principal impact crosses team boundaries

• Sustained ownership beats one heroic project

• Visibility should follow meaningful impact

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

What It Actually Takes To Become A Principal Engineer

I came across a question from someone trying to understand what getting promoted to principal engineer actually looks like. Not the generic career-ladder language. Not “increase your impact” and “show more visibility.” They wanted specifics, because the advice they had heard felt inconsistent and the target kept moving.

Honestly? I think that criticism is fair.

Before I get into my take, there is an important caveat: my perspective comes from working at Microsoft, and I am an engineering manager. Titles, levels, and expectations vary dramatically between companies. Some organizations go from senior directly to principal. Others have staff between them. Some swap the staff and principal labels entirely. So I am not claiming this is the universal definition.

What I can do is explain the pattern I have seen, the path I took, and what seems to separate someone doing excellent senior-level work from someone operating at principal scope.

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

Principal Is A Scope Change, Not A Coding Upgrade

The simplest framing I have is this: becoming principal is usually not about being a senior engineer who types code even faster.

By the time you are being considered for principal, the expectation is already that you are technically strong. If you interview at a big tech company, coding questions may still be part of the process. System design will probably matter even more. But being excellent at those things is the baseline, not the entire case.

The bigger change is the surface area of your responsibility.

A senior engineer can have a huge impact within a team. A principal engineer is usually expected to influence work across teams, products, or an organization. That does not mean you personally write every line of code or dictate every design. In fact, I have written before about why senior developers often end up coding less, and principal scope pushes that shift even further.

You are increasingly responsible for questions like:

• Can several teams align around a technical direction?

• Can this platform support an entirely new class of customers or partner teams?

• Can a risky initiative move from an idea to a durable, supported capability?

• Can stakeholders trust that you will drive the work without chasing you for updates?

• Can other engineers lead meaningful pieces of the mission and succeed because of the structure you created?

That is a very different job from being the person who solves the hardest ticket in the sprint.

You Can Be Promoted In Or Hired In

The person asking the question wanted to know what it took to get promoted into principal. My path was different: I was hired into Microsoft at the principal level.

That distinction matters because changing companies can be one route into the next level. Maybe you are already operating near that level, but your current team has limited opportunities. Maybe there are already several principal engineers and the organization cannot create enough principal-scope work for everyone. Maybe you have been close to promotion multiple times and now have a strong collection of examples to take into interviews elsewhere.

None of that means the interview is easy or that you get to skip demonstrating the scope. You still need the evidence.

When I joined Microsoft, I did not have another big tech company on my resume to provide a neat level-to-level comparison. I came from a much smaller digital forensics company, and I had never worked on globally distributed deployment systems at anything close to Microsoft’s scale. I go deeper into that transition in my journey from a startup into Microsoft.

What I did have were concrete stories about operating across an organization.

One example was taking a product idea that had been outsourced, bringing the work in-house, building the team around it, and leading that area successfully for years. I could explain the business outcome, the technical ownership, the team growth, and the sustained responsibility. The domain was different, but the leadership and engineering skills transferred.

That is the key. You do not need to have solved the exact same problem at the exact same scale. You need to show that you have repeatedly handled comparable complexity, ambiguity, and organizational reach.

Make “Organizational Impact” Concrete

“You need more impact” is frustrating feedback because it sounds important while telling you almost nothing.

So what does organizational impact actually look like?

Imagine you work on a platform that supports three kinds of internal services. You lead an initiative that lets the platform support entirely new classes of services. Now you are not just improving one feature for your immediate team. You are expanding the value of everything your team already built and making it available to whole new groups across the company.

But even that outcome is not enough if your involvement was just proposing the idea or making a couple of code changes.

At principal scope, you might:

1. Help shape the original idea and clarify the business value.

2. Lead the design and architecture across several teams.

3. Get partner teams bought into a shared direction.

4. Break the work into areas other engineers can own.

5. Navigate risks, dependencies, and changing requirements.

6. Keep stakeholders informed without turning communication into theater.

7. Carry the initiative through delivery and into sustained operation.

That combination is what turns “I worked on a large project” into “I led an organizationally important outcome.”

And yes, influence is part of it. The technically best proposal does not automatically win. If you are struggling to build support across teams, the same dynamics I discussed in why good ideas keep getting shut down absolutely show up here too.

Visibility Should Be A Consequence Of Impact

I have mixed feelings about the word visibility.

I have personally been put forward for promotion and received feedback that I did not have enough visibility. That was incredibly frustrating. My reaction was basically: what do you mean? I am doing the work my leadership asked me to do. Am I supposed to replace useful engineering work with a bunch of artificial self-promotion?

Communication matters. Project updates, stakeholder notes, demos, and reaching out to groups that might benefit from the work can all help. You should not hide important work and then be shocked when nobody knows it happened.

But I heard a framing from a VP that changed how I think about this: the impact should be large enough that the relevant parts of the organization naturally have some visibility into it.

Not every person needs every implementation detail. The point is that the work touches a broad enough surface area that leaders and partner teams can say, “Yes, I know that initiative. I understand why it matters, and I know this person is driving it.”

That is different from doing small-scope work and trying to amplify it until it sounds organizational.

Actionable Tip: treat communication as a multiplier for real impact, not a substitute for it. Learn to explain the mission, risks, tradeoffs, and outcomes in language each audience understands. That skill is a big part of why I think communication separates good developers from great ones.

Ownership Is The Signal Behind The Title

When I think about the strongest principal promotion cases I have seen, two words keep coming up: ownership and accountability.

People trust this person with an important initiative. They are not waiting for someone else to define every next step. They are not being chased down to see whether anything is moving. They create clarity, pull the right people together, surface risks, and keep driving toward the outcome.

Usually this is not someone who suddenly appeared, completed one enormous project, and immediately became principal. The pattern is more often:

• They have already been contributing at a high level on important work.

• They consistently make the teams around them more effective.

• They take on ambiguous problems without waiting for a perfect plan.

• They build trust across technical and non-technical groups.

• Then they lead one or two especially visible, high-impact initiatives that make the existing pattern undeniable.

That last project may become the cleanest promotion story, but it is not the entire story. It is evidence that confirms sustained behavior.

This is also why principal scope cannot be reduced to a checklist of code contributions. If your project requires coordination across teams, the difficult parts may be alignment, decision-making, sequencing, communication, and creating ownership for other engineers. Those are not distractions from the technical work. At that scale, they are part of the engineering work.

The Goalposts Can Move

Here is the part nobody loves hearing: sometimes the target really does move.

Organizations change. They grow, contract, reorganize, and end up with different distributions of engineers at each level. A company may decide it has too many people at a certain level and quietly raise the bar. The work that earned a promotion several years ago may not be enough under the current expectations.

That does not make the process feel any less unfair when you are on the receiving end.

You can do strong work, get told you were close, receive vague feedback, and then wait another six months while wondering whether anything you are doing matters. I have experienced the disappointment of being put forward and not getting the result. I have also experienced this on behalf of my employees when I am working for putting them forward for promotion. It is demotivating, especially when you thought you were following the guidance you had been given.

If that happens, try to get specific:

• What evidence was missing from the promotion discussion?

• Who needed to see a broader scope of impact?

• Was the concern about the work itself or how it was represented?

• What would make the next review materially different?

• Are principal-level opportunities actually available on your current team?

If your manager cannot turn the feedback into something concrete, that is useful information too.

And protect your energy. There is a real difference between stretching into bigger responsibility and running yourself into the ground chasing a title. I have shared more thoughts on pursuing promotions without burning yourself out, because no level is worth destroying yourself over.

Principal Impact Is Shared, Not Hoarded

One of the projects that helped demonstrate my own impact within the principal band was a multi-month resiliency initiative across an entire platform. It had visibility well beyond my immediate team, and I was responsible for coordinating work across a much larger group.

But I did not personally do all of that work. Not even close.

The engineers leading individual parts of the initiative did the work. My role was to help create the direction, coordination, accountability, and conditions for those pieces to succeed together.

This is important because large impact is not a fixed pie where the principal engineer takes the biggest slice and everyone else gets less credit. Done well, it is closer to one plus one equaling three. The overall initiative becomes a strong impact story, and the engineers leading its different areas get meaningful stories of their own.

If your version of principal leadership requires absorbing all the credit, you are doing it wrong.

The best evidence of principal-level leadership is not that everything depended on you personally. It is that the organization could take on a larger mission because you helped many people move effectively in the same direction.

A Practical Plan If You Are Targeting Principal

So what can you actually do with all of this?

Actionable Tip: stop asking only, “What task gets me promoted?” Start asking, “What important outcome is too large for one team, and how can I help the organization deliver it?”

Then work through this:

1. Learn your company’s definition. Get examples of people who were recently promoted and the evidence that mattered.

2. Inventory your real scope. Write down the teams, systems, stakeholders, and business outcomes your work already touches.

3. Find the missing dimension. Maybe you need broader technical ownership. Maybe you need cross-team influence. Maybe you need sustained delivery instead of another short project.

4. Choose work that serves the mission. Do not manufacture a vanity project for promotion. Find an actual organizational problem worth solving.

5. Practice telling difficult stories. Be ready to explain projects that went off track, how you built buy-in, where you changed direction, and what you learned.

6. Create opportunities for other engineers. Principal impact should multiply the people around you, not turn you into a bottleneck.

7. Consider the external path honestly. If your organization cannot offer the scope, another company may evaluate the experience you already have differently.

None of this guarantees a promotion. That uncertainty is part of why the process feels so nebulous.

But it does move the conversation away from “do more stuff and be more visible” toward evidence you can actually reason about: scope, ownership, trust, organizational outcomes, and sustained impact.

Do Not Let The Level Become The Mission

I understand why people focus on titles and levels. They are the clearest quantitative signal we have for career progression. Compensation follows them. Responsibility follows them. It is natural to care.

The part I do not love is when the entire incentive becomes: what do I need to do so I personally get promoted?

That framing can make a group of talented people optimize as individuals while the company hopes useful business outcomes appear as a side effect. It feels backwards.

The healthier question is: how do we work together more effectively on the mission, and how do I grow my ability to contribute at a larger scale?

If you keep expanding the complexity you can navigate, the people you can align, the outcomes you can own, and the success you can create for others, you are building principal-level evidence. The title may still depend on timing, organizational shape, and a process you do not fully control.

But the capability is yours.

If you have questions about software engineering or career development, drop them in the comments or submit them anonymously at codecommute.com. I would love to hear how principal expectations differ where you work too, because there absolutely is not one universal path.

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:

• Ralph loops make failed AI attempts cheap

• My template library is the real unlock

• First real end-to-end AI build succeeded

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

Feeding My AI Workers Templates

I like doing these AI recaps after I’ve had a real stretch of time to sit down and actually build, and this one’s a good one. I recently had a week off work -- my wife was back in Canada visiting friends for her birthday, so I had the house (and the animals) to myself. I still ended up doing some work every day in some capacity, but I also had the flexibility to focus on what I actually wanted to build. Fair warning up front: this is an extension of the stuff I’ve been talking about recently with building things using AI.

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

Too Many Copilot Tabs, Not Enough Brain

For context: I lean on Copilot CLI for basically everything these days. I keep telling myself I should try other tools more -- I’ve poked at a few this year -- but the flow is working so well that pulling myself away feels actively disruptive. Add in the fact that I’ve got my token limits lifted, and there’s a lot of incentive to just stay put.

My day-to-day looks like juggling a handful of different repositories at once. There’s BrandGhost, the side business I run for automating social media posting and SEO work for other businesses. There’s Needlr, my dependency injection framework for .NET. There’s a consumer app I’m helping a friend build. And then a handful of smaller supporting projects on top of that. In practice, that means I’ve got a PowerShell window open with something like twelve tabs, and I’m just bouncing between them -- prompting Copilot in one, checking on another, prompting a third.

I saw someone online recently put a name to the mental toll of doing this -- and that’s really pointing to the significance of this way of working. Constantly juggling too many AI sessions is a real cognitive cost, and it’s messing with people’s heads a little. I’ve written about the context-switching problem before, but this is a new flavor of it -- it’s not just switching between tasks, it’s switching between agents, each with its own context, its own state, its own thing it’s in the middle of.

Ralph Loops, Orchestration, Spec Kit, and Templates

The system I’ve been building has multiple layers, and the important part is that every layer is optional on its own.

At the bottom is what’s known as a Ralph loop -- a pattern named after Geoffrey Huntley’s tongue-in-cheek nod to Ralph Wiggum, and it’s dead simple: a worker picks up a task, iterates on it inside some constraints, and if it doesn’t meet those constraints in the time it’s given, the work gets thrown away. No wasted human time arguing with an agent that’s gone sideways -- you just scrap the attempt.

On top of that sits an orchestration layer, which follows an open-source specification from OpenAI called Symphony. I’ve got my own C# implementation of it. This is the piece that schedules work across however many Ralph-loop workers are running.

And the third layer is an integration with Spec Kit -- GitHub’s open-source toolkit for spec-driven development. This is what lets you start the whole thing off just by handing it a spec. And I don’t know if I would call this a layer above or below the spec kit integration, but I have a template library that I am building for scaffolding. So it’s not exactly the same as spec kit, but it’s a a solo (or complementary) part of what the spec could include -- all up to my own standards and expectations for how I want something started.

Here’s the part I actually like: none of these layers are required. You can use the inner Ralph loop by itself. You can use the orchestration layer without ever touching a spec. Or -- and this is the version I’ve been testing -- you can hand the whole system a single one-shot prompt and let it use Spec Kit to build out the spec, then use the orchestration layer to schedule the work, then let the agents go execute it.

The One-Shot Calculator Test

To actually test this, I’ve been feeding it about as simple a prompt as I could come up with: “I want a desktop-based calculator app in C#.” That’s it. That’s the entire prompt, on purpose -- I wanted to see whether, given almost nothing, the system would actually finish.

Given how trivial that ask is, my bar was low: I expected spec documents to get created, and I expected a simple app with some buttons that does calculations -- the same basic calculator UI you’ve got on your phone. Tech stack didn’t matter to me -- WinForms, WPF, whatever, I wasn’t specifying it in the prompt. And since it’s such a simple app, I gave it a budget of an hour to get it done.

The early attempts weren’t failures exactly, but I wasn’t happy with them either. The problem was mostly glue -- the connective tissue between all the pieces. I’d come back and find it had burned 30 minutes retrying a single step because a worker session had literally frozen, or gotten stuck in a loop trying to build something it was missing a dependency for. That’s half an hour of a 60-minute budget gone to something completely silly, not to the actual work.

Eventually, though, I got a real end-to-end success. First one. And that felt like a genuine milestone, even for a calculator app -- because it meant the scaffolding, the orchestration, and the loop logic were all finally working together instead of fighting each other.

Why Templates Are the Real Unlock

If you take away one thing from this issue, I’d want it to be this: the real unlock isn’t the fancy orchestration layer. It’s the template library.

I’ve been building up a set of templates -- somewhere north of 10, under 20 -- that represent the foundation I’d expect for any codebase, depending on what I’m building. Want a desktop app in C#? I’ve got an Avalonia template that’s great for getting a cross-platform desktop app off the ground fast, which is exactly what kicked off the calculator build. Every one of these templates already reflects how I like to build things with a plugin architecture, and how I like to wire up dependency injection.

But a template isn’t just a starting solution file and a couple of projects. That’s part of it, sure. The bigger part is that every template ships with my coding standards already turned on -- analyzers and linters configured the way I want them by default. It also ships with my agent instructions: a library of shared instructions that match against file paths. So if an agent is working in a file that ends in test.cs, it automatically gets my standards for what a good test file looks like in C#. And because those instruction files are themselves templated, I can swap in different pieces depending on the stack -- xUnit instructions versus TUnit instructions, for example.

Actionable Tip: if you’re experimenting with anything like this yourself, don’t start with the orchestration layer. Start with a small library of your own project templates and coding standards. That’s the piece I use every single day, regardless of whether the fancier orchestration experiment ever fully pans out.

Put it together and the goal is simple: when I kick off a brand-new project, it’s scaffolded well from the very first commit, fully on autopilot -- instead of me getting an agent to reinvent my standards from scratch every single time.

This Isn’t Just For New Projects

The other half of this system isn’t about kicking off brand-new projects -- it’s about ongoing work. There’s a small web server sitting there listening, and I can just queue work items up to it. It schedules agents against that queue, and if a backlog builds up, an orchestrator looks at priority and dependencies and figures out how to work through it.

Some pieces of this I use constantly, some are still very much an experiment. The templating library and the reusable instruction files -- I’m in those every single day. Because I’m running across so many different Copilot sessions and repos, I keep spotting the same small pattern show up more than once: “oh, this is clearly a recurring problem, let’s get it into the instructions” -- and that feeds straight back into the template library. The same thing happens when I’m building a new feature: sometimes I realize I need a template for this shape of work, sometimes I realize I just need better instruction coverage.

That’s honestly why I’m not worried if the fancier orchestration experiment doesn’t pan out. The templating system is something I get value from regardless -- and it also syncs just the instruction files (not the whole template) across my different projects, so if I improve a standard in one repo, it can propagate to the others.

... Besides, people smarter than me I am sure are already lightyears ahead on the orchestration part!

Teaching the Agent to Ask About UX

After that first successful run, I went and looked at the actual calculator -- and it looked terrible. So I asked Copilot directly: based on the spec, was there anything in there about UX? Nope. Nothing.

So for the next attempt, I changed the one-shot prompt -- and I mean changed it barely at all, because I wanted to keep it close to a true “give it nothing” test. I just added one line: I want a consistently styled user interface that looks modern. That goes in right at the start, and then the same pipeline runs: Spec Kit turns it into a spec, orchestration schedules the work, agents execute.

The part that still catches me off guard, even though I built it: there’s an agent driving the entire Spec Kit conversation on my behalf. I didn’t invent that pattern -- it’s not novel -- but actually watching an agent have that back-and-forth about what I want built, fully hands-off, still feels a little nuts. When we’re this hands-off, we either need to expect things to be done in odd ways or provide significant enough guard rails to keep things on track.

Worth saying too: none of this requires Spec Kit at all. If I want to bring my own spec, or my own prompt, or skip that step entirely, I can just start a new repo and start sending work items straight to the queue. Those work items can just as easily be GitHub issues -- the system integrates with GitHub directly.

Turning This Into Real Eval Scenarios

Once I’ve got this working end-to-end reliably, the next step is turning scenarios like the calculator app into actual eval scenarios. The idea: define requirements that apply across every scenario -- has to finish within a given time window, has to stay under a token budget, has to actually deliver on the spec. That last one needs an LLM judge that reviews the spec against the output and decides whether it actually delivered. I’ve written before about building LLM-as-judge evaluation harnesses in C#, and this is exactly the kind of system that needs one -- I don’t have a ton of eval experience yet, so I’m actively building that muscle.

Why bother? Because it gives me a way to tune the system honestly. If I change how conflict resolution works, or how retries behave, or how work gets scheduled across multiple parallel workers, I want to be able to run it against a handful of eval scenarios and say “yep, this still meets my bar” -- instead of just eyeballing one run and hoping.

One optimization idea that came out of watching this calculator run: it only used a single worker because there wasn’t enough parallel work to justify more. But for anything more complex -- multiple workers, potential conflicts, retry logic -- there’s a real efficiency question buried in here. Instead of spinning up a brand-new working session for every single work item, what if a worker just kept reusing the working directory it’s already sitting in? If a build takes a minute, and you’re chewing through 10 work items, that’s a minimum of 10 minutes out of your budget spent purely on rebuilding from scratch every time. On a 60-minute budget, that’s not a rounding error -- that’s a huge chunk of it.

Why I’m Actually Doing This

Zooming out, I think about all of this in two ways.

The first is that I’m trying to build things, and using AI well, so I need to get better at building the scaffolding that makes AI effective -- that’s my templating library, that’s my instruction file library, and I’m actively working on both.

The second is that I’m experimenting because that’s genuinely how I learn best. Long before AI was part of the picture, this looked like me building a role-playing game as a side project -- not because I ever expected to ship a finished game, but because building it forced me to learn different corners of software engineering I wouldn’t have touched otherwise. Playing around with agent orchestration right now is the same instinct. I’m not sitting here thinking I’ve invented agent orchestration -- I haven’t, and there are people and companies way further ahead of me on this, which is completely fine. I’m happy to go use their stuff when it makes sense. This is just me playing around so I can learn, because that’s how learning has always worked for me.

If you’ve got questions about software engineering, AI, or your career, drop them in the comments, or head to codecommute.com and submit them anonymously -- I’ll make a video response for you and everyone else watching.

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:

• Healthy conflict between product and engineering matters

• A non-technical boss isn’t an automatic dealbreaker

• Surface tech debt before it gets ignored

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

When Your Product Manager Becomes Your Boss

This week’s topic comes from a post over on the ExperiencedDevs subreddit, and it’s a good one: is it normal for the product owner or product manager to be your boss? The person who posted it had their engineering manager leave -- and instead of backfilling that role, leadership made the product manager who already worked with the team the new manager of the engineers. So now the engineers report into a product manager, and as far as I can tell there’s no engineering manager replacement coming. That’s just the path forward. They were asking the obvious question: is this normal, and what should I make of it?

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

One Detail Changes the Whole Picture

Right at the end of the post, they dropped in a piece of context that I think matters a lot: this is a company that’s primarily a marketing company. Software is an aspect of what they do, not the whole business. And they wondered if maybe that was a factor.

I think it’s a huge factor, and I want to call out why I love that they included it. We talk about a ton of different software engineering topics, and the right answer almost always depends on the situation. A tiny startup is not a giant enterprise. A company that’s effectively 100% a software business is not the same as a company where software supports some other product or service. When I read something like this and feel a strong gut reaction -- wait, what the heck is that? -- the most useful thing I can do is check whether the context is just very different from what I’m used to. It usually is. So keep that in mind as I share my take: your situation might not map cleanly onto mine, and that’s exactly the point.

Why You Actually Want Conflict Between Product and Engineering

Here’s the meta point I really want to land, because everything else hangs off of it. I think it’s genuinely important for a team or an organization to have healthy conflict between engineering and product. “Conflict” is almost too strong a word -- think of it as healthy tension between two groups motivated by different priorities.

If you only have product representation, you get pulled toward what I’d only half-jokingly call feature factory hell -- crank out features, crank out more features, and never make space for the work that keeps the foundation from getting brittle. Flip it around: if you only have engineering representation, you exaggerate the other way into tech-debt-and-architecture hell, endlessly refactoring and re-architecting while shipping very little customer value. Both extremes are caricatures, obviously. But that’s the whole reason you want both voices in the room. They pull against each other, and that tension is what keeps you focused on what actually matters: shipping real value without quietly rotting the codebase.

So when a team loses its engineering manager and folds entirely under product, my first concern isn’t “a PM can’t manage people.” It’s “who’s representing the engineering side of that tension now?”

The Traditional Setup, and What’s Really Shifting

In a more traditional org, engineers report up to an engineering manager, and the product manager works with the team. Those are two different things, and it’s worth separating them. The product manager absolutely helps understand and set priorities -- they’re translating what customers and the broader industry are asking for, figuring out which direction the product should go, and often bridging into sales and marketing. But the engineers aren’t reporting to that person for career development. They report to an engineering manager, and the engineering manager partners with the product manager on what to actually go focus on. If you want my full breakdown of that role, I wrote about what’s actually expected of an engineering manager.

What’s changing in this Redditor’s case is that the reporting line and the engineering representation are both collapsing into the product manager. The partnership tension I just described doesn’t have an obvious counterweight anymore.

Ownership Moves Around -- a Lot

I want to paint a picture from my own career, because the balance between product and engineering is not fixed. It moves.

Back when I worked at a digital forensics company before I landed at Microsoft, most of the time product management set the direction of the product and made it very clear what we needed to deliver -- they sat between engineering, sales, marketing, and customers. We shipped monthly, and we’d prep hard for some big conferences, so product would shape a lot of the roadmap around those. From the engineering side, as an engineering manager and a software engineer, our job was to make it real -- and to push back in a healthy way. “You want these things, but you may not see all the detail that goes into doing them well, so let us represent that side.” Then we’d meet in the middle. Funny thing is, even though a lot was set by product, I never felt like I lacked input or control. We just had a genuinely good working relationship.

Then I came to Microsoft, onto a deployment platform team in Microsoft 365. Early on, it felt almost the opposite -- engineering managers were quite literally defining the roadmap, and the product managers were there to facilitate that vision, jumping into cross-team dependencies and smoothing things out. Then there was a reorg, and it flipped dramatically. Product went from facilitating to owning every priority, work stream, and deliverable -- to the point where it sometimes felt like I barely had a say. A complete 180, on the same org, in the span of a few years.

On the team I’m on now, it’s more of a hybrid. I feel like I have a lot of say in what we work on, and the product managers do a great job bridging the business needs down -- “here’s the initiative, here’s the spend or performance goal we need to hit” -- and then leaving the how to engineering. Three very different balances, all in one career. So when someone asks “is it normal for product to run things?” -- honestly, the ratio swings all over the place depending on where you are.

The Two Things That Get Weird

So what actually gets harder when a product manager is directly managing engineers? I see two big ones.

Career development. In this case the poster said their PM isn’t technical at all. That can make career growth genuinely tricky. Not impossible -- I want to be careful here, because I’ve had non-technical managers I thought were fantastic, and plenty of people will disagree with me on that. There are real strengths a non-technical manager can bring. The hard version is when someone is non-technical and struggles to communicate effectively with technical people. That’s when it gets rough -- it’s hard to feel relatable to a manager when you don’t think they can follow what you’re working on or understand what career progression looks like for an engineer. Even if they actually do get it, that gap erodes the trust and respect that make the relationship work. I went deeper on how you even evaluate this in measuring manager effectiveness.

Delivery and representation. This is the thread running through everything above. When you drop the engineering voice out of priority-setting, you lose the person who’s supposed to argue for the foundation. You’re left with a product focus -- and like a bunch of the Reddit commenters warned, get ready for the feature factory: more and more features, less and less room for the work that keeps your base from getting brittle. It’s not that it can’t work. It’s that the structure quietly removes the counterweight. Getting non-feature work onto the roadmap is already hard enough with an engineering manager in the room -- I broke down that whole battle in how to get tech debt prioritized.

Subscribe now

How You Actually Make It Work

Here’s the part I care about most, because it’s the part you can control. If you’re in this spot and you’re not immediately heading for the door, do two things.

First, invest early in communication. Figure out how to talk to this manager so they actually get it. If you start going on about classes and code structure, a non-technical PM may have no idea what you mean and no interest in it. So learn -- quickly -- the level you need to communicate at, and ideally help them learn how to communicate effectively back to you. You don’t control their half of that, but you fully control yours, and getting this right is what lets you set clear expectations when you’re not seeing eye to eye. This, by the way, is the exact skill I’d argue separates good developers from great ones -- being able to translate technical reality for a non-technical audience.

Second, be proactive about surfacing the engineering side. A non-technical product manager probably isn’t going to ask, “hey, where’s our tech debt, do we need to re-architect anything?” -- not out of malice, but because it’s genuinely not on their radar. So you’ve got two options. You can sit and sulk -- “well, I guess we’re a feature factory forever, no tech debt work, no improving our test infrastructure, no re-architecting.” Or you can say: they’re not going to ask because they don’t know to ask, so we’ll bring it up. Lay out the pros, cons, and risks for the areas they don’t have exposure to. Whether they act on it is a separate story -- but the part you control is making sure it gets raised. And if they consistently won’t factor it in when prioritizing? That itself is a useful signal about whether this is a good long-term fit.

My Best Boss Was a Product Leader Running Engineering

I’ll leave you with a story that complicates the whole “product running engineering is bad” narrative. At that same digital forensics company, there was a stretch where our VP of engineering left, and the interim VP of engineering was our product management leader. So product was, quite literally, in charge of all of engineering -- a different level in the hierarchy than this Reddit situation, but the same basic shape.

And honestly? In my eight years there, that person was the best engineering leader I worked with at that level. Which sounds wild given the framing of “oh no, product is in charge, there’s no engineering voice.” So what made it work? He wasn’t writing code and wasn’t a software engineer, but he was technical enough in how he communicated. He listened to the engineering side. He clearly understood that you need that healthy conflict between product and engineering to prioritize well. And when he didn’t follow a technical detail, he’d just say so -- “I don’t get it, can you explain it a different way?” -- no bluffing, never frustrating to work with. A lot of it came down to his willingness to genuinely take in engineering concerns instead of just handing down “product decided, go ship it by next week, figure it out.” Even reporting into him, I always felt well supported in my own growth.

So, Is It Normal -- and Should You Worry?

My honest read: it’s not an absolute dealbreaker, but I’d also be lying if I said I’d love being in this exact situation. I think statistically I got pretty lucky with that interim VP, and more often than not, I suspect this setup doesn’t pan out quite as well. But the outcome isn’t fully out of your hands. If you’re aware of the parts you can influence -- communicating in a way your manager actually understands, and proactively making sure engineering concerns reach the prioritization table -- you can tilt the odds. And if you give that a real shot and it still doesn’t work? Then yeah, it’s probably time to go find a place where engineering gets a seat at the table.

If you’ve got a situation like this you’re wrestling with, you can submit it anonymously over at codecommute.com and I’ll do my best to make a video response. Hope this one helps.

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:

• 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!