Ceora, Ben, and Matt talk with Danielle Man, Director of Engineering at Apollo GraphQL, about how an MIT program for high school girls helped kick off her career, her path from IC to engineering manager, and how Apollo became what it is today.
Danielle’s path to software engineering began when she was accepted into MIT’s Women’s Technology Program, an education and mentorship opportunity for high schoolers interested in engineering or computer science. She later earned her CS degree from MIT.
If McDonald’s is a REST API, then Chipotle is GraphQL. Think about it!
Find Danielle on LinkedIn here.
This week’s Lifeboat badge goes to user torek for their answer to Why doesn’t Git natively support UTF-16?.
Danielle Mann After I did that summer program at MIT, I ended up applying there for undergrad and going there, because once I got accepted there I was like, "Alright, this will be the way." And when I joined, I was undecided about if I wanted to do mechanical engineering or computer science, but I kind of knew that I would do one or the other. And one of the things I realized once I got there is that all of the math that I had learned in high school from my school that didn't really teach STEM very sophisticatedly was, I got to MIT and they were like, "Okay, now you have to combine physics with calculus. Those aren't separate concepts anymore." And at that point I had got really confused by what everything that was going on in physics was, and I was like, "Okay, I'm really bad at all of this applied engineering stuff. I think I should stick to software programming where everything is cleaner and outcomes are either true or false, not many decimal points." And so then I pursued that path for the rest of college.
Ben Popper It's good to learn about yourself. That's what college is for. You're like, "I'm a binary kind of person. Don't give me all these long-tail solutions."
DM I like it when it's clean.
[intro music plays]
BP Avalara NEXT is a free online event for developers looking to build tax compliance into their systems to navigate increasing regulatory complexity. Join them, March 30th, to learn about Avalara's vision and to connect with their developer community. Register at AvalaraNEXT.com.
Ceora Ford Welcome everyone to the Stack Overflow Podcast. I'm really, really super excited for today's episode. I'm one of your co-hosts, Ceora Ford. I'm a Developer Advocate at ApolloGraphQL. I'm also joined by two of my other co-hosts who I'm going to allow to introduce themselves as well.
BP Hey, everybody! I am Ben Popper. I'm the Director of Content here at Stack Overflow, and I'm also joined today by my colleague, Matt. Hi Matt.
Matt Kiernander Hello everyone. My name is Matt. I'm a Technical Advocate here at Stack Overflow. And I'm going to pass on the torch to Danielle to introduce herself.
DM Hey, everyone. I'm Danielle. I'm a Director of Engineering at Apollo where we help people build graph APIs.
CF Yeah, so if you can't tell, me and Danielle share the same workplace. We are employed by the same company. So that's why I'm super excited to have this conversation today. As always, we love to have interesting people on the podcast to talk about the work that they do, how they got into the work that they do, all that kind of good stuff. So we want to do the same thing with you, Danielle. And I would like to kind of hear what your background before Apollo was like. What got you to Apollo? What got you interested in tech and software engineering in the first place? All that kind of good stuff.
DM Well I grew up in the Bay Area, so I grew up kind of surrounded by Silicon Valley and people in the programming profession. And my stepdad is a software developer, and so he was always kind of encouraging me to pursue those kinds of interests. But my high school was very small and we didn't really have computer science classes or anything. So when I was in high school, I just took the standard math classes and standard science classes. And there was one summer, the summer before 12th grade, where a lot of colleges will offer programs for rising seniors in high school to try out things that maybe they hadn't been exposed to in their high school programs. And so I applied to this program at MIT called The Women's Technology Program, and it's for high schoolers. And you go out to Boston for a summer and they teach you how to program in a month. And you try to make a little Tetris game by the end in Python, and I'd never had an opportunity to do that. And so I applied and I got accepted, and that was a really exciting moment for me, because that was the first time I even got introduced to any of these concepts. The program that I did was a combination of electrical engineering skills and then computer science skills. They teach you how to make a circuit, how to make a little radio. But my favorite part of the program was the visual side of things and the programming side. They teach you how to make a little program using Python where you try to animate a character across a page. The assignment was like, "Make a little car. It's okay if your car is just a rectangle and just drive it across the screen." And that's the assignment. And I got so carried away that I think I drove a car and I had a cow and I had a UFO and the UFO beamed up the cow, and I made it very, very complicated and I was like, "Oh, wow. Okay, I think I'm really having fun with this. I'm actually genuinely enjoying it." I took it a little farther than I was supposed to.
CF Cool. Yeah. Where does your career trajectory lead you after that?
DM So after I did that summer program at MIT I ended up applying there for undergrad and going there, because once I got accepted there I was like, "Alright, this will be the way." And when I joined I was undecided about if I wanted to do mechanical engineering or computer science, but I kind of knew that I would do one or the other. And one of the things I realized once I got there is that all of the math that I had learned in high school from my school that didn't really teach STEM very sophisticatedly was, I got to MIT and they were like, "Okay, now you have to combine physics with calculus. Those aren't separate concepts anymore." And at that point I got really confused by what everything that was going on in physics was, and I was like, "Okay, I'm really bad at all of this applied engineering stuff. I think I should stick to software programming where everything is cleaner and outcomes are either true or false. Not many decimal points." So then I pursued that path for the rest of college.
BP It's good to learn about yourself. That's what college is for. You're like, "I'm a binary kind of person. Don't give me all these long tail solutions."
DM I like it when it's clean.
CF Yeah, yeah, yeah. That makes sense. I enjoyed algebra and calculus in school, but I think I'm similar to you. I enjoy more of the straightforward, wrong or right, that's it, you know? Cool, cool, cool. So then take us to what happened after you graduated from MIT and you're done with your CS major degree and all that great stuff.
BP That's an interesting way to evaluate it. I was talking to a venture capitalist the other day who's moved from investing in traditional companies to investing in like the blockchain crypto space, trying to be on the bleeding edge. And he was saying, that's what they look to as sort of a leading signal is developer activity. So yeah, go on GitHub, see which projects are attracting the most attention from people who are building stuff. Maybe that's a good place to invest.
MK Was there any other company that you were looking at as a potential or were you kind of like 100% committed to doing the Apollo route?
DM: It's kind of funny. When I graduated from high school and went to college, I was like, "Oh, I'll go to MIT, and I got in so I didn't really look for other places. And it was similar with Apollo. I had done an internship at GoDaddy, and I really enjoyed my time with them and they had a really wonderful intern program. And so I was kind of thinking I'll go back to them, but why don't I just give my resume to Meteor that one last time and see if they actually look at me this year, whereas every other year they had ignored me, and it kind of worked out. And then it was hard to choose, but I came here and I'm very, very happy that I did.
CF So you started out with an internship and just stayed since then?
DM Yeah, I started as a full-time but junior developer on things at Meteor. But then, because I was the brand new person and they were just starting to look into GraphQL and start this GraphQL project that they were calling Apollo, they said, "Hey, you're brand new. You don't have any context on this Meteor stuff. Why don't you go work on Apollo stuff?" So I've been working on Apollo-oriented things for as long as we've been doing them. But, yeah, since before the company was Apollo.
BP That's super interesting. So like, do you think at the time they were still trying to test the value proposition there? They were like, "This is the new thing. Maybe we'll do this. You're the new person. You try it out. Kick the tires, see if this is worth investing in."
DM Definitely. There's a whole backstory to why Meteor started looking at GraphQL and how that became Apollo that we could go into yeah.
CF Tell us more about that.
DM Okay, so Meteor is a full-stack framework. It was opinionated. Our founders started it back in 2012 and the landscape of how we do web development obviously changed a lot in the last 10 years. And so at the time they made this relationship between Mongo and Node a very important part of the framework. So in order to make a Meteor app, you're tied to using Mongo as your database. I think that that's very successful for people that are starting greenfield because Meteor handles all of the real-time aspects of data transfer between Mongo and Node and then your web browser, which is why people loved it so much. But if you want to actually have that kind of Meteor development experience using any other database that's not MongoDB, you just couldn't use Meteor and you couldn't do it. Meteor handles all of the challenges and complexities of WebSockets and subscriptions for you and that's why people love it so much. But you could only do that if you were using MongoDB. And so within the company, they started looking at ways that they could maybe integrate with other databases. Maybe like a query language that they could put in front of their layer with Mongo, so that you could use that query language and connect to other databases. And around the same time, Facebook open sourced their specification for GraphQL. And I think the folks at the company at the time saw that and thought, "Wow, this looks a lot like what we're doing internally, trying to design this new data layer for Meteor." And so initially the Apollo project just started as building tools to help make GraphQL as successful as possible and to help establish GraphQL as being something that's here to stay. Because that would be the best outcome for Meteor because we can use GraphQL for Meteor. And then I think over time, I'm sure it happened pretty quickly from where the founders were sitting, but I was just a junior developer at the time, so over time it became more and more clear at the company that there was this opportunity with GraphQL that probably had a much, much higher ceiling than any opportunity we could ever have with Meteor, and so eventually the investment in Apollo grew and then the whole company got pivoted to Apollo.
CF Yeah. I think this illustrates the beauty of being in a startup. Things change so quickly and honestly when you're that early on, it's very easy to pivot the whole company, the whole business model into a totally different direction. So I want to hear what was your experience like helping build Apollo from day one at a startup? Like you're a new developer early on in your career. You're also at a new company that's early on. What was that like? What were some of the learnings and challenges that you confronted along that journey?
DM I think in the early days, because we're talking about 2016-2017, the battle was really to catch up to Facebook and catch up with our open source to what Facebook had opened sourced as their client and server for GraphQL. So the early days focus was really on wanting to be players in the GraphQL space and we want to make GraphQL as easy to use as possible. And so I wasn't in a leadership role yet in the company and I was kind of just along for the ride as a developer at that point. But I remember we hosted the very first GraphQL summit conference in 2016. It had maybe 300 people attend total. And I remember the goal of the conference from our perspective was to prove to people that GraphQL was a serious technology. We wanted to bring these leaders from the early GraphQL adopters together, like Shopify and GitHub were the big names at that conference, and show other companies that, "Hey, this technology is really serious. You can trust that it will be here to stay. You can make bets on it and invest in it." And that was really the only point. It just took a while for people to use GraphQL seriously enough for us to have an opinion on what kind of products we should make at Apollo. We can get there later as we talk about it, but at the time we just wanted GraphQL to be successful.
BP Right. So let me interject for a second here. I'll ask the most basic question as the lay programmer, and then I'll let Matt and Ceora follow up after you answer me. For somebody who has a rough understanding of how software development works but isn't in the space themselves or writing code every day, how would you explain what GraphQL does, and then what the layer ApolloGraphQL does?
DM Ooh. Let's see.
BP You can assume I know what an API is. I got that much.
DM Okay. So you know what an API is. API is a way that a client and a server decide to communicate with each other so they can pass data and both mutually understand it. And the most prevalent specification for doing that, specification is like the language that these two entities decide to speak to each other. The most prevalent specification for doing that for the last 20 years in the web has been the REST API specification. And with REST, the idea with that is it's almost like if you go to McDonald's and you're like, "I want meal number one." You have predefined meals, you get whatever is predefined, and there's not a lot of flexibility, but you know exactly what you're going to order. That worked really well for a long time because the internet has evolved a lot in the last 20 years and especially in the last 10 years with the complexity to which we want to talk to people with data. And so 20 years ago when the specification first came out with REST, it was very appropriate for the way people were using the internet back then. But over time we've become more sophisticated with how we want to use our data on the internet. We now have more clients, you have your web client, your iOS client, your Android client, your Roku, your Apple Watch. They all want access to the same fundamental pieces of data but they need it at different levels of granularity, different speed levels, different performance levels. And so the REST specification where you have these predefined menus and you can't change what you're asking for created a lot of challenge for more sophisticated client use cases. Because really, all of these clients want slightly different things. They don't want to have to order from the predefined menu, they want to be able to order a la carte and tell you what they need.
BP Right. I just have to finish this culinary metaphor now because it's too good. And then I swear I'll let Matt and Ceora in, but if McDonald's is the REST API, then Chipotle, where I get to pick and choose, is more like the next turn of the wheel? Graph QL? Okay, great. I've got it now.
CF You got it.
MK I was thinking I was just going to absolutely butcher a McDonald's burger and be like, "You know what? I want a Fish Filet as well as a BigMac Patty."
DM Exactly. And then the Apollo Graph is an extension beyond that. So if you are in a place where you can define your data to be queried more flexibly, like the Chipotle way of querying, then you need to have a really well-defined a la carte menu so that people know what's available, and that's something that you define called your GraphQL schema. So the Apollo Graph is all about you treating that Graph QL schema as a core piece of your product. It's not like your product is just what you're showing your end users through an interface. Your product is the data and you give it that level of care so that people can use it in ways that maybe you didn't even yet anticipate. And you can enable that kind of use case.
BP AvalaraNEXT is a free online event for developers looking to build tax compliance into their systems to navigate increasing regulatory complexity. Join them, March 30th, to learn about Avalara's vision and to connect with their developer community. Register at AvalaraNEXT.com.
MK I am curious, just for my understanding, I've never used GraphQL before, but I'm curious as to where you would kind of define Apollo and its responsibility starting and ending, and then how that integrates with GraphQL. Like what is the value add that Apollo is giving GraphQL that makes it its own kind of entity, as opposed to just GraphQL the open source framework?
DM So GraphQL is a specification. When we were talking about APIs, it's the language that the client and the server agree to use to talk to each other. That's all that it is in and of itself. It is that language definition. And so in order to use it as a developer, you need tools to interpret a language. You need a translator or you need to be taught that language. You need to learn a language to start speaking it on both the client side and the server side. So one of the things Apollo does is build those developer tools so that people can speak GraphQL, but also use frameworks that they're very used to, like React, or Node, or there's an entire community of tools that people have used to help you speak GraphQL. If you're using Python or Ruby there's just like a whole boatload of these things. So one of the things we do is build the tools to help speak GraphQL, and then another thing we do is build tools to help people understand how their GraphQL is being spoken. We can show you analytics on who's using your API and what they're talking about, and that turns out to help you if you're trying to evolve your craft and scale it.
CF You explain that so well, I'm going to have to relisten to it. I have to always explain to people, especially as a developer advocate, and then even with family. They're like, "Where do you work?" And having to explain what GraphQL is and what Apollo does I over-complicate it. So I'm going to verbatim steal everything that you just said whenever I talk to people from now on. Very, very cool.
BP I love it. As you were saying your metaphor about the drive-through I was thinking about a poorly put together API nobody likes. It's like the menu at the drive-through where you keep saying what you want and it gets garbled somehow on the other end, and then you get a bag and it doesn't have the right food in it. So I guess one of the things that I'm also really curious about, aside from the technology, if Matt and Ceora are okay with moving on, is the evolution of your career internally. You said you started as an intern. Did you then move up the food chain as an IC before moving over now to what you're doing more as a director and a manager?
DM Yeah, exactly. I started on the IC path. And when I joined Apollo we were about 20 people. So we had two engineering teams, one that we called the open source team and the other that we called the cloud services team, and I was on the cloud services team. And as the company grew and pivoted, pivots are always really hard for companies. There were challenges with that in a few ways. And there was a person on my team who was my manager, who ended up leaving and so it created a management opportunity. And up to this point, I had been writing React code for the front end for our product, which is now ApolloStudio, but I'd also been interested in filling gaps, wearing hats like you would at any 20 person startup. So one of the things that I had done is gotten myself involved in recruiting very early on. And especially with recruiting interns, I was very interested in that having just come out of college, and it was really confusing to our candidates what was up with our company because we had these two things, both Meteor and Apollo. And so I had just out of the blue made an entire recruiting website on my own. I did it with our Head of Recruiting, and I had it in my mind that he would write most of the content and I would build the website. But the reality was I built the website and then I was like, "Alright, so I need these seven pages of content." And he was like, "Here, I wrote you the content." And he sent me like three paragraphs about culture. And I was like, "Okay, that's perfect." So I put his three paragraphs in the culture page, but then I had to write these other pages myself to fill out this website. And it was a bit funny for me because I was such a junior person and I was like, "Nobody else is going to do this, so I'll take a first pass and then I'll bring it to our founders and I'll be like, do you like what I wrote about your company?" But I guess they did because honestly they didn't ask for any updates. That was our recruiting website for a couple of years. And I think because I'd done that I kind of became visible to the founders, they saw maybe some leadership qualities in me. And so they gave me that role when there was a new manager opening, they invited me to try it out and so I've been doing that ever since.
CF Cool. I want to know, it seems to me like you transitioned to a leadership role pretty early on in your career. What was that transition like? What were some of the challenges, the good things that happened, or unexpected things that happened, and even if you have some tips for someone who's listening who wants to transition into manager roles. What tips would you give them? That's a lot in one, but feel free to answer any of those.
DM Totally. Well, there've been a lot of challenges, but it's also a job that I really enjoy and honestly the environment in which I'm managing now is the best it's ever been for me at Apollo. I'm really loving it so I feel like I've learned a lot in the last five years of doing this. When I first got the role, it was exciting to have that responsibility. I felt very responsible to all the people. But I had no idea how to do the job and I basically didn't have any mentorship. I didn't really have much career experience up to this point. And I'd been working for my co-founder directly for a long time now and he's been learning the ropes of how to do his job just as much as I was trying to learn the ropes of how to do mine. I made a lot of early mistakes for sure. I think with management though there's everything that you can read in a book, everything that you can prepare yourself for, and then real challenges that you just have to live to understand them and to know how to do that kind of thing in the future. And I had plenty of that early on. I feel like I really got a big dose of it in good and bad ways. So yeah, I draw on that experience all the time.
MK Can you talk to any of those good or bad experiences? Give a learning opportunity that you had and then something that really made you think, "This is why I went into management." If you can share those details.
DM I think I fell into management, honestly. I'm very glad that I'm here, but I don't think I as an IC thought, "Oh, wow. I really want to be a leader, and therefore I should go into management." It was more at the time, I was like, "What is a tech career? I don't know. Maybe I should be interested in management. That seems like a thing that people do." So that's kind of how I got started. I think the way in which I really felt, "Oh, wow, this is why I do it," has come a lot later because I think I had to understand the job and feel successful in the job to feel the reward of the job. So what I've accomplished up to this point is I have 20 people that work for me and my group. I've been able to groom multiple managers at our company. I've been able to hire probably like 30 people into our company, control our company's culture, at least in the realm that I work in. All of that to me is like, "This is why I do it." I'm actually really proud of that. It means a lot to me.
CF You should be.
DM It's so cliche, but seeing people grow in their own careers and being able to get that for them, being able to show them that they can progress, that they can lead that project or get that promotion because I've helped them, that's really rewarding for me. Some of the early challenges were just around the team that I inherited. The company was pivoting and so there was a lot of challenge because we were so deeply ingrained in what we were doing with Meteor. And in the end we gave that all away and we sold that to another company so that we could focus on Apollo. And so the time that I stepped into the role didn't have a ton of mentorship, and then there was a lot of disorganization and disarray from the pivot.
BP Yeah. I think one of the things that you said which really stands out to me, along with the idea of managing through change which can be very difficult and is unique to each company, is that you've read books and talked to other people and maybe had mentorship or didn't, but until you experience certain things, you have to learn from the experience of doing them. One thing I always wonder about with people who go from an IC to manager role and then have a large team of folks working under them, I don't know if they're developers or engineers. Do you ever feel that you have to work on the side alongside your job to maintain your technical chops and to know what the changes are that are important so that if you're in a role of managing people who are writing the code, they have a certain level of respect for you or the decisions that you're making?
DM Interesting. I think yes. I don't feel like that's a pressure, but I think I am a programmer and I just love that so much that I like to continue to dip my fingers into all of those pies. I like to have side projects, and because I know the code so well at Apollo I do even like to contribute. I don't have a lot of free time in a predicted kind of way, but around the holiday period for example, a lot of my team was on vacation already and so I found myself thinking, "Hey, I've been wanting this thing for a while. Why don't I just open a PR and send it off to somebody. So I do still get a lot of joy out of doing those things, but the breadth to which I manage folks is much greater than my own technical expertise, and I'm super okay with that. That's not really a problem for me as far as managing the team goes. I don't feel like I need to be the most assertive technical voice in the room. I have a lot of opinion on front end code and kind of the intersection between product and UX design and front end engineering, but I manage infrastructure engineers, data folks, and they're their own experts. And they tell me what they think I should be doing and I trust them and I try to hire people where I can trust them in that way. And it's a really good relationship. And one of the things I had to learn doing this job because I am in a role where I manage very senior folks while I'm still relatively early in my own career. So I had to learn how to be a partner to really senior folks so that we could have mutual trust and there wasn't some sort of weird power hierarchy between our level of experience and our level of age and what we could accomplish together.
CF Very cool. I love that. That's something I think about a lot too as a developer advocate since I'm not strictly technical. I'm always like, "Am I going to lose all my coding skills?" But I think I agree with you. Over time I've realized that while they're important, there are other skills that are also equally important that I have as well. One thing I wanted to talk about too was in the little blurb that you sent us about yourself, you said, "I care much more about the people I'm working with in the day-to-day specifics of my job." I want to hear how that kind of shapes you as a manager and how you work with the people you manage.
DM I think that's a core part of my ethos. I don't really approach my job as saying, "Oh, a Director of Engineering does things like make key replatforming decisions and that's what I do and I'm not willing to do other things." I don't approach it with such strict lines drawn. I see the job as being a gradient and glue and coming from the size when the company was so small, I think part of being glue for a team is wearing a bunch of hats even if you don't really know how to wear them. So in that way I'm not really that bothered one way or the other about what I'm doing day to day, but something that I really care about for the culture of the team that I've built and that I work with is that we enjoy each other's company and that it's actually joyful to come to work. I think work can sometimes be stressful, it can sometimes be toxic. But if things are going well, what I would like to achieve is a work culture where things are actually safe and people love coming to work. You like logging in on Monday's, not to do the job but to see the people. And if you have complicated things going on in your home life or your personal life, work can be a haven from that where things are normal and structured and there's work to get done and you can do it and you can get that dopamine hit from shipping and you can feel good about that. And then you can go back to dealing with whatever else is going on in your life. My goal is to achieve that, and for when we have it to maintain it, and for when we don't have it to get there and that's what I mean by caring more about the people.
BP Very cool.
CF I wish every director and manager was like that.
BP We were just chatting a bit about the IC to manager transition. And you spoke very eloquently about some of the reasons that you do it and the experience and the ethos you're bringing. To take it back to the technical for a second, can you just tell folks over the last year or so, what are some of the things that have happened at ApolloGraphQL that you're proud of or you think are significant to developers who might work with your tools? And then from there, let's look out over the next year. I know you can't show us the roadmap, but what are some things people might be getting excited about and things you might be working on that you think will be significant?
DM Yeah. Well from the teams in my group, we built Apollo Client, Apollo Server, Apollo Client Web, iOS, Android, and then also some of the free and more ubiquitous developer tools and SaaS, and so there are always big wins. Apollo Client 3 was a big win, Apollo Server 3 was a big win. On the SaaS side, something that we're very proud of is we built this thing called the Apollo Sandbox, which is a little developer environment that you can come to to write GraphQL queries, and it's continuing to evolve and blossom and it was very fun to build, and we're very excited about where it's going. So it's a lot of interesting technical stuff that's gone into that especially that we're very excited about. For the coming year Apollo's big focus is on Apollo Federation. And the idea with that is we want everybody to be able to model their data as a graph, because, you can read our marketing website, there are lots of reasons why. And in order to do that, inevitably companies have their data in lots of different places. Bigger companies have lots of teams, lots of microservices, people in different parts of the company need to be able to independently own their portion of the graph. So it's actually very hard to scale a big data graph as one monograph. And what we want to support is for people to be able to make their data in much smaller subgraph sizes, and then federate all those together. And so we've created a technology, we call it Apollo Federation. It helps you make one gigantic graph out of lots of smaller subgraphs. And most of what you'll see from the company over the next year I think is the evolution and continuing maturity of Federation.
CF Awesome. Exciting stuff. It's funny hearing you say that, because that's a lot of what my role has been focusing on over the past few months. So it's so weird to see both of my worlds collide like this, but thank you so much.
BP You made this happen, Ceora. You did this.
CF Yeah, thanks so much for taking the time to tell us about yourself, your career, your managing style, what's going on at Apollo, what your journey there has been like. Super appreciate it, even for me as someone who's fairly new at the company, I loved listening to all your answers.
CF I'm going to close out the episode now. We're going to wrap up with a lifeboat, which is an answer score of 20 or more to a question score of negative three or less, that goes on to receive a score of three or more. So this badge was awarded to someone named Torek. And the question is "Why doesn’t Git natively support UTF-16?" Okay. So with that, we're going to close out. I have been Ceora Ford. I'm a Developer Advocate at ApolloGraphQL. You can find me on Twitter. I spend a lot of time there. My username there is @Ceeoreo_.
BP My name is Ben Popper. I am the Director of Content here at Stack Overflow. You can always find me on Twitter @BenPopper. You can always email us firstname.lastname@example.org with comments or questions for the show. And if you enjoyed our programming, please leave us a rating and a review. It really helps.
MK And I've been Matt Kiernander. I'm a Technical Advocate here at Stack Overflow. You can find me on Twitter or YouTube at MattKander. And I'll pass off to Danielle to finish off the show.
DM Thank you all so much for having me. This is my very first podcast, so thanks for going easy on me. My name is Danielle Mann. You can find me at Twitter Danimman.
CF Awesome. Thanks so much. See you all next time. Bye!
[outro music plays]