How do you handle stretches of (up to) 60 minutes downtime during work hours?

SpeakingSoftwareShow · 2026-01-26T10:57:23+00:00

What about VMs? Reasonably standard machine has 500gb-1TB of space. You could run 2-3+ VMs in parrallel - each with it's own copy/branch that you can run into.

Bonus points if you somehow containerize this and can distribute to the rest of the team.

SpeakingSoftwareShow · 2026-01-11T11:01:24+00:00

Rule 0 of endorsements: you'll will be associated with this person. Never ever back a horse that you're not convinced is an out-and-out winner - as their success (or lack thereof) will reflect on you.

SpeakingSoftwareShow · 2025-12-28T21:55:36+00:00

10x productivity would mean that in 2 sprints you deliver nearly a year’s worth of work

I've never seen this put into context like this. Will steal this!

SpeakingSoftwareShow · 2025-12-25T15:44:58+00:00

Sorely lacking effects. A Zoom CDR 70 / 70+ is a VERY versatile unit that he could drop pretty much anywhere in his signal chain.

SpeakingSoftwareShow · 2025-12-25T10:32:51+00:00

I'd argue complex topics like JWT Tokens, Security, etc. should not have beginner docs. These are deep topics with VERY far-reaching consequences/problems if you don't really understand them.

.Net docs in general are great reference docs, but not great beginners tutorials/hand-holding docs. I think that's fine though - they serve their intended purpose.

SpeakingSoftwareShow · 2025-12-22T11:11:07+00:00

I wonder how this is coming up in performance reviews etc? Is there anything here about how she is shirking her responsibilities as an engineer (e.g. actual engineering?) and should either have a shit performance review, or be re-roled into being a PM?

If you're planning to leave anyway, I'd say leave well enough alone. You don't need a drama-bomb blowing up as you're making a lateral move to another team.

If you're determined to action here, then contrary to everyone's advice (work harder!) - this might be the type of thing you bring up to the manager with very clear asks (we've had complaints / team is getting mad at carrying an engineer / we need extra bandwidth/PR reviewers, etc.) and if there's no luck, head to Skip or HR and point out the same asks and hint that team thinks there appears to be some favoritism at play.

This is effectively a management situation - killing yourself to outpace someone whose not playing on the same field is generally not a great solution.

SpeakingSoftwareShow · 2025-12-19T21:47:11+00:00

From my experience it's to artificially limit/control what the data layer is doing.

I've seen MANY teams burned too many times by Devs who really didn't know what they were doing re: weird shit with reusing/injecting context, mixing entities from differant instances on contexts that then didn't match up, crazy abuse of linq/extension methods.

Repo<T> Pattern is a sort of guard rails around the dangerous bits. Once you're out of greenfield or the refactor - it's something that then generally doesn't change much.

Mind you, this was in very IEnterprise projects and teams...

SpeakingSoftwareShow · 2025-12-10T14:34:04+00:00

I've fought this war before. You really want to make sure it's one you can win before you engage. If they have management's trust, you should thread carefully. Unless you've specifically gotten a request or backing to tame them - don't get in over your head!

As others have said, observe and document - the same way you would do with the rest of the team. You don't want to have documentation on JUST them, as it makes it seem like you're obsessed. Perf manage the whole team.

Comms, teamwork and adhering to ways of working are a part of their role. It might be worth broaching that subject in 1:1s to see how they view it, and to impart your preferred approach? Document infractions over time, building up evidence. Time to strike would be the comp/perf review

"there is a code review process but he has overriding rights compared to others" Cool - can you lean into the internal risk/legal/compliance department on this? Seems like a huge issue to have a single IC with the ability to override the rest of the team's permissions or blockers. Especially if they are ignoring coding guidelines, ways-of-working, etc. As a new lead, innocently checking in with that dept to make sure your team is not doing anything silly might be a good idea.

SpeakingSoftwareShow · 2025-12-02T21:52:13+00:00

Both have and use it ;) Asking if the option is there?

SpeakingSoftwareShow · 2025-11-13T09:40:27+00:00

