Rooftop Ruby Podcast

27: Hiring Juniors with Ryan Bigg

Collin Donnell Episode 27

Ryan Bigg talks about hiring juniors, writing, and company culture.

Follow us on Mastodon:

Show art created by JD Davis.

Collin:

Hello, everyone. Once again, this is three weeks in a row. Very special guest. today we have Ryan Big. Ryan is an author, a lead engineer using Ruby, React, and TypeScript. And he's also written some really interesting posts and given some interesting talks. So we're just, Gonna talk about all of those things. Ryan, welcome to the show.

Ryan:

Thanks for having me.

Collin:

And of course, I'm joined by Joel, as always. Hello, Joel. So, I thought a good place, cause you've written some things. Joel, uh, was showing us that he has one of your books, so I'm sure he'll have some things to ask about it. Uh, which is, uh, your, your writing. Can you tell us about the things you've written and what that experience has been?

Ryan:

Yeah, uh, at the end of, uh, well, I think it's the start of 2010, I moved to Sydney from Brisbane. I moved around the country a bit. Um, and I, I was there, I was like, I'm going to make new friends. And then basically that same month, Manning got in touch with me and said, would you like to write a book? And making friends and writing a book, these two things are incompatible. Um, so I thought I'd sign up, I'd sign up to start writing this book. And I asked them what the book was. They wanted me to write a book called Rails in Action. It used to be called MIRB in Action, but it never got published. MIRB was merging into Rails at the time. And so I started writing Rails 3 in Action. And that project took six to seven months to complete. And I had to write it in a format called DocBook, which is all XML. And that was an experience in itself as well.

Collin:

So, okay, describe DocBook to me now, because I know that's not, I know it's not extremely relevant to the content, but uh, so you have to write the book in XML, or is there like a tool you use, or what does that look like?

Ryan:

Yeah, it's, uh, writing handcrafted XML, artisanal XML. And, uh, so you start a paragraph by writing, I think it's open bracket para, uh, end bracket. Um, and then you've got your listing blocks, which I think were three or four tags embedded in each other. So you've got the title of the listing block and you've got the code block underneath that. And then, yeah, it's all, all XML. The great thing about the tooling there is that when you ran the generator or you ran a, um, uh, like a linter over it, it would just tell you that there was an error at the end of the document because you didn't close a tag somewhere, you know, 400 lines up. Um, so yeah, you'd have to go through and kind of cut out half of the chapter and hopefully your clipboard remembered it. And then try and diff it, so I got very good at remembering to commit my changes before doing the linting side of things. Uh, otherwise I ended up, uh, I think at one stage I lost three quarters of a chapter through that process and had to rewrite it.

Collin:

Yeah, that sounds like something there should be an app for. Um, so, so you wrote the Rails book, another, uh, active Rails. You also wrote this, uh, multi tenancy in Rails. That sounds interesting. Maintainable Rails. And also there's an Elixir book in here. Do you want to talk about any of those or the experience of those?

Ryan:

Yeah, I was writing with Manning and the XML really annoyed me and somebody put me onto this um, writing tool called LeanPub, or the publishing company called LeanPub, L E A L E A N P U B and um, they write in Markdown and I was like, what, I can write books without XML? I can write without having to use Word? Because Word you can't commit into a Git repository and have clean diffs on. That's kind of what I was looking for. And so I started writing, um, multi tenancy with Rails, which is a book about creating a multi tenanted Rails application where you have accounts and then you have subdomains. And anytime you access a subdomain, you can then, um, that's going to scope all your queries to a particular. series of, uh, accounts, so account specific queries. I think it was, um, I'm trying to remember the, it was books and chapters, I think for that one. I'm trying to keep it on, on brand there, but yeah. And then I started writing, um, much later after that, I started writing a book called the Toe Robot because there was a bunch of companies in Melbourne. Using the Toy Robot Coding Challenge. It's 250 words of like, you've got a robot on a 5x5 grid. It can move up, down, left and right. And given a set of instructions, you have to tell us how the robot moves and where it ends up on the grid. And I was like, this is such a contrived coding test. It's not really testing like, these companies are real estate companies or e commerce companies. Had nothing to do with toy robots and yet their coding tests were around toy robots. But I thought, it's a really good topic for a book because it's a very gentle introduction to Ruby. You have an array, which is the grid, and then you move the toy robot along the grid coordinates. And so I decided to write that book, and right after that, I was also learning about Elixir, well, this is pretty decent for Ruby, it's got to be good for Elixir as well. So yeah, I wrote, I wrote, just keep writing books all the time. It's a really enjoyable thing to get the knowledge out of my brain and into other people's hands.

