Fable Tales, Staff Engineer at Stripe

Hey, everyone. Welcome. My guest today is Fable Tales. I met Fable years ago when we were speaking at a Ruby conference.

Yes.

And you invited me to pair on some RSpec code, and we have been friends ever since.

Because that's that's how you make friends in the Ruby community, apparently.

I do wanna talk talk about that in a second, but let let me finish introducing you first. So you previously worked at DigitalOcean and Google. You currently work at Stripe. Yep. You were a technical adviser to the CTO at Stripe. Now you're a staff engineer.

Mhmm.

Welcome to the podcast.

Thank you. Thank you so much for having me.

Yeah. I'm I'm stoked to chat. It's nice to talk to a friend that I know well. Maybe we start actually with that that conference interaction because you I would say you have this the quality of being really unafraid to sort of reach out to people and, like, ask them to do things. And that is the reason we're friends.

Yeah. I think, like, honestly, this was something of an experiment for me. So this was actually the very first international Ruby conference I had ever attended, and I only knew a few people who were coming, and I I sort of wanted to make additional friends. And so what I did, it wasn't just you, but I reached out to a handful of people who I knew were attending, whose talks I had really enjoyed videos of. And I was like, hey.

Right? That's a really good point. Yeah. Yeah. Conferences are basically I I mean, I really feel that, like, conferences the best thing you can get out of them actually is connections with people. Yes. Like, nothing like, no talk I've seen approaches the value I've gotten from friendships developed at a in person conference.

Yeah. And, honestly, when I when I go to conferences where I know they are recording the talks, I will spend the vast, vast, vast majority of my time in the hallway, because I can watch the talks later, but I can't get that time with those people back. Right? And, like, you know, for example, a really good thing this habit has created is opportunities to, like, work with people I wouldn't usually get. So right before I stopped working on arspec, I was at Ruby Kaigi with the JRuby folks, and we, like, skipped maybe, like, 3 hours of talks to sit together and do some, like, rspec jruby debugging that, like, would have been just impossible to do any other way.

Mhmm. Nice. Yeah. And I think that, like, reaching out to do a specific thing also Mhmm. Like, worked. You're like, let's use Vim and pair on our spec. And I was like, I mean, like, did you wanna go to the contributor list for rspec? It's like a pretty good pitch.

Yeah. I I knew I knew I had sort of, like, it's it was, something to learn and something to offer. Right? Like like, I had seen your VIM talk. I was, like, I wanna get better at VIM. I bet Ben will help me get better. And in fact, you did. And Nice. You know, you got you got yourself on the aspect change log, so we both got to learn something. Right?

Yeah. That's cool, and it's it's a good experience. Mhmm. And, yeah, you're right. The conference can be sort of default intimidating. Yes. Like, it's it's a room full of people. It can be a little tough to make those connections.

Mhmm. Yeah. Yeah. Yeah. For sure.

Cool. Alright. So can you give me a big picture overview of some of the things you've worked on at Stripe in your time there?

At Stripe, yes. I have done I've done a lot of things at Stripe. So when I joined, I was on our API platform team, and that is the team that is responsible for running the core Stripe API service. So when you hit the vast majority of Stripe API endpoints, you are, like, directly going through code that is maintained by the API platform team and sort of, by association, that means, every time you make a request to the Stripe API, you are executing code I have written, which is is, you know, sort of cool. I then, after I was on the API services team, was the tech lead of our Ruby services team, where Stripe is sort of in this transition from having a large monolithic service to, smaller services.

Yeah. Wow. That's awesome. How did you other than pairing with me at a recent conference, how did you get good at programming?

I think, like, the I I'm sort of very lucky, right, by comparison with lots of programmers that I so so my my dad worked at IBM, and so, like, I grew up in a in a house of sort of, like, software. And I started programming when I was 12, in Java because my dad worked at IBM. And, you know, I just I just programming sort of was my hobby, alongside playing video games, you know, through my teenage years. I studied computer science at university. I I always just loved it.

Okay. So you put in a lot of hours, which is certainly like a big component. Right? But it's also probably not enough. It's not sufficient. Yeah. It's I I think you're doing other clever things to get better.

