Every API product manager wants as many developers as possible adopting and using their APIs. They want them to get to Hello World quickly and have a great developer experience (DX) along the way. Of course, the bigger goal is to be able to tie API success into the larger objectives of the company. For many, despite the best intentions, their metrics are too simplistic, narrow, and based on outdated models of engagement.

With complete API analytics, you can guide API users throughout the entire journey — from signup and education to Hello World and app deployment. Often, it’s not…

You’ve built an API to solve technical problems, but you know that’s just the beginning. In addition to helping developers use it, you need to understand how they use it. You want to measure its performance and popularity, and make adjustments based on what you discover.

Maybe some developers are seeing a lot of errors when making API calls or it’s taking too long for them to get to the first “Hello World.” Perhaps the number of developers converting to paying customers is below your expectations. …

Incident management is an always-on responsibility, but after your last sprint, you deserve a long rest and peace of mind. Your incident response plan may be the furthest thing from your mind and if it’s well-configured, you can finally sleep soundly. A robust incident response plan gives your organization coverage and confidence to identify emergent security threats and rapidly execute the appropriate response. In this post, we’ll cover detection and communications workflows that will enhance your incident response program and take some stress out of your on-call cycle.

We’ll assume you’ve done some preparation to create an action plan with…

Cloud native engineering is a flexible discipline. However, the many DevOps tool options and integration methods can be confusing. More complexity often means more difficulty automating tasks. DevOps programs should evolve toward process improvement. Improvements in code delivery will drive greater transparency in project communication, wiser adoption of shared resources, and make more room for quality assurance.

In this post, we’ll look at three examples of DevOps automation. They use Jira, Jenkins, and Docker — but the concepts of event-triggered workflows will translate to whatever tools you use.

Build Resources (and Transparency) From Work Tickets

Transparency is key to open communication within DevOps teams. Imagine a world…

To become a well-versed engineer takes years of practice. There is usually a determination that it’s your calling — or at least your vocation. But many more people dabble. They poke around at things to try to figure them out. They tweak and experiment. These casual coders do it for fun, to solve problems, or both.

Being a professional coder involves a daunting learning curve for someone who does not know to code. However, it can take just a few hours to dip your toe enough to feel like a casual coder. You may not be shipping production apps right…

With January coming to a close, it’s a good time to reconsider those goals and resolutions. How about starting (or improving) a coding habit?

Around this time four years ago, Ryan Seys did exactly that.

Ryan was a college student at the time, and received a challenge from a friend. It was not your typical collegiate dare. Ryan’s friend instead suggested they both attempt to commit public code to GitHub for 30 days straight. The friend just made it a week, but Ryan hit the goal and then just kept going.

That’s the power of building positive work habits —…

The most important element to developer success, with APIs, open source, or other tools, is documentation. Yet, any developer will tell you that most of it isn’t very good. Bad documentation happens on accident, for a lot of reasons…

Busy working on the product

Don’t know enough about the product

Know too much about the product

Haven’t found the time to focus on it

Not sure what needs to do in the docs

Haven’t encountered your undocumented problem before

Too busy with support requests

Too busy with sales

Haven’t hired that role yet

Docs are “good enough”

Developers aren’t their core customer

Waiting to finish a redesign

Want to completely re-imagine the documentation experience

Too many products to document

Nobody thinks it’s their job

Everybody thinks it’s their job

Well-designed products shouldn’t require documentation

They’re working on it


It’s rare that engineers are idolized in their own companies for everyday efforts. So, it’s especially notable when another company turns you into the hero. That focus on developers is the foundation of Twilio’s story. Many other API providers seek the adoption and success of this communications company that just went public.

Photo by Ed Yourdon

I have been watching from the outside, as a developer and API journalist, since 2009. Early on, and consistently through its growth, Twilio has focused on the entire experience of a developer using its service.

I have a hypothesis about APIs: a lot of the people who want to use them are non-developers with a business problem.

Katie Tegtmeyer

Yet, so much of documentation and resources are aimed at an incredibly technical audience, building robust applications. What if the potential majority of API integrators just have a problem to solve so they can move on with their job?

This is not about everyone learning to code, because not everyone needs to be a full-time programmer.

What do non-developers with a business problem want? They want to solve their business problem. That’s it. If the solution requires using…

Adam DuVander

With APIs and people, anything is possible. Mostly it’s the people.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store