Collin:

Yeah, that's, that's great. Um, so, so you sent me a couple of posts that you said might be good to talk about, and the first one wasn't actually a post. It was a talk at, uh, RubyConf Australia, and it was about hiring junior developers. And you start off with being like, Hey, in five years, somebody's gonna be here. You don't know who they are yet, but they're gonna... They're, they're going to rule, they're going to be the coolest. Uh, but you have to hire them now. Uh, so can, can you go into that at all? Maybe we can just talk about that.

Ryan:

yeah, um, I started that talk, and that was a bit of a contrived situation, but I've actually experienced it a few times now. Not just the juniors that I've taught, but the juniors that other people have taught as well. Um, and I've just been impressed with like the rate at which they learn and grow. Um, just the way they proceed from, you know, How do I generate a controller? What's an action? How do I make a view? You know, this form isn't posting correctly. And then five years from then, they're like giving leadership level talks at conferences. And you're like, well, where did you have time to learn this stuff? So, yeah, um, one of my, one of my big passions besides writing is teaching juniors and watching them learn and grow and evolve as, as developers. So when I have been hiring people, seeing how they start out as people who may have a decent grip of Ruby, but not a good idea of how to do Rails stuff and watching them grow and evolve past that point. It's really interesting and really thrilling to me to see. Yeah,

Collin:

So then one of the questions I had there is you mentioned in the talk, like, you know, everyone is saying like, we're hiring senior Rails developers or whatever. Right. So how do you get buy in from the place that you're working to be like, we. We need to create senior Rails developers, and we only do that by hiring junior ones. So, like, how do, how do you sell

Ryan:

it's a huge supply and demand issue, isn't it? Um, every company around the world experiences it. We're hiring seniors, hiring seniors, hiring seniors. You pay exorbitant rates for them and you spend months and months trying to recruit them and never, like very rarely, somebody just walks in the door and says, I'm looking for a job. And given the, the economical situation at the moment, things are a little bit different, but let's backtrack a little bit. Um, I was working for a company called CultureRamp around 2016. I was hired there as a senior developer. And one day my mentor, Joe, came up to me and said, look, we're looking to hire, um, I was telling her we need to, we need to be hiring more. And she's like, well, why don't you start a program or start an initiative here? And I'm like, do I have permission to do that? And she says, yeah. Give me a pitch of what it looks like, how many people you're looking to hire, how long the program's going to run for, what you expect to get out of it, and I'll put it up to leadership. And leadership, the CTOs and CEOs were on board with it. And so we put out an ad saying we're hiring junior developers, we're going to run a junior engineering program, it's going to last six months, and we're going to hire five people. We ended up hiring, we ended up interviewing, uh, well, uh, we got 109 resumes, I think it was, in the first program. We ended up conducting over 40 interviews, or 50 interviews, something like that, some astronomical number. We gave them a coding test, which, um, just because they're juniors, I needed to assess their coding quality, um, and make sure that it was, you know, up to snuff for the junior program. There wasn't a particularly high bar for that, it was more, have you done a basic Ruby tutorial to understand how to find methods in classes and run some tests and that sort of thing. We interviewed them and we ended up hiring six people out of that, that cohort. And then the hard part started where I was like, well, what do I teach them? How do I convince a group of six people to all learn the same thing at the same time? Because different people learn different things at different rates. And so you have to kind of give directional learning on that. The way that program ran is that we started off by teaching Ruby and then moved off into Rails very soon after that and kind of attempted to do model applications around how our main monolithic application was structured at the time. So any sort of problems or issues that came up in the monolithic application we try and model in the classroom setting where the risks are massively decreased because you're not shipping production code to real users. You're instead just doing it in a classroom sort of setting. So we ended up catching up. I think it was, uh, this is a long time ago now. But I think it was like, uh, for the first couple of weeks we were in that classroom setting and then they would be released into their teams. And then every week they would come back to me, uh, and then we changed it to one week with me and two weeks in their team. So there'd be a complete week with me just doing any sort of learning, asking questions and um, kind of research mode. And then they'd go off into their teams for two weeks and then do, do actual real live production, um, coding challenges. Now, I think that's a better approach to bootcamps because bootcamps are, there's no production code written at all. There's no risk involved. And I think that risk aspect is the best way to learn because you learn to be cautious and you learn to be, uh, you learn to work on real problems that matter to the business. Now, in a classroom setting, you don't get that risk, but you do get, you do get the kind of freedom to experiment and learn. So I think mixing both of those models together really works well.

Collin:

So, if they weren't coming out of, uh, like, boot camps or something, where were you finding these folks that had already learned a little bit of

