You must log in or register to comment.
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.
Do it, tending nature is a lot easier than attempting to herd cats that think they’re the honest thing since sliced bread and their code would never fail.
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:
- they need to file a ticket
- it gets discussed in planning, but postponed because there’s an extremely important™ deadline (repeat this step like 5 times)
- someone from upper management notices the problem and sends an angry mail; it is finally included into the sprint
- they implement the change
- it gets rejected in code review due to some nitpick
- they fix that nitpick
- it passes code review and is merged onto
main - it gets discussed again in sprint review
- it gets shipped two months later
- ah crap, something broke; need to bisect a few hundred commits to find out it was this change that broke it
- spend half a day preparing and testing a hotfix release, because the next proper release is months away
- it gets rejected in code review due to some nitpick
- …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.
So Ephera, why is this bugfix taking more than 1 hour?!!
Bugs are not possible to evaluate (except the most simple ones) and if you can’t completely fix the bug and its deoendency bugs in the original time allocated then everyone will think you just wasted time. Or so it has been for me on those “Agile” jobs.
Yeah, I didn’t even include technical debt into my list, but it comes up so often as well. Chances are someone else already saw the problem, considered fixing it, then saw the mountain of technical debt blocking a fix, and decided to ignore the problem in the end.
For me, thankfully, folks have been understanding so far, when a bug fix takes significantly longer than expected.
But we also explicitly don’t estimate bug fixes upfront, because of what you say. You have to diagnose the bug to figure out what solution is required. And the solution can range from a one-line-change to a refactoring of half the codebase. Good luck estimating that…
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.
We’re seen as the problem, who only dredge up trash, without recognition of the cleanup in our wake.
Well in a sense that is true. This guy is pretending like he’s the only one that sees bugs. In reality he’s the only one that isn’t able to understand priorities. If you’re constantly reporting every bug no matter how trivial, that is a problem. You’re wasting people’s time.
Based on the time in role for the OP of the linked article, I’d venture to guess they aren’t wasting people’s time.
Really? Because some of his hand-picked bug examples are “syntax highlighting is sub-par on GitHub.com”, “Google Analytics’ map view shows some cities in the wrong place”, “a weapon in a game works differently than intended in a way that isn’t noticeable to players”, “a Google hangouts call didn’t work once”.
Technically bugs but… Yeah let’s see his perfect software.
Tenure doesn’t mean much.
Don’t feel bad, this seems to happen in every field.
I really did enjoy watching Oppenheimer because, though surely politics played a role in promotion, knowing your shit was an absolute qualification for working on the Manhattan Project.
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).
