CWDN series: DevEx – Couchbase: 1 size fits one, personalisation matters
This is a guest post for the Computer Weekly Developer Network written by Perry Krug in his capacity as head of developer experience at Couchbase.
Krug describes himself as a ‘very’ technical systems engineer with expertise in networking, enterprise storage, Web 2.0 infrastructure and NoSQL databases. Now heading up the Developer Experience initiative at Couchbase, he is concentrating on growing the firm’s current developer community as well as making it easier to build modern, cloud-native applications on Couchbase.
Krug writes in full as follows…
Personalisation has long been a mantra for IT services and applications.
From directing consumers to the most appropriate Amazon purchase, Netflix series, or mortgage options; to ensuring employees have access to the exact tools and information they need to do their jobs effectively, the idea of one size fits all is largely in the past.
The same applies to the developers themselves.
At the most basic level, the development team is a resource and the key to getting the most out of any group of people is to treat them as individuals, so that each can reach their maximum potential.
A personal experience
There’s no single factor or secret sauce that determines the best developer experience – like so many other considerations it depends on the complex interaction of a whole range of variables, including the developer themselves.
For instance, one person’s streamlined interface is another’s over-simplification that removes the level of granularity they need. One person’s preferred programming language will be another’s poison. And one person’s flexible working that allows for more time with their family is another’s invitation to procrastination.
That said, there are still priorities. For instance, take time. Many developers are over-stretched and over-worked: in a recent survey we performed of 533 software developers, only 5% said they had the capacity to take on more projects.
Taking some ‘me’ time
Freeing up developers’ time will improve their effectiveness – but it will also allow for a better understanding of what their key role is and how personalisation can truly help them. And even at this relatively broad stage, taking the right approach for the individual is still imperative.
Krug: Personalisation requires focus or it can easily spiral out of control.
For example, automating repetitive, lower-value tasks is an obvious way to free up developers’ time – but knowing what those tasks are for each development team and even each developer, will help make the right decisions about what and how, to automate.
Similarly, developers should be given the tools that let them do their jobs easily. This often means that familiarity trumps novelty. For the individual developer, a tool using the SQL language they have grown up using will be more powerful than a tool that offers newer functions in an unfamiliar language.
Finally, there’s the question of whether developers still need to own their entire role.
Low- and no-code development and serverless computing make it easier for developers to create applications – but they also mean that individual business units have the power to purchase cloud applications themselves and even develop their own (simple) services. In this case, taking some responsibility from developers can speed up the business and improve the developer experience – as long as they don’t immediately have to take on the new responsibility of fixing the mistakes of teams who haven’t been educated or managed correctly.
Even these relatively broad decisions need to take a personalised view, but when developers are freed to concentrate on their key roles as much as possible is when personalisation can really shine.
Keeping up with the Joneses
Successfully personalising the Developer Experience relies on this streamlining.
If the business can’t automate, simplify and/or delegate tasks, the number of processes and tools in play will prove overwhelming: making successful personalisation too complex to even attempt, or at best only reaching a proportion of its potential.
Instead, with fewer moving parts to consider, organisations can focus on those factors that truly add to – or detract from – the developer experience. For instance, allowing for more granular detail in exactly what tools developers are using and how they are using them; or giving more time to dedicate to collaboration and individualised project management that will help reduce pressure even further – ideally creating a virtuous circle.
This should also mean developers have more time free to learn how to use new tools, instead of having to fight against innovations because learning how to safely and effectively use them would simply add to their workload. And the team as a whole will have the time to understand exactly which innovations – if any – will most benefit which members.
Fording ahead with focus
Ultimately, personalisation requires focus or it can easily spiral out of control.
Removing developer distractions will help create that focus and provide its own benefits. After all, three out of four developers say they’re taking on work outside their core job description.
