DevOps

DevOps is a culture. Do not consider it as a job title. DevOps is everyone’s responsibility and not just for that DevOps engineer. Generally, people writing CI/CD pipelines, deploying code, taking care of DX, doing security patches, playing janitor, and working with infra are called DevOps.

I won’t argue about the definition of DevOps because it doesn’t matter. What is important is to understand that each software engineer should be able to do their own “DevOps”. To be good at it what you need is good automation, scripting capabilities, and working knowledge of how systems integrate with each other.

Like I said, everyone should be able to put a website on the internet. If you know how to do it then you should be able to automate the process as well. Thoroughly understand each stage of the development cycle of your code. How a task is assigned to you, how you code it, test it, get it QAed, deploy it, where is it deployed, the system that runs the code, and how it goes live. Understand all the underlying systems and their specs. Be in a position to automate all of what is possible. Do it when it makes sense. More about when to automate and when to skip later in this post. This could be a lot for a junior engineer but 2 years into engineering, all of it is not too much to understand. Believe me, it will pay dividends you never imagined.

Each engineer must be able to improve their own developer experience. Always identify what frustrates you in your day-to-day development and fix the underlying problem. If something is tedious and is a regular part of your day job, automate it. Automate as much as you can to give yourself and your team room to help grow the business.

Whether to automate something or do it manually can be determined by a simple rule. Automate it when the collective engineering time a task takes approaches the time it will need to automate it.

A very basic example of tedious work is formatting. It should be totally automated even if you are doing a side project that probably won’t see daylight. It’s trivial. All modern languages and frameworks have built-in support for this.

The next steps depend on the scale of the team, organization, and nature of the product but here are some things to consider.

Set up basic linting and automate it so you don’t have to run it manually. Put them in pre-commit if the code base is small enough, in pre-push or CI otherwise. Put them in your CI steps. Enforce your codebase-specific conventions through linting rules instead of manually pointing them out in PR reviews.

Write tests. Automate the way they run on your code. Put them in CI and run on pull requests before they are merged. Calculate test coverage and make sure it doesn’t drop after the new code is checked in.

If you write e2e tests, automate that as well. Run them regularly.

If you happen to do some security checks and tests, automate them to run regularly.

Measure performance and set monitors when latency spikes. Alert when scripts are taking too long in the browser or when the FPS of your game drops below a certain point on certain devices.

Doing or skipping any of these practices depends on what you or your company can afford to do. Automating them is rarely up for discussion. If you can afford to do them i.e. write tests then automate them. Everyone should be able to do so.

Adding these checks becomes increasingly and exponentially important with every new individual that works on the same system/codebase. If you are a team of one, you can get away without all of the checks. If you are 3, you need some of the checks. In a team of 30 people, you need all of the checks plus some customized rules of the team/product. In a team of 50, you need so many basic and tailored checks that eventually your engineering speed slows down. This is why one should not have a 50-person team Even 20 is a stretch. A company with large teams is on a highway to deterioration.

As you scale, automate the developer’s workflow as well. Make project managers redundant. A developer shouldn’t have to ask for code reviews. A developer shouldn’t have to go and ask QA to test his/her code. A developer shouldn’t have to worry about releasing his code in production or alerting stakeholders that xyz bug has been fixed. Automate the entire process.

Doing DevOps will make you a better engineer. Period.

This post is from a series of related posts about software engineering. It is part of an attempt to write a book in public. I seek your feedback. Raise your opinion. Share with people who can benefit from it. Contribute in the comments section, on social media, over a cup of coffee, or however you prefer. This will help me and the community tremendously.