DEV Community

The Bike Shed

385: The Boring Parts of Tech

Joël is joined by thoughtbot Software Developer and Dirt Jumper Daniel Nolan. Dirt jumping is BMX-style riding 🏍️ with really enormous dirt jumps.

But for a person who loves excitement in his spare time, for Daniel at work, it's not the new and shiny that interests him. When he dives into something, the "boring" parts of tech are what he finds most fulfilling. He wants to know the "why," and in this conversation, he explains how it sustains his career.

This episode is brought to you by Airbrake. Visit Frictionless error monitoring and performance insight for your app stack.

Transcript:

JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. And today, I'm joined with a guest, Daniel Nolan.

DANIEL: Hey.

JOËL: And, together, we're here to share a bit of what we've learned along the way. So, Daniel, what's new in your world?

DANIEL: So, recently, I just picked up a dirt jumper bicycle, and I've been learning to get better at dirt jumping. I ride mountain bikes quite a bit. But jumping is something that I haven't been super comfortable with.

JOËL: What is dirt jumping?

DANIEL: So, Dirt Jumping is kind of more like BMX-style riding with really huge dirt jumps. If you do it right, you don't pedal. So you should be jumping and pumping and making your way around the track or the course without the need to pedal. So it's actually pretty interesting. And it's supposed to level up your mountain bike skills if you get good at this.

JOËL: So the idea is you start up high somewhere, and you just kind of let the gravity bring you down?

DANIEL: Yep, that's the idea. So you start up on a platform; usually, you drop in. And then, from there, you start the series of jumps or rollers, pick up speed, and then kind of go into some bigger jumps, and berms, and stuff and make your way around the course. It's pretty fun.

JOËL: So you're coming down from a high, and then you hit a dirt ramp somewhere. You go up in the air. You fly off, and you're doing, like, a flip or something like that?

DANIEL: Yeah, not quite there yet. Some of the people I ride with can do flips, and no handers, and stuff; definitely not there, but just getting comfortable on big dirt jumps. I think the scariest thing is not being able to see the landing. So it's, like, if it's just a little jump, like, you know where you're going. But if it's like one of those big jumps with a huge lift, you just have no idea what's on the other side. And no matter how, you know, even if you've hit it ten times, it's still scary because you can't see it.

JOËL: How do you land safely when you can't see your landing place?

DANIEL: There's a technique where you kind of push the bike down. So, like, once you're in the air and you've kind of leveled the bike out, and you spot the landing, you force the bike down to kind of accentuate that movement and make the bike go down.

JOËL: Just so I get a better mental picture here, how high up are we talking about when you're flying off this ramp?

DANIEL: So some of these dirt jumps are probably...on the ones that I'm riding, they lift to probably, like, you know, eight, nine-feet high, and you're probably getting, like, three to four feet in the air over that to clear it.

JOËL: Wow. That's a little bit of elevation right there.

DANIEL: Yeah.

JOËL: I would probably be scared.

DANIEL: The safe jumps have what they call a table on top, so there's no risk. Like, if you land on top of the jump, you're not going to die. But, yeah, typically, they're flat on top. So you have to have enough air and enough momentum to clear that flat part and land on the downside.

JOËL: I like to do a lot of bouldering. In this case, I do it in a gym, so you're climbing up a wall that's maybe 15 feet high. Even at that height, I feel a little scared; not very good with heights. How do you feel when you're up 15-20 feet on a bicycle, and you don't know where you're going to land?

DANIEL: It's scary. I mean, just, there's no way to get around it. But that's the whole reason I started getting into the dirt jumping is just try to get it to where it's more second nature, and you're not so terrified.

JOËL: Kind of pushing some of your personal limits, then.

DANIEL: Yeah, for sure.

JOËL: So it sounds like you're introducing a lot of excitement and novelty in your personal life. And that contrasts to a recent conversation that we had where you'd mentioned that, at work, it's not the kind of shiny, new tech that excites you, or even kind of the scary parts. But you find that the boring parts of tech are what are most fulfilling to you.

