This article is a wild premise, a wild ride and a wild conclusion (also I’m increasingly warming to the idea of htmx).

“Every cloud-pilled, react-vue-braindead, click-to-deploy developer actually thinks web views require 7 minutes to “compile for production,” then when live require 5-15 second “skeleton loaders” on entry is just a fact of life nobody can question or ever improve on modern 5 GHz machines with 5 Gbps network connections. Developers, at the median, have been getting less capable and more focused on made up silo/cult/trendy dead-end fads for 10 years and the entire world suffers daily.”

Notion has formulas now (!) and here’s a formula to calculate a Cost of Delay column based on two other columns:

if(Value=="Killer" && Urgency=="ASAP", "1 Very High", if(Value=="Killer" && Urgency=="Soon" || Value=="Bonus" && Urgency == "ASAP", "2 High", if(Value=="Killer"&&Urgency=="Whenever"||Value=="Bonus"&&Urgency=="Soon"||Value=="Meh"&&Urgency=="ASAP", "3 Medium", if(Value=="Bonus"&&Urgency=="Whenever"||Value=="Meh"&&Urgency=="Soon", "4 Low", "5 Very Low"))))

“Squashing destroys this information. I’ll take a merge with 1000 +50/-50 commits over 1 squash every. single. day.”

I’ve been hammering on this fact as well that it’s silly to use git and then throw away so much information that you could use later. But then again most people don’t know git bisect exists.

I get asked pretty regularly what my opinion is on merge commits vs rebasing vs squashing. I’ve typed up this response so many times that I’ve decided to just put it in a gist so I can reference it whenever it comes up again.

I use merge, squash, rebase all situationally. I believe they all have their merits but their usage depends on the context. I think anyone who says any particular strategy is the right answer 100% of the time is wrong, but I think there is considerable acceptable leeway in when you use each. What follows is my personal and professional opinion:

I prefer merge and creating a merge commit because I think it best represents true history. You can see the merge point, you can see all the WIP commits the developer went through. You can revert the whole merge easily (git revert -mN ). I create merge commits more than 9 out of every 10 PRs.

I also believe having more commits makes git bisect better, as long as every commit builds. I hate hate hate when I bisect a project only to land on a single squashed commit from a single PR that is like +2000/-500. That is… not helpful at all. I want to bisect and land on a commit thats at worst like +500/-500. At worst. Ideally I land on a commit thats more like +50/-50. Then I can say “ah hah,the bug is there.” Squashing destroys this information. I’ll take a merge with 1000 +50/-50 commits over 1 squash every. single. day.

This strategy depends on good hygiene by the developer keeping every commit building. I follow this rule 99% of the time (I make mistakes, but I try very hard not to). In OSS, you can’t really control this and I’ll sometimes end up fixing up commits for people (using interactive rebase prior to making a merge commit). In a professional environment when I was an engineering leader, I would generally expect engineers I worked with to keep every commit buildable.

I do squash though when a PR has a bajillion tiny “WIP” “WIP” “WIP” commits but is really aiming towards one goal with a relatively small diff. That’s my squash use case. I’m careful when squashing to rewrite the commit message so it is descriptive. The default squash commit message created by Git and GitHub is not good (it just concatenates all the squashed commit messages, usually a series of “WIP”).

If you have a big diff AND a lot of “WIP”, then I rebase (interactively), and selectively squash and reorder commits where it makes sense. I tend to expect developers to do this and care about their commit hygiene, but unfortunately a lot of developers aren’t that comfortable with Git. In the OSS world, I do it for them. When I was an engineering manager back in the day, I’d expect engineers I worked with to have this knowledge.

On this last point, I also tend to use a Git GUI client for large interactive rebases. I’m extremely comfortable with the Git CLI but when I’m interactively rebasing a very large PR (say, 50+ commits) with a large number of changed lines, I find using a GUI to be helpful. I’m on macOS so I use Tower. This is the only situation I actually use a GUI, though.

Last week I was making a presentation and I came across Deming and his principles. I have often gotten the question: “If you don’t measure X, then how will you know we’re doing well or improving?” which I always felt was misguided.

It turns out that Deming was way ahead of me there, he says: “Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership.”

Leadership is always the key.

As much as it pains me, I’m teaching myself Helix and trying out the Jetbrains IDEs. Code has been the first editor that really clicked for me but as with all free things, there’s a hidden price to pay for it.

(Also the quality of VS Code seems to be going downhill. At some point if they keep developing software past completion, the software becomes crap.)