- What abstractions to use and why, how to design them
- Common patterns and solutions, what to use and what to avoid
- What test at what level and why
- How to structure code in files/libraries/packages
- How to contribute and review changes
- How to document code
- ...
A bit about a problem I want to solve: From a team of 5-7 people we grew to several distributed teams and have newcomers from various backgrounds (c#, python, go, while we mainly write in typescript). What I see more and more is that each team or even each employee solves problems differently, using different abstractions etc. (and it is easy to do because we have microservice-ish architecture) - because there is no more shared approach. Frequently, when I contribute to other people code I have to spend time just to understand what's happening, how code is laid out and why (too often it is just personal preference). I imagine other employees have the same problems too, and it affects overall effectiveness - a lot of time wasted on unnecessary cognitive load.
It seems like engineering guidelines, if composed carefully, would help solve at least some of these problems.
All of that is necessary cognitive load.
It's hard, and that's why you get paid.
Maybe not enough, but that's a different matter.
Anyway, there needs to be a business case for creating, distributing and enforcing guidelines. Usually there isn't and your question doesn't make one.
Beyond that there needs to be an established workplace culture where people take engineering guidelines seriously, production staff follow them, and compliance is a way in which leadership measures individual contributor performance.
If there isn't organizational buy-in, guidelines are pretend work. They look like work and are easier than the actual work.
Just doing the hard work is the simplest thing that might work.
Good luck.