DANIEL: Yeah, I actually really do like diving into the more boring parts. And I think to give just a little history about myself and maybe why that might be, I'm a second career programmer. My original career, or what I thought was going to be my lifelong career, was I was an auto mechanic. So I was a certified VW tech in my early 20s. And I've always kind of had this passion for, like, why things are. I want to know why something is. So, when I dive into something, it's like, I want to know the why. I don't want to just know what the fix is. I want to know why that thing fixes it or whatever.

So I find that getting into the more boring parts of programming, and especially in the Rails stack, allowed me to do this. So, for example, like, a gem that Dependabot can't upgrade, and it just sits there. The PR just sits there, and nobody wants to touch it. So then I come along, and I'm like, well, why won't it upgrade? Why can't we upgrade this thing? And I start diving into sort of breaking changes. Is there stuff like that?

So fixing things, for me, has been something...since I was just a little kid, my mom said I always used to take things apart and put them back together. I always want to know the why. Doing some of the more boring stuff, you get to do a lot more of that.

JOËL: So it sounds like really you're motivated by curiosity pretty strongly.

DANIEL: Yeah, for sure. I don't want to just know what a quick fix is or something like that. I want to actually get in. I want to read this, you know, like, an example, like, a gem that won't upgrade, like, I want to go dive into that source code. I want to see what the source code is doing. I want to figure out the why, you know. I don't want to just Google for, like, hey, I can't upgrade this gem. What do you think I should do? So I've always been super curious. That's how I've been able to sustain in software development and not really get burn out. It's what makes me tick.

JOËL: How do you feel about bug fixing or, like, chasing down bugs in general? Is that something that really scratches that itch?

DANIEL: It definitely does. I feel it's, you know, very similar to somebody comes to you, and they've got a broken car. And they're like, "Hey, this thing's making this noise when I'm going down the highway at 50 miles an hour, you know, what is it?" You know, it's very much the same thing. Like, you get an end user, and they're like, "Hey, when I click this button in the browser, and, you know, this thing doesn't load," or, you know, I'm getting a 500 error." It's very relatable. I love diving into those type of things. Like, I love fixing bugs.

JOËL: It's interesting that you related that back to your work with cars because it sounds like you were doing sort of the mechanical version of debugging.

DANIEL: Definitely the mechanical version of debugging. But it's still...it's a lot of the same stuff. It's a lot of process of elimination and stuff like that, right? Like, you got a noise coming from the front left. It could be anything, you know, it could be the wheel. It could be brakes. It could be, I mean, there's a number of things it could be. So you kind of got to start going down the path of like, you know, well, it's not this, and it's not this, and it's not this.

And it's very similar when you have a bug, you know, and you start down the path of, like, oh, well, I can click the button. The post is getting sent to the server. But, for some reason, you know, the parameters aren't going past the controller or something like that. So, you know, you maybe go look for some primitive params or something, I don't know. But it's very similar as, you know, just going through the process of, like, checking things off and trying to get to the root cause.

JOËL: Yeah. So, when you joined software, you already had this skill kind of really built up pretty well.

DANIEL: Yeah, I definitely did. Being a mechanic, a lot of times, I would get, like, the problems that nobody else wanted to deal with. Because people were like, oh, he likes troubleshooting electrical issues and stuff like that, so give it to him, you know. Whereas the other mechanics are just, you know, like, were more, like, oh, I want to rebuild the engine, or I want to put a new trans...like, it visibly needs an engine.

Like, oh, there's a rod through the side of the block. It's leaking oil everywhere. Okay, yeah, like...versus, oh, it's got some electrical bug where, you know, one injector doesn't fire every 50th time, or something like that. And something that you just really have to, like, trace down and figure out why it's not happening. So I feel like I had a pretty good, no pun intended, toolbox coming into...

JOËL: Nice.

DANIEL: Software development as far as just problem-solving skills, I guess.

JOËL: It's interesting. A few years ago, I interviewed a bunch of people about debugging and the parts they liked, the parts they didn't like, hopes, and fears. And most people I talked to actually enjoyed debugging, except that, oftentimes, when bugs come up, it's because they're blocking something else. And there are time pressures.

