Into Developer Ergonomics
This is the first story that is really was sitting in my drafts section for almost a year now. Since i just updated the Developer Ergonomics of my personal landing page i think it makes sense to kick off (hopefully) more stories here on Medium with a bit of history.
Curious why Developer Ergonomics scratches an itch for me?
Here is how it all started.
What kind of a beast am I?
All my career as an technical consultant i was wondering why i was doing things the way i do it. Why i am interested in certain parts like developer productivity, release process, test harnesses, build pipelines etc?
In 2010-ish i was under the impression that i am a “Build Manager”. That is a strange role and it was (even back then) hard to explain to people that there was an actual business value for having a share of your workforce working on it full time.
But, besides having i big heart for build-systems, dependency management and convention over configuration paradigms, it never was the full story of what i was busy with. A dedicated share of my time went into test automation. I am just in love with fast, repeatable, concise but still impactful software tests. My APIs — my code output — mostly are:
- Automation & Pipelines for the Software Lifecycle
- Testcases
- Test Harnesses
- Framework Abstraction
- Sample Code and Tutorials
- Technical Documentation
This means, i am serving to developers primarily. Developers are my primary customers. So, the quest goes on. What is this beast that i actually care about?
Developer Advocates
It must have been around 2013 where i got aware of the role “Developer Advocate”. Mostly in context of very technology friendly corporations like Google and Pivotal. There has been written much about it, but my impression is that developer advocates like Trisha Gee, Hadi Hariri (both Jetbrains) and Josh Long (Pivotal) are mostly outward-reaching evangelists. They appear to be the public face of their internal developer workforce. So while they definitely close to what would be called superstars in other industries.
They do care about developers. Its in their role-name. Though its outward-facing. I don’t know how much effect they have on internal development teams. Hard to tell, mostly because the companies who do have Developer Advocates are already on the bright side of what people call digitization. They are living the digital life already. Did they “invent” the Developer Advocate role because their companies are role-models in the industry already? Or are developer advocates the reason for success?
The new Kingmakers
RedMonk, the developer-focused industry analyst firm, coined the mantra “developers are the new kingmakers” to illustrate the impact developers have today. In a world where we speak about digitizing almost every aspect in our (non-digital) life using the Internet of Things, Cloud Technology and Machine Learning it is clear that developers have an impact.
Developer Advocates are the public face of the new Kingmakers. You can chose if you see them as the Rockstars or as the Public Relations Department in their organisation.
Aren‘t Developers only modern assembly-line workers?
Still, developers are often seen as work-horses. People who crank out the code are just the soldiers. The real genius are the architects, managers and domain experts. This is only one side of the coin. Partially true.
The other side of the coin is that software developers often happen to be very smart people.
Software Developers are people who can create models of the real world, abstract away parts that don’t contribute to the problem domain, they can work iteratively on problems and ultimately are becoming cross-domain experts just by accident. That is because Software Development affects almost all other aspects and domains in our (work-) life. If you can model a problem in code, you can do this across across different domains just by interviewing domain expert. You are the glue “code”. And this is a good thing.
Domain Experts vs. Management
In his book Developer Hegemony Erick Dietrich (Twitter) shows how developers who care are an essential part of what he calls “an upgrade for the modern corporate structure”.
This is actually the tipping point: Developers Who Care. The kingmakers are not your business logic developers. This is stuff that (hopefully) can soon be done by domain experts themselves. Or machines. Or both.
What really matters
What really matters are empowering developers who think of themselves as enablers. Don’t put barriers in their way. Motivate them to also work in your organisation. Make them Developer Advocates. Not just at the Google or Amazon.
You need to support the business developers as well. In fact, they do a lot of undifferentiated heavy-lifting which makes projects fail, good people leave and ultimately make your organisation not a good place to work in as a software developer.
This is what Developer Ergonomics is all about
Developer Ergonomics is about all-day mechanics to increase developer productivity, improve software quality and providing a good work environment to attract and retain top talent. Listening to Developers is the first step.
Developer Ergonomics is about providing the right amount of creative space and meaningful borders which some also call railroads. Practically this means creating custom development kits (SDKs) that are suited for the job at hand.
Developer Ergonomics is not a single technology or principle. It is a new view: Looking at how software is invented, being developed and how it is nurtured.
Will talk about all those things in dedicates stories. Thanks for reading. Let me know what you think. Follow me on Twitter.
