349: Unpopular Opinions

Steph and Chris announce Joël Quenneville as the new host of the show! 🎉 Joël talks about his grand plans for where The Bike Shed is going to go from here. (Okay, maybe not grand plans...!)

Together, the group chats about unpopular opinions and hot programming takes.

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

Follow Joël on Twitter! Welcome him to the show.
Joël Quenneville - DRY is harmful for intermediate devs

Become a Sponsor of The Bike Shed!

Transcript

CHRIS: Thank you. No brown M&M'S. No asking me weird questions. I ask very little.

STEPH: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Steph Viccari.

CHRIS: I'm Chris Toomey.

JOËL: And I'm Joël Quenneville.

STEPH: And together, we're here to share a bit of what we learned along the way. So, hey, Chris, what's new in your world?

CHRIS: What is new in my world? There is a new friend on the show with us today, Joël, developer extraordinaire, principal developer at thoughtbot, former coach of the Chicago Blackhawks (That one's not true, but it's funny to say.) and friend of the show, many time guest. Joël, so great to see you. How are you today?

JOËL: I'm excited to be joining the show.

CHRIS: Fantastic. So Steph and I shared with the audience in the previous episode that we have decided...we've made the heavy decision that it is time for us to hand over the hosting mantle. But we had yet to discuss exactly where that was going to go. And today, we are happy to share with you the specifics of that, which is that Joël will be taking over the hosting detail. So, Joël, do you have grand plans for where The Bike Shed is going to go from here?

JOËL: Maybe not in grand plans, but I'm definitely already planning content, lining up a few guests. I think the next few weeks are going to be a lot of interviews with some guests, a lot of co-workers at thoughtbot will want to share their stories or some exciting things that they're working on, things they are specialized in.

One thing that I really appreciate at thoughtbot is that we're all pretty full-stack developers. Everybody tends to have a specialization or an area they're really good at. And so when you're ever stuck, and you need advanced Git help, you go to, historically, Chris. If you want some help on security, you go to Mike Burns, et cetera. And so yeah, I'd love to bring in some of them and get to talk a little bit about some of the areas where they're either doing something interesting, or this is just an area where they have deep expertise.

STEPH: I have to say that having you take over as host of the show feels like such a nice continuation, given that you've been involved with The Bike Shed since you were a guest on the show back in 2018. And then, since then, you've been a repeat guest. And even when you're not here, Chris and I still frequently bring up your name and mention some of the talks and the blog posts that you have written.

So I'm super excited for everything that you just said, for all the guests that you're going to bring on the show, and the thoughtbot voices. And I'm looking forward to tuning into future episodes and hearing what happens next.

JOËL: Yeah, this is a really exciting transition for me. I am a long-time fan of the show. I've been a guest a few times. And now, coming on as a host is just taking it to the next level.

CHRIS: Yeah, Joël, I'm also super excited to see the new perspective that you bring to the show. And frankly, to Steph's point, you've been on the show a bunch of times. You've been here in spirit. In fact, there was a tweet that someone sent to us which was "Hey, @joelquen," which is your Twitter handle, "I feel as if I know you and your work after listening to @SViccari and @christoomey. They definitely appreciate you," which was true then and is true now. So I couldn't be happier for you to be taking over this hosting slot.

JOËL: Creating content for developers and sharing the things I've learned, or the things that I've experienced with other people has always been something that's been really important to me. And so, getting a chance to bring that to The Bike Shed is a really exciting opportunity.

My past work has intersected with the show several times, either that's been conference talks or blog posts, or even just conversations we've all had. Steph and I pair almost every day. So there are a lot of good conversations. A lot of conversations that end with me saying, "You should talk about that in The Bike Shed. That's a good topic."

STEPH: You have been an excellent source for topics in terms of you've literally added stuff to our Trello board that we use to manage the show and then yes, and all those conversations that we've had. You're like, "Oh, this will be a good Bike Shed topic." And I'm like, "Hold please," while I go and then add it to our board.

JOËL: The fun of being an employee at thoughtbot is that I have access to the Trello board. And I can just add whatever ideas I have there for you all to talk about. [laughs]

