6x founder and Shopify Principal Engineer on AI, Rails, and pairing with Obie Fernandez

I felt like I was getting screwed over. My position had not really changed officially. My salary had not really changed officially, but I was leading the practice, flying all around the world with Roy Singham, like advocating for Ruby, selling projects, essentially running a small business. consulting practice by myself, getting no respect, having probably three dozen daggers in my back from different powerful people who didn't like what I was doing and being told just to calm down. Eventually,

I said, screw it. From Tuple, this is Distributed, where we show how world-class engineers and their teams tackle the challenges of remote work. I'm Jack Hanna, your host. Hey, everyone. Today, we're chatting with Obi Fernandez.

Obi is a prolific musician, photographer, author, entrepreneur, and software developer, of course. As an author, he's most famous for the Railsway series. He recently wrote Patterns of Application Development Using AI. He's co-founded at least six companies that I'm aware of. And he's currently a principal engineer at Shopify, where he works on the developer acceleration team. We'll touch on that later in the episode.

He was an early member of the Ruby, Rails, and XP communities, and if any of those are interesting to you, this episode's going to feel super nostalgic. In the conversation we dug into his personal backstory, including a bunch of those early days, not just from Ruby and Rails, but also

Also from Java, we talked about pair programming, why he thinks it's worth it, when he thinks it's worth it and how to do it well, as well as how he's using AI both individually and with his team. And I'll be honest, it is a lot. He shares his thoughts on Toby's now infamous AI memo, the Shopify CEO, and much, much more. If you're into any of the topics I mentioned below, this conversation's a really fun one, so I hope you enjoy.

Hey, so Obi, as I was preparing for this interview, I stumbled upon the stir. that you created by shitposting Java in favor of Ruby and Rails in the early 2000s. I wanted to start here. When were you first exposed to Ruby and to Rails, and why did you take the language and framework so strongly?

Oh, wow. Shitposting was not a term back then, but I guess that's exactly what it was. I was really lucky in the earliest part of my career. I got into Java like right when it came out in 95. And I was literally just getting my professional software career off the ground. So I got very lucky to be in Java at that time and got into enterprise Java super early, super early, like with the initial...

releases of what eventually became J2EE and Enterprise Java, like the very first versions of that. And during those years, no one took Java seriously. Part of my DNA. was working in technologies that no one took seriously like java back then they were like oh this is for applets it's a toy it doesn't scale

write once, run anywhere is bullshit, doesn't actually work. Anything they could find to criticize Java, they would criticize Java. I was at my very first death march, which actually memorialized in my book called How to Eat Nachos and Influence People. I recently came across it again. On that project, we were working in Java at Daimler Chrysler, and it was a total shit show. It was a death march for many reasons I won't get into here.

But interestingly enough, ThoughtWorks, where I worked at the time, we were consulting at Daimler. And we had a product called Cruise Control. And I had a colleague on that project called Aslak Helisoy.

Maybe nowadays, not too many people know who Aslok is, but back in the day... Yes, yes, he wrote Cucumber. And back in the day, he was somewhat well-known... open source contributor like we had worked on dependency injection frameworks together and Java and things like that so we were buds and we were on this crazy project and as if we didn't have enough shit to worry about we decided to

Rewrite Cruise Control, which was ThoughtWorks' professional continuous integration product in Ruby. And we call it Damage Control. And I can't even explain the rationale behind this other than we were young and stupid. But that was my first introduction to Ruby. And ironically, I hated it. I absolutely hated it. So, I mean, I had been doing Java at that point for like eight or ten years. So you get really, really into...

Having a good IDE, I remember I was a big IntelliJ evangelist. I was really into strong typing and all the benefits you get from that. But I really respected ASLAC, and ASLAC had gone into Ruby. like head over heels in a big way the problem was that we were rewriting damage control on windows and like ruby's process control sucked anything that involved you know forking process or opening things that you need to do for CI did not work well on top of that

We were just using like jedit or something, you know, one of these like really, really basic text editors, no syntax highlighting one. So not only did we not have typing, not have IDE, didn't even have color. you know, syntax highlight or anything like that. It was madness. I ended up thinking it was crazy. And that was stacked on top of all the pressure from the project. We ended up quitting that project unceremoniously. And luckily...

