Building Bridges: From Developer to Developer Advocate

First Programming Experiences

James Beswick: Hi everyone. My name is James Beswick. I'm the head of developer relations at stripe and today I'm joined here with David.

David Edoh-Bedi: Hi, I'm David Edoh-Bedi I'm a developer advocate. That's right.

James Beswick: David, tell us about your background and how you got to where you are today.

David Edoh-Bedi: I was born and raised in Togo, a small country in West Africa. I’ve always had a passion for electronics and finance. In high school, when thinking about college, I naturally gravitated toward engineering.

My parents, especially my dad, had lived in the U.S. before, so they wanted me to attend university there. After researching, I ended up at Iowa State University, which has a strong computer engineering program. That’s how I chose that school.

James Beswick: What was your first programming language in college?

David Edoh-Bedi: My first programming language was C++. When I started college, I was undeclared in engineering because I wasn’t sure which field to pursue. Initially, I considered aerospace engineering—it seemed cool to me. But as I took courses, I realized computer engineering was more versatile, offering opportunities in many industries, so I chose that instead.

Now that you ask, I remember what first inspired me to program. Back in high school, I used graphing calculators like the TI-89 and TI-92. I had to repeatedly calculate the greatest common divisor (GCD), so I looked through the manual and wrote a program to automate the process. My teacher was impressed and asked how I did it. I just explored the calculator, discovered functions, and wrote one to compute the GCD from a set of numbers.

That experience fascinated me—the idea that you could take inputs, process them, and get meaningful results. It made programming feel like magic.

Transitioning from College to Industry

James Beswick: I actually started with C++ too. It provides great foundational training for a career in development. But what were some of the hardest things you faced when you first started?

David Edoh-Bedi: For me, it was the lack of exposure. Coming from Togo, many of my classmates in university had taken computer science classes or had access to computer labs in high school. I didn’t have that, so I had a knowledge gap to bridge. It wasn’t a burden because of my natural curiosity for programming, but it was a challenge to overcome. There’s no secret—just experimentation and learning as you go.

James Beswick: Many people now are taking courses and attending coding academies to learn quickly. There's also a gap between leaving college and starting your first job, where you’re working on larger projects. What were some of the things you found challenging when you transitioned from college to your first job?

David Edoh-Bedi: Great question. After college, I got an internship at Microsoft, which was an incredible experience. As a kid from Togo, the idea of working for Bill Gates seemed unbelievable. It was an exciting time for my parents, too.

At Microsoft, the difference was huge. In college, we worked on self-contained programs—projects like designing a system for a gas station or similar tasks. But at Microsoft, I worked on Windows, which was part of a much larger project. It was a different scale. For example, my project was about in-place upgrades for Windows. The idea was to ensure that when upgrading to a new version, documents, applications, and drivers were preserved. I worked on automating the manifest file, which listed all the documents on the system. This was part of a larger migration engine, and I had to understand how my work fit into that bigger picture. It was my first experience working on production code, not just code to get a grade.

James Beswick: Going from college, where you largely work alone, to a team environment at a company like Microsoft, how did you learn to work with other developers, especially those with more experience?

David Edoh-Bedi: At Microsoft, all interns were assigned mentors, which was a huge help. My advice to any young developer is to find someone more experienced to learn from. I was fortunate to have a mentor assigned to me, and that was invaluable. They guided me not only on technical issues but also on things like participating in meetings and handling the project management side of things. My biggest takeaway was the importance of learning from others.

Recommended talk: Legacy Systems & Digital Transformations • Ian Cartwright, Rob Horn & Hannes Lowette • GOTO 2022

Dealing with Legacy Systems

James Beswick: Legacy systems are something most people deal with when joining an enterprise. While many expect to work on new applications, they often end up dealing with legacy systems. What are some important things you learned while working on such a massive system, especially with technical debt?

David Edoh-Bedi: Great question. One fascinating aspect of Windows was the scale. Thousands of engineers worked on the project. Some parts of the system evolved quickly, while others, like the kernel, moved much more slowly due to the scrutiny involved with any changes. The difference in dynamics between fast-moving features and the slow pace of the core components was striking. It was a challenge, seeing how parts of the same system could move at such different speeds.

Another thing I learned that I didn’t have exposure to in school was version control, like how code branches work. The kernel, for example, had a more rigorous testing process and moved at a different pace than the UI branch, but eventually, they would converge. Seeing how these different moving pieces came together was fascinating.

James Beswick: It's amazing that you went straight from college to working on such a massive project. I’ve been there, working on many projects myself.