CHRIS: That is the most direct way to send in a listener question is just to write it into the Trello board directly. Skip all the forms, and the Twitter, and the whatnot.

JOËL: Yeah, speaking of topics on our Trello board, let's go out on a really spicy one. I see we have a card about unpopular opinions. Chris, you created this. What is your hot programming take?

CHRIS: This was so long ago, I don't even remember. But this one has interestingly sat on the Trello board for a while. I was like, Steph, let's really lean into it. Let's go out there. What are our extreme takes? And I think we say the stuff that's in our heart most of the time anyway. But we're; also, I don't know, pragmatic, kind of boring up the middle.

Someone recently described my tech choices as like a Subaru. Like the architecture, the way I built it, you know, it's stable. It'll get to where you want to go. It's not going to be too fancy or too flashy. And I was like, you know, actually, humorously, my wife and I just bought a Subaru. So I was like, I guess I can't say no to that.

Anyway, though, I think I have one spicy take, which I have shared on The Bike Shed before. But it is the thing that I will die on this hill. I care about this. It feels like I'm just being persnickety, but I think it matters, which is that the phrase single-page application or the idea of an S-P-A or a SPA, which I've heard some people say it, is just a terrible framework. I am so unhappy with it as a concept.

I think, technically, the implementation of them has often led to some really complicated things, which is why I've spent so much time exploring Inertia, or LiveView or Livewire, or all of the other options that are out there. I think there are some really interesting novel ways. Remix.run is the most recent thing that I've been talking about, which takes a pretty traditional SPA type of build and then makes it behave more like a traditional server-rendered application.

But just the idea single-page application really grinds my gears that that is a thing that we talk about. Because it's the web, we have URLs; these should all be different pages. I don't care if there's one bundle of JavaScript that we send down or that it begins as a single HTML file that we send down, and then we repopulate constantly. There still should be URLs. Those are a honkin' good idea, and we should use more of those. And we shouldn't anchor to a technology...like, no, SPAs, I don't like it. I'm not a fan. So that is my unpopular opinion, I'm pretty sure.

STEPH: I think we have a full episode, too, where we focused a lot on that topic where you shake your fist at the SPAs in the world [laughs] and why you don't like them.

JOËL: I feel like the industry pendulum might be swinging back. I think we've hit peak SPA, and now we're slowly moving back, anecdotally anyway.

CHRIS: That is definitely what I'm seeing more and more of, and I'm very happy for it. Because I think there's some interesting stuff that came out of SPAs and the ideas of like, oh, let's animate, and let's have more continuity and page transitions and things that I think can really enhance the end-user experience. But I think the cost has been too high. It's broken us from some of the norm.

Like, how does the web work? That's a thing that we should talk about. Links, they're awesome. You can link between pages. It's so cool. And we just kind of threw that away. And we're like, div onclick. It'll be fun. Don't worry about it. Screen readers, who cares about those? Doesn't even matter. I care. That's who cares. I'm going to calm down now. I'm fine. It's fine. But yes, I agree. I do think the pendulum is swinging back, and I'm very happy to see that.

JOËL: Long-time listeners of the show will know that I'm a big fan of the Elm language. And for the longest time, I wanted to do a client project at thoughtbot with it. But I agree with you, Chris, that a lot of things shouldn't be SPAs. A lot of things should be just boring Rails apps. And so, every time an opportunity came, I just couldn't justify doing a front-end app. So I would be like, yay, I would love to do Elm here, but this should just be a vanilla Rails app.

And then, one day, we had a project that came in that was actually a single-page app. It was one page where you loaded up a bunch of data streams and then could interact with them and get all these cool visualizations and things. There was no clicking away. There were no other pages. It was just load some data, and you've got a playground. And that was the moment I knew, okay, this is the app I want to do in Elm. And that was my introduction to bringing Elm to colleagues at thoughtbot to work on a project together.

STEPH: You put out the signal kind of like the Batman signal, but you put out the Elm signal calling everybody into the project.

JOËL: [laughs]

