I'm working with a bunch of people who occasionally start new Golang projects that are eventually maintained the just about the whole group. Everybody has their

I'm working with a bunch of people who occasionally start new Golang projects that are eventually maintained the just about the whole group. Everybody has their own idiosyncratic ways of setting up their new projects, so every time I switch to working on another project I have to spend some of my cognitive capacity figuring out and remembering what the natural way to nest directories, name config files, wire up build/deployment scripts etc was for this particular project. It's not the end of the world, but I think the effort required outweighs the benefit of natural growth, and any arbitrary, ill-fitting consistency is preferable to no consistency. imo, at some point, the worn-out "cattle, not pets" mantra applies to codebases too, not just infrastructure. So, I don't have any extremely strong opinions on project layout and if all of the unimportant decisions are already made for me, all the better. That said, I would never want to tell anyone "you must blindly follow this one particular structure". Rules are meant to be thoughtfully broken.