Don't sleep on Ruby & Rails

Well, we’re here with Justin from Test Double. What’s up, man? Welcome to the show.

Hey! Thanks so much for having me back. It’s been about a decade since you last had me, and I didn’t know whether to take that personally…

I wouldn’t do that… It was actually a – we’ve been missing you.

Yeah.

Yeah. The wisdom. Bring it.

Yeah. I don’t know if I have wisdom so much as…

Opinions, wisdom…

Yeah, I have – what’s that thing we’re supposed to have? Strong opinions, loosely held?

That’s right. I’ve heard that one.

Right? I’m a firmholder, just constitutionally… And so I speak with zeal and passion, and I change my mind every couple of years.

There we go. Well, then we have you back at a good time, because maybe your mind has changed, maybe it hasn’t… One thing that’s happened in the meantime - of course, any listener who remembered that first episode, congrats to you, I guess, for sticking around for a decade…

That’s right.

…and remembering Justin Searles was on back in like the one hundreds, talking about Lineman.js. You’ve also been on other shows around our network… So people can go back into the feeds and find more of Justin’s strong opinions firmly held on our other episodes. But you’ve also been running Test Double for a decade plus. This is a thriving dev consultancy shop… I’m not sure what y’all refer to yourselves as, but tell us about Test Double, just like size of the company and what y’all do.

Yeah. Well, first I’ve got to correct the record, that at really no point have I ever run the company… And so I think I credit a lot of our longevity and success to that fact. Test Double is really the story - at least that’s how we started - of me and my co-founder, Todd Kaufman, because he and I, we share all these same principles and values, and like broad strokes opinions about this industry and the mission that we’re on to improve how the world writes software… But if you looked at us from like a temperament and a skill perspective, we couldn’t be more different.

And he’s our CEO, and he is the guy who can run the company. And I - I used to be really good at tweeting, and been working on that, and now I’m learning how to toot, and getting back to blogging, and YouTubing, and all that stuff… But honestly, I think that the thing about Test Double to know at this point in 2022 is we’re about 105 or so, 100-ish consultants. Most of our engagements as a consulting company, we are embedded with engineering teams at companies who give a s**t about trying to do things better… And that’s really universal. Anyone who thinks that software should be better, and is striving to get better, and wants some outside salt to both get stuff done, accelerate a team’s ability to deliver stuff, and also leave their team better than we found it, is a good partner for us. And we’ve got clients that really run the gamut, from startups building new products, to companies like GitHub and Gusto, who are trying to renovate large and existing code bases in a nimble fashion.

So yeah, we are very adaptable to meeting our clients where they are, and understanding that you’ve got to start somewhere… And we’re really gifted, I think, or we’ve built a really gifted team, who are skilled at hitting the ground running and understanding that they’ve got to win hearts and minds by just showing up and doing the work. So I think of us as sort of like – we used to joke that we’re like a blue collar agile software consultancy, back when people still use the word agile with some regularity…

It was the selling point, right? Like, the agile agency… We must google “agile agency for hire.” It must be a challenge running that kind of business, right? I mean, you said you don’t run it, admittedly… But I’m sure you’re a part of how it operates, and part of its success, to some degree. I mean, be humble if you need to…

[05:59] I’m curious, is that a challenge? Like, I think of like the Toptals, and the placement agencies… How have you been able to survive - if not thrive, I don’t know - for ten years in a world where you’ve got Toptal in the top three percent… And I only say them because they’re a past sponsor, and we kind of know their message a bit… And that’s like the one I think of most when I think about a brand, or a company who cares about placing software developers globally, really, in the realm of ability to place the better ones. They’ve got a vetting process, a certain amount get through that process, and they engage with the GitHubs and the Gustos. How do you compete and how do you operate in a world where that exists?

Well, if you went to our website, testdouble.com, which you should do, it wouldn’t really tell the full story of how we’re different from a staffing company, or a placement firm like those, or like UpWork, or something… Because if you just compare our people versus other people based on hourly rate as if you’re doing an apples to apples comparison of what you’re gonna get, I think that’s a flawed analysis… Because our company, what we really are is we’re change agents. So if you go to Toptal, or you go to UpWork, and you take the highest-rated rent-a-coder, and you pull them into your organization, the best-case scenario is that they onboard really well into like the engineering system, culture, or process codebase that you’ve already built… And when you work with us, and what I think some of our best clients would tell you, is that our people change the culture that they’re in for the better. They work within your culture, and they’re in it, and so they have all the context to understand ways that the team could improve, or the organization could improve, but they’re not of it. Our engagements are usually three to nine months long, we rotate on to the next thing… And so our consultants are driven by that mission and purpose, but when they rotate between so many different projects, always meeting clients at really high stakes moments, when they’re trying to affect change in their organizations, it produces a sort of like a pattern recognition machine in our brains as consultants, that helps us on each subsequent engagement. We show up and we’re like “Oh, you know what? This rhymes with something I’ve seen before. Have you maybe considered this?” Or “Hey, I was at another client that had a similar problem. Would you be willing to give this a try?” And that is a pretty big, I think, differentiator between us and a lot of other firms. And I think it’s a big reason why we’ve been successful. Not because I’ve got firm opinions firmly held, but because I was able to talk a lot about them in public and attract a lot of people who’ve got strong opinions loosely held, and they’re maybe able to live up to that mantra a little better than I can.

So when people come to you and your teams, they’ve already sort of adopted, or already bought into your view of the world, like what you think creates better software? Or do you have to also kind of sell them from the inside about the way you go about things? Because one thing I didn’t know about you, Justin, is you do have a very specific view of things… And maybe it’s changed over time. I remember maybe an older version of what it was; I could probably name a few things that I think you believe, and maybe we’ll let you name off some of the things that Test Double believes in in crafting software… Is that a process that happens, people come to you and they’re like “We want the Test Double system”?

You know, what’s funny about that is if there’s a spectrum, if there’s two polar opposites between a staffing firm and like a delivery firm that just like claims to have figured out software development, like “We’ve found the silver bullet. Our way is the perfect way…” And when we founded the company in 2011, I was very cognizant, because I was hanging out with people from [09:46] from Thoughtbot, from Hashrocket, I was hanging out at the offices of like Pivotal Labs in Boulder, I had some friends there… And each of them had a different marketing strategy that basically said, “We’ve cracked the nut on software. If you’re frustrated about software, pay us money and we will be the panacea to all these problems. Trust our people up in this ivory tower, who are going to hoist upon you this perfect code, and you’re just going to be able to pick up and run with it.”

[10:16] And I thought that was both patently disingenuous, because it doesn’t respect the fact that I think software is just encoded communication between people, and all parties need to be in the room, working together through it. It’s not like the artifact is what matters, the benefit is in the planning and the conversation and the shaping of that stuff… And so it’s a joint collaborative exercise.

And secondarily, I would look at a company like [10:43] which at the time had a kind of pyramid-shaped engineering progression scheme; I think I saw a diagram of this one, with - you’re all craftsmen, and then like the top was the master craftsman, and that was Uncle Bob, who was one of the owners in the company at the time… And I just remember thinking as somebody who likes – if I’m not humble, I at least like self-deprecating humor. I was like “I can’t start a company, put me at the top of the pyramid, and then tell everyone that they’ve got to do things or think things the way that I would do, because a big part of me and my co-founder Todd’s kind of ideology is inspired by E.W. Deming, which is like in the Toyota production system, “You’ve got to trust the people closest to the work to make the right decision.” So if there’s some talking head up in the clouds like me on Twitter saying, “No, this is how all your tests should look”, then it robs the team of being able to actually look at their situation with all the rich context that they have, and make the right decision.

