TL; DR:

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

• People will model whatever hours you actually keep

• Overcommunicate the expectation -- silence sets it for you

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

What Your Working Hours Signal To Your Team

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

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

What I Actually Care About As A Manager

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

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

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

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

Where The Perception Actually Comes From

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

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

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

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

My Own Trap (And What I Got Told)

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

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

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

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

The Manager Who Got It Right

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

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

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

A Funny Coincidence

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

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

Wrapping It Up

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

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

Subscribe now

Share

Leave a comment

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

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

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

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

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

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

TL; DR:

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

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

• Balancing delivery with people management is the real challenge

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

Can You Actually Quantify How Good a Manager Is?

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

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

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

First, Set the Expectations

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

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

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

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

The Three Dimensions of Manager Effectiveness

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

1. Technical Ability

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

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

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

2. Project Management

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

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

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

3. People Management

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

Here’s what falls under this:

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

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

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

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

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

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

So How Do You Actually Measure This?

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

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

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

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

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

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

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

It’s Going to Look Different for Everyone

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

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

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

Share

Leave a comment

Subscribe now

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

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

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

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

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

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

TL; DR:

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

• Tool usage gaps and product integration gaps are different problems

• Your engineering fundamentals are more transferable than you think

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

The AI Career Conversation Is Changing

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

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

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

“I’m Going to Be Replaced by AI”

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

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

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

The “Being Left Behind” Fear

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

Not Using AI Tools Effectively

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

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

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

Not Building AI-Integrated Products

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

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

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

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

Subscribe now

The Cutting-Edge FOMO

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

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

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

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

How I’m Navigating This as an Engineering Manager

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

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

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

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

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

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

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

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

Subscribe now

Your Skills Are More Transferable Than You Think

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

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

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

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

Share

Leave a comment

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

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

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

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

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

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

TL; DR:

• Context switching is costly but never fully avoidable

• Give your manager context before they re-prioritize

• Limit work in progress to stay focused

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

Context Switching -- The Tax Nobody Budgets For

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

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

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

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

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

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

Startup vs Big Company -- Context Matters A LOT

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

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

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

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

What You Can Actually Do About It

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

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

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

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

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

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

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

The Same Principle Works at Big Companies Too

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

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

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

How I Manage WIP on My Teams

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

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

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

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

Document It If Your Manager Isn’t Getting It

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

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

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

Sheltering Your Team -- The Manager’s Role

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

Here’s how I think about it in practice:

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

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

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

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

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

The Bottom Line

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

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

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

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

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

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

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

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

TL; DR:

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

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

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

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

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

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

It sounds simple. It’s not.

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

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

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

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

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

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

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

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

The Minimum Baseline: Design Reviews and Code Review Exposure

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

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

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

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

Pull in the Experts Early -- and Work With Them

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

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

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

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

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

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

Side Projects Are Still on the Table

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

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

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

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

The Part Nobody Wants to Talk About: Trust

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

Not difficult. Impossible.

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

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

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

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

What This Actually Looks Like in Practice

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

For me personally, that means:

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

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

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

• Being intentional about exploring areas where I feel gaps forming

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

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

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

Subscribe now

Share

Leave a comment

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

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

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

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

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

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

TL; DR:

• Copilot CLI finally pulled me from Visual Studio

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

• Roslyn analyzers are surprisingly effective AI guardrails

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

Have I Finally Moved Away From Visual Studio?

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

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

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

Why Copilot CLI Clicked For Me

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

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

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

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

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

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

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

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

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

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

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

Build a Habit of Turning Wins Into Reusable Skills

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

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

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

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

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

Roslyn Analyzers Are Surprisingly Good AI Guardrails

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

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

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

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

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

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

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

Managing Multiple Parallel Sessions Without Losing Your Mind

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

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

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

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

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

Share

Leave a comment

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

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

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

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

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

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

TL; DR:

• Burnout builds slowly -- it sneaks up on you

• Trust with your manager enables harder conversations

• Know what you want before raising burnout

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

Should You Talk To Your Manager About Burnout?

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

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

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

Burnout Doesn’t Happen Overnight

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

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

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

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

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

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

Your Relationship With Your Manager Matters More Than You Think

Before we talk mechanics, I want to zoom out.

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

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

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

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

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

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

You probably do have a list. A list of:

• Things that frustrate you

• Things that feel broken

• Things that drain your energy

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

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

• Fix all of it?

• Escalate everything?

• Nod sympathetically?

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

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

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

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

Know What You Actually Want From the Conversation

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

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

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

• “I want help solving one specific thing.”

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

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

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

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

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

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

What Happens If Nothing Changes

I want to be honest with you here.

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

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

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

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

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

Leave a comment

Share

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

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

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

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

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

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

TL; DR:

• Foundations beat language-specific trivia every time

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

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

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

  Subscribe now

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

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

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

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

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

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

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

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

The Real Reason: Foundational Knowledge Transfers Everywhere

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

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

• how garbage collection works as a concept

• what it means for a language to be managed

• what design patterns exist and why

• how different types of systems handle memory and concurrency

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

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

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

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

Where AI Changes the Equation

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

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

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

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

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

But Foundations Are Why I Didn’t Get Stuck

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

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

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

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

There Are Still Cases Where Deep Knowledge Matters

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

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

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

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

The Bigger Picture: AI is Opening Doors

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

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

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

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

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

Yes. Absolutely.

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

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

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

Share

Leave a comment

Subscribe now

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

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

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

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

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

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

TL; DR:

• Mission alignment shapes how engaged you are daily

• Understanding why your work matters is underrated

• Reflect on what engages you, then align your search

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

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

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

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

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

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

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

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

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

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

The “Fulfillment Across a Career” Framing

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

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

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

What Alignment Actually Looks Like

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

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

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

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

The Manager Angle: Always Explain the Why

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

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

The gap is why.

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

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

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

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

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

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

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

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

