Code and the Coding Coders who Code it

We talk about Ruby, Rails, JavaScript, and everything in between. From tiny tips to bigger challenges we take on 3 questions a show; What are you working on? What's blocking you? What's something cool you want to share?

All Episodes

Code and the Coding Coders who Code it

Episode 10 - Ernesto Tagwerker

September 06, 2022 • Drew Bragg • Season 1 • Episode 10

0:00 | 55:59

My friend and fellow Philadelphian, Ernesto Tagwerker joins the show to talk about his companies new offering, Tune. We also talk about some of Ernestos open source projects, how his team balances educating the community on how do upgrade while also making it their main business, and strategies to onboard juniors.

Links:

Send us some love.

Judoscale
Autoscaling that actually works. Take control of your cloud hosting.

Support the show

Drew 0:04

Hello everyone. And welcome to another episode of code and the code and coders who code it? I'm your host, drew brag. And today I'm joined by Ernesto tech worker from fast Ruby IO and also from my home city, Philadelphia. Ernest, why don't introduce yourself.

Ernesto 0:18

Hey drew, happy to be here. And, yeah, my name is Ernesto tech worker and, I guess my pronouns are he him and I'm the founder and CTO of, fast ruby.io and humble labs. And, when I'm not working on code, I like to spend time with my kids or my wife, and to enjoy the wonderful city of Phil.

Drew 0:43

Awesome. So for those of you who are new to the show, I'm gonna ask Ernesto three questions. I'm gonna ask him what he's working on. If he has any blockers and if he doesn't, what blockers did he recently have and how did he solve them? And then I'm gonna give him an opportunity to wrap up the show by just sharing anything cool, new or interesting that he's built or learned doesn't even have to be coding related. So Ernesto with that being said, what have you been working on?

Ernesto 1:07

man. So many things. Actually just got, got back from my vacation. I took four weeks off, so I'm still trying to. Think about what was I doing before I took off? so yeah, uh, one thing that we been working on at fast Ruby that I owe is a new, audit, offer. Basically it's a performance audit for anybody who's running a Ruby or rails application. And yeah, I wanna say a few months ago we partnered with, Nate Burke Koeck who. It's kinda like the rails performance guy. If you don't know him, please go and read all the things he's written in the past. but anyway, Nate and I have been friends, uh since a couple conferences ago and yeah, we wanted to, to start offering this, this new audit to, to the rails ecosystem and. Talked to him. And we said, let's do tune, which is basically one service. He was doing many, many years ago. And then he stopped doing it. And I thought it was like a really cool idea to get a sense of how your application is doing in terms of performance. So right now we are working with a couple clients, working a couple reports for them and. I guess I'm trying to get the word out that this is out there and it's available and people can just come to us and, and we can work on something like that for them and help them, have a more performant application, out there. Another thing that I'm working on, I guess, is, some open source projects, uh, Maintainer and contributor to a few Ruby, code quality tools like, Ruby critic and skunk. And one of the things that I want to do before the end of the year is release version 1.0 of skunk. and answer a few repeat questions that I've had about that library. So those I think are like my two priorities for the next, uh, three months or so.

Drew 3:14

That's awesome. That's a lot to unpack too. So for tune, I know you guys have prerequisites for doing an upgrade, right? You have to have test coverage. You have to have. Things so that you guys know you're coming into an application, you actually can upgrade. What are the prerequisites for something like tune?

Ernesto 3:31

Yeah for tune, it's actually a lot easier. There is really not that much in terms of prerequisites. we need to get access to your source code. so I guess there needs to be like, Some NDA signed for us to look at like private information. and we need to get access to your APM. So if you're running scout or a new Relic or skylight, we're gonna need access to those, services. So I guess, if you're not running an APM, there will be like initial step to say, okay, Hey, we need to install this. It needs to run for at least a week. And. Then we can get to work. You know, you get, we get to look at your source code, look at your infrastructure, look at the new Relic data or APM data. And usually it's pretty quickly, like in about a week, we'll come up with a report and then, you know, you can either decide to work with us on making the changes or you can do the changes yourself. so yeah, compared to the rails upgrade service that we offer. It's a lot less in terms of prerequisites. and just to, to make it clear for anybody who's never heard about fast Ruby, do I owe it's, um, productized service to do rails upgrades for companies that struggle to do them. And one of the prerequisites is that their test suite is. You know, pretty solid. So I would say like 70% or more in terms of code coverage, we have worked with clients that have like 50% or more. The problem with that is, you know, manual QA takes time. And if you add the human factor to a. Already long project is only gonna make it longer. so yeah, we just rely so heavily on the test suite that we need applications to have like a really good test suite. So we don't have to go manually testing like 50% of your application. But it is, it is quite a big requirement. I know like some applications or some teams that struggle with, technical debt also struggle with, keeping up with their test suite and making sure that the test suite is getting better in, you know, every sprint.

Drew 5:45

