TL; DR:

• Pick the platform your users need.

• Cross-platform doesn’t mean cost-free.

• Lock-in isn’t the same as loyalty.

• Watch the livestream (or check out the recording) on Monday, November 2nd at 7:00 PM Pacific!

Are Desktop Applications Obsolete?

Hey folks!

I came across a question on the ExperiencedDevs subreddit about software moving from desktop applications toward web apps. Why does that happen? And aren’t we losing something if the software no longer lives on our computers?

I think those are fair questions. But I don’t think desktop is dead, and I don’t think web automatically wins.

I’ve been programming for more than 20 years. More than half of my programming career has been in desktop development. So this isn’t coming from someone who has only ever built things for a browser.

My perspective is that web apps can open up opportunities for a product. Desktop apps still make sense when their capabilities fit what you’re building. The interesting part is figuring out which tradeoffs you’re actually willing to make.

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

Cross-Platform Doesn’t Make The Cost Disappear

Let’s say you’re building an app for Windows customers.

If Windows is the only platform you need, building specifically for it might be a perfectly reasonable choice. But what happens when you also want Mac and Linux users?

You have options. You could build separate native interfaces and share the parts of the application that don’t depend on the platform. You could use a cross-platform framework. Or you could ask whether the product belongs in a browser.

None of those options makes the engineering work disappear.

With separate native interfaces, you have more platform-specific work to maintain. With a cross-platform framework, I would want to examine how much complexity moves into the framework and how the experience feels on each platform.

Maybe the interface doesn’t feel completely native. Maybe it does, but your team has more work to get it there. I’m not saying that makes cross-platform a bad choice. I’m saying you need to look for where you’re paying the cost.

The browser has its own version of this tradeoff. Reaching users through a URL can be attractive, but “it opens on a phone” and “it’s a good product on a phone” are not the same thing.

You still need to consider layout, interaction, and the devices your customers actually use. Mobile isn’t free just because the page loads.

Start With What The Product Must Do

What if your app needs frequent access to local files? What if it interacts with other things on the computer? What if a very specific native experience is part of what customers are buying?

Those are more useful questions than asking which platform is winning.

And I want to be careful here: the browser isn’t simply incapable of working with local files. The File System Access API can read and save files after the user grants access. But browser support, permissions, and the exact workflow still matter. That is not the same as assuming every browser can provide every desktop interaction you need.

For a product where those boundaries keep getting in the way, I would seriously consider desktop. For a product where they aren’t important and reaching people on different platforms is valuable, I would explore web.

What about performance?

I wouldn’t choose based on a blanket statement that native is always faster or that browsers are now fast enough for everything. I would identify the interaction that matters, build a representative slice, and measure it on the devices we need to support.

Actionable Tip

Before choosing your stack, write down:

• Which platforms your customers actually need.

• What must work without a network connection.

• Which local files, devices, or system integrations matter.

• What “fast enough” means for the important workflow.

• Who will maintain the application after the demo works.

Then compare the options against that list. Not against your favorite framework’s homepage.

Your Team Is Part Of The Decision

Historically, team familiarity has been a big factor for me.

If you have developers who are very effective in a particular stack, and no strong requirement pushing you away from it, leaning into that experience can help you get the product out the door.

A theoretically better technology doesn’t help much if you can’t ship.

I think AI can change some of that calculation. It may make an unfamiliar stack more approachable. That is part of why I’ve been talking about how AI changes the reasons we choose programming languages.

But “I can generate this” isn’t the same as “we can support this.”

You still need to evaluate the output and understand the important boundaries. Owning the quality of AI-written code doesn’t stop being your responsibility because the stack is new to you.

If your first attempt misses a requirement, use that to improve the process. Fixing the feedback loop is more useful than repeatedly asking for a better result without explaining what better means.

Installed, Offline, And Owned Are Different Questions

The original question also brought up ownership. Maybe people feel better about buying software if they have a copy installed on their computer.

I can understand that preference. It’s just not a requirement I personally have for every product.

For example, I pay for Office outside of work, and I mostly use the web apps. I work at Microsoft, but this is my perspective as a paying customer, not a statement on Microsoft’s behalf. Whether Office is installed on my computer isn’t what makes that purchase valuable to me.

Would I prefer a one-time purchase over a subscription? Sure. But that’s a different question from whether I need a desktop application.

And offline access is another question again.

Imagine you have a document on your computer, but the application you need to open it requires an internet connection. If the network is down, being unable to view your own local file would feel pretty bad.

That’s a hypothetical workflow, not a claim that every Office application behaves that way.

The same concern comes up for me with single-player games that require an online connection. It feels weird even when it isn’t frequently stopping me from playing.

But web doesn’t automatically mean online-only, either. Progressive Web Apps can store data locally to support offline work. You have to deliberately build and test that experience. A product that depends on a remote service still needs a plan for what happens when that service is unavailable.

So ask the customer what they mean by ownership. Is it a one-time payment? Access to their data? Being able to keep working offline? Those answers can point you toward different product decisions.

Lock-In Is Not Loyalty

Another part of the question was whether a desktop app makes it harder for users to switch away.

Maybe. But I don’t think making it difficult to leave is the same as earning loyalty.

I would rather have people stay because the product does something valuable for them. Creating barriers can also give someone a reason not to buy in the first place.

From the business side, I can see why a subscription model might be attractive. You can think about retention, expanding usage, and offering more value to existing customers.

That doesn’t prove a subscription is the right model for your product. And it doesn’t prove web apps are more profitable. I’m describing why I think a business might explore that direction, not presenting market research.

The implementation and the pricing model deserve separate decisions. Don’t let “we want subscriptions” quietly turn into “therefore our users don’t need offline access.”

Don’t Rewrite A Working Product To Follow A Trend

If you already have a desktop application, this conversation isn’t automatically a reason to replace it.

What problem would the replacement solve?

If you’re weighing rewriting against refactoring, start with the capability you need rather than assuming a new platform fixes everything.

You might be able to share more of the underlying logic. You might need a new client for a particular audience. Or keeping the current product might be the right answer.

And remember the maintenance side. Managing technical debt is still work in a web app. A different delivery mechanism doesn’t erase the cost of supporting what you’ve built.

Actionable Tip

Pick one important customer workflow. Try the smallest realistic version of it in the alternative you’re considering. Include the awkward parts, not just the happy-path screen.

Can it work offline when required? Can the user access what they need? Does it perform adequately? Can your team maintain it?

Desktop isn’t dead. Web isn’t a universal answer.

I think the opportunity is having more choices. Our job is to understand the product well enough to make one deliberately.

Which requirement has actually pushed your team toward desktop or web? I’d be interested in hearing the tradeoff, not just the technology you picked.

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:

• Fix the rules, not just the patch.

• Guide good behavior. Gate bad behavior.

• Separate unfinished code from blocked verification.

• No live stream this week! Sorry about that 😦

The Agent Wrote It. The Reviewer Said No.

What do you do when an agent writes the code, puts it up for review, and a human says, “We can’t integrate this”?

I got a submitted question about exactly that. How do you correct the process? How do you stop the same assumptions from carrying into the next change?

My answer isn’t just to tell the agent to try harder.

I want to understand how it got there. Did it miss a rule? Was the rule ambiguous? Did my checks leave a gap? Or did it spend all its time fighting the process instead of finishing the work?

Those aren’t the same problem. And I’ve been running into both.

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

And the irony of all of this? I am pretty sure it was a bot that submitted the anonymous question in at Code Commute... But still a good topic!

First, Was This Supposed To Be Mergeable?

Sometimes I give Copilot a high-level architecture task because I want to see how the pieces could fit together.

I’m not necessarily expecting a production-ready result. I want something concrete to read. Show me the structure. Show me where these responsibilities might live. Then I can decide what I agree with.

That’s different from handing over a small feature with clear acceptance criteria.

If I asked for an exploratory prototype, I’m not going to get upset that I can’t immediately press merge. But I still want to learn from the parts that don’t fit. There are many situations that I find myself having an easier time digesting the concept once I see it applied to the codebase, and since code is cheap... why not? It doesn’t mean I have to merge it though -- that was not the goal.

For delivery work, I want a much tighter boundary. My walkthrough of a bounded change with Claude Code is an example of defining the behavior you want while keeping existing contracts intact.

Actionable Tip: Before delegating, say whether you want an exploration or a change ready for review. Don’t leave the agent to guess which finish line matters.

Working Code Can Still Break Your Architecture

A lot of my projects use vertical slices or plugin-based architectures. Those boundaries matter to me.

I’ve had agents produce something that works, but does it by making plugins know about each other or share code in ways I don’t allow.

From the agent’s perspective, it connected the pieces. From mine, it cheated. In one case, I was positive I already had instructions and tests preventing the pattern. So I went back to the session and asked about it! I was confident that this should have been borderline impossible to even happen.

The explanation was interesting: the guidance and tests existed, but this particular variation didn’t fall into what they covered.

The rule in my head was broader than the rule in the repository.

That’s useful information. Fixing only the generated patch would leave the same opening for the next task.

Instead, I wanted a separate, focused PR to close that gap: update the guidance, extend the tests, and update the analyzer where appropriate.

Guide Good Behavior And Gate Bad Behavior

I try to approach this from two directions.

• First, give the agent enough guidance to build things the right way.

• Second, put checks in place to catch the things it gets wrong anyway.

Only having instructions means I’m depending on the agent to follow them. Only having checks can mean it spends a bunch of time building something before discovering that the approach was never allowed.

Neither side is perfect. I want both. And I try to aggressively get these added into the repository if I am spending any time reviewing and adding feedback.

