Investing The Time To Learn API Best Practices So You Do Not Reinvent The Wheel
14 Aug 2017
I was on a call the other day with a group of people who are in the trenches of organizations and companies working hard to deliver human services in cities around the country. We were meeting to kick of the design phase of a new type of API, and after they shared all their thoughts via project documentation, they were asking me to help identify examples of best practices from the space. The group felt they didn’t have the time, or the awareness of what is going on to be able to identify the best practices that already exist across the space.
This is one of the reasons I stay out of the weeds of individual projects. I may help define, design, and even shadow the deployment and management, but I work hard to avoid the tractor beam of ongoing projects so that I can pay attention to the bigger picture and help share stories about what I’m seeing. I feel like there should be people like me in each industry helping shine a light on, and aggregating of best practices when it comes to the API life cycle. There is just too much work to be done, and it helps to have folks who have domain expertise, not just lightly understanding what is going on across many sectors like I do.
I think it is fine for the sector to depend on API analysts like me, but I think that groups should also be investing in the time to pick up their heads up and pay attention to what else is going on when it comes to APIs in their industry. I understand that many groups are busy keeping systems operational, and dealing with real world problems, but dedicated reading of blogs, white papers, and tuning into social channels for other API providers is important as well. Each decision made on API design, deployment, and management should be established from time spent reading, and learning about other existing approaches–minimizing the amount of wheel reinvention that occurs.
The amount of time you invest in learning about other successful API providers will pay off in the amount of time it saves you when defining, designing, deploying, and managing an API. Sadly, it is one of those areas that some companies aren’t always equipped to measure the return on investment from something like this, resulting in many companies limiting the amount of time API developers spend reading blogs, and actively researching existing implementations, leading design patterns, and healthy API practices. If your boss is ever giving you grief about the amount of time you are spending on learning about other APIs, make sure and point them in my direction. I’m happy to help them understand why you don’t want to be reinventing the wheel when it comes to web APIs.