Aaron Francis

Learn more →

Transcript

Aaron

00:00:00 – 00:00:20

Hey, y'all. This is a very special bonus episode. This was recorded live at RailsConf. So at RailsConf, they did a podcast crossover panel where they brought a bunch of very Rails specific podcasts together. And our very own Andrew was on the panel at RailsConf.

Aaron

00:00:20 – 00:00:49

I got to sit there in the audience, so I got to hear the whole thing live. Framework Friends stays pretty high level, and we try to dive down on some specifics, but we stay high level and look at comparisons of frameworks. If you want a super deep dive into the Rails ecosystem, how they're thinking about things, how they're trying to grow junior developers into senior developers, there's some really good inside baseball in this episode. So if you're interested in that, this is gonna be a great one for you. You're gonna love it.

Aaron

00:00:49 – 00:00:55

If that's a little too deep dive y into Rails, that's totally fine. We'll see you guys in the next episode.

Gemma

00:00:55 – 00:01:28

Live from Portland at RailsConf, we're recording a podcast panel crossover episode. I'm Gemma Isroff, one of the co hosts of the Ruby on Rails podcast. I'll be moderating this panel. We have 5 podcasts represented here across 8 panelists. We're gonna go around to start and hear what all everyone is excited about for RailsConf.

Gemma

00:01:28 – 00:01:35

First up, we have Brittany Martin from the Ruby on Rails podcast. Brittany, what talk or workshop are you most looking forward to?

Speaker 1

00:01:35 – 00:01:50

I have to admit, I'm gonna go with a meta answer, and it's gonna be this panel, but also as well, the Make A Switch track, which I ended up curating. We already saw Joel Hoxley give a fantastic talk as well as David Hill, and I'm just excited for that track to continue.

Gemma

00:01:50 – 00:01:57

Sounds great. Looking forward to hearing the rest of it. Next up, we have Robbie Russell of Maintainable Software Podcast.

Speaker 2

00:01:57 – 00:02:13

Hello. I'm enjoying so far the, what what is it, Talk to Me Like I'm 5 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 I'm kind of mandating most of my teams sit in those ones in particular if they can.

Gemma

00:02:14 – 00:02:15

Which ones have you been to so far?

Speaker 2

00:02:15 – 00:02:31

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 as well.

Gemma

00:02:31 – 00:02:34

Next up, Andrew Culver from Framework Friends.

Speaker 3

00:02:34 – 00:02:55

Yeah. So for me, conferences are about people, and so I'm kinda notorious for hanging out in the hallway track. I'll attend a few talks, but mostly, like, for the limited time that I'm here, I come in late. I leave real early because I got kids that I gotta get back to back home. But for the time that I'm here, I just try to have so much face time with, you know, everybody, like, who's in the room right now.

Gemma

00:02:55 – 00:02:58

Nice. Nick Schwenerer, Ruby on Rails podcast.

Speaker 4

00:02:58 – 00:03:05

I'll do 2 things. 1, like, RailsConf for me is back. I'm just so hyped for it. Mhmm. I'll call out.

Speaker 4

00:03:05 – 00:03:16

I joined the Ruby community in 1st week of March 2014. I've never been to RailsConf. I've, like, followed the content for 8 years. So it's such a treat to be here. I will, to honor your question, pick a specific thing.

Speaker 4

00:03:16 – 00:03:36

I'm excited to see the remote Ruby Gang talking about, pocket well, 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 we say in the UK, buzzing to see, the Remote Ruby guy.

Gemma

00:03:37 – 00:03:42

Yeah. There's a whole community content track. Speaking of Remote Ruby, Andrew Mason.

Speaker 5

00:03:42 – 00:03:54

Yeah. What's up, everybody? I was excited for Joel Hoxley's talk, which is great. Joel, again, Joel's in the audience for anyone listening. I'm excited for Schwad's talk because Schwad always gives amazing talks.

Speaker 5

00:03:55 – 00:04:01

I'm always excited for Britney's talk. Britney's not giving a talk this month, so that's why I'm excited

Gemma

00:04:01 – 00:04:04