I think yeah. And I so I think I think for me, like, the biggest I think one of the biggest things that can help you become a better software engineer is, like, never accepting that something is, like, impossible or too difficult to be solved. Right? Like, the in some senses where I've seen sort of, like, myself succeed where the software engineers fail. It's just a sort of, like, dogged determination that you can understand the behavior of even, like, very complex systems if you are just willing to, like, push and push and push and push and, like, inspect, like, how this thing runs and, like, what branches does it take and that sort of thing.

you

know, just just earlier today, I was sort of talking to someone about, like, how I debugged through some nonsense in the Ruby VM. And I was like, fundamentally, what it came down to was just, like, shoving print statements in, like, various pieces of the Ruby VM and seeing what happened. Right? And, like, that sounds that sounds really scary. Right? Debugging into Ruby VM.

Totally.

But but it just it's just it's not actually.

That's funny. Because because I am I am that programmer that you are doing better than because I'm, like, too afraid to go look in the Ruby VM for what the thing is. I mean, that's just like, too too black magic, too scary, too

low level. Yeah. Yeah. And, like, you can you can understand it. Right? I think another thing is, like, being willing to learn and work, like, in anger in as many programming languages as you can. And I think in in particular, even

though it's

I think it's not cool anymore, like, being willing to, like, work in and with complicated c programs is, like, probably one skill I possess that distinguishes me from a lot of, like, programmer like, notionally, right, if you look at my CV, I am a Ruby programmer. But, like, I can, you know, I can deal with, like, complicated c programs with the best of them. Right? And, like, you know, I think I think, like This

is a great pairing too. Right? That's what's underpinning the all the Ruby. It's like, if you need to go to the c level, no problem.

But it it it also underpins, you know, all the browsers and the operating system. And, like, you know, it lets you it lets you read the kernel, like, should you should you need to go read the kernel, which, you know, I have done. And, like, you know, when I worked at DigitalOcean, we were literally we were maintaining a Rails app that was like an internal admin interface for people to use. But the internal admin interface spoke to, you know, hypervisors on bare metal all around the world, and, like, you you need to be able to, like, drop to the, VM hypervisor level to be able to, like, debug issues sometimes. And, like, that's you know, I'm gonna SSH into this, like, physical machine somewhere around the world and, like, start editing Perl scripts, like, managing, like like, Libvert state.

And it seems like c and c plus plus are, like, the the languages there. Like, you could pair those with almost anything higher level and say, like, because so much software is written in that. Like, if you're gonna dive down the stack, you're gonna hit c m c plus plus. Right?

Yeah. Yeah. I would say you are in like, actually, god, now that we're now that we're talking about this, I'm I'm reminded of, one of the things I did at Google, which, was debugging a memory leak in the protocol buffer library for PHP, which also, like so I I've not slung all that much PHP in my life. Right? It's like some when I was a kid before I discovered Ruby, but, like, never serious production usage.

Wow.

And and I I do think like, I I I wanna illustrate as well. While c and c plus plus are important, I think it's, like, being able to get to the underlying complexity of whatever system it is you're working on and just it just so happens that a lot of the time, c and c plus plus are

what underpin those systems. I feel like do you have a bug spotting knack? Is it a side effect of just, like, being able to grok the system well enough to sort of notice that that's a bug there? Is it, like, a is it an intuitive thing where you're kinda like, something's up here?

I think I don't know if I do by comparison with other software engineers of my level of experience, but like, I think regardless of your sort of, like, natural bug spotting ability, the ability to sort of, like, confirm and bisect problem spaces and that sort of thing is, like, more important. Right? And so, like, to me, it's not just Mhmm. I can, like, I I am not not some, like, godly programmer who can stare at c code and immediately tell you where all the bugs are. You know, I'm just gonna go in there and fire in a bunch of print statements and have that sort of, like, tell me things about the the system.

Yeah. I you reminded me of a story from the, like, really early days of Tuple where we had this bug, and, Spencer, who had written so much of the app, was, like, away on vacation. And John and I were like, it would be really cool if we could fix this bug because it's like we can reproduce it reliably, and it would be great to fix it. And we realized that it was in the c plus plus of WebRTC. Mhmm.

