At ReadMe, we think a lot about creating a great experience for the developers that are building with our customers’ APIs. But we care a lot about the folks responsible for those APIs, too! Behind the scenes of every developer hub, there’s a team of engineers, product managers, and technical writers who make the magic happen ✨
Today, we're talking to Justin Jenkins from DriveWealth, who provides APIs that power investing for 100+ fintechs, brokers, and advisors across the world.
Can you share a little bit about how you wound up in your current job and what your career trajectory has been like? Have there been any surprise developments over time? For example, jobs or projects that you wouldn’t have predicted you would be doing, but were drawn to and found you enjoyed, or something similar?
Howdy! Yes, right now at DriveWealth my official title is “Sr. Product Manager, Partnerships” but at most startups, this just qualifies me as “I can do a little bit of everything.” My background is in development, specifically backend engineering working with large data sets and REST services. After building this experience in development, I started working with clients pre- and post-sale. I’ve always enjoyed working with clients and helping to solve their issues, and one of the ways we do that at DriveWealth is with our developer documentation.
Around Christmas 2022, we had a goal of redoing our documentation to be all in OpenAPI. We completed 50+ different public routes with different combinations in six weeks. On February 8 2023, the documentation launched to ReadMe via OpenAPI. I enjoyed this project very much because the long-term result is that we can make updates easier and faster than ever before.
What drew you to working on documentation and learning more about developer experience?
When working for startups, no matter what your official role is, one of your unofficial duties is to find and fix issues. Our developer documentation was one of the things I knew we could improve to help our external developers. The common goal DriveWealth and I had was to reduce overall integration times of our partners. Developers asking less questions on Slack means more efficient development cycles and our partners being able to launch products faster.
Did you have any strong opinions about DX going into these projects, based on your own experiences?
Having only been a developer and not in a position to think about other developers and their experience, I didn’t have strong opinions on DX when we started. I did have an opinion on needing a solution to solve our internal/external documentation.
What’s the most surprising thing you’ve learned in taking on these more DX-focused projects?
That no organization out there has a formula that will work for all engineers or developers. The biggest thing we can do is recognize this fact and constantly get feedback from the developers/engineers in question to see where tooling, communication, and productivity can be improved.
Are there any misconceptions you had ahead of time that you’ve learned more about through this work?
I would say a misconception is that, “If you build it, they will come.” The fact is, just because you add a tool or make a process easier doesn’t mean anyone will actually use or follow it. Let’s be honest, some developers are lazy — not all, but some! And even if they aren’t, they’re probably busy and have a million other things on their plate. So if using your new process or tool means learning something new, you need to remember that and keep it in mind as you introduce and onboard users.
What are the most important lessons you’ve learned, and how have they impacted the way you approach your day-to-day work?
I’ve learned that context in reviewing a PR on publicly facing documentation is extremely important. The more information a developer can provide on the “why” behind a change, the better. As a reviewer, we may not know the context or may have lost the context, because it was discussed weeks ago. When developers err on the side of providing more information, it helps the content reviewers review more quickly and give better feedback when necessary.
What are your favorite resources for learning more about developer experience, APIs, and documentation?
My favorite resource is attending conferences or like-minded meetups. I can always read about different approaches to things like developer experience, APIs, and documentation, but that information is always in a silo. I learn the best from those road-to-rubber moments that come from speaking to others at more mature organizations and their methods. Hearing about real applicable experience/metrics from others is a great way to better inform our organization of the specific benefits of a process and/or tool.
What would be your top piece of advice for someone who wants to learn more about these kinds of projects and incorporate them into their work?
I’d say if you're working in developer experience, then the goal is to be constantly improving. Just because you get to a state where things are good doesn’t mean you should stop — change your POV a little and you can probably find something else that needs improvement. And have fun with it!
Thank you, Justin!
We're excited to hear more about the new developments at DriveWealth, and you can learn more about their experience with ReadMe in their customer story.
More about Justin:
Hey, I’m Justin Jenkins, a Senior Product Manager, Head of Partnerships at DriveWealth. My passions are solving complicated problems with tactical solutions for people and technology. In my spare time, I like to think I’m a great salsa dancer and car enthusiast. I’m always driven by the need to understand what is next and what is needed to overcome the current objective. I am super excited about the advancements in DevEx and technology, and how we can bring that knowledge to DriveWealth.