ThoughtWorks didn't ding us for it because the whole thing was a shit show from top to bottom for reasons that weren't our fault. And I ended up getting sent to a project in the UK called Dixon's. And there... I met up with another friend from ThoughtWorks named Carlos Villela, not as well known as Aslak, but great guy. And he had also gotten into Ruby. I respected him. And he was harping about this new thing called Rails. And Rails...

at the time was like way pre-1.0. So this is like literally January 2005, right? So I don't know exactly what version it was. But I checked it out, and a lot of my background in the previous four or five years had been doing a lot of web apps with Java, so like Tomcat, JSX, things like that. And as soon as I tried Rails, I got it. I got why this was like so much better than the existing situation with Tomcat and with J2E.

I liked that it was full stack. I liked that it was convention. I actually had a lot more exposure to dynamic typing than I realized at the time because Previous to ThoughtWorks, I had worked for three years developing a lot of stuff in JavaScript. And I guess even without realizing, it had warped my mind quite a bit. So I took to the dynamic typing part right away. The other thing, too, that was really notable...

about that particular period of time in 2005 is that a lot of the leading people who were, let's call them luminaries and thought leaders in Java and other open language, even .NET and things like that, made the switch. There was like change in the air, right? Like this is new, this is exciting. So there was a big movement. You know, I saw myself as having the ability to jump on this in a not accidental way because people, they, you know, that I mentioned before.

were criticizing Ruby for the same reasons that I had heard them criticize Java for like almost 10 years before so I said okay well this criticism not only is not valid to me, it almost validates the fact that this could be big. The fact that you had a contrast of it being so good that a lot of the smartest people I knew were moving to it, and yet there were so many voices.

against it yeah it was like a dramatic contrast and for me who had already been doing a lot of shit posting online in my blog and like was already a controversial figure even before Ruby via my blog post. It was just a really natural fit. And I thought Ruby and Rails have this dualistic dichotomy in the community.

in that there's this concept of mats is nice so we are nice is minneswan is like actually part of the doctrine of ruby because mats the the japanese creator ruby is a really famously nice guy and then dhh who's a dick you know he's like a total asshole and he has always prided himself on not really caring what anyone thinks and just being uh you know iconoclastic kind of knock down whatever

obstacles there are to getting whatever he wanted done. And I liked it. I felt that radical change required someone like DHH that Nice wasn't going to cut it when the odds were so stacked. against the adoption of this new cool thing right it was going up against a very powerful set of adversaries you know like there was a lot of money

A lot of money riding on J2E. IBM championing with their product. You had a number of other kind of big vendors and things like that. And a lot of serious voices saying that that was the way to go. And you had Microsoft with .NET.

right but but you can't argue with results and at thoughtworks we went from being almost a complete 50 50 split between java and net in 2005 to ruby work representing over 40 percent of revenues of global revenues in 2007 in two years wow that's a really quick turnaround i understand you led the first ruby focus team there do i have that right i did the first

ruby on rails paid work at thoughtworks in march of 2005 march or april at john deere so it wasn't just like at a startup or something yeah and company it was at john deere A few months later, when it came time to deploy that work, Dondear IT basically told us, no, you can't. We only support Java and .NET in the data center. And we pushed and we pushed. And after a while,

You know, we figured, OK, there's plenty of like Pearl CGI apps and things going on. So how do you support that? Oh, well, we can give you a server, but you'll have to manage it yourself. And then, you know. One thing led to another, and that was the first deployed Rails app at a Fortune 500 that I know of.

John Deere is not even Fortune 50. It's probably Fortune 50 or something, right? Yeah, it's quite big. I actually interviewed a principal engineer there, and we talked about some of those early days that we didn't have this direct connection, so it's kind of cool seeing some of this stuff.

come together. Fast forwarding a little bit, you had this early exposure to Ruby and to Rails. You took to it immediately in part because of this contrast that you notice between some of the smartest folks you know really leaning into it.

folks over here having this really negative reaction to it. And I actually think that that feeling of contrast and disagreement and emotion is often a really good signal for for also starting a business and in addition to identifying what is like a an interesting technology to lean into but what might be an interesting business to lean into and i think it's kind of interesting that shortly thereafter

In succession, you started six companies. Well, you know, six companies over 16 years for that matter, which 16 years might not be very quick, but six companies is certainly a lot for that period of time. I was wondering what drove you to create and to start so many things.