Wrapping Up

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

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

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

Share

Leave a comment

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

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

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

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

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

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

TL; DR:

• Communication responsibility lands on you, not your audience

• Think from their perspective -- not yours

• Metaphors bridge the technical and non-technical gap

• No livestream this week, sorry!

The Real Gap Between Good Developers and Great Ones

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

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

The Responsibility Is On You

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

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

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

Know Your Goal -- And Theirs

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

The goal frames everything.

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

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

Levels of Indirection Kill Technical Detail

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

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

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

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

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

Metaphors Are Your Secret Weapon

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

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

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

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

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

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

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

Start With the Framework, Not the Steps

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

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

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

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

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

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

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

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

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

TL; DR:

• Start with the problem, not the solution

• Define success in the role before writing questions

• Hiring is imperfect -- iterate and build the skill

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

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

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

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

The Two Scenarios

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

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

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

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

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

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

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

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

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

Defining What the Role Actually Looks Like

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

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

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

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

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

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

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

Subscribe now

When You Don’t Have the Expertise Yourself

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

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

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

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

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

In the Android example, if success means:

• Going from zero to a published app

• Actively sharing knowledge with the rest of the team

• Owning Android security for the platform

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

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

Subscribe now

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

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

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

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

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

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

Share

Leave a comment

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

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

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

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

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

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

TL; DR:

• Context shapes everything

• Stop optimizing for the perfect plan

• Know your stakeholders deeply

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

Why Everyone Seems to Have a Different Opinion on Planning

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

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

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

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

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

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

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

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

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

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

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

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

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

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

How Planning Changes at Scale

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

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

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

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

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

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

Stop Trying to Make the Plan Perfect

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

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

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

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

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

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

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

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

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

Your Environment Is the Variable

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

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

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

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

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

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

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

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

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

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

TL; DR:

• Legacy systems are some of the most real software engineering

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

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

• No livestream this week, sorry!

Stuck Maintaining Legacy Code -- Now What?

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

Spoiler: the developer says they ARE using AI tools.

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

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

Legacy Systems Are REAL Software Engineering

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

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

• There’s little to no test coverage

• Everything is tightly coupled

• You touch one thing and five other things break

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

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

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

So what do you do?

Start Building Confidence Through Tests

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

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

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

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

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

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

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

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

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

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

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

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

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

I have a challenge with statements like this.

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

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

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

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

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

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

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

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

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

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

Bridging The Communication Gap

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

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

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

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

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

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

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

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

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

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

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

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

Talk About Systems, Not Classes

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

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

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

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

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

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

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

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

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

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

Wrapping Up

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

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

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

• Refactoring Legacy Code - What You Need To Be Effective

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

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

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

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

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

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

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

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

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

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

TL; DR:

• Software rewrites are almost ALWAYS underestimated

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

• The Strangler Fig pattern lets you rewrite incrementally and safely

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

Why Do Software Rewrites ALWAYS Take Longer Than Expected?

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

Spoiler alert: that’s also been my experience.

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

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

Why Teams Push for Rewrites

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

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

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

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

The Two Clean Slates Problem

But here’s where things start to fall apart.

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

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

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

1. A clean slate from a code and architecture perspective

2. A clean slate from a feature parity perspective

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

Subscribe now

The Resource Split

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

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

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

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

The Scary Trap

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

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

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

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

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

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

Subscribe now

The Strangler Fig: A Better Way

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

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

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

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

How It Works in Practice

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

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

But How Do You Actually Break It Up?

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

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

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

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

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

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

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

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

Why I Like This

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

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

Subscribe now

Real Examples from My Career

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

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

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

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

The Takeaway

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

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

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

Incrementally is the way I recommend, if you can.

Share

Leave a comment

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

• Resume reviews and interview guidance!

• Software engineering podcast and livestreams!

• My Code Commute vlogs are on YouTube!

• All of my weekly vlogs are on YouTube!

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

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

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

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

TL; DR:

• Side projects help demonstrate learning

• Soft skills are CRITICAL

• Check out the live stream on Monday, February 2nd at 7:00 PM Pacific!

Beyond the Code

How often do you find yourself focusing purely on the technical details when you’re preparing for a software engineering interview? If you’re like most of us, you’re probably grinding LeetCode problems, sketching out system design diagrams, and making sure you can explain exactly how your favorite framework works under the hood.

I get it. I’ve been there. I’ve done that.

But as an engineering manager who has been hiring for over a decade, I’ve seen a recurring pattern: developers who can “nail” the technical rounds but still fail to land the offer. Usually, this happens because they miss the opportunity to showcase two critical areas: how they learn and grow, and the soft skills that make them a multiplier for a team.

Your Side Projects are a Narrative, Not Just a Repo

One of the biggest mistakes I see some developers make is assuming that the existence of a side project on a resume is the end of the story. If you got the interview, your project selection was decent enough to get you noticed, but the interview is where you actually have to sell the value of that experience.

To be clear: no, side projects are NOT a requisite for being qualified for a job. However, they can be an AWESOME way to showcase additional learning and experience that might not show up in your professional experience.

You can check out some of my thoughts on side projects in interviews in this video:

Focus on the “Stuck” and the “Unstuck”

When an interviewer asks about a project, don’t tell them it went perfectly smooth. If everything was easy, it’s honestly not that interesting to me as a hiring manager. I want to hear about where you got stuck and how you got unstuck.

This is your chance to demonstrate problem-solving focus and resourcefulness -- the core traits of an engineer. Explaining that you had to weigh multiple solutions before hitting your IDE or blasting prompts into ChatGPT shows me that you can think analytically and not just follow tutorials or vibe-code blindly.

The Value of “Reinventing the Wheel”

