CWDN series: Dev-eXperience – Cockroach Labs: Building for the 99% in day 2
This is a guest post for the Computer Weekly Developer Network written by Jordan Lewis in his capacity as senior director for cloud engineering at Cockroach Labs.
Lewis writes in full as follows…
To paraphrase Fatboy Slim, we’ve come a long way on developer experience: through the hard times and the good.
The hard times saw IDE makers tie us into their extended Application Lifecycle Management (ALM) systems. The good was evolved DX that allows devs to flow through their work using the tool of their choice.
Much of the focus has been on the early stages of the software story, on Day 1.
Day 2 – the evolution of the software with testing, security, observability and more – isn’t getting the love.
Rather, we’re in danger of slipping into an IDE mindset: each day I hear more companies claiming to offer a ‘single pane of glass’ for some aspect for Day 2. They are young companies trying to own the conversation but, beware: it’s a siren call (i.e. it sounds alluring, but it’s ultimately potentially dangerous) and the unwary will end up with 10 panes of glass and the overhead that brings: context switching, decision fatigue, and the need to maintain large and growing tool chains.
As we consider ‘good’ DX for Day 2, we should reset the conversation. The industry is full of prescriptive advice: it’s easy to feel if you read enough blogs, attend the right conferences and follow the right influencers that you can implement an ideal DX. All that’s needed is a dose of strong leadership and some discipline among the ranks and you, too, can achieve the engineering dexterity of Apple, Meta or Netflix.
All of which brings me to Akita Software founder and CEO Jean Yang, who takes a refreshing view on this topic.
She has busted several myths around developer experience but the relevant one in this context is there’s no gold-standard development environment. All those blogs, events and influences describe an aspirational view. Yang, instead, says we need to cater for the 99%: devs outside the hip companies and frameworks who are getting work done. Those whose work, Marc Andreessen might say, is eating the world.
With that in mind, I have two ideals that should inform our thinking on DX.
Principle #1: Location
First: rather than push developers into one environment, meet them where they are.
We talk about a shortage of developers but each year I’m staggered by the size of each new intake of recruits. These take their seat next to those with experience of the technologies and stacks in situ. Everybody is at a different stage in their journey as software engineers and it’s counterproductive for new recruits to have to learn the nuts and bolts of the earlier generation’s technology: they want to log in and crack on.
Those developers work using a range of modalities so we need DX that caters to that: something capable of working with the underlying technology platform in a way that makes sense for each. Let developers work in the environment that’s right for them – that feels familiar and intuitive. That could be a terminal working from a command line, a UI that lets them visit a website or log into a management console, or working through APIs.
The takeaway?
If you are a tech company building tools, don’t claim you’re the one true tool. If you mandate your organisation’s developer infrastructure, think ahead: have a good sense of where your organisation is going with Day 2.
Principle #2: Collaboration
Sounds simple but what does that really mean? Let’s channel Yang and develop a model that serves the 99%. Cloud infrastructure is complex and it changes fast. Delivery times are tight. You’ve been asked to manage a database migration or a schema update – your time is not best spent reinventing the wheel. Or, management wants a set of metrics to measure delivery and performance but there’s a huge number of dashboards to pick from.
This is where collaboration steps in: it means an environment that’s capable of capturing elements like configurations and making them available to others. Collaboration means making best practices available as templates that can be copied, cloned and edited. It means, in short, the ability to follow in the best-practice footsteps of your peers.
DX has served us well in Day 1 but If we’re going to raise the bar on Day 2, and live up to the ideals of flow, DX must serve the broadest base of devs. That means living up to the ideals of familiarity and collaboration – and leaving the 99% to pick the tools.