Yeah, no, absolutely. I mean, it's test coverage is important and hopefully everyone's floating around that magic number, but if you're not there, getting there can be, can be tough. So when you're, when you get access to an APM, what are like the first metrics you look at? Like the most important metrics.

Ernesto 6:02

Yeah. So I think the request, queuing time is one of the, the key ones that we look at. you know, how much time does a request sit there, waiting for a process to become available, to process it. so sometimes, you know, when it's higher than 50 milliseconds, that's usually like, A sign that we could improve it. We could set up your Kubernetes cluster to have more, you know, passenger processes to process it. yeah, I think that's, that's usually one of them, uh, page load time is another one. and yeah, it usually depends on, on the application sometimes, you know, it's. It depends on whether it's like using a lot of JavaScript. So the JavaScript is taking forever to load, or sometimes it's something more specific like, um, maybe your application code needs to be improved, but we try to go from like more generic to more specific. Uh, when it, we work on a tune.

Drew 7:07

Okay. I know, actually you sort of answered my next question was, you know, how much front end stuff do you touch as far as performance goes? Um, so it sounds like you do touch it a at least a little bit. How, how much are you looking for? All right. We have. Massive amounts of style sheets and JavaScript going over the wire and that's slowing down stuff, or we're not caching things correctly on the front end. or is it more of just a, yeah, no, we're mostly looking at your Interactions with database, your interactions through rack and things like that.

Ernesto 7:43

Yeah, I, I would say it's more Ruby and rail specific than JavaScript specific, like, We might look at yeah. Caching and seeing like how much of the JavaScript that you're using is being cashed. whether, you know, you're using web back or, or something else, whether you're using a CDN or not. ideally we, we, you know, will recommend, like to start using a CDN for all the. Packs or all the chunks that need to be cashed. but we are not gonna go and dive very deep inside, like your JavaScript code. that is something else. one thing, another thing that's kind of coming down the pipeline for us is a productized service. JavaScript upgrades, more like no JS upgrades, but, we are not thinking we're not planning to launch any like JavaScript performance optimization services anytime soon, maybe in the next five years or so, but for now, it's just Ruby rails and infrastructure, heavy. When we work on the tomb.

Drew 8:51

Sure. And how much, so you have your Ruby bits or your rails bits, you have your database bits. How much does the infrastructure play in. What your tune report looks like? Like you had mentioned, we may suggest doing something with Kubernetes. If you're not on Kubernetes, how, like, does that change a lot of what you look at or look for? Or is it pretty much like if you're using Kubernetes, we're gonna go this route. If you're not, and you're doing this instead, we'll tweak it slightly, but it's the same generic. Like, this is what we look for on the infrastructure side.

Ernesto 9:26

Yeah, we look at the infrastructure and depending on, on what they use, you know, we might tweak our recommendations. Like if you're using Heroku, we might recommend use, the autoscaler plugging that, uh, I forget who, who built it? I wanna say it's his name is Adam, but, you know, instead of using like Heroku's native autoscale performance dinos, we would probably recommend like, Hey, use this, plugin that someone is, I think it's called rails auto scale.

Drew 9:58

Hm. Yeah. I,

Ernesto 10:00

we'll have to Google that later, but yeah. Yeah. but anyway, use that tool if you're not using it, if you are using it then, okay, great. Then we check that item off the list and we continue down with like another item and we make our recommendations based on what you currently have. you know, some people think that you need to move off Heroku and like start using. You know, Kubernetes or Google cloud or whatever. the past, I participated in those migration projects and sometimes it costs so much to actually do it that I don't know if it's like the best way. So what we usually try to do is to make things work and scale with what you have. And if we notice like, okay, you've maxed out all the things that we recommend it, then it's like, okay, maybe it is time to move away from Heroku and start using, you know, Google cloud or AWS. But usually, you know, Heroku, we, we love Heroku. We use it a lot, use it for our internal tools and, yeah, I'm one 99% sure that you can tweak Heroku to go way faster. with our recommendations.

Drew 11:14

Okay. And then, so once you have a tune report, is it fairly easy? For if a team does have the capacity to say, okay, engineer, if you're gonna go off and take care of this checkbox item, other engineer, you're gonna go do this. Is it pretty easy for a team to take your report and do it, do it themselves if they wanted to, or is it maybe split where it's like some of these things you could do yourself, but you probably wanna hire our team to take care of the more complex items or do you just distill it down enough for them?

Ernesto 11:46

Yeah, I think, um, Their recommendations are good enough and clear enough that a team could just take a, take it and run with it. Um, and if it's not super clear, I'm sure we can point them to the right documentation for them to like go and follow the steps. Um, I think it works well. When you take the broken recommendations, you implement them. And six months ahead, you know, six months go by and we come in and we do the same report and we tell you. Awesome. You implemented all these things. it looks much better now the average request time is way lower. It doesn't fluctuate with all the, you know, peak times and stuff. And we basically come in and say like, yeah, you're all good. You just keep doing what you're doing. And you know, maybe. in a year. We'll talk again and see if performance has degraded over time. But, I think it works very well when you do it recurringly and you keep it as like one of your business goals to keep performance in check and you don't let it slip, over time. So yeah, either way, I think we're happy to implement for, for our clients or have the them do it themselves. I think it's in everybody's best interest to. Learn a little bit more about performance and some of these key concepts that Nate has been talking about for years.