You know, it's funny. I was actually quite happy at ThoughtWorks and I was making what I considered to be a good amount of money and I had the respect of my peers and I got to work directly with Martin Fowler and other significant people. But as I mentioned before...

We went from zero to 40% revenues in the Ruby practice, and I was kind of like leading that practice. A lot of people's cheese got moved, if you will. It was a disruptive change within the company. So ThoughtWorks had a very flat management structure. there was practically no management of line personnel i mean there was a resource management group which was like four people you know or five people for like i don't know almost a thousand consultants worldwide

And they were the ones responsible for placing you on. We had a lot of latitude, right? I remember being assigned to Bank of America and told I had to take a drug test. And I said, sorry, I won't do that. Well, yeah, I was surprised that you and Aslak could quit that project unceremoniously and it not be a big deal. Oh, no, no. I mean, like I said, I wrote a serious chapter in my book about this project. I mean, it was a death march and it was not going well.

We had to get heavy duty firepower. But the point I was trying to make is that, you know, you asked like, what does it mean that we moved a lot of people's cheese or why was it disruptive? Because all of a sudden people didn't want to work on other projects anymore.

They didn't want to work in Java and .NET. They wanted to work on Ruby. A sizable amount of people in the company, including a lot of the best talent in the company, just refused to work on other work that wasn't Ruby-based, which pissed off a lot of...

Business development executives, you know, a lot of clients, you know, people who are responsible for delivering clients and pissed off a lot of people who didn't like Ruby, which we had a fair amount of people that were contrarian voices as well saying that it sucked.

Is that what led you to start AshRocket? Yeah, that was essentially, you know, one thing led to another. And eventually I felt like I was getting screwed over. My position had not really changed officially. My salary had not really changed officially, but I was leading the practice.

flying all around the world with Roy Singham, like advocating for Ruby, selling projects side by side with business people, with salespeople who weren't doing anything. I was literally writing contracts, essentially running a small. consulting practice by myself getting no respect you know having like probably three dozen daggers in my back you know from different powerful people who didn't like what i was doing and being told you know just to calm down eventually

I said, screw it. I don't know when it started my own thing, you know. It was hard from the standpoint of quitting a salaried position, you know, and leaving what was essentially a prestigious job to the unknown. I mean, I had not really run my own business before that point. I had done some self-employed kind of stuff before my first career IT job.

And it had gone so poorly that I said, I'm never going to try that again until I actually know what I'm doing. So it took well over 10 years, probably 12, 13 years until I even consider it again. The timing was perfect for HashRocket, right? My book came out. The back of the book literally advertised HashRocket. We got a lot of business that way. The book was a massive success. More than probably people can appreciate these days because books are like...

Not as big a deal as they used to. But my first royalty check was almost $50,000. I literally went out and bought a car. And that was back in 2008? 2009? 2007. 2007 oh wow and that's the world's way the world's way yeah yeah

An incredible experience, obviously. And HalfRocket wasn't the last company that you started. Again, I think you went on a succession of starting four or five additional companies thereafter. And today, despite all of these entrepreneurial journeys, you're a principal engineer at Shopify.

company who's known for its work in Rails and DHH just joined the board. And it's obviously a company that has given a lot back to the Rails community. I want to talk very briefly about what your team does at Shopify, because I think... developer acceleration sounds like this kind of cool but ambiguous thing. And then we can get into a little bit more about some of the practices and ways of working that we talk about quite a bit here on the show.

Sure. I probably couldn't have predicted that I would be working for Shopify. I was kind of prejudiced against big companies. My biggest startup success story, which is Andela, where I was CTO and part of the founding team, when we started getting too big, I left because it was just like...

the politics and the organizational dynamics i just i didn't want to deal with it i much prefer leaner kind of get ideas off the ground kind of situations you know i was working for the last two years on a startup called olympia which didn't really go anywhere, but it was successful in its own right. It's just that I was coming off raising 7 million for an NFT platform, hired 100 people. So that was like one end of the pendulum and I kind of swung all the way back.

So literally just wrote Olympia with very little help, accompanied by me and my girlfriend, who's the CEO. And it was essentially a ChatGPT wrapper before that even became a term we launched. the summer of 23. The revenue went up, and it was kind of good, and we were cash positive kind of right away, and I didn't want to raise any money, and then it went down because Chatsubiti and the rest got better.

However, the good thing about Olympia is that it gave me a lot of practical experience in prompt engineering and AI development. I ended up writing a book called Patterns of Application Development Using AI.

