The Parts of DevOps That Have Nothing to Do With Code

Power lines, trees, and stranded cars were unfortunately common this past week.

When you hear about DevOps, you often hear about all of the ways it can help your code be better. That’s true. But there’s a whole host of other benefits. This week highlighted how a dev team can be stronger with a solid DevOps practice.

The Storm Cloud

Last Monday started normally. We did remote co-working, reviewed PRs, and chatted about what we did over the weekend. It seemed like a cloudy, but pleasant and normal start to the week. And then the derecho hit.

Reader, I did not come right back…

Most of my team is in St. Paul, but I’m down in Des Moines. And in the 90 minutes between my first and last message above, my neighborhood went from your generic midcentury housing tract to a literal disaster zone.

Power lines, trees, and stranded cars were unfortunately common this past week.

I took the afternoon off, letting my team know I’d be outside helping clean up anything we safely could and waiting for the power to come back on. The waiting lasted three days. I did my best to find power and stable internet for as long as I could each day, but I was effectively cut off from my team.

The Silver Lining

Luckily, we’ve been remote-ready from the start. And we have been working hard to build a DevOps culture in the team. And it showed this week. The team was able to pick up tasks where they’d been left off because statuses were communicated to the whole team before trouble hit. They knew where to find the information and the processes were already known. We have several ways to communicate, so we could still get in touch with each other to ask questions or for me to let them know I was fine, but still waiting for the lights to come back on. In addition to an enabled team, many processes are automated, so if I only had flaky LTE for a few minutes, I could still kick off builds or PRs and know that things would still complete even when my connection dropped.

Of course, we didn’t get as much done this week as a “normal” week. But we got a lot more done while dealing with an emergency situation than we would have had we not prepared ahead of time for trouble to happen and to keep any one of us from becoming a bottleneck.

How do I make my team resilient?

There are plenty of consultants out there that will happily sell you a program in one of many detailed systems. Here we believe the important part is that you have a system. It doesn’t matter which one, as long as you don’t lack a system. In our DevOps culture, we have come to value good communication, daily growth and learning, and team empowerment.

To get where we are, we’ve been working on:

  1. If you feel like you’re over-communicating, you’re probably communicating the right amount.
  2. Show your work. Keep written logs of where your tasks stand. The more detailed the better.
  3. Automate the things that are easy to mess up first, even before the boring stuff.
  4. Daily learning. Share our mistakes, articles or hints we found valuable.
  5. Give frequent mini-talks about topics or technology that we’re working on or learning about.
  6. Build the tools to work effectively remotely.

Discover why Dojo Five EmbedOps is the embedded enterprise choice for build tool and test management.

Sign up to receive a free account to the EmbedOps platform and start building with confidence..

  • Connect a repo
  • Use Dev Containers with your Continuous Integration (CI) provider
  • Analyze memory usage
  • Integrate and visualize static analysis results
  • Perform Hardware-in-the-Loop (HIL) tests
  • Install the Command Line Interface for a developer-friendly experience

Subscribe to our Monthly Newsletter

Subscribe to our monthly newsletter for development insights delivered straight to your inbox.

Interested in learning more?

Best-in-class embedded firmware content, resources and best practices

Five Most Common Reasons: “It works on their machine but not on yours!”

One of the most frustrating things during any type of development (be that firmware or software), is to grab a project’s source code and have it not build. No doubt everyone who has done some form of programming has encountered this at least once in their life.  Maybe you’ve pulled a repository from Github, built it according to the readme file, and it DOESN’T BUILD. Surely you’ve missed something….right? You look at the bug reports for the repository and see

Read More »
When is Yocto Right for You?

When is Yocto Right for You?

Embedded systems are more complicated than they’ve ever been. Modern devices have multiple connectivity stacks; they run heterogeneous software written in many different languages written by third parties; they perform machine learning and send telemetry to the cloud and receive OTA updates. A single-threaded bare-metal OS won’t satisfy these complex requirements, but Linux will. The Yocto Project was created to manage the details of deploying Linux in modern embedded environments. What is Yocto? Yocto is a toolkit for creating platform-specific

Read More »
Best Firmware Development Tools of 2025

Best Tools for Firmware Developers in 2025

This blog post will touch on some of the best and most useful Firmware development tools. Before we begin, there are a few caveats to be aware of. The “Best” tools does not necessarily mean the “Newest as of August 2025”. There are new tools coming out all the time, however, just because they’re new doesn’t automatically make them useful or even good.  A firmware developer/project shouldn’t use 100’s of tools – that would be a nightmare to maintain and

Read More »