Dion Almaer

Software, Development, Products

Developer Experience

Developer Productivity Matters

I have been fighting for investment and focus on developer productivity for a large part of my career. Platforms often focus on the user side more, and think that the focus should be on solely economic opportunity. Understandably, if you can’t persuade a business that their effort will result in profit, you won’t get resources applied.

I can’t tell you how often I have heard a version of the following:

“Hell. Developers rushed to learn Objective-C to build iOS apps!”

— Bizness Guy

The gold rush was real on getting apps available for the exploding usage on the iPhone, but while Objective-C looks weird to many from the {curly brace generation} it is actually an elegant language (sure, it has quirks, but don’t we all!). This flippant repost also ignores the quality in the UIKit foundations, and the quality of tooling.

Pete’s right!

Economics of a platform are important, and are an input into how many developers can be hired, but there are clear reasons that it is important to focus on developer productivity if you work on a platform. I contend that the vast majority of platforms are under invested in their support of developers, and haven’t reached the point of limited returns. Why?

Time is precious

A developer has a set time budget that is fixed. There are priorities coming at them from all sides. The “business” wants features, features, features. The platform is forcing deprecations, and requirements for performance, accessibility, and security.

Time well spent

If we can take away any time that is wasteful, we can optimize the time well spent of a developer. This allows for more productive output per time slot.

Another important characteristic of time well spent is that we aren’t JUST talking about pure optimization of effort. Developers want to do a good job, and are quite willing to spend time that results in higher quality experiences. We want to do a good job, and have experienced getting into the flow state to build something great. The notion that “developers are lazy” is often misinterpreted. We just don’t want to waste time, just like humans hate any form of bureaucracy that feels wasteful.

Frustration is the productivity killer

If you are frustrated, time gets exponentially eaten up. Developers are engaging in a creative pursuit, and paper cuts slow down your flow, and get you in a frame of mind that is destructive. When you are enjoying yourself, your energy levels won’t deplete in the same way as if frustrated. This is why it is vital that you track developer needs and frustrations and actively get rid of them.

If the platform is hard to use, and the tooling isn’t delightful, and the documentation sucks, well then the effect on time isn’t a set amount, but is rather a multiplier. You have the power to influence a multiplier. This is a big deal. Also, if you are particularly bad, that multiplier can go as low as zero, where the developer flips the table and does something else 🙂

Developers don’t scale linearly

While the economics of a platform may allow for hiring more developers, we all know that this doesn’t scale cleanly. As a team grows, you get increased communication costs, and it takes a very special team to be able to scale. Cut out the need and allow teams to be as small as possible, and to allow a team to be able to work in parallel as best as they can.

Don’t cop out on productivity

Don’t fall for it. Don’t think that you can get away without focusing on developers and doing everything you can to keep them productive. I remember someone who told me “The business doesn’t care about developer smiles” as though I was a hippy solely looking to care about our developers (which isn’t a bad thing!). Building trust is important. Having developers who love working on your platform is valuable. But beyond that, you want the flywheel from developers to be going as fast as possible. You want them putting their effort into quality new features. You want them fresh enough to want to put effort into areas that you care about in the commons of your ecosystem (performance, privacy, security, etc).

You should be doing everything you can to maximize time well spent, and taking on as many hard problems as you can, so your ecosystem doesn’t have to.

So, yes, developer productivity matters.

Does mobile documentation matter for developers?

Developers code on their laptops, normally docked with their mechanical keyboards and monitors, right?

As such, when it comes to developer documentation, you don’t need to be responsive, and can focus on a desktop-only set of docs.

I have heard this sentiment many times, and at first blush it makes some sense. For all the talk of mobile eating the world, a lot of the business end of things happens on the desktop Web.

Once you have desktop docs going, you look at your stats and see that you were right! A fraction of traffic is coming from mobile! Glad you didn’t waste any time on a great responsive experience! Well, hold your horses. You may have self selected your answers here.

A great developer experience includes a great documentation experience, and that includes mobile. I have seen transitions from desktop-only to responsive, as well as responsive from day one, and both have shown how important it was to go mobile, too.

Take one of the Google developer sites for example, and a recent slice:

mobile: 90+% of share
This slice is from a campaign, so bias, but directionally similar

Why is mobile such a big deal?

All documentation isn’t equal. There are a variety of reasons why someone ends up in your docs. The Web is a viral platform due to the sharing of URLs through all sorts of mediums (via Email, Twitter, Slack, etc). People are increasingly accessing these mediums via mobile, and are tapping in to read from there. I often read a lot of developer-oriented content on mobile, and will save it away and often revisit on desktop.

I also do a lot of memorization through mobile, using space repetition systems. A common task during the day will be saving some developer knowledge into my system.

This is somewhat akin to customers who browse for products on mobile and finish the transaction on desktop.

Beyond documentation

It has been fantastic to see the trend of developer documentation being seen as putting the manual online with some hyperlinks, and instead using the medium to add a lot of interactivity to help you learn.