And so I would say even from our first hire in 2012, and onward, there has always been a very healthy disrespect of Justin’s ideas and takes. I’m more meaning to share them to be an exemplar of what it looks like to care a great deal about this craft, and the journey that we go on as humans to kind of build great things together.

Wow.

Well said.

Great job. That’s a great base to build from, honestly. I mean, it is humble, and it is self-deprecating in terms of humor, but I think that’s a great base to build from, because you need to – I like the idea of trusting the people that’s closest to the work to have that rich context, as you said, to make the good decision, versus somebody who’s so far removed, and potentially even domain-wise on something completely different, and your current thought may not translate well… So why would you disable them?

Right. You’ve also stayed in the weeds for the most part, haven’t you, over the years? I feel like maybe you’re not – I don’t know, you can tell us; maybe you’re not deployed on specific projects and stuff, but I’ve seen you continually presenting your ideas in the public, showing real code, working on side projects, doing stuff that is real… And so while you don’t want to have the ivory tower, Justin’s “Here’s how we do things”, I think it probably would be fun working in your orgs, because you probably do have to like represent your ideas, and like let the truth come out through the discussion, through code, through argumentation… Do you feel like you’ve stayed relevant over the decade, or have you felt like – like, are you one of the people that’s close to the problem, or no?

It’s a great question, and I think that the answer kind of lies in my joking description that we were like a blue collar agile consultancy. A big reason that that was top of mind for me was I was seeing a lot of capital T, capital L Thought Leaders just slowly veer away from anything that looked pragmatic, to just sort of becoming an echo chamber. It’s a big reason why we’d never called ourselves a capital A Agile consultancy at any point, right? I’m not sure it was ever on the website, even the word. And if you think you’ve got it all figured out, then what ends up inevitably happening is you will be met with circumstances for which your prescription or your favorite way of doing things is not a good fit; maybe it’s no longer a good fit, because the industry has changed, or maybe it was never a good fit for this kind of particular circumstance that you just hadn’t run into before.

[14:08] And every time we as practitioners run into something like that, we have a choice; we can either dig our heels in and try to force the problem to be shaped like the solution that we like, or we can, adapt and try something new, and maybe it’ll have pieces of other solutions that we’ve seen in the past. But every single problem is a new one.

And as a result, for me in my own practice, I’m very sensitive to the idea that if I just go off and speak at 25 conferences a year, or at least in the before time, when there were that many conferences - if I just talk and talk and talk, eventually I will lose touch of the work. And so I had several very fortunate mentors early in my career, and one of them told me that everyone goes through seasons in their career. We like to think of it as a progression. It’s a step ladder, and you’re just like “Okay, I’m senior one. And now I’m senior two…” We’ve had all these kind of titles promulgate over recent years. “Now I’m staff, and now I’m principal…”, and like that’s the track.

I think of it instead of as “In this season of my life, this three months or six months, I’m gonna go heads down, sit really close to the ground, and really listen for the pain points that I’m experiencing, or that this team is experiencing, and I’m going to take notes.” And then Jerod, when I went to speak at your conference at NEJS in Omaha, what those events were for me was a chance for me to plant a flag in the ground and look back over the last six months of my life and say, “What did I learn? Was it worth it? What from this experience that I’ve just had might be useful for somebody else?” And surely, there’s something. And there have been times when there really was nothing, and that’s separate feedback about how am I spending my time and what am I choosing to focus on.

So what I’ve been doing this year has been to take dedicated time to build custom applications inside of our company at Test Double that a scaling business now needs. You know, you’re a 100-person company; we’ve got a bespoke approach to how we staff people onto engagements to make sure that the client gets what they need, and the people get what they need… And by building that, I’ve observed so many cool things about both new tools that are great, as well as popular things that I think aren’t so great… And that’s the opportunity, or that sewing gives me the opportunity to reap those sorts of opinions from a more informed place, where I can actually play ball with other people instead of just kind of talk at them.

Yeah. Well, I think it’s a great setup, because that’s kind of what we have you here to talk about to a certain extent today, is some of your findings and some of your gleanings and learnings and thoughts about the state of web development, about Ruby on Rails… I think there’s some setup to this particular conversation, a few things… The first one is - over the summer we did an episode… Adam, what was it called? “A new set of web frameworks emerge”, something like that…

Mm-hm. Yeah.

…where – it was actually a trifecta, a sampler platter I think we called it, of JS Party episodes, where we had interviews with Fred K. Schott from Astro, Miško Hevery from Qwik, and Luca Casonato from Deno’s Fresh framework. And I was on one of those three original JS Party episodes, and therefore was on the show, and one thing I said about Fresh at the time was it seems like finally, for me as a person who has roots in Ruby, and Rails was my first big framework - if you don’t count WordPress, which is where I really started, it was Ruby on Rails… And then the Node thing exploded, and we went kind of that direction, as many of us did… It seemed like the JavaScript community was kind of starting to finally come around and accepting that a batteries-included full-stack framework can be a good idea, can be a good thing… Versus the small libraries, piecemealing everything together for yourself, which has kind of been the ethos of the JavaScript world.

[18:07] After listening to that show, we had a lot of feedback, some tweets, kind of like saying “Rails devs are out here listening to Deno team talk about Fresh, and talk about some of these other things…” It’s like the Rails devs are out here, kind of rolling our eyes, because we’ve been here for a while; we’ve had this, and Rails isn’t cool anymore, or whatever. And so like people have to rediscover stuff Rails has been doing for a long time, was kind of a part of the reaction to that.

And then you had a post, a tweet, which today would have been toot, but it was a tweet at the time, which caught my eye. You said, “I’ve been so productive since getting up to speed on Turbo and Stimulus”, which are sub-components of a modern Rail stack, “plus Tailwind (in parentheses) in Rail 7 that I’m at serious risk of writing a “You might not need React” blog post. Hold me back, hold me back.” And I don’t know if you ever wrote that post, but I replied, I said “Sometimes just coming on a podcast and talking about it is even more fun”, right? Like, none of the pain of writing… Which led to this conversation.

So we’ve wanted to do kind of a Rails catch-up kind of an episode for a while, Adam and I have had, kind of in our list of things to do, and didn’t really see the opportunity… And then your comments - I was like “Okay, Justin’s obviously feeling things about productivity with Rails, with a modern Rails set up”, versus some of the stuff you’ve been doing otherwise; I guess React is the one named… So let’s talk about it. Let’s talk about where Rails is, let’s talk about what’s exciting and new, or what it’s good at, what it’s gotten better at, maybe where it still fails, and how that compares to some of the other offerings out there in modern web dev land. So that’s a whole lot of words… I will now stop talking and ask you to respond; maybe give a little bit of your most recent experience with what tools you’ve been using lately to build stuff inside of Test Double, or otherwise.

Yeah. Now, as a contrarian with a lot of opinions, I have an inclination very often when I’m asked a question to ask if I can answer a different question instead, to start… [laughs] Just to say, I would love to, if it’s okay–

As a longtime podcast host, I say no. You have to answer my question, as asked. No, I’m just kidding… [laughs]

He’s kidding, he’s kidding.

I’m kidding…

Can we can we back up and just sort of set the table a little bit? Because I’m sure everyone who’s listening to this is coming to this conversation with a different experience over the last X years… If you don’t know me, and you’re just meeting me now, hi. Hello. In the Ruby world, I was always sort of the outsider looking in for a long time. I helped start a Ruby meetup in like 2006, we had an event, I asked him hard questions about how Rails was working, and I was like “You know what, screw this”, and I went and worked in enterprise Java for a few years.