CHRIS: You put a small tree on your desk, and everyone came together around it.

JOËL: [laughs]

CHRIS: Also, I want to applaud your pragmatic restraint of I want to use this. This would be fun to use, but it is not the right choice for many particular applications or projects that came through the door. But then you found it. Then you found that magic moment.

To be extra clear, I'm not opposed like; my distinction is an SPA or traditional server-rendered HTML generation on the server...I got redundant in there, but that'll be fine. It's more the bundle of JavaScript that goes down and that there's no routing on the server-side, et cetera, that all logic is pushed to the client-side.

I've harped on about Inertia and my love for that framework over many, many an episode on the show. But I feel like that, and many other solutions that are in that similar space, allow us to have the sort of experiences that are traditionally associated with an SPA but don't give up on the idea of auth being simply managed via a cookie on the server sort of thing. Cookie on the server is a phrase that doesn't really make sense. But y'all get what I'm saying, I hope. If not, assume that I said the right thing. It'll be more fun that way.

JOËL: Steph, I'm curious; what's maybe one of your unpopular opinions or hot takes?

STEPH: I have a couple, and since Chris used a phrase that has now helped anchor me in terms of like the hill that I will die on, I'm now looking through that list to pick the one that I feel like the most passionate about. So looking through that list, I might just have to go a couple. It's hard to really choose.

But the first one is I'm going to say you don't need a side project. I can't tell you how much that frustrates me when people just always say you have to do something on the side. You have to stay up late and code. You have to do coding on the weekends. I feel very strongly that software development is a job, and it doesn't have to be your passion; if it is, that is fabulous.

But it is, at the end of the day, still a job, and you don't need to know three additional languages to be good at your job. And you should be able to focus on learning what makes your day-to-day easier and then learn that during your work hours. So that's something I feel very strongly about.

JOËL: Do you think that's something that is a current reality or something that is aspirational? As in, an employer shouldn't require it, or it is currently possible to have a completely fine career and never have a side project.

STEPH: I think it's very possible currently and aspirational for some teams. I think there are some companies and teams that will turn you down because you don't fit that mold. And I think that's what then puts us in that unpopular opinion category. Because there are enough people that still think that that is an important part of being a software developer.

But I do think that there are still plenty of teams and people that are starting to agree with the idea that it shouldn't be that way and that that is not a requirement for an interview, or for joining the team, or for being a good developer, or for progressing in your skills. So a little bit of both, currently possible and also aspirational.

JOËL: I'm going to throw a question out, and I think this may be its own complete topic. So feel free to tell me that this is not the day to talk about this, but I'm going to put a question out. Recently, there was a really good conversation that happened internally at thoughtbot where one of our newer developers was asking, is it possible to progress our whole career ladder without ever doing any side projects? So just 32 hours of client work, eight hours investment time every week.

And maybe a little bit beyond that, maybe it's technically possible. But it takes an excruciatingly long time. Is it possible to progress in a reasonable amount of time through the career ladder without doing any extra work outside of our standard working hours? What are your thoughts on that for thoughtbot?

STEPH: I think the answer has to be yes. Because I mean, who's creating that ladder that you are climbing? It's going to come down to the company and the managers and the people who are deciding on how you advance, and not everybody has time. So what you're telling me is that if someone can't advance during the normal work hours that they have then...because they have families; they have other priorities in their life; they have other responsibilities, that then they're just stuck? And that feels like an unacceptable answer to me. So my answer is absolutely you can progress during the work hours that you have. And if you can't, then that is a problem for managers and leadership to fix.

CHRIS: I definitely agree with the assertion that you're making, Steph. And I like the ire that you're bringing to this. This is good. This is the sort of fire that we should have in this particular segment. I do think there was an aspect of the question that is subtle and really interesting to me, which is in a reasonable amount of time. And then you mentioned, or it might take an excruciatingly long amount of time.

A thing that I observe about our industry is that it is rather young overall, and the expectations of progression are incredibly rapid. This is sort of my second career. I spent three years as a mechanical engineer working in industry. That was the first thing that I did. And that world looks wildly different.