For my .NET projects, Roslyn analyzers are useful for rules I can express mechanically. Analyzer diagnostics can be configured as errors, giving the agent build feedback rather than waiting for a human to spot the violation. That doesn’t mean an analyzer understands every architectural decision. The rule still has to exist and cover the offending pattern.

This is the same reason I emphasize repository-specific conventions in my Copilot CLI workflow. The agent needs more than a feature description.

Actionable Tip: Take one repeated review comment and ask two questions: “How do we explain the preferred approach?” and “What check would catch this violation?”

Your Teammate’s Agent Needs The Context Too

I’ve also hit this working with a colleague on BrandGhost.

He was using Claude Code. I had been creating guidance for Copilot, but I hadn’t properly synchronized it for his setup. His fault for not using the Microsoft product though, right?!

The resulting PR included patterns I couldn’t accept. But the agent hadn’t received the guidance I expected it to follow, and I didn’t have checks catching those patterns either.

That’s not a fair situation to turn into “Why did you build it wrong?” -- that’s very easy to happen when you aren’t operating under the same guidance.

I had to take responsibility for the missing context. Holding back the PR was still the right call. Blaming my colleague for instructions his agent didn’t have wasn’t.

If your team uses different tools, check what each one actually receives. Don’t assume guidance written for one setup automatically reaches another. A reviewable repository workflow starts with making those expectations and boundaries visible.

Subscribe now

The Code Wasn’t The Only Thing Getting Stuck

I had a working prototype built with Claude Code in roughly ten minutes. I gave it to Copilot to integrate into a hosted environment. Copilot tried it and reported that it could use it.

Heck yeah. Time to rock and roll!

About 72 hours elapsed while I kept giving it work on that integration. That wasn’t 72 hours of me sitting there continuously, but it was still a frustrating amount of time for something I’d already seen working. How could we be multiple days into this when I had literally handed over the working code?

When I inspected the remaining work, six items weren’t the features or fixes I’d asked for.

They were about the infrastructure and process being used to prove the work was done.

For example, it needed screenshot evidence for a before-and-after comparison, but it had run into trouble on the CI host. It was spending time investigating that instead of delivering the evidence.

I suspected waiting and retrying the job might have been enough. I hadn’t established the exact infrastructure cause. That’s a different failure from violating a plugin boundary.

Was the implementation incomplete? Or was the implementation ready to inspect while verification was blocked? I needed those separated, not flattened into one list of “things left.”

I’ve talked before about agent review loops expanding beyond the useful work. More activity isn’t automatically more progress.

In this case, the agent was busy working hard, but it was spending time on things that simply did not matter.

Review The Session, Not Just The Diff

My next step was to go through that session with a reflection skill and ask what went wrong.

I didn’t have the answer yet. Maybe my instructions were misleading. Maybe I hadn’t supplied guidance for recovering from those blockers. Maybe the session would reveal something else.

But asking it to “finish by morning” clearly wasn’t enough. We were several mornings in and I was still feeling the pain.

For your own workflow, I’d start by separating:

• Implementation gaps: Which requested behaviors are still missing?

• Verification gaps: Which claims still need evidence?

• Process blockers: What is preventing that evidence from being collected?

Then decide what a useful next attempt looks like and when it should stop and report the blocker. That’s not permission to call unverified work complete. It’s a way to make the actual problem visible.

I’ve found the instructions-and-checks loop repeatable and useful. Refining the agent’s development process is something I’m still figuring out. That’s the harder part of delegating bounded work to an agent: I want it to navigate the work, not just keep moving.

Actionable Tip: On your next rejected agent PR, don’t stop at “fix this code.” Find the missing guidance, missing gate, or unproductive loop that helped produce it.

That’s the improvement I want to carry into the next task.

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:

• Delegate code, not your quality bar.

• Turn recurring mistakes into automated checks.

• Use telemetry, not just code familiarity.

• Watch the livestream (or recording) on Monday, October 19 at 7:00 PM Pacific!

The Demo Works. Do You Understand The System?

Hey folks!

I came across a post on the ExperiencedDevs subreddit about maintaining quality when agents are writing more of your code. What caught my attention wasn’t someone saying that AI produces terrible code.

It was almost the opposite.

They could get a demo working quickly. The code looked reasonable. But as the application grew, they felt increasingly disconnected from it. When something needed fixing, they weren’t sure how to direct the agent because they didn’t really know what had been built.

I think that’s a much more interesting problem than arguing about whether AI can write a function.

Getting something operational and knowing how to keep it healthy are different things.

I’ve been talking about how AI changes the reasons we choose programming languages. I think there’s a related shift here: if we spend less time personally writing every line, we need to be deliberate about how we maintain our standards.

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

This Feels Familiar From Engineering Management

As an engineering manager, I don’t know every line of code my team writes.

That wasn’t always the case. Earlier in my career, I was managing people and writing code alongside them. As I spent more time managing and less time in that codebase, I became more detached from its implementation.

Does that mean I can’t help the team build good software?

Of course not. But it changes how I help.

I can discuss the problem, question a design, and help establish the patterns we want to follow. If someone needs help with a specific implementation, though, there comes a point where I need to roll up my sleeves and read the code with them.

I see a similar pattern with agents.

If an agent keeps failing to fix a behavior, repeating “make it better” isn’t much of a strategy. At some point, I need to understand the relevant part of the system well enough to ask a better question.

Delegation changes where I spend my attention. It doesn’t remove my responsibility.

That’s also part of what I’ve been exploring while building a game with AI agents. Having something generated doesn’t mean I can stop judging whether the result is what I actually wanted.

Leave Better Breadcrumbs

So what do we do when we need to investigate code we didn’t personally write?

One thing I’d ask an agent to do is walk me through the relevant path. Where does the request enter? What makes the decision? Where does the data get written?

Then I’d check that explanation against the code. A confident summary is useful as a starting point, not proof.

Consistent patterns help here, too. If similar operations follow the same structure, I have fewer surprises to untangle. If every feature introduces another way of doing the same thing, navigating the code becomes harder. This is of course a tax that humans pay when reading code, but I feel convinced that this adds overhead and complexity to agents working in codebases as well.

This isn’t some special AI-only discovery. It’s a reason to care about cohesive software in the first place.

Actionable Tip: When an investigation is painful, don’t stop at fixing the immediate bug. Ask what made the code difficult to navigate. An existing pattern worth reusing or a short explanation of a non-obvious constraint might save you from repeating the whole investigation.

Instructions Are Direction, Not Enforcement

Imagine investigating a slow write operation and discovering that it makes a separate database round trip for every item.

That’s an example to investigate, not a claim that every loop involving a database is wrong. The actual calls, provider, and workload matter.

But suppose you’ve confirmed the problem. You’ve measured it, found an appropriate batching approach, and fixed it.

What happens the next time an agent touches that area?

I want to capture the lesson somewhere it can use. Not “write performant code.” Something more useful: follow this repository’s established write pattern, avoid unnecessary round trips, and preserve the required transaction behavior.

Include the reason. Include where the existing pattern lives.

Repository instructions can give an agent that direction. They’re part of the practical workflow I discuss in my GitHub Copilot CLI guide for .NET developers.

But here’s the important distinction: telling an agent what to do is not the same as proving it did it.

We already understand this with people. You can explain a convention to someone and still need to check for it in review. Instructions help steer the work. They aren’t a guarantee.

Stop Reviewing The Same Mistake Forever

If a rule matters enough that we keep looking for violations, can we check it automatically?

As a .NET developer, one option I think about is a Roslyn analyzer. Analyzers inspect code for particular patterns and report diagnostics. If the relevant rule runs during the build and is configured as an error, a violation can fail that build.

That configuration matters. An analyzer suggestion isn’t automatically a blocked change.

Not every concern fits an analyzer, either. Some rules need information that isn’t available from static analysis. Some checks would take more effort to build and maintain than they’re worth.

For those cases, I might use a test instead:

• An architectural test for a dependency boundary we don’t want crossed.

• A configuration test for a setting the application requires.

• A behavior test for an outcome we need to preserve.

And the tests need to check the actual requirement, not just produce a green result. My article on testing a processing pipeline is one concrete place to explore that kind of thinking.

There are tradeoffs. Instructions are relatively cheap to change, but they don’t enforce themselves. Automated checks provide a repeatable signal, but someone has to design and maintain them. Human review can consider context that a narrow check misses, but I don’t want to spend every review rediscovering the same mechanical violation.

I’d rather combine those approaches than pretend one replaces the others.

Actionable Tip: Pick one recurring problem from your recent reviews. Write down the desired behavior, then decide whether a build check or a test can reliably catch it. Don’t start by trying to encode every preference you’ve ever had.

Your System Needs To Tell You What’s Happening

There’s another piece that becomes more important to me as I know fewer of the specific lines: logging and telemetry.

When you’ve written a feature yourself, you can sometimes recognize a symptom and think, “I know which code path would do that.”

When you don’t have that familiarity, what tells you the story?

With BrandGhost, I want signals I can inspect when something isn’t working. In the larger systems I work with at Microsoft, that need is even more obvious. There are many service instances and dependencies involved. Remembering how one method works isn’t enough to understand what’s happening across them.

Logs, metrics, and traces give us different views of system behavior. They don’t magically explain every failure, but they give us evidence to investigate instead of relying entirely on memory.

If you’re working in .NET, structured logging with OpenTelemetry is a concrete area to explore.

I wouldn’t take that as “log everything.” I’d start with the questions I need answered: Which operation failed? Where did the time go? Can I follow the work across the relevant components?

If I understand less of the implementation from memory, I want better signals, not fewer.

Keep The Bar. Improve The Feedback.

I don’t think the answer is that you must personally memorize every line an agent produces.