In my very first conference talk at RailsConf, the national Rails conference, in Chicago, I think the spring of 2014, it was a talk about why Rails was not meeting the moment of frontend JavaScript, and like single-page applications, and like rich user interfaces using JavaScript, and how you could marry the Lineman.js tool - which is incidentally what we talked about ten years ago - with Rails, to kind of almost bifurcate your system between a backend API and a frontend static site generator that you’d build your UI with.

And a couple years later, I think it was the day – you know, as I kind of became more enmeshed in Ruby land, I gave a keynote at RailsConf, and later that day on the exhibition floor me and DHH kind of just had it out in the open, like a 90-minute-long debate, and like a crowd was gathering. If you’ve ever seen the music video “Beat it”, it was kind of like that.

[laughs]

[22:00] But it was actually all in good fun, and it was a healthy debate about full-blown frontend, static, single-page applications versus what we used to call Rails views, like server-side-rendered HTML with JavaScript sprinkles on top, which was the pejorative way to put it. So just to be clear, I spent a lot of time on the other side of the fence here. The way in my mental model that I thought about the problem at the time, and that I think I still think about the problem, the throughline, is that in 2014 if I wanted to build an application with an interesting user interface, with drag and drop, or with simple actions, not requiring a full-blown page refresh, you could start any application… I viewed it like a chasm, like the size of the mountain that I could build of an application in terms of dynamism and user interactivity and that stuff was possible to do with just pure Rails. But at some point, if my product owner or somebody else were to say, “Hey, and I need an interactive map view for putting all of these work orders on it”, then at that point I would just groan, because now the JavaScript sprinkles would become too big… And I’d have a Backbone app at the time, or whatever it is… And it would create all this mess. And there’s no easy way to go from “I’m an application that’s like a server-side rendered HTML templates with a bunch of JavaScript sprinkles” to “Wave a magic wand and now I’m a fully-formed, robust backend API, plus logically-organized frontend user interface application.” And so there’s this chasm in the middle; it’s just so hard to jump from one to the other that my advice at the time was “If you think that there’s any chance at all that in the reasonable future, the next couple two, three years of development, that you might need that richer user interface, just let’s make it really easy on day one to separate the two activities, and just build APIs that talk to JavaScript frontends.”

All that to say, I think that what’s happened in the last few years is that first Phoenix and LiveView in the Elixir stack, and then in the Ruby world Rails and what they call Hotwire, which is really kind of a combination of a tool called Turbo, which does partial page refreshes and other kind of navigation tricks to make sites that are actually phoning home and getting fully-formed HTML from the server, but they’re doing it over a WebSocket and it all feels very fast, but me as a developer as far as I know I’m just designing the server-side templates just like I always was… And Stimulus, which is a very Rails-aware, if not literally aware; like, it’s definitely in on the gag of how to bind events and actions to small little tiny focused JavaScript functions and classes that themselves are arranged in a hierarchical way that mirrors the DOM.

So as I’m building out the DOM – I think David at some point said the DOM is kind of, in his mental model of an application, the single source of truth… Turbo respects that because you’re dealing with just sort of sub-fragments of the DOM, and Stimulus respects that because you’re binding to sub-fragments of the DOM. And just like React taught us, as long as you’re really rigorous about that approach to thinking about [the DOM], like, you’re just snipping this subtree and swapping in a new subtree, and letting the browser be efficient at repainting stuff… It moves the locus of control several notches further towards the server side, such that now when I think about this little tiny molehill of what I seven years ago was able to build with a Ruby on Rails application, now I can go way further. I can build – if you’ve seen the Hey email web client; it’s basically Gmail, in terms of its user interface. It’s got lots of goodies, it’s got a lot of very dynamic user interface features that we used to associate with single-page application development; like, this is the only way to do it. And now what I’m saying is that there is still a gap… If you’re building like an in-browser music player, with all sorts of like very app-like stuff, then yeah, you probably should be reaching for a single-page application framework to build a true frontend with an API backend. But if you’re building what most businesses are building, which is – not to be condescending about it, but like glorified CRUD apps with some cool components here and there, suddenly just pure Rails with Stimulus and very, very few JavaScript dependencies is actually really appealing and completely enough. That has been my experience over the last few months of working with the tools.

So when we compare, I guess, this Stimulus library… Let’s just focus in on that one, because I guess it’s kind of where you work inside of the DOM, right? Where you’re actually firing functions based on events and actions, and what have you… To me, conceptually, where I think React changed the game conceptually was the declarative nature of just defining what your component looks at the end of the day, and then giving it certain ways of changing to get to that place, and not worrying about anything else. That singular direction of mental model I think is why React – I think that’s why React took off. And you can respond to that as well. And I wonder how much Stimulus goes back to this feeling of like “Well, it’s better than Backbone, but you’re still kind of just hooking up event handlers to click actions and fire, and stuff”, which – I’ve built web apps that way, I’ve got no problem with it, but I know that as my web apps that I built that way get bigger and bigger, it gets more and more unwieldy. So maybe respond to the React paradigm versus this.

Yeah. Well, I mentioned one aspect when we were talking about shadow DOM all the time, when React was brand new, and stuff… The reason that I think React was successful where Ember wasn’t - for anyone listening, Ember was in a hot competition with React as like the thing to come after the 18 other frameworks that had preceded them - was that Ember really nailed bi-directional data binding, to make a better jQuery; like a sane approach to organizing applications that way… And where React agree– Totally agree– Shine was the unidirectionality of data flows from a source of truth, and it lands on the page, and it doesn’t go back from the page, and upstream again, right? I actually think that Stimulus and Turbo, when you work with them in concert, provides roughly the same effect. Because at the end of the day, if you look at React early days or now, the tricky bit is always state. When state changes, what happens, and who’s tracking all the state? And with Rails, and with the DOM, the answer is anytime state materially changes for anything that isn’t totally ephemera, the answer is “You phone home and you get new HTML from the server over a WebSocket, ad the model that the controller is dealing with represents the new state.” And so it is unidirectional much in the same way, and it’s also declarative in the same way, in that all of the Stimulus binding stuff is not happening manually, it’s through data attributes that you’re decorating onto the HTML, as you normally would…

And so what the Stimulus is really doing is strictly just saying, “What do I kick off when somebody clicks on this?” Or “When I have a data attribute that has a particular value associated with it, when that value changes somewhere, how do I react to that?” And you can totally still write the sort of simple click handler, kinda like holding a lot of state in your head in the frontend browser, style the code, but if you spend the time to kind of shift your mindset a little bit, and think in that unidirectional way, like if your brain’s already been reprogrammed to think that way about React, then I would just replace kind of the top node of your React application with locating that in the server-side router, and it’s gonna go to the controller, and then it’s gonna go render the markup… And maybe it’s only rendering a single little tiny div, but because of the optimizations that the framework takes care of for you, that’s going to be done performatively, because it’s going to happen over a live WebSocket connection.

That makes sense to me. I think we have an allergic reaction as an industry to HTML over the wire; like, there’s like something where it’s like that’s not pure…

It feels impure.

[32:02] Yeah. Is there something – is there more to it, or is it just like there’s a purity…? I know as developers we get idealistic; we have a purism that we desire. And then there’s pragmatism, and we try to find somewhere in the middle where we can be productive. Is there more to it? Like, are there valid reasons why sending HTML over the wire is a bad idea? Or is it just because it’s not a Data Interchange Format? Or I don’t know. What do you think?

