I will always prefer one of these ways of working over the other.

I have an extremely hard time to understand how the other is reasoned about or chosen.

1

2

If you like to work in long lived branches:

Why do you think that your work needs to be able to work in isolation from everyone else’s work?

At the end of the day, it’s one product. Your code needs to work with everyones code.

While you are probably not concerned if you find yourself in a bad merge conflict, you are just as likely to inflict a bad merge conflict on others.

Why are you okay with setting your teammates up like this?

There are ways you can work that doesn’t do this to your teammates.

Would you be willing to learn another way?

I used to work like the following image until I discovered that team flow is more important than everyone being 100% busy. Finishing WIP is more efficient than devs constantly starting new work (and therefore causing more wait states). Working on multiple things “at the same time” is not efficient in any way.

Classic example of resource efficiency over flow efficiency.

Contrary to popular belief, shorter cycle times get more work done.

You can avoid having complicated git setups, rules, when to merge, when to rebase, etc, if you work to get your small commits that don’t break the build into main sooner. Instead of rebasing/merging 25 commits, get your code into main after 1-3 commits. The pain goes away.

Think you can’t work in such small steps?

I think you can. I believe in you if you try.

Adopting TBD, CI, embracing fast feedback cycles, etc isn’t about “going faster”.

It’s about increasing quality, detecting bugs and bad merges sooner, and affording the business the opportunity to pivot easier and sooner. It simplifies the process, increases productivity, and even increases team morale. It’s about lower risk, lower costs, and increasing value.

To think it’s just about speed is to miss the point entirely.

I have worked in a meta-programmed-spaghetti-code mess.

It was all approved via PRs but everyone agreed it’s trash now.

The PR process failed.

No one wants to tell the author it’s crap because “it needs to get out” to meet the OKR and “it works”.

“LGTM ship it.”

52 Easy Manual Steps to Deploying

Once upon a time, I was tasked with removing a link on in our app.

It took almost all day to get this done. Ridiculous! I wrote it out to visualize it. I wanted to see the context switching necessary so I added which app or webpage you have to be in to complete that step.

It took 52 steps to delete a link and get it into production.

A link…

52 steps…

52 easy steps…

The 8th step was where the link was removed. This is the only step that involved editing code.

Every step after it was what it took to get it out the door, updating jira tickets, updating teams on slack, etc.

How much money does this place have??