to hear her here. Next up, Jason Terrence.

Speaker 6

00:04:04 – 00:04:14

Oh my god. Hello. Well, I feel like any answer I give now would just be cheating. I too very much like the hallway tracking the people. I very much enjoyed Joel's talk.

Speaker 6

00:04:14 – 00:04:24

Dave Copeland's giving one I'm really looking forward to. The one I'm least looking forward to is the remote Ruby talk. Oh, and I'm excited that Aaron Francis is here, so we can talk about Laravel that's holding on

Speaker 7

00:04:24 – 00:04:26

to her. Laravel.

Gemma

00:04:26 – 00:04:29

Also, of remote Ruby, we have Chris Oliver next.

Speaker 7

00:04:29 – 00:04:38

I'm just so excited to, like, put faces to Twitter avatars and Discord and everything. Had conversations with so many people and then

Colleen

00:04:47 – 00:05:02

I am super excited about my workshop, which is coming up in 45 minutes on building an advanced query builder with ActiveRecord. And there's actually quite a few ActiveRecord talks here this week, so I'm super pumped for those. I'm really looking forward to it.

Gemma

00:05:02 – 00:05:09

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 there.

Speaker 1

00:05:09 – 00:05:26

Yeah, Britney. 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 cohost's career. Nick's first episode was September 2018. He was a regular guest, and then he became official cohost in 2021.

Speaker 1

00:05:26 – 00:05:43

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 just I feel really grateful that I have an opportunity to talk to them regularly about it.

Gemma

00:05:44 – 00:05:50

We feel grateful for the same. Well, Ruby, I know you're doing a whole talk on podcasting. Do you wanna give us a little preview?

Speaker 6

00:05:52 – 00:05:53

I'll let Andrew give the preview.

Speaker 5

00:05:54 – 00:06:17

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 gonna be about kind of our journey to starting 1, kind of the lessons that we've learned. Because I've at this point, I've been on 3 podcasts. Jason and Chris started Remote Ruby, and then I joined them later.

Speaker 5

00:06:17 – 00:06:33

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.

Gemma

00:06:34 – 00:06:36

What are some of the mistakes?

Speaker 5

00:06:36 – 00:06:56

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 cohosts. And if you only have 2 cohosts, 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.

Speaker 5

00:06:56 – 00:07:07

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 fun of it.

Gemma

00:07:07 – 00:07:10

Colleen, do you have a similar view on podcasting?

Colleen

00:07:11 – 00:07:28

So 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.

Colleen

00:07:28 – 00:07:47

I just could not get into a good routine. I didn't like it. And then I started podcasting. 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 because I do a podcast with someone who I'm already friends with.

Colleen

00:07:48 – 00:07:57

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.

Gemma

00:07:59 – 00:08:00

Andrew, yeah, do you have similar thoughts?

Speaker 3

00:08:00 – 00:08:12

Yeah. So for me, it's 2 things. We were already having conversations. So Aaron and I were already chatting. And so by just hitting record, they gave us this opportunity to kinda, like, share that.

Speaker 3

00:08:12 – 00:08:33

I kinda had a sense, like, yeah, yeah, people might find this interesting. What you can't if for anybody that's listening, there are so many podcasts. Mhmm. We have friends like Justin Jackson and, like, his whole life is podcasts because there's so many of them out there. And so anybody that thinks that they have a unique take on something, if you're thinking about starting a podcast, start a podcast.

Speaker 3

00:08:33 – 00:09:00

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 gonna 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 as well.

Speaker 3

00:09:01 – 00:09:30

And until you start publishing stuff, you can't know if that's gonna 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.

Speaker 3

00:09:31 – 00:09:57

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 6 months because I might have something to say. And so the idea that you can get an audience, and then you can share with that audience the incredible thinking of people that may only wanna do a podcast a couple times a year. That's another thing that I love about the medium.

Gemma

00:09:57 – 00:10:11

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's 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.

Gemma

00:10:12 – 00:10:13

Does anyone have thoughts on that?

Speaker 3

00:10:13 – 00:10:25

