Tim Lane
Bio: I a software developer working in the circus and entertainment industry producing simple HTTP APIs for use within my company.
Role: Software Developer
Company: Software Developer
Industry: ACME Corporation
API Evangelist Conversation with Tim Lane
This is the second pilot for the new API Evangelist Conversations podcast. This is an off the record edition where I interview my alter ego Tim Lane, but obfuscate my voice and hide my face. Like the first one, it isn't that smooth as it is awkward to interview yourself, but I am also just getting started with all the production around this series.
Who are you?
I'm Tim Lane.
What is your role?
I'm a software engineer.
Where do you work?
I work for Acme Corporation.
What industry do you work in?
I work in the circus and entertainment industry.
Are you an API producer, consumer, service provider, tooling provider, or analyst?
I produce and consume APIs. I wouldn't say I'm good at it, but probably better than most.
I take the time to think about the business and technology of APIs, and I slow down enough to put on the hat of my API consumers. I like a simple API. I don't like it when my APIs get too big and bloated. I prefer to keep them separate and modular unless they work together to accomplish a specific business objective.
I take care to make sure my APIs are intuitive and easy to understand because I have used a lot of APIs in my career and I do not want people to go through the pain and suffering that I have gone through over the years.
Why do APIs matter?
They are an easy way to make data available. I don't have to learn a lot about or care about your back end or the programming languages that you use. APIs make it easy for me to provide data, code, and other resources inside and outside my company in many different applications. API gateways make it easy to do the authentication, rate limiting, and other things I don't like to do over and over with each API I build.
So I really like being the guy who can create easy, simple to use APIs that can be used in any way you like in any type of application. The best part of all of this is I don't have to do any front end work.
Are APIs a priority with your leadership?
On the surface they are and, and in word they are, but they really don't have a clue why they matter or what, what, what they do.
I guess I need to do a better job of educating them. I also need to convince them to invest more in educating business teams on why API's matter and how they work right now. API first is just a buzzword that you have to say, or people think you sound stupid, but honestly, there isn't much behind it other than talk.
If I asked anyone to walk me through what API meant, nobody would be able to do it. I'm sure, uh, you catch me on a bad day. I probably can't articulate it either.
What is your biggest challenge with APIs?
Well, just carving out the time to do them, right? I have such a huge workload as well as a full calendar of meetings and, and in a company that doesn't really value self service and I'm in an immense and often unrealistic amount of pressure to deliver new products and features.
If I could just get 25 percent more time without meetings, I could move mountains when it comes to the consistency, quality, and reliability of my APIs. Instead, I find myself cutting corners on documentation, examples, and other resources that would save consumers of my APIs time and money. And since most of my APIs are used within my own company, this would save us a lot of time and a lot of money.
Why do you think people don’t care about APIs?
People just take them for granted. Kind of like electricity or water. They just expect them to work. And then they don't really think much about it until they get their bill. I don't think people see APIs when they're viewing a dashboard in their work or swiping through their Instagram feed.
They see the end result of those API resources. But I don't think they often associate this with anything. I don't think they ever think much about it. People tend to be aware of the, just unaware of the number of APIs that, that they depend on each day, let alone who makes those APIs and how those APIs are shaping their world.
Honestly, I think even if they did know more, like me, they still wouldn't be given all the time they need to think about it. They just don't have the time in their day or the priorities to properly pay attention to APIs.
Do you work with REST APIs?
Yes, that's all I work with. One team I was on for a while was experimenting with GraphQL, but I've never actually seen it put into production.
I would say my APIs are almost always REST, or whatever that means. I, I read one time on, on level, whatever rest and hypermedia, but it really seemed like, like too much for me. I just use HTTP to make JSON available via different paths. I keep it simple, man. I do try to keep things plain language using resources.
I use my HTTP methods and I put a lot of thought into how I expose different resources, capabilities, and other algorithms. But honestly, I don't sweat it too much. I just think a simple HTTP API will win out over any type of API just because it's really cheap and easy to use.
Do you use OpenAPI?
I do. I started using it to generate redoc documentation, and now I'm using it to generate SDKs.
I think I've also imported them into Postman to generate Postman collections. I've even begun hand editing them to improve on them. I wouldn't say I'm designed first as I depend on the Amazon API gateway to generate my open API for me, but I do spend a lot of time cleaning it up and improving the design of it.
So it looks better in documentation. It is handy for, for also sharing with people who use my APIs. Like I said, most of my API consumers are internal in my company, and I find it really useful for answering their questions. I just give them an open API most of the time and, and they go away.
What is the most interesting part of your job?
Solving problems. Actually solving the problem for whoever's using my API. I see understanding their requests as a kind of puzzle. I love it when they give me requirements and tell me their story, and I'm able to come back with something that reflects what they need. I like learning how people who need APIs in web, mobile, or even now artificial intelligence applications, how they see APIs, data, algorithms, and other things that I can make available.
I like it when I get to produce an API, but also consume other APIs as part of the process. You have to be mindful of your dependencies, but API orchestration always makes for a really cool puzzle. Keeps me interested.
What book are you reading?
Uh, I'm reading a book on artificial history of natural intelligence, thinking with machines from Descartes to the digital age, it's written by David W. Bates. Not really excited about the whole AI thing like everyone else, but I enjoy reading about how we got to where we're at. Both the technology side, but also just what we think intelligence is, let alone artificial intelligence. A lot of what we collectively believe about artificial intelligence It comes from a lot of really messed up concepts involved with religion, white supremacy, and colonialism.
I'm more interested in why people are so interested in AI than I'm interested in AI itself. I actually think there's, there's a lot more there to talk about. Then what API does in, for me as a software developer.
