// Dude, just merge the template

How many times have you thought to yourself, God I’d love more process, I’d absolutely kill for more gatekeeping and more things in my way before I can write this code? How many times have you raised your hand in a meeting to put a ticket in blocked because of some minuscule, ridiculous reason that isn’t even an issue - let alone a blocker? How many times have you “taken the day to gain context” only to sit and write personal documentation, on a private note space, about how you feel about a certain section of your codebase? How many times have you had a two point ticket for a month because you want to make sure you can recite every single character of code you’ve written for it by memory?

Yeah I’m going to go ahead and say never. Unfortunately I’ve worked with this person, this is something I’ve encountered in the wild and it’s all absolute truth. The final straw for the team we were both on at the time was a template file. A simple file that lays out how something should be structured within a specific part of a specific third party app.

Ask yourself a question. Would you just write the template, maybe ask a quick couple of questions to the team on Slack and get some opinions, and then push up the 1 point ticket and move it to done within a couple of hours? I would, my team would. Except this person.

The timeline.

Week one, day one. The ticket was picked up, twelve million questions about the template were asked during standup. Day two, the stand up update was that they were taking the day to analyse the codebase to gain a full understanding of how the template should look. Day three, yesterday didn’t happen fast enough so a second day analysing the codebase was done. Day four, an hour long meeting was put in the team’s calendars to discuss potential criteria for said template. Day five was taken as PD time to learn how to properly structure template files and understand how the industry typically uses them.

Week two, day one. The standup update was that a fundamental understanding was not garnered so another meeting was to be placed in the team’s calendar to discuss potential criteria - again. Day two and three were knowledge gathering - huddles, slack conversations, product input requested, other teams within the business consulted. Day four, work began on the template file. Day five, more PD time to tackle the same thing as last week.

Week three and four were code writing weeks. The same update every day. “I’m writing the template file” with the final day an MR being up for review, and a huge document written up for the entire team to go over.

A month, to write a template file. The MR was over engineered. The template suggested was bloated, full of irrelevant checks and far too over the top. It was rejected, and the ticket was moved to blocked for the simple reason of “we need more meetings to discuss how we should approach the template”.

Guess what though, that wasn’t good enough for the team. So someone else picked up the ticket, asked me and two of my colleagues for input, we said our piece and the template was written and merged within a couple of hours. The dev that spent a month on process was frustrated. From their perspective, the process hadn’t been followed. From ours, there was no process to follow — we just got it done.

Process is part of our everyday workflow, we have to follow it to some extent, but as devs we typically hate it and will get around it anyway we can, or at least deal with the bare minimum. We just want to solve problems and write code. So why was process so engrained into this dev?

They needed every aspect of every piece of work to be fully discussed, fully planned and refined. Documentation, sign off, absolute context. For every single ticket, for every single task.

And look, I get it. That need for certainty isn’t malicious, it’s just a different relationship with ambiguity than most devs have. The problem is, software development is ambiguous by nature. Requirements change, context flips, and dude, sometimes you just need to merge the template file. The devs that are comfortable with that uncertainty, the ones who can get stuck in, iterate over crap, and course correct, are the ones that move fast. Process has its place, of course. But it shouldn’t be a comfort blanket.