I am always – so I should put on the table first that, as a developer, I have just a real strong streak of believing that there is one true righteous answer to every problem. And I have to temper that a lot. Because what I’ve learned through nurture, I suppose, over the course of my career, is that just like there’s infinitely many bad ways to do something in software, there’s also infinitely many right answers… And a lot of the times the perfect right answer of pure functions, and unidirectional data flows, and like proper interchange formats that adhere to some kind of protocol, or fit into some gigantic architecture such that… Any two services in our enterprise could theoretically talk together, even though they all flow in just this one kind of tree-shaped direction, just like everyone else’s services do. When you give into thinking that that is going to be the solution to the problem of “Boy, software is hard. It’s hard to manage a bunch of complexity and get everyone to agree about what this thing should do”, then I worry sometimes about… You said allergic reaction; I think that’s the right answer. I worry about the allergic reaction that develops of an impure solution that maybe is good enough, and maybe is way faster to implement, and actually doesn’t have a practical reason to be bad, other than it feels bad, and it doesn’t suit my fancy of being mathematically provable as correct. I had the same initial revulsion; I spent a long time before getting serious about trying Turbo and Stimulus. I let it simmer for a couple of years before I really tried it in anger this summer… And the truth is, just like Rails itself was the pragmatic thing that was willing to say, “You know what - all this stuff that your DBAs do with your databases, and all the fancy keys and referential integrity - it kind of doesn’t matter; just treat the database like a hash and figure out the rest later.” That was the thing that ejected me from the Rails community when I was much younger. And here, it’s the same sort of thing, where in fact that HTML over the wire thing, if you’re actually using the framework and trusting it, once you get going, it’s an implementation detail. I think I messed up and called it something else a couple of times to even remember that it’s actually a WebSocket connection that is actually pushing HTML over a pipe, because you just don’t think about it, because it sort of just works.

Right. So here’s a response to that. So I had this conversation, a similar conversation, with Tom Preston-Werner on JS Party, talking about Redwood, which is GraphQL and SPAs. Well, okay, it’s more complicated than that, but… Let’s just say he believes in a strong API layer, let’s just say that. And his response to me when I said kind of “HTML over the wire, can’t we just do it the traditional way? We have tools to get over a lot of humps…” Obviously, there’s times where you might need something else… But he said, “It’s all well and good, until you have multiple clients. And once you have multiple clients…” For instance, we know we’re going to have an iOS app, we’re going to have a website, and we might have a command line tool, etc. Now you’re kind of stuck if you went this direction. Whereas if you went the other direction, with a GraphQL API, for instance, and multiple clients, you’re at least set up for that very possible reality for many people. Do you find that’s the case? Is there a time where it’s like – I think there’s a lot of businesses that think immediately…

[36:04] I tend to get on the YAGNI side of this argument. I’m not sure where you land, but I feel like there’s a lot of businesses that, you know, they do get some success, and then they do want to go in these other directions, and then they’re like “Well, do we rewrite a whole new thing? Do we have to go back and re-architect our backend? Do we bolt on a RESTful Rails API?”, which in my experience has never been as easy as the sales pitch for Rails’ APIs… So yeah, his response to that was “Multiclient breaks that argument.” What do you think about that?

I think there’s a couple worthwhile reactions. One is, when we say multiclient, we’re mostly talking about phone apps. And the industry has changed quite a lot since the app stores were new, where to build any application at all would have required not only an API talking to native Objective-C code, or Java, and Android land… But it would have to really sip the data, because the computing constraints were so narrow. And now we’re in this other world where, if anything, with tools like React Native, and with the advent of much more mature UI frameworks for those different clients, I’m not as concerned as I used to be about that exact question. It was something I worried a lot about in 2014, when I was thinking about when you need an iPhone app, because everyone was like building those, and now what it is is “Oh, it turns out that we can actually run pretty far afield with just responsive web design and a mobile website.” And if you need an application – nowadays when I talk to clients or prospective clients for Test Double, it’s almost always not that “I need my entire gigantic website of 800 controllers and every single thing that you could possibly do through the web”, it’s “I have a very specific use case, where these people who are doing site inspections need to check for these particular things, and they need to be able to scan barcodes really quickly, and they need to be able to do this or that.” And so the scope of functionality that’s needed by mobile applications tends to be much narrower, and it tends to come much later in the lifecycle of applications than it did 10 years ago.

And you asked me a bit ago, like “I seem to be coding a lot. why is that?” One big reason is I’m not a believer in progress. I’m not a believer that this industry is getting better over time, and like innovation is happening… Because when you’re outside tech, everyone’s like “Oh, look, we’re getting smarter and hotter all the time. And all these new technologies are coming out. It’s great!” I honestly feel like in many ways the industry has regressed since I’ve joined it. And it’s worth thinking about, when we ask questions like this one, of - that may be what Tom shared is completely conceptually true, but I think the industry has changed where now the likelihood that you’re going to need to build both a web client and two native mobile applications, and maybe some third client, on day one, or near day one, with full-fledged functionality - even as I say that, I struggle to even think of like how often I’ve seen that in recent years.

And so I would instead say - if somebody had that consternation or that frustration, I would say, “Well, if you’ve got a small team, and they’re careful, and they’re experts…” For example, when I do a Rails application in this way, the controller is kind of the controller, in terms of my search feature is going to take a query string from users, and then it’s going to go and figure out what are the results, and then it’s going to call stuff that does all that hard work for me, and then the last little line is just going to like render a template from that piece of data… And I could just as easily respond to a JSON format, or header, and just convert that to JSON and have like a quick presenter just do that. And in well-factored Rails applications - well, yes, building the whole separate API as a bunch of separate endpoints really never works, because you end up with two code paths doing the same thing…

[40:10] If you’re really careful about being rigorous in how we structure the data that flows into the templates, that data - the controller and the route is asking the same question. The inputs are the same arguments, that might modify the answer… And then the answer is factored in a way that’s like - it’s the same answer, it’s just different shapes to present it to the client.

So I’ve had really good luck of doing exactly what you’ve struggled with, and I’ve seen a lot of teams struggle with, of just “Okay, cool, well this particular set of routes needs an API response now, so be able to respond to JSON requests, as well as to web requests.” In fact Turbo, which I’ve been talking about, has a Turbo stream feature, where those action cable little partial page snippets are also just another kind of request, right? It just goes through the same templating, it’s just that it knows it’s only a document fragment, instead of the whole document.

So that’s, I think, more functional than going out whole hog on day one and saying “You know what - we just need a full­-fledged API.” It’s just like saying “We need microservices on day one”, or something like that, “because we’re afraid that in the future we’re gonna have more complexity.”

Sure, sure. Yeah, in my experience - and I don’t have that much; I probably have like two or three go-arounds on that - it’s that what happens with the “Well, we can just take this controller action and we can render it to JSON with a slightly different presenter and all is well” is that it seems like the phone client or whatever the second client is ends up needing at any particular endpoint dramatically different representations of the data in order to do its job, that it feels like “Well, I’m just basically building two.” So I can’t actually just say “.json” and roll. I have to create an endpoint for this, because the shape of the data is way different than the matching webpage. So that that was my experience, but…

And you’re making the point for me that it’s easy to talk on a podcast about everyone’s experiences, and then stake a claim that “I’ve got this figured out”, but the truth is, I am very confident if Jerod and I were to sit down and try to solve a problem and spend a few weeks on something, that by the end of that few weeks we’d have something working, and there’d be zero surprises, and we’d both feel good about it. So there are cases where that’s 100% true, and vice-versa. It really depends on the context.

Yeah. This feeling that you have, of not progression, but regression instead - where does that come from? How does it manifest in actuality?

Yeah, examples. Give us examples.

