My work uses python and it hasn’t been bad for new code that has tests and types. Old code we inherited from contractors and “yolo startup” types is less good, but we’ve generally be improving that as we touch it.

I get a small amount of joy from clicking the “request changes” button and blocking some doofus from merging lazy untested code.

That doesn’t address the opportunity cost. Spending time on this means not spending time on something else. There are other optional things and user choices they could work on instead. This is always the case when doing anything, but AI is very far down the list of things I think are worth paying the costs for.

Opportunity cost

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 think a lot of people are kind of bad at written communication. It’s not an easy skill.

Often at work folks will write twice as many words and clauses as needed. The Hemingway editor ( https://hemingwayapp.com/ ) isn’t perfect, but I recommend they take a look at it.

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

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?