Twitter. 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.

Gemma

00:10:25 – 00:10:27

Robbie, have you had similar experiences?

Speaker 2

00:10:27 – 00:10:53

You know, Twitter is helpful. So I do encourage people to email me as well. My format doing more of, like, interview style and fairly consistent topics, but just a broad range of different people. So but the angle that I you know, in terms of communication, it's also but it can be lonely as a podcaster and that you don't hear. Oftentimes, we'll post stuff on Twitter, and hopefully, the guest will reshare that and their network or will help interact with that.

Speaker 2

00:10:53 – 00:11:11

But there's other areas I 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 bit. 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 as well.

Gemma

00:11:11 – 00:11:13

Brittney, any thoughts?

Speaker 1

00:11:13 – 00:11:33

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, like, how proud he was of me and then he would just really believed in the podcast.

Speaker 1

00:11:33 – 00:11:52

And so he held on for all that time that I was learning. But I will say to you, the gravest 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 listeners.

Speaker 5

00:11:52 – 00:12:15

I 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 listen 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, like, and and things like that. Also, is if you solicit feedback, kinda going back to what Robbie was saying, that's another great way to get it.

Speaker 5

00:12:15 – 00:12:28

And I would also say 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 this.

Speaker 2

00:12:28 – 00:12:52

I was just gonna say on the, like, asking for people to do reviews, I 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 are telling me to go anywhere. Is Stitcher still a thing? Anyways, you know, sometimes I'll just kinda 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.

Speaker 2

00:12:52 – 00:12:58

Woah. And they so I'm like, oh, cool. I got a nice review on some sidewalk in someone's neighborhood. So thank you, whoever that was.

Speaker 4

00:12:58 – 00:13:15

Nice. And feedback's definitely a gift. It's taken me a long time for me to learn that in, like, most areas of life. Like, y'all listen to podcast, I listen to podcast. 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 we don't commute, so we don't have that that cheat code as often anymore.

Speaker 4

00:13:16 – 00:13:32

And so most people, if 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 why are you offended? Because it's not true.

Speaker 4

00:13:32 – 00:13:42

It always stings for me, any feedback and anything. This is not even just a podcast. But if you can try and wrap a kernel out of it and and make something positive, it might be one of the nicest things you

Gemma

00:13:42 – 00:13:47

hear. Switching gears a little bit, Chris Oliver, what do you love about the Ruby ecosystem?

Speaker 7

00:13:48 – 00:14:07

A lot. Probably the people the most. Aside from that, there's something about the Ruby ecosystem that started in entrepreneurship and the language itself is kinda like designed around humans first, which is unique and rare. So it's all kind of around people and stuff.

Gemma

00:14:08 – 00:14:10

Anyone else have thoughts here? Andrew Culver.

Speaker 3

00:14:11 – 00:14:42

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 like, Mats 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 RailsConf, 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.

Speaker 3

00:14:42 – 00:15:03

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 as well. But the focus on tooling, you know, it it it's interesting. There's a why quote. I'm probably gonna butcher it a little bit, but I think there's actually, like, a lesson to be learned from it.

Speaker 3

00:15:03 – 00:15:33

So one of the things that Y said toward the end of his tenure was software so unrewarding. You 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.

Speaker 3

00:15:34 – 00:15:54

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 SaaS 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.

Gemma

00:15:55 – 00:16:08

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?

Speaker 6

00:16:09 – 00:16:30

So they talked about RubyConf, but Andrew is talking about tooling. But, like, tooling's kinda stagnated, it feels like, and the Ruby community, Ruby ecosystem. And, like, they're talking about Ruby threes focuses on developer experience. There are times I've considered not writing Ruby. I watch these other people work in languages and they can do amazing things, like amazing refactorings.

Speaker 6

00:16:30 – 00:16:36

And then even things like suggestions. And I'm like, I'm still writing the same Ruby code I'm

Speaker 4

00:16:45 – 00:16:59

from a similar time which was and I think this applies for our community today. If you don't create, you become defined by your tastes. Your taste can only alienate other people. So create. And I think that that's, something that we could we have a mature ecosystem now.

