Kelsey Hightower talked with Ambassador Labs's Daniel Bryant about a range of subjects, including what shifting left and developer responsibility really means, promise theory and what developers really need to be successful, and developer empathy, or stopping the practice of "cart-before-horse" coding to get to the heart of what users want first.
Kelsey Hightowe, Principal Engineer and Staff Developer Advocate at Google, and a leading voice in the cloud native and Kubernetes space.
Here are some of the key takeaways from their conversation:
The move to "shift left" has received a lot of attention, but it's not only the developer who is affected. While the developer, and the software, will benefit from the developer getting all the information needed as early as possible, dependencies unfold further downstream. While developer ownership or understanding is important, it is just as important to define who is responsible for different steps, e.g., "If you're the developer, you will have some responsibility for the "ingredients" you add to the mix. You will be asked to understand and answer for some of the choices you make. And beyond the developer, everyone needs to be aware of their responsibility in that pipeline."
Kubernetes, at the end of the day, is a last-mile technology that requires instruction to do what the developer intends for it to do. As the developer takes on more responsibility, or at least needs to understand the consequences of what they code. Centralizing the experience around a platform or control plane enables understanding of what's required to deploy and run code without the complexity of having to manage it completely. It's about creating a platform that, with some configuration, the developer can trust to run their code as instructed. "The control plane concept or experience is the evolution of this, where things take off for all sorts of infrastructure platforms. You now have a central place to hold state, converge it and keep it true over time. Kubernetes just happens to be what we consider a universal control."
If engineers are coding applications and features without using them or considering the user experience, it is completely devoid of empathy. And what is the point of creating software if isn't serving the needs of its users and helping them accomplish their goals? Engineering empathy for the user into the coding process requires developing human, or soft, skills, like communication and putting oneself into the user's shoes. "It does not work any more to create software in a vacuum. The user reaction should be, 'Wow, someone thought about how I would use this; it's intuitive, it's frictionless'." It is through empathetic engineering that developers will achieve this outcome.
The industry as a whole would benefit from giving developers more time not only to develop their soft skills but also to do their research, both to understand what has already been created in the world and to gain a better understanding of where gaps and needs are and the psychology of users' behavior.
"Code should be the final step in the software development process. If you get really good at the human side of it, I think you will end up writing much better software."
The supply chain of software is the next great step in the maturity curve for cloud-native computing. Developers should be able to account for what is actually in the software. The importance of developers taking greater ownership of what they code and its dependencies is becoming codified in the form of software bills of materials (SBOMs). SBOMs ensure the integrity of the software supply chain and help elevate application security.
"Education, centralization and discipline will help us really focus attention on what's in our software. And knowing that we have the power, control and responsibility to make sure that only the things that are necessary to be in there."