Maybe you don't need React – Rediscovering the Vanilla DOM
Stacked branches with vanilla Git
The first rule of stacked branches1 is don’t use stacked branches:
- Make small changes
- Work closely with your teammates to get the changes merged quickly
- Profit
Alright, so you didn’t take the advice. Maybe you are making a big change that has to be worked as one big change, but you want to slice off pieces for reviewability. Maybe your teammates are slow to review your changes. So you put your first branch up for review, then you create a second branch off the first branch to keep working, then–if you’re a glutton for punishment–you create a third branch off your second branch, and so on.
Anyone who has set up stacked branches knows what a pain it can be to manage. The initial setup is easy. The problem comes when there is a merge conflict between your stack and the main branch. Or what happens when you need to pull in a change that got merged to main.
If you haven’t been keeping up with new Git features, your workflow probably involves a lot of git checkouts,2 lots of git rebase commands, maybe commit counting like HEAD~123, or cherry-picks or who knows what other tedious work. Even after all that you probably missed something and now one of your PRs shows a bunch of duplicate commits.
It is 2023. There is a better way.
Don’t change incrementally what can be done across-the-board
How do you eat an elephant?
In a living, evolving codebase inevitably changes will come up that you want to make everywhere. Maybe you discovered a better pattern that you want to apply throughout the codebase. Maybe entropy has caught up and some tedious change needs to be made everywhere.
In small codebases you just make the change when it comes up. Even in larger projects, sometimes there is no choice–the project won’t build without biting the bullet–and so you end up making the change. More commonly though, you make the change in the files you touch and hope there is time to come back later to fix up other places.1
Such is the reality of programming for a business.
The thing is… what if making the across-the-board change didn’t have to be a manual, time-consuming task? We’re programmers after all! Automation is what we do.
Mise en Place for Software Engineers
You know how in cooking shows they have all the bowls full of ingredients in front of them, ready to go so that when they start cooking there is no risk of something not being ready at a critical moment? There is a cooking term for that, mise en place, which roughly translates to “putting in place”.1 It’s not just for TV either. Mise en place is taught to and practiced by professional chefs, because upfront preparation2 prevents costly mistakes later.
BTW it is pronounced like MEEZ ahn PLAHSS (ah = the “a” in father).
Team vibe and the goldilocks zone
Everyone likes to make a difference at work. To see your effort move the needle. Not everyone, however, is keen on the all-in commitment this mindset often leads to. 50+ hour work weeks. Crunch time.
At the other extreme, some prefer a uniformly steady workstream. Work must be kept predictable so that brain power is reserved for all the other things in life. Not all can stomach the trade-off this takes though. Order is typically achieved by carving out fiefdoms–often at odds with the goals of the wider org–and the work becomes largely meaningless.