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.
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 —…
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.
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.
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…
With APIs and people, anything is possible. Mostly it’s the people.