Yeah. Like, I think even very early career programmers have gone through the process of doing that debugging action. And, like, I think people imagine that in systems of a certain size or scale, like, some magical thing happens where it makes that approach not work when when in fact that is that is not true.

Right? Yeah.

Like like like, you know, all all of these all of these machines, like like, every CPU, anyone who writes code today executes on behave in, like, roughly the same way. And even even the, like, scariest of, like, you know, multithreaded, like, c or c plus plus, like, async, you know, programs, like, follow the same logical rules as, like, you know, hello world in JavaScript. Right? And and, like, you can like, I promise you that you can actually just slam print statements all over them and make the bug go away.

I love that. Yeah. I think there's definitely also mental thing here of, like, these artificial boundaries that I have, like, that that I've constructed where it's like, oh, no. Like, that's a dependency. I can't go in there. Like, that's just, like, unknowable. This boundary cannot be passed.

I was actually just I was actually literally just about to say this. You know, and sometimes that means knowing how to pull the source of a library down and compile it and, you know, link it into your program versus using your dependency manager. And, like, lots of people have never done that. Right? Because most of the time, most of our software dependencies work exactly as we expect them to.

Interesting. Yeah. I that that that makes sense. So there there is some can there. You can download the kernel and run it. My guess is Great. It's that's, like, not often the thing. I think it's more of the fear. Yeah. I think it's, like, there's something special about a kernel or a VM, and, like, this is just, like, un understandable by a mere mortal like me. Yeah. So I just, like, shouldn't get in there.

Yeah. And I'm like, I'm not I'm not especially much more clever than most software engineers. Right? I don't have I don't have magic powers. I just I'm I'm just unwilling to take no for an answer.

Yeah. Yeah. It's the it's the willingness. You're just like you yeah. And I I I think your message of just like, you can slam print statements in anything and eventually kinda figure out what's going on. Yeah. And, yeah, just go for it.

Yes.

Print statements or do do you how do you feel about debuggers versus print statements?

They both have their utility. I think, like, I would never tell anyone that you, a 100% of the time, want to use a debugger and a 100% of the time, only want to use print statements. Like, I I will pry things. I I so I guess not everyone who's listening to this podcast is a Ruby programmer. Pry is like Ruby's debugger, for those of you who are listening.

Got it. So print statements, fast and light, easy to do debugger when you wanna, like, maybe step through a lot of things or something?

Well, it's it's a bit more situational than that. Like, you know, you you can get into sort of, like, hell where, like, the thing you're debugging is a subprocess being invoked by another program that, like, is capturing standard out and standard error. So you need to, like, side load print statements out to another file. Or, like, like, there are there are hell versions of this where it's or, like, you're you're 19 layers deep in forks, and so you just don't know what your process ID is, and so you can't attach a debugger to it. Like, there there are sort of programs that are more and less resistant to, like, various types of debugging techniques.

And a a

debugger can at least tell you, you know, you're in this frame. And and then once you've done that, you can slam print statements in. Right? And so I I my approach is almost always hybrid. And, you know, like, as I mentioned earlier, like, I was I was debugging pry. If you're debugging a debugger, you probably can't use the debugger to debug the debugger. You you probably only have print statements. Right? And so the it it's just really situational. You talk

a bit about the tech advisor to the CTO thing? That catches my catches my interest.

Yeah. I I guess we we really never talked about this on air before. That that doesn't seem real.

That's a great yeah. Maybe we did. It'll be

possible. Possibly. I'll, yeah. I mean, I'm happy to give you a summary anyway. So so it was time time has become a a blur in my mind, but, it was is most of 2022 and some of 2023, I was I was technical adviser to Stripe's CTO David Singleton.

Oh, interesting. That's that yeah. Those are those are quite different.

We definitely talked about that on, Art of Product. So I'm Alright. That's an

that's an old podcast. We're on a new podcast now. I'm not gonna make people go listen to that one. This is we're doing a whole new thing now.

