[00:00:00] Jemma Issroff: Live from Portland at rails comp 2020. We're recording a podcast panel crossover episode. I'm Gemma is off one of the co-hosts of the Ruby on rails podcast. I'll be moderating this panel. We have five podcasts represented here across eight panelists. We're going to go around to start and hear what all everyone is excited about.

For rails comp. First up, we have Brittany Martin from the Ruby on rails podcast. Brittany, what talker workshop are you most looking forward to? 

[00:00:29] Brittany Martin: I have to admit I'm going to go with a meta answer and it's going to be this panel, but also as well to make a switch track, which I ended up curating. We already saw Joel Hawksley gave a fantastic talk as well as David Hill.

And I'm just excited for that track to continue. 

[00:00:44] Jemma Issroff: Sounds great. Looking forward to hearing the rest. Next up, we have Robbie Russell of maintainable software podcast. 

[00:00:51] Robby Russell: Hello, I'm enjoying so far. The, uh, what does it talk to me like I'm five or I forgot the way it's titled, but yeah, the tracks there have been really great in terms of getting down to some of the basics and such.

And so. Kind of mandating most of my teams at, and those ones in particular, if they can do which ones have you been to so far? I just sat in the rails console one and I learned a few things that I didn't know about or I'd forgotten about like using jobs in rails console is pretty fun having sub-processes and there was one earlier on maintaining rails applications.

I really enjoyed that one. Next up 

[00:01:26] Jemma Issroff: Andrew Culver from framework friends. 

[00:01:28] Andrew Culver: Yeah. So for me, conferences are about people. And so I'm kind of notorious for hanging out in the hallway, track, all attend a few talks, but mostly like for the limited time that I'm here, I come in late. I leave real early. Cause I got kids that I got to get back to back home.

But for the time that I'm here, I just try to have as much face time with, you know, everybody like who's in the room right now. 

[00:01:50] Jemma Issroff: Nick swatter, Ruby on rails pod. 

[00:01:53] Andrew Culver: I'll do 

[00:01:53] Nick Schwaderer: two things. One, I like trails con for me, his bag. I'm just so hyped for it. I'll call out. Hi, joined the Ruby community in first week of March, 2014 and never been to rails comp.

I've like followed the content for eight. So it's such a treat to be here by will to honor your question, pick a specific thing. I'm excited to see the remote group began talking about a pocket while I won't spoil anything. I love our community, but seeing people not just carving out their niche, but like helping to grow more of things in the community to make it sustainable, to make it more welcoming and open to more people.

And so I'm absolutely, as you're saying, the UK buzzing to see, and I agree began, 

[00:02:31] Robby Russell: and there's a whole 

[00:02:32] Jemma Issroff: community content. Speaking of remote Ruby, Andrew Mason. 

[00:02:36] Andrew Mason: Yeah, what's up everybody. I was excited for Joel Hawksley's talk, which is great. Joel, again, Joe's in the audience for anyone listening. I'm excited for Schwan's talk because Schwab always gives amazing talks.

I'm always excited for Brittany's talk and Britney's not giving a talk this month. So that's why I'm excited to hear her 

[00:02:54] Jemma Issroff: here. Uh, next up 

[00:02:56] Andrew Culver: Jason. Tarryn's. 

[00:02:59] Nick Schwaderer: Hello? 

[00:03:01] Jason Charnes: Well, I feel like any answer I have now would just be cheating. I too very much like the hallway track and the people, I very much enjoy Joel sock.

Dave, Copeland's giving one. I'm really looking forward to the one I'm least looking forward to is the remote Ruby 

[00:03:13] Nick Schwaderer: talk. 

[00:03:15] Robby Russell: Oh. And 

[00:03:16] Jason Charnes: I'm excited that Aaron Francis is here so we can talk about Laravel this whole 

[00:03:18] Andrew Culver: time. 

[00:03:21] Jemma Issroff: Also have remote with me. We have Chris Oliver next. 

[00:03:24] Chris Oliver: I'm just so excited to like put faces to Twitter, avatars and discord and everything had conversations with so many people.

And then finally getting to meet them in person is the best. That's what I'm looking forward to the most. 

[00:03:37] Jemma Issroff: And we have Colleen Chandler from the software social 

[00:03:40] Colleen Schnettler: podcast. I am super excited about my workshop, which is coming up in 45 minutes, filling an advanced query builder with active record. And there's actually quite a few active record talks here this week.

So I'm super pumped for those. I'm really looking forward 

[00:03:56] Jemma Issroff: to it. So next question I have is why podcast, and maybe we can get into the community content track a little, or, or what's going on. 

