I enjoy thinking about the API space from the 250K level. It is interesting to study what is, what has been, and where things might be going when it comes to APIs. I find it compelling to learn about how API providers, service providers, and investors see things, then reconcile that with what actually happens on the ground. Looking at API change across business sectors has lifted my view from 100K to 250K, allowing me to not just understand how the tech echo chamber sees APIs, but also how mainstream businesses and government agencies see APIs. Always pushing me in new directions, helping me see beyond any single silo I might get trapped in along the way.
Watching the API lifecycle come Into focus over the last decade has been interesting. Watching API management shift how we generate revenue from our software, witnessed API design come to life, as well as mocking, testing, and other stops along the API lifecycle have all been educational experiences. I like to think about API-first, and how progressive developers are delivering high quality APIs from end to end. Studying, listening and writing about these concepts, then repeating, repeating, and repeating, until I push my own understanding to new heights. This is what API Evangelist has been for me. It has been something that has allowed me to constantly reinvent myself, and establish goals continuing to grow and understand the landscape, even after burning out a couple of time along thew ay.
While I thoroughly enjoy thinking about the lofty API lifecycle stuff, I also thrive on understand what developers face on the ground. You’ll always find me hacking away on a new API prototype, or playing with a new piece of infrastructure. And, you will always find me advocating for developers needs over those of business leaders—it is just how I am. I understand how essential it is for me to stay close to the action, while still also understanding how things work up at the top. I definitely can’t ignore the business and political realities, but hearing what developers need to just be successful in their work matters a great deal. If it ain’t making a developers life easier, it probably isn’t worth keeping track of as part of my research—all of my lofty thoughts are rooted in this reality.
In my experience most API providers and consumers don’t care about APIs, services, tooling, and process as much as us analysts do. That is OK. They are more concerned with what they need to get their job done, and be successful at the company, organizations, institutions, and government agencies where they work. They tend to not care about startup exits, or the most relevant standard. They want friction reduced in their daily lives. They want to just get this project done, and done right, so they can move on to the next project. They may enjoy hearing.a good story from time to time about the best way to be doing APIs, but most of the time they just want it done for them. They just want the API designed, deployed, mocked, tested, managed, documented, and secured for them. They don’t want to have to understand the nuance, pros and cons, and other challenges that come with moving throughout the API lifecycle.This is the honest reality of the API lifecycle.
I feed off these realities, as well as the ups and downs of studying, thinking, and writing about APIs. I like thinking about the big picture, and learning about how individual or teams of developers are getting work done. I like knowing there is no one right way of doing APIs, and learning about all of the ways to deliver them throughout the API lifecycle. It is what keeps me coming back. I’m also getting used to things not always going the way that I would like them to. I’m getting used to the world not working as we think it will. I’m fine with being wrong some of the time. It comes with the territory. It helps me not get to attached to any single vision of the API space, and leaves me more open to listening to what others are doing on the ground floor, and coming down from the clouds to see how the bits and bytes are moving around. Building bridges between what different folks are doing, and rooting my lofty visions of the API space in postitve developer and end-user outcomes is what keeps the API Evangelist train moving forward.