You’ve likely heard the advice “don’t reinvent the wheel,” but for side projects, reinventing the wheel is one of the best ways to understand complexity. If you built your own HTTP library or a custom game engine, talk about the appreciation you gained for the work that goes into big libraries. It shows you aren’t just a “copy-paste” developer; you’re someone who wants to know how the gears turn under the hood.

This isn’t necessarily the recommendation for building all software -- but it IS a cool opportunity to showcase that you wanted to dive into something and understand it. Curiosity is an awesome trait for an engineer.

Subscribe now

Ask for the Interviewer’s Focus

Interviews can be vague, and system design or project walkthroughs are often left underdefined on purpose to see how you handle ambiguity. Before you dive into a 20-minute monologue about your database schema, stop and ask: “I have a lot to say about this project; is there anything in particular you’d like me to focus on?”.

Depending on the company, they might care about:

• Design decisions: Why did you pick this specific tech stack over another?

• Market research: If it was a product, how did you think about user needs?

• Collaboration: Even on a side project, did you contribute to open source or work with a buddy? Highlighting teamwork is a massive value add because it’s a skill many juniors lack.

Leveraging Skills from Other Industries

If you are transferring from a different career path, you have an enormous leg up that many people overlook. You shouldn’t just be trying to compete on technical skills; you should be leaning into your lived work experience.

If you’ve dealt with customers, managed projects, or navigated difficult team dynamics in a past life, those are high-value indicators for a hiring manager. Especially for junior devs or folks trying to break into a dev role, while others are trying to prove they can write a function, you can prove you can deliver value to a business.

Subscribe now

Why Soft Skills Trump Technical Depth

This might be a hot take, but in many cases, I value soft skills over technical depth.

If you have a candidate who is a technical “god” but is abrasive or impossible to work with, they can tank a team’s productivity from 100% down to nearly zero. As a manager, my goal is to create a multiplier effect where everyone makes those around them better. Multiplying anything by less than 1x means they’re taking away from overall team effectiveness. More on that in this Code Commute video:

The Friction of Coaching

Here’s the reality from the manager’s desk: It is much easier to coach a technical gap than a soft skill gap. If you don’t know a specific library, I can give you the time and resources to learn it. But if you lack self-awareness, struggle with active listening, or constantly blame others, that is significantly harder to fix.

In my career, I have observed that it’s absolutely possible to coach on people skills... But it’s significantly more time and effort. And that’s on BOTH sides -- the EM and the employee. Not to mention, while that coaching is happening, there could be a greater impact felt across the team.

Red Flags and Radical Accountability

During the interview, I am actively looking for red flags in how you talk about your past experiences.

• Blaming others: If every failure in your past was someone else’s fault (a “dumb” teammate or a “bad” manager), that’s a signal you don’t take radical accountability.

• Close-mindedness: If you insist there is only “one right way” to code and refuse to consider alternative perspectives, you’ll be a bottleneck for a collaborative team.

Subscribe now

Practice “Showing Your Work”

When you ask for help or explain a problem, be ready to show what you’ve tried so far. This isn’t just for on-the-job communication; it’s vital for interviews. If you get stuck on a coding problem, don’t just stare at the board. Explain your investigation. Proving you’ve put in the effort before seeking a shortcut tells the interviewer you are diligent and self-driven.

It’s Not Always You: The Factor of Luck

I want to end this by reminding you that interviews are a skill, and like any skill, they require practice. But even if you do everything right -- if you represent your projects perfectly and showcase great interpersonal skills -- you might still get a rejection.

Sometimes it just comes down to bad luck. Someone else might have shown up that day with a slightly better-aligned set of niche experiences, or the hiring committee was split.

Don’t take it personally. You can only control what is in your power: your preparation, your curiosity, and your willingness to keep building. Focus on becoming the person who fits the role, rather than just looking for the shortcut to land the job.

Keep building, keep asking questions, and keep refining those “people” skills. They’ll take you further than any single line of code ever could.

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:

• I like it even as an IDE user!

• Powerful and integrates with Github ecosystem

• Check out the live stream on Monday, January 26th at 7:00 PM Pacific!

GitHub Copilot CLI’s New Power Moves

If you spend time in the terminal, you know the sweet feeling of getting into flow and staying in flow. The latest GitHub Copilot CLI updates are built to let us do exactly that. Copilot CLI is essentially your AI pair programmer, right there in bash or Powershell. It “brings AI-powered coding assistance directly to your command line”, meaning it can not only write code but execute shell commands (with your permission) as part of its work. Think of it like chatting with a teammate named “Copilot” who never gets tired, works in the dark, and doesn’t mind repeating themselves.

Ever since Copilot CLI launched in public preview, the team has been on a tear adding features to make it more useful and predictable. The January 2026 changelog sums it up nicely: Copilot CLI “continues to push the boundaries of agentic AI assistance in your terminal”. We’ve now got powerful new reasoning models, built-in planning tools, better context management, and even first-class GitHub CLI integration. These features can seriously upgrade your dev workflow. Let’s walk through what’s new, why it matters, and how you can make Copilot CLI work for you.

If you’re curious beyond the article, I have been starting to create videos around my usage with Copilot CLI, starting off with some basics on model selection:

Plan Mode: Map It Out Before You Code

One of the biggest headliners is Plan mode. The idea of “team-first development” applies here -- this is Copilot’s way of joining the planning meeting before the coding starts. Instead of rushing into code, you can use the /plan command (or press Shift+Tab to toggle between plan and normal mode) and Copilot switches into a conversational planning flow. It asks clarifying questions about scope and requirements, and then sketches out a structured implementation plan before writing a single line of code.

In practice, it’s like talking through the feature with a peer. Try it on a side project: say “build a simple todo API” and use /plan. Copilot will ask if you want REST endpoints or GraphQL, what kind of database, and how to handle edge cases. Give it a few details, and it generates a step-by-step plan you can review. Having this plan up front changes your perspective. It catches misunderstandings (you might realize you hadn’t specified a user auth requirement!), and gives you confidence in the approach before any code is written.