[00:04:04] Brittany Martin: Yep, Brittany. So I love its ability to be a time capsule. And it's so cool to have a timeline of my own career, but it's even cooler to watch my co-hosts career.

Nick's first episode was September, 2018. He was a regular guest, and then he became official cohost in 2021. And then Gemma's first episode was in March, 2021 and then became a cohost also in 2021. And each have had like a really unique path to Shopify and establishing themselves more in the community.

And. I feel really grateful that I have an opportunity to talk 

to 

[00:04:36] Jemma Issroff: them regularly about it. We feel grateful for the same remote Ruby. I know you're doing a whole talk on podcasting. Do you want to give us a little preview? 

[00:04:46] Andrew Culver: All are they intrude? If the preview? 

[00:04:48] Andrew Mason: Yeah, I mean, I think podcasting is a great way to kind of reach a very large audience without as much overhead as producing videos.

So our talk is basically on how to start a podcast and it's tailored towards Ruby, but it's going to be about kind of our journey to starting one kind of the lessons that we've learned, because I've, at this point I've been on three. Jason. And Chris started remote Ravi men. Then I joined them later. So I think we have individually a lot to share with the community to help them not fall into the same traps that we did.

So that's our goal is to like help encourage people to start their own podcast and do it in a way that they can avoid some of the huge mistakes that we've made over the years. 

[00:05:29] Jemma Issroff: What are some of the mistakes? 

[00:05:31] Andrew Mason: It takes a team. In my opinion, to produce a great podcast from editors, from doing marketing, doing show notes, you know, there's so many aspects of it and having cohos.

And if you only have two co-hosts one person doesn't show up, what do you do then you skip a week. I think consistency is really important and it's kind of back to us about having a team. And when you don't have that team in place, it can really produce a lot of heartache and headache. And a lot of after hours work on the podcast, which is not the goal.

And it really detracts from the. Colleen, 

[00:06:02] Jemma Issroff: do you have a similar view on podcasting? So 

[00:06:05] Colleen Schnettler: one of the things I love about podcasting is this concept of luck, surface area. And it's this concept that the more visible you are, the more opportunities come your way. I'm a self-taught developer. And when I got into software, everyone's like, you should blog.

You should blog. I could not get into blogging. I just could not get into a good routine. I didn't like it. And then I started podcast. Random people on the internet, listen to the podcast and then people recognize you and then they know you. And I have found for me like professionally, first of all, I love it.

Cause I do a podcast with someone who I'm already friends with, but professionally like opportunities start coming your way as you become more visible. And I think it's a very low friction way to become more visible 

[00:06:53] Jemma Issroff: Andrew yet. Do you have similar thoughts? 

[00:06:54] Andrew Culver: Yeah. So for me. We were already having conversations.

So Aaron and I were already chatting. And so by just hitting record, they gave us this opportunity to kind of like share that. I kind of had a sense, like, yeah, people might find this interesting what you can't. If for anybody that's listening, there are so many podcasts. You have friends like Justin Jackson and like his whole life, his podcasts, because there's so many of them.

And so anybody that thinks that they have a unique take on something, if you're thinking about starting a podcast, start a podcast, just do it because what you can't know. Before you do it before you start publishing, before you start sharing your ideas is who's going to come out of the woodwork. And yeah, we got like feedback from people that we knew, but we also met tons of people that we've never heard of before that reach out and say like, Hey, I love that.

And people that come up to you at conferences and say, Hey, you know that conversation that you had, I really identified with that. That really captured something that I had been thinking about. And until you start publishing stuff, you can't know if that's going to happen. And it's so low friction, like unlike blogging, which it takes a ton of time.

We were already having the conversation. So you just hit record and you publish it. And then I think the other piece of it as well, which for folks who have guests on their podcast, it's amazing. To think that you can provide infrastructure for super smart people, people that are way smarter than me, you can get them on.

We had a guy say this to us recently where he didn't want to reach out to people and be like, Hey, can I come on your podcast? But he said, but reach out every six months because I might have something to say. And so the idea that you can get an audio. And then you can share with that audience, the incredible thinking of people that may only want to do a podcast a couple times a year.

That's another thing that I love about the medium. 

[00:08:51] Jemma Issroff: So the ability to enable others or to push others forward. Yeah. You mentioned feedback a few times hearing from your listeners. I know that something that it's tough to do as a podcast host, it's tough to figure out where your listeners are and how they talk to you.

Does anyone have thoughts on that? 

[00:09:09] Andrew Culver: Twitter is the best thing ever. I live on Twitter. And so when you open your DMS, make it easy for people to send you messages. Yeah. Just open that sucker right up. Robbie, have you 

[00:09:20] Jemma Issroff: had similar experiences? 

