I love using interns for this. Typically they 1. Have some free time to test things out. 2. Smart enough they won’t try to eat the mouse. 3. Dumb enough they won’t be able to figure out those 20 obscure steps to make it work like the senior dev would.

It won’t find all bugs, finding ui/ux issues or common bugs they are great at. One example that I can think of is our badges had 2 barcodes on them, one assigned by new company who bought us and one assigned by original company(for legacy and regulatory reasons). If you never worked for old company the second bar code was all zeros. Most employees knew this and new to always scan the new one to log into software. An intern didn’t. They ran a bunch of tests but reviewing the data the “operator” was listed as all zeros. This could have been a legal issue if released into production. Thankfully it was caught because intern didn’t know which bar code to use, a check was implemented in the code to ensure the user was not all zeroes(as well as other tests to make sure it was new company and not old company but I can’t go into detail on those).

I feel like many bugs in the wild just come from business processes slowing everything down, especially in larger companies. It might seem like a bug that can be fixed in half an hour, if anyone spotted it, but instead:

1. they need to file a ticket
2. it gets discussed in planning, but postponed because there’s an extremely important™ deadline (repeat this step like 5 times)
3. someone from upper management notices the problem and sends an angry mail; it is finally included into the sprint
4. they implement the change
5. it gets rejected in code review due to some nitpick
6. they fix that nitpick
7. it passes code review and is merged onto main
8. it gets discussed again in sprint review
9. it gets shipped two months later
10. ah crap, something broke; need to bisect a few hundred commits to find out it was this change that broke it
11. spend half a day preparing and testing a hotfix release, because the next proper release is months away
12. it gets rejected in code review due to some nitpick
13. …you get the idea.

You go through that slew of bullshit exactly once before you learn to turn a blind eye to anything that looks easy to fix.

This article was fascinating to me because it described my experience when using software. I’d constantly run into bugs and issues and would get frustrated.

Even when I worked at a big tech company where I was surrounded by other devs, I would find and fix bugs, improve framework abstractions, etc.

The idea that people have to have a mental model on things should work to find bugs was interesting.

The life of a gardener continues to call my name.

What is the social punishment for repeatedly and consistently finding flaws in the work of others? maybe this isn’t about cognition so much as fitting in.

Or more systemically: programmers who point out flaws are weeded out of the employment pool.