This kind of approach isn’t unique to the Copilot CLI, of course. Many of you have seen this with Claude Code, and I’ve even talked about planning discussions in GitHub spaces:

A quick tip: use /clear to reset the session if context gets messy, and /cwd to make sure Copilot is working in the right directory. Once plan mode is done, review the outline, then tell Copilot to run (by toggling out of plan mode with Shift+Tab) and watch it implement step by step. It’s a new way to work iteratively -- think, “plan, code, adjust, plan again,” rather than code blind. This fits a typical engineering workflow: first architect, then implement. Copilot CLI even remembers past plans to some extent (more on memory below), so your “plans for features” can become part of your project’s evolving documentation.

Slash Commands: Keyboard Shortcuts for AI

Working in the terminal is all about efficiency, and Copilot CLI’s slash commands are magic for that. These are literally commands that start with /, like /clear, /model, or /add-dir, and they trigger Copilot to perform a specific task. Instead of guessing the right natural language prompt, you just issue a command. As the docs say, slash commands give us “quick, explicit, and repeatable commands directly in your workflow”. A few of them quickly become muscle memory.

For example, start a fresh CLI session with /clear to wipe any old context. When switching projects, hit /cwd <path> to tell Copilot “now focus on this folder,” and it replies “Changed working directory to: …”. For a specific model or detail level, use /model gpt-5.2-codex to pick the latest code-specialized model (GPT-5.2-Codex is now available) or use --model. The command /help or just / will list everything available. These shortcuts make Copilot’s actions predictable and fast, which is huge. No more copy-pasting long prompts; there’s a command for common tasks like fixing linter errors, running tests, or even viewing session usage.

Copilot’s blog has a great slash-command cheat sheet. They highlight that /clear, /cwd, and /model cover your bases: clear the slate, set the directory, pick the intelligence level. Also worth knowing: /add-dir and /list-dirs to control file access (important in a team or security context), and /review for quick code reviews (more on that in a bit!). The nice part is that slash commands fit into any workflow: you type them while in a Copilot CLI chat, or even in a GitHub Copilot chat session elsewhere. They are explicit shortcuts, so every team knows exactly what’s happening (no magic voodoo prompt interpretation).

Pro tip -- slash shortcuts to remember: use /clear when Copilot is repeating old context, /cwd to switch projects, and /model if you want the highest quality output (or experiment with GPT-5.2’s “extra reasoning” level). And don’t forget /delegate to hand off complex tasks to Copilot’s cloud-based coding agent.

Steering and Iterating: Stay in Control

One big theme here is iterative, steerable workflows. Copilot CLI was already conversational, but now you can even chat with it during its thinking. Say Copilot is in the middle of generating code; you can type follow-up instructions on the fly, which enqueues them for after its current response. This is so handy. The conversation feels natural -- you don’t have to wait, type a new prompt, and wait again. You can correct course midstream. For example, say Copilot is writing a feature and you realize you need to tweak something: instead of restarting, just type an instruction like “Actually, use a priority queue here,” and it queues it up seamlessly.

To be honest, I am VERY much a die-hard Visual Studio user because I really prefer working in an IDE compared to a command line. But this ability to naturally interrupt and redirect the agent in chat makes the CLI experience really smooth. I’m hopeful we’ll see more of this migrate to Visual Studio as well.

If Copilot asks permission to run a tool (like npm install or git), you can now give quick inline feedback. If you reject an action, Copilot will ask why or adapt, rather than just stopping dead. It’s like telling your pair-programmer, “Hey, that’s a sensitive directory, try another way,” and the AI remembers for the rest of the session. The goal is keeping you in charge.

Another powerful feature is cloud delegation with /delegate. This command pushes your current session to Copilot coding agent on GitHub. When you run /delegate complete the API integration tests, Copilot will commit any unstaged changes as a checkpoint, create a new branch, and open a draft pull request. The coding agent then works in the background on GitHub’s infrastructure, and you’ll get a link to the PR and agent session. You can continue working locally while Copilot handles the delegated task in the cloud. I’m personally not at the point where this context switch is natural, but I do love delegating work to cloud agents in general so that I can focus on whatever else I am building.

All these features aim to make the workflow feel like coding with a live teammate, where you can pause, redirect, and multitask. No more waiting idly for long outputs or losing your train of thought while Copilot scribbles away.

Keeping Context Sharp: /compact and /context

Working iteratively means building up a conversation. But we all hit token limits eventually. Copilot CLI now handles that gracefully. It will auto-compress (auto-summarize) your chat history in the background when you hit about 95% of the token limit. You might not even notice it happening, except that your session can keep going “virtually infinite.” If you want control, use the /compact command anytime to manually force a trim. Press Esc to cancel if you change your mind.

And if you’re ever curious how much brain space Copilot is using, /context will give a token breakdown. This is especially useful when juggling multiple tasks in one session. Keeping context tight means the AI stays focused, which is crucial for accurate responses. In fact, Claude Code (Anthropic’s tool) also does auto-compaction when it gets full, so these agents are thinking about the same problems of context drift. The lesson for us is to periodically clear or compact context, especially when switching tasks -- otherwise AI suggestions can start referencing outdated stuff.

Enhanced Permissions: Trust But Verify

Teams working in sensitive codebases will appreciate the finer permissions controls. Now, when Copilot asks for tool approval, you can select “Yes, and approve TOOL for the rest of the running session” to automatically approve similar requests. For instance, if you let it run one npm install, it won’t bug you again for every package in that session. And if you do trust Copilot completely, there are flags like --allow-all (which enables auto-approval of all tools and paths) or the /yolo command to enable YOLO mode -- letting Copilot run freely without prompts. Use these carefully, but they can save clicks when you’re in a trusted environment (or just tinkering locally).