[00:09:22] Robby Russell: You know, Twitter is helpful. So I do encourage people to email me as well.

Mike format doing more of like interview style and fairly. Topics, but just a broad range of different people. So, but the angle that I, you know, if it's terms of communication, it's also, but it's going to be lonely as a podcast or not. You don't hear often, sometimes we'll post stuff on Twitter and hopefully the guests will reshare that and their network, or we'll help interact with that.

But there's other areas I've found like some interaction over like Reddit. Sometimes I'll post the links there as well, and try to use some controversial title for the episode, just to kind of provoke people a little. That tends to help a little bit as well. Those are some areas, but I do get a lot of emails and occasional DMS and stuff from people.

[00:10:06] Andrew Culver: Banana thought. 

[00:10:07] Brittany Martin: Yeah, for me, I used to have a very loyal listener who would tell me about how terrible my audio was. And I so appreciated them for it because I was learning. And then as I tweak things, I would have sessions with them. And then eventually when we hired a professional editor, he reached out to me and told me how proud he was of me.

And then he would just really believed in the podcast. He held on for all that time that I was learning, but I will say too, the greatest joy for me, I will echo Andrew is when I'm on Twitter and someone will tweet an inside joke from an episode and bring it back. Like we get jokes about goo. We get jokes about treading water.

It's really fun for me to share those jokes with those lists of. I 

[00:10:47] Andrew Mason: think you can be the source of your own feedback as well. I say time and time again, like I'm the only one who listens every single week when our podcast listens, I listened to it and that is a way for me to find errors in the way I speak things that I do when I speak like arm, like, and, uh, and things like that also is if you solicit.

Kind of going back to what Robbie was saying, that's another great way to get it. And I've also said that when you get that feedback, it may not always be positive and it may not mean that you need to change anything. Not all negative feedback means that, oh, I should adjust this because this one person doesn't like the way we do.

[00:11:23] Robby Russell: I was just going to say on the, like, asking for people to do reviews, I've found that if I kind of repeat that over and over, it's kind of becomes an echo chamber of nothing. It's hard to get reviews on apple podcasts and other places. I don't even know where else people were telling me, but go anywhere is stitch.

You're still thinking. Do you know, sometimes I'll just kind of go a little off script and then I'll be like, or write something and some chalk on the sidewalk. And then someone sent me a photo that they did that they were like, oh cool. I got a nice review on some sidewalk in someone's neighborhood. So thank you.

Whoever that was. 

[00:11:54] Nick Schwaderer: And feedback is definitely a gift. It's taken me a long time for me to learn that in like most areas. Like, y'all listen to podcasts. I listen to podcasts. It's quite a big commitment to carve out a half hour, 20, 30 minutes, 60 minutes of your day, especially in a remote world where you don't commute.

So we don't have that cheat code as often anymore. And so most people, if they're unhappy, what do you do? You just switch off? So like how much does somebody care to? Actually, even if it comes off as quite terse with feedback, sometimes it can either be, well, if it's true, why are you offended? And if it's not true, then hire you.

Because not true. I'd always things for me. Any feedback on anything? This is not even just in podcast, but if you can try and wrap a Colonel out of it and make something positive, it's might be one of the nicest things you hear. 

[00:12:37] Jemma Issroff: Switching gears a little bit. Chris Oliver, what do you love about the Ruby ecosystem?

[00:12:42] Chris Oliver: A lot, probably the people the most beside from that, there's something about the Ruby ecosystem that started in entrepreneurship and. The language itself has kinda like designed around humans first, which is unique and rare. So it's all kind of around people and stuff. Hey, 

[00:13:02] Jemma Issroff: what else have thoughts here?

Andrew Kovar. 

[00:13:05] Andrew Culver: So I think the thing that attracted me to the Ruby ecosystem like 10, 12 years ago now it was tooling. And I think that comes back to what Chris is talking about. That it's a human. Maths is nice. So we are nice, like the whole Mina Swan thing. And then the way that, that bubbles up, I think into rails, since we're at rails comp, as a framework is the developer experience.

It's like a framework that was developed with empathy for the way that you would interact with it. And that was different than a lot of what existed at the time. And I think other frameworks have taken inspiration from that. And we certainly don't have a monopoly on developer experience. I think we can look to other frameworks for inspiration.

There is. But the focus on tooling, you know, it, it's interesting. There's a white quote. I'm probably going to butcher it a little bit, but I think there's actually like a lesson to be learned from it. So one of the things that Y said toward the end of his tenure was software. So unrewarding to write something and then a year later it gets replaced by something better.

And then a few more years go by and it doesn't run at all. It doesn't run at all. There's an inverse way. Of looking at that quote. And that is that our stuff's always getting better. There isn't a monopoly on anything and you can always propose a new, a better way. And we're the beneficiaries of that. And because there's that focus on developer experience that keeps driving us forward rails continues to compete.