The idea of achieving principal engineer, which is a little bit more formalized of a concept, but I saw that as 30 years down the road kind of thing, or it may be 20, or something, but a significant chunk of my career. That is something I might achieve towards the end of my career after having put in a lot of time.

And development is just such a young industry. Like, the idea of going to a bootcamp and then two years later being a senior engineer and continuing to progress just ever so rapidly is interesting. I don't want to slow anyone down by any means. And I don't want to say that like, well, when I was over there, it was slower, and so it should be slower here. But I don't think it's realistic, frankly.

And I think some of what is at the heart of this question is like, no, this is an industry where you get in there, and in five years, you have achieved the pinnacle of your career. And then you go retire, and you go to a cabin in the woods, and you never talk to humans or touch a computer again. That's the dream. It's like, well, maybe that's not realistic. And what would it actually look like if we were a little more chill about these sorts of things? That is a question that I have.

STEPH: It's funny that you mentioned that one because that was one that I almost put on my list of unpopular opinions where I think the progression in which we change our titles as developers is silly, [chuckles] is probably the best word that I have for it. Because I agree with you, I don't want to slow people down. And we often change our titles to reflect that, yes, we want more responsibilities. We want more pay, and so that feels like the best way to then achieve those goals.

But it's so rapid in how we expect people to progress to different levels of engineering. I do think it loses a bit of its meaning because then we progress people so quickly through those different roles. Because then senior developer means so much. I mean, are you a senior developer with two years of experience or ten years of experience? Like, you could be in both of those groups. And so, it just loses some of its meaning because of that.

JOËL: It's also hard because years of experience aren't really a good way to compare two developers. I mean, two versus 10 is probably something you can compare very roughly. But five versus 7 or 5 versus 10, someone might be much more experienced or be better at solving problems after five years than somebody else in 10.

CHRIS: I will argue that two years in a consultancy is like five or maybe even ten years in a middle-of-the-road product company that's kind of got its stuff figured out. And just the volume of new and novel that will come at you is quite large. And I strongly recommend working with a lovely company called thoughtbot to get that experience because it'll be a fun time while you're there. And, man, will you learn a lot.

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 you cut your debugging time in half.

So why do developers love Airbrake? Well, 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 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 enables 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 and includes 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. So head on over to airbrake.io/try/bikeshed to create your FREE developer account today!

STEPH: Joël, I have another potentially unpopular opinion I'd love to share. But I'm curious, what's one of yours?

JOËL: So here's a controversial opinion that I have: DRY, Don't Repeat Yourself, is dangerous, I'd say even a harmful rule of thumb for intermediate developers. It's one of our favorite kind of aphorisms, principles that we try to live by as developers. But I think it often does more harm than good at a certain point in your career.

When you start off as a new developer, one of the most common sorts of bugs you'll do is where you duplicate code, and then you change it in one place and don't change it in the other. And they're out of sync, and then your code breaks. And then you discover DRY, Don't Repeat Yourself. And it's amazing because this simple rule fixes 80% of the bugs you were creating. And of course, now there are other types of bugs you find out about. But it's a whole class that gets eliminated by that, and it's wonderful.

But then you get into the intermediate developer, and you start to get clever, and you try to apply this in a lot of places. And you start trying to abstract things that are similar but not the same, and then they start to diverge. And then you've got a mess on your hands. And this happens in application code happens in test code.

Yeah, you end up doing that, prematurely abstracting, and particularly when it's just based on through a simple substring matching. So you're saying this string of 100 characters is identical in two files. We need an abstraction that shares these two when the fact that the two strings might be similar is just coincidental. And so that's where you cause more harm than good. And then eventually, you kind of transcend that, hopefully, and get back to the point where you can maybe apply DRY more judiciously.

Now, DRY is no longer for you about similar characters. It's about similar or actually same concepts because similar is not good enough. And hopefully, you have the discernment to distinguish between similar and same. And when you're not quite sure, maybe you leave them separate to see will they diverge in the next few months?

STEPH: It's almost like you and I are on the same project, and we have felt similar pains in the world.