For me? Once I saw Copilot trying to push changes to my remote repository, I made a promise to myself that I wouldn’t touch YOLO mode. I feel quite confident with the file changes and such locally, but once it starts to try and push code on its own I get very concerned!

All of this makes Copilot’s actions more transparent and team-friendly. You’re building an audit trail. Slash commands like /add-dir, /list-dirs, and /usage ensure everything Copilot does is explicit. In a real-world team, that means there are no surprises about where your AI “coworker” is poking around.

Instant Code Reviews: The /review Command

A huge time-saver: the new /review command. Instead of jumping into GitHub.com or a separate tool, you can ask Copilot right in the terminal to review your latest changes. Just stage your code, run /review, and Copilot analyzes the diff. It will point out things like potential bugs, security issues, or anything odd it sees. It’s a “quick sanity check” without leaving your editor.

In practice, run this before you commit or open a PR. It’s like having a second set of eyes on your code. For example, /review might flag a missed null-check or a missing await in an async function -- issues you can fix before even pushing. This kind of on-the-fly review keeps quality high and saves rounds of back-and-forth later. If you’re on a team with coding standards, you can even feed Copilot a style doc via custom instructions (see next) so the feedback aligns with your conventions.

Custom Instructions: Teaching Copilot Your Project’s Rules

One of the most exciting under-the-hood updates is custom instructions support. Copilot CLI can read instruction files from your repository that persist across sessions. Think of it as teaching the AI your project’s personality. You define coding standards, architecture patterns, even how your team likes naming things, and Copilot references these instructions automatically.

Why does this matter? Because it means you don’t have to re-explain your project setup every session. Copilot will already know, “Oh right, we always put logging in this helper class,” or “We favor snake_case in our database fields.”

Copilot CLI supports these instruction file locations:

• Repository-wide instructions: .github/copilot-instructions.md

• Path-specific instructions: .github/instructions/**/*.instructions.md

• Agent files: AGENTS.md (in git root and cwd)

• User-level instructions: $HOME/.copilot/copilot-instructions.md

Note: If you’ve used Claude Code (Anthropic’s CLI tool), you may be familiar with CLAUDE.md files. Copilot CLI can also read CLAUDE.md and GEMINI.md files for compatibility, but its native instruction format is .github/copilot-instructions.md. If you’re setting up instructions specifically for Copilot, use the .github/ path.

You can think of it like having a persistent conversation with the AI about your codebase. An easy way to use this is by creating a .github/copilot-instructions.md file in your repo that outlines the big rules of your project. Copilot will pick that up and adjust its answers. For example, if you save your API conventions in the instructions file specifying that you use Express, Copilot will stop suggesting incompatible frameworks like Sinatra.

Bottom line: invest a little effort in “teaching” Copilot once, and it pays dividends forever. Beyond that? I’ve made videos talking about how I use Roslyn analyzers to further steer Copilot:

GitHub CLI Integration: “gh copilot”

Another nice productivity bump: you can now install and run Copilot CLI through the GitHub CLI. Just run gh copilot in your terminal. The first time it will prompt you to install Copilot CLI, and after that gh copilot launches it. This is clutch for people who already use gh for their workflow. You can add it to a quickstart script so new teammates get Copilot CLI set up automatically.

Bonus: GitHub Actions will auto-install Copilot CLI too. So if you want to embed Copilot CLI tasks in a CI/CD pipeline, it’ll just come up without manual steps. In short, gh copilot turns Copilot CLI into a first-class citizen of the GitHub tool ecosystem. Don’t overlook this: using gh copilot means you don’t have to juggle Homebrew or npm installs on every machine.

Looking Around: Claude Code and Other AI CLI Tools

You might wonder how this stacks up with other AI coding CLI tools like Anthropic’s Claude Code. In concept, they share some ideas: Claude Code also has a plan-mode (activated by Shift+Tab) and slash commands, so you can create a file of tasks and iterate through them. One blogger demonstrated a workflow with custom slash commands to manage a checklist-style development flow. For a deeper dive into Claude Code’s features, check out this guide to slash commands, agents, and skills.

But Copilot CLI ties tightly into GitHub. For example, Copilot’s /delegate can push tasks to GitHub’s cloud-based coding agent, and /review plugs directly into your Git diffs. Claude Code, on the other hand, uses CLAUDE.md context files and its own agents. Both have context compaction and memory features. For a side-by-side comparison of these tools, check out jgandrews’ writeup. The key takeaway is that whether you use Copilot CLI or Claude Code, the pattern is similar: break your work into steps, keep the context clear, and iterate. If your team uses GitHub everywhere, Copilot CLI is a natural choice -- but it’s worth knowing other tools exist.

(And for the record: yes, in Claude Code you can even route it to call GitHub Copilot CLI via shell if you really want to mix and match, which is a fun experiment but gets advanced quickly.)

Actionable Tips for Your Workflow

Let’s translate all this into things you can do right now:

• Install Copilot CLI: If you have GitHub CLI (gh) installed, just run gh copilot. It will handle the install or prompt you. Otherwise follow the docs. Make sure you’re on Copilot Pro/Enterprise if it asks for licensing.

• Explore /help: Open a Copilot CLI session, type / or /help, and get familiar with commands. Try /clear, /cwd, /list-dirs, /review. The cheat sheet on the GitHub blog is a great reference.

• Try Plan Mode: Pick a small feature you want to build (even “Write a function to...”). Use /plan or press Shift+Tab in the CLI to enter plan mode. See what questions Copilot asks. Answer them. When you’re done, review the plan and toggle back to normal mode. Watch how Copilot turns plan into code.

• Use Cloud Delegation: For a longer task (like scaffolding a module or complex refactor), try /delegate your task description here. Copilot will create a branch and PR, then work in the background on GitHub while you continue locally.

• Commit Reviews: Before your next commit, stage your changes and run /review. Take Copilot’s feedback seriously. It might catch security issues, missing docs, or suggest improvements.