Speaker 4

00:16:59 – 00:17:15

We can really be lazy if we want. And I think the rails way is awesome. Like, the Ruby way is awesome. But I think we can now put the mantle on our shoulders and create, even if it's just fantastic, interesting new gems. Be the content we want to see in the world, and that goes with podcasting, it goes with open source.

Speaker 4

00:17:15 – 00:17:32

I really feel Jason's 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 SaaS apps, crowd SaaS apps all the time with Rails, but I think there's a lot more innovation and fun to be had.

Speaker 3

00:17:33 – 00:17:57

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.

Speaker 3

00:17:58 – 00:18:31

And, like, when I sold my first SaaS business, the margins when we went through due diligence were like 95%. We operated at a 95% profit margin. That is an opportunity that we should be trying to give. And and we haven't even scratched the surface of all the SaaS 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.

Speaker 3

00:18:32 – 00:18:38

A single person building a SaaS app can change their life, and I think we got the best tool to give to people for that.

Gemma

00:18:38 – 00:18:45

Yeah. Or even, I would argue, enable people to build their own tools that can lift them up. Robbie, do you have a thought there?

Speaker 2

00:18:45 – 00:19:19

I'm gonna go ahead on a little bit of limit 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 a problem for all of us software engineers where 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 the stuff that was already working, that our apps are already reliably working with, you know, our customers, our clients have already invested time and money into. And, like, everybody chasing the next shiny new thing.

Speaker 2

00:19:19 – 00:19:32

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 maintained, and I created an open source project.

Speaker 2

00:19:32 – 00:20:13

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 and 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 the next new shiny object isn't the thing that we're trying to compete with. I think the point one of my comrades over here 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 selves to take care of the stuff that we've already invested a lot of time and energy in.

Gemma

00:20:13 – 00:20:14

Yeah. Brittany?

Speaker 1

00:20:14 – 00:20:42

I think that's a really interesting take, Robbie. And it kinda makes me question, you know, in order to grow out the Ruby community, we have to do one of 2 things. We either need to introduce new people into the community who haven't been here before, or we need to try to reacquire 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 gonna 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?

Speaker 1

00:20:42 – 00:20:44

And really, are things better?

Gemma

00:20:44 – 00:20:54

Nick, the why 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 exclusionary?

Speaker 6

00:20:54 – 00:21:22

This is maybe a crappy take. But Rails being the only web framework in Ruby sometimes feels a bit exclusionary. And, like, there's tsunami, there's Sinatra, but people associate Ruby with rails, and that's fine to an extent. 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.

Speaker 6

00:21:22 – 00:21:36

I wasn't around for Merv, Rails merger, the Merber. 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 forward.

Colleen

00:21:37 – 00:21:49

Yeah. Totally. 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 in a call. And none of them are Rails developers.

Colleen

00:21:49 – 00:22:04

And I think because we need more junior level Rails jobs. People are gonna 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.

Colleen

00:22:04 – 00:22:22

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. Better Junior.

Speaker 5

00:22:23 – 00:23:01

And to add on to that, here's a call to action to everyone listening. You and your company are in a position to argue for and to promote and to do whatever you wanna call it to get more junior engineers into your company. And it's kind of up to management and the senior developers to 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.

Speaker 5

00:23:01 – 00:23:07

But at the end of the day, it's the engineers in those companies who can facilitate this change, and we need to.

Speaker 4

00:23:08 – 00:23:30

Yeah. And, like, plus, plus, plus, plus. I wanna give credit, and I I won't call out people unless I wanna talk about it. 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 5 years from now randomly in a car, if you're just an engineer, you can give a voice to this in your company.

Speaker 4

00:23:30 – 00:24:06

I was hired as a self taught Rubyist, 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's paying me anything to code, and I did a difficult job. And if you are able to facilitate even just one person every 2 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 shout outs on Twitter, if you do this for the good of the community, just an altruistic good is something that we definitely believe in, and it's great for the community. And thank you to all of you and everything that you all have done for juniors over the years.

Speaker 6