It continues to be like, I think it is still to this day, the best way to launch SAS applications specifically. And so that's one of the things that I love about rails and love about the community. It's that focus on people 

[00:14:50] Jemma Issroff: what's missing. And we have a foremost why expert, I think probably in the world next to you, who is nodding along.

So I think we can say that quote was all good. What's missing that next year or the next year or the next year we might see in the community. Jason. 

[00:15:04] Jason Charnes: So they talked about Ruby cough, but Andrew is talking about. But like tooling, it's kind of stagnated. It feels like. And the Ruby community, Ruby ecosystem, and like they were talking about Ruby three's focuses on developer experience.

There are times I've considered not writing Ruby. I watched these other people work in languages and they can do amazing things like amazing refactorings and then even things like suggestions. And I'm like, I'm still writing the same Ruby code I'm writing five years ago. So I think that's something we can improve on for sure.

And I think they're trying, so that's 

[00:15:36] Nick Schwaderer: encouraging, I think this will lead into another white quote from it's the similar time which was, and I think that's applies for our community. If you don't create, you become defined by your tastes and your tastes can only alienate other people. So create. And I think that that's something that we can, we have a mature ecosystem.

Now we can really be lazy if we want. And I think the railway is awesome. Like the Ruby way is awesome, but I think we can now put the manta on our shoulders and create, even if it's just fantastic, interesting new jams, be the content we want to see in the world. And that goes with podcasting. It goes with open source.

I really feel Jason saying. And I think that part of that solution would be to continue to create new and innovative things. I think there's definitely a lot of room for that. We could definitely stagnate and make awesome SAS apps, crowed SAS apps all the time with rails, but I think there's a lot more innovation 

[00:16:26] Andrew Culver: and fun to be had.

I think that's a call to action. I think that's what for anybody that's listening to that if that resonates with you, I think we're just scratching the surface. Of what we can do to make it easier for people to develop software. It's such a lucrative opportunity. I have like a physical product business as well, and the margins are terrible.

It's so awful. And like when I sold my first SAS business, the margins, when we went through due diligence for like 95%, we operated at a 95% profit margin. That is an opportunity that we should be trying to get in. And we haven't even scratched the surface of all the SAS software that can be written with rails.

You can find a mission in it in creating better tooling, higher levels of abstraction, greater developer experience and usability so that we can give these tools the best set of tools to a greater set of people so they can improve their economic situation. A single person building a SAS app can change their life.

And I think we've got the best tool to give to people for that. 

[00:17:33] Jemma Issroff: Yeah. Or even I would argue, uh, enable people to build their own tools that can lift them up. Robbie, do you have thought there, 

[00:17:40] Robby Russell: I'm going, go ahead down a little bit of lemon here and say that I disagree with everybody. To an extent I'm actually more interested in maintainable software, but thinking about as new tooling is coming out, I think it's great.

We keep building new tools, but it actually becomes. For all of us software engineers, wherever we're like, well, we need to upgrade to this new thing because that's the new thing that everybody's talking about. And there's not enough emphasis on like, how do I help take care of this stuff that was already working, that our apps are already reliably working with, you know, our customers or our clients have already invested time and money into like everybody chasing the next shiny new thing.

And I'm like, what about the thing that's already working? How can we refactor that? How can we iterate on that? How can we make sure that those gems are getting more support? Maintainers I maintain. And I created an open source project. It's exhausting to take care of projects for a long time. And so I think we need more in the Ruby ecosystem, less new gems, more emphasis on helping participate in helping take over projects or just helping those maintainers push things forward or help offer to volunteer and things like that.

Teaching people how to like migrate these things, how to handle upgrades. So that's the next new shiny object. Isn't the thing that we're trying to compete with? I think the 0.1 of my comrades over here, I was saying here was just, we're trying to make the developer experience great. And we can be a little lazy and we are being lazy as a community at times.

And I think we owe it to ourselves and to our future. To take care of the stuff that we've already invested a lot of time and energy and 

[00:19:08] Andrew Culver: Brittany, 

[00:19:09] Brittany Martin: I think that's a really interesting take Robbie and it kind of makes me question, you know, in order to grow out the Ruby community, we have to do one of two things.

We either need to introduce new people into the community who haven't been here before. Or we need to try to re-acquire the community members who have left for other languages and frameworks. And so the question is if we make the software more maintainable, are we going to be able to coax back the members that we've lost in the past?

Like, is it our job to educate how things are better and really are things about. 