Yeah, so I think of it in terms of like a sine wave, sort of, is like how the industry – it might get better overall over time, but we go through these cyclic patterns. And when you’ve been through a few of them, it’s hard not to see them. And when you’ve come out the other end of a few of them, it’s hard not to become a little bit jaded about it, because it sort of feels like we’re not going anywhere, like we’re just walking in circles.

I’m not there yet. I’m not jaded, and I’m not cynical about the industry. An example - when I was coming out of college, and I was working in big enterprise Java stuff, there was a lot of J2EE, Java 2 Enterprise Edition, which I think they kept calling J2EE until Java 5 came out… It was such a complex, burdensome, multi-person… Everything about it was this assumption that you’re going to need 18 layers of striation to do a Hello World, to build the most basic application. And the answer to the question, “Why do we need this?” is, well, someday, when you’re a big application, you’re gonna need to be able to do that. Or if you’re like IBM, or BEA, or Oracle, who are selling these things, the answer was, “Well, our proprietary Java application server has some feature like hot swapping the application in production without having to restart any servers, or something, and in order to do that, it has to be packaged in a certain way. And at really high scale, you just need that, and so that’s why we have these architectural decisions. And I pushed back against that.

[44:08] How I got into JavaScript frontend development was I was working in those environments, and I was like “Nope, I need to move a lot faster.” And so I was building full-blown applications in JavaScript, and just like sipping data however I could, to get the user interface the way that the customer needed. And I think that that spirit of an eclectic set of small tools solving very specific problems of the JavaScript open source world, as much as people look back and see all this churn as we moved from framework to framework and tool to tool, there was a certain pragmatism about “Look at all this stuff that I can solve, and bypass the really silly, complex machinations of my enterprise, because they just literally don’t care about what happens in the frontend, because it doesn’t matter.”

But when I say like there’s cycles, like – I get my years mixed up, because it’s bleeding together a little bit… But once React became dominant, and once you started seeing Amazon and Google, in addition to Facebook, really start to push open source, like their favorite open source tools, through paying developer evangelists to kind of like just press the flesh at conferences around the world, and convince everybody that no matter what scale you are, the answer is Kubernetes… Or our favorite tool for just coincidentally plugging into our cloud computing platform, right? So that’s why we want you to go serverless, on our servers. So there was a sort of enterprisification of open source that occurred by just marketing really heavily towards the same impulses that you’re expressing. Like “Well, I might need it someday, and I don’t want to throw all this out. So if it works well for Facebook, using Create React App and pulling in at a given point in time hundreds of small dependencies, then surely that’s good enough for me, or that’s like enough for me”, without thought of “Well, Facebook has a much larger group of people pouring over those dependencies, and keeping them updated.”

The complexity that you see now in frontend applications looks more to me like the average frontend application. Of course, you can write really lean ones. I strive to, with very minimal dependencies. But the average one, the average team, they just have this – it’s a disposition and a temperament towards looking to an authority, and pulling in tools, external tools wherever possible to solve problems, and the people who are kind of the loudest voices in that community are trying to solve problems at Facebook scale, Google scale, Amazon scale, and if you’re just some startup, it is YAGNI. You’re not going to need a lot of that stuff. Definitely not now, maybe not ever. But you’re either way saddling yourself with that level of complexity.

Yeah. I’ve heard of progress described – we think of it as maybe a ladder, or some sort of vertical ascent, right? Maybe it’s rocky, or whatever; you’re going up a mountain. But I’ve heard it described, and it kind of matches your description to a certain extent, more as a helix, where you’re actually like circling something. And you’re slowly like going upward, as the helix does make progress, but it’s way slower than you think it is. As you’re just right there, you think you’re going up this mountain. And you end up doing a lot of that same stuff over and over again, and maybe revisit the same concepts, but now it’s five years later, and there’s different tools and different capabilities, and so it’s a little bit better than it was last time we were here, but here we are again.

I’ve also been in this industry for a long time now, and I’ve seen a lot of things a) come and go, but also come, and then go, and then come again. And a lot of excitement about stuff that isn’t new ideas, it’s just newly discovered, same ideas. And so that can get –

For the next generation. Right?

Yeah.

[47:52] So many developers enter the industry every year, and so many leave, that like we basically replace ourselves every three years. So it’s no wonder that some hot take, some smart wisdom that I had a few years ago - no one’s even heard it, because so many people come into this industry that I think we have to relearn a lot of lessons, regardless.

I love the spiral staircase idea. I think that there’s a lot of truth in it. But for anyone listening to this conversation, at best I can offer up this sort of like amateurish prognostication about like what I’ve seen the industry doing… But how I bring it home, and how I make it relevant in my existence as a developer who’s moving through it is I think about that helix, I think about that cyclic nature of gradual improvement through my own practice of each app I build, each thing I do, each time I solve a particular kind of problem, there’s a new opportunity for me to do it just a little bit better, and to like learn from last time. And the more cognizant I am of that, and the more careful I am about thinking about how I think about things, the firmer footing and the more steady progress I have to actually get better each time. And that’s something that if you can achieve that for yourself as an individual, and as somebody who consumes and lives in like the kind of information ecosystem that we all do as developers, I think that you also develop a reflex to know what you’re looking at when some new, splashy landing page of some new open source tool that’s going to save us all - when that lands, you’ll be able to read that and look at the different heuristics to tell you whether it’s still going to be around in a year, and whether it’s going to actually make your situation better, or just be the 17th tool in your stack.

One of the founding principles of this podcast has been to be not the Ruby Show, not the JavaScript show, not the Kubernetes show, not our services show - you know, you-pick-your-buzzword-and-throw-it­-in-there show… It’s been the show to look over the fence at all the cool things happening throughout the industry, throughout software, and see how they apply pretty much anywhere. And I wonder if we’re in this “chasing cool” issue; I don’t know what to call it necessarily.

There’s a lot of cool things happening in the JavaScript world, but there’s a lot of really sturdy, stable, capable things in the Ruby world. And I wonder if – I thought maybe part of your answer would have been the chasing cool. People are so focused on chasing cool and iterating that they forget to look at what’s really stable, say - not just in the Ruby world, but elsewhere… That they keep rechurning and recreating, only to come back to where we’ve been. But it’s not JavaScript, it’s Ruby, so it’s not cool.

You raise a really good point, and I think of this often in terms of lifecycles of like language ecosystems, or tool ecosystems, where the temperament and the disposition of an early adopter - none of these trails have been blazed, maybe I have to produce a lot of open source on my own just to get the very basic stuff done… Versus somebody very late in the process, who might be like “Well, there’s no such thing as greenfield development of Perl CRUD apps anymore, so every new project that I get, I actually love it, because it’s a chance for me to treat each project as a puzzle box, to kind of like crack the nut and figure out how do I continue to make forward progress in this world of a stagnant ecosystem.” Sorry to any Perl enthusiasts.

It’s something that I think about in those terms probably a little bit more, because we all, I think, will mature over the course of our careers, and just go through different modes of - sometimes I’m really excitable about a new technology, and it’s splashy, and it’s fun, and it totally unlocks something for me, and other times I’m just trying to get something done.

[51:48] So if you want to categorize it into two buckets, I think that we have technologists who are really in the game; they’re just here for the music. They want to be on the cutting edge, and see the next thing, and be there. And what I have strived to do – when I think of the best moments I’ve had in my career, it’s actually not thinking of the technology as an ends, but as a means to doing something else; to helping people, to sitting with a product owner who wants to solve a problem with software… And I just take that bevy of technology experience and I figure out, if it’s a business, “How do I make or save that business money through deploying the software well?”, where if you start thinking about technology as a means as opposed to an end, then of course, the pragmatic solutions are going to rise to the top, because you’re not there to waste their time or yours to solve the problem. And that’s where I try to spend more and more of my time, is “Where can I help bridge that gap where I’m both engaging with new technology, innovation, ways to think?” …not fall into that sort of cynical, stodgy old man yells at cloud persona that I sometimes play on mastodon.cloud. Or social. Mastodon.social. Oh man, I should probably know the main name of where I toot…