Drew 13:16

Do you, do you have any recommendations for listeners in general or people who are using the tune report of, of resources to go to, to learn more about Ruby and rails application performance?

Ernesto 13:28

Yeah. I really like the complete guide to rail's performance. It's not free, but you know, in the grand scheme of things, if you're a manager, just go buy it to for your engineering team. If you are just trying to learn more about rail's performance, you know, it's not that big of an investment to just buy it. it's basically Nate's, book, you can read it and you can apply it. The next week when you finish reading the book, the other thing that's super interesting. I don't know if you're there, but, Nate's slack team is super interesting. I think if you buy the book plus the, I don't know how he has it set up right now, but I remember back in the day it was like, yeah, just pay a little more to get access to the slack community for the book. I joined it about three years ago and it's been super helpful just to see case studies. People will share like, oh, I made this tweak and then I see this performance change. Um, you know, I started using J Mallek with psychic. And they show the difference between like the performance, like before and after. And you're like, oh, shoot. Like, this is something that I could just go and implement with a new built pack in Heroku. And. It would look like this for my application too. So anyway, yeah, just having like a slack community and the book, uh, are very, very important for anybody who's interested in performance. So, um, that would be like my, my recommendation.

Drew 14:58

Yeah, I, I have the book. It's fantastic. And I have, um, I'm in the slack channel Def definitely a lurker, not posting anything, but I agree. Both, both things are awesome and a wealth of knowledge. Is there a minimum rails version that you want people to be on for tune or is it like, yeah, if you are on 4.2, we're gonna recommend we do an upgrade for you, but we'll also do a tune for you.

Ernesto 15:23

Um, not really no, that the version is not an issue. of course, yeah. We'll, we'll recommend like if they're on rails two, three, uh, Hey, you should probably upgrade to rails seven or you should start using rails LTS. some people are running, really old versions in production and they don't even use the rails LTS product. Um, so. Yeah, upgrade. We're happy to help, but you know, if you don't want to do it, we'll still do a tumor report for.

Drew 15:54

Okay, that's awesome. Um, changing gears slightly to a slightly more upgrade oriented, topic. So your fast Ruby's basic business is coming in and doing rails upgrades for companies, but you guys also have a wealth of knowledge on doing upgrades in the form of your ebook and the blog and Conference workshops and everything it's. So how do you find it to balance out where your company's main product is performing this upgrade, but you simultaneously are in many ways for free teaching people, how to do the thing your company gets paid to do. How does that end up working out? Like how do you strike the balance? There is it just you're banking on engineering teams, not having the time to do the upgrade themselves or. Like, uh, what's I appreciate I've used fast Ruby's blog, like crazy in every upgrade I've done and the eBooks. Awesome. But just curious how, how that works in the business model.

Ernesto 17:43

Yeah. Uh, oh, that's a great question. I, I love it. And I, I have to be honest, you know, and transparent, like doing an upgrade with us. It is very expensive and usually. There are only a few countries in the world that can afford our services. Um, and our projects start at, um,$50,000. So I know that there are many teams in all over the world that cannot afford our services. So that's why we're happy to share. Yeah, the complete guy to upgrade, uh, rails. Uh, that's the ebook. We share some tips in our newsletter too, and we try to. Do you know, the, their classic formula of sharing our recipes, because if you have the time and you just need someone to guide you in the upgrade, great, you can do it yourself. Uh, you grab our guides, uh, you grab our advice and techniques and you just go and you do it yourself. Um, You know, I'm, I'm from Argentina and it is a little sad to say that no company from Argentina could hire us to do the upgrade for them, cuz it would be super expensive. And the good news is like with all the formulas and all the content that we put out, someone could just grab that and do the upgrade themselves. They can set up dual booting and gradually start doing it themselves. Um, So I think the way that it works is like, if you don't have the time and you have the budget to do the upgrade with us, you, you know, you reach out to us, we talk and we do the upgrade for you. No problem. But if you don't have the budget, then maybe you have the time to do the upgrade yourself. And at the end of the day, we want people to, to grab our, our techniques or grab our, our ideas and go and, and implement themselves. like the whole thing about the dual booting, technique is like, it's something that we do, but also like other companies that do upgrades to, and it's in my to-do list is like, Just submit a poor request for the rail guides to explain how the technique works and the tools that people could use. And it's been in my to-do list for. I wanna say like four years but at some point I wanna take the time to submit the poor request and say here, upgrading rails, how do you do it? Okay. Set up dual booting. Cool. How do I do that? Well, you can use two gyms or more probably there's next rails, which we currently maintain. And then there is boot boot that, you know, does basically the same thing, but with a different way. So. If you go to the guides in the near future, or like people to just see. Upgrading should be easy, but if it's not easy, you should set up dual booting and you can use this to set up your CI to run two jobs. And you can set this up in your development environment to quickly debug between versions, because you will find weird behaviors with callbacks, from rails between versions. So dual booting will help you with that. And I think, I don't know if that answers your questions, but the more we share our recipes, the better they get and the better they get, the easier it gets for us to upgrade our client's applications too. So it's kind of like, um, virtuous cycle, I guess.