I also don’t think the answer is to trust it because the demo worked.

The approach that makes sense to me is to keep improving the feedback around the work:

1. Give the agent useful direction about the patterns you want.

2. Check important, repeatable requirements automatically where practical.

3. Review the decisions those checks don’t cover.

4. Make sure you can investigate the system when it behaves unexpectedly.

When something slips through, use that failure to improve the process. Maybe an instruction was vague. Maybe a check was missing. Maybe you need to understand that part of the code more deeply.

None of this guarantees perfect software. Human teams don’t get that guarantee, either.

But I’d much rather build a process that helps me catch mistakes than keep asking an agent to “make no mistakes.”

That’s the quality bar I want to keep.

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 reduces friction, not engineering responsibility

• Pick languages for the problem you’re solving

• Unfamiliar stacks still need credible validation

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

Are Programming Languages Dead?

I came across a question on the experienced developers subreddit: With AI writing more of our code, does the programming language even matter anymore?

My answer? Yes. But I think the reasons we choose a language are changing.

That is a different conversation from declaring programming languages dead. AI can make an unfamiliar stack more accessible without making every stack interchangeable. It can help you build something without magically removing your responsibility for what you ship.

And honestly, I think that distinction is pretty exciting. We have more options. We still have decisions to make.

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

The Best Language Is Not Always the Best Decision

Imagine you have eight engineers. Seven are comfortable in one language, and one knows another language that looks like a better technical fit.

Do you automatically choose the technically better fit?

I wouldn’t.

Maybe that language gives you more performance. Great. But if adopting it significantly slows the team down, you have to weigh that against getting the product into people’s hands. A performance advantage does not help much if you never ship anything.

It is the same kind of thinking that makes me question whether a tiny product needs Kubernetes and microservices before it has a single user. You might be optimizing something that isn’t your actual problem.

Historically, team familiarity has been a pretty significant part of that tradeoff. I think it still belongs in the conversation. AI just changes how much friction an unfamiliar language introduces.

It doesn’t reduce that friction to zero. It gives us another way to work through it.

I’ve Built Things in Languages I Don’t Know

C# and .NET are usually my tools of choice. Not because I think they’re the best answer to every problem. I’ve used them for a long time, they’re well suited to a lot of what I build, and I can get things done effectively with them.

But I’ve also used Copilot to build MCP servers in Go. I hadn’t written Go before. I wasn’t purposefully reading Go code either.

Why choose it?

For those little servers, I liked the smaller package and the ability to distribute something that could just run without asking the user to install additional dependencies. Could I bundle dependencies with .NET? Absolutely. Go wasn’t the only viable answer.

The difference was that I could consider it without first deciding to spend a bunch of time learning Go just to build an MCP server.

I’ve also built things in Rust with AI. For those projects, performance and dependency-free distribution were characteristics I wanted to lean into from the beginning. Did the projects absolutely need Rust? No.

AI made the choice accessible. It didn’t make the choice mandatory.

There is an important caveat here: These were side projects, not mission-critical systems with tons of paying customers. A bug in one of those MCP servers is not the same kind of problem as an outage in a service people depend on.

That distinction matters. Building a game with AI still left me responsible for checking what it produced. A different language doesn’t change that relationship.

Actionable Tip: If you want to try an unfamiliar stack, pick a small project where a mistake is recoverable. Be explicit about what you want to learn and what level of risk you’re accepting.

Subscribe now

Your Team Still Has to Own the Result

I’ve lived through a team adopting Rust for a new product because its language characteristics were a good fit. The engineers didn’t have prior professional experience with it, and the decision included accepting that development would take longer while they learned.

That was a tradeoff, not an oversight.

With AI, I think a decision like that can become easier to make or rationalize. You have tools that can help engineers navigate unfamiliar syntax and implementation details.

But you still need to ask: How confident are we in the software we’re building?

If your team isn’t comfortable having agents generate code in a stack nobody understands, that is a meaningful constraint. Don’t pretend it disappears because someone says the models are getting better.

If something goes wrong, your customers aren’t going to accept, “Well, the agent wrote it.” Neither is your boss.

You own what you ship.

I’ve talked about deciding what part of software development you keep when AI writes the code. For this conversation, accountability is one part you don’t get to hand away.

Actionable Tip: Before adopting a new stack, answer three questions with your team:

1. What benefit are we choosing it for?

2. How will we establish confidence that it works?

3. Who can diagnose and recover from a failure?

If the answers are vague, generating more code isn’t going to make them clearer.

Syntax Familiarity and Technical Fit Are Different Things

I don’t particularly enjoy reading Rust. That’s my personal preference, not a verdict on Rust as a tool.

With AI doing more of the implementation, I can put less weight on whether I enjoy the syntax and more weight on whether the technology fits what I’m building.

That doesn’t mean software engineering knowledge stops mattering. I’ve been programming for a couple of decades. I’m still defining what I want the product to do, thinking about the architecture, and deciding how systems should integrate.

I’m changing how the code gets written. I’m not abandoning those decisions.

The ecosystem matters too. If you’re building a web application, you might choose TypeScript or JavaScript because the libraries and tooling fit your needs. That isn’t a claim that Rust, Go, or C# can’t do the job. It’s a reason to look beyond the syntax.

Sometimes you don’t need to move your whole application to another stack at all. Connecting a C# application to a separate agent runtime is one example of keeping a familiar application boundary while using another technology where it fits.

And an existing product is a different decision from a greenfield project. AI helping with a port doesn’t automatically make a rewrite worth doing. There still needs to be a reason to incur that cost.

Confidence Needs Something Behind It

When I say you need confidence in how the software is built, I don’t mean you need to feel impressed by the output.

I’ve had an AI model catch useful bugs while review loops expanded the scope and time. Those two things can both be true. A tool can be valuable without every behavior being something you want.

So if you’re using an unfamiliar language, give yourself something concrete to evaluate.

Can you run the result? Can you check the behavior you actually need? What happens when an input is wrong or a dependency fails? Does the packaging advantage you chose the language for actually show up?

For example, testing a processing pipeline means checking faults, cancellation, and cleanup, not just confirming that the happy path returned something. The implementation language might change, but those kinds of engineering questions don’t go away.

Actionable Tip: Build one small, end-to-end slice in the proposed stack. Evaluate the characteristic that motivated the choice, and exercise a failure path. Use that evidence to decide whether to expand the experiment.

Where I Think This Goes

My hypothesis is that knowing a language’s syntax will matter less in our decision to use it as these tools become more capable.

Not that every language becomes equally good at everything. Not that everyone suddenly stops writing code. And definitely not that knowing how to engineer software becomes irrelevant.

I think we get more room to choose based on the problem rather than being boxed in by which syntax we already know.

Could programming languages eventually be designed more around agents than humans? Maybe. I’m curious about that, but I don’t know enough about LLM training to make a strong claim about what would actually work better.

That is a thought experiment, not something I’d use to justify a technology decision for my team.

For now, my position is pretty simple: Programming languages still matter. AI is changing the tradeoffs around choosing them.

Use that flexibility where it helps. Keep the responsibility that comes with it.

Would you trust your team to ship something in a language none of you know well? What would you need to see before you’d be comfortable doing it?

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:

• AI agents need scoped, reviewable slices

• Autopilot still needs experienced checkpoints

• Expertise matters most at the boundaries

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

Building a Game With AI Is the Easy Part

I got into software development because I wanted to make games. That was the original spark for me, and even after more than 20 years of programming, I keep coming back to it.

One of my role-playing games has been evolving on and off for roughly two decades. Another project, currently called EVO: Habitat Zero, is a creature breeding and caretaking game inspired by something I played as a kid. These are not the only things I am building either. I still have BrandGhost moving full speed ahead, a SQL workbench project called Skweel, and a secure agent-to-agent communication platform in progress.

Why keep all of these projects around? Because side projects give me a place to explore ideas that matter to me. They let me test technology, architecture, product decisions, and now AI-assisted development without pretending every experiment needs to become a polished business.

The interesting part is not that an AI agent can generate code for a game. We already know these tools can generate code. The interesting part is what happens when you give one a backlog, let it run on autopilot, and then discover where your own judgment is still doing the real work.

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

Start With Decisions, Not a Giant Prompt

I did not begin by telling an agent, “Go make me a game.”

While I was traveling, I used ChatGPT to talk through the high-level mechanics and capture the decisions in Markdown. I chose Unity. I wrote down architectural ideas. I described how the creatures should behave and how the player should interact with the systems. This was not a giant specification with every detail locked down. It was enough context to establish direction.

Then I handed those files to Astra and asked it to do three things:

1. Decompose the design into high-level GitHub issues.

2. Put those issues into a sensible implementation order.

3. Deliver the game through small vertical slices.

I was also explicit about what not to do. I did not want every issue fully specified up front. When an issue was ready to be worked, the agent could break it down with the latest context instead of following a stale plan written weeks earlier.

That distinction matters. A huge prompt can produce a huge amount of output, but output is not the same thing as progress.

Actionable Tip: Give your agent enough context to make the next decision well. Do not force it to predict every decision for the rest of the project before the first useful slice exists.

Build the Smallest Thing You Can Inspect

The implementation plan started with questions I could answer by looking at the game:

• Can Unity display a creature?

• Can that creature animate?

• Can it move through the scene?

• Can its animation change with its internal state?

Each answer moved the project forward. More importantly, each answer gave me something concrete to inspect.

This is exactly why I like vertical slice development as a way to deliver useful behavior incrementally. The agent was not spending weeks building disconnected infrastructure and promising that a game would appear eventually. It was producing visible, playable behavior.

There is a tradeoff here. Horizontal groundwork can be necessary. You still need systems that support future features. But when an agent is generating a large amount of code quickly, vertical slices create feedback points before the volume gets away from you.