00:24:06 – 00:24:09

Schwab said he'll pay a $100 per junior hire.

Speaker 4

00:24:09 – 00:24:12

Yeah. I will, actually. Yeah. I will. I will pay your company a $100.

Speaker 2

00:24:13 – 00:24:42

And for those listening as well, another thing, if if you're nervous about the idea of even bringing out your 1st junior developer, bring in interns. Do it once a quarter, build it into your team's cycle, keep them there for 6, 8 weeks, time box it so that you know there's an end period, tell them that you're not hiring them at the end of it. It's like a period that you're gonna pay them for 6 to 8 weeks. That way, you're not on the hook for that awkward conversation when they say, do you wanna keep me? Because you gotta build in that kind of, like, those 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.

Speaker 2

00:24:42 – 00:25:10

So I'm actually a big advocate for having a regular internship cycle so that your team 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 gonna think later down the road. So build 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 everybody up.

Speaker 1

00:25:10 – 00:25:33

So at TextUs, we'll be hiring 2 junior back end 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 men's wearing. 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.

Gemma

00:25:34 – 00:25:43

Great. 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 Kolber.

Speaker 3

00:25:43 – 00:26:34

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, Vue, 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, it's the idea. 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 bad.

Speaker 3

00:26:34 – 00:27:02

I think of 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 he 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 monolith.

Speaker 3

00:27:03 – 00:27:28

And so I think the world that we're in right now, sort of canonically in Rails with, like, Hotwire or Stimulus Reflex and CableReady, 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 it's a solid answer.

Speaker 5

00:27:29 – 00:27:42

Web components. That's where the front end is going, in my opinion. Why? Why? Because having this entire framework to do maybe this smaller thing, I feel like it's kind of going out of style.

Speaker 5

00:27:42 – 00:28:06

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 up and ship it.

Speaker 5

00:28:06 – 00:28:12

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

Speaker 1

00:28:12 – 00:28:16

So I'm curious then, Andrew, do you feel that all rails developers should be full stack?

Speaker 5

00:28:16 – 00:28:17

Yes. I do.

Speaker 4

00:28:17 – 00:28:36

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 will write it, and are happiest in the pure Ruby.

Speaker 2

00:28:36 – 00:28:38

But but but but but but

Speaker 4

00:28:38 – 00:29:01

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 in 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 wanna build things. So if you got a friend who's an expert in a thing, they can build the thing on top.

Speaker 4

00:29:01 – 00:29:20

But we always need to make sure we support the ability to just build product. 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 wanna be one person builders, as long as we keep servicing that community, then I think we can.

Speaker 6

00:29:20 – 00:29:43

It's gonna 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, find very fascinating about it is I actually just I'm gonna 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.

Speaker 6

00:29:43 – 00:29:55

Sorry. I like components, I guess, is what I'm trying to say. And so I like the view component because things like sidecar assets where you can, like, attach JavaScript functionality, style sheets. It's kinda isolated. You can test it.

Speaker 6

00:29:55 – 00:30:20

I'm not saying like build your app with a full design system beginning. As we've learned how to use them, like a podia, it's been very valuable because now people like me who are like Schwab said in the eyes of the wall, 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 just a good way we're moving as well.

Speaker 3

00:30:20 – 00:30:47

One thing I'll say on that with the Vue components, I've also found that there's anybody that that's out there looked at it, and they're like, I don't think Vue components are for me. I think partials also answer, you know, 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 got a lot of tools on the back end, but it all falls under that umbrella of, like, HTML over the wire.

Speaker 3

00:30:47 – 00:30:49

I do think that that's a good place to be.

Gemma

00:30:49 – 00:31:02

Joe Mazzolotti is asking how can we, as open source developers or maintainers, help invite more folks, especially those who are underrepresented to contribute to the open source community? Yeah, Britney.

Speaker 1

00:31:02 – 00:31:36

I think it is inviting those guests onto the show. My first episode that I ever recorded with Nick was his first pull request into rails, and we just dug into what that meant and how, like, he navigated it and discussing with the contributors and just really trying to lower the bar and make it clear that it it's accessible to everybody, but also making it clear too that 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 us to Ruby Weekly? They're always looking for content.