• Set Custom Instructions: Create a .github/copilot-instructions.md file describing your project’s tech stack, conventions, and goals. Copilot CLI will use that as context. This is like having a consistent onboarding for the AI.

• Monitor Usage: If you’re on a plan with usage limits (e.g. Copilot Pro has a token budget), use /usage and /session to see what you’ve spent during your session. It helps avoid surprises on your bill.

• Join the Community: The Copilot CLI repo on GitHub is public. If something doesn’t work, check the issues there. Since it’s still in public preview, the team is actively listening. Also, share your tips with your teammates -- these features are still new to many of us.

Keep Coding, Together

Copilot CLI’s updates are not just shiny new toys; they’re designed to fit how we actually build software. Planning, clear commands, context-awareness, and the ability to course-correct mirror a good team workflow. Using these features feels like having a dedicated helper who’s learning your codebase and following directions -- fast and tireless, but definitely still on your team.

Experiment with these tools, but stay in the loop. AI isn’t here to replace the dev on the team, it’s here to eliminate grunt work. Keep reviewing what Copilot does (after all, you know the project best), and feed your insights back to it (literally through instruction files). If it makes you more productive and your code more polished, it’s earned its place in the toolkit.

Ready to dive in? Open up your terminal, update Copilot CLI, and start chatting. Ask it to draft a plan, run tests, fix bugs, or explain code -- all without leaving your shell. At the end of the day, these new Copilot CLI features mean one thing: more time writing good code and less time context-switching between windows.

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:

• It’s NOT required

• ... You probably will find value in doing it

• Check out the live stream on Monday, January 19th at 7:00 PM Pacific!

Building Software Outside of Work Hours

This topic gets people weirdly emotional.

On one side, you have the crowd that treats side projects like a moral requirement. If you aren’t coding after work, you are falling behind, you don’t want it enough, and you are basically doomed. On the other side, you have people who act like building anything outside of work is automatically unhealthy, or that anyone who does it must be compensating for something.

Both extremes are missing the point.

You don’t need to build software outside of working hours to be a legitimate software engineer. Your life does not have to revolve around your job. You can love software and still want to spend your evenings with your family, at the gym, playing games, reading, or doing literally anything that has nothing to do with code. That is normal. That is healthy. And it does not make you less serious as a developer.

But if you are someone who wants to build outside of work, then we can talk about how to make it effective. Not performative. Not guilt-driven. Effective.

Because here is the reality: building outside of work can be a career accelerator, a learning tool, a confidence booster, and sometimes even a path to income. It can also be a fast track to burnout if you approach it like a second job with no boundaries. So the question is not, “Should everyone do side projects?” The question is, “What are you trying to get out of it, and does your approach actually match that goal?”

That is where people get stuck, and you can watch my Code Commute video on the topic too:

Start with the why, not the what

Most people start with, “What should I build?” and that’s the wrong first question, in my honest opinion. If you don’t know why you are building, you will pick a project that does not fit your life, does not fit your energy, and does not fit your outcomes. Then you will quit and assume you lack discipline, when really you just started with the wrong framing.

In my experience, most “why” buckets fall into four categories.

The first is skilling up in an area you are not getting to touch at work. Maybe you build backend services all day, but you want frontend experience. Maybe you have done mobile for years and want to learn web. Maybe you have been living inside one stack and you want to explore something else because you are thinking about a role change. If your workplace supports internal mobility and your manager can help you find opportunities, that is ideal. Learn on the job, get real constraints, and get paid while you do it. But if those opportunities are not there, building outside of work can fill the gap.

The second bucket is resume and portfolio material. This is especially common for junior devs, but it applies at any level when your resume feels light in a specific area. I want to be careful here though: the goal is not to create shiny projects. I have never hired someone because their side project had tons of users. The value is being able to talk about what you built, why you built it, the tradeoffs you made, what you learned, and what you would do differently. If you can’t explain it, the project does not help you. It sets you up for an awkward interview where you are basically forced to admit you do not understand your own work.

The third bucket is income or entrepreneurship. Sometimes you have a problem in your own life, you solve it, and then you realize other people might pay for it too. Sometimes you want freelance work, consulting, or a product business. This is a completely different game than learning for learning’s sake. If your goal is customers, you should optimize for shipping and reliability, not novelty. And this is where I see people shoot themselves in the foot by trying to learn an entirely new stack while also trying to build something sellable. That combo is brutal. It slows you down, increases frustration, and makes the whole thing feel like a grind.

The fourth? Well, you probably don’t need to read a newsletter article on it if your why fits into this bucket: Because you find it fun. I spent a lot of time in this bucket of building things, especially super early in my programming journey. I just liked building games and things related to games! I realize not everyone will fall into this category, and that’s totally fine. If you find yourself here, the nice thing is that you can get coverage on all three other buckets and it won’t even feel like work.

So whatever your why is, be honest about it. And don’t be afraid to change it. The mistake is pretending your goal is learning when you are actually chasing resume validation, or pretending your goal is income when you are really just curious and experimenting. Different goals demand different approaches.

Activation energy is real, NOT a character flaw

Even with a solid why, building outside of work can feel hard. Not because you are lazy, but because doing “more work” after you already worked all day is hard. That is just reality.

There is a massive difference between wanting to build because you are excited and forcing yourself to build because you feel like you should. When it feels like obligation, the activation energy is huge. You sit down, open the laptop, and suddenly cleaning your kitchen feels like a thrilling adventure.

If you want consistency, your best lever is making the starting friction lower. A simple way to do that is aligning the project with something you already care about. It does not have to be deep passion. Just enough interest that it pulls you in.

Video games are an easy example because a lot of developers already like them. If you have a favorite game, build something adjacent to it. Not a massive community tool. Something small:

• A tracker

• A checklist

• A Pokedex-style database

• A loot log

• A build comparison tool