Drew 21:29

right. No, I, I agree with everything you just said, teaching people how to do something like that, that ends. Being extremely helpful for the whole ecosystem. Um, and I will say though, even though 50,000 sounds like a lot of money. I mean, there are teams out there doing internal app upgrades of two or three developers working on a year to get an app upgraded. So like when you look at it that way, like how much are you paying those, that team of developers who are now not working on feature requests and are just doing the upgrade? Versus 50,000. I mean, even a little bit more than that, it, for a lot of companies, it may end up breaking, breaking out, uh, a little bit more in your favor. So

Ernesto 22:13

Yeah.

Drew 22:14

done a lot of upgrades and they are their time consuming, especially if the app is large and old, um,

Ernesto 22:22

Yeah. And these days, those are the applications that we are working on. Like we're talking about like huge monoliths that have been around for 10 plus years. there is a surprising amount of, Public companies out there that are running these rails applications that are really old in production. And, you know, I can't really name names, but there are so many out there and I'm like, wow, this is shocking. And I'm glad that we picked this niche that is. It's so big. Like we, when we started working on it, we were working with a client and then we thought, oh, we could package this up in a nice way that it's, um, a productized service. and then it just blew up. Like we we've been growing so much over the past three years. Like we went from being a team of six to a team of 30 in two years and we're. Yeah, we're excited about the technical debt space. Um, and this is another topic that I'd love to talk to you about is like gradually, we started becoming maintainers of Ruby code quality tools and li gems that, it feels like the code quality. Niche in the Ruby world was cool at some time, but then it was abandoned. And then it's like, okay, fast ruby.io came in and we slowly became maintainers with like a few gems that have been really cool and useful for many years. But now people are like not using them or maybe they're just using code climate. I don't know. I'm just wondering what, what you think about that.

Drew 24:09

I personally love Ruby critic. I think it's great. I run it on apps that I'm getting familiar with. Um, I've run it on apps in the past. I've run it on my current company's app and I won't share any scores cuz it's an old big app. Um, but no, it's, it's awesome. But probably a lot of people using code climate, just cuz it's. It just integrates with GitHub and anytime there's a full request, it just runs everything for you. And there's no real major setup. So one less thing for an engineering team to do. But I mean, I personally love Ruby critic. And for a while, when we were using Jenkins build servers, we had. I think we had it set up to automatically update our like Ruby critic, output our HTML output. Um, we don't have anything now that we've moved to GitHub actions set up yet just cause we don't have anyone to do it yet. but eventually, but I like the gem quite a bit, so I hope that it sticks around and thank you for maintaining it.

Ernesto 26:11

Yeah. And I'm just thankful for whoever wrote it in the first place. Like I, when I found it, I started using it and I was just interested in this concept of like churn, churn versus complexity. Um, you know, like Michael feathers, Sandy Mets have written about this topic. And, I thought it was just fascinating to see like, oh, that's how you find like the most, tortured code, you know, quote marks there. Uh but, um, And then I thought, well, that is, that is really cool. But at the same time, like you, you said about like the test suite and the pre requirements and stuff, it's like, we use. Test coverage and code coverage as well. So how can we like combine like churn and code complexity and test coverage all in one place. And that's how I created this gem called skunk, which is basically extending Ruby critic in a way to say, awesome. There's churn there's complexity, but now there's. Code coverage and test suite. And are your most, uh, complex or your most costly files? Um, covered by tests. And anyway, that's, if anybody's interested in the relationship between like all those three dimensions, they can go and check out skunk and, and see how, how they can use it. Um, the biggest. Question that I'm trying to answer now is like, what is a good, skunk score? And I think that's the, the main question I wanna answer with version 1.0 is saying let's use the grading system that goes from a to F like Rubic critic, like code climate, uh, skunk should do something like that. So that people know like, okay, what is a, a good skunk score? Well, this file is an a, or this file is an F. It's an F because you know, this file keeps changing. Complexity is terrible and there are no tests. So

Drew 28:20

Yeah, that sounds like an F yep. That sounds like an F to me.

Ernesto 28:25

but, uh, anyway, right now, if you run skunk on your application or library, you'll see a number that doesn't mean much. It could be like 0.1, or it could be like a hundred 0.7 and you. What do I do with this? so, anyway, I apologize for that, but it is a version 0.5 right now. So give me a break, please.

