"Four habits of highly effective cloud engineers" by Tecknuovo cloud partner Ben Snape

With 15 years’ experience in cloud and DevOps engineering in all corners of the tech industry, our cloud partner Ben Snape has a thing or two to say about what works and what doesn’t. In his blog post, he shares his top four tips for becoming a highly effective cloud engineer.

For the title of my blog post, I took inspiration from the famous book by Stephen Covey: The seven habits of highly effective people

I’m going to channel my inner Stephen Covey (with a cloud engineering twist), and delve into the four topics I believe are the keys to becoming a highly effective cloud engineer.

Put the company’s needs above your own ambitions

The simple reality of working for any company is that each of us will likely only play a small part in that company’s overall life.

So with the limited time given to us, we as cloud engineers have a duty to select industry-standard, best practice tools and technologies that are not only a good technical fit, but also the right choice for whichever direction the company will take in the future — long after we’re out of the picture.

Indeed, that future direction often gets overlooked. But the pattern is easy to reverse. Once you’ve identified a technology as a good technical fit, consider these three things in regard to that technology (in order of increasing importance):

• The team’s current skill level — are they well enough versed in the technology?
• Ease of hiring — is it easy enough to hire people who are skilled in the technology?
• Ease of skilling up — is it easy enough to upskill teams to use the technology?

If the answers to these questions are concerning, it’s usually a good indication that you’re making the technology decision for the wrong reason(s). Choose a technology that gives you positive answers to those questions, and you’ll be well on your way.

The takeaway here is that we must be careful not to shoehorn some new technology into the stack for the sake of being able to demonstrate commercial experience in that technology.

Set yourself high professional standards

It sounds simple, but setting and upholding solid professional standards is an absolute pillar of high-quality and effective cloud engineering. That said, if I had to pick the one thing that I’ve seen most consistently on projects across the board, it’s a lack of professional standards.

These are behaviours which can manifest themselves in many different ways, but most often stem from ill-discipline. In the short-term, they can cause build failures and increase friction with team members. Longer-term, they can make debugging and auditing more difficult.

Some examples of lacking professional standards include:

1. Clumsy commits — where new files are either excluded or unintentionally added.
2. Badly worded commits — making code reviews and debugging difficult.
3. "Pushing and praying" — where changes are too hastily made in lieu of proper critical thought.
4. Not running tests locally (especially when practising trunk-based development)
5. Leaving the build broken for someone else to fix (and not communicating that). This is more likely than ever before, now that colleagues are often spread across multiple time zones.

This is my advice for how we can do better:

• Become proficient in the tools and technologies you use on a daily basis.
• Pair with others regularly — you’ll learn lots of tips and tricks along the way.
• Always be learning and trying to improve yourself, and strive to be the best you can be.

Set a TTL on your opinions and be aware of your biases

Checking your own biases and setting a time to live (TTL) on your opinions is a universal way of doing more efficient work. But it’s a topic that is rarely highlighted in cloud engineering, and something that will become more and more relevant as your career progresses.

Often when we’ve made up our mind about something — like evaluating a new tool — we’re reluctant to go back and re-evaluate our findings at a later point. After all, we gathered all the evidence then, and used it to make an informed conclusion.

You might be right: the tool or technique wasn’t a good fit, or even failed, in a prior situation. But that doesn’t mean it may not be feasible now. Here’s why:

• It may have improved since your first evaluation, or its recommended usage may have evolved.
• Perhaps you weren’t given enough time to fully evaluate it, or you had a flawed understanding of its capabilities at the time.

At what point do we hold our hands up and say “okay, let’s take a look again”, and re-evaluate a tool with our previous experience and biases in mind?

Discarding biases and starting fresh is difficult — so we need to make a real, conscious effort. Technology trends move on, and often even come full circle. We need to be prepared for when that happens.

Don’t make “surprising” architectural decisions

What is meant by “surprising architectural decisions” can be quite nuanced. But it typically includes things that go against (very) common conventions, involve the clear misuse of a technology, or even a conscious decision to not use an appropriate technology.

It’s difficult to give clear examples without digging into technical details, but I can give one from my own experience that involved application configuration in Kubernetes. Applications were deployed via Helm but at runtime, pods would load additional configuration via a custom init script that was making calls to AWS Parameter Store. Once loaded into memory, it removed all traces of this process.

It was difficult to understand this design decision, as there are clearly established best practices provided by Kubernetes itself (i.e. ConfigMaps).

I think this is one of the more dangerous behaviours that we as cloud engineers can fall into, as it can lead to a lot of fear, uncertainty, and doubt for your colleagues. Not to mention future maintainers of the system.

The good news is that the main antidote to this is having a good, up-to-date wiki and architectural decision records (ADRs). To find out how to build and maintain one for your current or next project, head to adr.github.io

Conclusion

I use these four habits as they have helped, and continue to help me stay efficient on every project I work on. They also help me positively influence my fellow team members, and I hope you'll find them just as useful as I do!