Speaker 1

00:31:36 – 00:31:38

So get your name out there.

Speaker 7

00:31:38 – 00:32:16

Yeah. I think 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 with them. If somebody is not sure how the flow goes, like have a whole kind of script of start 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 5 minutes yourself. It's nice to be able to have some of those, you know, left open on purpose.

Speaker 3

00:32:16 – 00:32:43

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 I'm not talking $500 a month. I'm talking, like, we're gonna dedicate $50 to this project that we get substantial economic value from. I work on such a project. Right?

Speaker 3

00:32:43 – 00:33:05

So I have an open source framework that people use on top of rails, and we have substantial financial backing on the open source side. And that doesn't all go to me. That goes out to, like, 7 or 8 developers that help me on a regular basis. One of them, it's the 1st professional Ruby he's ever written in his life. He's a English teacher in Japan.

Speaker 3

00:33:05 – 00:33:24

And so that comes from funding. And so I look at the projects when that was a commercial framework, and I look at the libraries that we used to support. And at $500 a month to some of those projects that we were supporting, we were the highest paying contributor. That's ridiculous. We have to have a serious conversation.

Speaker 3

00:33:24 – 00:33:44

If we wanna talk about getting juniors into open source contributions, we need to make a disconnect between open source being unpaid labor. 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.

Speaker 4

00:33:45 – 00:34:03

Now, just to put in a little bit a couple of thoughts. Number 1, just write this down if if you're not already aware, codetriage.com. And then just go look at it later. But if you're gonna mentor a junior with that, it it allows you to pick a couple of repositories and pick settings. And just like one pull request a week, it'll just get sent to your your inbox.

Speaker 4

00:34:03 – 00:34:15

You can look at it. And maybe it's somebody who's been ignored for years, and you can like dig into that and learn a bit more. But it's passive. 1st, you have to get that passive contributor experience going down. But what's the goal?

Speaker 4

00:34:15 – 00:34:37

Where am I trying to get with this as a junior or senior or an intermediate? Well, I like this term, and I use a lot privately, become an open source civilian. We're not all gonna 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.

Speaker 4

00:34:37 – 00:34:58

It's like that passive work, and maybe just pick a couple things to participate in. Now, to final, I think directly to your point, what can we as casters, besides me just saying 2 thoughts now, 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 them.

Speaker 4

00:34:58 – 00:35:16

I lived in the country. I didn't talk to Ruvius. So I really influenced how I thought about things. Like I remember, I I listened to Derek Pryor and Sage Griffin years years ago on Bike Shed, and what they talked about 2 people, their opinions and how they acted in their life really informed how I thought I ought to talk and act, and and we can do the same too. Say, oh, yeah.

Speaker 4

00:35:16 – 00:35:26

Yeah. That was just on blah blah blah repository. And I look at this PR from a couple years ago that got in from Code Triage. We said that a couple of times, people will be doing the same. It lowers the barrier.

Speaker 4

00:35:26 – 00:35:31

It makes it just a few hours a month, and it becomes a good thing you can do, like, mow in your yard.

Speaker 2

00:35:31 – 00:36:04

I was gonna say that one other strategy that I created this thing called Omazeesha once upon a time, and 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 been a lot of participation from people, and I think that project makes it easy for people to participate for sometimes, it's quite often their first open source project that they contribute to. I didn't do anything intentionally. I don't feel like I have the secret sauce 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.

Speaker 2

00:36:04 – 00:36:14

We've had small groups reach out to us. And so when they're like, hey, we have this idea. We We wanna participate and help get involved in an open source project. Can we help contribute to Open Z Shell? They'll inquire about this, and we'll be like, alright.

Speaker 2

00:36:14 – 00:36:22

Well, cool. We're we're gonna end up working with, like, 3 to 5 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.

Speaker 2

00:36:22 – 00:36:47

