Understand the environment you intend to deploy to

Environment affects how you build your system. Decisions made on the environment can limit the options for technologies that can be used. Whilst making decisions on how to build a system, take some time to review limitations and understand the deployment environment.

Automate Code Quality, build process and releases

DevOps and source control affects how effective and productive teams can be. When an engineer gets into a good rhythm and there are guard rails for what they need to avoid and what they should do, the majority of their time should be spent resolving, improving and building. This is ultimately the goal of a successful and high velocity team.

Enforce coding standards, linting, test code coverage, tabs/spaces, benchmark requirements and review process and any other activity that can be setup to work automatically.

Document and host your documentation

One of the challenges with documentation is that it usually lacks immediacy, gets outdated quickly and goes out of sync with product easily. The benefits of good documentation however cannot be overstated. A lot of legacy systems cannot be updated, optimized easily due to a lack of understanding.

With this in mind, it makes sense to document why things are the way they are. There are schemes and practices that make sure that documentation is relevant. One such practice is the use of ADR(Any Decision Records). The idea is to keep track of why things change with a log that gives context. An example if this is why option A was chosen over the alternatives. This minimizes documentation required but the context helps when months to years later, a maintainer of the system wants to understand choices that were made.

Ensure Observability of your system by Logging and Telemetry

The bigger and more complexity, the intentional you have to be with logging and telemetry. Although these tend to be neglected, a well instrumented system proves to be easier to diagnose when there are issues in production than when it is not.

There is a sweet spot for telemetry and logs, my hot take is that it is better to be noisy that silent, especially at the onset of the project. There is an argument to not use logs and rather to prefer events. This is a credible and viable alternative, granted, it would require a lot of discipline and domain knowledge.

Setup Generators and templates for boilerplate

This is in line with automation, it is simply generating as much code as possible. It can be as simple as using templates for servers, generators for known tasks and CLIs for repeated activities. This is and will become an ongoing process of refinement. The better the automation story of development, the easier it will get to provide value. An example of this is generating code from swagger documentation or generating swagger documentation from the code. Whichever direction is chosen, both should not be handwritten.