Alternatively, build a team with a mix. Sometimes having a person passionate about process can be very helpful when they have a little tension with the pioneer types.
They drove me a little crazy, but one of the best people I ever worked with was a “test enthusiast” and believed that anything not automated was going to eventually cause us trouble.
It was good friction and made one helluva a system that managed to serve a couple hundred thousand remote clients while basically on autopilot for several years now.
For sure. It means you actually have to be intentional about what you test. Best team I ever worked on had two loud, friendly, utterly opposite engineers when it came to excellence vs velocity. But it made us really talk through why we chose the things we did.
A team with a mix is best if it's not a mix just in terms of personnels but in projects and the way incentives are structured.
The culture within the team can go south sooner than one realizes if the 'process' types feel they're constantly cleaning up the mess of pioneers (who tend to get more attention in general for their shinny projects). And on the other hand the pioneers may perceive process-types folks resist any new changes and are stuck supporting outdated technology. The truth usually lies somewhere in the middle.
I've found this to work extremely well. I tend to err on the side of caution, building well tested systems with carefully planned failure modes. I work very well with people who drive hard and spit out a ton of rapid prototype code that's full of bugs. It's frustrating, and there's often tension. But the end result is the best of both worlds.
Maybe don't, they keep the world from falling apart at its duct-taped seams.
You aren't giving us enough context to know whether that changelog requirement is a good one or not. But if your team has agreed on the process, either convince them to change the process, or try to understand why your (hopefully reasonable and competent) colleagues believe it's necessary.
> what if your team is dominated by process people.
If that's not your jam, consider a new job.
> only explanation that everyone agreed to was that "it makes it easier to see what changed"
Maybe it's safety critical software or there are downstream clients? Maybe it's open source? Maybe it's not actually every PR and we have an unreliable narrator? The post did start with "I hate process people", after all.
For what it's worth, I'm notoriously not a process person. But I've seen and respect stability they can bring to a team and product
fwiw way back i used not see the point of changelogs, but after experiencing what it's like to consume a lib or use software without one, also how useful they can be when you need to know what's changed, it i've changed my view on them.