Fast code generation makes short feedback loops more important, not less important.

Autopilot Does Not Mean Unattended

I have let Astra work through the backlog on autopilot. That sounds like I handed over the repository and disappeared, but that is not what happened.

I check in regularly. I ask it to open Unity to a scene that demonstrates the latest functionality. While the main session continues working on the next slice, I can see what has actually changed in the game. Every check gives me evidence instead of a progress summary.

That is the part people can miss when they hear “autonomous agent.” Autonomy changes how often I need to type instructions. It does not eliminate accountability.

The workflow is closer to:

1. Give the agent a bounded objective.

2. Let it implement and validate the slice.

3. Inspect the behavior in the real application.

4. Correct the direction while the change is still understandable.

5. Continue only when the project still makes sense as a whole.

I use the same philosophy when I am delegating real work through agentic development workflows. The point is not to hover over every generated line. The point is to establish boundaries and feedback loops that make drift visible.

Actionable Tip: Ask the agent to demonstrate the feature in the environment where users will experience it. A written summary is useful, but it is not proof that the software works.

The Playable Test Case Surprise

One of those check-ins exposed something awkward.

The agent had been delivering the vertical slices as separate demo scenes. Each scene showed that a capability worked, but they did not yet feel like one cohesive game. It was almost like I had a collection of playable test cases:

• One little experience for this mechanic

• Another little experience for that mechanic

• A different scene for the next capability

Was that wrong? Not entirely. Those scenes made the behavior easy to isolate and verify. They were useful artifacts.

But they were not the product I had in mind.

So I asked whether the roadmap included bringing those pieces together into the actual gameplay experience. It did. The agent could explain where that integration work belonged and why the current phase was still focused on isolated mechanics.

That was a good answer, but I only got it because I noticed the gap and asked.

This is where your role shifts. You are not just reviewing syntax. You are reviewing whether the implementation strategy still leads to the intended outcome.

Your Expertise Sets the Ceiling

The software side of the project has gone well. I have been programming for more than 20 years, and I am comfortable evaluating architecture, behavior, and implementation choices.

The art side? That has been a different story.

I am not a 3D modeler. I do not have deep experience with game materials, textures, or professional art direction. So I gave the agent a vague version of “make professional game assets and do not make mistakes.”

You can probably guess how that went.

It produced a space station interior. It made creature models. It checked boxes about polygon counts and materials. It was also hilariously bad. One creature started as a strange-looking fox and somehow became a compressed, ball-shaped version of that fox. The agent was proud of the result. I was trying to understand how we had arrived there.

The problem was not simply that the model failed. The problem was that I lacked the domain expertise to give it a strong target and evaluate the process early.

This is one reason I keep coming back to the question of what developers should retain when AI can write more of the code. Your judgment, taste, and ability to recognize a bad direction become more valuable as execution gets cheaper.

AI can amplify expertise. It can also amplify ambiguity.

Better Inputs Beat Louder Instructions

My next move is not to yell “make it professional” more forcefully.

I need to give the art agent better references. That might mean finding a high-quality texture that communicates the material I want, providing a model that demonstrates the proportions, or assembling a small visual language the agent can follow.

I do not want the final game to look like a pile of unrelated free asset packs. But a reference asset can establish the direction in a way that paragraphs of vague adjectives cannot.

This is not unique to game art. Templates, examples, constraints, and known-good starting points help agents reason about the result you actually want. I have seen the same thing while feeding AI workers reusable project templates. The fancy orchestration is useful, but a strong foundation often creates the biggest improvement.

Actionable Tip: When an agent repeatedly misses the mark, stop adding adjectives. Give it a concrete reference and define what should be preserved, changed, and validated.

Keep the Agent Fast and the Feedback Faster

I am genuinely excited by how much of Evo Habitat Zero has come together while an agent works through the backlog. Seeing new mechanics appear in Unity is fun. Watching the art agent confidently produce nightmare fuel is also fun, just in a very different way.

But the biggest takeaway is not “AI can build games now.”

It is this:

Give the agent clear direction, small slices, concrete references, and frequent opportunities to prove the work.

Let it move quickly where you have the expertise to evaluate the result. Slow down where you do not. Bring in stronger references or actual domain experts when your own judgment cannot reliably close the gap.

That is not a limitation of agentic development. That is the discipline that makes it useful.

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:

• Higher pay does not erase startup risk

• Your risk tolerance changes over time

• Treat equity as uncertain upside

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

Should You Leave A Stable Job For An AI Startup?

A developer asked me about a decision that sounds exciting and uncomfortable at the same time.

They are already working for one of the top employers in their country. The role appears reasonably stable, the pay is fine, and they can generally log off around five. But recruiters are reaching out about AI startups offering 50% to 60% more money.

So what is the catch?

Maybe longer hours. Maybe on-call work. Maybe less stability. Maybe equity that becomes incredibly valuable, or maybe equity that never becomes worth anything at all.

This is exactly the kind of decision where I do not think there is one correct answer. The useful thing is not for me to tell you, “Take the startup job,” or, “Stay where you are.” The useful thing is to make the tradeoffs visible enough that you can decide whether the risk actually fits your life.

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

There Is No Universal Risk Profile

My younger self and my current self would evaluate this opportunity very differently.

Early in my career, I had fewer responsibilities. I was not married. I did not have pets. I had paid down most of my school debt through internships, and I had already spent six internships working at small companies. I knew I liked that environment.

My first full-time role was at a startup. I would love to tell you that I researched every variable and made the mathematically perfect choice. I did not. Some of it was judgment, and some of it was luck.

What mattered was that I had room to take the chance. If the job demanded a lot from me, I was prepared to work hard and see where it went.

My life is different now. I am married. We have pets. If we decide to have children, that changes the equation again. My choices do not affect only me anymore.

That does not make the startup good or bad. It means the same offer can be a smart risk for one version of you and the wrong risk for another.

I wrote recently about how career fulfillment changes as your life changes. Risk tolerance works the same way. You need to revisit it instead of assuming the answer you had five years ago still applies.

Actionable Tip: Before comparing jobs, write down what you are protecting right now.

• Time with your family

• Predictable income

• Health benefits

• Career acceleration

• Learning opportunities

• Flexibility

• A mission you care about

If you do not know what matters most, the largest salary number will make the decision for you.

Compare The Full Trade, Not Just The Salary

A 50% to 60% raise is meaningful. I am not going to pretend otherwise.

But salary is only one line in the offer. If you move from a predictable schedule to consistently working nights, weekends, or on-call rotations, you are trading more than one employer for another.

You are trading time. You are trading energy. You may be trading certainty. Depending on the company, you may also be trading a clear role for whatever problem is on fire that week.

That environment can be energizing. It can also be exhausting.

I have talked about what four years in big tech taught me after working at startups, and one of the biggest differences is not that one environment has problems and the other does not. It is that the problems often have a different shape.

At a large company, stability does not mean layoffs are impossible. We have all seen that. What it often means is that the company is not relying on one product, one small customer base, or the next funding round to make payroll.

At a startup, those business risks can be much closer to your day-to-day reality.

Actionable Tip: Translate the offer into the actual trade you expect to make.

1. What compensation is guaranteed?

2. What hours do people really work?

3. How often is the team on call?

4. How much runway does the company have?

5. What happens if the next funding round does not happen?

6. What would you lose by leaving your current role?

The goal is not to make the startup look scary. The goal is to stop comparing one complete job with one attractive number.

Equity Is Not The Same As Cash

Startup equity can be exciting. It can also make an offer feel much larger than it really is.

The important reality is simple: the company has to become valuable for that equity to become valuable.

That can happen. People join startups, work incredibly hard, and end up with a life-changing outcome. It is also not the most common outcome.

My mental model would be to make sure the guaranteed compensation works for me first. Then I would treat the equity as uncertain upside.

Ask about:

• The number and type of shares or options

• The current valuation

• The strike price

• The vesting schedule

• The exercise window if you leave

• Expected dilution

• Whether there is any realistic liquidity path

You do not need to become a venture-capital expert. You do need to understand enough to avoid mentally spending money that may never exist.

The same applies to the mission. If you strongly believe in what the company is building, that can absolutely matter. I have written about how much company alignment matters for developers, because believing in the work can make a difficult season feel worthwhile.

Just do not let belief in the mission replace basic due diligence.

Startup Learning Can Be Incredible

I think startups can be some of the best learning environments available to a software engineer.

Why? Because there is usually so much happening that it is almost impossible not to learn.

There may not be a specialist for every problem. The company may be solving something for the first time. You might need to move between architecture, implementation, operations, customer feedback, hiring, and planning much faster than you would in a more established organization.

That chaos is not automatically bad. It can force you to develop range, judgment, and comfort with ambiguity.

Of course, constant switching has a cost. The context-switching problem looks different across startups and large companies, but neither environment is magically free from it.

The question is whether the learning is worth the pace for you.

If your goal is to compress a huge amount of experience into a few years, a strong startup can be an incredible opportunity. If you are already near burnout, need predictability, or want to protect time outside work, the exact same environment may be a terrible fit.

Subscribe now

Interview The Startup Back

A company can tell you that it has excellent work-life balance. You will learn more by asking for concrete examples.

Try questions like:

• What did the team work on outside normal hours in the last month?

• How often are engineers paged while on call?

• What happens when a deadline slips?

• How many people have left the engineering team in the last year?

• What is the company’s current runway?

• Which assumptions must become true for the business to succeed?

• Why is this role open?

• What would make someone unsuccessful here?

Listen for specifics.

“We care deeply about balance” is a value statement. “The team had two after-hours incidents in the last quarter, and here is how we handled them” is evidence.

