This piece about moving away from CDK is a bit overly dramatic and comes down to “CloudFormation sucks” which is something that anybody who’s worked with it can testify to.

That said if you’re committed to AWS as your cloud provider, CDK is an amazing piece of technology that bridges the worlds of infrastructure operations and programming.

If the concept of bridged terraform providers for pulumi is something that proves itself, that of course would be great, but I’d say it’s still pretty uncertain.

It’s much healthier for Germany if digital issues have an answer that goes beyond “Let’s see what the CCC has to say!” The CCC is a shady organization which is good at taking things apart but does not have that much constructive to offer.

A broader social discussion would reveal that security and privacy are not the only two dimensions on which digital solutions can or should be measured.

Late to the party but I very much love this interview with Karri Saarinen, the co-founder of Linear. Their way of working, “The Linear Method”, will be waved away by companies (“we can’t do that because…”) but with leadership with the right mentality and experience I don’t think it’s that far off at all. Ask your leadership how you can work like this.

Also I already know I’m going to use the term “side quest” a lot.

We don’t use Linear but we recently moved all our stuff from Jira to Github Projects which—even though it is mostly abandoned—is Linear-enough.

Most importantly, it is right on top of our codebase which is where I believe all engineering work should happen anyway.

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.