And so all that extra context is what makes debugging stressful for most people that I talk to. But the actual act of debugging, that kind of process of elimination or trying to hunt down the source of a bug, many people I interviewed actually found that highly fulfilling. So it sounds like it taps into a lot of the same interests that you have.

DANIEL: That's super interesting, yeah. And it is fulfilling, too, right? Like, you're going this hunting, and you kind of, like, put on your detective hat and go try to, like, figure out what the breaking thing is. And then you get the payoff also of like, okay, well, you know, if you actually fix it, you resolved it, and you get that little bit of payoff.

And I think for any job for me to be fulfilling, I have to have that kind of that payoff where you start with something broken, and you fix it. You know, you start with an empty editor, and then you build out a web application or something like that. So it's just, like, having that payoff is definitely huge. You know, I just find that part of software development super fulfilling.

JOËL: So you've mentioned debugging. You've talked a little bit about gnarly gem upgrades. What other types of work fit under that boring part of software heading for you?

DANIEL: Putting in some tools for best practices maybe, you know, like setting up linters and stuff like that, automated code review kind of things. It's stuff that you tend to see, like, teams and stuff want, but they just never have the time. They're always building, you know, new features and stuff. So I think a lot of that stuff, like, gets pushed by the wayside. Refactoring code that's good enough. It's good enough, and it's working, but it could be a little cleaner, a little easier to read; kind of enjoy that, too. I don't know, do you have any things that you would consider boring programming work?

JOËL: I think some types of features sometimes can feel boring, maybe a little bit beyond boring. It's scary or unpleasant to work on. Sometimes there are just parts of the code that are really gnarly to work with. I'm like, oh no, I've got the ticket that requires touching some of that gnarly code in a particular part of the app. There's one app, in particular, I'm thinking of that this was the wizard code, or the multi-step form processing code that had gotten really gnarly, and so nobody wanted to touch it. And if you had a ticket that required touching that code, it's like, oh no, you drew the short straw.

DANIEL: Yeah. I've definitely had experiences like that. I had a feature I worked on at a previous job where it was...the feature was referred to as the black box because nobody knew how it worked. Nobody knew what it actually did. But they knew that it didn't produce the results they wanted. And they knew it needed to be refactored, so that was definitely one. I don't even know if I would say that was boring, but definitely, a scary part that nobody wants to touch.

There's just all kinds of stuff that's boring. Like, if you're just constantly adding new features and doing new things, and adding to the app, there's code that's probably not used anymore. So using something like Coverband and going in and finding unused code and cleaning out that kind of stuff. Optimizing queries, again, you know, you build something, and it works. It's there. It's doing its thing. And nobody's complained that the endpoint's slow. But when you run it, you notice that there's like, you know, 70 N+1 queries. So you go, you know, you go touch that up a little bit.

I feel like a lot of people and a lot of programmers just don't want to do that work, or it may not even be that they don't want to do that work. It's just a lot of times; there's maybe no time for it. So that's no fault of anyone in particular. But I think we need to, you know, figure out a way to make some more of these things fun. Maybe more teams need to build in, like, gem upgrade day or something. And, you know, like, go upgrade the ones that are hard to upgrade. Upgrade the ones that Dependabot can't, that have breaking changes. Or, I don't know, there's got to be some way where we can make some more of this, like, the tasks that keep the car running more enjoyable, right?

MID-ROLL AD:

Debugging errors can be a developer’s worst nightmare...but it doesn’t have to be. Airbrake is an award-winning error monitoring, performance, and deployment tracking tool created by developers for developers that can actually help cut your debugging time in half.

So why do developers love Airbrake? It has all of the information that web developers need to monitor their application - including error management, performance insights, and deploy tracking!

Airbrake’s debugging tool catches all of your project errors, intelligently groups them, and points you to the issue in the code so you can quickly fix the bug before customers are impacted.

In addition to stellar error monitoring, Airbrake’s lightweight APM helps developers to track the performance and availability of their application through metrics like HTTP requests, response times, error occurrences, and user satisfaction.

Finally, Airbrake Deploy Tracking helps developers track trends, fix bad deploys, and improve code quality.