David Edoh-Bedi: It was enormous.

James Beswick: What advice do you have for people who are taking on huge projects?

David Edoh-Bedi: Start small. Break down complex problems into the smallest possible parts. It’s easy to get overwhelmed, so approaching it piece by piece makes it manageable. As an intern, I was given a smaller, self-contained project that fit into the bigger picture. It helped me gain control over my work without feeling overwhelmed. Don’t try to tackle everything at once. Lean on more experienced people to help break things down.

Transition to Developer Advocacy

James Beswick: So when did you go from being a developer to a developer advocate?

David Edoh-Bedi: That's a great question. I was at Microsoft for quite a long time and like wearing different hats. I found that one consistent theme as I progressed in my career was this: a light interacting with customers and external users. So, during my engineering days, I just I would just get random exposure to external customers. When I worked on Windows, we would do what we called OEM tours for OEMs or your Dells and Toshiba's and computer manufacturers.

Obviously, heavy, windows, partners. We would travel to these OEMs and help them install whatever new version of Windows was coming out. As I mentioned earlier, I worked on setting up an upgrade so we'd make sure that other applets, you know, like Dell had their own, I don't know, printing system.

Toshiba would have their, you know, their like, apps on, on the device. Making sure that those things worked with whatever new OS we came out with, and those experiences were very appealing to me. Understanding how the end user, at least an external user at the end user would have been the actual person buying the laptop, but there's somebody external to the company, how they viewed our product.

Because when you're a developer, if it's cool, you're building stuff, but sometimes you're so far removed from the end user that you don't have that perspective. So it just really helps. At least for me, I found it fascinating to go outside, and sometimes, the things they're talking about have nothing to do.

Or you just don't even think about it because it's not part of your day-to-day. Sometimes, you're so focused on building the feature that you don't look at it from a customer's perspective. So, I had that kind of experience at Microsoft. The more I progressed in my career, I started seeking out roles that would allow me to do that as part of my job description.

Eventually, I left Microsoft and decided to try something new and ended up at stripe, and I took on the role of integration engineer. That's try. So basically that that role consisted of just working with external Stripe users, oftentimes enterprises, that are integrating Stripe. It's kind of a post, well, sales role where a lot of time they signed contracts with Stripe, but then they need to actually integrate, right?

I'm trying to think one that I could mention publicly, but, but so, so that was kind of the progression from, you know, the sort of like an engineer to an external facing room that's stripe. And then, after a couple of years in integration engineering, it's a different position because, I just wanted to try and try that as well.

From Windows to Stripe: Navigating the Challenges of Transitioning Roles and Public Speaking in Tech

James Beswick: What were the biggest challenges for you transitioning from Microsoft, where you worked on a vast system like Windows and didn’t directly interact with users, to a role in integration engineering, where you’re working closely with customers?

David Edoh-Bedi: The biggest challenge was working directly with customers. You’d hear both their positive feedback and their complaints. As a front-line representative of Stripe, you’re expected to be the expert on everything, but the reality is, you can’t have deep knowledge of every product or feature. These roles give you breadth, but it’s impossible to have the same level of depth on all aspects of the company.

The challenge for me was dealing with customer frustration directly, without the support of a buffer. It forced me to develop empathy for users, which was one of the reasons I got into the role in the first place. It confirmed some expectations I had, but it was definitely a shift in perspective.

James Beswick: As a developer advocate, there aren't many of us in the industry, and the role still seems relatively small in many companies. What qualities do you think make someone a good developer advocate?

David Edoh-Bedi: Great question. Empathy is huge. You need to relate to the frustrations people have with your product without taking it personally. Developers are trying to be productive, and products like Stripe are just tools to help them build. Frustrations can come out strongly, but it’s important to understand that they want to fix the issue and move forward with their project. Empathy, curiosity, and a passion for the community are key. In this fast-evolving industry, staying curious is essential. I really enjoy meeting developers and learning about the cool projects they’re working on—it's energizing for me.

James Beswick: People often ask me this, so I’ll ask you: As developer advocates, we often have to speak on stage in front of large audiences, which is something most developers aren’t used to. What was that like for you, and how did you develop those skills?

David Edoh-Bedi: My philosophy when learning something new is to break it down into the smallest possible steps. For presentations, I started with smaller, friendly audiences. In my integration engineering role, I got to do demos for small groups, which helped. At Microsoft, I had opportunities to teach people how to build Windows apps. My advice for someone starting out is to begin with a small, supportive audience. There are groups like Toastmasters that help with public speaking. I went to a few meetups, and they provide prompts to practice speaking in front of others.