Drew 28:50

Yeah, absolutely. No, that's, that's a awesome goal though. And an awesome library, cuz I think those things it's really easy to lose sight of how those three things kind of go hand in hand and how much your code can improve when you're paying attention to those things. Especially high turn files that end up being complex that don't have good test coverage. That is, that is a black hole of danger. Like. You have no backstop to touch that file. And that's, that's a scary thing. Um, so I think, I think the, the goals you have set forth for skunk are awesome. So that sort of sounds like a blocker that you're kind of trying to figure out that grading system, but. Do you have any other blockers or any blockers that you recently had that you solved and wanna share? I mean, you are working on a lot of cool stuff, so I'm sure you've run into some interesting blockers.

Ernesto 29:46

Well, yeah, I think you, you touched a really good point there. Like. Main blocker is like, I don't have time these days. um, and I'm not working that much on clients' applications. I mean the tomb report is one way that I'm, I'm gonna be more involved in like clients' applications, but when it comes to the upgrades these days, I'm not working on any client projects because I can add the most value when I. Kind of switching between projects and helping with specific problems to, to unblock my team. But I think my main blocker is that these days, like I want to release a skunk version 1.0, that means that in order to figure out like what the grading system is gonna be, I need to be in the weeds like improving, uh, Technical debt or, or investing in technical debt for like libraries or application code. Um, and I just don't have the time, these days to go and be like, okay, this file looks like an F. If I switch it slightly, does it become a D or a C or whatever? Um, And I think like that's my main, main blocker. I just wanna touch the code to learn from real life experiences to improve the, the grade for this file. So anyway, if, if you have like some real life rails applications that you think are messy and open source, those would be like a good, starting point for me. We have one that's, called points and we use it to estimate our upgrade projects. and I've definitely run skunk there and I can see it goes from zero to a hundred for like the, the worst to the best. Um, but anyway, it'd be interesting to look at other applications that I'm not that familiar with to try to improve it and improve the skunk score for like the worst files in the project.

Drew 31:48

Right. Right. All right. Well, call out to all the listeners. If you've got a project for Ernesto to look at, definitely hit him up and he'll come in and tell you how terrible your codes are.

Ernesto 31:59

Yeah. Yeah, for sure.

Drew 32:01

And, and help you improve it. uh, so this, I mean, it almost feels like I don't even need to ask the last question because the last question is like, share something new or cool or interesting. And that's all you've been talking about is cool and new and interesting stuff that you've got going on. But is there anything else that you wanted to add and it doesn't have to be coding related. I mean, four weeks of vacation, what'd you do there?

Ernesto 32:30

Yeah, I,

Drew 32:31

jealous by the way, cuz four weeks of vacation sounds amazing.

Ernesto 32:35

Yes. Well, okay. To make it sound less, uh, awesome. I was, uh, two and a half weeks of those was with my kids, uh, traveling to Spain and back. So if, you know, I mean, if you're a parent, you know, that traveling with kids is not really. Super relaxing. It's more like, uh, you're basically a Butler to your kids and, uh, your kids are demanding things all the time. And anyway, it was two and a half weeks of being with my kids and enjoying them for sure, but also, uh, working a lot as a co-parent with my wife. Um, uh, And the last week of my four week vacation was just like me fixing stuff around the house, which is, was good. But I just moved to a new house. that is like a hundred years old. So I was fixing like the technical debt off the house before if you think about it. so yeah, being. An owner to a house is, is challenging. Interesting. And I don't know, I'm only now, like after two months of like moving in, I'm finally enjoying my, my new house, my new old house. but, uh, no, I think, uh, in terms of like cool and interesting things, um, I don't know. I feel like I'd love to talk about this. One thing that we, we try to do at the company is to hire junior developers that are also remote developers. And I think like we talked about this in a previous conference, uh, just you and I about like the challenge that we as remote companies, Just for context, we've been remote even before COVID like before COVID we were remote and it was always like a scary thing to hire a junior developer, and train them remotely and like find the time and the resources to be there for them so that they can become, you know, so software engineers and then senior and all that. So. I don't know, I guess, like that's something that I would love to talk to you about and see how you guys are doing. I'm not sure if you, you have junior engineers that are remote right now, but that's something that we do and. We try to do one junior engineer at a time. And once they move on to the next level, we open up the position again. Uh, and the three junior engineers that have been with us have been great and they are now, you know, two, our software engineers, and there's a third one, that's a junior engineer. Um, but anyway, I'm just wondering if you've had to deal with that. And, and how, what are things that have worked for you guys and within three.

Drew 35:36