Since 2008, Airbrake has been a staple in the Ruby community and has grown to cover all major programming languages. Airbrake seamlessly integrates with your favorite apps to include modern features like single sign-on and SDK-based installation. From testing to production, Airbrake notifiers have your back.

Your time is valuable, so why waste it combing through logs, waiting for user reports, or retrofitting other tools to monitor your application? You literally have nothing to lose. Head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

JOËL: Would it be fair to describe the types of work that you've been talking about here, you've been describing as the boring parts of development, would it be fair to put those under the heading of maintenance?

DANIEL: I think it would be fair to put it under maintenance, maybe even relating that back to cars. It's the same thing, right? Like, you can put a new paint job on the car, and you can get some new, shiny wheels. And you can, you know, put a turbocharger on it or something but, eventually, you know, you got to change your oil. You got to change your tires. You need to change your air filter, new windshield wipers, you know, so you can see when it's raining.

These things are all just things that need to be done. Otherwise, no matter how shiny your car is, it's just not going to go anymore, right? So I feel like maybe most of these tasks are maintenance. It's not the shiny, new thing. It's just keeping the thing running.

JOËL: And, I guess, traditionally, at thoughtbot, we've done engagements where we're either building new software or new features on existing software. Or we might be coming in and fixing some larger problems, maybe doing something like helping with a Rails upgrade or helping to backfill a test suite, some larger kind of chronic problems.

But we recently introduced a maintenance service that is, instead of having people full-time there to do a particular task, it's more of so many hours a month to just do a lot of those boring things where we're doing like you said, potentially gem upgrades, or fixing bugs, or things like that. Is that a team that you would be interested in joining?

DANIEL: So I actually got to work with Jeanine and [inaudible 16:05] on support and maintenance for about a month, month and a half maybe. I worked on an upgrade. And that's exactly what I did. It was upgrading a Rails 5.2 app to Rails 7. And yeah, it was not only super fun, but the other fun side of that, for me, is that a lot of times when I'm doing these things, and you find breaking changes, the gem is either, like, ten years old, and it can't be upgraded because there's nobody maintaining it anymore. So you maybe have to create a fork, or you maybe submit a patch or something.

So this is a way that I've been able to get, you know, my feet wet in open source without really contributing to a specific open-source project. So I have tons of little commits on different gems here and there fixing stuff up or something I found along the way that couldn't be upgraded or something like that. So yeah, the support and maintenance team is definitely something that I'm interested in, and I had a good time working with them for that rotation.

JOËL: And I think it's really interesting you're talking about the pattern of open-source contributions that you were having. And I think that's something that's really valuable to the community, just those little patches in various places because it's broken or is no longer compatible with other things. What you're doing not only helps unblock you and your client but also is probably unblocking a lot of other people in the community, so might have a larger impact towards other people than if you were putting all of your time into contributing to one more well-known gem.

DANIEL: Yeah, for sure. You know, I know for sure, like, some of them I have a commit on Honeybadger, something that broke recently, a Sidekiq upgrade that broke, and there was just a small change to the way the error handling worked. And it was, like, causing just this flood of errors. And it was just a simple change. But I'm sure not only did it fix it for us and the app I was working on, but, yeah, I'm sure quite a few people benefited from that one.

JOËL: So, for those listeners out there who are hearing you talk about some of this maintenance or boring work and maybe are feeling inspired to go and do that on their team, how would you recommend getting into that?

DANIEL: Well, I mentioned Dependabot. If your team's already using something like Dependabot for, like, minor gem upgrades, maybe there's a PR that's stuck that Dependabot can't upgrade because there's some breaking changes in one of the gems it's trying to upgrade. That's a great place to start. You could run, I believe; it's bundle-outdated. And that will tell you what gems are in your gem file that are outdated and need to be updated.

So any of them that are going to be major version bumps, you know, going from, like, two to three, typically, you'll usually have breaking changes somewhere you can kind of jump in and go fix those breaking changes. Maybe there's even breaking changes in another gem that may be related or something that you're trying to upgrade. And, you know, you can't upgrade past version two because the new gem you're trying to upgrade depends on that gem-specific version or something like that. So I feel like that's a great way you could jump in.

