From DevOps to Software Engineering

Learn how to make the transition!

I have a number of friends and professional contacts who are looking to make the jump from DevOps to software engineering for varying reasons. Some are looking for a professional challenge. Others feel that development teams should do their own operations. A few are looking for more money.

A quick aside about money. DevOps/SRE is in a weird spot right now where new DevOps engineers with beginner skills and little experience are making more money than many software engineers with a decade of experience. This has led many to believe that DevOps is a better career choice in order to maximize compensation. This is not always the case. Top software companies pay their software engineers more than they do their DevOps Engineers/SRE/Solutions Architects. It is easier and quicker to make money in DevOps, but software engineers generally have a higher ceiling.

Transition to Software Engineering. So if you are a DevOps Engineer/SRE looking to develop your software engineering skills, then you have come to the right place. Software engineering coding interviews tend to consist of two types of problems:

1. Problem Solving with code - think effective use of loops, conditions, variables and data structures to solve a problem or put an algorithm together.

2. Logical and Maintainable code - think effective software design that is maintainable, extensible, doesn’t repeat itself (DRY), easy to read, uses patterns effectively, etc.

Mastering problem solving. You can master problem solving by solving problems on sites like leetcode.com. This isn’t easy to do and takes time, but the path is clear. My advice would be approach to problems this way:

1. Solve the problem

2. Solve the problem again in an unfamiliar language

3. Optimize your code to get a better runtime (faster results, less memory)

4. Study and understand other people’s solutions

Of all those steps, I think #4 is the one that people don’t do enough of. Some problems on leetcode.com are extremely easy to solve but very difficult to optimize. The optimization might require an approach you would never think of unless someone told you. By looking at other solutions, you will unlock new ways of thinking. I admit there are problems I would never have solved if I didn’t look at other people’s solutions. In other words, I tried to solve them problem (step #1) and failed and proceeded directly to step #4. There is nothing wrong with this. Ideally, you solve the problem yourself but that will not always be possible. I am not suggesting you copy someone else’s code and submit it. That is pointless. Learn their strategy and come back after a week or so and implement it yourself. It doesn’t actually matter if you submit it or not.

Learning software design is less straightforward to learn than problem solving. In my experience, most computer science graduates do not have a solid grasp on software design when they enter the industry. The best way to learn software design is practical experience working as a software engineer, but how do you get experience if you don’t have a job yet? One way could be contributing to open source projects but that is not always feasible for a learner because open source maintainers generally only accept high quality commits. So what are the other options?

I am here to help. I am launching a series of blog posts specifically designed to help DevOps Engineers learn Software Design. I won’t pretend you can use my work alone to master Software Design, but I hope it will help.

The first posts will be on Decoupling Algorithms from Business Logic. The first post is released. Click here to check it out!

You might be wondering why I don’t simply write the blog posts on Substack. Unfortunately, the code formatting options on Substack are limited and not that great. For example, is the following code formatted properly on your screen?

func depthFirstTreeTraversal(root *Node,  businessLogic func(*Node)) {
  stack := &Stack{}
  stack.Push(root)

  for !stack.IsEmpty(){
    node := stack.Pop()
    businessLogic(node)
    for _, child := range node.Children {
      stack.Push(child)
    }
  }
}

If you enjoyed this post, please share it with your friends!