June 13, 2022

How To Become A Developer Advocate | A Developer Advocate From Stripe Breaks It Down


Do you enjoy creating content or even just have an interest in understanding users who use a product? Especially if you have coding knowledge, have you ever considered a developer advocate role? I brought on Mike, a developer advocate for Stripe, who clearly is passionate about what he does. We went over a range of things from what he loves and hates about the position to all of the different pathways to becoming a developer advocate. If you're trying to break into tech, I highly recommend you hear what he has to say.

Mike Bifulco (guest):
Twitter: https://twitter.com/irreverentmike
Linkedin: https://www.linkedin.com/in/mbifulco
Website: https://mikebifulco.com

---------------------------------------------------

🤝  Join our junior friendly developer community:
https://discord.gg/H69QqZ8MVJ

🔥  Want more personalized help from me? Here are the paid mentorship and review services I offer:
https://calendly.com/donthedeveloper

❤️  If you find my content helpful, please consider supporting me by becoming a channel member and get access to additional perks. Every little contribution helps and is actually used to pay my bills.
https://www.patreon.com/donthedeveloper

---------------------------------------------------

Disclosure: Some of the links below are affiliate links. This means that, at zero cost to you, I will earn an affiliate commission if you click through the link and finalize a purchase.

📚  Web development books and other products I recommend:
https://www.amazon.com/shop/donthedeveloper

Justifiably Proud Productions
Justifiably Proud Productions is a podcast that recognizes life, leadership, and...

Listen on: Apple Podcasts   Spotify

Ways to Change the Workplace with Prina Shah + Guests
For those who stand against crappy work cultures, lousy leaders and toxic teams!

Listen on: Apple Podcasts   Spotify

Transcript

Don Hansen:

Welcome back to another podcast episode where we help aspiring developers get jobs and junior developers grow with this new series. We're going to go ahead and continue it. I want to start introducing other tech related positions besides software engineering or where you can use your coding skills to essentially I'm still make quite a bit of money and explore different areas of tech where. It might be more suited for you. So for this episode, we're going to be diving into what a developer advocate is probably kind of touch on developer relations, maybe developer relations engineer. It seems to blend a little bit, so, but I'm going to learn more about that. So I invited on Mike, he's a developer advocate for Stripe currently, and yeah, I'm excited to have this conversation. Thanks for coming

Mike Bifulco:

out, Mike. Yeah, of course. Thanks for having me Don,

Don Hansen:

for sure. Um, so yeah, let's kind of just start with a little bit about your.

Mike Bifulco:

Yeah. Okay. So, um, my name is Mike . Uh, I'm a developer advocate at Stripe. Um, I've been at Stripe for two and a half months or so now I started in March of this year of 2022. Um, I in past lives, worked for Google as a developer advocate on the Google assistant team. Uh, I was a startup founder. At one point I founded a company called simple, um, which was a SAS company for, uh, helping independent scale coworking, uh, businesses run their operation. Um, I also worked for Microsoft and was technical director for an online code school called gymnasium in the past. Um, my background is kind of in front end development. Uh, design, um, and sort of generalist engineering. Uh, I also went to university once upon a time for both mechanical engineering and computer science and, uh, kind of very obviously made my choice to go one way or not the other once I graduated. Um, and, and that's kind of where I'm at today.

Don Hansen:

Interesting. Um, okay. So let have education behind you. What, um, so you were aiming for front end. Uh, what happened with that? Yeah, actually,

Mike Bifulco:

it's funny. I would say that I largely wasn't really aiming for it, but I kind of found my way there by hook or by crook. Um, my, like I said, my undergrad degree was in computer science or one of them was, uh, and I took a very traditional course of computer science, um, study. When I was in school, I went to Yukon up in Connecticut. Um, That program was largely designed around very traditional engineering stuff, like algorithms and data structures and all the things that you see on, um, you know, typical engineering interviews and, and challenges and tests and courts and things like that. My first job out of school, I was working at Microsoft. I was hired as an engineer into Microsoft consulting organization and found very quickly that I had an affinity for not making the, uh, inner workings of, of an application go, but more so making it make sense for the end user using it. So. Uh, at the time that was around 2009 was a really, really like the beginning of user experience becoming a big deal for lots of these companies, Microsoft, obviously it was no exception to that. Uh, and I found myself drawn more to the front end because I was really interested in making sure that the person on the other end of the device, uh, could look at what was going on, understand it and, uh, take advantage of the software. And so. I went from being sort of just as a traditional engineer, to someone who was really interested in design. Um, I actually did 95% of a graduate degree in human computer interaction, uh, which is the sort of intersection of like art, uh, and psychology. And, um, uh, basically is the study of what people do, what they're thinking, um, what psychological, uh, phenomenon you can take advantage of when someone looks at software. And so for awhile, I used to say that like, if I was doing my job really well, You wouldn't know I was there at all. If you use something that I designed, you would be able to look at your phone or a website or whatever it may be, and just use the thing and not think about like, oh, what am I doing? How do I accomplish the task? Uh, so that's what drew me to the front end. Um, invariably I sort of stuck with that in various, um, roles throughout the years, uh, and, and kind of have found that to be one of my strong suits, but really it's all about thinking about how people use things. Uh, what the goal is, how you're getting things done and sort of translating between engineering requirements and end user, um, uh, interactions.

Don Hansen:

That's that's interesting. It, so it really sounds like I liked that. So if you're, you're doing your job effectively, the user is not even going to know that you exist essentially, or that your position exists. And that's a pretty cool way to look at essentially building a quality product, um, and being able to provide, you know, maybe the right documentation or, um, the right, uh, instruction for it. But. I come from psychology. I got a psychology, a bachelor's and, um, didn't do anything with it for a little bit. Right. But I came into software engineering, completely fascinated with just how the user interacts with the website, how they feel about it. Right. And. It's to me. That's really interesting. So I'm getting stuck in a lot of conversations with design, with UX, and they're like, okay down, we don't need you for this, but I want to be here. Right. I want to learn. Um, and I was, I was just always fascinated with Dux. Um, so I mean, you know, in the future, you know, if I wasn't doing what I was doing, becoming a developer advocate, sounds like something that might be up my alley. Um, it sounds really interesting what. I guess, what exactly was it about becoming a developer advocate, developer relations that like really attracted you to it? Was it the user, was it creating materials for the user to explain the product? Like what exactly was.

Mike Bifulco:

Yeah. So that's a really good question and really poignant. Um, there's, there's a whole bunch of history between me starting as a, in, in the user experience stuff, and then jumping into developer relations sort of years later. Um, but it follows a familiar theme. So, um, what it boils down to is I really enjoy the developer relations side of things, because it's a bit about that journey of getting someone to learn, how to do something, teaching someone how to do something, um, and seeing that. Uh, synthesize information into making something that accomplishes a goal or solve a problem that they have. Um, for me, I'm also the first to tell you that I'm a bit of an extrovert. So it's a lot of like getting to meet people and, uh, create things that people will interact with. And, uh, in some sense, put myself in the spotlight when it makes sense to, but other otherwise give people the opportunity to shine. Something for themselves. Um, I mentioned before that I had founded a startup in the past. Uh, when I was working on my startup, one of the things we did there is we built this community of, uh, of, uh, end users of, um, owners of coworking spaces. And in building that community, it was really powerful to see people learning from each other. So, um, To give you a concrete example. Uh, if you, uh, let's say you live in Iowa and you're running your own coworking facility and I live in New Hampshire and I own my own, uh, you and I are not adversarial. We don't have competition. I'm never going to lose business to you bid through through that. So it really makes sense for me to learn from your experiences and for me to understand what you've done to make your business work and vice versa. I can share with you a developer advocacy is very similar. And as I was building that company, I was working with lots of developer advocates from companies like. Google, uh, the Firebase developer advocacy team helped me quite a bit when I was running into trouble, setting up, uh, the software there, um, striped my, my current employer. Um, we were, uh, the, so the company that I ran simple was three people and we were probably one of the very first, uh, Uh, companies that benefited from Stripe, having a developer advocacy program and really in practice, what that meant is that when we needed help, we would sort of get to our wit's end, try something out for long enough. And, uh, when we couldn't figure out how to accomplish the goal we had, we would contact, uh, the people at Stripe and would get, uh, either useful help for like, Hey, here's how you do this. Or maybe this thing is like, what you want to do, isn't doable yet. But we can talk to the engineering team about how we would accomplish that. Um, and so I found that it was really cool to. Uh, sort of make that connection between one thing and the other, um, and be able to, um, both create a product that was doing something, but also influenced the product that we were using to build our stuff. Um, when I jumped into developer advocacy, uh, it was because I really, really valued, um, helping people. And I really like the idea of being able to do things that gets people, uh, from a, to B in a way that they might not have considered before. So. I'm a very lucky guy. I've had a really lucky life and I'm the first one to recognize that. And I really liked the idea that through my work, I can give back to people and reach people who I otherwise wouldn't meet, uh, and get them to maybe start a company or create a product or grow their product or whatever the case may be in a way that they would. Been able to do, or they might not have done otherwise. Uh, and people like me and my colleagues, uh, help help them to do those things every day. Uh, I've derive a lot of satisfaction from that personally. And I think it's really cool to see people grow things. And, uh, that, that is a big driver for why I like developer advocacy so much. And. Um, it uses a lot of the skills that I have. Um, I suspect you, and I'll probably talk about this a little bit, but there's a lot of flavors of developer advocate of people who I work with who have lots of varied skill sets and do lots of different things. And I'm able to take advantage of the things that I've, I've grown throughout my career to assemble something that. The people around me, the engineering teams, or work with the other advocates on my team, the developers who are building stuff with Stripe at the moment, but with Google in the past. Um, and, and that's a really kind of magical thing for me. Uh, and it's something that I think maybe your typical developer persona, uh, probably wouldn't love doing, but it just, it, it hits all the right marks for me. And it's a super fun job and I really enjoyed doing it

Don Hansen:

honestly. How would an introvert do with disposition?

Mike Bifulco:

Yeah, so I worked with a lot of introverts and I think that's maybe surprising to some people. There's a couple of different ways that it works. Uh, there's definitely some introverts who like, prefer to sort of, um, get all of their extroversion out in bursts. And that might be like, Hey, I'm I, you know, super introverted person or even a mildly introverted person. I don't mind getting on stage for an hour, even if it makes me really anxious because I like to teach people. And that's a valuable thing to me. Um, there are also versions of developer advocacy that have nothing to do with sending out under the bright spotlight with a microphone in front of you and talking to people. Uh, some developer advocates do things like just record videos in the comfort of their home. That's really easy for them to do or something they enjoy doing. There are developer advocates who do things like just write blog posts. And if you're a really good writer and you're doing. Uh, teaching people with tutorials. So you can do it that way. Um, even still, there are flavors of developer advocacy, how you kind of mentioned before, um, developer advocacy or developer relations engineers who do things like build tools and take feedback from devs to build things that make their experience as a developer, a little better. So. It's something that can fit a lot of introversion extroversion. Then I think we kind of all fall on a spectrum there somewhere and waver back and forth between how much we want to be introverted or extroverted naturally. Um, and honestly, gosh, if I had to put it into percentage, I think only minority of the folks that I've worked with in developer advocacy are truly extroverted and a lot more people kind of fall in the middle.

Don Hansen:

Interesting. Some of what you were describing, essentially. Um, if you are a writer, maybe you create blog posts, you had talked about potentially creating, um, correct me if I'm wrong, but documentation around like how to use a product. Um, I just had a technical writer. And that's going to be released. Uh, it should have already been released once this is released. Let's just get thrown off on the schedule, but sure. It almost sounds like the exact same thing, but more for the written form of a developer advocate. So I guess like when I think of developer advocate, I know you're going to dive into the different flavors. I, and even just hearing you, I, I guess I, initially I pictured being in the spotlight, you know, having a mic in front of you, recording videos, et cetera. Um, But it sounds like there are a lot of different flavors. Do you, I guess, do you ever work with technical writers? Um, and how would they be different from developer advocates that focus more on writing?

Mike Bifulco:

Yeah, sure. So, um, this is probably something that varies depending on the team you're at, depending on the company you're at, depending on the size of the company and the maturity of the organization. What I'll say is at, uh, in my current job at Stripe and my prior job at Google, uh, people who were in roles that were called technical writers, or sounded like a technical writer, uh, typically worked on developing technical documentation. So more often than not that. Uh, strike.com/docs, writing the things that appear on that page, right? Here's how you use this API. Here's what this library does. Here's, you know, step one through 10 of how to implement something and maybe a blurb explaining the value proposition of that. Developer advocates tend to do more of the, um, somewhere, somewhere in the neighborhood of, um, the art of the possible, uh, right. Like, Hey, here's an idea for what you might do with stripes, APIs. Here's how you could spin up, um, something that would allow you to sell products on. Um, with, you know, kind of a bunch of things together. So Intercom and remix and view and knucks and all these things, uh, whereas technical writers tend to focus squarely on making documentation, really great, making it really understandable and making sure that it's accurate as well.

Don Hansen:

Okay. I appreciate you clarifying. I think that makes a lot of sense and I, I can see that being a little bit different depending on the size of the company, the type, et cetera, and, um, I think, you know what, before I, so we're going to dive into how do you become a developer advocate, right. Um, but before we do that, you had mentioned there's different flavors. Can you kind of go into a little bit more detail about that? Sure. So

Mike Bifulco:

again, this is one of those things that the actual nomenclature will vary depending on the company and the size of the team. Um, but in general, um, there's this thing called developer relations, uh, which in maybe five, 10 years ago, used to be called developer evangelism at some companies, some companies might just call it developer advocacy, but the whole idea is your job is to help developers to. Uh, take the product that your company is building and go do something with it. Um, and accomplish there, something that, that helps them with their problems or build a product or whatever it may be. Um, so the goal of a developer relations organization is a lot like what that sounds like is to form relationships with developers, to make sure that they're getting what they need, that they have help implementing things when they need it, uh, that they know where to go for technical support, but also to then be the liaison back to the organization. Hey, this actually looks like something that's maybe not doing exactly what our developer users want. We should go iterate on this or make it better, or, uh, maybe even be the first customer at the zero with customer of tooling and test things out before it goes out to developers. So to take on the persona of someone who's never seen this stuff before, build from scratch with a new. First of all, does it work? How easy was that? What stumbling blocks did you come across? How can we highlight those sorts of problems and understand how these developers use it a little more? Uh, these organizations are built up of several different job roles. One the technical writer, which we just talked about will sort of write the documentation and help develop that. Uh, there's developer advocates like myself who, uh, formed the relationships with the external folks. Uh, do the liaison Ning to the engineering teams, um, and build things like demos and conference talks or podcasts or videos or blogs, whatever the case may be. Uh, and then there's in some organizations, also engineers who live in these developer relations, um, org that will go and do things like build tooling. That's very specifically for developers. So, um, Put that concretely at Stripe. Uh, we have lots of products. Like we have products that will let you, um, submit payments online with credit cards, right? Uh, that that's a product that Stripe builds the developer tooling that we might build for something like that is here's a command line interface that you could use to make that faster, or to test your thing or to deploy it more quickly or whatever the case may be often in some organizations, developer relations engineer. We'll go and build that kind of thing and maintain it and make sure that it's useful in speeding up the experience of developers. Um, there's a lot of, uh, DRES, uh, who will go and build like extensions for visual studio code or, um, tools for CGI, uh, that that helped to, um, verify that what's being built, uh, is working that kind of thing. Um, I also, haven't covered a lot of other roles that happen in these organizations. There's managers, obviously who manage the teams and make sure that everyone's working and the ship is, um, you know, moving along project managers who will track, uh, projects from start to finish, uh, make sure that everything is happening on schedule, that all the constituents are being consulted, et cetera, et cetera. There's program managers who will do things like look at the larger picture of, uh, the scope of a product and how that fits into the world. Um, often the question is, are we building a product that makes sense, is this, is there a job to do with this thing that we're helping to get done? Um, and in, in a different organization, that could be something like, are we building the tooling that our developers need to get their jobs? Um, and really kind of anything else you'll see in an engine engineering organization can pop up as well. We have, uh, folks who work in marketing that are specific to developer marketing, where their job is to help us write and say like a great Twitter campaign that gets developers to want to try to build things, uh, using our tools. Uh, They might help us plan big events, like big conferences or big moments throughout the year where we want to land something that's impactful that gains momentum on Twitter or a Y Combinator or whatever makes sense. They're not Y Combinator, hacker news, uh, all those things. Um, and, and so there's a lot of pieces that add up to this thing, uh, and really, really, as you can imagine, all of those roles involve different skillsets, different backgrounds, uh, are, are, are requiring them sort of multidisciplinary and cross-functional collaboration. That is pretty complex, but, uh, thankfully requires a diversity of backgrounds and experiences and, um, skills as well.