James Beswick: Reading slides is one thing, but doing live demos is another. Things often go wrong on stage. How do you handle a demo when something goes wrong live in front of hundreds of people?

David Edoh-Bedi: My advice is to avoid live demos as much as possible—pre-recorded videos are safer. But if you do have to do a live demo, always have a backup plan. The worst thing is to get stuck without a plan B. If live coding isn’t working, switch to slides to keep things moving and avoid awkward silence.

Recommended talk: Expert Talk: Are We Post-Serverless? • Julian Wood & James Beswick • GOTO 2024

Exploring Stripe's Global Reach: Beyond Payments and the Complexity of Payment Systems

James Beswick: Now you're at Stripe. I've been at Stripe for a few months, and it's often seen as just a payments company. To the outside audience, payments might not seem that complex, but there’s a lot going on behind the scenes. From your perspective, how do developers learn about Stripe’s complexity when integrating?

David Edoh-Bedi: There’s a lot more to it than people realize. I didn’t know much about Stripe before joining, but the mission statement—growing the GDP of the internet—really intrigued me. A few years ago, about 12% of global commerce was online, which showed the potential for a company like Stripe. Coming from Togo, where e-commerce is still in its early stages, I resonated with the mission.

Stripe starts with simple payments, like credit card processing, but as developers dive in, they discover more. Stripe handles fraud detection, in-person payments, and even helps with company registration through Stripe Atlas. It surprises a lot of people just how much Stripe offers beyond the basics.

James Beswick: In the U.S., credit cards are everywhere, and cash is becoming less common. But globally, payments vary widely. It's surprising how diverse payment methods are across countries, isn't it?

David Edoh-Bedi: That’s something I’ve learned at Stripe. It's fascinating how different business models and payment methods are across the world. In some places, credit cards aren’t as prevalent—bank transfers are much more common. In Western Europe, for example, you might assume people are using credit cards, but in countries like Germany, methods like SOFORT bank transfers are huge. In the Netherlands, bank transfer payments are also very common.

It’s surprising because, in the U.S., bank transfers aren’t as common for paying merchants. People might transfer money between friends, but paying a merchant through a transfer is rare here. It’s interesting to see how different payment methods dominate in different regions.

James Beswick: A lot of developers now have to deal with payments in their applications. When I was at AWS, I was surprised how many large businesses attempt to write this code themselves. They often run into trouble, especially with sensitive data like credit card numbers.

For instance, storing them in an S3 bucket isn’t ideal. As developers, we learn that some things are best left to others, like writing your own authorization systems. Services like Auth0 already handle this well. The risk of getting hacked and the complexity involved makes it not worth doing on your own.

Similarly, handling payments and credit cards is much harder than it looks. The risks are significant, so it’s better to let someone else handle it for you.

David Edoh-Bedi: Absolutely. People often underestimate the complexity of handling card payments. You need to store this data securely, which is far from straightforward. Offloading that responsibility makes a lot of sense.

There are many aspects to this process. I remember when I first started, I saw a lot of card testing attacks. For those who aren’t familiar, card testing happens when bad actors gain access to credit card numbers and try them on various websites to see which ones work.

This happens more often than people realize, and Stripe helps protect against these kinds of attacks. When building a payment system, it’s easy to think it’s just about taking payments and sending them to a bank, but there are many layers involved. For most businesses, it makes sense to stick to their core strengths and let a company like Stripe handle the complexities of payments.

James Beswick: When you start a new project or enterprise, you often aim to keep things simple to test an idea before building too much functionality. But then you look at apps like DoorDash or Uber, where money moves in complex ways—drivers paying, passengers paying drivers, and people paying different people. It’s a lot to manage. One of the products you work with is Stripe Connect. Can you explain that, as it might be new to many people?

David Edoh-Bedi: Stripe Connect is a product that’s essential for marketplaces and platforms, like Uber or DoorDash. It's designed to handle all the moving parts in these types of businesses.

There are three core components: the platform (like Uber), the end users (the riders), and the merchants (the drivers). Connect facilitates the entire process, from onboarding users and merchants to verifying their identities. For instance, when an Uber driver or rider sets up an account, Stripe handles their verification.

Another key aspect is payments. We collect the driver’s bank or debit card information so they can be paid. This is where Connect really adds value—it's not just about moving money but ensuring every part of the transaction is seamless.

One feature I find interesting is instant payouts. Normally, payouts happen on a set schedule (daily, weekly, or monthly), but with instant payouts, merchants can offer drivers the option to get paid immediately, for a small fee (like 5%). This can be an additional revenue stream for businesses using Connect.

