Netflix buffering issues: Boxing fans complain about Jake Paul vs. Mike Tyson

I'm not a manager and I don't stack rank people, but I am 100% capable of knowing when one of my co-workers or predecessors is a fucking moron.

The trick is to use my massive brain to root cause several significant outages, discover that most of them originate in code written by the same employee, and notice that said employee liked to write things like

    // @ts-nocheck
    // obligatory disabling of typescript: static typing is hard, so why bother with it?
    async function upsertWidget() {
      try {
        // await api.doSomeOtherThings({ ... })
        // 20 line block of commented-out useless code
        // pretend this went on much longer
        let result = await api.createWidget({ a, b, c })
        if (!result.ok) {
           result = await api.createWidget({ a, b }) // retries for days! except with different args, how fun
           if (!result.ok) {
             result = await api.updateWidget({ a, b, c }) // oh wait, this time we're updating
           }
        }
        // notice that api.updateWidget() can fail silently
        // also, the three function calls can each return different data, I sure am glad we disabled typescript
        return result
      } catch (error) {
        return error // I sure do love this pattern of returning errors and then not checking whether the result was an error or the intended object 
      }
    }

    function doSomething() {
      const widget = await upsertWidget()
    }

...except even worse, because instead of createWidget the name was something far less descriptive, the nesting was deeper and involved loops, there were random assignments that made no goddamn sense, and the API calls just went to an unnecessary microservice that was only called from here and which literally just passed the data through to a third party with minor changes. Those minor changes resulted in an internal API that was actually worse than the unmodified third party API.

I am so tired of these people. I am not a 10x rockstar engineer and not without flaws, but they are just so awful and draining, and they never seem to get caught in time to stop them ruining perfectly fine companies. Every try>catch>return is like an icy cat hand from the grave reaching up to knock my coffee off my desk.

Isn't that a problem with your code review process? Why is that person's code making it to production?

So again, maybe they're a bad employee but it seems like nothing's done to even try and minimize the risks they present.

There's a disincentive to actively block PRs if you don't want your coworkers to think you are a bad colleague / not on their side. So you often see suboptimal code making its way to production. This has a worse effect the more terrible engineers there are.

Except in this case it's clearly affecting at minimum the rest of OP's team.

At that point it's not one person being obnoxious and never approving their team members diffs and more of a team effort to do so.

But at minimum if you have a culture of trying to improve your codebase you'll inevitably set up tests, ci/cd with checks, etc. before any code can be deployed. Which should really take any weight of responsibility out of any one member of the team. Whether trying to put out code or reject said code.

In this specific case, the fucking moron in question was the one who designed the code review process and hired the other engineers, and it took place a significant length of time before my involvement.

Which, yes, does raise interesting questions about how someone who can't be trusted to handle errors in an API call ended up in a senior enough position to do that.

Turning this into an incentive that everyone values is a signal that a team has a great culture.

I dunno, I've gone and done a "git blame" to find out who the fucking moron that wrote the code was, only to find out it was me three years ago.

Sure, there's such a thing as stupid code, but without knowing the whole context under which a bit of code was produced, unless it's utterly moronic, (which is entirely possible, dailywtf has some shiners), it's hard to really judge it. Hindsight, as applied to code, is 2020.

I agree with the general sentiment ("one instance of bad code might have been me") but not the specific sentiment ("I could easily decide to catch and ignore errors through every bit of code I worked on without knowing why that was bad, and commit other, similar crimes against good taste in the same way").

The difference for me is that this is pervasive. Yes, sometimes I might write code with a bug in error handling at 3am when I'm trying to bring a service back up, but I don't do it consistently across all the code that I touch.

I accept that the scope is hard to understand without having worked on a codebase which a genuine fucking moron has also touched. "Oh strken," you might say, "surely it can't be that bad." Yes, it can. I have never seen anything like this before. It's like the difference between a house that hasn't been cleaned in a week and a hoarder's house. If I tried to explain what hoarding is, well, maybe you'd reply that sometimes you don't do the dishes every day or mop the floor every week, and then I'd have to explain that the kitchen I'm talking about is filled from floor to roof with dirty dishes and discarded wrappers, including meat trays, and smells like a dead possum.

Hey, that possum's name was Roger and I'm really sad that it died. I've been feeding it for weeks! There are definitely bad programmers out there who's code is only suitable for public shaming via the daily wtf.