Hello friends! It’s June and I’m tired. My boys have baseball four nights and it’s peak camping season, lots has been happening. But, I’ve still managed to come up with a list of reads. Let’s jump into some links.
1. The peril of laziness lost (6 mins)
Software problems are complex and can take a while to fully fit into our heads. LLMs make it too easy for us to deliver code based on shallow understanding. So how do we balance? Bryan Cantrill (CTO at Oxide) suggests leaning into workflows that work with programmer laziness. Things like promoting engineering rigor, a talk I highly recommend checking out
2. Laws of Software Engineering
This one is less of a quick read and more of a great bookmark to digest over time. It’s a beautiful site that lists 56 different laws of Software Engineering. Each page gives quick takeaways, examples, and even links to further readings. The further readings include books and pivotal blog posts. Dr Milan Milanović (CTO at 3MD) has done an impeccable job curating all of this information.
3. Drunk Post: Things I’ve Learned as a Senior Engineer (23 mins)
This is a substack post quoting a drunk post from /r/ExperiencedDevs on Reddit. I found the substack a bit easier to read, but you can view the original thread as well. A user named flipstables gives a long bullet list of honest truths about life as a Senior Engineer. As you can imagine, it gets a bit messy, but it does hit on some good points. Definitely caught myself nodding along with this one.
4. What Async Promised and What it Delivered — Causality (18 mins)
This was an absolutely fascinating read as part of a series named The Concurrency Problem. It goes over the concept of callbacks, the introduction of Promises and Futures, and ends on summarizing Async/Await. Josh Segall (TPM at Google) gives a great summary of how these all fit together and suggestions on what can be improved. He also posts describing actors in erlang and channels in go that are worth a read. You will have a solid understanding of the concurrency landscape after reading all three articles.
5. Stop Using Pull Requests (20 mins)
Obviously we can’t stop using pull requests altogether, but that wouldn’t get as many clicks. The author (Andrea Laforgia) instead suggests that we should take a look at some ways to optimize pull requests. I enjoyed this post’s suggestions: trunk-based development, Test-Driven Development, and Team-focused Development. The main point is small, methodical changes are more efficient than huge long-lived branches. I’ve always disliked long-lived branches, but that’s a rant for another day.
Semi-related to the link above, maybe our tech for managing code changes could use an upgrade.
Over my career I’ve given multiple presentations to my teams on the tradeoffs of different git workflows.
Bill Jings gives an articulate explanation of Git’s rough spots when it comes to managing commits.
He suggests giving Jujutsu (aka jj) a shot.
I’ve since swapped over to using jj and have to say that I’m loving it.
My only complaint is that I’ve used jj as a vim shortcut for <esc> for years so typing it out in my editor is annoying.
Maybe it’s time to update my workflow.