The best way to learn is to do, and it is important to be able to feel how things work and play with them. We have embedded Glitch into web.dev as an example of bringing you tight playgrounds to explore, and remix for your own experimentation.

How do you want this type of content to be approachable on mobile vs. desktop?

The other important realization for me has been integration. Developers often end up in your docs via search, and they rarely probably go to your root domain and just read read read.

Take time to look in the Search Console to see your analytics to see how users are getting to you, and make sure that you have the content they need. You need a base of reference documentation, and then can walk up the chain to use cases, and finally verticals.

Look for other areas of integration.

  • Where do your developers live?
  • Their IDE? And certain plugins?
  • Do you want to reach them on StackOverflow or Glitch?
  • Do your error messages link out to documentation to help?
  • Do your docs work offline? (e.g. if someone is reading on the subway to work, or generally stuck in poor and variable connectivity)
  • Do you include code from source files that you have tests running against to make sure that a copy paste works?
  • Have you built a connection between the tools and your documentation so it can be surfaced inline?

There is so much to do, and while “docs” are a first class citizen, it is also important to recognize that good tech writers are still under-rated!

A Users Hierarchy of Digital Needs

Leave a Comment


There is some great discussion in the community about the importance of User Experience compared to Developer Experience. Nolan Lawson added a fun analogy to the mix with his piece on composers and audiences, reiterating the fact that users don’t benefit directly from our naval gazing.

Of course, the story isn’t “UX vs. DX!”. It isn’t an outright war between the two, and in fact they can work well together. Unfortunately it is easy to get the balance in the force wrong.

Jake Archibald had another great post on the new streams API for the Web. One of his examples talked about flow control, and how this new capability allows the streams and the platform to work hand in glove:

Imagine we were using streams to download and display a video. If we can download and decode 200 frames of video per second, but only want to display 24 frames a second, we could end up with a huge backlog of decoded frames and run out of memory.

This is where flow control comes in. The stream that’s handling the rendering is pulling frames from the decoder stream 24 times a second. The decoder notices that it’s producing frames faster than they’re being read, and slows down. The network stream notices that it’s fetching data faster than it’s being read by the decoder, and slows the download.

I content that we may have a backlog issue where the communities focus may not be in flow with the platform.

The Hierarchy Of Needs

Back to the diagram above. Here are the pieces of the pyramid and how they fit together in my mind.

Something Worth Doing

First of all, we should be building something that users need or want to do. This doesn’t mean that it has to cure disease, or only be something of social good, it just means that people see a use. Most startups fail because the timing of this use, a lack of marketing it, or the product not being good enough (see below) causes the rest to be moot.

This is the base. Few want to waste time building something that no one cares about. We want to solve problems and should focus here first.

Is Our Platform Capable

I would love to teleport anywhere in the world. Currently we don’t have a platform that supports that however. We next need to map the problems that we see into a solution that can actually work for our users today (ignoring R&D and academia).

We also need to work with our platforms to help prioritize the capabilities of the future. As their consumers, we need to help inform them as they may not be consumers themselves. This is an example of flow control.

  • If the platform builds features that aren’t used then there is a bad backlog.
  • If the platform doesn’t build features fast enough then we are left to our own devices, which could mean idle hands or leaving the platform.

I believe that one reason that we get a lot of DX tinkering in a community is when the platform isn’t keeping up. There are other reasons for this too however:

  • We are in an experimental phase where we have new capabilities that we are pushing and stretching
  • Productivity is a bottleneck (see below)

Can Our Users Actually Do It

Now we have the capability for a solution, can we design something that works for real humans. This is where the user experience kicks in to gear. It doesn’t matter if your platform has amazing capabilities if they aren’t wired up in a way that makes them usable.

Can It Perform Well Enough For Them To Keep Doing It

Performance builds from here and has strong ties to the usability and capabilities pieces below. Performance can make or break you. It is often the bottleneck, for example: OCR, VR, speech recognition, AI, etc. We have envisioned how computers could help us in some many places where we have needed R&D across many vectors to make them usable and performant.

Can Developers Fix and Iterate

If we can in theory build a great performing user experience, we then need to make it work in practice. It needs to not take a life time to build features. We need to be able to debug and fix issues in short order. You shouldn’t need to be an enlightened guru to be able to eek out the performance out of the platform, there should be a clear well trodden path.

You can see how all of these fit together and are important. What is the bottleneck for what you are trying to build? It may vary.

We need to work the flywheel across all of these, and when we do so great things happen. Our mobile users have new needs that we need to solve. We need to build offline first experiences that perform well for them and allow them to get their tasks done. We need to have developer ergonomics that allow developers to easily build out these features and keep iterating to solve more problems.

From problems to solution ideas to platform capabilities to user experience to developer experience. We walk up and down the stack all day. One learns from the other. The more we can do to get a reactive well oiled machine, the more we can get done.

This is why I think it isn’t UX vs. DX. This is why I think we need to work together better than ever. Our users are counting on us to do so.

The right thing to do, is the right thing to do.