Yeah. I mean, we definitely deal with the remote. Challenges, but, and I, there's a few of us, few of the more senior engineers on the team have been like, kind of brainstorming and thinking about how we can make a better push to bring in junior engineers and not just be looking for someone who's more mid or senior and has experience coming in. But we're, we're not at a spot where we have. The time and resources to devote. Like, I feel like we'd be doing them a disservice currently. Um, hopefully that'll change soon. I know that I've heard a lot about this topic recently in the Ruby community, which is awesome. Like there's definitely a huge push for being better at mentoring juniors, hiring juniors, getting juniors up to the level where fine. If you're a company that is only hiring mids. The community has done the work to get this person up. Um, like Andy Kroll has the first Ruby friends going on where you're gonna get a mentor and a mentee paired together. And there's a couple of other companies that are doing a good push. Um, Andrew Mason and Julie just started, uh, the Ruby for all podcasts. That's specifically targeted to juniors, which is great. Um, and is also an awesome podcast. If you haven't listened, definitely go listen. Just a. Podcast, even if you're not a junior, um, the one thing, and again, we are not hiring juniors. So take it with a grain of salt. The one thing that I've found that I think is extremely helpful when bringing people into. a new role, uh, especially a new role, a new code base, a new company, especially if they haven't worked remotely before is actually hiring more than one at a time. That way they start together and they have a buddy that they can kind of go to and be like, Hey, I'm working on getting my head wrapped around this part of the code base. And. Have you gotten a chance to like touch it yet? Do you understand it? Like, Hey, can we pair on this pro and, and it's just, it's another junior or it's another person who is equally as lost as you Um, hopefully, you know, no one's being that lost, but there's always that degree of like, I am overwhelmed. This is a 13 year old code base and it's way bigger than anything I've ever touched before. And I feel. A little overwhelmed. And my mentor at my company is great, but I need someone who speaks my language, having that other, Hey, you started the day before me or the day after me or the same day as me. Like you are in the shit. Like I am. I think that helps. I I've, I've noticed it in when we are hiring people. I feel like the people who come in as a group end up doing better than, or not better, just have an easier transition time. Then, if they came in solo and just were like, you would think it's the opposite. Cause it's like, oh, if you come in solo, you get all that like one on one dedicated time. But I think it actually works out more. Like if you come in in pairs or groups, you still get all that one on one time, plus a buddy. And I think that buddy system helps out so much, So, yeah, I don't know how much that helps you because we're not in this, in the position that you're in, where we're bringing in juniors. But, there are a lot of people out there. So if you're listening to this and you are actively hiring juniors or actively involved in helping. Level up juniors, please reach out to me and, Ernesto and give us your thoughts, cuz it's something that, uh, myself, one of the other seniors on the team and a few of our ETLs have been very like, Hey, we wanna, we wanna bring in juniors cause there's a lot of them and they're awesome people and have the potential to be amazing engineers. We just don't have. I don't know if we don't have the time or the resources, or if it's, we just don't understand exactly what they need enough to understand what kind of time and resources we need to dedicate them to. So that's where we are.

Ernesto 39:48

no. And that's a, a great point. Like, um, I think. To consider like, do you have the infrastructure to set up, or to onboard a junior developer and set them up for success? Right. I feel like over the years, we, you know, we are consulting shops, so we are constantly looking for talent to, to hire and, Yeah. It's the, the buddy system is one of the things that I would say it works very well. Like we don't hire two junior engineers at a time, but when we do hire one. We hire one at a time. And when we do, we set them up with an onboarding buddy and someone that they can reach out to that will be able to answer any questions that they have, even if they're like totally lost. another thing that we do at Olas is we like to. Have a bench of senior engineers that are available to pair with the juniors. granted right now we're still pretty small. So there's one person on the bench that can do that and pair with the junior engineers when they need to. but anyway, that that's something else that helps, like if you're gonna have. One or more junior engineers like have senior people who are available and like, the message is clear. Like, Hey, this person is available and they're not assigned to any client projects because by design, we save them up to pair with other engineers can be senior or can be junior, you know? Um, so if anybody needs help at UL labs, what we do is like we have the pair channel. And anybody can be like, Hey, I'm available to pair now, if anybody needs help or, Hey, I'm stuck in this problem. Can anybody pair with me right now? And there's usually one person that will have the time to do that. but yeah, I think like we've learned a lot over the past few years, but we're still trying to get better. So by no means, I mean that, we're awesome at onboarding and. You know, training junior engineers, but I like the challenge and I like the idea of always having one junior engineer to push us to be better for them and to be a better team, to, to support them.

Drew 42:12