Oh, he doesn’t even know his instance. Come on…! We’ve got a Mastodon newb over here…

Well, the big one.

The big one.

Yeah… You can find me at justin.searls.co. That is a URL that will exist for a while, and it links to all of my – whatever my Mastodon is. I’ll figure that out, eventually. I’m kind of curious if that, Adam, is - does that resonate with you, based on where you were when you were asking that question?

Yeah, well, kind of grokking what I think the undercurrent of your tweet might be even, which was maybe you are not paying attention to – and I think you said you use Turbo and Stimulus out of anger even; less with blinders. So maybe your lack of usage and desire to steep deeply in it and determine whether or not it would work for you in the kind of applications you build and the style you build them, I wonder if there’s a part of the world that just simply has blinders on, because it’s not JavaScript. They won’t look at the other side of the fence to say, “Okay, well, I could use that, or that is actually really productive”, because it’s only JavaScript; or because it’s Ruby, and that isn’t cool anymore.

That’s kind of – to some degree, the world has said that Ruby isn’t cool anymore, even though it’s highly capable, very stable, etc. I wonder if that’s part of your undercurrent there. Because you said you’re almost serious about writing “You may not need React.” So it’s almost as if – you kind of played a double part there, where you did it out of anger, then you steeped yourself in it, and you found it was pretty productive etc. I wonder if there’s a population in the world out there that just doesn’t look at it at all because of blinders.

A Ruby hero of mine is the late Jim Wyrick… And he used to say that you don’t really know a technology until you’ve used it in anger. And when I say I use something in anger, what I mean is I’m the dog who caught the car, and I’m holding on to that bumper for dear life, and I’m going to build this thing, dammit, one way or another. And so I’m going to go through the hard parts, and I’m going to come out the other end, and then I will have an honest appraisal of whether or not other people should use it, too. Because it’s the only way to really know, I think, whether the tool is going to work.

And to the point about JavaScript - it’s interesting, because JavaScript has been the trendy thing for so long, and it’s more of an ecosystem than a community, because everyone needs it. It’s the lingua franca of the web, that you can spend your entire career there, and you could get lost for years and years and years in just JavaScript land, and keep yourself completely busy and have a wonderful time and career. But I’m fortunate, looking back, on just how much both like boutique languages, as well as just competition among primary languages there was when I was coming of age as a programmer… Because the first language I really felt like I got and understood deeply was Java. And when I understood Java, I identified as “I’m a Java developer, and I want to find every solution I can in Java.”

[56:13] But then once I cracked the nut on a second language, and then a third, then I was able to relax that a little bit, and think more in terms of “What is the stack getting me? How do I feel? What kind of teams are successful or not successful with a particular technology?” And I would wish that for anybody. So even if you spend a lot of time in JavaScript land, trying to solve something in a radically different technology stack is just good life experience, because it frees your mind, it liberates you from thinking that every solution has got to be JavaScript. Because frankly, you mentioned Ruby not being cool anymore - like, we joke about this sometimes internally at my company; we had a period of like tons and tons of Node.js and server-side rendered React projects come through in 2016 to 2018, but then they started to trickle off. And then we had a bunch of really, really massive companies invest in renovating their Rails apps, because they tried either building a whole bunch of microservices, and breaking up their monolith, or they tried rewriting their entire interface in like frontend React, and they saw how much extra work that was. Then I think Jerod used the phrase “batteries included” earlier, and they’re like - you know, it was actually much cheaper for us to upgrade from Rails 3 to Rails 7, and get up to speed…

That’s a jump…

It is. Well, and actually, Test Double has done a lot of upgrade projects, and we’ve got like a whole knowledge base of –

That’s four versions in the middle there, Justin. I mean, that’s a big jump.

Yeah, of how to do that, and you can check our blog for some advice… But today we’re at the point where there’s probably more Ruby developers getting paid to write Ruby on Rails applications that at any point ever. But we show up on Hacker News less and less, because it’s like a lot of this stuff’s been solved, and it’s just less noisy, and it’s less public. But it’s still making a lot of people a lot of money, I think.

It’s an interesting time too, because there’s a lot of layoffs, there’s a lot of – I saw this one thing where somebody had… I’ll paraphrase their scenario, because it’s not necessary for the conversation here… But they wanted to now take their new focus, because their focus has changed, and focus on founders and mental health. And the reason why was because there’s gonna be a lot more founders out there because of all the layoffs and all the change in the job market… And actually, there’s the people who don’t want to go and work at these big companies anymore because of whatever the reasons are. I just wonder if there’s some sort of gem, let’s say, inside the Ruby world, that is not visible to folks, because they just haven’t – because of the label; it’s not cool anymore, even though I still think it’s cool. I wonder if that’s just taking people away from this [unintelligible 00:58:42.05] and that kind of thing, where - hey, if you’re in that space, or whatever, maybe, maybe just go out there and build a Rails project as a hobby project, and realize what’s still there. I wonder if this might be a good time for that.

I think layoffs are always concerning, even just talk about them… Like, if you look at all these press releases about layoffs, the vast majority aren’t pointing to actual economic conditions, or business constraints… It’s like, worry about what people are talking –

It’s FUD.

Yeah. Investor sentiment is what’s driving a lot of it. But we’re not immune as individuals, because we’re either affected by those layoffs, or we think about, you know, like, me as a developer, am I going to be affected or impacted? Or if I am, will I be able to find something? And what I can tell you as a consultant who has seen several cycles, and come in at company – generally when we’re helping companies, it’s a really interesting time for the company; good or bad. That’s why they’re bringing in outside help. And the one thing that I guarantee for you as a professional that’s going to be recession-proof is an ability to solve people’s problems that generate more value than your cost. And pragmatic tools are the name of the game in being able to demonstrate that repeatedly, and to have a big impact, and to leave a good taste in people’s mouth when they work with you.

[01:00:10.01] And so if you have sort of this mathematical purity approach to technology, or if you have an arm’s length, sort of like – if you’re in an organization right now where you can’t explain how the thing that you do makes or saves the company money, somebody else is probably also struggling to answer that question, and maybe you’re right to be concerned. But if you want to be able to independently, full-stack, just build stuff that’s just sweet, and rocks, and does cool stuff, that is what I think the Ruby in Rails community has been. That has been our purity of line as we’ve focused on the tools that we build and use; how do we make it as productive as possible for solving problems with technology, so that an individual, much less a small team, can run circles around much larger organizations? And that’s always been true; it just became less in en vogue, I think, over time, as the venture-backed startup world started agglomerating into larger and larger organizations. Human organizations started demanding I think a lot of the cloud services, DevOps and complexity that now occupy a lot of our brain space when we talk about technology.

So on the lines of Rails again, and individual productivity, and progress, even if it’s a helix, what is Rails’ current story when it comes to loading your JavaScripts, your assets…? I’m from the day – so I’ve been using Phoenix myself for the last few years on Changelog.com, which is really the only app that we work on. I’m no longer a consultant like you, which I was for many years; I just have like our app, and I work on it, and that’s the one. So I don’t have this experience. But back when I was using Rails for multiple people’s web apps, it was Rails asset pipeline days; like, that was what I used. And there was like – npm was blowing up, and it wasn’t the greatest way of doing things; it was slow and error prone. And I’m curious what the story is now with just like loading stuff. How does it work?