JOËL: [laughs] I think this is a thing that a lot of developers eventually get to the point where they can do it decently well in production code. But at least when it comes to RSpec code, the Ruby community has just refused to learn this lesson. We're still stuck in that intermediate developer phase where everything's got to be extracted out as shared setup. And I would argue that shared setup on most tests is similar and not same. And the identical thing is if you're just copying two strings of code that look similar in two files and creating an abstraction that really doesn't need to be there.

CHRIS: Friends, I have to tell a truth in this moment. I wrote a let within an RSpec file this week. It happened.

JOËL: [Gasps]

STEPH: This is actually why you're moving off the show, Chris. This right here. [laughs]

CHRIS: I'm getting kicked off the island. I've broken rule number one [chuckles]; let's not. This was...I think it was a reasonable one; at least I couldn't figure out a different way to do it. I was defining a class within an RSpec file, a representative implementation of a subclass. And I tried to do it by just defining a class in line, but RuboCop came along; we recently added RuboCop to the app as well. And RuboCop said, no, no, no, you are leaking a constant. And I said, oh, that's true, RuboCop.

And then, thankfully, the documentation page for that rule had a pointer to what to do instead. And so it ended up with a let. I don't actually think I need to let now that I think about it. You can dynamically define a class within a spec example. So I then, in the rest of the example, started doing that. So I'll probably remove the one let that I actually added. [laughs] But it happened.

JOËL: That honestly seems reasonable to me. I think there are use cases where let can be done correctly. It's just really hard to have the discipline to not stray off that very narrow path of safety. I recently gave a talk at RailsConf about how your test suite is making too many database calls. And most of them are all related to doing way too much during your setup phase.

And one of the reasons I gave that this happens too often is shared setup and let in particular. And I thought that I might get booed off the stage. But in fact, several people came up to me afterwards and told me that I had actually given them a whole new perspective they had never seen, and that was interesting to them.

STEPH: That's awesome. That's so nice that people came up and shared that with you. Yeah, I think one of the areas that I don't know if we highlight enough, but whenever you and I happen to gripe about the use of let or over drying and extracting setup for tests, specifically, is because then we're not talking about the trade-off of then you're coupling all your other tests to that extracted setup.

And so it's not so much that I care that you dried up your test setup, and now the rest of my tests are likely reliant on that extracted shared setup. And then that's where we've introduced a trade-off, and it's a painful trade-off that I have worked through a number of times. So just to add a bit of persnicketiness to our discussion in terms of it's not so much the DRY in the extraction that bothers me, it's then the trade-off of now everything is coupled. And it becomes much harder to then create independent scenarios that are still easy to read and then modify.

JOËL: Because you're coupling two things that are not the same, that want to diverge. And now you're forcing them down a single path. And I think probably the biggest, reddest flag you can get that you've misDRY-ed is where you try to introduce conditionals to your shared extraction. Because the whole point of a shared extraction is that everything is the same. And so once you start introducing branching in there, you know something's gone horribly wrong with your abstraction.

STEPH: Okay, so I think we've established that we've got very strong, maybe popular, unpopular opinions about DRY and especially using DRY in test setup. What's another unpopular opinion that you have, Joël?

JOËL: This one is a stylistic one. But I think that in Ruby, at least, every if should come with an else. You want something to happen when your condition doesn't trigger. I think it generally makes for more readable code and also prevents some implicit nils from getting through. And nil errors are probably at the top of your bug backlog if you were to look at right now (For all of you listeners, I'm pretty sure that's true.), excluding JavaScript.

CHRIS: Someday, we're going to make undefined a function, and it's going to be a great day. This is an interesting one, Joël. I'm inclined to agree with you, but I know that in my code, I don't necessarily follow this adage. So I find it interesting. I would call them intentional nils; I'm sometimes fine with that, or particularly in side effect-y code, you know, if this condition, then do something, otherwise, nothing.

But yeah, it is interesting. The explicitness, the nil, is a big mistake that seems true. You hang out in Elm for long enough, and you don't have one, and then you got to think about stuff harder. But yeah, I don't find myself doing this. So I find it interesting. I conceptually agree with what you're saying, and yet my code tells other stories.