Okay. Yeah. I mean, we can we can maybe get into that, but, David always sort of ran and sponsored the engineering blog at Stripe. So I ended up, kind of keeping that moving. I think there were, like, so many thing.

Or like Nice.

Or like feed him things to say, without without it getting too spicy. There were definitely instances where, like, I would send him a DM and he would just say exactly what I DM'd him verbatim. And, yeah, so I mean, really just kind of like, you know, the second brain person at your back kind of a role. Having someone who is really in tune with engineering at Stripe and just, like, helping out.

Cool. Nice. Alright. You wanna talk about code more?

Yeah. Sure.

Alright. What's a coding hill you would die on?

See, when you ask me this question, I have I have a problem. And the problem is that it's it's, like, one of the least popular takes, in the in the Ruby programming language. But I think new style and by new style, I mean, Ruby 19, hash syntax was a mistake, and we should just never have gotten rid of the hash rockets. And and this this take is, like, so nuclear in in Ruby that, even when I wrote my own Ruby auto formatter, like, people argued me off this hill, to I was like So

so you wouldn't die here?

I guess in my heart of hearts, this is the hill I will die on.

I hear you.

But but like if when I'm building a popular tool for the masses Totally. I knew it was one I had to give up on. But Definitely. To this to this day, I would I would keep the hash rockets if it didn't get me, you know, thrown out of RUBY forever.

Is it an aesthetic thing or parsing or something?

So so the the the argument roughly goes that, we don't gain any capability with the new hash syntax and that it is actively confusing for things like quoted symbols, and that it makes the implementation of the language more complicated for, like, what isn't really that big of an aesthetic change.

Yeah. I hear you. And the Hash Rockets are kinda cool looking. Yeah. They just they they look cooler. Alright. We gotta get off this in case some some of the audience isn't a Ruby programmer, and this is, like, the worst

Anyone in anyone in the audience can at can at me. I I don't care. Yeah. This is a terrible take, but you are you asked. So

Absolutely. Yeah. Are you a are you a prototyper? Do you make little little programs to, like, try things out?

Oh, yeah. You know, it's it's interesting because, like, it's quite rare that I am doing new things. Like, I spend I spend much more of my time, like, in the abyss, like, fixing arcane bugs. But, I actually I actually ended up building a whole new, RPC client within Stripe, last year. And, absolutely, the the first rev of it was, like, a script.

Okay. So yeah. So you you properly spiked.

Oh, yeah. Yeah. I I was writing trash code

Yeah.

As fast as I could to prove that it could work. And and actually part part of that is because, a lot of people, has said it was categorically impossible. And coming back to sort of the previous conversation, like, I don't believe in categorically impossible. So I was like, no. I can I can do this?

That's awesome. It's you so you did the hard part of a spike, which is you threw it away when you were ready to do it for real. Yeah. Because you're writing so, like, you're telling yourself, I'm writing a spike. I'm gonna write crap code. And then you get it working. And now you have to do this really difficult thing psychologically, which is like, no. No. No. I'm not just gonna be like, actually, it's already working.

Yeah. Well, I had a reference architecture for what I wanted the thing to look like in my head.

That's cool.

And so Reference from somewhere else? What do you mean?

When you say reference architecture, I'm imagining, like, you you saw another architecture you liked that you wanted to use or you just had, like, a plan?

I had a plan for what I wanted the architecture to look like in my head with the the reference part of that is, like, that's what I was referencing. And, like, I was like, this script did its job. It, like, it proved it proved we can we can sort of do the thing.

You you shut the haters up. You showed him. Look.

Yeah. Yeah. Yeah. Quick quickly. And then I was like, okay.

Wow. The majority?

The, like, vast, vast, overwhelming majority.

Yeah. Okay. So you're not even screening on Ruby ability really. You're just like, if you're a good engineer, get over here. We'll teach you.

We we don't interview for Ruby Ability at all for, like, most of the software engineers we hire. Interesting. Yeah. Like, e there are even people on the Ruby infrastructure team at Stripe who never programmed Ruby prior to Stripe.

So is there a, like, a significant curriculum to get people up to speed?

It's not that big. We just we just throw them in. Okay. Yeah.

