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
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.
"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.
Github considered harmful? And other links
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.
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.
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.
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.
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.
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.