Yeah. Well, the answer is - if you’re coming into an existing application, whatever you used to be doing probably still works fine. All of these tools are still supported. But if you’re running Rails new today, the golden path is one of the two following. First is, if you’re targeting modern browsers that support import map, out of the box no bundling happens; you just create a manifest and say, “Hey, these are my dependencies. These are the version pins. Browsers, pull them in and cache them.” And then now I’ve got Lodash, or now I’ve got whatever it is. And if you use tools that will work correctly when imported via and import map in a browser, then you’re off to the races. I couldn’t dream of something like that. I guess I could dream or something like that; it was called Require.js and it didn’t really work super-good. But now it’s something that is standards-based, and it doesn’t require a custom Ruby gem solution for wrapping every single dependency, like we might have seen when Bauer was the thing before npm.

The second path that you might take - and this is the one that I’ve taken, because it only takes about 15 minutes for the first path to go sideways in practice - is there are new first-class gems that Rails new will bundle if you say the right incantations on your command line. And if you get confused about that, toot at me and I’ll try to help you, because it can be a little bit confusing if you’re new. I think it’s called Rails CSS bundling, and Rails JS bundling, or something similar. The CSS bundling and the JS bundling I think is all driven by ESBuild. There’s also a Tailwind-specific mode, that will incorporate the Tailwind CLI and Tailwind configuration…

So ultimately, what gets built – now, I skipped over in the story, because you mentioned the asset pipeline, which was like run by a gem called Sprockets… The bad years were when Sprockets was kind of falling over and couldn’t really support npm stuff, and then Webpacker was Railsy way to do it, and you ended up with 15 different configuration files that said the same thing… And it truly was a mess. But now, ESBuild is so great. It’s so fast, it’s no-nonsense, it’s set it and forget it; you don’t really have to do any configuration. Rails handles all that for you.

[01:04:23.15] I’ve been working on this project for a few months now… I’ve done two or three now with this tool. If I’m deploying to Heroku and I don’t have any sort of complicated infrastructure needs, once I have a Hello World, I haven’t thought about this question at all.

Nice. Well, that’s the best story, right? The invisible story is the best one.

In fact, even in giving that answer, I am very worried that I made several factual errors, because I’m explaining a thing that I saw in a read me in June… Because I don’t know, because I don’t need to know. And you’re right, that’s the best kind.

We’ll give you the benefit of the doubt. Well, that’s a great answer, because it was so painful for so many years, and especially during the transitions, like you said, where we’re kind of like in this new Webpack world, but we’re still in the Sprockets world… And the transition was heavy. That’s why those upgrades - you probably have some like serious intellectual property in your upgrade runbooks there at Test Double. Like, here’s how we upgrade; those were moneymakers, for sure. It was painful for that. So that’s excellent.

The other thing that I don’t know about, because like I said, I haven’t been in the Ruby world - I’ll echo Adam, I still love Ruby, I still use it all the time… Anytime I write any sort of script on my computer that has to take an argument and do its thing and shell out… I don’t even go for Bash, I go straight to Ruby, pretty much, because I love it that much. But I haven’t used it in modern web stuff for probably five or six years. I know that Ruby 3 was supposed to be like three times faster. That was like the marketing deal. Ruby 3x, or something. I know Ruby 3 is out. I’m curious about advancements in the language itself, or changes that have happened of late. Have you read a readme back in June that told you the answer to this one?

Yeah, yeah… You know, it’s great. So if you’re listening this conversation and you’re not a Ruby person, and you’re like “Why do these three schmucks talk about why they have this nostalgic almost, or this affectation towards this Ruby language?”, when you might not see that or understand it… One thing that Matz, the creator of Ruby, and DHH, the creator of Rails have in common is that they’re both optimizing towards programmer happiness. So if you are a developer, and you’re interested in being happy, you should check out Ruby… Because that is, I think, the North Star for a lot of decisions in the language, as well as in the frameworks and tools that we use. Because we always want to be productive, we want stuff out of our way, we want to be able to express ourselves in a minimal, terse way, and just have the computer do the work for us. And it’s easy to say that, but you see 1,000 points of light that you can point to if you’re going through a codebase of like “Here’s an example of a config file I didn’t have to write, or a method where I didn’t have to copy-paste the same basic thing five times to satisfy some framework underneath me, all the syntax that I didn’t have to sprinkle in to make something compile correctly…”

And when you look at Ruby as a language, what’s maybe most interesting to me is that the experience of trendiness, of popularity, of how much people talk about Ruby has waned in the West. We talk about it less, the conferences have, I think, fewer people going to them. It has fewer committers from the West than it did… But I’m a student of Japanese language and Japanese culture, and I’ve lived in Japan several times in my life, and I’m friends with a lot of the – and Matz is a Japanese person… I’m friends with a lot of the Japanese Ruby community members, as well as committers and maintainers of Ruby overseas… And if you go to RubyKaigi, their kind of national event, every year the crowds are bigger and bigger.

[01:07:58.28] It’s a professional event, people take Ruby really seriously, they’re really excited about Ruby as a language, they have a whole onstage discussion of all of the committers, like a Q&A session… And the committers are big enough to field an orchestra. Like, it is so many people who show up on stage, excited about -0 here’s an example. In Ruby 2.7 we used to have this way of parsing the syntax of a Ruby file listing called Ripper, that was very fast, but the API would produce sort of this like gobbledygook that you had to write a custom parser of the parser’s output to try to figure out “Well, here’s a method definition, and here’s a parameter.” In Ruby 2.7 they released an abstract syntax tree module that allows anyone who’s writing Ruby to reflect on the Ruby and introspect the structure of the file listing and then dynamically play with that, or build other interesting developer tools based on the awareness of what’s the code actually do, and what’s the structure.

Another example is the IRB terminal repl that you get with Ruby… And in any dynamic language, I think repls - if you’re not familiar with the acronym, it’s Read Eval Print Loop. You type a little something, you hit Enter, you see what it does, and then it asks you for more input. Working with the repl is a really rapid way to get feedback from your system. I think the longer that I’m programming, the more that I think programming is really just a conversation that I’m having with my computer, and anything I can do to ask my question faster, and get a faster answer from the computer, and then think whatever thoughts I need to ask the next question - that feedback loop is the most important thing to any developer’s improvement and productivity.

So the repl has been massively improved, both in performance, as well as in features. Now you have a lot of introspectability available to you inside of the repl. It’s easy to pull one up at any given code point. It’s got much nicer autocomplete, it’s visually just a much more, I think, pleasant place to be, to help you understand “Where am I? And what’s this code doing? And how is it behaving?” So the repl is another great example.

Another one is - there used to be a debugger that was kind of modeled after GDB, the GNU Debugger, which you might be familiar with if you’ve written C or C++; it was called RDB. And it was not – not to demean anybody who might have worked on it, but it was roughly forgotten about entirely for like a period of 15-20 years. Like, when I was coming of age in Ruby land, people would tell me “Oh, yeah, we just don’t debug.”

Aaron Patterson, I think one of his most famous blog posts is “I’m a puts debugger.” Like, he doesn’t use the debugger, he just prints out statements, because it’s literally more pleasant and a faster feedback loop than trying to fight with a step debugger in Ruby.