Ryan:

They were,

Collin:

what was their previous

Ryan:

man, this is, this is a pretty diverse topic. So we did have some that came out at bootcamp. We had one who was a nurse, um, previously a nurse. And self taught programmer. And she was one of our very first interviews. And I was like, what's your background in programming? She said, Oh, I did this, this course online and I've just kind of, um, experimented around with it. And I kind of, it just fits my brain. I think it was her exact words. And I was like, so you've got four months Ruby experience, but you're coding at the level of like somebody who's got two years experience. What's the, what's the secret? She's like, it just fits my brain. So that was really fun to watch. But then we've had people come out of coding bootcamps. Um, somebody did the Harvard CS50, uh, I think it's CS50x course. Um, yeah, just a whole mismatch of people, mis Mix match of people.

Collin:

Mish, mishmash.

Ryan:

looking for. Thank you.

Collin:

And, so, what would you say, like, So it sounds very structured, which is cool. I wish I maybe would have had something like that early on. I feel like all of my early experiences were basically the same as my later experiences, which is they were like, here's the repo, good luck. So you had a couple of months here where you're doing this very structured environment, like. What were the, I don't know, what were the hangups people ran into early on? How did you help them get over it? I think people learn so much in those first few months, right? Like, those first, like, couple of years are so big. So, like, they must have just been progressing really

Ryan:

Yeah. Yeah, they were. Um, one thing I didn't mention actually at the, at that time as well is that we had three people who were considered juniors at the company, but not part of the, the, that hiring process. So we had six. People who we hired and three other juniors that formed that first cohort actually of nine people. Um, so you're talking there about like the, I guess the expendability of it and how you kind of track, um, track that sort of thing and make sure people are working fine. We had, um, we had somebody come to us from a consulting group. This is one of the initial juniors, not people we hired. And they sent her out on a client expedition kind of, uh, discovery thing by herself as a junior developer to, to collect requirements. And that completely obliterated her trust in herself and her own abilities. And it took months of recovering that. Once that work was finished, like, that took, like, months of... Of saying, it's okay, we trust you to do the right thing. Her, her rate of learning and picking things up. One day I was teaching her about, um, Git checkout. And she's like, Oh, I also learned about Git rebase. And then she just like Git rebase interactively. And like, this came out of nowhere. And she's like, yeah, I just read ahead in the Git book and just learn this stuff and picked it up. So it's like that confident side of things. We had another developer who was like. Constantly, maybe not constantly, 95 percent of the time worried like, if I fuck up, I'm going to get fired. And I'm like, there's, there's so many safety, so many safety mechanisms in place. That if you do fuck up, we will prevent it before it reaches production, most likely. And if it happens to reach production, we've got other developers who will step in and be like, we'll fix it, no problem. It'll go away and we'll, we'll know not to make the mistake again. But you can't learn without making mistakes. And I try to emphasize that a lot. And I also emphasize the fact that if we were going to fire you, we would telegraph it way in advance. Like we're talking like a month at least, like we'll give you notice and we'll say like when you're, you're not performing. But we never had to have that conversation with our juniors because they were, they were in such an incredibly supportive environment thanks to the company and the culture and its values. Yeah,

Collin:

I mean, that's, that's great. I think having a supportive environment for like any level of developer is really important, you know?

Joel:

I'm really interested in the fact that you had a classroom setting with these developers, because I don't think I've heard of that before. I've heard a lot of people talking about how, you know, you should hire junior developers, um, but like, I've never heard stories about people setting up a classroom in a company and being like, I'm guessing you dedicated specific amounts of time to like just learning and not even learning on the job?

Ryan:

Yeah, that's right. So they were, um, when we had that week on cadence and then the two weeks off that week on, we were stuck in a room almost, um, the whole time. And we had a whiteboard, and a projector screen, and we could write code on that. So we did stuff like the Toe Robot exercise, we did some pair programming

Joel:

Mm

Ryan:

We did stuff where you would rotate around, um, somebody would be driving and everyone else would be asking to, um, we'll be telling them what to do. And so that would be like five minutes of writing on the code and then you'd rotate in, um, kind of around Robin style to complete a coding exercise. So yeah, that was kind of fun for, for that time. But then once we finished the program, they were released into their teams and. Um, I still caught up with them on a weekly basis. I blocked out an hour in my calendar and that was completely uninterruptible an hour for each person as long as they needed it for, and when they said, look, I'm feeling confident and capable, then we cleared that hour and anytime they wanted to chat to me, they could just reach out and slack and say, Hey, I, I need some time to chat about this thing or that thing, and we would catch up.