So there's not like a there's not like course you do or, like, it's just kinda like, here's your mentor person to, like, ask questions.

There is some there is some developer education.

Mandatory? Happens for everybody?

Yes. Well, so when you join Stripe, everyone goes through a week of sort of, like, generic Stripe onboarding, and then software engineers go through 2 weeks of, like, developing at Stripe onboarding. And part of that is actually, like, practically like, a small group of, people in your onboarding class will work together on a project and actually, like, ship something. In most people do Ruby. Some people do Java because we also have a lot of, Java services in production.

I'm thinking because we sometimes it's like we have kind of a weird problem domain, like a weird space and, like, our app is written in c plus plus. Mhmm. And it's like and I'm wondering if we're screening on c plus possibility when we shouldn't be. And what it would require to just choose for engineering ability, like, capability and, like, train people.

I think it is reason more reasonable for you to screen for people who can program in c plus plus than it is for Stripe screen for people who can program in Ruby.

I'm making the classic error.

Yeah. Like like like, Tupelo and Stripe are very

different businesses. Arguably, I guess.

I you know, like, one, you know, one reason I can give amongst the many is that, like, it's way easier to start programming something in Ruby than it is to start programming something in c plus plus, and, you know, dozens of reasons beyond that. But, like, yeah. It's it's, you know, 2 very different business contexts.

Fair. Are you a big, workflow optimizer in terms of, like do you, like, work on cutting out lots of shortcuts and, like, keystrokes? How crazy are you with that kind of stuff?

I used to be. I don't like, I think I would continue to be if I was still a full time heads down software engineer, but I'm I'm just not. And so, like, at at least now it doesn't feel like the long pole.

What's the breakdown of coding versus, like, not coding time for you?

That's, that's a great question. I think on the average week, it's like super honestly, it's super variable. One thing I would say is, like, unlike many software engineers at Stripe, there's sort of, like, a presumption, that staff software engineers can be distracted into planning, architecture, resourcing, status updates, blah blah blah blah Yep. At almost any time. Right?

enough.

Like, frank frankly, like, for for me learning the Gmail, hot keys was at one point a bigger productivity boost than, like, speeding up my IDE.

Yep. That makes sense. Yeah. Do you miss the pure coding days?

I think the problems I work on are more interesting now. I think, like, how do you make a organization as large as Stripe effective is, like, a sort of, like, very interesting meta problem. And, like, it's not for everyone. Right? I know deeply, deeply experienced software engineers who, like, don't want to stop being hands on keyboard and programming all the time. Right? And more power to them. It's just not for me.

Fair enough. So is it about the the leverage? Is that exciting to you now? Having more impact? Or just that you're sort of tired of cranking out code all the time? You need more variety.

There are I think I think the right way to look at it is it is easier to find people who can, like, crank out code than it is to find people who can do that and, you know, well understand business context and think about, you know, the the complex problems of, like, what our priorities are and, you know, how we do how we assign people to tasks and, you know, what are we actually trying to get done this year? And, like, how how does what we're doing measure up against the company objectives? And, like, you know, broadly broadly speaking, I think, like, programming is a tool software engineers need to have, but, like, being a really great programmer is actually not sufficient to be a a wholly well formed software engineer. And that if it were flipped, there are, you know, there's probably a lot of wasted opportunity by having me just, like, at the keyboard all the time.

Yeah. And does that match with what you want? Or is it just, like, you you wanna serve your best, like, help the organization as much as possible?

I will be I'll be honest. I'm person I'm personally very motivated by like wanting particularly, particularly Stripe, but you know, this has been true in the past as well just to be, like, as good as it's it can. And, like, I sort of just on a personal level, like, abhor not doing whatever I can to, like, make that true.

Cool. It's like a core drive for you, sounds like. Mhmm. Those are the best. You don't have to, like they're just they're just there. Yeah. The fire just burns.

Yeah. Ice icy problems. I make them go away. It doesn't necessarily matter what shape they are.

Mhmm. And the fulfillment guns from there. Yeah. Nice. So does it make sense to talk more about programming if, do you do you like the nitty gritty still?