Shibata-san - his handle is @hsbt - took it upon himself. Oh, shoot… Did I give Shibata-san credit? It was either Shibata-san or [unintelligible 01:10:51.00] One of them came in - there’s going to be a link, or something - and totally rewrote the Ruby debugger library, and made a gem of it. And so now it can interact with, just like Node can with a Node Inspect - it can interact with any kind of debugging user interface, whether that’s VS Code, your IDE of choice, or a remote terminal session that connects to something that’s listening on the other end. And it’s a first-class, great debugger, and I’ve got a YouTube video of how to set that up in VS Code. I’ve had a really terrific experience with that. It makes Ruby feel fresh and modern.

And those are a few examples. Ruby itself is indeed a lot faster, it is quite mature, they’re adding new stuff all the time. And something that I hope to be doing more of in the future is to start unearthing more of the kind of new features that come out every year. Ruby has an annual release cycle on Christmas, of all days. So Ruby 3.2, I think, is next - I’m always playing with preview versions, and stuff - and comes out on Christmas… Which is really fun if you maintain a bunch of gems, by the way, because then on December 26th you get a whole bunch of free GitHub issues from helpful people on the internet…

[01:12:06.00] Well, they’re gifts. Consider them gifts.

Yeah, they are. Yeah, it’s Boxing Day. So all that to say each new version of Ruby does contain so much new stuff, but because a lot of the contributors are in Japan, speak Japanese, and may not be writing blog posts that get traction in the US, I would like to see myself and other people in the Ruby community do a better job of just surfacing some of the cool stuff that’s happening… Because I don’t think we’ve done a good enough job of really highlighting Ruby’s advancements in the last few years. So just take my word for it, please.

What could bring that back, though? I mean, you said it’s waning here in the West; not so much in the Far East. In fact, it’s thriving, as you said. RubyKaigi is just killing it, basically. Growing, and maturing, and innovating, all the -ings… What can we do to – what are some pragmatic ways we can actually stop that waning here in the West? I mean, is it simply a chasing cool issue, where you feel like the en vogue thing to do is to basically just not like at Ruby, look at anything else, I suppose?

Well, once you’ve been up or down the helix staircase of progress a few times, I think that you become comfortable with associating yourself or with working with tools that aren’t necessarily the trendiest thing. And the answer to the question of “How do we reignite enthusiasm for Ruby in the West?” is first to just recognize that it is a stronger tool than ever, and more people are using it than ever. Now, it’s true that if you build it, people won’t come; they have to hear about it, they have to learn about it. And that’s why I think the call to action right now is just celebrate the cool stuff that it does, and talk about it. That’s why I’m here today. It’s exciting stuff to talk about, because it’s really fun to use, and it’s really productive, and I want more developers to have that kind of experience. And because the fundamental tools, both recent innovations in Ruby, as well as the current formulation of like what you get when you type rails new, if you’re writing a Ruby on Rails application - it’s just so strong that I think that that will serve as a testament for anyone who tries it. People are going to touch that flame, and they’re going to get excited about it, and they’re going to share it via word of mouth, and hopefully it’ll be just like it has been on other moments of Rails ascendancy, or anything else. People won’t be able to shut up about the productive time that they’re having.

Well, it’s been fun talking about this journey with you, and catching up. I mean, it’s just been too long, honestly. We’ve gotta get you back more frequently than every ten years. Maybe every one-and-a-half, maybe every –

Seven-and-a-half years…

16-and-a-half months, on the nose… I’m not sure…

Alright. I won’t take it personally.

Well, please don’t. Please don’t. Because we have mad respect for you, and enjoy when you come on the show. But we’re fans of Ruby, and I was actually thinking, as we asked you “How can we prevent the waning?”, I suppose… Like, Jared and I have great passion for Ruby; we use it whenever we reach for something… But when we have the only application we work on is Changelog.com, we’re not going to rewrite to Ruby because we want to see it thrive again. In fact – I mean, there’s a lot of things that we can compare with Phoenix and Ruby on Rails, and things like that, and see the differences… But we can’t really help that by building an application, because we’re not builders anymore. We’ve built one, and we’re gonna maintain it, and that’s it; keep improving it. So that’s an interesting aspect… Because I was thinking, how can we –

And to be clear, I would not want you to. So Test Double - we’ve got a lot of Elixir clients, we’ve got a ton of people in the company who don’t like Rails or Ruby, or they have moved on to Elixir and Phoenix, and they love it… I haven’t had the opportunity yet myself. But the moral of the story is, it’s great to get excited about new technology, but if you’ve got something that’s already solving a problem, and you’re having a good time, you shouldn’t feel bad because something else is suddenly cool.

Right.

[01:16:04.22] Well, I do have one bigger question, but I’m gonna save it for our Plus Plus members, because we’re at time, and I’m actually not sure how it’s gonna land. So you might see me get some egg on my face if you’re a Plus Plus member and you’re tuning into the after show… Or you might be like “Hey, let me become a Plus Plus member, so I can hear this.” It may not be worth it, we’ll see.

Or it might go so poorly that it’s not even there for Plus Plus people either.

Well, that’s the egg on the face. If it’s not there, that’s basically egg on my face, as you’ve said recently Jerod.

[laughs]

Justin, thanks, man. Thank you so much for coming on and sharing your passion for Ruby and the productivity it’s given you, and the road you’ve been on. I think that’s so true, when you said about giving that talk to look back a few months, or a year, or whatever it might have been, to say what can you offer. I want more people to do that. I think this is the kind of platform people get to do it on, which is a podcast… But I appreciate you sharing that here with us today, so thank you.

I appreciate that… And you know, at this moment in time we’re reliving and we’re kind of watching Twitter self-immolate. I am in a moment of reflection about just like recapturing some of what was magical about the web before all the web 2.0 companies sort of sucked all of my attention and creativity… So if you’re listening to this and you have things to share, I think there’s never been a better time to start a blog seriously. Even if it’s just a link blog, even if it’s just something little… You know, make a website, share your thoughts, and link to other people, and hopefully they’ll link to you… Because the best way – just like rubber-ducking through a hard problem and talking through the problem helps us solve it, the reason that these talks or these blog posts or the open source that I’ve written has been so impactful to me personally is not because I’m imagining somebody with this leather-bound collection set of the Justin Searls tomes or something, to serve as my legacy when I’m gone… It’s because doing that work of digesting and sharing and articulating what am I learning - that is where I get so much of, I think, the edification from this as a career, because it helps me understand and contextualize, “Who am I in this industry?” and “What am I doing?”

Well, I’m glad we have you out there as someone to emulate. So if you are planning to take Justin’s advice and you plan to emulate some of his learnings, and this process of putting it out there, so to speak, through a blog, or through toots, or tweets, or who the heck knows what’s coming next… We have an easy way, Jerod, right? Changelog.com/submit. That’s how you submit to Changelog News. Weekly newsletter, online, all week long… We’ll share your links. We want more blogs out there. We’re for the open web, we’re for RSS feeds. We’re pro RSS.

We record entire podcast episodes about RSS, in which we state emphatically what Justin just said. Please, start a blog, publish, own your domain… Notice he has Justin.Searls.co, and he can confidently say, unless the DNS system breaks down at some point, that that sucker is going to be there, regardless of what else happens.

That’s right.

So we definitely –

As long as that’s my name… And I am bummed now, because I actually spent on two different websites in the post-Elon Twitter purchase era, written custom Atom XML feeds by hand to perfectly curate your experience if you subscribe to blog.testdouble.com, or Justin.Searls.co. Those feeds are immaculate and readable, which was not true before.

Talk about using a technology in anger; there you go, handcrafting RSS.

Oh, man… Each one’s written by hand, by me. When your client goes, I’m there, with a pen and paper, and then I’m relying on transcription technology to deliver that.

[laughs] Beautiful. It’s a beautiful thing.

Nice. Well, Justin, thank you again. It’s been awesome.

Thanks, guys.