Engineering Standards Do you have engineering standards, are you starting with developing them, or they are created to after mass adoption?

could you be a little bit more specific with your question?

I can try 🙂 two examples for standards can be: 1. Use CircleCI for CI 2. Use ngnix ingress (k8s) for all ingress traffic Does your organization have writing standards the everyone must follow?

We use a ADR board, its kinda a mess but good enough

I see, yeah not really. We’re trying to pretty much follow coding standards, including above all, no-code = ideal (the less the better)

@Omer Kahani it depends on the standard. Coding standards are agreed upon and decided at the team level. Teams expect to be given an environment to develop services, CI, deployments, etc. They wouldn’t think of doing everything on their own from the beginning. It’s a waste of time :) The environment into which services are deployed (microservice world) enforces a particular way of deployment and the rules you must meet to deploy. Some things are also processed through batch changes.

I really like the golden path approach, meaning you have one, documented!, way to solve common problems and those paths are becoming the de facto standard. If new services are bootstrapped with CircleCI out of the box, it is fairly likely that developers will stay on this path. One benefit is that this feels less prescriptive and still allows experimentation, so teams fell involved and your engineering org can iterate on your paths.

standards should come from principles, good leadership starts with principles

@Johannes Würbach & @Andrew Fong I agree with the golden path approach, and also think the product should be used in platform. For my it suggests that standard are problematic, as they are a way to force things, and we don't want to force a product on the customer. I wanted to see if there are other thoughts 🙂

So my take is what I call "standardization by design". You do not want to abstract the user but give them higher level options that are convenient while also giving them the full context of what's happening under the hood. Sounds vague, let me be more specific: • Rather than exposing people to a full blown helm chart you give them an even higher level file. • You define a baseline helm chart that's empty but containing defaults such as CPU allocation etc. • You're dynamically creating the final config from a combination. The result is less cognitive load (team only needs to deal with the higher level file), standardization (you can drive that through the baselines) as well as abstraction without abstracting, because the team still has the full context.