You may still join without perfect answers. Startups are uncertain by definition. But uncertainty you understand is different from uncertainty hidden behind recruiting language.

Run The Failure Scenario

Most people spend a lot of time imagining the upside.

What if the company takes off? What if the equity becomes valuable? What if you learn more in two years than you would learn in five somewhere else?

Those are fair questions. Now run the other scenario.

What if the startup runs out of money? What if the role is not what you expected? What if you leave after six months? What if the job market is difficult when that happens?

Can you absorb that outcome financially and emotionally?

If the answer is yes, the risk may be completely reasonable. If the answer is no, that does not make you timid. It means the downside has consequences you are not willing to accept right now.

Actionable Tip: Decide what failure would cost before you decide what success could pay.

Consider your savings, benefits, visa or residency constraints, family responsibilities, and how long a job search could realistically take. The more fragile the downside is, the more evidence you should demand before taking the bet.

My Answer Is Different Now

At this point in my life, I know how I work. I like working hard, sometimes to a fault. I can get deeply focused on making progress and do a poor job balancing everything else.

Because of that, if I joined a startup again, I would probably assume I was consciously giving up some work-life balance. Maybe the company would prove me wrong, but I would not build my decision around that hope.

I have also said that if I put startup-level energy into something again, it would most likely be my own company. There are a very small number of people who might convince me otherwise, but I know how much effort a successful startup can require. I do not think I have that effort available for somebody else’s vision right now.

That is part of why I still build side projects and think carefully about what I want to build next. They let me explore ideas and create things while keeping control over how much of my life I am willing to trade.

Your answer may be completely different, and that is the point.

Subscribe now

The Decision Is Big, But It Is Not Permanent

Changing jobs is a major decision. It is not a permanent identity.

You can join the startup and discover that it is not for you. You can stay in the stable role and reconsider when your circumstances change. You can interview, learn more, and decide the offer is not strong enough.

If a startup fails, that is not the end of your career. It may be inconvenient. It may be stressful. Finding another role may take time. But if you keep learning, working hard, and pursuing opportunities, one company failing does not erase what you gained.

So should you leave a stable job for an AI startup?

Maybe.

But do not make the decision because AI is exciting, the recruiter created urgency, or the salary number is large. Make it because you understand the workload, the business risk, the learning opportunity, the mission, and the downside, and you still believe the trade fits the life you have 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:

• Fulfillment changes as your life changes

• Career decisions are rarely permanent

• Meaningful impact is personal

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

Is Anyone Actually Fulfilled With A Software Engineering Career?

A developer asked a question that sounds simple but gets complicated very quickly: Is anyone actually fulfilled by a career in software engineering?

This was not really another conversation about AI taking jobs or changing how we write code. It was a much broader question about whether the career itself gives people what they hoped it would.

I have been thinking about this recently because I had an intern on my team, and we talked through some of the choices that show up early in a career. Do you go directly into the workforce? Do you continue school? What kinds of roles or industries might fit? Those decisions can feel enormous when you are making them.

The thing I wanted to make clear is that fulfillment does not have one permanent definition. It can look different from person to person, and it can look different for the same person as life changes.

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

Fulfillment Is Allowed To Change

I think most people have some core values that remain fairly stable. The way those values show up in your life, though, can absolutely shift.

At one point, career growth might be the thing you prioritize most heavily. At another point, family, flexibility, health, education, or time outside work might carry more weight. That does not mean you were wrong before. It means your situation changed.

This is why I do not think career fulfillment is something you answer once and then lock in forever.

If you never revisit it, five years can pass before you realize that four years and eleven months of a role have felt completely wrong. The first month was exciting because everything was new, and then the rest became something you tolerated.

That does not mean you need to conduct a dramatic career review every week. It means you should check in often enough to notice when the work no longer fits. I have written about building a career that fits how you operate, and the same idea applies even when burnout or ADHD is not part of the question. A career can look successful from the outside and still be a poor fit for the person living it.

Actionable Tip: Put a recurring career check-in on your calendar. Quarterly might work. Yearly might work. The exact cadence matters less than making sure the reflection actually happens.

Ask yourself:

• Which parts of my work give me energy?

• Which parts consistently drain me?

• Am I learning, contributing, or moving toward something I value?

• Has my answer changed since the last time I asked?

You do not need to make a giant change every time. Sometimes the answer is simply, “This still works for me.” That is useful information too.

Most Career Decisions Are Not Permanent

Early career decisions can feel like doors that close behind you.

If you start working after school, can you ever go back for a master’s degree? If you choose graduate school, are you falling behind everyone who entered the workforce? If you move into management, have you permanently left technical work behind?

These choices have tradeoffs. Going back to school while working full-time is not trivial. Changing roles may cost time, money, comfort, or momentum. But difficult is not the same as impossible.

I have known people who completed a master’s degree part-time while working. Plenty of engineers have moved from individual contributor roles into management and then returned to individual contributor roles. People change industries. They take time away. They discover that the path they selected was not what they expected.

That flexibility matters because what comes after senior software engineer is not one universal promotion ladder. Success might mean staff engineer, management, a different specialty, a smaller company, independent work, or staying exactly where you are because the work fits your life.

The goal is not to avoid making a choice. The goal is to stop treating every choice as a life sentence.

The Role And The Career Are Different Questions

Sometimes people decide they are no longer fulfilled by software engineering when the actual mismatch is narrower.

Maybe the domain does not interest you. Maybe you do not believe in the company’s mission. Maybe the team environment is unhealthy. Maybe the role asks you to spend your time in ways that no longer line up with what you enjoy.

That distinction is important.

An engineering manager who keeps reaching for coding tasks might not hate software engineering. They might miss building things. Someone who feels disconnected from a product might not need a new profession. They might need a domain where the outcome matters more to them.

This is why I think the management trap in software engineering is worth understanding before treating management as the automatic next step. Management is a different job. It can be incredibly fulfilling, but it does not become fulfilling merely because it comes with a promotion or better compensation.

I have been managing teams for roughly thirteen years, and I still genuinely love building software. In my primary role, spending more time coding would usually mean spending less time on the people and organizational work that I am actually responsible for. That is a real tradeoff.

AI tools have created a few more opportunities for me to build things without taking focus away from the team, which I appreciate. But the underlying question remains: Do I still value the work my role needs from me?

The same tension exists before management too. As senior engineers spend less time coding, their impact often shifts toward design, communication, mentoring, and helping other people move faster. If writing code is the only part that feels meaningful, that shift can be uncomfortable.

Impact Is More Than How Many People You Reach

When I think about fulfillment in my own career, I keep coming back to impact. Not performance-review impact. Not the biggest number I can put beside a project. I mean impact on an area of life that matters to me.

Earlier in my career, I worked on digital forensics software used by investigators, examiners, and law enforcement. The software helped people recover and understand evidence from digital devices. The total audience was much smaller than the audience touched by the work I do now, but the impact on an individual case could be enormous.

My current work can affect experiences for hundreds of millions of people. That is massive reach. At the same time, one request taking a little longer for one person does not feel as personally significant as helping uncover evidence that contributes to finding the truth in a case.

Neither form of impact is fake. They are simply different.

In my role now, much of the personal fulfillment comes from working directly with people. I get to help engineers grow, progress in their careers, and work through challenges. That gives me some of the individual impact that I value even when the product impact is broad and less personal.

This is also why company alignment matters for developers. If the organization’s mission is deeply connected to something you care about, the work itself may provide a strong sense of purpose. If it is not, fulfillment may need to come from the craft, the people you support, the flexibility the job provides, or the life the job enables outside work.

There is no rule that says your employer must be the source of all meaning in your life. Some people want work to be a reliable nine-to-five that funds everything they care about after five. That is completely valid.

That is not how I personally think about work. I enjoy working, and I spend too much of my life doing it to settle indefinitely for, “This feels okay.” But that is my answer. You need to understand yours.

Run The Smaller Experiment

If your honest answer is that the work is not fulfilling, resist the urge to jump immediately to the largest possible conclusion.

“I hate this project” does not automatically mean “I hate software engineering.”

“I miss coding” does not automatically mean “I failed as a manager.”

“I want a different kind of impact” does not automatically mean “Everything I built in this career was wasted.”

Actionable Tip: Identify the smallest change that could test what is actually missing.

• Try a different type of project

• Ask for more mentoring or design responsibility

• Explore another team or business domain

• Talk with an individual contributor who returned from management

• Take a course before committing to another degree

• Build something outside work to see whether creation is the missing piece

Small experiments give you evidence. They help separate dissatisfaction with one environment from dissatisfaction with the entire career.

Do Not Settle For “Fine” Without Checking

So, are software engineers actually fulfilled?

I hope many of us are. I enjoy what I do, and I can still say that I could be more fulfilled. Those statements are not contradictory.

Fulfillment is not a finish line you cross after getting the right title, salary, or employer. It is an ongoing alignment between what you value and how you spend your time. Because both sides can change, the conversation has to happen more than once every five years.

Check in with yourself. Separate the role from the industry. Think about the kind of impact that matters to you. Remember that most career decisions are not carved in stone.

You spend too much of your life working to never ask whether the work still fits.

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:

• A missed date is not a PIP

• Ownership means finding the next move

• Manager accountability covers people and outcomes

• No livestream... I am on vacation!

When A Developer Misses The Deadline, Who Owns It?

A question came up in the comments about what happens when an engineer does not deliver a project on time.

Does the developer get put on a performance improvement plan? If the manager cannot get the developer back on track, does the manager get put on one too?

