So, here's my contrarian take on Why Trunk-Based Development Is Great But Probably Won't Work For You. Buckle up, it's a long one.

From time to time I talk about, or boost someone else's discussion of, "classical" continuous integration/trunk-based development/push-to-master/whatever. I do this because I've personally worked like this and I genuinely think it's a marvelous way to write software.
I've also, at this point in my career, failed—a bunch of times!—to bring this technique into practical use on the teams and organizations I've worked with. As a result, while I still do it myself, I don't focus as much on encouraging it in others.
The technoculture that's presently in vogue is what I think of as async/individual—optimize for the individual, performance-manage the individual, decouple the individual from others so they can be their best, most productive, most heroic selves.
This is in contrast to what I think of as sync/team—a culture that leans into interdependence and collaboration. If you've never worked on a team that collaborates very closely every day for months or years on end (and likes it) you've likely not experienced a team like this.
There are a bunch of reasons why this technique failed to gain broader traction, but briefly (1) difficult to achieve (high-collab work was never very popular) (2) tooling has closed the gap between good async and great sync teams (3) dual pressures of COVID + tech salaries.
Before I go further, the technique I'm describing involves devs working in pairs or mobs, pushing small atomic commits directly to the main branch, and those commits being deployed more or less immediately—in contrast to individuals working in branches.
What makes it difficult? It requires new skills, technical process changes, and organizational buy-in. These tend to be difficult to roll out all together. In no particular order:
Pairing + review discipline, which includes:
* pairing skills
* schedules built around pairing
* atomic commit practices
Cycle time discpline, which includes:
* sync work over async work
* WIP limits
* adequate feedback loops
* "just in time" planning
Build discipline, which includes:
* local pre-commit builds
* fast builds
* reliable builds
* trustworthy test coverage
* keep-it-green practice + rapid rollbacks
CD & observability discipline, which includes:
* robust feature toggles
* robust observability
* rapid deploys
* robust continuous deployment model
And finally, it almost goes without saying, but: Trust and courage, which includes:
* A mutual-support & learning culture
* Trust in others
* Rapid failure recovery
* Openness to risk-taking in approach
One could meaningfully write a book about each of of these. Indeed, many such books exist.
These disciplines require, at best, hands-on upskilling from disciplined practitioners to get right, and that's if—IF!—your team is bought in. More likely you're swimming upstream against a bunch of contemporary trends—most notably, the move to more async work.
At worst you're looking at months or years of work to get them right, all the while dangling out on a limb and trying to make a case to the organization that it'll be worth it—someday.
Conversely, many of these disciplines aren't necessary or interesting in an async/individual work culture. Once you've decided to make your builds async, you tend not to feel as much immediate pain if they're flakey or slow.
And who cares if a build runs locally? Who's hacking on a plane these days anyway, with or without onboard wifi?
Even if you decide to become an advocate for these (significant) changes, you may ultimately find that this was never the bottleneck worth optimizing for—that the problem lay in product or leadership or finance or a half-dozen other places.
So let's say you want to do it after all. How do you achieve it?
1. For an existing team, it has to come from within but it's probably not going to arise spontaneously—i.e. you're not going to retro your way into doing it. It requires either an internal champion to take a risk, or an external hire with chops, or both.
2. It's unlikely to happen without practical hands-on experience doing it. So, a hire (again) or a coach. This is where management/leadership fiat has failed for me personally.
3. It has to demonstrate real improvements over the alternative—from a sustainability, velocity, and happiness standpoint—or it'll decay. Doing it takes discipline, and discipline is hard to sustain.
4. It requires, at minimum, buy-in from leadership up the chain, particularly in environments with a lot of interdependence—monoliths or monorepos, which will also often share a common method of change management.
5. It requires settling clear expectations with new hires: that you're a pairing culture, that you're a courage culture, that they'll be expected to try things that may feel uncomfortable. If you don't set expectations up front, that discomfort may turn into attrition.
6. Tighter upfront expectations will likely narrow your hiring funnel, which your recruiters may be uncomfortable with.
Lots more to write about this, but that's me for today.
It almost goes without saying, I think I implied but omitted it above: pairing remotely is hard. Tight collaboration is much easier when you're colocated.
Also, to be clear: please understand this thread to be an attempt to understand + explain my own failures in leading through this change and its implications, and not of any other person or team I've worked with.
To be clear, I say this not out of some kind of normative judgment but because I think there simply aren't many teams that work like this. There are also plenty of people who've worked on teams like this but disliked it, and I respect that.

More from For later read

Excited we finally have a draft of this paper, which attempts to provide a 'unifying theory' of the long economic divergence between the Middle East & Western Europe

As we see it, there are 3 recent theories that hit on important aspects of the divergence...


One set of theories focus on the legitimating power of Islam (Rubin, @prof_ahmetkuru, Platteau). This gave religious clerics greater power, which pulled political resources away form those encouraging economic development

But these theories leave some questions unanswered...

Religious legitimacy is only effective if people
care what religious authorities dictate. Given the economic consequences, why do people remain religious, and thereby render religious legitimacy effective? Is religiosity a cause or a consequence of institutional arrangements?


Another set of theories focus on the religious proscriptions of Islam, particular those associated with Islamic law (@timurkuran). These laws were appropriate for the setting they formed but had unforeseeable consequences and failed to change as economic circumstances changed


There are unaddressed questions here, too

Muslim rulers must have understood that Islamic law carried proscriptions that hampered economic development. Why, then, did they continue to use Islamic institutions (like courts) that promoted inefficiencies?


You May Also Like

1. Project 1742 (EcoHealth/DTRA)
Risks of bat-borne zoonotic diseases in Western Asia

Duration: 24/10/2018-23 /10/2019

Funding: $71,500

2. Bat Virus Database
Access to the database is limited only to those scientists participating in our ‘Bats and Coronaviruses’ project
Our intention is to eventually open up this database to the larger scientific community

3. EcoHealth Alliance & DTRA Asking for Trouble
One Health research project focused on characterizing bat diversity, bat coronavirus diversity and the risk of bat-borne zoonotic disease emergence in the region.

4. Phelps, Olival, Epstein, Karesh - EcoHealth/DTRA

5, Methods and Expected Outcomes
(Unexpected Outcome = New Coronavirus Pandemic)
“We don’t negotiate salaries” is a negotiation tactic.

Always. No, your company is not an exception.

A tactic I don’t appreciate at all because of how unfairly it penalizes low-leverage, junior employees, and those loyal enough not to question it, but that’s negotiation for you after all. Weaponized information asymmetry.

Listen to Aditya

And by the way, you should never be worried that an offer would be withdrawn if you politely negotiate.

I have seen this happen *extremely* rarely, mostly to women, and anyway is a giant red flag. It suggests you probably didn’t want to work there.

You wish there was no negotiating so it would all be more fair? I feel you, but it’s not happening.

Instead, negotiate hard, use your privilege, and then go and share numbers with your underrepresented and underpaid colleagues. […]