In this episode, Dave and Jamison answer these questions:

1. Listener Ashleigh asks,

   I’m a mid-level developer at a small company with a non-technical manager. After several months working on migrating our users from a legacy system to our new system, our non-technical business analyst discovered our current system re-uses lots of code from the legacy system. The BA immediately escalated their “concerns” about this to our manager. This quickly resulted in a group message from our manager to the BA, our senior engineer, me, and another developer. Without asking for more than a cursory explanation of how two sets of users who need the same functionality can use the same code base without breaking things for each other, our manager made the decision to fork the project and maintain two separate code bases.

   The developers tried to explain why this was a bad idea, but we were immediately shot down. This has already resulted in issues in pre-production environments. They were afraid that having changes in one unified code base would break things for both groups of users. We were given no opportunity to make further arguments. Two months later I find that my motivation at work has tanked. Despite being below market rate, I’ve stayed because it’s allowed me to advance my skills as a developer.

   But my trust in our BA and management is completely shattered. Is it worth staying in my current role? Is salvaging my current situation a hopeless cause that will likely just collapse again in the future? Or would I be wise to get out ASAP before things blow up and the blame is pushed on our development team? I feel like I already know the answer in my gut, but I’d like to hear your perspectives on this.

2. Listener Damison Jance asks,

   I sometimes find myself struggling to describe how software issues will affect product designs to non-software engineers. It is hard for me to explain “this seemly tiny change in user experience you’ve asked for is actually driven by this backend functionality that is totally transparent to users and really no one besides backend engineers has any reason to know about it, but yeah anyway that small change is going to require six months of work and changes to multiple services.” I have found this approach quite ineffective, and I think it comes off as me sounding like “my way or the highway”. I’m wondering if you guys have any tips for explaining how systems work to people who aren’t software engineers and don’t necessarily have all the context you do.

Show Notes

Microservices video (keyword: Omegastar): https://www.youtube.com/watch?v=y8OnoxKotPQ

In this episode, Dave and Jamison answer these questions:

1. “Hi! Love the show, long time listener.

   So an architect noticed an issue with credentials embedded into request body being logged. I had planned to resolve that, and someone already had done so for another instance.

   I took a day or two to figure out how to fix it globally, and even tied it into another filtering we did. That would mean one list of sensitive data patterns to maintain – that we already had, and don’t need to worry about which context keys to scan in. Scan them all, CPU time is free after all /s

   I opened this PR, and received no feedback for a day. Another engineer did mention an alternate approach that would resolve this particular case, but I was trying to fix it globally so we didn’t have to maintain a list of keys to scan on.

   Next day he mentioned he made some click ops change that resolved THIS PARTICULAR INSTANCE, meanwhile still not providing any feedback on the PR. This approach is IMO a maintenance burden: keep two different filtering in sync, proactively add keys to strip. High chance of mistakes slipping in over time.

   So I said OK works with some caveats, and rejected my PR. I can not explain why but this incident tilted me hard. For one thing he essentially grabbed my ticket with no communication and resolved it himself. Then he provided no feedback and went with a different approach without consulting anyone else. Worst of all, he ended up with an (IMO) markedly worse fix that I had already dismissed as being too brittle and likely to miss things in the future.

   What do? Am I unreasonable to feel undermined and disrespected?”

2. Hi Dave and Jamison, long time listener love the show. I work on a team that is relatively small in size but we own a huge scope including multiple flavors of client-side app and a bunch of backend integrations. We recently launched our product and since then there have been constant fire due to various tech debt that we never fix. Our manager has attempted to ask the team to share the burden of solving these tech debts, but there are only very few that are actually doing it. I can think of many reason why they are not able/willing to take on the task, likely due to other priorities or unfamiliarity with the part of the codebase. Due to my familiarity with various component, I’m usually the one proposing the fix and actually fixing it. I have started to feel this is taking a toll on my own career development because I ended up not having bandwidth to work on those bigger projects/features that have high visibility and good for promotion. I do think solving the tech debt is important work and don’t mind doing them. How would you navigate this situation? Thanks for the awesome podcast!

In this episode, Dave and Jamison answer these questions:

1. I’ve managed an ML team in a small company for ~2 years now. I created an 8 person team from scratch and I’m super proud of the team I’ve built. However, I miss being an engineer and wish I could spend more time coding. I was considering asking for a role change to IC, but out of nowhere my manager offered to me a promotion to head of platform engineering. I would have 3 engineering teams reporting to me - about 30 people altogether.

   I have trouble saying no to new opportunities but can I put the genie back in the bottle? If I get “Peter principled”, I feel like it would be challenging or embarrassing to return to IC work.

How can I stay close to the ML side while managing other teams? Would other teams feel dejected if they know I had a “favorite” team?

2. Is it just me or do people also find silences over Zoom unbearable? I work in a team that is mostly remote, and I find myself deliberately logging into meetings late to avoid the silence or the stilted, awkward smalltalk. If i’m running the meeting, I kickoff at 1 minute past to avoid having to deal with that dead air. I also find myself too quick to fill pauses during meetings. I never have this problem in person meetings. I’ve been in the same team now for nearly a year and I still dread uncomfortable silences over Zoom. How do I get over this?