Joel:

So you were running this, this program, sounds like, and, and like, I'm guessing you were doing the, the classes and the, uh, you were there to help people out afterwards. What would your advice be to, uh, maybe someone who wants to set something like this up at their company?

Ryan:

It's not as hard as you think it is going to be, and it is incredibly rewarding. Um, it can seem astronomically difficult to set up a whole curriculum, but you don't need to set up a whole curriculum. Even just an outline of what you plan on teaching, and getting the feedback from the students week in week out to determine what you're going to teach next is incredibly vital to ensuring a successful program. I wasn't the only one doing the teaching, I got a couple of guest, guest lecturers to come in. So one guy came in and gave a lecture on React when I was not that. professional about it. Um, and he, he blew them away with like, uh, a completely, you know, you change the code in this part of the app or this pane of the window and it changes the, how it looks in this pane. And they're like, why didn't we have this with Ruby? And so the next time I actually ran the program, we started with React and started with that JavaScript and HTML and CSS. So it was really re reactive coding. Whereas with Ruby, you kind of have to run the, the command to see the output. In React, you don't have to do that. It automatically live reloads and compiles.

Collin:

How much of this teaching time, I feel like, how much of this teaching time, uh, and holdups were just around tooling? Because I feel like that's actually kind of the hardest part early on. It's just getting everything working and, you know, you can install something so that you can pull down a new repo. Like, once you've done it a lot of times, it's, you can do it pretty quickly, but I feel like those first few times are, it's a, it's a big project

Ryan:

Yeah, it sure is. Um, we had a couple of projects that were involving setting up different repositories. So it was like, we want to clean down the main monolithic application. Here's go through the Ruby and tell us where it breaks. And so people had different ways of setting it up. Like they had RBM for RVM or CH Ruby, different opinionated ways of setting up Ruby on their own machines. Fortunately, a bunch of the juniors didn't have machines set up. They got them from the companies. And since I was able to set them all up and just run them through a couple of hours of, you know, we need to set up Ruby at this version, we need to set up JavaScript at this version, we need to set up Rails at this version, make sure you can run these, this command, this command, this command. And maybe these other tools are going to be success, uh, going to help you succeed here as well.

Collin:

I assume the hardest part of this then is actually just getting that buy in because you had to go to somebody who was your boss and be like, all right, so we're going to interview like 40 people. And then, I'm going to take two weeks off my real job to go teach them how to be Rails developers. And then, they're going to go to their own teams. And then I'm going to take an hour every week for each one of these to deal with them. Uh, so, I feel like just getting that buy in has got to

Ryan:

Yeah. They lost, they lost a senior engineer to this program. And it cost the company a bunch of money as well, um, to just mentor these people and train them up. Like, it was a huge buy in, um, from the company. The leadership is what really clinched this deal. They believed in the program's success. They believed that it would contribute to the, the value of the company. In some measurable way. And that's how I think we, we managed to make the program successful and be able to run it at least twice.

Collin:

And do you see, now that it's been a few years, do you, do you see any of those people around in the community now? Are

Ryan:

Yeah, they, they have, they don't run away from me when I see them at conferences. So I must've done something right. Um, and I've seen some of them, um, who have now reached the senior level at their company. So they've moved on from CultureAmp and gone off to other companies and now they're mentoring other developers. And I hear stories of like. I've got this junior in my team who I'm mentoring now and I've given them your books and like they said they're really helpful for learning. But I've noticed this typo in the book over here, that sort of stuff.

Collin:

That's amazing. I used to do, um, I used to teach workshops, so like a three day workshop on how to make an iOS app uh, back in several years ago, and it was pretty amazing that I would sometimes see people at a WWDC like three years later, I'd have somebody who like, to me at that point, I'm like, had to be reminded who they were because I'd met them once three years ago, and they're like Yeah, I took your thing, and now I'm an iOS developer, and I've been doing this, and I'm like, it's pretty wild.

Ryan:

like the ripples spread out and you go, well, I've taught this developer who's taught this developer who's taught that developer. Um, I don't think I'm quite up to the fourth level yet. I think it's maybe two or three levels deep at the moment, but it's, it's proceeding and it's, it's really, it brings me so much joy and meaningfulness to my job, I think.

Collin:

That's amazing. It seems like you, you decided what you wanted to, uh, see in the world, and then you became the change that you wanted to see, uh, as they say, so that, that seems great. Sorry, Joel had his thumb up like this, and then it just did the, uh, iOS, uh, Automatic. Um, now, now we're all doing the, the new Mac OS thing where it'll pop up reactions. I like this one where you do like this and it does the confetti. Or as I call it, tiny trash. Um, all right, moving on. Uh, okay. So we wanted to talk about this other post you had too, which was about, um, let me get back to it really quick. It was about, uh, you, you, you have a blog by the way, we'll link to it. And this was about culture and values. And it's talking about, uh, How you switch jobs in thir three times in 13 months, and I think this is experience a lot of people have had in the last couple years, so maybe we can talk about that a

Ryan:

Yeah, that was, that was certainly an experience in itself. Um, at the end of 2019, there was talk at Cultureamp about running a third iteration of this program. And I think I was about two or three weeks into planning this, this project, um, and trying to break it up into smaller modules so people would take a module and learn about a particular thing they were interested in about Ruby or Rails or Elixir at the time. And my manager came to me one day and said, Hey, can we have a talk? And I'm like, that's never good when a manager says, Hey, can we have a talk? That's the shark fin is circling the boat, right? So, um, we went into a meeting room and he said, I've got bad news. The, um, Cultural Ramp has decided not to continue the junior engineering program anymore. We're going to be switching your role back into a senior developer role. And I said, that is incredibly disappointing news. And I was, um, incredibly upset about that, that stuff. I took the rest of the week off. This was a Wednesday, I think. And I took the rest of the week off and just packed it, like. The stress. Cause I was like really invested in the success of this program. I really believed in it. I really cared about the company and its values. And I think like bringing up the next generation of programmers is incredibly vital work and it felt like the rug was being pulled out from underneath me. They said that they were going to run the program and then they said they weren't going to run the program and it just was incompatible, um, to, to my brain, like I couldn't understand why they said they were going to do it. And then they said they're not going to do it.

Collin:

So is that when you left,

Ryan:

Yeah. I, um, they said, you've got two options. You can. Actually, the two options were say on as a senior at the rate we've been paying you for three years or you can take this redundancy package because we're taking, we're essentially making your role, your junior engineering program lead role redundant, redundant. And I said, well, what's the size of the redundancy package? And they told me, and I said, that's a big number. And I had a chat with my wife and she said, well, we're looking to buy a house and that would make a really good base for a deposit for a house. And, um, I said, yep, I'll take the big bag of cash. Thank you very much. And we ended up buying this house that I'm now sitting in. So that's the very short version of that story. Um,

Collin:

Wait, you quit your job and then used the money to buy a house before you

Ryan:

not quite in that order. We were shopping around for a little while before we ended up buying this house. So I quit that job at the end of 2019. And then at the end of 2020, when we passed all the COVID, uh, lockdowns in Melbourne. We decided we'd move out here to country Victoria, so I'm actually 280 ish kilometres west of Melbourne now. I call it Outer Outer Western Melbourne, it's a running gag. And but yeah, this house we were able to buy with that redundancy package, if we didn't have that, we would have been saving for another five, six, seven years, something like that. So it has a silver lining in that particular cloud. Yeah, so at the end of 2019, I was approached by a company called Coder Academy that then was. running a bootcamp in Melbourne. And they were wanting to bring me on as a senior lecturer there, building up their coursework, teaching the next generation of programmers and that sort of thing. And I was very excited by that. And then this little thing called COVID came along. Um, and yeah, yeah, you've heard about it. It's good. Um, and what, uh, happened in Australia is that we ended up closing our borders to all international arrivals. This coding bootcamp, not itself, but its parent organization, depended on a lot of international arrivals, teaching them English and that sort of thing. The company panicked and laid off 236 employees in one go at the start of April, and I happened to be one of the lucky few that got laid off. Um, the previous week, uh, we heard about redundancies were going to be happening at the company. My boss assured me that I was not going to be a part of that group. And then that Friday of that week, I was, uh, given a phone call and told that I will no longer be, uh, working for the company.

Collin:

Yeah, it was... Man, that early COVID couple of months was such a weird time, because it seems like all those companies freaked out as they do, and then fired everybody, and then all these tech companies were like, Oh, we're actually just making a lot of money right now, because people need to, like, buy stuff to work from home, and then they immediately had to start

Ryan:

Yeah.

Collin:

people. Um,

Ryan:

Yeah. Yeah. I mean, Shopify, what tripled their staff or something ridiculous like that in 2020. Um, yeah, it's incredibly, um, strange times to watch this, this massive growth in the tech sector. So yeah, after, after Coder Academy, I was looking for a, just a senior job somewhere. I ended up joining a company called Covidence, which does, um, scientific review, helping out people doing scientific reviews of papers and that sort of thing. And I worked there for seven months. And I, uh, during that time we were house hunting and we found this house in Warrnambool and I told my boss we're moving out, um, uh, we're moving out to Warrnambool. And his boss wanted everyone to be working out of an office in Melbourne after the lockdown's finished. So this was in November, December 2020. After the Melbourne lockdowns had finished, they wanted everyone. Yeah, he was just super quick on it. Um, we weren't quite through the last of the lockdowns, but he said as soon as we are through this, we'll get everyone back in the office working together. I said the commute's four hours one way. I'm probably not going to make it. I'm happy to work remote and they weren't happy to work remote. And at the same time, the relationship there was kind of rocky. I cared a lot about producing quality work and what I cared about and what my manager and my project manager cared about. sometimes weren't the same thing and we butted heads a lot, let's be honest. So we decided, like, my boss called me and said, don't come in on Monday, essentially. And I lost my job that way. Um,

Collin:

Yeah, sorry, I feel like I've now made you, because you wrote about it in this blog post, I've now like made you go into

Ryan:

it's okay. I'd rather, I'd rather be open and honest about this stuff. That's, that's the radical candle side of things that I try and try and live by.

Collin:

yeah. So, so the title of the post is Culture and Values. So I guess the question

Ryan:

Yeah. Yep. Yep. So I, I cared a lot about CultureRamp's values. I cared about a lot about Coder Academy's Covenants values. And then, um, trying to remember the exact time. So at that time, like I'd been let go from CultureAmp and it was, was, uh, I felt at the time, like it was a betrayal. And I've talked to a lot of people. I've talked to therapists about this sort of thing. It's not, not the people betraying you. It's the company betraying you and the company, while it's made up of people, the company makes decisions in the interest of the company, not in the interest of the people that work for the company. And it's not in the, not the people making the decisions, it's the company as a whole. And you just happen to be, um, uh, not, not a victim, but a, an outcome of this situation that the company was facing at the time. And help me rationalize it. It's not a personal betrayal. It's something else entirely. Um,

Collin:

You know, somehow

Ryan:

I know, I know, um, I try not to, try not to hold grudges against these, these people. They were just doing what they were told, essentially, um,

Collin:

I know, I'm just

Ryan:

yeah, uh, the, the, so the culture and value side of things, I do care about the culture of the company, but being let go three times in quick succession just made me think. Why am I so invested in my work? Why am I so invested in these companies and progressing their, their culture and their values? Why am I so wedded to the idea of working for a company for a long period of time? And so I then decided I wouldn't do that. I would go into freelancing instead. And I had done freelancing years and years ago and made an absolute bad job of it. And I decided that, no, I'm a proper adult now. I can probably do my taxes accurately. And, uh, write up some contracts and that sort of thing ended up, ended up doing that sort of thing for, uh, six, six to seven months and decided that living out of a suitcase probably wasn't the best idea because you work for a company for three to four months and then you move on to the next gig and the next gig and the next gig. And I was like, well, I'm not really building up any sort of long term. Um, friendships and, and knowing a code base and having to move to another code base is like really, it takes a lot of mental exertion, right? And so I was like, this is not really making me as happy as I thought it would. Um, and so I then started looking for a full time gig again. I was like, I've, I can learn to love again. I can learn to trust again. And I had this honest conversation really early on with, um, Nash and Matt, who are my current bosses. I was like, look, I've been burned by culture and values, uh, companies and saying like companies saying we're family. We're not going to do anything bad. And then whoop. Oh, sorry. Uh, economical situation, shit. We're just going to rug pull. And, um, I was like, right. If this happens here. Let's just be frank and honest about it and do it straight away. Not, not hold anything back. That sort of thing. Be honest about it. Like, yeah, sure. We're going to do that. We'll be honest about it. And if you are feeling, you know, like this job isn't for you at any time, let us know, and we'll try and do our best to fix it up. And it's now been two years and we are working together in harmonious relationship. And if tomorrow there wasn't a role for me anymore, I would be okay with that.

Collin:

That's... I'm sorry, I just... I don't know if I should say this, because it just went through my head as you were, um, as you were talking. As you said, you said to them, Hey, if this happens here, let's talk about it. And in my head, the thing you were gonna say was, If this happens here, I will burn this fucking place to the ground.

Ryan:

2019 me would totally do that. But thanks to all like the talking to different people in the industry, I realized this is way more common than I originally thought it was. And yeah, 2019 would burn the place down. I would actually go to the office and probably punch somebody in the face. I would travel that way. It is a 12 hour. Um, but 2023 me is like, that's fine. Yes, I'm gonna be upset about it for like, maybe a whole week, but I will recover and move through this. Like I've moved through other things as well. So I, while I care about perpetuating good culture and good values at the company, it's what we do day in and day out and how we treat people every single day, not what's written down on a piece of paper and says like, We're family, or we trust people to make the right decisions, or that sort of thing. It's the day in and day out of how you work together. I think that's, that's the important thing.