JOËL: So I would argue that Ruby is an expression-oriented language; all methods auto return something as opposed to a statement-driven language like JavaScript, where nothing returns unless you explicitly return it. Ruby is all about those return values. And so you need to cover all branches, and if you don't, Ruby will implicitly have some branches that you don't have there. And so, I prefer to make visible the branching logic that's happening.

STEPH: I also like this one. I think I'm on the same page as Chris, where I like the opinion and this statement. And then also, you'd asked me earlier about whether something is capable now versus aspirational. And this feels like in the aspirational area for me where I agree with it, but I don't necessarily do it. But I think it makes a lot of sense because then it does force you to think about what is the return value? And to be very explicit and say, yep, no, I want a nil here. That's just what I'm going to return.

JOËL: And maybe even think about in that else case maybe you don't always want nil, maybe you'd rather return an empty string, or a null object, or something like that. And forcing you to actually manually type that value in instead of just being like yeah, Ruby knows. It'll put a nil there. It's easy to not think about the error edge cases, which I know is the opposite of how Chris thinks. Chris thinks about all the error edge cases.

CHRIS: My brain has been shifted by experience.

JOËL: One thing that I think this works really well is a stylistic approach that I use where I separate branching code from doing code. So in a particular method, if there is a conditional, then the body of the conditional calls out to another method. It doesn't implement logic there directly. And if a method does a calculation, or does the side effect, or does some kind of work, it's not allowed to have a conditional in it. So an individual method either gets to branch, or it gets to do a thing but not both.

STEPH: Is that so you can quickly see all of the branching that's involved so you can see it at a very high level versus if you have a very large branching in your method and then it's hard to see how many possible return values that you have?

JOËL: Yes. I like it because when you read code, especially when you're reading code that has a conditional in it, typically, you're reading it at a higher level of abstraction. You just want to know what are the possible ways that it can branch, and then what are the paths it can go down? And you probably don't care about all the nitty gritty implementation details that happen at each branch.

And then you might care about one particular branch and decide to go down that path. At that point, you will jump to that method. But you don't need to have all 2 or 3 or 10 branches expanded for you. It keeps the method at a single level of abstraction and also allows each method, in a certain extent, to have a single responsibility. It does one thing. It's either branching between n choices, or it does one thing, but it doesn't try to do multiple things.

So that's less of a hot take opinion, like, everyone should write code that way. That's just a style I've adopted for myself that works really well. But that particularly dovetails nicely with my hot take, which is if should come with an else.

STEPH: I like it.

JOËL: Yeah, so, Steph, do you have another juicy opinion you'd like to share with our listeners?

STEPH: Yeah, I've got one more to share, and this one is going to show my consulting roots. And it's that developers should be included in the design and planning phases, and not just in the execution phase of the work. So that's something that I've seen a number of teams struggle with where they wait until either design is considered completed or perfect or someone else has figured out the way that they want a feature to be built, and then they just essentially throw it over the wall and kick it over to the development team.

And so then it's laid out with very specific criteria. But it's not clear the problem that's actually being solved. And so developers have done a very narrow focus of what they're working on. And you just often end up building the wrong thing when that happens because people don't have the context. They don't know the questions to ask if they do run into some questions regarding the requirements.

And so I strongly advocate that developers shouldn't just pick up tickets and then write code, that they should be part of the planning and the product process as well. Turns out that developers often have really good ideas when it comes to features. And they also have a lot of knowledge about the application and can ask good questions. So why not include them in that process?

JOËL: You mentioned that this is inspired by your experience as a consultant. I've sometimes heard the contrast between the terms contractor versus consultant. Is that a distinction that you make?

STEPH: Yes and no. Yes, because I've heard other people make that distinction, but I personally wouldn't make that distinction. And even for people who are not a contractor or consultant but they're full-time, I still love when people can adopt the mentality of you have the same responsibility of this product and where it's headed and its technical decisions.

