It’s No Longer about How You Write Code but How You Operate It
The role of the developer has changed significantly over the past two decades. While once upon a time developers were largely expected to write code, then throw it over the fence to operations for them to run, today the code is only a small part of what developers are expected to own. (Including all of the disciplines that are undergoing “shift left” practices to engineering.)
We’ve transitioned to a time where developers are not just expected to write code, but they’re also expected to operate it. This means all aspects that affect this in production — from the quality and performance, to security, among others, have taken center stage. Decades of expertise cultivated in a specific language, for example, has suddenly evolved from being a critical skill to a floating skill.
Remember the days when hiring managers would look for Java or Python programmers and this affected employability? Well no more! Engineers today are being hired with little or no regard to the programming language they have excelled at.
Today, the core skills programmers need to demonstrate to truly be employable are transferable skills on the side of operations. Domain expertise in platforms, stacks and business operations have become by far more critical skills for engineering organizations today.
So how does this affect hiring and recruitment?
Evolving Our Hiring for Today’s Critical Skills
To be able to find the talents that map to these new critical skills, we need to rethink the way we qualify, hire and interview candidates and engineers. One of the central things we should focus on when interviewing candidates is how they learn and operate new technologies.
This type of skill will give us a good indication of how quickly they can evolve in a rapidly moving technology landscape. What’s more, with the incredibly fast pace of innovation happening in the world of artificial intelligence and machine learning, all of the repetitive small portions of code will become automated, low code to even no code. We don’t need to look much further than GitHub Copilotor InfoBip to see this happening already.
This leaves us with the humans doing the higher-order tasks. In a world where most of the complexity lies in the sheer scale and intricacies of running microservices and cloud native operations, we’ll need to reserve our humans for making the correct operational decisions.
Everything from the network protocols we choose to the underlying stacks, to the supply chain we import, affects our application’s performance. With competitors one click away many times, there’s a growing lack of tolerance for any system or performance lag, and programmers are expected to own this part of the experience as well.
We’ve heard the terms “user experience” for platforms and products, and developer experience when talking about dev tooling. This is all expected to be owned by the engineers building the products. The products today consist of far more than just code to properly thrive in large-scale cloud native operations.
Security in Real-World Operations and Our Chosen Stack
One area we certainly can’t ignore that has come to the forefront of engineering operations is security. Security affects so many aspects of our code already, its automation and operations, and the infrastructure it is running on. Security considerations affect every part of our technology stack, each has its own domain expertise from the code to the third parties to the infrastructure it runs on — these considerations together constitute nearly 15-20% of our stack’s considerations.
On top of this, the stack we choose to run has a direct impact on nearly every aspect of our engineering organization. From the talents that will want to join us (as they all want to be working on the hottest stacks), but on the other hand, the more cutting edge, the greater the skills gap in operating these stacks. And that’s just the hiring part.
Our stack also affects how quickly we can onboard engineers, the learning curve they experience and the time until they can start delivering value to our team. This is where automation has delivered a lot when it comes to evolving engineering teams and what the future of engineering will look like.
Ops to Automate All the Things
This is why we’re seeing the *Ops trend across all of the well-known engineering disciplines: AIOps, GitOps, CloudOps, MLOps, DataOps, DevOps, turned DevSecOps or just SecOps, because you can’t write great applications and software without knowing how to operate it. One of the great solutions for the operations side has indeed become automation, and we see this in each of the areas above — from policy automation and GitOps, to CI/CD, to automated scaling, auto-recovery and even security through automated alerts and pull requests like Dependabot and much more.
However, even automation can evolve and align more with engineering workflows, and to help enable this future of everything ops. I’ll explain.
Let’s take the well-known backlog — this can be in issues, pull requests, security vulnerabilities, you name it, we have many of these in engineering organizations. However, these are a byproduct of manual intervention. We’ll soon get to a place where we have more moving parts than people to run them, and this is why we have to optimize for machines automating tasks. (No, robots will not be replacing you, only the parts you don’t need to be doing).
For example, as noted in a previous post of ours — all backlogs need to move to a fix-first mindset. If we have tools opening issues and not closing them, well that’s yesterday’s news. We don’t need more doomsday tools that just tell us what’s wrong. All our scanners and detectors should go that extra mile and also enable automated fixing and remediation for the simple tasks, and more intelligent alerting and prioritization for the tasks that require a manual touch.
This can also apply to how we as managers think about planning our projects, tasks and sprints. How we can better prepare for the age of operating code — where this starts with a fix-first mindset and everything else falls under the automation-first mindset. Whether it’s looking at the huge volume of tasks associated with operating code and understanding which can be done in batch operations and continuously, or ensuring anything that’s built to be automated and cyclical — needs to be highly aligned with engineering cycles and sprints.
Once we think about our sprints in terms of the operational aspects, this can also enable us to be more structured about how we plan our sprints too. For example, have some sprints focused on product (dev, code and features), and others focused on engineering (ops tasks and technical debt).
All of this together will affect the way we design our systems, and how we bake automation and resilience into them. Architecture will put a focus on lessening the learning curve, making it possible to leverage no code and low code tools to ramp up new engineers, instead of adding unnecessary (operational) complexity to our stacks — or as Armon Dadgar, CTO and co-founder of Hashicorp, likens it “resume-driven architecture.”
The Evolving Engineer
As engineers, we need to start being aware that this is where the world is moving to, and focus on skilling up based not just on how we write code, but also how capable we are of operating it in the long term. This will take “you wrote it, you own it” to a whole new level, and will require engineers to have a much wider range of skills associated with operational aspects of code than just programming in a specific language.
This also means that our tools need to become much more straightforward and easy to adopt, aligned with developer workflows and optimized for automation, with greater support for learning built in — from no code to low code to deep code, and will be actionable not just informational (and when possible, also automated). This will free up the humans to focus on the truly complex tasks and less on the repetitive ones. Once we understand this as hiring managers, we will know how to identify the engineers who will really provide impact and value for our teams, and as engineers how to position our value correctly when we are looking for our next opportunity.
