Probably pull justices from the lower courts at random to hear individual cases. Much harder to bribe all the judges than like two well known supreme Court justices.

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.

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.

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.

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

The python code we inherited had some performance issues. One of the guys was like “we should rewrite this in Java”.

Luckily the boss was not an insane person and shut that down. The issue was an entirely stupid “…and then we do one query per project” behavior that worked fine when the company was small but unsurprisingly started to suck as users created more projects.

Instead of a months long complete rewrite, we had a two hour “let’s add profiling… Oh wow that’s a lot of queries” session.

I don’t want to see a dozen commits of “ran isort” “forgot to commit this file lol” quality.

Do you?

Having the finished feature bundled into one commit is nice. I wouldn’t call it stupid at all.

There’s two options in the green button on a pr. One is squash and merge, the other is squash and rebase.

Squashing makes one commit out of many. You should IMO always do this when putting your work on a shared branch

Rebase takes your commit(s) and sticks them on the end.

Merge does something else I don’t understand as well, and makes a merge commit.

Also there was an earthquake in NYC when I was writing this. We may have angered the gods.

…and? You squash so all your gross “isort” “forgot to commit this file” “WIP but I’m getting lunch” commits can be cleaned up into a single “Add endpoint to allow users to set their blah blah” comment with a nice extended description.

You then rebase so you have a nice linear history with no weird merge commits hanging around.

Do not merge your unfinished stuff into main.

I don’t like merging main into my branch because I don’t understand git, and I feel like that can make a confusing history.

I used to only merge. Now I rebase. The repo is set up to require squash and rebase when going to main.

All the garbage “spelled thing wrong” and “ran formatter” commits go away. Main is clean and linear.

Squash your branch first

I think it’s definitely a thing most people grow out of when they gain experience.

My boss told me about how when he was new he rewrote a whole chunk of the front end. His boss gave him a talking to about how you can’t just go and do that when you’re working with a team.

At an old job I just opened a PR to apply a code formatter to an internal project I wasn’t even a routine contributor to. PR was rejected and I learned a valuable lesson about talking and getting buy-in before making sweeping changes.

You should have an agreed upon format that is enforced by cicd. Prettier, black, whatever.

Which one of you loose cannons down voted this?

Did I already post in here about how he wrote a custom DSL instead of using the standard widely used ORM we use everywhere? Maintainability nightmare.

He doesn’t work here anymore and now I have to either figure it out or rip it out. So far it looks like “rip it out” because it took less than an hour to swap in the orm, and now there’s just a lot less code needed.

It could be!

But part of working as a professional on a team is communicating and achieving consensus. Just trying to make a change like that out of the blue is poor form.

Also consider the opportunity cost: we had planned on getting XYZ done this week, and instead he spent a few hours on this and dragged a few people into a “do we want to change to poetry right now?” conversation

This guy was also difficult to argue with. He was always professional, which I guess is worth something.

One time he tried to remove all the types from a bunch of code “because they were all going to change later.” I refused to allow this. We went back and forth in the comments for hours. I think eventually the lead or boss got involved. Thankfully people sided with me.

His “later” project that was allegedly going to change all the things was rejected by the team. The code in question is still used and properly typed a year later.

There was a guy I worked with that tended to want to unilaterally make sweeping changes.

Like, “we need the user to be able to enter their location” -> “cool. Done. I also switched the dependency manager from pip to poetry”.

Only a little bit of exaggeration