If you do not follow the happy path something will break 100% of the time. That's why engineers always follow the happy path. Some engineers even think that anything outside the happy path is an exception and not even worth investigating. These engineers only thrives if the users are unable to switch to another product. Only competition will lead to better products.

My favorite happy path developer.. and he was by far 10x worse than any engineer I worked with at this, did the following:

Spec: allow the internal BI tool to send scheduled reports to the user

Implementation: the server required the desktop front end of said user to have been opened that day for the scheduled reports to work, even though the server side was sending the mails

Why this was hilariously bad - the only reason to have this feature is for when the user is out of office / away from desk for an extended period, precisely when they may not have opened their desktop UI for the day.

One of my favorite examples of how an engineer can get the entire premise of the problem wrong.

In the end he had taken so long and was so intransigent that desktop support team found it easier to schedule the desktop UIs to auto-open in windows scheduler every day such that the whole Rube Goldberg scheduled reports would work.

You found a 1× engineer; the worst engineer that can keep the job.

Over time we actually found him to be more of a -2x engineer, but thats another story

edit: reminded me of the old joke

A programmer gets sent to the store by his wife. His wife says, “Get a gallon of milk, and if they have eggs, get a dozen.”

The programmer returns home with 12 gallons of milk and says, “They had eggs.”

The fool, he should have gotten 13 gallons of milk

Ah, the "and" ruins that joke for me by signifying a separate clause. I think the original is:

> A programmer gets sent to the store by his wife. His wife says, “Get a gallon of milk. If they have eggs, get a dozen.”

'Antiwork' - every hour they work uses up more than an hour of other engineers' time in questions, meetings, and later fixes.

Correct - they do bad work quickly which requires 2x the time on repairs

> more of a -2x engineer

You just needed to find another one like him, and bam, +4×.

(It is actually conceivable that two bad engineers could mostly cancel each other out, if they can occupy each other enough, but it’s not the most likely outcome.)

It honestly doesn't even sound like there was a happy path involved in his work.

> That is great QAing. It also speaks to why QA should be a real role in more orgs, rather than a shrinking discipline.

As a software engineer, I've always been very proud of my thoroughness and attention to detail in testing my code. However, good QA people always leave me wondering "how did they even think to do that?" when reviewing bug reports.

QA is both a skillset AND a mindset.