Yeah, I really dig that idea of having that bench. And it's almost like I am the pairing on call person. Like I'm not working on anything, but being available to pair. I think that's an awesome idea. I think that would be really helpful, especially when bringing on juniors is like, Hey, you're not gonna bother this person. There's no, there you're not interrupting their work. You're not taking them away from some client deadline thing that they have. Their whole job right now is to help you. So pair with them, I think pairings awesome at all levels. So, you know, always having someone to pair is amazing, but for juniors, at least I remember when I was a junior, like being like, I don't wanna bother anybody. I don't want to like, come in and. Be like, Hey, I have so many dumb questions and you're so busy, but could you like spare five minute? Like I hated doing that. And now that I'm, you know, the staff engineer at my company. I'm like, oh, please don't ever feel like that. Like, please interrupt me and take me away from this crap that I'm doing. I would rather pair with you and help you level up. I get so much more joy out of that than releasing something. and I think a lot of, at least a lot of our ETLs are the same way. Like, no, you're never a bother. You should ping us all the time. But I think having it set up like you're describing where it's like that bench, that on call set up, it's like it takes any. Internal pressure away from like, nah, I'm gonna bother this person. You're really not like, this is what they're dedicated to right now is pairing with you. So I think that's, I think I might pitch that idea at work. I'm stealing it. Ernesto. Thank you.

Ernesto 43:53

Yes, please take this idea, steal it. Um, in any company, I think it's a, a good idea to have a, a bench or either a staff engineers or senior engineers that are, that also have the right personality. You know, sometimes you want people who are. very helpful, very open, very, ready to jump in and try to understand where, where things are, where the code is, even if they don't know anything about the project. we just have this really great staff engineer in our bench right now that, uh, he's always happy to, to help and jump in. And even if he doesn't know the code, he can. Pair with the, with the junior or the senior engineer and share their mental process because sometimes it's all about that. It's like about, oh, wow. Yeah. I have no idea what this library does, but I see what you're trying to do. And I see that the library should be doing that, but it's not. So let's figure it out together. sometimes, engineers, even with all the experience in the world are, are not that great at, at helping other engineers. So that's one thing that I would recommend for anybody who wants to make the jump from like senior to staff, at least in, in our company is to not just work on your technical skills, but also in your, your communication coaching and, and teaching, uh, skills. So you can help other engineers like be comfortable with you. Uh, and, and one last thing I wanna say about this thing is like, it is so normal what you said, like this whole thing of like being junior or being like less experienced and being like, oh, I don't wanna bother people with my questions. And you're, you're really not bothering people. Or you wanna be in a company where that feeling is, is. It's not a, a problem, you know, you wanna, you wanna be okay. Asking questions and even if you think that it's a silly question, you can, we have, a learning channel in our slack, account and anybody can just go there and post, like something that they're learning or something that they need to learn and, and ask for advice. Uh, there. And if you're a senior or, or at a staff level or a CTO level, what I would recommend is like to be as vulnerable as possible in open slack channels, you know, and being like, Hey, I'm trying to figure this out. I have no idea what this library does. and maybe start like, a slack message that becomes a threat and where you kind of like go sharing and asking for, for advice, asking for questions. I think the worst thing you can do as a senior person is to just DM other people and not share your struggles, with the rest of the company. because you know, we, you can be the most senior person and you're still gonna struggle to find the answer for. Complicated problem. So anyway, just be vulnerable and share your, your process, in public channels. I would

Drew 47:02

Yeah, I agree.

Ernesto 47:04

that.

Drew 47:05

I completely agree with everything you just said. Um, it's very helpful when others can see like, oh, you're this level, but you still struggle or you still have questions or you still want someone to pair with you and, and, and get help on questions and help get others to get you unstuck. And I think for anyone who's like, oh, I can. Pair with this person, cuz they're more senior than I am and I'm only a junior or a mid, like I can't bring anything to the table. That's also completely untrue. Like the amount of times that I've been, like I gotta pair with someone on this and just catching them up to speed on the problem I'm working on. and saying it out loud and trying to explain it to someone I'm like, oh, I've freaking figured it out. I got it. Yep. Sorry. for I'm. I'm good. Now it was just the rubber duck. Uh, the rubber duck phenomenon that I needed was just another person here to say like, well, what's that doing? And then I explain it and I. Ah, I figured it out. Got it. So you can be a mentor at any level. Like sometimes the person only needs just another set of eyeballs, especially if they've been working on something for a while. So all good stuff. Definitely. I love how much I've seen in the Ruby community, getting juniors leveled up, like it felt like we were all talking about it for a while, or it was like, yeah, we need to do something. We need to do something. And then all of a sudden it was like, yeah, we're gonna do something like we have the mentorship project coming out. Your company does juniors. Other companies are starting to do juniors. We're working on it. And my company, like we are hiring. And we are really trying to work hard on setting up a system where we can hire juniors. We can, we can do a, a really competent junior right now. Who's like capable of doing stuff on their own, but we wanna set it up that we can almost take like a boot camp grad and bring them in and get them up to speed. And it's a lot of work, but I think it's really worth it. And I love seeing how much the C. As a whole, not just companies, but as a whole is like opening up resources. We've got new podcasts, mentor, program, everything coming out. And I think that is a huge thing for the community and our future. So I'm super pumped to see it.

Ernesto 49:20