Oh, yeah. I I I love it. There's something there's something very fun and interesting about just being, like, up against up against the computer and just, like, having to sort of push through. Right? Like, as I was kind of talking about earlier, like, a lot a lot of the work I do these days is just like people come with arcane bugs and they go, Fable, we need we need this arcane bug to not be here anymore.

They're, like, we've heard you have a lot of knowledge and a lot of tenacity. Could you make this go away, please? Yeah. Yeah. And everybody wins because you you seem to enjoy that a lot.

Yeah. Yeah. Yes. And, you know, like, in particular, this is like I think I think this is a thing. It's really great that, I I'm here at Stripe because, as I mentioned, we have the largest Ruby code base in the world and actually actually by some distance.

Mhmm. Yeah. I mean, Stripe needs a you. Yeah.

Yeah. Yeah. That is true.

At least at least 1.

Yes. Okay.

So let's we've been we've been high level a little bit. So let's let's dive down the stack Yeah. Touch and talk about some some Cody things. Are you a pretty strong practitioner of short methods, small classes, lots of little pieces linked together, operating a concert, or are you more like, why don't you just throw all that in one method? It'll be easier to not have to track through things.

Am I allowed to be annoying and say it depends? That's I

have a hunch that's gonna be, like, the refrain of this podcast. Yeah.

Yeah. I think to me, the sort of there's, like, a there's, like, a much more interesting meta question there, which is like Please

do my job for me.

Like like like, why why would you choose like a particular version of one of those constructs over the other, right? And like to me to me it's kind of like are you trading off, speed to change, readability, speed to write? Like what, like, what are you actually trying to do? Right? And so, like, you know, for example, like, when I was shipping completely greenfield startup code, like, code just goes wherever.

Yeah. Yeah.

I think, like, and, you know, it's, Kent Beck has this, framework, called, explore, expand, extract, which sort of, governs the journey of a life of a software product. Right? And so, like, in in the the early days, you're in the explore phase, and, you know, you want to find what the product is even supposed to be as as quickly as possible. Right? Because if you don't, you're going to die for the aforementioned reasons.

I I haven't heard that back thing before.

Mhmm.

Okay. Do you have a sense of your personal style? Like if I saw some code and was like, oh, Fable definitely wrote this other than Hash Rocket syntax in Ruby.

I don't know. Well okay. So I suppose there's one there's one way of answering this. Right? Which is that, I literally wrote a Ruby auto formatter because I was so angry about how, people were writing Ruby code. In a sense, all the Ruby at Stripe has Fable style.

Got them.

Yeah. Got them. This is maybe this is maybe a funny aside. That's That's hilarious. No.

That's the way to win the style argument.

Is just write the autoflex.

Write it. Yeah. That's amazing. Yeah.

You know what? We'll we'll do a we'll do a podcast exclusive, behind the scenes here. So, at Stripe, we anyone at Stripe can create a new emoji in Slack, And there is a there is a fable crimes emoji, because I I am sort of known for, kind of blowing past, safety features if they are in the way of, like, me solving whatever particular problem it is, I am trying to solve. And so sometimes I will be like, I'm doing so many crimes right now.

Is this, like, past, like, type checking kind of safety features?

Oh, yeah. Just like t untyped or, like, throwing evals in there or, like, reaching into private guts of objects. Like and this comes back to, you know, what we were talking about earlier of, like, being really unwilling to sort of, like, accept that problems are impossible is, like, sometimes you just you just gotta do crimes to, like, to to to to solve a problem.

Sometimes you just gotta do crimes. A quote from a high level Stripe engineer.

Yeah. We're really we're not passing the front page test on that one. But, yeah. No. What I mean by that is, like, frequently, and this is especially true in large systems, like, you know, that will be, like, the right way to do a thing, and it will be, like, safe and have boundaries and stop you from, you know, blowing up a thing. And I'm like, look. I know. Like, I know. I know. You you just you just gotta let me you just gotta let me do it this one time.

And so