I started going out and talking about it at conferences, including Rails World. And at Rails World last year, Toby, who I've known for decades at this point, And Duncan Davidson, who I know back from Java days, because he was like the author of Tomcat, when I finished my talk presenting patterns of application development using AI, I came down and they were like, hey, you need to come present this at Shopify.

And I was like, hey, I'd love to. That'd be fantastic. And then one thing led to another, and it turned out that there was a position as principal engineer working with some of these advanced AI initiatives to improve our developer experience. Here I am. It was actually humbling to join because I thought, woohoo, I'm going to start working on the AI assistant for the Shopify admin or something like that. No, it turns out there's probably two dozen people working on that.

There's like literally hundreds of machine learning people and like practically everyone at Shopify is working on AI in some way or another. What the group that I'm most closely associated with does... is to use AI to improve developer experience. So they're by nature cross-cutting concerns across the organization. They're not specific to any product teams.

And or if motivated individuals on product teams are developing cool things that we can then generalize, abstract, and apply to the rest of the organization, then we do that. So for instance, at the moment, I've been working a lot with structured AI workflows as a complement to using agents. Everyone, and rightly so, is taking advantage of cursor agent, cloud code.

But there is still a very valuable place in that stack for having structured workflows, meaning I want to configure... in some cases even like a state machine sort of thing where it's like i want to go from this step to that step to that step in that order always i don't want it to be non-deterministic i don't want it to be up to the agent i want to tell the agent here you have this tool

Use this tool whenever I want you to do X, Y, or Z. Take the results of that tool, feed it back into your process. So that's the kind of stuff I've been working on. Yeah, I mean, sounds like pretty cool stuff. at the intersection, a lot of the work that you've done in the past. I know you care deeply about how folks work together. Obviously, you were early at ThoughtWorks and ThoughtWorks prides itself in pairing and agile practices. Hashrocket is a company that is kind of well-regarded

for leveraging these practices as well. And so I do want to shift gears a little bit and talk about pair programming specifically. It's something we talk about quite a bit in the show. I know it's something that you care about. And then weave back in this AI angle because this intersection between

How humans collaborate with each other and then how they collaborate with things like AI, I think is really, really interesting and evolving pretty quickly as these things get better. And so I'd like to talk about both of these things. Do you think every developer should?

Pair program? MARK MIRCHANDANI- It depends. But it also depends on how you're asking it, because it's super open-ended, right? I think every developer should have the experience of pair programming, especially early in their careers when they can most benefit from pairing with more senior people. To me, one of the main benefits of pair programming for a general audience is the mentorship aspect of it.

There's just so much that you can't learn on your own. You can't pick up from books. You can't pick up from AI. What are some examples of those things? It's the myriad little efficiencies and thought patterns that...

make a senior person senior, right? Especially around knowing what not to do. Going back to the earliest experiences I had with peer programming, I mean, just... Just being reminded to really look at a stack trace before just assuming or before running to debug, you know, or to debug statements and the code. It's just one of the probably thousand examples I can think of, right? Just having someone who's been there and done that.

A lot of the most talented junior people I know are just too fast. AI is not making it any better. No, no, no, definitely not. And when you're at that stage in your career, speed, energy are two of the things that you can differentiate on, right? Understandable, but that slowing down piece seems like a clear benefit of pairing. The way you've described pairing seems somewhat one-sided in its benefit, benefiting mostly the junior and not the senior. Is that how you feel?

No, but I was reacting to the fact that you said everyone, right? Sure, okay. How I feel as a somewhat senior, pairing is not necessarily as fun for me unless I'm pairing with someone else who's as senior as I am. then like we can really kick ass. And it's still fun. It's still effective pairing with less senior people. It's still a way to maintain focus. It's still a main, you know.

Still a way to knowledge transfer. You still learn things even from your junior pair. It's just not necessarily as fun. It's also harder to do certain kinds of activities when you don't have a balanced pair. For instance, the... The code base that I'm actively working on right now, very rapidly advanced.

over the course of the last two weeks using what is almost five coding, let's call it. And it was what we needed at the time. So we were able to show results like it was essentially a lot of prototype level code, right? I've been looking at this with concern, in particular because the team, myself included, let the AI write a lot of the tests and the code. And a lot of those tests were hot garbage.