It is a fair question, but it starts from a framing that I think is too simple. A project slipping does not automatically mean somebody failed at their job. Real projects have dependencies, changing constraints, technical surprises, and decisions that turn out differently than expected.

The more useful question is this: When the plan stops working, who takes ownership of figuring out what happens next?

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

A Missed Milestone Is Not An Automatic PIP

Let’s start with the most important distinction.

A performance improvement plan is not supposed to be the automatic consequence of one missed milestone. A project can slip for all kinds of reasons:

• Another team misses a dependency

• An external vendor falls behind

• The original technical approach does not work

• The scope was larger than anyone understood

• A higher-priority incident interrupts the plan

• The date was unrealistic from the beginning

None of those automatically means the engineer assigned to the project is performing poorly.

There is a difference between the outcome being off track and the person refusing or failing to engage with the problem. That distinction matters. I have written about when a struggling developer should be raised with their manager, and the same principle applies here: early communication creates room for coaching and correction. Silence removes options.

If you miss a date because a dependency moved, that is one problem. If you knew the dependency moved, said nothing, explored no alternatives, and let everyone discover the delay at the deadline, that is a different problem.

Ownership Starts When The Plan Breaks

When I talk about accountability, I am not saying that you must personally control every variable. You cannot.

What you can control is how you respond.

If the project is slipping, ownership means communicating that clearly. It means looking for alternatives instead of sitting back and hoping the problem fixes itself.

Maybe the date can move. Maybe the scope can shrink. Maybe there is a temporary implementation that meets the immediate need. Maybe your team can help the dependency team finish its work. Maybe you need to abandon the original design and choose something that is available now.

Actionable Tip: When you raise a delivery risk, bring the clearest options you have.

• What changed?

• What does it affect?

• What can still be delivered?

• What tradeoffs could protect the date?

• Who needs to make the decision?

You do not need to have every answer before speaking up. But “the project is late” is much less useful than “the project is at risk, here is why, and here are the three paths I see.”

This is where radical accountability differs from a blame culture. Accountability is about improving the situation. Blame is about finding the person who should absorb the discomfort.

Those are not the same thing.

Managers Own More Than Individual Performance

As an engineering manager, one of the most important parts of my job is helping people do their best work and grow in their careers.

But that is not my entire job.

I am also responsible for the charters of my teams. I currently have three sub-teams working in different areas of a routing plane for Microsoft 365. Those teams have different focus areas, including firewall technology, but they contribute to a larger mission.

If everyone is happy, growing, and producing excellent work that has nothing to do with our charter, I am still failing in my role.

On the other hand, if we deliver everything by grinding people down, ignoring their careers, and treating them like interchangeable output machines, I am also failing.

The job requires both. I need to support the people and help the organization get the outcomes those teams exist to produce. That balance is part of what is expected from an engineering manager.

So when a project slips, I cannot point at the engineer and say, “That was their project.” I might not be the person writing the code or coordinating every dependency, but I am accountable for whether the team has the clarity, support, coaching, and escalation paths needed to move forward.

Accountability Bubbles Up The Organization

This does not stop at the engineering manager.

If I repeatedly ignore my team’s charter, miss important outcomes, or fail to coach people who need support, my manager should notice. If that continues for months and nobody addresses it, accountability moves another level up.

Every layer has expectations of the layer below it.

That does not mean every missed delivery triggers a chain of performance plans. It means leaders should be able to explain what they own, how they know whether it is healthy, and what they are doing when it is not.

This is why measuring manager effectiveness is so difficult. You cannot reduce the role to one number. Technical direction, delivery, hiring, coaching, team health, and stakeholder trust all matter.

A manager might be strong at supporting people but weak at connecting their work to the team’s charter. Another might drive delivery while leaving a trail of burned-out engineers. Neither extreme is what I would call effective management.

Coaching Is Part Of The Manager’s Deliverable

The original question also called out hiring and coaching. Yes, managers should be accountable for both.

If I repeatedly make poor hiring decisions, someone should ask whether I need help improving how I assess candidates. If an employee needs performance support and I neglect them, that is not the employee’s failure alone. Coaching and mentoring are part of my job.

That does not mean every unsuccessful performance plan proves the manager failed. Sometimes a manager can provide clear expectations, frequent feedback, practical support, and reasonable opportunities to improve, and the employee still does not meet the role’s requirements.

The accountability is in doing the work properly.

Actionable Tip: If you manage people, do not wait for a formal process before providing useful feedback.

Use regular conversations to make expectations visible. Talk about what is going well, what needs to change, and what support would help. Effective one-on-ones should evolve around the person and the situation, not become a calendar ritual where neither person says anything meaningful.

If a formal performance process becomes necessary, it should not be the first time the employee hears that there is a problem.

Ask What Each Person Did Next

When something goes wrong, I would avoid jumping immediately to, “Who gets put on a PIP?”

Instead, ask:

• When did the risk become visible?

• Who communicated it?

• What alternatives were explored?

• What support did the engineer request?

• What coaching did the manager provide?

• What decisions did stakeholders make?

• Did this happen once, or is it a repeated pattern?

Those questions give you a much better picture of accountability than the missed date by itself.

Projects will slip. Dependencies will fail. Estimates will be wrong. That is software engineering in the real world.

Ownership is not pretending you can prevent every problem. Ownership is refusing to become passive when the problem appears.

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:

• AI changes the work, not your interests

• Keep the parts that energize you

• Offload friction without surrendering judgment

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

AI Can Write The Code -- What Part Do You Keep?

There is a version of the AI conversation that is mostly about fear: Are software engineers getting replaced? The question that caught my attention from the ExperiencedDevs subreddit was different.

This developer was not primarily worried about losing their job. They were worried about losing the part of software development that made them care in the first place.

They can hand increasingly complex work to an LLM and get something useful back. That’s impressive, but it also leaves them wondering where they fit into the process. The building, the problem-solving, and the feeling of making something are starting to feel different.

I’ve talked before about how AI career fears are evolving, but this is not just another replacement-anxiety discussion. This is about engagement. If AI can perform more of the work, what part of the work do you actually want to keep?

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

I Would Start With Questions, Not A Prescription

If I were talking directly to this person, I would not jump straight to, “Here’s the best AI stack,” or, “Here’s the correct way to stay motivated.”

I would ask questions.

• What part of software development used to pull you in?

• Was it exploring a hard problem before the solution was obvious?

• Was it designing the system?

• Was it writing the implementation yourself?

• Was it learning an unfamiliar technology?

• Was it simply seeing an idea come to life?

Those answers matter because two developers can do the same job and love completely different parts of it.

I’ve had people tell me they genuinely enjoy working in legacy codebases. They like the constraints. They like figuring out how to move one piece without breaking five others. Someone else might look at the same situation, read about dealing with legacy code, and think, “Please let the AI handle all of this.”

Neither person is wrong. They are motivated by different challenges.

The Industry Is Optimizing For Throughput

My own experience with AI coding tools has changed quickly. Not that long ago, I could hand over a non-trivial feature and the result was somewhere between, “Cool, that worked,” and, “I just created more work for myself.”

There were tasks I would not even bother delegating because I expected the back-and-forth to cost more than doing the work myself.

That line keeps moving.

The models are more capable. The tools around them are better. Skills, instruction files, custom agents, and stronger development harnesses let us provide useful context without manually writing a 400-page specification for every task.

I do not think “one-shot everything” is a useful goal by itself. I also do not think the future of software development is engineers spending all day writing absurdly detailed specs. But the direction seems clear: AI is taking on more ambiguous work with less explicit supervision.

That means organizations will keep looking at throughput. If one person can move several workstreams forward with AI while another person insists on manually completing every step, there may be pressure on the second person to change.

That is not a moral judgment. It is a constraint worth acknowledging.

I’ve shared some of my real GitHub Copilot CLI workflows on a C# codebase, and the benefit is not that I can avoid thinking. The benefit is that I can spend more of my thinking time where it has the most value.

Find The Zoom Level You Actually Enjoy

I think about software development at different “zoom” levels. It’s actually something I apply when thinking about codebases, system architecture, workflows... and even careers!

At one level, you care about the exact loop, condition, and method. Zoom out, and you care about how the classes collaborate. Zoom out again, and you care about service boundaries, data movement, and the shape of the system.

Some people love the implementation details. Some love the architecture. Some love experimenting in the problem space before any architecture exists.

For the developer who raised this question on the original Reddit post, it sounded like the early problem-solving pass might be the part they want to preserve. They want to explore the difficult problem themselves and bring in AI afterward.

That can be a completely reasonable operating model. The important part is understanding the tradeoff. If that early pass becomes the bottleneck while everything around you is optimized for throughput, you may need to adjust how much of it you keep, how long you spend there, or what you hand off afterward.

Actionable Tip: For one week, keep two short lists:

• Work that gave you energy

• Work that drained your energy

Do not write broad labels like “coding” or “meetings.” Be specific. Was it shaping an API? Untangling a production issue? Writing repetitive mapping code? Reviewing a design? Learning a new domain?

Patterns will show up. That kind of reflection matters well beyond AI, and it is part of building a career that fits how you are wired.

Let AI Take The Friction

Once you know what you want to keep, look at the rest of the work.

Maybe you hate writing boilerplate. Maybe tests, observability, or security reviews are the tasks you procrastinate on. Maybe you love designing a feature but lose all momentum when the implementation becomes repetitive.

AI can help with those parts, but “give it to AI” is not the same as “stop being responsible for it.”

If I want an LLM to handle work that I do not enjoy, I still need to set it up to succeed:

1. Explain the outcome, not just the task label.

2. Provide the constraints and relevant context.

3. Define how the result will be checked.

4. Review high-risk decisions instead of trusting plausible output.