Collin:

Yeah, honestly, uh, the family thing triggers me a little bit now, because circa 2014, 2015 era every goddamn horrible startup in the world was like, we're family. I had one that I worked for. This is no joke, uh, had everybody get a picture of them as a kid, right? So they could hang it in the stairs like when you were kids, you know? Like in your fam because we're a family. I absolutely refused to do it. I was like, that is so dumb. I'm not doing it. Um, I didn't

Ryan:

a little creepy.

Collin:

very much, uh, after. It was very creepy. It's very weird, right? Um, something else you mentioned before is talking to a therapist. And I just want to say for me, I think a lot of people have been a little, uh, traumatized in the last couple of years. You know, uh, you're not the only person who's like, I switched jobs like three times in however long. Uh, although I guess the last couple of years have been better. Um, but I feel like a lot of people have been in a situation. I have to say personally, I think. Uh, therapy is really good. I think, I'm gonna take a, a wild hot take here and say therapy is probably a very useful thing if you are one of these people who feels a little bit traumatized by the state of the industry in the last little while. If you can, it's very expensive, but if you can afford it or your insurance will cover it,

Ryan:

Yeah. Um, we get in Australia, we used to get five sessions free from the government or discounted or subsidized. And then in COVID, it bounced up to 10 sessions. So that was quite a decent rate. Ended up paying maybe 50 a session, something like that. So our, um, our socialized medical, Medicare system here covered it, thankfully. And that, that was really helpful. Like a lot of what we do as programmers is we keep it all in our brains. And so. All the emotions are also kept in our brains, and we might, I don't know, have, like, I can get angry from time to time, and I have to explain to my wife, like, I'm not angry at you, I'm angry at this thing I'm trying to think about, and think through, and, and process, like, I'm fixated on this thing over here, I'm not upset about what you're doing, it's this other thing over here, and so, like, even, even getting to the point of being able to communicate that was tough, and the therapy is, is what helped me there. I think, just think as programmers, like, I think everyone, every programmer should have like five to ten sessions of therapy a year because there's so much shit that goes on in our day jobs and not talking about it with somebody, it just, um, um, creates rot and mold in the brain somewhat. And yeah, it just needs to be let out, I think, as a, as a way of, of, of growing and evolving as people.

Collin:

Yeah, I feel like, uh, you know, a lot of times as developers, we feel like we're not, it's not just a job. It's like a Bushido code or something, where like, we have to dedicate our lives and all waking thoughts to, uh, you know, to kind of our job.

Ryan:

It's the way of the programmer.

Collin:

Yeah, I mean, coding at night's great, like, I do that too, but, you know, because, like, it's how my brain works, and it's, like, playing on a computer is what's fun for me, um, but on top of therapy, I've also, I've been pretty serious into meditation for, like, several years now, and zen, and things like that, and, um, I think, The thing that's interesting to me has been with that, and maybe therapy can have a similar effect for some people, is that you go into it thinking, like, this is going to help me focus better and be more productive, but the actual optimal result, I think, is that work seems a little less important than it did before. You realize, like, this isn't actually the most important thing in the world. Like, it's,

Ryan:

yeah, yeah. It's not, it's not my core personality trait. It's that I work for this company. It's a thing that I do and it's just a, a part of the puzzle of who I am.

Collin:

Yeah, I, um, yeah, and speaking about the whole values thing, I, I don't know. I've had weird experiences with that. Have you ever worked somewhere where they had an acronym they

Ryan:

no. no.

Collin:

I think Sonos had an acronym. It wasn't, it wasn't Sonos. It was a different acronym. Uh, and I forget what it was, but I thought it was very funny at the time. Something you mentioned a little bit in this, uh, in this blog post about culture and values also was, uh, coding tests and how at some places you were just like, listen, I'm not doing it. And then you would get, you know, you wouldn't get the job, um, which is understandable. Uh, maybe we could talk about that a little bit, cause you know, I think Joel and I have also spoken about coding tests, so maybe it'd be

Ryan:

