Working in organizations housing multiple teams, all contributing to the same code repositories, is something that we all likely will be a part of your career. In workplaces like this collaboration is what can make or break an organization. As an engineer, you’ll probably be thinking of course, properly timed commits and pulling from the master/main branch consistently ensures your code can be merged in a timely manner. Right?
Well, it gets much deeper than that. Having a solid shared process is what makes all this possible. When you don’t, those are the applications and platforms we view as unreliable and never have faith when a new version is released. With all that said, let’s take a more in-depth look at the ways the process is powerful.
Collaboration starts before code is written, and ends much after a PR is merged in. The process starts in the planning phase, continues in the implementation phase, strides through verification, and ends with the release. Throughout all of that, a well outlined and mutually used process is what keeps everything flowing smoothly.
In the beginning, proper planning and scoping create a proper matrix of tickets and testing instructions associated with the task, PR, and reviews ensure things are being built to spec before merging, and verification identifies if everything is good to go or there is something missing. That, in itself, is quality assurance.
Keeps Everyone On The Same Page
Working in teams is a mixed bag, and expectations are much higher than they should be. Think about it. For the most part, anywhere you work, your team is mostly a random assortment of people with no connection outside of employment. So it’s too idealistic to think that all these people of free will can come together harmoniously on their own.
The proper process brings them together and removes the majority of the individualism that tends to break everyone from being on the same page. Think about it. How much time is wasted in review cycles and verification alone just from people thinking individually instead of in the scheme of the bigger picture? In my experience, a lot!
A process is a cure for this.
Settles Disagreements and Misunderstandings
Engineering is a prideful profession, filled with people trying to validate their thinking. With that, you can expect to see theoretical conversations and/or extreme edge cases lead into rabbit hole conversations. Unfortunately, of course, that’s on the nicer side as well. It does get much worse.
Well, with proper process acting as a reference point, it can settle most of these rabbit hole conversations early. Think about grooming a task and assigning story points. Using Fibonacci numbers, you think something is a 2 and someone else thinks it’s a 5. You both present your thoughts, neither budges, a proper process for assigning story points would say either meet in the middle or go with the higher. Some cases even break the known into its own task and the unknown into its own spike.
Nobody is hurt, mostly, and everyone can move on faster than they would otherwise.
All these points are more so surface-level benefits of having a process. While not the most in-depth they show how much time can be saved just by discussing them. So if you’re a growing young team, or a more mature team wasting a lot of time, take a step back and write out that process. Save some hours in the day, maybe improve retention even, and make work-life a bit better.