[00:19:39] Jemma Issroff: Nick the Y quote, you pointed to brought up, tastes as being exclusionary. I wonder if anyone has thoughts, in what ways are we as a Ruby community being 

[00:19:48] Andrew Culver: exclusionary? 

[00:19:49] Jason Charnes: This is maybe a crappy take, but rails being the only web framework in Ruby sometimes feels a bit exclusionary.

I like there a NAMI there Sinatra, but people associate Ruby with rails and that's fine. Through accent. Like I very much love rails and obviously, but I do think there's value to be had from like having alternatives and being able to learn from other people and different ideas. I wasn't around for Merv rails, merger, the murderer.

But I think I would have liked to have been because they were like competing ideas that became one, and I think that would help push Ruby 

[00:20:30] Andrew Culver: forward. 

[00:20:32] Colleen Schnettler: So I think it's simpler than that. I do these weekly mentorship calls with junior developers. And I usually get like 15 to 20 and a call and none of them are rails developers.

And I think because we need more junior level rails jobs, people are going to go where the money is. We all need to make money. If you look, I mean, even as us as we've hired people, we don't hire junior developers. We don't, especially in rails. I mean, I know I'm being real specific, but I think part of that is because these applications are.

A little more legacy, a little bit older, you need to have more context. And so I feel like the problem is solvable at the basic level and that's, we need to hire people 

[00:21:16] Andrew Mason: better than. And to add onto that. Here's a call to action. Everyone listening, you and your company are in a position to argue for and to promote and to do whatever you want to call it, to get more junior engineers into your company.

And it's kind of. Management and the senior developers who create and prove that you can have an ecosystem where juniors can thrive. They can learn the way you do rails. They can do all these things, but it really comes down to the people who are already in those positions to bring people into them, to throw the rope down, back after you're done using it and pull up people behind you.

And I really think we can say, oh, well, these companies need to change. But at the end of the day, it's the engineers in those companies who can facilitate this change and we need. 

[00:22:03] Nick Schwaderer: Yeah. And like, plus plus, plus, plus I want to give credit and I won't call out people unless they want to talk about, but people at this table collectively have done so much to lift up juniors and give juniors opportunities.

And to give them a voice, I'd say, if you are listening to this, and if you're listening to this five years from now, randomly in a car, if you're just an engineer, you can give a voice to this in your company. I was hired. A self-taught Ruby list. And I got into the game in 2014 and it was the most isolating and difficult and painful time going from nobody's paying me to code to somebody, paying me anything to code, and it did difficult job.

And if you are able to facilitate even just one person every two years, you're making a huge impact in the universe. And this is something like, if there's anything, like, if you want me to just give you a shout out on Twitter, if you do this for the good of the community, Just an altruistic or there's something that we definitely believe in, and it's great for the community.

And thank you to all of you and everything that y'all have done for juniors over the years, Schwab 

[00:23:01] Jason Charnes: he'll pay a hundred dollars per junior 

[00:23:03] Nick Schwaderer: hire. Yeah, I will actually, yeah, I will. I will pay your company a hundred 

[00:23:07] Robby Russell: dollars and for those listening as well, another thing, if, if you're nervous about the idea of even bring out your first junior developer, bring in interns, do it once a quarter, building your team cycle, keeping them there for six, eight weeks time box it.

So. You know, there's an end period. Tell them that you're not hiring them at the end of that. It's like a period that you're going to pay them for six to eight weeks. That way you're not on the hook for that awkward conversation. When they say, do you want to keep me? Because you got to build in that kind of like that muscle of, because what ends up happening is you might hire that person.

Then you think I won't have time for the next person. So I'm actually a big advocate for having a regular internship cycles. So. It gets in the habit of having people come and go, because it also helps you improve your onboarding experience for new developers to your projects and build up that resilience amongst your team, that this is an expectation of the job.

Not something that we're going to think later down the road. So building internships first, serving in your junior developers, you can do that in parallel as well, but your junior developers have people to mentor immediately when you bring interns in. And so they're part of the process as well. And so that just levels.

So 

[00:24:05] Brittany Martin: at Texas, we'll be hiring two junior backend developers this summer and juniors work well for us because we only hire seniors that are excited to mentor. I can't tell you how many times I have interviewed seniors that have been very technically savvy, but have clearly no interest in mentoring. And unfortunately that just won't work for us.

And so I think that's important that you have to establish that as a norm within your organization. 

[00:24:29] Jemma Issroff: So Chris Winslet, a long-term rails developer is asking, where is the front end going? What's happening to that in the future? Yeah, Andrew 

[00:24:37] Andrew Culver: Culver. I'm sure everybody up here has like an opinion about this and it's very relevant.