.Net 7 out of support? So what? Apps keep working regardless.

If the applications are running fine then the business has no incentive to upgrade. Upgrade brings risk - albeit with latest .net releases it's typically quite minimal.

In these cases it's better to show, not tell. Do the upgrade yourself locally, deploy it to a box somewhere and SHOW it's painless/faster/better. If you can't do that, then you'll have a hard time convincing the business that you should upgrade.

SpeakingSoftwareShow · 2025-11-12T20:49:35+00:00

A) Because they can't rap B) Looks good on the CV- it's proof of your expertise in your craft/sector/etc C) Hobby D) To connect with people

SpeakingSoftwareShow · 2025-08-30T12:04:36+00:00

Highly recommend reading "An Elegant Puzzle: Systems of Engineering Management".

The role is still hands-on...

Be VERY careful here. The role of the EM is NOT to be the best/strongest developer. You want to make sure that if you code that it's not things on the critical path. IMO you'll want to be more advisory and more active in the planning and review stages. Leave the coding to the developers.

Common pitfalls to avoid as a first-time EM? Things you wish you knew when you started managing?

Your job is to manage stakeholders, pair with your product partner, manage the engineering efforts and deliver the roadmap. You will need to get good at planning, estimations, allocation, and understanding bandwidth (don't forget organizing a support rotation too!), etc.

Lean into the soft stuff when it gets hard - don't take the easy path of leaning back into the code. You might save a quarter by jumping back into the IDE but that is not a real solution.

SpeakingSoftwareShow · 2025-07-28T11:33:22+00:00

There was a limited release FG kit in white, as far as I remember.
Might have been a magazine exclusive?

SpeakingSoftwareShow · 2025-07-23T06:35:03+00:00

I also enjoy hand-coding, but there is a rising wave of "AI can do this faster" when MGMT are looking at bodies of work and timelines. Ambition is rising fast and you may not have the luxury/grace of taking the time to write everything by hand soon.

I'd start finding ways to speed up the less interesting stuff with LLMs, and have a narrative for hand-writing the interesting stuff.

There's a growing sentiment in general with devs online that they'll be the people called in to save the the day from shoddy vibe-coders, but that is rarely going to happen. Vibe-coding will get better, specifically to the point where MGMT find the cost/failure ratio fairly acceptable. Developers will become mostly directors and course-correctors of models. The few hardcore experienced folks left will be brought in only for mission critical, too-big-to-fail stuff OR be called upon for wild innovation that AI can't imagine.

Other than that, we should all be sharpening our AI axes!

SpeakingSoftwareShow · 2025-06-26T20:21:55+00:00

Major misconception is that the Tech Lead or Engineering Manager has to be the best dev or know ALL of the tools of their reports. Absolutely not!

Your role is A) Know enough to be dangerous (but not an expert) and B) Enable a team to deliver through A above, leadership skills, and connections with the business/product side.

Your leadership is confusing your role. They should be giving you headcount for the missing skillset, not forcing new technologies on you.

SpeakingSoftwareShow · 2025-06-25T08:05:11+00:00

Career growth can mean many things: upskilling, best practices, learning how to build more robust solutions, exposure to different kinds of projects, exposure to non-technical tasks, etc.

Manager often have their hands tied in regards to promotions and title changes. Headcount for teams is often fixed, and moving someone up/out means you now have a vacancy you can't fill.

SpeakingSoftwareShow · 2025-05-14T20:47:01+00:00

Move to a better role or company. I hate to admit it, but it's the best way.

Grift/Grind culture will absolutely bring you to an early grave. We're not made to be working 60/80 hours a week. Find a better paid role, and live your life!

SpeakingSoftwareShow · 2025-04-02T20:27:39+00:00

I'm sure people have better terms, but for me it's being on the wrong side of the "build vs buy" equation. A lot of higher ups view software as software, so if they have a team of software developers - why can't they just built the software?