We haven't got to go through and review those things yet or work on some new features or got some features. When we do in that sort of way, that's made it easier for us to kinda wrap our head around it because we're not then so just to say, like, I think it's really important to try to help the individuals that reach out to you and wanna contribute. But if you're listening and you're, like, I wanna contribute, try to maybe find a few people that you'd wanna contribute together with. And then you can approach a project being, like, hey, we're a little more organized. We got 3 of us.

Speaker 2

00:36:47 – 00:36:54

Someone's gonna be a point of contact. This is what we're hoping to accomplish. This is our timeline. What can we work on? How can we help your project move forward?

Speaker 2

00:36:54 – 00:37:12

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, there's like a timebox to it. They're gonna get something further collectively, and then they're gonna work amongst themselves as well. And 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 just individually

Gemma

00:37:12 – 00:37:22

come. We're gonna take one more question before we wrap up. John Monnell is asking, how can we make our development environment mimic our production environment, especially if it's quite complex?

Speaker 3

00:37:23 – 00:37:30

If somebody says Docker, I'm out of here. Docker. You can use Docker, but your battery will last for 4 hours.

Speaker 1

00:37:30 – 00:37:50

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 active 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 because I feel your frustration, John. Like, it's really difficult to solve a bug when it's only something that's gonna be present in the ecosystem that you've built in production.

Speaker 1

00:37:50 – 00:37:59

And let's not joke around. You might have Redis going, Elasticsearch, CDN. There's just a lot of stuff. And to try to clone that locally is really difficult.

Speaker 2

00:37:59 – 00:38:16

I can take the position that I don't think Rails should solve that. I feel like if you're building out a SaaS, there's, like, patterns you can follow, and I don't feel like that should be baked into Rails necessarily. We've had Capistrano. We saw projects that we deploy with Capistrano. It works great for those projects, 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.

Speaker 2

00:38:16 – 00:38:32

Some magic happens. Someone Someone else made that stuff work, and I 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 at each of those organizations, especially larger organizations.

Speaker 2

00:38:32 – 00:38:48

If you got an engineering team of 50 to a 100 people, we just wrapped up doing our biennial Rubicon Rails survey community survey. And, like, growing is, like, 11% or something. I don't remember the exact number I copied my head. 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.

Speaker 2

00:38:48 – 00:39:02

A lot of systems are probably in place. And so it's not gonna be, like, oh, this is really great when it was, like, 3 of us on a team, and we could all get everything up and running in, like, 5 minutes on our machines. Now it's like, how do we connect all these different system? We have serverless stuff. What does serverless even mean?

Speaker 2

00:39:02 – 00:39:17

But, so there's a lot of, like, challenges there. I think that those are trade offs that each company is gonna 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, kind of make decisions for the organization.

Speaker 5

00:39:18 – 00:39:45

It's funny that Britney said active deployment because in one of my first podcasts in, like, 2018, maybe 2019, we had a guest who talked Specifically, he 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 Hatchbox, Fly, Render. I mean, you can keep going and going and going and going. So I don't feel like deployment's getting harder.

Speaker 5

00:39:45 – 00:39:50

I feel like developers are complicating their setups more than they need to, and I feel like that's part of the problem.

Speaker 3

00:39:50 – 00:39:58

Also, my dig at Docker was a joke. I don't love it. I use it every day because of some of the complicated infrastructure stuff. So

Gemma

00:39:59 – 00:40:00

Chris Oliver, any thoughts there?

Speaker 7

00:40:00 – 00:40:33

It's 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, I think at some point, somebody's 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.

Speaker 7

00:40:33 – 00:40:52

It's kind of more of a DevOps y 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 in the community. So part of me just feels like, you know, waiting for changes to happen and stuff like that.

Speaker 3

00:40:52 – 00:41:30

One thing I wanna 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 HatchBox, how many infrastructure companies can you think of all of those companies that are doing interesting infrastructure things that are bootstrapped? The only ones I can think of are Laravel Forge and you've got Hatchbox, 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 as well.

Gemma

00:41:31 – 00:41:45

So we have very many calls to action, and that's a full cap. I just wanna 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.

(Extra) RailsConf Podcast Panel

Transcript

Not enough emails?