I think we're on the right track. I don't think that that excludes react view any of those other toolings, but I think if you go back to that original blog post about stimulus, this isn't exclusive to stimulus. It's a philosophy. What DHH articulated in that blog post, I think is one of the most significant things written in the 15 years that I've been doing software development.

It's more than that now, but in that I think there was a fork in the road where a lot of people started going too far to the front end, too much running in the client. The answer to that isn't react is bad. View is bad. Backbone was bad. Angular was. I think of, uh, somebody that I know military vet saw an opportunity in government for a piece of software that needed to be built and he built it.

It was really scrappy and it had angular. And then at some point there was a new feature. And so we used backbone for that. And then he used Ember and then he used react because each of those was the best tool for the job of the thing that he needed to build. But it was like bolted on top of a traditional rails model.

And so I think the world that we're in right now, sort of canonically in rails with like Hotwire or stimulus, reflex, and cable. Ready, those get you, I think 80%, 90% of the way there. And then if you still need, I work on apps with react bolted on top. I don't do that work, but I think that philosophy pulling out the heavy machinery is the quote from the blog post.

I think it's a solid answer 

[00:26:23] Andrew Mason: web company. That's where the front end is going. In my opinion. Why, why? Because having this entire framework to do maybe this smaller thing, It's kind of going out of style, but what I think is coming more into style is this idea of atomic things that you can put anywhere.

And they work the same. I feel like that's the goal of just normal react components or something. It's like, oh, I can build this react component and I can use it everywhere, but that doesn't work in practice. Really. It's the same thing with like a rails partial. So I feel like we are trending more and more towards this idea of being able to like package the whole thing.

And ship it and then wherever it shipped to, it has the ability to be configured to work in that environment. 

[00:27:07] Brittany Martin: So I'm curious on Andrew, do you feel that all rails developers should be full 

[00:27:10] Andrew Mason: stack? Yes, 

[00:27:11] Nick Schwaderer: I do. I don't have a stiff opinion on this, but I think that something that in wherever it goes, it needs to think of, I won't call anyone out.

I'll say people like me, people like me, who in the eyes of the law are full-stack people like me who run from CSS and JS, but we. And our happiest and the pure Rubin about blah, blah, blah. But we like that rails can help us from the beginning, build a thing. I need to concern myself with my business logic and the problem and the user and what I need to solve for them.

I need as little friction in the way. I'm glad that rails has moved, not just convention over configuration, but like having the support for all the ways that people want to build things. So they figured a friend who is an expert in a thing. They can build the thing on top, but we always need to make sure we support the ability to just build.

I mean, I'm very interested in the new tooling that's coming out, but maybe there's some front end whizzes in here who disagree with me. But as long as we think of the people who are full-stack, but not really, but want to be one person builders, as long as we keep servicing that community, then I think we got, it's 

[00:28:15] Jason Charnes: going to sound like I'm sucking up because it's on the front row.

But view components are kind of a big piece for us, like at podia of moving forward. The thing I like five very fascinating about it is I actually. I'm going to be burned alive at the end of this, I actually kind of like react, but I don't like the JavaScript part of it, but I like the idea of components.

Sorry, sorry. I liked components, I guess it was on trying to say. And so I like the view component because things like sidecar assets where you can like attach JavaScript functionality, Sal sheets, it's kind of isolated. You can test it. I'm not saying like build your app with a full design system beginning as we've learned how to use them.

Like at podia, it's been very valuable because. Now people like me who are like Schwartz that in the eyes of the law considered full stack developers, like we can ship consistent interfaces and we're not as worried about how they look every time we're just rendering out components. And I really, I think that's a good way we're moving as well.

[00:29:15] Andrew Culver: One thing I'll say on that with the few components, I've also found. That there's anybody that that's out there looked at it and they're like, ah, I don't think view components are for me. I think partials also answer some great questions. Like you can go very far just with partials, so you don't have to go to some crazy front end framework.

We've got a lot of tools on the backend, but it all falls under that umbrella of like HTML over the wire. I do think that that's a good place to be. Joe 

[00:29:45] Jemma Issroff: is asking how can we as open source developers or maintainers? Invite more folks, especially those who are underrepresented to contribute to the open-source community.

Yeah, 

[00:29:56] Brittany Martin: Brittany, I think it is inviting those guests onto the show. My first episode that I ever recorded with Nick was his first poll request into rails. And we just dug into what that meant and how like he navigated it and discussing with their contributor. And just really trying to lower the bar and make it clear that it's accessible to everybody, but also making it clear to you, invite guests on that work on smaller projects.

They don't have to be these large, big public projects and then encouraging them as well. Like after you wrap up that episode, Hey, have you considered, you know, supplying this Ruby weekly, they're always looking for content. So get your name out. The other 