I would say I would say fable style is most visible when I'm in the middle of a complex problem. Not when I've solved it, but, like, when I'm in the middle. And the reason for that is that, like, I will I will blow through, like, any and all safeties, I need to if it makes me, like, believe I'm, like, closer to fixing something. Yeah. And so I guess if when you ask me what my style is, my answer is crimes.

I like it. Aggressive. Raw aggression.

Sometimes you've gotta just be willing to commit code crimes, you know?

Yeah. Yeah. Alright. I'm I'm on board. Are you still using Vim? No. Okay.

Stripe has a really well manicured, Versus Code story. I use Versus Code in VIM mode, so I'm, like, half I'm halfway there.

How is that?

Good enough, actually.

Nice.

It's the first Vim integration in something that is not Vim I've ever used that doesn't make me angry and want to immediately rage quit.

Cool. That's awesome. It it has seemed like that's possible. Hard hard. Because Yeah. It's like who what if you're gonna implement 20% of VIM, it's which 20%. There's no Yeah. Magic 20% that covers what everyone thinks is, like, the best 20%.

Yeah. And that there are there are things in Versus Code VIM that infuriate me. Like, a really good example of this is,

that's not remarkable, though. Right? Can't you say that about every piece of software you use?

What pieces of software that do not infuriate me? Are there any?

What's the most reliable piece of software you use that's like yeah, that you like?

That's a great question. This is one that's probably gonna get me some hate, but I I actually find Zoom to be really, really solid. Like, I almost never have problems just, like, joining a call and talking to people. Yeah. I like I have my Mac. It's plugged into my screen. I have my microphone. That's it. It's oh, I just bashed my microphone. I'm so sorry, audience. It just works. It just it just always works. And, like, the screen sharing always works. And

Yeah. It's great. That is the that is the thing they do. They work really, really reliably. And, like, even when networking distance are bad, it's like that's the they they do a great job with that. I have to give them that.

And this is not a piece of software per se, but, I guess this is my best piece of hardware. YubiKeys. YubiKeys are amazing. They just work. They do exactly what they say they're going to do. Yeah.

Yep. That's So

what were we talking about?

I asked you what doesn't make you rage. Oh, you're saying that v s oh, VIN mode in

VSP. Yeah. Yeah. It's it's, location storage. So, like, like, if you use the control o and control I shortcuts to go back and forth. And if you use the tag stack, those don't work the same way in Versus Code that they do in Vim enough for it to make me angry, but most everything else does.

You wanna pair on it and fix it?

No. I don't I don't, I don't really do programming outside of work at all anymore. I did that a lot in my twenties, and then I just I kind of don't anymore. Like, I'm not on any major open source projects anymore. I I'm not on the board of Ruby Central anymore. I just I kinda stopped. I kinda I kinda stopped from wanting to do, programming outside of work time.

So I did. Mhmm. I realized I should have I should have mentioned your open source work in your intro.

Yeah.

Because you're in the Rspec core team. I mean, among other things, that's what that's what stands out to me. And I wonder there are probably people that are interested in that. Mhmm. It's like, what is your what is your advice to people that, like, wanna get involved in, like, a heavier level with an open source project?

I think I think the open source world is very different to how it was in, what? Like, 2013, 2014 kind of

times. Old? Our advice doesn't isn't relevant anymore? Our experience is not relevant?

I I think the way I became a open source core team member probably would not work, anymore. Mhmm. Which I think is interesting. Right? That is interesting. Because all all I did was I I just, like, rolled up to the rspec project. I just started I just started sending them pull requests. I just started fixing fixing bugs, refactoring, and, yeah, they gave me they gave me a commit bit and a a core team bit. And, after how long? It wasn't that long, actually.

Mhmm. That's interesting.

And, Discord is, like, one of the best tools for open source, which is hilarious. But, like, it turns out that when you design a chat system for gamers, you need really, really good moderation tools, because gamers are terrible. And so you end up with, you know, a tool for building communities that's really good.

Yeah. That's interesting. Are you part of any great Discords? We're gonna ask

a part of any great Discords? I have a lot of social Discords I'm in, with friends and stuff and those are really good. I'm in the the, Greater Boston Area trans people discord, which is, like, you know, a sort of, like, social community group. But

you're not active in a programming one right now?

