Sarah Saunders, speaker at Devoxx US March 21-23rd, reached a scary conclusion recently: the code we write has no value.

Instead, it’s time for developers to concentrate on skills. The development community is so big on sharing knowledge, and the resources so available, code becomes less important. The real value is the skills behind the code.

We asked Sarah what her top 5 skills for developers are.

Top 5 skills

In no particular order:

  1. Understanding Agile
  2. Creating a Build Pipeline
  3. Avoiding the “it-works-on-my-machine” paradigm
  4. Unit testing
  5. Mocking

“Even if you were just building a tiny project where you expose an existing API to be read by something like a SAP system, so a project with no code at all, you’d need the above skills to assure your work and to fit in with the rest of the team.

“I believe coding itself within an enterprise environment will really be a luxury in the future. Like art – a machine can paint a person better, we do it because we enjoy it – writing something like a small database app with RESTful APIs would fit into the same category.”

Do you think there will be a division in the future between developers of systems and library writers? So developers who write systems to expose APIs, compared to developers who write the REST libraries that the system injects as a dependency?

Oh there is already! Wherever there’s a barrier, an interface, there’s someone to blame :). But if we’re not writing code and generating bugs that way, we will be able to focus more on the interfaces themselves. I’ve seen this in many an integration project, where an end-to-end test fails and each team instantly lands on the defensive: “You didn’t give me the right credentials!” or, “You TOLD me to send that data format!”

A skill you mention is understanding Agile – do you think there needs to be a distinction between Agile-the-recommendations based on the Agile Manifesto, and Agile-in-practice? Which do you mean?

I always mean the Agile Manifesto. I appreciate it’s easy to get abstracted from it in the excitement of daily chats and coloured post-its, but we always need to pop back and read it occasionally to remember what it’s all about. Agile is not something restricted to the dev team – the whole project must embrace and understand the manifesto and work accordingly.

As developers learn to create or implement their own build pipelines, and, thanks to containers and microservices, learn tenants of infrastructure, do you think DevOps will become the norm rather than a separate discipline?

Yes I sincerely hope so! For me, DevOps is an integral part of being agile. You need to be able to support frequent change, at a hardware, support and business process level, before you attempt frequent change at a development level. It’s so obvious to me that I am always amazed when people overlook it.

Should we be unsympathetic to the ‘works on my machine’ excuse when changes in production go awry?

Difficult – I don’t want to be unsympathetic, and it’s very easy as an individual developer to assume that the production build isn’t really your problem/issue/within your jurisdiction when you have so much else on your plate, but if there isn’t a safe, repeatable way to generate your environments you WILL, as a developer, get bitten by this – so time to step up and get it sorted!


For the full run-down, join us for The Monster is Coming Over the Hill – Enterprise Coding is Dead.

Devoxx US banner