CWDN series: Dev-eXperience - Perforce: When coding, think about the non-coding factors
This is a guest post for the Computer Weekly Developer Network written by Rod Cope in his capacity as CTO for Perforce.
Cope writes as follows…
Developers are still the front line of software innovation, the difference between great and bad apps, so the more time they can spend productively focused on creating code, feeling motivated and supported, the better for everyone.
This is not just some altruistic mission (though nothing is wrong with that): happier developers lead to stronger products and satisfied users. That’s why improving all the stuff around the Developer eXperience (DX) — removing unnecessary effort and providing the flexibility and freedom of choice they want — is essential.
Sounds obvious?
Maybe, but it’s often still not the case.
Why? It requires effort and a significant mindset shift for many organisations.
Process practice
For example, while management must investigate and invest in tools to support the DX, developers often want to bring in something else (spoiler alert, many of those will be good ideas). So, having an open-mind culture is vital, with developers knowing they can confidently make suggestions and be heard or try something new and still be supported.
Adopt the best ideas and share them as best practice processes to avoid having pockets of ‘good’ and ‘bad’ across teams. But a caution about processes: keep them as lightweight as possible. Otherwise, people will find a workaround, or where they cannot, heavy processes become demoralising.
Let’s not forget that every new process risks adding another layer of work.
Take away the friction
Processes are part of all the activity around writing code — I call it overhead — which, in my experience, can be as much as 80% of a developer’s time (think code reviews and tickets). That’s not exactly breaking news, but it is by no means universally adequately understood, let alone addressed. Take, for example, MISRA coding standard compliance: many developers are still spending a lot of time filling in spreadsheets or Word documents, yet for years there have been tools that can do the heavy lifting.
Perforce’s Cope: Don’t put a bad process on a good developer – and vice versa!
There are other areas where non-coding effort can be automated or at least made less cumbersome.
Taking away as much of that overhead as possible lessens the temptation to rush to do the bare minimum. Instead, there is the capacity and energy to focus on creating something robust that users actually want.
So how to minimise that overhead? Too much time is still spent looking for things or reinventing a wheel that exists elsewhere in the organisation. Instead, create one place to look for everything, such as setting up developer portals (again, not a new concept, but not yet standard practice).
Also, let developers live as much as possible where they like to be (especially their IDEs) and avoid making them leave. Go to them whenever possible (such as letting them book vacation via Slack if that is how they like to communicate) and be flexible. Avoid a rigid one-size fits all mandate around collaboration and meetings. Keep meetings to the minimum, focused and Agile-style. If developers want to avoid attending a company-wide Zoom meeting, give them the recording or even just the notes if they prefer.
It’s all about freedom and liberty to promote creativity, after all… so what else do we need to consider?
More rewarding onboarding
As another example of taking away friction, good DX includes helping new developers get up to speed faster and with less stress.
Traditionally, new team members could take six to 12 months before feeling up to speed, risking them feeling lost and demotivated. Instead, how about turning onboarding into an AI process with an interactive tool that guides where everything lives and how the team works? Compared to an overloaded senior developer, AI has infinite time and patience and does not mind being asked the same question repeatedly. This same onboarding improvement could also help senior developers get up to speed faster and more easily in areas they have never touched (or, at least, not for years).
Consequently, all team members have more confidence that they are doing the right thing and will make a positive contribution faster, learning in a way that fits their working day. This leads us back to that flexibility message, which, together with removing as much tedious toil work as possible, adds up to a better DX. After all, developers did not start their careers saying, “I’d like to spend lots of time meetings, doing admin tasks, trying to find things and working in an environment dictated by management that doesn’t suit me”.
Even in an increasingly automated and AI-driven world, great software still comes down to people.
So, if developers are the frontier to achieve software quality — and on schedule — it makes sense to wrap everything possible around their coding time for a better overall DX, benefiting not just them, but management and, ultimately, users too.