And we all should be mindful of the time that we're spending as we're working on something. And I think being a consultant helps you be more mindful in terms of like, oh, I've spent two hours on this problem. I should probably reach out for help. And I feel like people who haven't had an opportunity to be in that mindset don't think that way. But I think it's a really wonderful state to be in all the time just to think through; okay, I've been stuck for an hour, now's the right time that I should reach out for help. Versus spending like a full day on something and then reaching out for help.

So I have heard that distinction, but I personally wouldn't make that distinction. I would advocate that even if you are a consultant, or full-time, or contractor that ideally, you would still be part of those different processes to then help build a valuable product.

JOËL: Steph, I found it really interesting when you introed this idea. It was about developers bringing their ideas to the business and design side of things. But then, when you dug into the idea a little bit more, you kind of flipped it on its head and said that being involved in those meetings helps developers do their job better because now they can more appropriately timebox a feature or decide when they've hit that 80% point that's good enough to ship, and then they need to reprioritize something else. So it sounds like there are advantages to both sides, both the business side and the dev side, from a tighter integration there.

STEPH: Yeah, thanks for calling that out. I think that's an excellent point that I hadn't really even considered as I was just rambling about a strong feeling. But yes, I think it's beneficial to all sides. It's beneficial to developers who are getting the work done. And then I also think it's really beneficial to the product team and design just because that way, everybody essentially has the same context. They're on the same page.

And then you also have more camaraderie that way too in terms of people know the problems that they're trying to solve. And you can have more opinions. And people can surface those ideas versus if you are kept in the dark as to perhaps why a feature is being built or who it's geared towards, then it's more likely that you're not going to be as connected with the rest of the team and be able to provide helpful ideas because you won't have the fuller context to then surface that to the rest of the team.

So this is definitely coming just from all of my experience in the projects that I've been on that the most successful projects include design, and developers, and product management. And they all get together, and they talk about the problems that are being solved. Versus the projects that I've been on where essentially, all of that work is done separately, and then there's just a Trello board or Jira tickets or whatever tool that you're using. And then developers go and pick up tickets.

Because then you often end up having those discussions anyway because developers are then going to have to check in to say, hey, you said this thing. Did you mean this? What exact requirements am I looking for? By siloing that process elsewhere, you end up just duplicating your efforts because that conversation is ideally going to happen anyways.

JOËL: I recently had a conversation with someone who had been promoted to senior developer and was asking me for some advice on how do you be a senior at your job. And this is at a product company. And basically, what you were saying, Steph, is what I recommended. If, as a senior developer, you are just a machine that converts tickets into code, they're not using you to your full potential. And honestly, they're overpaying for what they're getting.

You need to be in those meetings, in those conversations, so that, as you mentioned, you can be that nexus between business and tech and tell them, look, this is your strategic goal. You think this is the technology thing you want to do. Yes, it will solve your problem, but it will take twice as long.

And that is incredibly valuable to the business people because doable and easy, and very similar solution that is near impossible to do in tech are very common. There's a classic xkcd about this situation. And so having someone who knows that nuance and can recommend and say, look, we can do this in two weeks. That will take six months. Or even just talking through trade-offs is incredibly valuable.

And then, as you said, bring that back in your own work, knowing when to say, look, we thought this is going to take two weeks, and it's taking more. We think this is going further. We know that the business goal is to get to here. So I'm going to pause on this and propose a different technical solution that will get us most of the way towards that goal while still respecting the deadlines we're working under.

I might argue that this sort of mindset is not just a senior developer thing. It's valuable at mid-level and junior as well. And I think that as a consulting firm at thoughtbot, that's something that we bring in from the beginning for everyone that we try to build this. But definitely, as you move up into your career, this is going to become more and more important.

CHRIS: Yeah, I'm surprised. I'm actually totally on the opposite side of this one. I fundamentally disagree with...no, I totally agree with everything you're saying and how important these sorts of conversations are. We're actually working on something at Sagewell right now. It's a new, reasonably large integration with an external platform.