Yeah. Yeah. And I love that. Julie and Andrew, started a podcast about this, this stopping in particular. and I think if we wanna bring more people to the community, this needs to be even better, you know, like we need to, to have more, more resources and make it easier to, for people to get into the community.

Drew 49:38

Yep. I completely agree while we are coming up on time. I know that you are a very busy man, so I do not want to take up too much more of your time, but is there anything else that you wanted to talk about before we start wrapping up?

Ernesto 49:49

Uh, no, I think, uh, if anybody's interested in any of the Ruby jams that I brought up, in the, the episode, you can. Just go to github.com/fast Ruby, and you'll see a bunch of, code quality gems in there. I think the easiest way to help us, with a contribution is to, you know, pick the one that you like the most try to set up the project locally and see if the test suite runs that'd be like a quick and easy way to, to make a contribution and say, Yeah. You know, you missed this in the rate, me or something. Um, if you wanna help with skunk and kind of explore the relationship between chair and complexity and code coverage, um, just go and run skunk in one of your rails apps or one of your Ruby gems. Uh, that'd be super helpful to report back if it worked, if it, um, didn't work any anyway, I would like to know, If you're interested in working in technical debt projects, we are always looking for, talented developers. right now the junior engineer position is taken. But, if you follow us on LinkedIn or Twitter, we will let you know when we open up the position. Once again, hopefully, before the end of the. And yeah. If you're struggling with performance in your rattles application or Ruby application, feel free to check out fast ruby.io/tune. Uh, that's our. Audit for performance optimization. And yeah, if, if you, if anything that I talked about here is interesting. Feel free to follow me on, on Twitter. Uh, I'm at ETAC worker there, and I usually complain about stuff. Sometimes. It's about code some, sometimes it's about flying and sometimes it's about meeting up randomly drew in the airport.

Drew 51:46

Yeah.

Ernesto 51:47

Because I had to switch flights midway to Philly. Um,

Drew 51:52

Yeah. Go direct, man.

Ernesto 51:53

some other day.

Drew 51:56

uh, yeah, no.

Ernesto 51:58

between Portland and Philly. We learned.

Drew 52:01

Found that out the hard way. Uh, actually, so you took my, my wrap up question. I was gonna ask. Where people can find you on the internet you got that covered, everything that you just said will have in the show notes. So one last thing before we wrap, will I see you at Ruby comp, either in Houston or in, Rhode Island?

Ernesto 52:20

I think I'm I'm I, if I go to any of those events, I think it's gonna be the Ruby com mini, uh, because of. Political, um, issues. Uh,

Drew 52:35

that's the whole point of mini, so,

Ernesto 52:37

Yeah. And I also, I really like, Gemma, who I know is involved in Ruby comp mini, and also, yeah, to be honest, like I prefer smaller conferences other than big conferences. So, yeah, I'm thinking about submitting a, a talk for Ru K mini. I don't know if I still have time, but hopefully I will have the time, but even if I don't get accepted, I'm probably gonna be there. Um, at Ruby K mini, what about you? Which one are you planning to go to?

Drew 53:09

So I am definitely going to mini I'm submitting a talk also, um, for, for what it's worth. It's only a four hour train ride. So, you know, no planes, uh, to get to Ruby comp mini. So thank you again, Ernesto for coming on the show. It was awesome to get to talk to you. It's funny that you live in the same basic area as me and I see you less than I see people who live states away, but it was awesome that you came on the show. I was, I'm glad we got to talk.

Ernesto 53:40

Yeah, it was great to be here. And I, I, I think we should definitely make plans to hang out in real life in Philly, which I don't think it's ever happened. Like we hang out in Vegas and Portland, but never

Drew 53:56

we've seen each other a lot. Just never in Phil. Well, hopefully we'll get maybe a Philly RB in person soon. Uh, we do have, we do have people coming from other countries to Philly RB now. So maybe not, cuz I think half of the people that are showing up to Philly RRB are not actually in Philly.

Ernesto 54:14

Yeah.

Drew 54:15

at least four of us in Philly.

Ernesto 54:18

Yeah, I, forgot to mention that in the episode. So here it is. I'm also, the organizer of Philly RB. So if in you're in the Philly area and wanna meet up, Come to the next one. Hopefully in September, we'll have a meet up, but, and if you're interested in speaking at, at Philly RRB, either remotely or, you know, on site, feel free to DM me on Twitter and we'll, we'll find some, we'll figure something out.

Drew 54:46

Yeah, and right now it's not in person, it's all virtual. So you don't actually even need to be in Philly. We have a couple of other countries and cities being represented, so feel free to drop by and just hang out with other Rubus so hope to see everyone there and hope to see you too. it will be. I think a week after this episode, airs will be the next one. So people will have a little bit of time to jump on, but I will include the link to sign up, um, in the show notes too. So awesome, man. Well, thanks again for coming on. This was great. We'll do it again soon and I'll see you at Philly B.

Ernesto 55:23

See you there. Thank you.

Drew 55:24

See man.