• A stat calculator

Even something dumb and fun is fine, because the point is not the app. The point is lowering the barrier to starting.

And if you are thinking, “Yeah but I don’t care about games,” cool. Use whatever you do care about:

• Fitness

• Cooking

• Music

• Personal finance

• Sports

Your hobbies are full of tiny problems that can become tiny projects. Tiny projects are what get finished. Finished projects are what create momentum.

Too many ideas? Pick one.

Some people don’t have an activation energy problem. They have an overwhelming problem. They have a list of ideas, and they cannot pick the “best” one, so they pick none.

There is no best idea. There is only the idea you actually start.

If you have ten ideas, write them down and pick one. Literally pick one. Random number generator if you need it. You will learn more by building the “wrong” project than by spending three months optimizing your decision.

• Starting is a skill.

• Scoping is a skill.

• Finishing something small is a skill.

Those skills transfer to every other project you will ever do.

Keep most variables fixed, or risk drowning

One practical guideline that saves people a ton of pain is this: don’t make everything new at once.

If you want to learn Postgres, don’t also simultaneously learn:

• a new language

• a new framework

• a new cloud provider

• and a new deployment approach.

That’s a recipe for stalling. The more unknowns you stack, the more likely you are to hit a wall, and once you hit the wall the motivation drops fast.

Instead, pick one or two things you want to learn and keep the rest familiar.

• If you are a C# developer and you want database experience, keep C# and learn Postgres.

• If you want to learn Python, build a small service with a database you already know.

• If you want to learn cloud deployment, keep your stack familiar and focus on the deployment pipeline.

You are trying to create a learning environment, not a chaos environment.

Match process to goal, or risk wasted effort

This is where people get lost in the sauce. They start building, they get distracted by architecture, they rewrite everything twice, they chase the perfect framework, they reorganize folders for a week, and they feel productive because they were busy. But they aren’t necessarily moving toward their goal.

... Unless your goal was practicing refactoring and system rewrites. In which case, heck yeah!

If your goal is learning, you need to slow down enough to understand what you are doing. AI tools can help, but they can also trick you into thinking you learned something when you just shipped something. If you can’t explain it, you didn’t learn it. If you are using AI, use it to ask “why” questions, explore tradeoffs, and clarify concepts. Don’t use it like a slot machine until code appears that compiles.

If your goal is resume material, focus on projects that create good stories. You want to be able to walk someone through the situation, what you built, why you chose that approach, what you struggled with, and what you learned. That is what makes a project valuable. Not the number of stars, not the number of users, not whether it looks fancy in screenshots.

If your goal is customers or income, you need to bias toward shipping and stability:

• Reduce novelty.

• Use known tools.

• Build the smallest viable version.

• Get it in front of people.

• Iterate.

Don’t turn the project into an excuse to rebuild your entire identity as an engineer.

A reality check before we wrap up

Building outside of work is optional. It’s a tool. It can be a great tool. But it’s not a moral requirement and it’s not the only path to growth. You can grow by:

• Taking on harder work at your job

• By mentoring

• By reading

• By deliberate practice

• By learning through reviews

• By pairing with stronger engineers

• AND by being intentional about the work you accept.

If you do want to build outside of work, do it intentionally. Start with the why. Keep it aligned with your life. Reduce activation energy by aligning with interests. Keep most variables fixed. Match your approach to your goal. And build small enough that you can actually finish and learn.

That is how side projects become something that improves your career and your confidence instead of something that just makes you feel guilty on a Sunday night.

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

• LeetCode, System Design, and Behavioral

• ... AI is likely going to change the landscape here

• Discuss YOUR resolutions on the live stream on Monday, January 12th at 7:00 PM Pacific!

FAANG Interviews Aren’t One Skill Test

If you’re preparing for interviews at FAANG or other big tech companies, one of the biggest mistakes I see people make is assuming that being “good at coding” is enough.

It isn’t. Don’t get me wrong... it’s a BIG part of it, but it’s not the only part of it.

FAANG-style interview loops are intentionally multi-dimensional. You are not being evaluated on a single axis, and success in one round does not compensate for being unprepared in another. These interviews are designed to test different skills, in different ways, across different contexts.

At a high level, you should expect three major categories of interviews:

• Coding rounds: These are (generally) your LeetCode-style questions

• System design rounds: These are (generally) “build me a clone of system X”

• Behavioral rounds: These are (generally) “tell me about a time when...”

And the key point I want to stress is this: each one requires deliberate, targeted preparation. You should NOT wing these. Relying on general experience alone is likely only going to get you so far. And you absolutely cannot treat them as interchangeable.

Let’s walk through each one.

Coding Rounds: Yes, You Still Have to Practice

Like it or not, coding interviews at FAANG companies are still largely LeetCode-style problem solving. And if you’ve heard me talk about this stuff online, whether it’s social media posts, videos, or live streams... I am NOT a fan of LeetCode style questions for interviews. I touch on it here on Code Commute:

I strongly dislike the format because I don’t think it reflects real-world software development, and I don’t think it does a good job of measuring engineering effectiveness. I’ve felt this way for years, both as an interviewer and as an engineering manager.

That said, your opinion on LeetCode is irrelevant to the outcome of your interview. Yeah -- I’ve also had to do the LeetCode grind for principal-level engineering management roles. I don’t like it, but it’s unfortunately what’s in place. If they ask me, they are absolutely going to ask you as a software engineer.

If you are interviewing at a FAANG company today, you should assume that you will be asked LeetCode-style questions. These questions are not just about getting a solution. They are about:

• Explaining your approach clearly

• Identifying tradeoffs

• Understanding time and space complexity

• Refining a naive solution into a better one

Even very strong engineers struggle here if they haven’t practiced recently, and I feel it’s because this style of problem-solving is more “artificial”. It rewards familiarity with patterns and tricks rather than day-to-day engineering tasks -- like working in existing large scale systems.