And we're very, very intentionally pushing such that product and design are going off and doing some work, and engineering is going off and doing exploratory what do the APIs actually look like? What's the data that we need? What's the object model in this system? What can we get away with not providing? What do we need to provide?

And continually, we're just trying to encourage communication across those different tracks. So design is thinking about different flows and what's the experience a user is going to have. And ideally, getting engineering to review that and say, "Oh, that's going to be easy. That'll be hard. I think we could do that, but I actually have to go look it up and see if that's possible," and vice versa.

Engineering now being in the depths of saying like, "Oh, actually, this has to be done in this way for legal reasons or whatever it is," and then providing that back to design and product to think about how do we structure it? How do we sequence things? What's part of the MVP? And I've been really happy with the nature of that, that back and forth communication.

But it is definitely something that requires intentional work of making sure that we're not just falling into our own silos, but we're coming up for air, having those conversations, passing ideas back and forth, including each other in the conversations. But without question, it will produce a better outcome at the end of the day. So yeah, I actually do, in fact, agree 100%.

STEPH: Yeah, to add on to that just a bit, there is a particular example that comes to mind where I felt the most pain for when developers and product and design aren't in the same room and then discussing the work to be done. And that's essentially where someone ends up building the wrong thing. And it's because someone decided that they knew the best solution for something, but they didn't really collaborate with the rest of the team. They turned that into a ticket.

So then a developer sees that, and then they start implementing, and it's not until later that someone comes along and starts asking questions to say, "Hey, so what problem are we solving?" Or "Why are we adding this code?" And Joël, I think you said it perfectly and that this is something that I do expect of a more senior developer where they have that experience, and they ask those types of questions that then you realize that, oh, we've actually built the wrong thing, or the thing that we're building doesn't solve the problem that we had in mind.

And at that point, you have someone who has invested a week, maybe a couple of weeks into something, so then that feels really terrible to then say, "We actually need to scrap this" or "We need to totally rethink this." So then you start making trade-offs of like, well, maybe we can keep this portion or preserve some of the work that you've done. And so you just end up in a really messy state. And that can be avoided if people are collaborating at an earlier stage of that process.

JOËL: Yes, you and I, Steph, were in a very particular situation where something like this had happened. Some developer had been working on a ticket for a couple of weeks. And it was one of those tickets that just kept growing. The code kept growing, but then the client kept adding new requests and features onto it. And then, at some point, you and I were brought in to help, and the first thing we had to do is like, let's stop and ask what is the problem that is actually being solved here?

And actually got everyone together with the client. And that conversation helped us do a big reset and helped us find a way that was more focused that actually solved the underlying problem, what the client actually wanted rather than what they said they wanted.

I noticed that for most of these unpopular opinions, it sounds like we pretty much all agree with each other. So either we all have a very similar set of unpopular opinions, or maybe these opinions might be a little bit more mainstream than we give them credit for. I find that oftentimes, at least on Twitter, when people tag things as "unpopular opinion" in quotes, they may be a little bit more popular than people give credit for.

CHRIS: I feel like the RSpec one is unpopular. And also, have you asked Steph about Pop-Tarts?

JOËL: [laughs]

CHRIS: Because we are capable of having sincerely unpopular opinions.

JOËL: Let's save that for the next episode. And on that note, shall we wrap up?

CHRIS: The show notes for this episode can be found at bikeshed.fm.

STEPH: This show is produced and edited by Mandy Moore.

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

STEPH: If you have any feedback for this or any of our other episodes, you can reach us at @_bikeshed or reach me on Twitter @SViccari.

CHRIS: And I'm @christoomey.

STEPH: Or you can reach us at hosts@bikeshed.fm via email.

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

ALL: Byeeeeeeeeee!!!!!!

ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.

Sponsored By:

• Airbrake: Deploy fearlessly and fix bugs faster with Airbrake Error & Performance Monitoring. Airbrake notifiers are available for all major programming languages and frameworks, and install in minutes, with an open-source SDK-based install and near-zero technical debt. Spend less time tracking down bugs and more time developing. Visit Frictionless error monitoring and performance insight for your app stack.

Support The Bike Shed

Episode source