[00:30:33] Chris Oliver: thing, another thing is like, you know, as a maintainer, there's a lot of things that are easy for you to fix that are quick, just like intentionally not do them and label it as a good contribution for somebody new and kind of work the process.

If somebody is not sure how the flow goes, like have a whole kind of script of star here, work through it, write it down, like all the edge cases that you need to think of and leave those opportunities open, even though like you could fix it in five minutes yourself. It's nice to be able to have. Some of those, you know, left open on purpose.

[00:31:11] Andrew Culver: I think we need to do more with all of our employers campaign, hard to donate substantially more amounts of money to the open-source projects that you use. I'm not talking 500 bucks. I'm not talking 500 bucks a month. I'm talking like we're going to dedicate 50 grand to this project that we get substantial economic value.

I work on such a project, right? So I have an open source framework that people use on top of rails and we have substantial financial backing on the source side. And that doesn't all go to me that goes out to like seven or eight developers that help me on a regular basis. One of them it's the first professional Ruby he's ever written in his life.

He's a English teacher in Japan. And so that comes from. And so I look at the projects when that was a commercial framework. And I look at the libraries that we use to support. And at 500 bucks a month to some of those projects that we were supporting, we were the highest pain contributor. That's ridiculous.

We have to have a serious conversation. If we want to talk about getting juniors into open source contributions, we need to make a disconnect between open source being unpaid. We have so much money in the businesses that we're in. We're raising so much venture capital. We have so high margins let's donate more money to open source projects.

Now, just to put 

[00:32:40] Robby Russell: in a little bit, a couple 

[00:32:41] Nick Schwaderer: of thoughts, number one, just write this down. If you're not already aware code triaged.com and then just go and look at it later. But if you're going to mentor a junior without it, it allows you to pick a couple of repository. And act settings and just like one polar request a week, I'll just get sent to your inbox.

You can look at it and maybe it's somebody who has been ignored for years and you can like dig into that and learn a bit more. But it's passive first. You have to get that passive contributor experience going down, but what's the goal. Where am I trying to get with this as a junior or senior or an intermediate while I like this term.

And I use a lot privately become an open source civilian. We're not all going to be full-time. Paid to maintain a thing, or some people very luckily are heavily in that, but I feel like we all have a duty as to be an open source civilian, and it's more than just like, oh, I found a bug it's like that passive work.

And maybe just pick a couple of things to participate in. Now the final, I think directly to your point, what can we as casters, besides me just saying. What can we, as podcasters do to further that? I think we need to normalize that. I think we need to make sure that we do what we think people should do.

And then we talk about it because I had listened to podcasts for many years before I ever was on, on, I lived in the country. I didn't talk to Rubius. So I really influenced how I thought about things. Like I remember listening to Derek Pryor and Sage Griffin years and years ago on bike shed and what they talked about.

Their opinions and how they acted in their life. Really informed how I thought I ought to talk and act and we can do the same to say, oh yeah, yeah, that was just on blah, blah, blah repository. And I have to look at this PR firm a couple of years ago that got him from code triaged. She said that a couple of times people will be doing the same.

It lowers the barrier. It makes it just a few hours a month and it becomes a good thing you can do, but like mowing your yard. 

[00:34:26] Robby Russell: I was going to say that one other strategy. I created this thing called once upon a time. There's been a couple thousand people that have contributed to the main project. I don't know how that's managed to happen, but there's a lot, but a lot of participation from people.

And I think that project makes it easier for people to participate for. Sometimes it's quite often their first open-source project that they've contributed to. I didn't do anything intentionally. I don't have to feel like I have the secrets. At all there. But one thing that I have seen work effectively for me and other people that are helping maintain the project is we've had universities reach out to us.

We've had small groups reach out to us. And so when they're like, Hey, we have this idea. We want to participate in, help, get involved in open source project. Can we help contribute to and inquire about this? And we'll be like, all right, well, cool. We're, we're gonna end up working with like three to five people.

We can work on like a project. Maybe there's some ideas we've had for a while. It's sitting in the backlog. We haven't got to go through and review those things yet, or work on some new things. Your gut, some features when we do it in that sort of way, that's made it easier for us to kind of wrap our head around it.

Cause we're not then. So just to saying like, I think it's really important to try to help the individuals that reach out to you and want to contribute. But if you're listening and you're like, I want to contribute, try to maybe find a few people that you'd want to contribute together with, and then you can approach a project and be like, Hey, we're a little more organized.

We've got three of us. Someone's going to be a point of contact. This is what we're hoping to accomplish. This is our. What can we work on? How can we help your project move forward? That makes it way easier for me as a project maintainer, to figure out how I'm gonna wrap my head around what the goal is.

