In this edition of the Community Interview series, we sit down with Brett Langdon, a long-time contributor within the Datadog ecosystem (notably as the maintainer of the node-dogapi library). To our great pleasure and honor, he recently joined the Datadog family! Read on to learn more about Brett and his approach to coding and open source participation.
The interview
Dan
Hello, I'm Dan with the Datadog Community team. I'm here with Brett.
Brett
Hi! I'm Brett Langdon. I'm a software engineer and DevOps consultant, and I like Datadog! I've been a long-time user at a number of different companies—since back in the old days before all the cool new features you have today, like APM, Logs, Watchdog, etc. I've also been a contributor since the start: I've got commits in the Agent, have written a bunch of Checks, and helped write the Celery Integration for APM. I also built and maintain an open source Node package for the Datadog API: node-dogapi.
Dan
Fantastic! That is actually a much deeper range of contributions than I was aware of. Let's start at the beginning: over the past four or five years, from your perspective, how has the Datadog open source experience evolved?
Brett
What's there in open source tools that are provided by Datadog is fantastic. For the most part I generally don't need to write anything custom for Datadog anymore, because over the past four, five, six years—however long—the open source community and Datadog have been contributing in big ways. Back in the beginning, if you used anything non-standard, you pretty much had to write it yourself and Datadog would hope that you would contribute it upstream for everyone else to use. But nowadays, everything is already available!
Brett
Given the age of the projects, I think that it's actually easier for new contributors to contribute to Datadog because there are so many examples! There is pretty much a type of Check or Integration for almost any type of tool, and that makes everything really easy for people to write new tools, or write new Checks, or new Integrations—whenever they actually need to.
Dan
I'd be interested to know about are your thoughts on what's under the hood—the API, either web or programmatic, for example. How have you seen that evolving over time?
I’ve been working with Datadog code for a long time…
Brett
It's been a while since I've contributed to the Agent or written a Check or anything like that. APM is probably the most recent thing that I've contributed to, and it was in beta so pieces were still moving around when I was contributing.
Dan
To be fair, things are still moving around now, so…
Brett
Yes, and it's interesting! Datadog is investing time and effort in to re-factoring and re-thinking how someone goes about doing an Integration or writing code, or even what the code API looks like. As a user, you know things are getting better. Datadog listens to the community and listens to the pain points. You can tell they have a bunch of their own engineers working with this stuff every day.
Brett
I think one of the problems that you end up with—and this is for any project that lives longer than six months—as you try and change, and refactor, and adjust some things internally, you're going to have some issues. For example, this uses the old style, and this uses the new style, and this is some weird hybrid… sometimes it can be hard just reviewing the code itself to know what the right way of doing something even is!
Dan
Haha, tell me about it!
Brett
I've been working with Datadog code for a long time, and to be honest, I've never really read any of the documentation on the website. I usually just jump right into the code—just get in there and get my hands dirty. As someone who takes that approach, sometimes it can be a little like, "Hm, that's interesting," or, "Why are these two files structured completely differently?" But, like I said, I think that just comes with the age of the project too. I know that Datadog has a responsibility to maintain as much backwards compatibility as possible in the best interest of the community.
Datadog listens to the community and listens to the pain points.
Dan
Moving on from the Datadog code, you mentioned that you maintain a Node library as well? Please introduce us to that—what was the impetus for its development, for example?
Brett
I'm going to pull up the repository right now. Wow, yeah, 2013 was the first commit on that! It's been around for a while, and it's gone through at least one full rewrite during that time. It's funny—I assumed you'd ask this question, and I was trying to think through why I started this project in the first place. I think the real reason is that I liked Datadog as a company, I saw that no one else had the library, and so I decided to write it. I've actually never used the package myself for work, or for a project, or for anything! I just saw that there was a need for it.
Dan
That's… not the answer I was expecting, haha. How do you write and maintain a thing that you don't actually use?
Brett
For something like this, you're writing an integration for an API that is documented. So as long as you keep the code up to date with the documentation, and you implement all the end-points, and make that available in a nice consistent way, it's actually not that hard. You just need to stay up to date on it. You don't need to use it to know how to use it, because it's just an API.
Dan
Alright, fair.
Brett
Because I don't actually use it, I'm not actively contributing much code anymore. I maintain it, but right now it's driven by the community. There are issues from time to time: "Hey, this endpoint is broken," or, "This is a post instead of a get." I can take that feedback and make small changes as needed. But it's definitely just long-term maintenance as opposed to actively developing. I think that's a little unfortunate—but, like I said, I think that that just comes from the fact that I'm not actively using it, so that's the approach I take.
Dan
What's interesting is that it's mostly community contributions. You actually have your own community. It's sort of like orbits or degrees of separation.
Brett
I think that is a great way to think about it.
Brett
Personally, Datadog has always been very accepting of my contributions to the code base, on whatever project I've ever contributed. The engineers have been very open and responsive, and they're willing to work with me. I've always felt gratitude for the code that I've contributed. And that means a lot too. You know you make your first contribution and you have a bad experience, you're not gonna keep doing it.
Dan
Are you involved in any other open source projects that you have a role in maintaining, shepherding, mentoring, PR review, stuff like that?
Brett
Not right now. I used to be much more active in the open source community as a whole, but my involvement tends to vary based on whatever job I have. If I'm in a job that does some open source contributions it just starts to become part of my day to day life. For the past year I've been a consultant and rarely do people pay consultants to develop open source software, so it's just a mind shift in where my time has been spent. But, with my next adventure, I'll be able to contribute more to open source.
I liked Datadog as a company…
Brett
In fact—I will be working at Datadog! My actual job title will be Open Source Software Engineer, and I will be working on the Python APM. That was actually a very huge part in my decision. The opportunity to come to Datadog—a company that I care very deeply about—and to have this opportunity to get back into the community and to get back to contributing to open source. Well, that was pretty much the main deciding factor in joining the team.
Dan
Fantastic! Thanks for taking the time out to chat—and I look forward to working with you!
Keep the story going!
If you’re interested in developing for the Datadog platform, check out the Developer Tools section of the Datadog docs—don’t miss our regular Community Office Hours either!