Don Hansen:

It sounds potentially very multi-disciplinary. Um, I, so when I hear a lot of this, this is interesting. So I think. Pretty inviting to people of different personalities and different backgrounds, which it almost seems like, um, it potentially is a second or third position that you can bring a lot. Like if you work in a tech team, you're building out a product, at least like you could probably bring that experience into a developer relations role or developer advocacy role. Um, but. You expanded on quite a bit. And it sounds like there are a lot of flavors. And when I hear this, I almost think, wow. Um, how does anyone know any specific path to become this? Like what, what is the, yeah, I guess what is the path forward? What are the skills that you need to build? Should you have experienced most likely, should you not? Um, yeah.

Mike Bifulco:

Sure. Yeah. So there's good news and bad news there. The good news is that there's not a specific path. And what that means is that lots of different people can find their way into this kind of work. And really, depending on the team you work on, uh, it might be more favorable to someone who has a strong engineering background might be more favorable to someone who is a strong marketing background or content production background, depending on the needs of the business and the product. Um, the, I guess the bad news from that is if you're someone who needs, uh, like a dotted line to follow from a. That can be pretty intimidating. Um, but I'll say that I work with people who have strict engineering backgrounds, uh, who went to school for engineering, like myself, who somehow ended up in developer advocacy. Uh, I worked with folks who started in completely different, uh, parts of the world working in finance. Uh, one of the most talented developer advocates I ever worked with. Um, studied sociology, uh, and came from like just a world that was so different from me, you know, hunkered over a computer, uh, in undergrad, trying to write algorithms, but really, really great developer advocate because they understand people. They understand how, uh, people learn and the things that go into, uh, um, uh, Sharing information and making sure that people sort of, um, get the things they need out of the world. Um, like yourself psychology can be a pretty important thing too, right? Like there's a lot that goes into making people want to do something or giving them the results that trigger the dopamine receptors that make things feel valuable. Um, there's folks who I've worked with who have business backgrounds as well, who, uh, come from like the finance world who understand. Um, you know, just a enough finance to be really smart in a FinTech, which is what Stripe does, but also somewhere along the way, started dabbling in software development and, uh, have become a really good software engineers and can go and build things to accomplish a task. Even though they may never have taken a computer science final on algorithms in their life that as it turns out, it doesn't really matter. If the job that you're doing is something that's more about producing. Uh, educational information or, uh, showing people how to do something.

Don Hansen:

I think it's a really interesting role. I really do. And I, I feel like with this type of role, one of the most important things that I'm hearing is just kind of an interest for. Yeah, you're almost like, um, you're almost like a bridge between whatever parties that you focus on, but it sounds like you really need to care about people and how they use a product. Is there like, um, is there a developer advocacy role that's outside of product? Cause like, even when you think about like software engineering, sometimes it's. It's agency work and you take in clients and you essentially build a website and move on to the next product. You're learning tons of technologies. So, yeah. Are there any alternatives outside of like a very specific product?

Mike Bifulco:

Sure. Yeah. So, uh, one example I'll give, um, completely unaffiliated with, but log rocket is a company that makes, um, tooling for building web applications and mobile applications that essentially sets up really good logging for your app. Um, they're really truly what the product does. Doesn't matter in the context of this discussion, but they have a really tremendous, um, uh, content production pipeline where the, the log rocket blog has demos and illustrations of how to do things. Any other product under the sun, their whole thing is they'll give you a tutorial on making a mobile app for iOS. One day. The next day, they'll show you how to build with super base. The next day, there'll be doing something on view and they, uh, I'm sure they take external collaborations, but, um, I would guess that they probably have developer advocates or something like a developer advocate working on their staff. That's just like, Hey, your job is to just go try stuff and build interesting tutorials. Uh, because by showing authentically that like we're a company that invests in building interesting things, invariably, someone's going to get to our blog and then say, Hey, what's log rocket, click on the, try the thing. Uh, and you may grow customers from that. So, uh, there are certainly cases where you're not tied to building the product. Um, there are also some developer advocates that work. More squarely in marketing positions, uh, where the, the developer advocacy org, um, instead of driving, um, revenue through a developers, building with a thing and drawing new money in whatever business model you're set up, maybe the goal at this point in the company is to grow the name. And so the, the goal of a developer advocate, it might instead be. Just reach as many people as possible. Uh, and that could be showing up at events, getting people to do hackathons, sponsoring things, all kinds of stuff that are a lot more marketing E than engineering E uh, and, and so, um, yeah, it really depends on the company which may or may not be a satisfying answer, but it's also as someone who might be seeking a career in developer advocacy, one of the things to do is to look for companies that are doing things that sort of mesh with what you want to do, uh, and try and form a relation. With them, right. Show them what you're doing. Show some interest in them. Um, if they have job openings, obviously apply to those, but like the really cool thing about developer advocates is that their job is to go. Make relationships with people, right. Get to know people. So you sort of have an in, if you're able to demonstrate that, like, Hey, I'm interested in what you're doing. I can do interesting things. Uh, I'm willing to try things and, uh, you know, maybe fail sometimes, maybe dabble in the new thing and just kind of, uh, get a 100 to 200 level understanding of what's going on. Uh, and, and just play around with things. Uh, Yeah, you, you kind of asked about, uh, how people can get into developer advocacy and it's, it's tricky. Um, but it really just depends on who you are and sort of you exercising your, um, your, your desire to try things out and your desire to play around with, um, you know, whatever tooling interests at the time. For sure.

Don Hansen:

That's really good advice. That's really good advice. I liked that. I almost think. If I personally were going this route and bringing my engineering background into it, I think I would probably focus on companies where I loved their product, that I've used it. And when I use a product for a long time, I'd probably submit more bugs or suggestions than anyone else I do. Maybe I annoyed the companies might, but I feel like those are also the companies that I probably should seek out to see if they have that type of position. Would you say maybe that's a good starting point to focus on products that.

Mike Bifulco:

Sure. Yeah. Uh, so two, two good bits there for literally any job in the world that you're trying to apply to. It doesn't matter what skill set you're getting. I think it's a really good idea to apply to companies that you love. Uh, this is advice I'll give to anyone for any job, make a list of 50 companies that you love, regardless of whether or not you think they would hire someone like you and go try and meet them. Go tell them that like, Hey, I love your thing. I don't know how it can be useful. But I want to be, let's figure something out. It doesn't always work. And, uh, you know, it can be tricky in, in, uh, companies where they're totally like 180 degrees off from your skillset, but it's an interesting thing to do, and you'd be surprised the responses you can get. So one starting with companies you love is a great idea. I also think Don, if I asked you about. In, in your journeys, building software, if you've interacted with developer, advocacy groups, or teams or companies that you've liked, you could probably identify a few. And if it doesn't come to mind straight away, one of the things I would ask you is have you ever opened an issue on something on GitHub? Actively participated in a discussion there with that team, that in a sense you opening the issue and, uh, having that discussion is you doing developer advocacy? You're saying, Hey, I'm a developer, I've got a problem. Uh, here's what I'm bumping into. Am I misunderstanding this? Or is this a real thought or whatever the case may be? Does that make sense? Yeah, that makes a lot of

Don Hansen:

sense. That's really good advice. Like you said, that advice could expand to. Quite frankly, to a lot of aspiring developers. It's, um, it's a pretty oversaturated market at the entry level. A lot of people want to get into it, um, and there's opportunity there, but I really see people standing out when, you know, they've reached out to a developer on the team that has a blog and you're like, oh, this is really cool. I love accessibility. You, you talk about this all the time. Is that what your team prioritizes? I mean, just even. Just any type of opener to him, really help get you noticed. So I guess thinking more specifically for, um, software engineering. So people that are a little bit more, they love coding and they want to blend that into developer app canvas. Oh my God. Developer ag. Can I not say this word advocacy? Um, they, they want. They want to blend it in, but they don't really know how much, um, they should learn how to code or how much code they should actually learn. They don't really know, okay, what stack do I even learn? Um, because you know, it's great. If you get hired at the company that you really want to work with, you can research the stack and you could kind of dive into that and learn more, more the tooling in the, uh, frameworks that that company uses. But, you know, realistically you have to also apply to other companies, right? So. And you're just essentially building like internal tooling for developers, potentially. How do you know how much, what you need to learn and how much of it you need to learn to actually get hired as a developer?

Mike Bifulco:

Sure. So, uh, I will say that I don't think it's a requirement at all to be, to be skilled with the thing for the company you're working at to get a job there. Um, in my case, I was familiar with Stripe before, cause I built a business on Stripe's APIs. That's really cool and really great for me. And it worked out super well, but, uh, you don't have to go sacrifice a couple years of your life building a business on Stripe to, to be a developer advocate at Stripe necessarily. I will also say that I think that, um, in the world we're living in right now, even if you're not yet an engineer or you don't, you're not confident in your engineering skills. Uh, there are many tools out there where you can know and use people's products, companies, products, without writing a single line of code. Uh, and I think we're turning a corner in the technical industry altogether, where we're starting to recognize that. There's this massive, um, wedge of the pie of people building cool things with no code at all. Uh, that is effectively developer advocacy, even though they're not developing with code. Uh, I think it's, if, if you have interests in becoming a developer advocate, you could probably get a job as an advocate by writing no code tutorials for anything under the sun. Right? So show someone how to build something with web flow or how to tie workflows together with Zapier or how to do it with an air table or. Google spreadsheet or Excel or whatever the case may be show interesting ways to automate things and to think about how to solve problems. Doesn't matter if you've ever written a single line of code, you may have never initialized a variable in your life. If you can figure out how to do that, you've shown your ability to think creatively and how to tie things together and solve some problems. If you want to become an engineer beyond that. That's cool. I also think that there's almost certainly companies who are hiring. I, I don't even know what you would call it. A no-code advocate, a non developer developer advocate. Uh, and so you could go that route as well. One of the things that I did, uh, I started a few years ago, which was a, um, more of a way to get some creative energy out than like a cognitive or conscious, uh, approach to the field of developer advocacy is I started a blog for myself. This is where you get the shameless plug. It's my own name.com. Mike bifocal.com where I just started publishing like things that I learned that were, um, but like stuck in my crawl, like, eh, If something was bugging me and I finally found a solution online, it was an obvious, I would write a very simple like, Hey, do you need to uninstall this from your match? Here's how you do that. Or, Hey, I found out vs. Code was running slowly on my new MUN match. Here's how I made it run more quickly. Uh, those aren't necessarily like database tutorials. They're not, uh, product tutorials. They're just like, here's me writing. I don't know I had a problem, I fixed it thing. Uh, and that got me into the habit of writing stuff. Uh, it got me into the habit of, um, turning on the part of my brain that looks for like friction and problems in my life that, uh, were improved my own experience when I solved them. And it got me into the pattern of doing things that are like developer advocacy, which is definitely a convenience I had. Um, I want to put a big, giant caveat on that and kind of everything else I've said that, like, I also had the luxury of time in my life and the privilege of not having to worry about, uh, you know, spending every day of my life, like, uh, working for money at that point. I wasn't, you know, there's lots of folks who probably you and I know who are like, um, in jobs that don't pay them enough to have time to start over. That's cool too. I don't think you need to do that. I think, uh, just showing some interest in showing some creativity as well, more than enough to get you there.

Don Hansen:

That's interesting that you put a big emphasis on the power of creating content, right in your own format. First of all, you gave really good advice where you had suggested a kind of turning on that switch in your brain to solve. The friction in your life, the problems in your life and starting there may, because I, I think even a lot of aspiring developers, they struggle, like what do I build? Um, and that, that's a very, very common question I hear. And that's usually the advice I give them. Okay, well, what problems exist? Right. And that's essentially how I got started in software engineering as a live stream. I built an analytics tool for Twitch and it was. I w I kept building features on top of it, and I knew the user and because I was to use her originally, and then I talked to other streamers. Um, but that that's essentially what got me my first job. Um, so I liked that advice, but also I would argue, so, yeah. You know, there is a situation where people don't really have that luxury and they have a full-time chapter. They have a family, they have other responsibilities, right. But essentially you got to put time into something you do to build up your skills on the site. And sometimes it's going to take a little bit longer. So I'm a big advocate of. Don't give people unrealistic expectations that, you know, they're just going to land their dream job without investing any extra time in. Right. Um, so, you know, even for the people that do have to balance their time, um, you know, if we had to compare getting involved, like getting involved in a good hub, uh, issue in that discussion or getting involved with the developer relations team at a company versus. You creating your own content and showing an interest in wanting to create kind of tutorials and help essentially bridge certain gaps. Um, what should, like if you had to pick one thing, what would you probably prioritize? Prioritize your time?

Mike Bifulco:

Yeah. Given the choice between the two, uh, I would do whichever one, you find yourself more fired up about. Uh, so if you have, if, if you have more passion for, Hey, I tried to use your, your tool. I really want to use your, your library and there's so many problems with it. Or I see these really easy areas for opportunity. Go crack, open a bunch of issues on get hub, start some discussions, give good feedback, provide, uh, you know, meaningful descriptions and give feedback in good faith. Don't just say this thing is terrible, but say like, Hey. I like what you're doing here, but here's an opportunity for improvement. Right? Do do the things that you would want to see if someone was giving you feedback. That's awesome. I think if you have the energy to do that, and if there's something that has inspired you to do that, uh, that's, that's super meaningful and is a great example. And you can link to all of those things, uh, in most cases too, and say like here's a portfolio of. All of the issues I've given feedback on get hub in the last six months, a year, two years or five years or whatever it makes sense. Uh, whereas it may be you like waking up on a Sunday morning and having a cup of coffee and writing a little tutorial on like, you know, here's, here's what I did to make this cool Tik TOK video this week. Or, uh, even here's a tutorial on like how I, uh, you know, rebuilt my game boy advance from 2003 or whatever the case may be. If you have energy to do it, that will show through. And I think your passions will open the door for you just as much as your ability to communicate. So, um, marrying those two things together in kind of either case I think is going to be good. Um, it just depends on where you're at and what, what is going to actually get done for you. Cause I think, uh, it can be easy to say like, oh yeah, I just need to go open more, get hub issues or participate in more GitHub things. Right. I dunno, what are you going to do? Spend your time looking for broken things and try and, uh, you know, hunt down bugs and be helpful that way. Like, to me, that feels like something that could go down a dark pathway pretty quickly. But if you already have an idea of something that like, oh yeah, I was using this thing and I would love if it did X, Y, and Z. And here's what I'm going to suggest for help. Go do that. That's awesome.

Don Hansen:

I like that you've given a lot of different options. Um, and it's a very unique perspective on how to even approach this career path, but like just career paths in general, to realize there's no, even with software engineering, there's not a super linear path. Like I, my whole channel is based on reviewing a bunch of different paths. Right. So. Uh, yeah, there are a lot of golden nuggets of advice here. Um, so I'm going to challenge you with this because I think you're pretty passionate about what you do. You enjoy what you do, and that comes off in the way you talk about it. So hopefully this challenges you

Mike Bifulco:

sure. Fire away. What do you hate

Don Hansen:

about your position?

Mike Bifulco:

Yeah. Um, that's, that is a good challenge for sure. Yeah. So I think, I think one of the things I find most frustrating. Um, this type of job is a tendency to see things in the short-term versus long-term. Um, and this is something that can be probably true for other engineering roles, but I'm going to kind of give you the story from a developer advocates position. Um, if I'm going and testing out a new feature for. What the product is right. If you started a company, you hired me as a developer advocate, I'm testing out something. And I give you a feedback that like, Hey, uh, this works, but it could be better if we did this, this and this, you as the owner of the business, have a stack of hundreds, dozens, whatever of priorities that you need to get done, the feedback I've given you feels very important to me because it's the pain that I've just gone through. Uh, but you may not get to go implement that for. Weeks months, years, maybe never, depending on where that winds up in, in the bigger picture of things. And there are a lot of things that feed into that. It could be how well the business is doing, where the money is coming from for the business. It could be that I've completely misinterpreted the size of the problem or just that, uh, focuses change. And sometimes it's really, really frustrating to be like, Oh, we gotta do, is this, if we do this one thing, it's going to be amazing. Like the sky is going to light on fire. They're going to throw us a parade. Uh, you know, like rainbows will shoot out of my eyes, whatever the case may be. If that. And that can be really frustrating. And sometimes you need to be able to like unplug and say like my own personal value that the satisfaction deriving from this thing is not from solving any specific problem. It's from building out a series of, uh, improvements and suggestions for improvements that over the long-term will benefit this product. And really in the end will benefit the developers for using the thing. Cause my job is to make those developers better, hopefully by making my company better to.

Don Hansen:

I can see that being frustrating. I really can't. And from my own experience, even as a developer, even bringing up the amount of technical debt that we're going to be experiencing, because we rushed this implementation. Um, and knowing, you know, it's, it might be six months before we reapproached this. I mean, I, you know, I, I have some pride as a developer and I I'd like to tackle that early. Um, So, um, you're, you're good. But, uh, with the audio, I, the thing is, what's really difficult about that. It almost feels like you read. The product really grows on you potentially, you kind of get attached to it. You, like you said, you go through the emotion of that bad experience that you just went to and you empathize with the user. That's going to go to that same bad experience. I can see that being really frustrating for that issue to get pushed off a year down the road.

Mike Bifulco:

Yeah. Uh, it can be frustrating. And sometimes we do get the other side of it. We're like 18 months a year down the line it gets fixed and maybe you forgot about it, or like it's become a less red, hot thing for you. And it's really, really pleasant when that happens. And that's good news too. Um, but the reminder of the continual reminder is that like the goal is not to fix any one thing. It is to make sure that the thing is continually improving. The other side of this, that I'll say that that's probably an important thing with developer advocacy. That can be frustrating that I don't have a solution for. And I don't know if anyone really does is like the longer I'm in my role and the longer I'm implementing things and testing out libraries for Stripe and building, uh, with the tools that strike me. The farther away I am from someone who's never seen this thing before. Uh, and the harder it gets for me to relate to someone who's never seen the documentation before, or who's never taken a payment online. Uh, and as a former or a user experience researcher, right? There's like a real value to, uh, being fresh on a problem and not having this sort of snow blindness of being super familiar with it. Uh, and, and losing that empathy for someone who's new to the problem set that's that my company is trying to solve. Uh, it's like an impossible consequence or, you know, unfortunate consequences of the work we do. Um, and so the other side of this is that you have to keep reminding yourself that you always know more than the person who's, who's implementing this on the other side of the fence, they know more about their problems, you know, more about your problems and the key to getting things done is communicating that well and being. Uh, a few Civ and understanding and sympathetic to the position that they come from. Uh, and in a sense, maybe the answer is, uh, hiring more people, having more people come or, uh, just doing more UXC type things where you just observed someone using something for the first time and like remind yourself of what that pain is like. Uh, that that's a big, um, Pattern, I think I've seen in my career. And one of those things, that's just like, that's, that's maybe the Shakespearian cursive being a super experienced developer advocate at any company is like, yeah, you, you can do this stuff with your eyes closed and that's not always useful. Uh, from the perspective of the devs who are using your tools,

Don Hansen:

that's a really interesting perspective. I feel like a lot of people would probably empathize with it in your position. Um, do you feel like. Do you feel like you almost have to like really sell your proposed change and sometimes even talk about it from like propose it as like a financial gain down the road for executives to be able to take it a little bit more seriously and prioritize.

Mike Bifulco:

That's one of those things that just depends, I think, um, on, on the state of the product and the size of the problem, um, there are certain things that are like, Hey, if I found this problem and it puts everyone in the world's bank accounts in danger, then like, oh yeah, they're going to mobilize a giant army to fix that as quickly as possible. Um, being able to. Put things into context of like, here's, here's a problem. We found an area for opportunity for improvement. Uh, this is the size of the bread box that we're dealing with. This is what I think we would need to do it. And here's the benefit in the end doing that honestly, is important more so than like trying to make it sound, uh, important in an out-sized way. Um, because again, it all comes down to that stack of priorities that the business has that they need to figure out where this problem problems. Uh, slides into the rest of the priorities. So I'm being hyperbolic and making things feel like they're much worse than they are, is not a good thing. Uh, but instead giving honest feedback and the size of, uh, the feedback should match the size of the problem as well as possible. Um, and also being open to people saying like, ah, I don't think you understand that maybe this isn't really the problem that you think it is or here's how we thought about it, or here's how we got there and kind of remembering that context as you go through is important. Would that being said, just like any other job, like if there's something that you came across that was like, oh, this is something that we really, really need to fix. We need to plug this hole or the ship is going to sink. You need to know when to raise those alarms and do that well. Or otherwise you're going to kind of get the, uh, the, um, uh, cried Wolf effect, right. Where like every problem I bump into can't be the biggest one in the world. Um, because then they all sound small.

Don Hansen:

That's really good advice for any position, honestly. Yeah. You really did an excellent job going over. So, so many variations of what this position holds and kind of had some getting into it. Uh, very articulate. I feel like I have a much better sense of what developer relations is like. Um, yeah. Uh, this is helpful. Is there anything else that you would add for anyone that potentially is interested in this.

Mike Bifulco:

Yeah, I think, um, we talked about it a little bit, but the value of diversity of backgrounds is really interesting and useful for our developer advocacy. Um, my team that I work on at Stripe as a global team, we're very small. We're about 10, maybe 12 people, uh, distributed around the world. And that's important and interesting and useful because, uh, taking payments around the world is very. Um, there are places where taking cash as the norm, there are places where, uh, only credit cards are used. There's places where it's in the middle. There are places like Japan, where there are local payments methods that are very different from anything I've used in the U S um, that are, are completely normal. And as a US-based developer advocate, I don't really understand like the cultural implications of that. Um, so my team has folks from around the world who have a diversity of backgrounds, which is really cool. Another sort of filter on that is that language is important. Uh, if, if you and I were building a product and suddenly we discovered that most of our users were in Germany, we would probably want to make all of our stuff available in German, but also probably have someone who understands German to make sure that we're conveying the information correctly and we're not missing cultural twos and things like that. So, um, one of the, um, fundamental things about developer advocacy is that like. If you're lucky and you're working on a team with a product that is, um, successful and well-funded, and the organization understands it well, uh, you should be working with people from all over the place who are very different from you who have, uh, you know, a number of languages under their belt. Been, uh, building software in different ways for a long time. And there are so many different ways to get different types of developer advocates that like, that's why there's not a cookie cutter developer advocate, job role, or a path to getting to developer advocacy. Ideally more companies will hire more people from more places who are doing more things. And frankly, between you and me, like, well, you and me and the audience, not just hiring engineers from Silicon valley to build, you know, APIs and tools for people in Silicon valley, like the, the further away we get from that, the more diverse and better products we're going to build for the world. And the more we're going to solve problems that help people who, uh, you know, you and me, Don will never actually meet, but we'll find value. And I think that's a really, really cool. I love

Don Hansen:

it. You really sold, you really sold this profession quite a bit. And I think it's pretty open to a lot of different backgrounds and, you know, I didn't even think about it. Like I can see companies, um, you know, if they have customers that are in Japan or in Germany or something like that, like, it really seems like if people, so a lot of peoples that don't come to me, um, with software engineering or they want to become a suffering. It would be a little bit harder when you're, for example, outside the United States, you want to work in the United States or where you want to transfer or get a visa or some variation. Right. But it almost sounds like a developer advocate is a little bit more open to hiring people around the world that are going to be able to bring those cultures of their customers. Um, that's, that's interesting. So that's definitely something.

Mike Bifulco:

Yeah. Hopefully at least that's the case, right?

Don Hansen:

Yeah. That's the ideal position, uh, potentially. Um, I have a good sense of this. I really appreciate this. Um, yeah, I, I think I'm good on questions. Um, if you're watching this video on YouTube in the comments, let me know what you think about this. And let me know if this is something that kind of appeals to you, or like you just hate it. Like seriously, let me know in the comments. Cause I'm curious, we're going to continue going over other positions, but yeah, Mike, if people wanted to reach out to you and anything else you want to shout out.

Mike Bifulco:

Yeah, of course. So, uh, feel free to chase me down on Twitter. My handle is at irreverent Mike, uh, which, uh, hopefully I'll, I'll convince Don to dropping the description here. Um, I also have a website, my bifocal.com where I build things. Um, I run a community of eight, uh, community. At community for API developers called API as you won't hate. Uh, and of course, if you're building a business and you're interested in building things with stripes tools that stripe.com uh, stripe.com/docs, and you can find hopefully everything you need there. And if not, please reach out to me on Twitter or wherever else you find me. I'm always happy. Okay. I

Don Hansen:

love that. Um, and I don't mind doing a little shout out was stripped. I use it as my payment processor switched over from a PayPal actually. So I got my business. I appreciate your product.

Mike Bifulco:

Of course.

Don Hansen:

All right. Seriously, Mike, thanks so much for coming

Mike Bifulco:

on.