I’d recommend that you:

• Carve out time multiple times per week to practice questions. Daily is great if you can make the time for it.

• Try not to look at the answers. Ideally, you’re not memorizing outcomes but instead navigating questions.

• Build confidence in the “easier” questions before moving up. You’ll find the patterns/approaches can stack and layer.

So if you’re preparing for interviews, you need to carve out time specifically for this. Daily practice or several sessions per week is not excessive. This is one of those areas where reps matter. You don’t have to like it. You do have to prepare for it. You can check out resources like:

• LeetCode

• NeetCode

One HUGE caveat to all of this... AI is absolutely changing the world we live in as software engineers. That means interviews are very likely going to be affected. At the time of writing this, we’re starting to see some companies (including Big Tech) start to explore changes here... So I am optimistic we’ll see this move away from the current LeetCode format to something more practical.

System Design: Understanding Beats Memorization

System design interviews are often misunderstood, especially by engineers earlier in their careers.

These interviews are not about drawing the “correct” architecture. There is no single right answer. What interviewers are evaluating is how you think, how you reason about tradeoffs, and how you handle ambiguity.

A typical system design question might sound like “Design a video sharing platform” or “Design a food delivery system.” The biggest mistake candidates make is jumping straight into solutions.

Don’t do that. I know -- it’s super hard because the gears start turning RIGHT away and you’re probably excited to get into it.

The first part of a strong system design interview is clarifying requirements:

• Functional requirements

• Non-functional requirements

• What’s in scope

• What’s out of scope.

• Scale assumptions

• Latency expectations

• Consistency tradeoffs

Only after you’ve aligned on those should you start proposing components. These are often not directly told to you by the interviewer -- you’re expected to ask about these things. These constraints will influence the system you’re about to build in the interview.

So, yes, you should practice system design. But I want to be very clear about something: memorization is a trap.

If you’ve memorized a specific “Uber design” or “YouTube design” and the interviewer asks a follow-up question you don’t understand, it becomes painfully obvious very quickly. You end up describing boxes and arrows without actually knowing why they exist. Understanding why certain components are used matters far more than remembering that they exist.

If you don’t understand something while practicing:

• Stop and dig in! This is the perfect time for it!

• Ask an LLM. Ask for pros and cons. Ask why one approach is preferred over another.

• Build intuition, not scripts. What should happen to your design if one of the constraints changes?

• Check out newsletters from awesome creators like and

As you move up in seniority, system design tends to carry more weight. Junior roles skew more heavily toward coding. Senior roles shift toward design, tradeoffs, and technical leadership. Every company will do this a little bit differently, but that’s a generalization that should be applicable.

Which brings us to the last category.

Behavioral Interviews Are Not About Technology

Behavioral interviews are where a lot of otherwise strong candidates stumble.

These questions are not asking you to explain your tech stack. They are not asking you to justify architectural decisions. They are asking you to demonstrate how you operate as a human being in a team. Questions like:

• “Tell me about a time you disagreed with a teammate.”

• “Tell me about a time you handled conflict.”

• “Tell me about a time you had to make a decision with limited information.”

Even when the scenario is technical, the evaluation is not. This is the important thing to keep in mind, because it’s very easy for us as engineers to want to explain all of the interesting technical details -- it’s just not the right time for it.

Interviewers are listening for things like:

• How you communicate

• How you handle disagreement

• Whether you listen to others

• How you navigate tradeoffs

• Whether you can reflect on outcomes honestly

The STAR method (Situation, Task, Action, Result) exists for a reason. It forces structure and clarity. If you struggle to frame answers, this is an area where using AI to rehearse and refine your stories can be incredibly effective.

One important tip here: many companies publish their core values. Those values directly influence behavioral interview questions.

If a company values “bias for action,” expect questions about acting under uncertainty. If they value “ownership,” expect questions about accountability and responsibility. If they value “collaboration,” expect questions about conflict and alignment.

Not only can you find these core values on company websites, you can work with your favorite LLM to help you out with these questions. For example, if you are practicing for your Meta interview, you could ask:

I am applying for a level XYZ software engineering role at Meta. Factoring in Meta’s core values (optionally give it the link to assist with accuracy), give 10 level-appropriate example behavioral interview questions.

(You can even steer the prompt to be more specific, so things like conflict resolution, project management, handling ambiguity, etc...)

You can and should practice behavioral interviews intentionally. This is not fluff. These rounds carry real weight, especially at senior levels.

AI Is Changing Interviews

I wanted to put this explicit reminder in here again that AI is already forcing changes in how interviews are run, especially coding interviews. LLMs can trivially solve many LeetCode problems. That reality isn’t going away, and I’m sure we’ll see more and more of this surfacing.

Some companies are experimenting with allowing AI during interviews. Others are shifting toward collaborative exercises. Others haven’t changed at all yet. But there IS change happening in the industry.

The important takeaway is this: you should prepare for the current reality, not the future you hope for. And as you are preparing for the current reality, keep tabs on how these processes are changing -- because change is happening rapidly.

Today, FAANG interviews still test coding, system design, and behavioral skills independently. Until that changes across the board, you need to be ready for all three. I’ll do my best to report on what I see changing as I see it changing because this is a critical part of getting your foot in the door to do awesome engineering work.

The Big Picture

FAANG interviews are not a test of how smart you are. They are a test of how prepared you are across multiple dimensions.

You need:

• Focused practice for coding rounds

• Structured thinking for system design

• Self-awareness and communication for behavioral interviews

None of these are optional. None of them are interchangeable. Your level and which company you are applying to may dictate the weight of each of these categories... but you need them all.

If you approach interview prep intentionally, with respect for each category, your odds improve dramatically. If you assume one strength will carry you through the entire loop, you’re taking a risky bet.

Prepare accordingly. Feel free to send in any questions so that I can help answer!

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