They were not testing behavior. They were just full of mocks and stubs, like line by line, verifying the implementation of these methods. Because it got stacked on several times, it just was getting to the point of unmaintainable to me. Since I like the TDD, I need the test to be clean. You know, the test for me can't just be an afterthought. And I finally got fed up and I rewrote it over the weekend.

because we have a few people working on this code base and it's hard to do like a major refactoring i had wanted to do it with with one of my developers in a pair i thought it would be a good experience yeah It was a hard rewrite. It was kind of like a rewriting throwaway code. Going back to some initial assumptions, if I had had another very senior person to go through it, I think...

that would have been great. But going through it with a less senior person who doesn't even necessarily see the value in the rewrite right away, that's painful. Yeah. Well, it's painful for you personally, but it's also an opportunity for them to better understand why the rewrite is necessary from your point of view and what better looks like, isn't it? I agree. But sometimes you just need to get it done.

One thing that I'm still undecided on in terms of long-term consequences, both seen and unseen, of this AI revolution that we're living through is that... I've even had people tell me that quality doesn't matter, that rewriting doesn't matter, that it's not necessary. If you can just generate code nearly for free, then what's the point of writing clean code?

Because as the situation changes, you can just rewrite what you need again. What's your response to that? In most cases, it's bullshit, right? Because a prototype is a prototype. I don't mind vibe coding, and I've done plenty of it myself. That's okay if you're trying to prove a concept, or you're trying to see if something works, or you're trying to see if you're going to get adoption. But if something becomes...

production software, then it's bullshit. I have not met anyone yet who is anal retentive enough to go through every single line of AI-generated code with a toothpick, especially if you start getting into dozens and hundreds and even thousands of lines of code.

There's just no human that can do that. Now you have production code that you literally don't know what it does. And how are you judging it? Because you generated the tests. You generated the implementation and you generated the test. How do you know?

that that code actually does what you think it does with any sort of reliability. How much AI did you use when you rewrote it? I used it probably 10 or 20% when I rewrote it because... One of the main things I wanted to do was to rewrite the test suite. And I haven't nailed the magic prompt that makes Cloud 3.7 write behavior-oriented tests. It just really, really wants to test the implementation.

Once you kind of get it in the right direction, it can kind of continue the flow. But certainly from scratch, I just have not figured out how to make it do that. Hopefully that's changing, you know, with 4.1.

and with efforts to to make the models better in fact everything i mean i just assumed that everything's going to get better one of the things i'm not like despairing about the situation that i assume these models are going to get better and eventually you know tying it back to the pair programming question Right now people see working with AI as working with a junior programmer at your side, but I think eventually the best case scenario is that it can be like working with a senior pair.

in the sense that the AI could be smart enough to tell you, hey, don't do that, or what if we consider this approach, or let's take a step back and think about how we implement it. You know, the kind of things that a senior would do, right? Is human-to-human pairing and modding still a thing in a world where these tools are that advanced? Yeah, although you end up

I mean, at least from my current experience, you end up sitting there and watching the cloud code do its thing or cursor agent do its thing. But you basically pair on telling the bot what to do. I don't know that we'll get to a situation where it's writing 100% of the code. Maybe.

But once we get to the point where it's writing 100% of the code, why do we care if it's Ruby or Rust or Python or Java? If all you're doing is telling it the outcome that you want, then it starts becoming more and more like Assembler or... You just don't care, right? What you care about is the artifact of what you told it. Yeah, you care about the behavior and the user experience and what the output is. Yeah, what you care about might ultimately end up looking like cucumber.

You know, like Gherkin, right? Like it's somewhat structured pseudocode-ish representation of what was discussed, probably summarized in some way. that is reliably translatable to some implementation code. As you were talking about some of these things, I was picking up on your body language and the way and your tone of voice that made me... get the sense that you feel like collaborating on telling the AI what to do is not that fulfilling of an experience.

or rather is less fulfilling or meaningful than traditional pair programming. And so I want to talk a little bit about... How does human to human connection collaboration evolve? And should we care about that even? I think it just ratchets up the abstraction level. You know, like the last meeting I was in on Tuple, you know, in a team room.

Was a couple of my engineers pairing on a Figma diagram, like designing a state machine for how to generate a particular type of code using an agentic flow. They weren't using AI for that, right? Yeah. just drawing boxes. They were pairing. Just because you're not writing code doesn't mean you're not pairing. Two brains, or three brains, you know, whatever the case may be is, for certain things is still better.