Yeah, um, as I was saying before with junior programmers, they don't really have a corpus of work you can refer to. They have like basic repositories you can look through, but they're, they're all, well they tend to be, um, repositories that have been created by following a tutorial. And what I was after is more of a corpus of work that's like unique and original from those developers. And so the coding test is a good way of doing that. With the senior developer, um, I've got a bunch of work on GitHub. I tried to create Magic the Gathering in Ruby because I was bored one night and decided to try and implement a game that has 40, 000 unique cards with all different rule texts on them because I thought it would be fun. Um, it varies between fun and frustrating. At a time, but it's a different piece of Ruby work to the ones that I'd be typically producing, which would be Rails applications. I've also written a bunch of books about it. I write books that your developers read and you're trying to give me a coding test and it feels like you're not understanding how long I've been in the industry for, how much time I've spent learning about this and, and so on and so forth. It's almost, it's almost insulting, but I understand they have processes and the HR says this is the way we're hiring people or the C level executives are saying. This is how we've hired everyone else. It would be unfair to not treat this person exactly the same. I get that. Um, but yeah, coding tests tend to be, uh, not a good use of my time. And, um, the way that I was hired at Fat Zebra is that I ran them through another application I built, which was this Hanami GraphQL and React application. And they just said, tell us how it works. Show us, you know, you've got this page on, on the screen here. How does it fetch the data from the database? Oh, there's this transaction class over here. And that talks to this repository class that's built in RUM. And can you explain why you've made those choices? And I just walked them through it for an hour and I had a great time doing that because I was on my home turf. I wrote that code. I knew how it should have worked. Whereas a coding test, it's usually like they have the homegrown advantage. So if I'm going to do any sort of coding test interview, if somebody has code they want to bring to me, if I'm interviewing them, I'm happy to run through. Like, I can pick stuff up, no worries. But if they want me to give them a coding test, I've got stuff as well. So, yeah, that's the kind of, uh, I think, I think that sort of approach to coding tests is warranted, I think. If people have code they want to share, let them share it. But if you have code that, um, if you have a coding test and they don't have anything, give them the coding test after that. Don't make the coding test mandatory.

Collin:

Yeah, I think, I think that is fair. I think you were talking about the idea of you want to put everybody through the same system, but also everyone is an individual person. And so, I don't know, I think there's a lot of, I think if you want to have the best hiring process, to me, I feel like you have to be able to, uh, you know, customize it a little bit per I like the idea of you saying, like, listen, I made this app, I can walk you through how the app works, and then, like, that's your coding test. I, I sort of think coding tests for senior engineers are a little silly, is my opinion. Um, because, like I said, they have, like you said, a corpus of work. I, I don't know why we're implementing, you know, this linked list

Ryan:

Exactly. There's, there's, you know, they've got experience to, like, they've passed, clearly, other coding tests at other companies, probably, by this point in their career, five, six, seven years into their career. Why are you making them jump through the exact same hoops again? Doesn't make much sense to me, in my opinion. But each, each person, each company to their own.

Collin:

Yeah, it, it also seems like, With the way the industry has been in the last 18 months to 18 24 months, it's just that these companies have, like, made the interviews even more arduous than they were before, because the supply and demand equation has switched a little bit, and so now you get interviews that are, like, you know, right as this 8 page technical document, you know, before you talk to anybody. It's, it's a little insane.

Ryan:

Yeah, it can be. Um, I haven't yet experienced that, but I can imagine. I do spend a bunch of my time at the moment writing technical documents. So yeah, I would imagine my next interview might be write this eight page tech technical document.

Collin:

Well, Ryan, why don't you tell people where they can find you

Ryan:

Yeah, I'm on Mastodon at ryanbig at ruby. social. I'm also at ryanbig. com and you can email literally anything at ryanbig. com and you can reach me that way.

Collin:

Um, as always, uh, you know, please go buy whatever novelty items you can get our name on. We would appreciate it. And then you can wear it in your hometown since we don't have any merch. Uh, also, you know, probably tell somebody that would like the show, uh, to listen. And... Until then, we will see you next week.

People on this episode

Podcasts we love

Check out these other fine podcasts recommended by us, not an algorithm.

Fresh Fusion Artwork

Fresh Fusion

Jared White
Ruby for All Artwork

Ruby for All

Andrew Mason & Julie J
Code with Jason Artwork

Code with Jason

Jason Swett
IndieRails Artwork

IndieRails

Jess Brown & Jeremy Smith
The Ruby on Rails Podcast Artwork

The Ruby on Rails Podcast

Elise Shaffer and Brian Mariani
Remote Ruby Artwork

Remote Ruby

Jason Charnes, Chris Oliver, Andrew Mason
YAGNI Artwork

YAGNI

Matt Swanson
GemRuby Show Artwork

GemRuby Show

Lucas Barret
The Bike Shed Artwork

The Bike Shed

thoughtbot
Rubber Duck Dev Show Artwork

Rubber Duck Dev Show

Chris & Creston