No. Well and that comes back to you. I don't really do

Yeah. Yeah.

Programming outside Discord. How would you do if how would you

do a commercial open source startup today? If you were to make a open source thing, give away the the the core of it, build a premium offering on top of that somehow?

Yeah. I mean, it sort of depends on the, you need a little counter. You need, like, a ding every time it I I say it depends.

That's what this podcast should be called.

Maybe that's the episode title. There you go. But, like, you know, I think I think it also sort of depends on your, target customer.

You've actually gone 2 depends deep, and you haven't even told me anything yet.

Given you any useful information? Jesus. So so, like, you know, if if your target customer are, like, in less than, you know, hundreds of employees, companies, you probably have a much lower compliance burden to hit to sell software to them. So, like, if you're selling to, a company that needs to follow, you know, like, so I mean, it's Oxley or SOC 2 blah blah blah, then, like, a thing you can sell them really easily is just a hosted runtime of whatever your open source is because, like, people hate, like, running their own stuff. Like, running server running servers is like a hard problem, it turns out.

Yeah. And he didn't he his thing is nice because he doesn't have to host anything. Yes. Host hosting is not just an easy thing to do. Oh, and we just all we just host it for you. That's, like, that's, like, the business. Like, that's another business, basically.

And so and so that's kind of the other that's kind of the other way you can split. It's like, what's the what's the, like, pro feature that businesses need, that consumers don't. Right?

Yeah. I feel like if if it were you, if I were starting this with you, I would do it with some sort of hosted component. Because you could do that.

Yeah. Yeah. Because you you'd trust me to run the service. Right? Like,

Yeah. And so, like, if you were doing this yeah. Yeah. You you if you're on the team, you do the hosted thing.

That's the other thing is, like, do you want to hold a pager forever?

Definitely. Yeah.

Right? And then

But the prima the upset the premium version of this that you don't host is sounds like a sweeter gig to me.

It it is, but it also is, you know, much harder to identify what the split is, like or even, like, know if you're building something useful. Right? Like, I would I would advise almost no one, go and start an open source project on something that's annoying them and then like try and build a pro version and sell it. I think like I think there isn't a lot of, like, obviously needful, unconquered stuff in that domain anymore.

It doesn't sound that wrong to me. If you had a problem at work and you built something, and you open yeah. I like I feel like you can sort of test this in phases. Like, did you have this problem enough that you solved it at work? If you did, can you extract something from the source? When you do, do other people care about the free version? If so, maybe there's a pro thing there.

Yeah. And, like, that

So it depends what the annoyances. Is it a business annoyance? Was it just are you mad about something in your Bank of America statement or something like this?

Yeah. And and also, no one values the time of programmers less than programmers.

Totally. Yeah.

Right. Right. Like like and that's the thing with, like, sort of turning open source, software pro is, like, such that, anyone's ever going to make a buying decision, they are probably in management and, you know, might be in a if you're lucky, they are an engineering manager. Like, if you're so they can actually understand the thing. But the the very first thing that somebody nets to the person making the buying decision is going to say is, like, I could build that overnight.

And

then and then you have to fight that against, you know, whatever egotistical tech lead or programmer is at your target, company ad infinitum.

I honestly think this was a sneaky advantage of Tuple. It's just that programmers hear about it, and they don't want to build it. Yes. Yeah. They're like, that sounds hard and annoying. And

so Yeah. Yeah. Video And they're right. Video streaming software is a uniquely annoying

Yeah. Yeah. Totally. Alright. This has been a lovely conversation. I think I think we I think we wrap it. We have a nice little chunk here.

Great. I mean, always always happy to chat.

Yeah. This was it was super nice to catch up again. Stoked to hear about all your things.

Cool.

Yeah. Cool. Thanks for coming by.

Yeah. Of course.

Anything you wanna, like, point people towards?

I mean, you know, I'll I'll just give the Stripe is hiring plug if you wanna come work at Stripe, Stripe.com/jobs. Lots of jobs all around the world, lots of remote jobs if you like where you live and don't want to have to move. Yeah. Take a look.

Cool. Awesome. Alright. Thanks.