Maybe some other ways would be if, you know, maybe you want to optimize queries or something like that. Maybe you have Sentry or some other type of software that reports on these things, New Relic, you know, so something like that you could go dive into and pick up an endpoint that's responding slow or something that has some N+1s being reported and go dive in, see if you can maybe touch those up.

JOËL: Those are all great suggestions. I know I once worked with a developer who would dedicate...I think it was the first hour of his day. So he'd come into work in the morning, and before jumping in on feature work, the first hour of his day, he would just do small improvements on things and not just, like, refactoring for the sake of refactoring. But they're things like you're describing, like, oh, do we have a gem that needs to handle an update?

Did one of our monitoring services highlight maybe some slow queries that I could tweak a little bit this morning? Or are there areas where we're feeling pain that we can make things better? And just by doing a little bit every day, he became known as the person on the team who is, like, having an impact, and making everybody's lives better, and making the codebase better, making the product better. And I really appreciated this person.

DANIEL: Yeah, sounds like an angel. Like I was saying, you know, I kind of hinted out a little bit before...I think these things...and it could be because they're boring, or it could just be because you have stakeholders that are, like, hey, we need to get this new feature out. And I just feel like a lot of this stuff definitely gets pushed to the back burner often, so figuring out a way to incorporate some stuff into your day like that, or automating some of it, you know, using things like Dependabot and stuff like that. I think they're all just great ways to keep the app or the project in good shape.

Another thing that I've done adding custom RuboCop rules to enforce things the way that you want them. So, like, it comes with a standard set of rules, but you find some pattern that's being, you know, repeated, and we don't want that pattern repeated. You know, spend the time to write a RuboCop rule so that that pattern doesn't get repeated. And you don't have to constantly police this in PRs, you know, you let the automated tool do it for you. But I've never really heard anybody get super excited about writing a Rubocop rule.

JOËL: And they're valuable.

DANIEL: Yeah, they're definitely valuable.

JOËL: I think the most excited I've seen people get about RuboCop rules is typically as part of an incident report. So something went terribly wrong, and maybe production went down. And then you're doing a post-mortem, and then you realize, oh, in this way, some bad code made it through. And you decide how can we prevent this from happening again? And the consensus is, oh, maybe a Rubocop rule would have prevented this. So I think that's generally where people actually start caring about a Rubocop rule is after there's been some larger incident.

DANIEL: Sure. We had something where I think, like, we first started using system specs on an app I was working on, and some people were using Path Helper, and some people were using URL Helper. And, for some reason, the ones that were using Path Helper would fail randomly. I don't really recall right off the top of my head why, but we wrote a RuboCop rule to just enforce using the URL for or the URL Helper instead of the Path Helper just to enforce that rule. So we didn't have to constantly police it, and it just made everybody's lives easier.

Figuring out a way to set some time aside for this stuff or automating this stuff is definitely beneficial because you may not always have somebody on the team that's interested or that wants to champion this stuff.

JOËL: Hey, you mentioned the word champion, and I like that word because it's the kind of thing that often doesn't get prioritized. And so you need somebody to advocate for that work getting done. And, generally, I've found this work is often cheaper to do sooner rather than later. If you postpone it too long, and now it's been ten years, and you've not done a Rails upgrade, and your app is still running on Rails 3. It's going to be very expensive to do that work.

DANIEL: Yeah, the biggest cost of software is maintenance is definitely true.

JOËL: Maintenance is valuable work, and we should celebrate it more.

DANIEL: For sure.

JOËL: On that note, shall we wrap up?

DANIEL: I think so.

JOËL: Thanks for joining us, Daniel. Where can people find you online?

DANIEL: You can find me on Twitter or on GitHub. Both are danielnolan.

JOËL: All right, thank you very much for joining us.

STEPHANIE: Show notes for this episode can be found at bikeshed.fm.

JOËL: This show has been produced and edited by Mandy Moore.

STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show.

JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter.

STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email.

JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week.

ALL: Byeeeeeeee!!!!!!!

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

Support The Bike Shed

Episode source