I work in a high stakes, fast paced, critical product team. I don't want to be identified so I won't list the team roles but we effectively have no dedicated manager or tech lead. It's effectively a bunch of Indian contractors and mid/sr SWEs on one team, and there is a hardcore culture silo.

Everyone puts their heads down, keeping their work as silo'd as possible and just report statuses. The PR reviews are mostly rubber stamps and the code is mostly AI generated.

I try to do my best to contribute to engineering leadership, I.e. pressuring people to put their designs to large features or greenfield development into a document and review it with the team before full sending a 40+ AI generated file diff PR, proactively commenting on PRs, assigning follow up tickets to indovidual engineers where I feel substantially necessary, etc..

But part of me is burning out being the only one who seems to care about anything other than doing what is specifically assigned to me. My last team had strong engineering leadership and my partner's current org also has very strong tech leadership as well (possibly even a little too much to the point where every PR gets heavily scrutinized). Also the current "sr" SWE is one of the most major contributors to the culture as well, and effectively does almost nothing I'd expect a senior SWE to do, they are more of a scrum master and EM.

Any tips on dealing with this culture? Should I keep up the tech lead role even though I'm mid level and not the sr? Should I just go along with the rest of the culture and just blast out as many tickets as possible? Should I look to transfer teams in the mid future? Should I be grateful my work isn't being blocked by a million other highly opinionated, vocal engineers?

Any advice is greatly appreciated

I want to gauge how much my chain of thought here aligns with what people experience. Because (spoiler): even a "bug that never happens" being unhandled makes holes in my mental model of code. One isn't that bad, but there tend to be more in larger codebases.

Let's say there's a bug that's almost impossible to reproduce. Do you care about it or not?

Example: a websocket reconnects -> the old connection's onmessage is still awaiting data.arrayBuffer()and finishes after the new connection has already delivered a fresher value, and overwrites it with an older one.

```typescript

let currentValue = 0

function connect() {

const socket = new WebSocket(url)

socket.onmessage = async ({ data }: MessageEvent<Blob>) => {

const message = decode(await data.arrayBuffer())

currentValue = message.value

}

socket.onclose = () => setTimeout(connect, 0)

}

```

In that example, it really can happen when the payload becomes huge + under CPU contention.

The fix is around three lines but adds effectively dead code.

```typescript

let connectionId = 0

function connect() {

const myId = ++connectionId

const socket = new WebSocket(url)

socket.onmessage = async ({ data }: MessageEvent<Blob>) => {

const message = decode(await data.arrayBuffer())

if (myId !== connectionId) return

currentValue = message.value

}

socket.onclose = () => setTimeout(connect, 0)

}

```

But I'd accept it just because the complexity was already there, in the model of the world the reader builds in their head. "This execution can lead to data corruption" is what I read in the original. If I see it handled, I let it go and move on with my actual task. If I see it's not handled, I get distracted and have to remind myself that this code is all right.

There's often more than one such bug; it's damn distracting in my opinion.

If the idea isn't detailed enough, I did a more detailed write-up with my position on that on my blog: https://www.dearlordylord.com/blog/mandelbugs-and-heisenbugs-as-attention-distractors/

But the general idea is hopefully presented as concisely as possible in this post. What's your take?