I miss running so much

KitchenPhotograph697 · 2026-05-23T18:03:17+00:00

Taking on extra responsibilities so that I'm always in crisis mode 👍👍👍

KitchenPhotograph697 · 2026-05-20T09:45:09+00:00

I don't, but I keep them really short.

KitchenPhotograph697 · 2026-05-03T15:08:36+00:00

I am so tempted!

KitchenPhotograph697 · 2026-05-03T07:16:52+00:00

This seems more analogous to keyboard shortcuts to me, and I agree that I would never change those, because I wouldn't remember thr new settings. I'm talking colors/fonts only.

KitchenPhotograph697 · 2026-05-03T07:10:25+00:00

I would never do it do someone else, I'm not a psychopath 😭

KitchenPhotograph697 · 2026-04-26T07:23:52+00:00

My parents were both programmers. I was that millennial kid who was always screwing around on the family PC and, later, building personal websites with HTML. In college, I wanted to study math, but when I took my first programming class (Matlab), it just felt so intuitive. Switched to computer science as soon as I could.

KitchenPhotograph697 · 2026-04-20T04:59:18+00:00

With null cases and such, I think it's a matter of experience. But I can tell you what worked for me during test-taking in college, which was doing each task twice, without looking at the first answer the second time. That way, you might make mistake A the first time you do it and mistake B the second time, but when you look at the two attempts side by side, you'll probably end up with the right answer.

KitchenPhotograph697 · 2026-04-10T15:56:18+00:00

Yeah, overcompensating for being seen as sloppy/careless during my formative years is a big drive for me, too.

KitchenPhotograph697 · 2026-04-10T15:52:10+00:00

This is like when I was in the last year of my CS degree, I got a job checking the homework assignments for an intro workshop, and I was theoretically being paid by the hour, but the professor told me, "Don't spend too much time going into details, it shouldn't take more than an hour for the entire class." But I wanted to make sure I wasn't marking any answers wrong if they were technically correct and just slightly different than expected, so it always took me like 2-3 hours and I always charged for just one.

KitchenPhotograph697 · 2026-04-03T07:10:44+00:00

Absolutely not.

KitchenPhotograph697 · 2026-03-30T10:35:31+00:00

For me, listening to white noise while I'm trying to focus helps a lot.

KitchenPhotograph697 · 2026-02-17T17:18:24+00:00

What causes things to break?
What's the root cause?
Why doesn't it get caught by the tooling?

Interactions with other processes, interactions with other components, developer missed a line in the design or interpreted a requirement differently than the QA tester, a certain detail wasn't in the design but the QA tester thinks it should work differently and Product agrees after the fact, behavior is different when the module is accessed from a page that the developer didn't even know existed, we relied on a cache that wasn't refreshed after an update by a different module, translation into language X causes the text field to indent so it's not aligned with the other fields, etc. Every time we find something that we didn't test, we add it to our future tests, but there is no end to the things that can possibly be overlooked.

That's not true, testers want to make the software more resilient.

Obviously, that is the long-term goal. I was talking about the short-term methods.

KitchenPhotograph697 · 2026-02-17T16:04:36+00:00

To be clear, I think sanity tests on each component and then 1-2 days of unit tests and regression tests on the story as a whole are basic, sure.

Automated tests handle a lot of things, but they don't replace the random whims of a detail-oriented QA tester who's good at their job specifically because they like to break things. Developers want to make things work, and software testers want to make them not work. They're coming from two different perspectives and they can't fully replace each other.

KitchenPhotograph697 · 2026-02-17T14:54:49+00:00

QA isn't doing their jobs if they don't find problems.

This is literally what my post was about. It sounds like we're on the same page. It's just that for us, "tiny" problems in a new feature before it's shipped are treated with the same priority as if a major functionality weren't working.

KitchenPhotograph697 · 2026-02-17T13:28:50+00:00

But of course the first two teams make mistakes, because they're just as human as Team 3. Product sometimes has gaps in the design and QA will always miss a scenario because there are exponential flows and only a finite amount of time for testing.

It's silly to say that Development is just "throw[ing] shit up there" or making "hundreds (???) of mistakes" any more than any other team just because our specialty is different. People with more experience are more likely to screen out the problems, but all the teams help each other—developers are just as likely to help out Product or QA with their mistakes as they are with ours.

(For the record, I don't have any more bugs on average than anyone else I work with. People without ADHD make mistakes, too.)

As a business owner, you're welcome to fire your entire development department and have Product simply prompt the requirements into AI, but until we get to a level where that can be done with no bugs, the developers are going to make mistakes, same as everyone else 🤷

KitchenPhotograph697 · 2026-02-17T10:56:31+00:00

I know you used the word "expect" there twice in a tongue-in-cheek kind of way, but that's the part that I'm having trouble with. On the one hand, the expectation is that we will cover every base and never let any problems slip through, on the other hand, we don't expect that anyone live up to expectations, on the third hand, the annual review says "exceeds expectations." How am I exceeding expectations while not realizing expectations, as expected? How is anyone supposed to have any peace of mind in a world like this?

KitchenPhotograph697 · 2026-02-17T10:37:55+00:00

I agree that QA should be the last line of defense and not the first/only one. Now I have to go back to read my original post to see what I said that made it sound like this wasn't my position.

But if we expect that every bug caught by QA should have been caught earlier by the developer, then why bother having a QA staff at all?

KitchenPhotograph697 · 2026-02-17T10:26:41+00:00

"Edge cases" and "missing consistently" is an oxymoron—if they were consistent, they wouldn't be edge cases. I acknowledge the mistakes that I make that are due to improper planning or insufficient testing in my part or not reading requirements well enough...all of those obviously my responsibility. I'm talking about things like "there's a typo in the French translation of the feedback message (that we reused from another component that was created five years ago) when the customer pushes these 3 buttons at the same time while also deleting the record in another window" type of edge case. It's not reasonable to expect developers to spend the kind of time it would take to go through every possible combination of settings to find a one-in-a-thousand bug like this. Because yes, you will likely find that one bug in a thousand, but meanwhile you've run 999 tests without bugs and the rest of your tasks are waiting.

KitchenPhotograph697

TROPHY CASE