A brief hiatus

Putting this newsletter on "pause" for at least a few weeks while I ramp up on a new job -- plus, the problem with Github, and why the best engineers I've worked with were the impatient ones

A brief hiatus
Photo by Nik / Unsplash

Hey there! You're reading Simpler Machines, a (usually) weekly letter about software development. I'm Nat Bennett – and this might be the last you hear from me for a few weeks, because I'm taking on some full time work. I usually at least pause my weekly newsletters while I'm ramping up at a new job.

To continue to get a letter from me monthly, log into the website and set yourself to receive "Mere Being" e-mails.

A Ghost e-mail preferences page showing Simpler Machines, Good Rectangles, Mere Being, and Comments

"Good Rectangles" is still technically un-launched but it might start up before Simpler Machines does, because it'll be a way for me to take a break from software for a bit – that'll be a single photograph per week when it starts going out.

In the meantime I've got a few links to share.

This essay on Github and the dangers of its dominance has been on my mind a lot since I read it in May.

Edward Loveall

Let's Make Sure Github Doesn't Become the only Option

There are a bunch of reasons to be concerned about the current dominance of Github in source control. A lot of them would be in play no matter what the software actually did – public companies with dominance over platforms eventually and inevitably end up degrading those platforms as they switch from "build value" to "extract value."

But I think Github in particular is a problem. PRs are as dominant as they are in our industry not because they're actually the best way available but because that's the direction that Github pushes teams. If you set up a new repository Github will nag you to make the main branch "protected," so you can't 😱 commit directly to main.

The software is actively hostile to trunk-based development.

Fossil: Home

An alternative source control system using (and developed for) SQLite

I, of course, still use Github exclusively, both professionally and for hobby projects. One alternative is to use another source control system entirely. Fossil has been on my to-do list for a bit but I haven't gotten around to it. If you've used it I'd love to hear from you – maybe it'll inspire me to actually take the time to check it out myself.

Fast, simple code review | Graphite
Graphite is modern code review for fast-moving teams - we help engineers write and review smaller pull requests, stay unblocked, and ship faster.

An alternative to Github's PR review interface

Another alternative is to use what're called "stacked" pull requests. This is apparently how companies like Facebook deal with some of the problems introduced by PRs, and "write and review smaller pull requests" is certainly compelling to me. This particular tool claims to be usable even if no one else on your team has adopted it, so I may be able to take this one for a spin sometime in the next few weeks.

Notes on structured concurrency, or: Go statement considered harmful β€” njs blog

A history of control flow in programming languages

I'm not sure if I really agree with the thesis here but that's not the important part – this is a great overview of the history of control flow in programming languages, going all the way back to assembler, and some context on exactly why "goto" was such a pain to deal with back in the day.

Curiosity and Impatience | DWF’s Journal
Some years ago, during a particularly complex client engagement, we got thrown a curveball. The team was about 10 developers, cranking on a greenfield project. We were a few months in and despite a rocky start, were feeling pretty productive. CI stayed green, we had code in Production, and we were…

An essay on the importance of impatience in software development

Finally – if you want your Pivotal stories fix while I'm on hiatus, go check out Davis Frank's journal. His latest story describes one of the more surprising differences between Pivots and more "typical" software engineers – good Pivots had a much lower tolerance for friction or waiting than most engineers I've worked with, and were much more inclined to prioritize work to speed up slow or tedious tasks. This pays off a lot faster than most people think.