I really dislike calver for like libraries and apis. For something like Firefox it doesn’t matter as much. But for a library? I want to know if this version has breaking changes.

This is what I always say. Put the tickets in order and we’ll do them.

Management always pushes back.

Yeah I don’t think this covers externalized costs

I am going to get a lot of use out of that URL.

I’ve been telling people they need to put a dollar in the jar when they do that, but I haven’t actually been enforcing it.

I know pre 1.x.x is kind of a wild west for versioning but uh is there any logic to the version numbers here? I’d think a new feature would be a minor version bump, not patch

I understood that reference

They should probably limit how many swipes you get instead of having your swipes go into the void.

I’ve done a lot of “then go get approval from the stakeholder to go ahead with this bug/problem”.

If product wants it out now now now they can sign off on it not working on mobile, so when their boss has a fit about it I can point to the conversation where Ryan said it was fine.

I’ve mostly worked at smaller companies though.

I was a full time test engineer / QA person for a while. My motto quickly became “nothing ever works”.

Pretty much any ticket behind a static copy change would have some problem or oversight. Sometimes even those would (did you account for very narrow view ports?)

Good developers would take this feedback gracefully. “Shit, you’re right, I need to account for mobile users.”

Bad developers would get defensive and upset. “We barely have any mobile users (me: did you check?). Alan already approved so I’m merging. I don’t want to waste time on this”

I worked at a place where all the DB column names were like id_user, id_project. I hated it.

It’s strangely satisfying when the “this will probably never happen” test case finds a problem during development.

I had tests for deleting that were like

• create item a
• create item b
• delete item a via the code under test
• assert item a is gone
• assert item b is still there

I thought maybe the whole bit with item b was excessive, but sure enough one day I accidentally fucked something up and deleted all the items, and the test pointed it out before the bad code left my local machine.

From what I’ve read, there are a few things that change people’s beliefs. Fact is not one of them. What your in-group believes is a big factor. So if we could murder fox news, we’d probably do the world a lot of good.

But the other thing that apparently can push people into reevaluating their beliefs? Horrific, personal, trauma. Someone who’s whole town was destroyed by climate change might be shaken up enough to rethink their world view. Maybe.

You could also maybe trigger the effect by beating the living shit out of a climate change denier, because being dragged out of their coal-rolling truck and being beaten so badly they’ll never walk again would be traumatic.

Well this is garbage.

I mostly work in Python, but we use types at work. For a hack day project I skipped typing stuff for like an hour, and then went “wait this sucks” and added types. It was easier overall.

Here there’s main. You branch off. Do your work. Make a PR to main. Build passes and someone approves, merge to main. Production release is done by tagging main.

The branches are short lived because the units of work we select are small. You have like one pr for an endpoint. You don’t wait until the entire feature with 20 endpoints is ready to merge.

Seems to work fine. I think this is different than trunk based development but honestly I’m not sure I understand trunk.

In real life? I’m not sure. Years of struggle to change government to enforce regulations, break up consolidation of power, blah blah blah.

In a like ttrpg or movie? Murder. Murder the board and other management and anyone they replace until the greed stops.

Maybe it’s part of an elaborate vampire hunting scheme. It seems like something idiot PCs would do in a role playing game, and the protagonists of “What We Do In the Shadows” would fall for.

It’s frustrating because it’s all done by people. Like if a volcano erupts you can’t really get mad at it. It’s just physics stuff. But all of this? People are making these choices. People made of meat and bone. Like, you could find the decision makers at Google who decided to shit up their product and kick them in the junk.

Kind of off topic but some people are really bad at writing jira tickets.

“Show the user a list of projects [eof]”

Ok but like, only their projects, right? Do they need to be ordered? Searchable? Paginated? Only active ones or soft deleted ones, too? Do you just need the name or do you need metadata too?

Somehow product doesn’t love my stance of “if it’s not on the ticket or in a sop, the behavior is undefined and you get what you get” stance.

i never tried it, but i like the idea of https://github.com/nvbn/thefuck for fixing mistakes in the terminal