I want to go back to something you said earlier. You asked me if it was less fulfilling. Yeah. I don't think so. I am an advocate for generative AI overall. What is fulfilling to me... is the outcome is not the act of writing the code right like i could have done with not spending 12 or 16 hours this weekend rewriting there was some fun to be had but

I've also been coding professionally for 30 years, so there's like a certain ceiling that you hit on. But what was fulfilling is that on Monday, we could start with a clean slate.

And I know that we're not just building on top of garbage. That's what I was really happy for. And to the extent that AI helped me achieve that, because the fact that I had agent help meant that I... could get more done that i would have otherwise that i stayed focused because i didn't get stuck that's fulfilling and that's fulfilling direct in a way that's directly related to ai if i didn't know that i had ai help i might not have even undertaken that effort

Right. Because I might have felt like I wouldn't have finished it in the weekend. Right. It was the sort of thing where I was like mostly finished on Saturday night. And then on Sunday I was like, well, I'm just going to tie up some blue sense and I spent another five hours on it. Yeah. You know, sort of thing.

But the reason I got it done so quickly was because I had AI help, right? And I had that confidence that was born of it. If I didn't have that, right? Like if this had happened two years ago, I don't know if I would have launched it, right? I might have just...

told the team, hey, we need to work on this, and then just prioritize it normally. But you wouldn't have had the same problem either, probably, because folks wouldn't have vibe-coded for however many weeks or months. That's an interesting premise. I'm not sure I agree because, you know, a lot of this vibe coded stuff is not that different from what we would call spikes or prototype code. And I'm a person who has typically worked pretty fast.

And I don't mind not pairing and I don't mind not doing TDD if it's for just trying to push something out for a particular reason. One of the most infamous talks I ever gave was where I got up in front of an audience and I said, don't do TDD in a startup. Like, don't try to write clean code in a startup because your startup's probably going to die. So it's a waste of time. And even within a big company like Shopify, there's plenty of startup-y types of things, right? You have an idea.

They get some sort of support or backing, and you want to do it, but you need to prove it. I'm relatively new to Shopify. One of the things I'm liking about it is that it's not particularly corporate. It's very startup-like, and it's very driven. Our project management...

system is called GSD, which stands for getting shit done. I mean, it's a no nonsense kind of like get shit done. And it starts out with an explicit prototype stage where you're supposed to just prove out whatever your concept is. and not worry about is this super clean or is it well tested or whatever you're just trying to prove it

And I think Toby mentions that in the memo, that it's a requirement to be using AI at that stage. I mean, you use pretty strong language about the expectations around this stuff. And I think it speaks to what you're talking about, which is... the fact that there's an expectation that people move fast and

People live with the consequences of moving fast, but you move fast in service of figuring things out quickly, of deciding whether or not something's worth spiking over the weekend to fix. Then the challenge becomes knowing when to stop. vibe coding when to slow down how much to slow down right i've literally been having discussions with the team going hey you know this thing that we've vibe coded in

two weeks, it's okay to take a day or two to refactor it and clean up the test suite because there is this infectious energy to just do more and more and more as quickly as possible. Are you worried about that for the industry or for the company for that matter to make it super tactical? No, I wouldn't say it reaches the level of worry. The older you get, I think you start realizing nothing really matters. If something's production needs to be reliable...

You have to know that it's going to be maintainable, right? Even if it's your future self. If you're not experienced enough to know that your future self is going to pay the consequences, well, it's a different story, but hopefully there's enough senior cooler heads on the team to prevail. and say, hey guys, we're about to shoot ourselves in the feet here.

And if not, you'll learn the hard way, right? If not, you learn the hard way. That's why I said I'm not particularly worried. Yeah, that's fair. I'm looking at the clock, and Obi, we're coming off on time much faster than I expected. I'm wondering, zooming out a little bit, what would you hope folks take away from this conversation?

or what message would you like to leave folks with as we wrap up the call? Well, one of the topics we didn't get to talk about is like big P versus little P pair programming. Yeah. Big P pair programming is what I see as the original. Kind of like the old school meaning of the term per-programming as MPEC described it in Extreme Programming, which is two people are sitting down, one keyboard, taking turns developing software, right?