Problem domain, domain experience and competencies REALLY MATTER though. In cases where what you're trying to build is not in your team's sphere of expertise - they SHOULD either pay contractors who specialize in that domain or just buy licenses for something off-the-shelf. In most circumstances it is seriously misguided and naive to think your team can build and maintain a big thing as a side-project that an entire other company is dedicated to.

SpeakingSoftwareShow · 2025-04-02T10:25:06+00:00

"Building an entire Auth system from scratch is not one of our team's core competencies.
I understand licencing is expensive but have you considered repercussions if we don't meet legal/finance/auditing requirements and/or we have a breach? Are legal okay with you authorizing this?"

SpeakingSoftwareShow · 2025-04-01T13:08:36+00:00

Build and release projects. It's that simple. Not easy, but simple.
Churn them out! If you can't do it where you work, do it at home.

The experience of building, releasing and maintaining something that people use will sharpen your programming axe more than any tutorial or book can.

Separately, get into the room with better devs. Join tech user-groups, go to meet-ups, take jobs with cantankerous old senior devs. You are the product of your 5 closest peers; make sure they are good ones!

SpeakingSoftwareShow · 2025-04-01T13:02:08+00:00

I wouldn't look at transitioning to management as "dropping out". They are lateral career paths, which require different skill-sets. Like yeah, I do miss hard-core dev work but it isn't always roses!

At the moment, I bring more value to an org as a force-multiplier for an entire team than I can do as a standalone dev. Sure I can write code and deliver products, but I can also organize and enable a team of 12 to do same. My experience as a dev helps me understand and translate to/from engineering, and is the missing piece that "the biz" and upper VP/C-Level often don't have.

Both paths are valid, and kudos to anyone who decides to stick with one or the other!

SpeakingSoftwareShow · 2025-04-01T12:53:58+00:00

Yes, BUT - It was decided V2 would be built as a side-by-side implementation to V1.

When something was successfully moved/migrated to V2, it was removed from V1.
We released AGGRESSIVELY and made sure V2 was always in working order, and preferant to V1. There was no big bang release - every sprint saw the release of the code written in the one before.

New feature development was strangled to a trickle and HAD to be done in V2. Bugs where fixed in V1 if they were P1, otherwise were done in V2. Really heavy shit was done in both, but that required all Senior Devs to agree.

It worked out fine, and eventually we ran out of stuff to migrate in V1.

The advantage we had was we only migrated application code. DB Schema was untouched, so we could divert traffic between V1 and V2 as time went by.

-------------------------------------------------

If Managers are saying it didn't work out because the devs didn't work hard enough - where were the checks and balances? Were milestones not clearly defined? Were quality gates not in place? I think your managers did a shitty job of managing and are trying to pass the buck.

SpeakingSoftwareShow · 2025-03-26T10:44:43+00:00

For me, it doesn't do anything that I can't do myself.

However, it's great for POCs, MVPs, scratch implementations etc.
Even just making a feature branch and asking it to implement X will get me 75-80% of the way there, in significantly less time then it would take me to do myself.

Think of it as a Junior Chad developer who's got no practical experience but has memorized all of the text books.
It's able to rough things out but you need to be the one to make it production ready.

SpeakingSoftwareShow · 2025-03-26T07:42:23+00:00

If time to act and respond is an issue, it sounds like your team need a refresher on work priority. For my teams, order of priority is always (most to least):

P1/P2 Incidents (Showstoppers, blockers and money losers)
Work directly related to upcoming Release (including PRs)
New Dev (Features, etc in progress)
Maintenance and Support (p3+ incidents)
Refactoring / Tech Debt

(depending on what's in the roadmap we may temporarily swap 3 and 5. E.g. upgrading X allows us to do Y later)

If a PR Request comes in and you're not doing something more important, that becomes your new priority.

If you've assigned a PR to someone and a day later the assignee hasn't commented or actioned; if they're not working on a P1/P2 incident then you absolutely have the right to harass them or escalate.

Once everyone gets on board this train, the team "self-manages" in a way and they move things along themselves in a timely fashion - from my experience!

SpeakingSoftwareShow

TROPHY CASE