James Beswick: The topic of money is interesting for many reasons. In the US, if I want to give you $10,000 without paying fees, the easiest way is still to write a check. Similarly, if I want to give you $0.20, it's easiest to hand you a couple of dimes. There's still a long way to go in terms of how money moves. We're making progress electronically, but it’s surprising how often people still use checks, especially in the US.

David Edoh-Bedi: It surprises me to see my parents doing it. As you said, there’s still a long way to go. Peer-to-peer platforms like Venmo are gaining traction, but for some people, it’s about comfort. My parents, for example, don’t like using PayPal. My dad prefers writing a check because it feels safer and more secure, even though there are better options available. It’s interesting that despite all the innovation, bank transfers are still one of the most popular ways to move money.

Recommended talk: Bringing Automation to Web App Hosting and Deployment • James Beswick • GOTO 2019

Mastering APIs and Payment Systems: Tools, Techniques, and the Evolving Developer Landscape

James Beswick: One interesting thing is how much things have evolved since we started writing code. Back then, it was all about understanding a library or SDK deeply so you could embed it in your product, package it, and ship it. Now, it’s more about APIs. We went through a phase where cloud providers like Amazon, Google, and Microsoft handled everything. But there were always better services outside the cloud provider. For example, instead of handling text messaging, you'd use Twilio; instead of building authentication, you'd use Auth0, and for payments, you'd use Stripe or another provider.

Now, the challenge is learning APIs. What’s your advice on how to get your head around an API, especially when it's not like a library?

David Edoh-Bedi: Great question. The first thing I do is treat the API like a black box. Understand the input and output, and treat it as a means to an end. From there, you can step in and try to understand the inner workings if needed.

It really depends on the use case. If you’re using an API for something simple, like sending text messages for shipping confirmation, treating it as a black box is often enough. You don’t need to understand how it's architected.

If you want to dive deeper, maybe because you’re building something similar or just want to understand how it works, open-source libraries and APIs are a great resource. A lot of this is available now. You can also find educational resources, depending on the provider. For example, Stripe offers content like tutorials and developer resources on our YouTube channel and Stripe Dev site to help people learn more about how the API works.

James Beswick: When you're building something in your inbox, you often have more options and confidence compared to using APIs or external tools. But when you're putting everything together and testing, what tools do you particularly like to use?

David Edoh-Bedi: You were asking about tools for testing APIs. I like Postman a lot, especially for REST APIs. It's pretty useful. I also use VS Code, which has various test libraries and hooks, depending on the setup. But Postman is the primary tool I rely on for testing.

James Beswick: Observability can be tricky, especially when you're using multiple clouds and different providers. I really like the new workbench feature in Stripe, where you can see what's going on inside when the data is coming in. It pairs well with AWS services like Lambda or ECS, helping you understand what’s going wrong in production. These tools are getting much better, making life easier for developers.

David Edoh-Bedi: Absolutely. The workbench is great because it lets you track the entire journey of objects through the payment process. Previously, logs were segmented, showing only parts of the system. With tools like workbench, you can see the whole picture, which is really helpful for debugging.

Comparing AWS and Stripe

David Edoh-Bedi: I feel like you've been grilling me! You've mentioned your experience at AWS. Now that you're at Stripe, what's been the most surprising to you?

James Beswick: AWS is huge, and Amazon's even bigger. Stripe is much smaller, but what's interesting is the pace of development. Being smaller means more projects, faster feature development, and a lot of passion in the Stripe community. There's a lot of care and attention put into the products. At AWS, it's very customer-driven, and things often stay in an MVP state for a while before becoming production-ready. But Stripe spends a lot of time getting things right before they’re released. By the time something reaches beta, it's usually high quality, which has impressed me.

David Edoh-Bedi: It’s interesting to hear that perspective. Coming from such a large project at AWS to Stripe, what was the biggest challenge for you? You essentially changed industries, right?

James Beswick: The biggest challenge was learning everything from scratch. I know AWS well, but I didn’t know much about Stripe. This is something a lot of developers face when moving to a new company or industry. It's about figuring out what’s important in the new space, understanding what you don’t know, and closing those gaps. Especially in our role, where our goal is to help others, it’s important to get up to speed and become useful quickly.

David Edoh-Bedi: Yeah, that makes sense. Well, I think that’s all the time we have.

James Beswick: David, thanks so much for the great chat!

David Edoh-Bedi: Thank you! It was a lot of fun.