Otherwise, I have not removed the frustrating work. I have replaced it with babysitting an agent that keeps producing the wrong thing.

The goal is not to surrender judgment. The goal is to reduce the mechanical effort around the judgment.

What I Actually Love About Building Software

This thought exercise made me look at my own patterns.

Historically, I have loved building frameworks and reusable systems. Many many moons ago, I built UI framework experiments in XNA and Unity. I have spent time creating ridiculously overcomplicated libraries that almost nobody would use, sometimes including me.

Why? Because exploring the shape of those systems was fun.

The same pattern shows up in things like BrandGhost and Needlr. BrandGhost started because I needed a tool as a content creator and wanted to build it. Needlr grew out of the way I liked structuring C# applications. Both gave me a chance to take an idea, shape it, and watch it become real.

That is the key for me: I like seeing ideas come to life.

I care about technical direction. I care about architecture. I care about patterns that will create headaches if they spread across a codebase. I do not feel emotionally attached to writing every if statement or choosing between a for loop and a while loop.

For a long time, writing all of that code was simply the price of admission.

There was also an almost inevitable point in some side projects where the design ballooned, I realized I needed to undo earlier decisions, and the recovery work felt bigger than the fun part. Historically, that could be where I abandoned the project.

AI changes that balance. It can help me refactor, recover, and fill in the mechanical pieces while I stay involved in the direction. That’s a big reason I still build side projects. I can explore more ideas without every idea demanding the same amount of manual implementation.

AI Can Expand Your Range

There is another benefit here: AI can help you move into areas where you do not have deep experience.

I had an agent put together front-end work for a private dashboard. I could inspect whether the behavior made sense. I could check whether the tests exercised real code instead of a fake system under test. But I did not have years of front-end experience that let me confidently debate every pattern in the implementation.

Without AI, I might have needed to learn an entire stack just to build a dashboard I needed. Blazor has often been useful to me for a similar reason: I can bring my C# experience into web UI work. AI gives me another way to cross that gap.

That does not instantly make me a front-end expert. It lets me produce something useful while being honest about where my judgment is strong and where I need more help.

The same applies to learning. I love the feeling of having learned something, but I am often uncomfortable at the beginning of a new challenge. AI can launch research in parallel, summarize a domain, and give me enough footing to start asking better questions.

It lowers the barrier. I still have to engage with the result.

Build A Personal Operating Model

There is no universal percentage of software development that you should keep for yourself.

Instead, build an operating model that reflects your interests, your role, and the risk of the work:

• Keep the work that gives you energy and develops judgment you want to retain.

• Co-pilot the work you enjoy but can accelerate with feedback or parallel exploration.

• Delegate mechanical work where you can define a clear outcome and verify it.

• Review decisions involving architecture, security, data, and other expensive failure modes.

Then revisit the model. AI capabilities will change. Your role will change. The parts you enjoy may change too.

Actionable Tip: Pick one task you routinely dislike and improve the handoff to AI. Add the context, examples, constraints, and checks it was missing. Do not expand this to everything at once. Prove that the handoff actually saves time before you depend on it.

Humans Are Still In The Picture

I am not convinced the destination is, “People disappear and AI builds everything.”

My expectation is that people become much more amplified by AI and whatever tooling grows around it. I do not have a crystal ball, and I am not going to pretend that I know exactly how every software role changes.

But even in my own projects, the valuable part is not just code appearing faster. It is being able to explore more directions, recover from mistakes that previously killed momentum, and focus my attention on the parts where I have something meaningful to contribute.

That still requires a person deciding what should exist, what good looks like, and which tradeoffs are acceptable.

Wrapping Up

If AI could take over one part of your software development work tomorrow, what would you be relieved to lose?

Now flip it around: what part would you genuinely miss?

That second answer is the important one. It tells you where your interest lives. Keep enough of that work to stay engaged, get better at it because you care, and use AI to reduce the friction around it.

You do not need to reject AI to preserve what you love about software development. You need to be deliberate about where you fit into the process.

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:

• Better code does not guarantee efficiency

• Review loops need stopping conditions

• Scope control still belongs to you

• YouTube would not let me schedule a stream so... no stream 😦

GPT-5.6 Sol Impressed Me -- Then It Wouldn’t Stop

One of the weirdest parts of using a stronger coding model is that the failures can start looking useful.

I had been using the Opus models pretty heavily, especially because the large context window was genuinely impressive. Then I switched back to a GPT model with GPT-5.6 Sol, and my first reaction was basically: holy crap, this thing is good.

I have written before about how different models can change the shape of a Copilot workflow. This was one of the clearest examples I have felt in practice. Sol was not just producing code I liked. It was noticing things around the requested work that other models had missed.

That sounds great, right?

It was. Mostly.

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

Going Off The Rails Can Still Produce Gold

I was trying to explain model differences to my wife, who uses ChatGPT but does not spend her time comparing coding models like some of us do.

The example I gave her was scope drift.

You ask a coding model to change one thing. Then you review the diff and discover that it touched files you never mentioned. With some models, I have looked at those changes and thought, “What were you even doing over here?” The answer is usually some version of: yeah, that was unnecessary.

My early experience with Sol was different.

It touched unrelated tests, but the tests were actually wrong. It found behavior that technically passed the existing test while still being incorrect. It caught bugs in test code and bugs in underlying features that were outside the narrow task I had assigned.

That is a pretty incredible feeling. The model appears to wander, you prepare yourself for cleanup, and then you realize it found something real.

But there is an important distinction here: useful scope drift is still scope drift.

When I am using GitHub Copilot CLI on a real C# codebase, I need to understand what changed, why it changed, and whether that extra work belongs in the same delivery. Finding a bug is valuable. Quietly folding every discovered bug into one feature is not automatically the right move.

A Better Result Can Still Be A Bad Workflow

This is where my opinion became more divided.

I noticed some Copilot sessions taking a really long time. Work that I expected to take maybe thirty minutes would keep going for several hours. I would check the session assuming something had broken in the harness or a sub-agent had died.

Instead, it was still working.

It had run a review. Then it was fixing review findings. Then it was reviewing the fixes. Then another perspective found something else. On one feature, I saw the pull request appear after roughly five hours of agent work, even though the feature itself was not a monumental coding effort.

Was the output good? Often, yes.

Was five hours the right tradeoff? I am not convinced.

We talk a lot about model quality, but delivery has more dimensions than whether the final code passes tests:

• How long did the work take?

• How much unrelated code changed?

• How expensive was the review loop?

• How much attention did I need to spend supervising it?

• Could we have shipped the intended scope much earlier?

A model can produce better code and still create a worse overall workflow if nobody tells it when to stop.

The Review Loop Can Convince Itself

I like review agents. I like rubber-duck agents. I like asking for another perspective before I trust a change.

I also think they can create a nasty feedback loop.

AI is extremely good at sounding confident. Most of us have read an answer and thought, “That sounds believable,” even when we did not have the evidence to prove it. The same thing can happen between agents. A reviewer confidently proposes another improvement, the primary agent accepts the premise, and suddenly the task has a whole new branch of work.

This is not an argument against custom agents and skills in Copilot CLI. I use them constantly. It is an argument for making their boundaries explicit.

One of my sessions started with a few changes to an evaluation harness. When I checked it later, the agent was hand-writing a custom Markdown parser.

What?

That was the software equivalent of walking into your house and finding animals casually having a conversation in the living room. Nobody is acting like anything is wrong, but you know this is absolutely not where the evening was supposed to go.

The parser was not the assignment. The agent had reasoned its way into creating more work, and every additional change gave the next review pass more surface area to inspect.

Better review is not infinite review.

Prototype Mode And Hardening Mode Need Different Contracts

When I am building something, I am usually operating in one of two modes.

The first is prototyping. I want to know whether an idea is feasible. Can I connect these pieces? Does this service do what I need? Is the core experience even possible? The code may be throwaway, and that is fine.

The second is hardening. The feasibility question is already answered. Now I need regression tests, repeatable behavior, operational reliability, and confidence that I can keep changing the system without breaking it.

Those modes need different instructions.

If I am prototyping, an agent that spends hours polishing abstractions has missed the point. If I am hardening, an agent that proves the happy path once and declares victory has also missed the point.

Actionable Tip: tell the agent which mode it is in before describing the task.

For a prototype, define the question you need answered and explicitly deprioritize polish. For hardening work, name the behaviors that need regression coverage and define which adjacent changes are allowed. If the agent discovers something outside that boundary, have it report the finding instead of automatically implementing it.

That one distinction can prevent a lot of “How did we end up building this?” moments.

A Million Tokens Does Not Remove Context Management

The other issue I have seen is around the context window.

GPT-5.6 Sol gives me a huge amount of context to work with, but in some longer Copilot sessions I have still hit a point where the session effectively stops making progress. In my case, this has happened with plenty of context apparently remaining, often somewhere around the final quarter to third of the window.

The frustrating part is that compaction can fail at exactly the moment I need it.

The workaround that helped me during this time was restarting the Copilot process for the same session with /restart, then running /compact. That has let the work continue, but it is not behavior I have seen in quite the same way with other models.

Is that the model? The harness? The interaction between them? I had no idea -- but I do know that it was a pain in the butt.

That uncertainty matters. I am describing what I have observed in my sessions, not declaring a universal GPT-5.6 Sol limitation. And for what it’s worth, Copilot CLI seemed to have been patched for this since I initially was ranting about it on Code Commute.

The broader lesson still holds: session and context management remain part of agentic development. A larger context window delays some problems. It does not eliminate the need for checkpoints, compaction, and clean task boundaries.

What I Am Changing In My Workflow

I am still impressed with the model. I am not switching away because a few sessions ran too long.

But I am changing how I supervise the work.