features or whatever it's orthogonal to whether they're doing tdd or not it's just the fact that it's two people working on the software at the same time but they're developing things and what i've seen over the years is that More and more peer programmers used to refer to any act of just getting on a call together to look at something, which has always existed. It's like calling someone over to your desk and say, hey.

this thing that you wrote is not working. Can you help me get through it? Or I'm stuck, you know, in whatever way. And then you work on it for a little while and they go away. That's what I call little P pair programming. And in informal surveying of people over the years, that's what most people nowadays, I think, refer to as peer programming. And there's great tools like Tuple for doing that.

The big P peer programming, I think, is where the real learning takes place. Mentorship, shared code ownership, knowledge transfer. A lot of the best things that you get out of peer programming are necessarily with the big P. And that takes management support and that takes people who are open-minded to working on it. It takes skill because it's frustrating to do Big P when you're not used to it. It takes patience with your pair. Numerous skills, right?

that are involved in having really satisfying principle pair programming taking place. That's why there are places that are known as legendary pair programming shops like Pivotal, to a lesser extent, HashRocket. Because we practiced it all the time. It was part of the culture. Everyone got good at it. Yeah. The number one failure mode we see is that people try it, have a terrible experience because they failed at working together effectively. And then right off the...

any of the benefits that can possibly come from the experience because they felt exposed or frustrated or pissed off from whatever the experience was or just that they didn't get anything done even for that matter. Yeah. It's kind of this bittersweet moment right now in history because I think everyone is pair programming to a certain extent. Anyone who's using an AI agent is essentially pair programming. I have a feeling that this might be like...

the final nail in the coffin of people actually establishing pair programming shops and practices like we had at Pivotal. One of the nice things about working at Shopify is we do have thousands of engineers. So I wanted to... you know, kind of champion some of this stuff regarding the big pair programming and whatnot. And like almost immediately was able to get a Slack channel put together with like 50 or 60 people interested. But at your average startup?

I don't know what you would do. On the other hand, I mean, there is a positive potential future where if the coding agent is powerful enough, it might actually mitigate some of the most annoying parts of... of peer programming which is sharing the keyboard especially sharing the keyboard with someone who types slower than you the practical things that make peer programming annoying

to a certain degree could be mitigated by the fact that you're just taking turns telling, you know, communicating to the agent what to do. Even right now, I mean, assuming the agents don't get like... orders of magnitude faster, you know, the fact that the agent is kind of sitting there cranking along gives you an opportunity to talk to your pair about what's going on and what, you know, it kind of builds in a buffer, builds in slack, if you will.

to be able to discuss, okay, what direction are we taking? Is that the right thing? Do we want to backtrack? The kind of conversation that you're supposed to be having with your pair in order for it to be a good experience, which a lot of times lesser experienced pair programmers don't do.

Because someone's just like, someone's driving. Yeah. And the other person's sitting there watching. Yeah. Or one person's dominant whether they're driving or not. So we're just doing whatever they say. So there are positives. Yeah. There's some reason for hope. i guess it's just going to look different totally you know it's change

It's a thing. It's a thing. We figure it out. As you said, maybe none of it matters. Maybe it all works out and we figure out how to deal with it one way or another. I do think that will be the case. Yeah. Well, in any case, I mean, yeah, thank you so much for making the time. I appreciate you being generous with your time and perspective on this stuff. If folks want to learn more about you, your work, where should they go?

Well, a good launching place is obfernandez.com. That's kind of got links to everywhere. Or obfernandez on Instagram is where I put a lot of my music stuff. I don't use Twitter anymore. But on the music front, I've released my debut artist album on Friday. I'm really proud of it. That's on YouTube and Spotify. Just search for Obi Fernandez if you're interested.

And yeah, nowadays I haven't been blogging too much, although I'm planning to start again, you know, maybe on a Shopify blog pretty soon. So keep an eye out for that. And my book is on Amazon. And on LeanPub. So if you want to support me on LeanPub, leanpub.com. Just search for that and Obi and my patterns of application development using AI.

book and course will come up or if you want the kindle version or hardback or softback it's on amazon as well cool good deal yeah we'll link to this stuff on the show notes so folks can find it more easily as well it's a pleasure having you on obi thanks thanks thanks again yeah i love you guys Thanks for joining us on Distributed. If you want to learn more about what we covered in this episode, or if you want to share your own thoughts, follow at Tupel on X or visit distributed.fm.