And again, this is like a timebox to it. They're going to get something further collectively, and then they're going to work amongst themselves as well. So they're, you know, they're, they're able to help themselves. And that has been a helpful way for me to bring in people outside of the people that is individually.

[00:36:07] Jemma Issroff: We're going to take one more question. Before we wrap up, John Manel is asking, how can we make our development environment mimic our production environment, especially if it's quite. 

[00:36:18] Andrew Culver: If somebody says, Docker, I'm outta here, Docker, you can use Docker, but your battery will last 

[00:36:23] Brittany Martin: for four hours. It's true. And I think we've always said that, you know, I've done episodes on this, where we talk about having something like the deployment, where it's just baked into the framework.

And I truly don't believe that we're anywhere near that. It is a really good question. I feel your frustration, John, like it's really difficult to solve a bug when it's only something that's going to be present in the ecosystem that you've built in production. And let's not joke around. You might have read is going Alaska, search a CDN.

There's just a lot of stuff. And to try to clone that locally as really 

[00:36:53] Robby Russell: difficult, I got to take the position that I don't think rails should solve that. I feel like if you're building out a SAS, there's like patterns you can follow. And I don't feel like that should be baked into rails. We've had Capistrano.

We saw projects that we deployed with Capistrano. It works great for those projects. And, but we have a lot of ones that I'm like, I don't understand what happens when we push this stuff to a branch. Some magic happens, someone else made that stuff work and they don't understand the pipelines. That's okay.

I'm not answering your question, but I don't feel like that should be a rails thing because I don't think we should have a strong opinion about where it gets deployed, but it gets back to the point around the development environment. Those are trade offs that each of those organizations, especially larger organizations.

If you got an engineering team of 50 to a hundred people. We just wrapped up doing our biannual Ruby on rails survey, community survey, and the growing is like 11% or something. I don't remember the exact number. Our company had, 11% of teams are like 50 plus engineers right now. Or maybe it's like 14% or something like that.

That's a lot of people, a lot of systems are probably in place. And so it's not going to be like, oh, this is really great. When there was like three of us on a team and we could all get everything up and running in like five minutes on our machines. No. How do we connect all these differences? We have serverless stuff.

What is serverless even mean? But, um, so there's a lot of challenges there. I think that those are trade offs that each company is going to need to make in terms of infrastructure. And I don't know that developers should be always be the ones that are making long-term hosting solutions necessarily either kinda make decisions for the 

organization.

[00:38:12] Andrew Mason: It's funny that Bernie said active deployment because in one of my first podcasts, in like 2018, maybe 2019, we had a guest who. Specifically named it active deployment. I'm pretty sure. So it's funny that we're still having this conversation, even though I feel like the ecosystem is getting better and better, there's more and more services to deploy your app.

Like hatch box, fly render. I mean, you can keep going and going and going and going. So I don't feel like deployments getting harder. I feel like developers are complicating their setups more than they need to. And I feel like that's part of the problem. 

[00:38:45] Andrew Culver: Also, my dig at Docker was a joke. I don't love it. I use it every.

Because of some of the complicated infrastructure stuff. So 

[00:38:53] Jemma Issroff: Chris Oliver, any thoughts there, it's 

[00:38:55] Chris Oliver: one of those things where, as a developer, you don't want to have to worry about the operation sides of things. You know, if you could get away without Docker and just have everything running and you have your dependencies and all that, that would be awesome.

But yeah. At some point somebody's going, gonna kind of come up with a, an alternative to Docker that can probably mimic that a bit better. They're still solving a lot of problems on Docker itself. And I think eventually we'll see it, it probably won't come out of the rails ecosystem itself. It's kind of more of a DevOpsy area to work in.

And so I feel like we're oftentimes just consumers of that activity that's going on instead of. Creating those things ourselves and the community. So part of me just feels like, you know, waiting for changes to happen and stuff like that. 

[00:39:46] Andrew Culver: One thing I want to point out, it's not directly related to what you're saying, but I think it's really exciting.

And Chris didn't mention it because it isn't directly related. But I think when you look at hatch box, how many infrastructure companies can you think of all of those companies that are doing interesting infrastructure, things that are boots. The only ones I can think of are layer of L forge and you've got hatch box and that baby was grown in the rails ecosystem.

And I don't think he's done yet. So I think there are exciting things happening in infrastructure, and I think that they can happen in the rails ecosystem. And I think that can be a call to action to anybody that's listening to this. So 

[00:40:26] Jemma Issroff: we have very many calls to action and that's a full cap. I just want to say thank you so much to all of our listeners, always, and especially the ones who are present today, watching this panel and thank you to everyone on the panel for being a part of it. .