Actionable Tip: give every agentic task a scope budget and a stopping rule.

Here is what that looks like for me:

1. Define the delivery boundary. Name the behavior, files, or subsystem that belongs in the task.

2. Separate discoveries from implementation. If the agent finds an unrelated bug, capture it unless it blocks the requested change.

3. Bound review loops. One useful review pass is not permission to keep reopening the design forever.

4. Create checkpoints. Ask for a status summary before a long-running session disappears into another branch of work.

5. Watch elapsed time. If a modest feature is still running hours later, inspect the current plan instead of assuming more time means more quality.

Permissions and tool restrictions are still important, and I have a full breakdown of what Copilot CLI can and cannot touch. But permissions only answer whether an agent can do something. They do not answer whether that work belongs in the current task.

That part still belongs to us.

The Model Can Be Impressive And Still Need Supervision

My first impression of GPT-5.6 Sol is still extremely positive.

It caught real problems that I did not ask it to find. It handled code with a level of awareness that surprised me. It made “going off the rails” look productive, which is not something I expected to say.

At the same time, I have watched it spend hours following review loops, expand a small task into a custom parser, and hit context problems before I expected them.

Both things can be true.

The model can be excellent, and the workflow around it can still need tuning. The output can be correct, and the process can still be too slow. The extra finding can be valuable, and it can still belong in a separate issue.

I do not want an agent that blindly stops the second it notices something outside the prompt. That would throw away one of the most valuable parts of a strong model. I want an agent that notices the problem, explains it, and lets the delivery boundary remain intentional.

That is the balance I am working toward: more capability without surrendering scope control.

If you are using GPT-5.6 Sol or another model for long-running coding work, pay attention to more than the final diff. Watch the route it took to get there. That is where the real workflow problems tend to show up.

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:

• Senior is a successful career destination

• Higher levels require broader organizational scope

• Career progression is not a straight line

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

What Comes After Senior Software Engineer?

Have you ever looked at a software engineering career ladder and wondered why everything seems to move reasonably well until senior, and then suddenly the next step feels like a wall?

You’re not imagining that shift.

I have talked before about why engineers can feel stuck at senior, but I want to approach this from a slightly different angle. Sometimes the friction is about your growth, your manager, or unclear expectations. But sometimes the ladder itself genuinely changes shape after senior.

That does not mean you failed. It does not mean your company wants to hold you back. And despite how easy it is to blame every weird career problem on AI right now, I do not think AI created this one.

So what is actually going on?

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

The Ladder Changes Shape After Senior

The first complication is that software engineering titles are wildly inconsistent.

Junior, mid-level, and senior are common concepts, even if a company calls them Software Engineer I, Software Engineer II, SDE, SWE, or something else. Beyond senior? Things get messy fast.

One company might have staff, principal, senior principal, distinguished, fellow, or partner roles. Another company might skip staff entirely. A smaller company might have nothing beyond senior on the individual contributor track.

That was my experience before Microsoft. For most of my eight years there, the technical path was basically developer and senior developer. There was an architect role that never felt fully defined. Even as a technical manager, I eventually reached a point where there was no clearly established next role on that track.

Was I suddenly incapable of growing? Of course not. The organization simply had not created an endless sequence of titles.

That distinction matters. We often treat a career ladder like a universal map, but it is really a model of what one organization needs.

Title Inflation Makes The Wall Feel Worse

I want to be careful here because I do not have data to prove this. Treat it as an observation from roughly fifteen years in the industry, not a measured fact.

I suspect the expected time between early-career promotions has compressed. Companies use titles as recruiting tools. Employees move between organizations more often. Managers feel pressure to show progression. People understandably compare their timelines with everyone announcing promotions online.

The result is an expectation that every step should arrive on roughly the same schedule -- or at least that there should be very concrete steps in a prescribed amount of time to get there.

But careers are not linear. Going from level one to level two in a year does not mean every future level should take one more year. Follow that math far enough and everyone becomes a CTO before the end of the decade. Clearly, that is not how organizations work.

The higher you go, the larger the expected scope usually becomes. There are fewer roles with that scope, fewer opportunities to demonstrate it, and fewer people the organization actually needs operating there.

That curve was always going to get steeper. Title inflation just makes the change feel more abrupt.

Senior Can Be The Destination

The phrase people often use is terminal level. I don’t love it. It sounds dark, like your career has arrived at a dead end.

That’s not what it means.

A terminal level is a stable point where someone can perform successfully for the rest of their career. For many software engineering organizations, that point is somewhere in the senior band.

Think about what that says about you. You are trusted to solve difficult problems. You can deliver high-quality work consistently. Teams depend on you. You can guide other engineers, handle ambiguity, and operate without someone spelling out every step.

That is a successful career.

It can also be a demanding one. I have written about how senior engineers often spend less time coding because their impact increasingly includes design, mentoring, coordination, and helping others move faster. Staying at senior does not mean staying static.

Your skills can deepen. Your influence can grow. Your compensation can improve. You can take on new domains and become the person everyone relies on without collecting another title every eighteen months.

Compensation And Promotion Are Related, Not Identical

This is usually where someone asks: “Okay, but what happens to my compensation if I am not getting promoted?”

Fair question.

The exact answer depends on the company, but promotion should not be the only mechanism for recognizing strong performance. Salary growth, bonuses, stock, expanded ownership, and other rewards can continue while you remain in the same level.

A promotion usually comes with a larger adjustment because the expectations changed. But that does not mean every strong review must end with a new title.

You can be performing extremely well at senior, receive above-target rewards, and still not be operating at the next level. Those signals overlap, but they are not identical.

That can actually be a healthy balance. Maybe you are kicking ass at senior, being paid fairly, doing meaningful work, and preserving room for your family or everything else outside work. There is nothing lesser about that choice.

Organizations Cannot Be Made Entirely Of Principal Engineers

Now we get to the structural part.

Imagine an organization where every engineer is principal, staff, distinguished, or whatever the top levels are called. It sounds amazing if you picture a video game team where everyone has max stats. If you could build an NBA 2K team of max-stat players, or your RPG party was all max level, that’s what you’d want -- right?

In practice, what work are all of those people doing?

The next level after senior usually expects broader impact across teams, products, or an organization. If you are actively targeting that path, I have a separate breakdown of what principal-level scope actually looks like. The important point here is that cross-organization work is not infinite -- at least not infinitely done in parallel with all the other cross-organization work.

A company needs people setting technical direction across teams. It also needs many more people turning that direction into reliable products, systems, and customer outcomes.

You do not need hundreds of engineers independently trying to lead company-wide initiatives. At some point, everyone collides with everyone else.

This is not an argument for gatekeeping. It is an explanation of why the number of roles naturally narrows. The organization needs a different distribution of scope at each level.

Healthy Teams Need A Spread Of Experience

The same idea applies within a team.

You do not want a team made entirely of brand-new engineers because the coaching and operational overhead would overwhelm the few experienced people supporting them. But stacking a team entirely with the highest-level engineers does not make sense either.

A healthy team usually has a spread:

• Junior engineers building fundamentals and taking on well-scoped work

• Mid-level engineers carrying a large share of independent delivery

• Senior engineers handling complex work, mentoring, and creating leverage

• A smaller number of staff or principal engineers working across broader boundaries

That spread creates continuity. Junior engineers learn from people with more experience. Senior engineers develop coaching and delegation skills. The organization builds its next generation instead of hoping experienced hires appear forever.

This is where AI enters the conversation, but not as the cause of the senior-level wall. Companies deciding they no longer need junior engineers because AI can replace them are creating a different problem. I have shared my concerns about junior developers relying on AI without building fundamentals, and cutting off the junior pipeline removes mentoring opportunities and future senior talent too.

The whole system needs continuity. You cannot keep only the top of the pyramid and expect it to replenish itself.

What To Do When You Feel Stuck

Understanding the structure does not make vague promotion feedback any less frustrating.

If your manager keeps telling you, “Maybe next time,” while you spend another review cycle trying to prove yourself, you need more than encouragement. You need clarity.

Actionable Tip: ask questions that separate your performance from the organization’s available opportunities:

1. What specific evidence is missing? Ask for observable examples, not “more impact.”

2. Am I consistently operating at the next level? A strong year at your current level is not automatically the same thing.

3. Does this team have work with the required scope? You cannot demonstrate cross-team leadership if every meaningful decision is already owned elsewhere.

4. Is a role realistically available? Sometimes the organizational shape creates more back pressure than anyone wants to say directly.

5. What would make the next review materially different? If nobody can answer, that is useful information.

You may discover that you have real gaps to close. Great. Now you can work on something concrete.

You may discover that you are ready, but the organization has no room. That does not automatically mean you should leave, but it gives you an honest tradeoff to consider. An internal move or another company may offer the scope that your current team cannot.

And please protect your energy. There is a difference between stretching into bigger responsibility and running yourself into the ground chasing a label. My advice on pursuing promotions without burning yourself out still applies here.

Your Title Is Not Your Entire Career

I understand why titles matter. They affect compensation, opportunity, how recruiters find you, and how many of us measure whether we are moving forward.

But the ladder cannot be the only scoreboard.

Senior software engineer is not a waiting room where you sit until your real career begins. It is a high-skill, high-trust role that many people work very hard to reach. If you stay there and continue doing excellent work, that is not failure.

If you want principal, staff, management, or another path, go after it with clear eyes. Learn what the role actually requires. Find out whether your organization has the right opportunities. Build the evidence. Decide whether the tradeoffs fit the life you want.

Don’t let the absence of another title erase everything you have already accomplished.

Careers are not straight lines. Organizations are not infinite ladders. And success is much bigger than the word printed beside your name.

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:

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