Vox

Leitura de 36 min

495: A shortcut to years of experience

Summary

Sally Hall and Aji Slater introduce the ThoughtBot Guides, a public GitHub repository containing the company’s collective, opinionated wisdom on software development. They describe it as a comforting place that avoids the common “it depends” answer, offering clear directives on everything from language-specific syntax to broader development practices.

The hosts discuss the structure and tone of the guides, noting their decisive language (“avoid,” “don’t,” “prefer,” “use”) and how they serve as a starting point, especially when venturing outside one’s familiar tech stack. They highlight specific recommendations, such as preferring detect over find in Ruby, avoiding ternary operators, keeping lines to 80 characters, and using resource routing in Rails. These guidelines are presented not as unbreakable rules but as distilled lessons from painful experiences.

A significant portion of the conversation revolves around the philosophy behind the guides. Sally and Aji reflect on how items like “avoid selective ownership of code” and “keep the code simple” promote a collaborative ethos and thoughtful design. They see the guides as a “shortcut to years of experience,” allowing developers to benefit from the ThoughtBot hive mind without having to learn every lesson the hard way themselves.

They also explore the living nature of the document, which is backed by discussions, pull requests, and linked blog posts that provide the “why” behind the recommendations. Aji shares a personal example of using the open-source project maintenance guide to help release her first gem, “Michelle,” which simplifies adding self-scheduling to healthcare applications. The episode concludes with both hosts expressing a renewed appreciation for the guides and an intention to contribute to them more actively.

Recommendations

People

  • Alan Turing — Referenced by Aji as her ‘absolute favorite mathematician’ and the subject of a talk she is giving about the Enigma machine and object-oriented programming.
  • Sandi Metz — Mentioned in passing regarding code complexity heuristics, specifically that jagged indentation (many levels) might indicate overly complex code.

Tools

  • ThoughtBot Guides — A GitHub repository containing ThoughtBot’s opinionated, decisive recommendations for building software across various languages, frameworks, and processes. Described as a ‘shortcut to years of experience.’
  • Suspenders — A ThoughtBot gem mentioned that bakes in many of the preferences from the guides when starting a new Rails project.
  • Michelle (gem) — An open-source gem created by Aji Slater that helps add self-scheduling functionality to healthcare applications, solving a complex query problem with specific indexes and a materialized view.

Topic Timeline

  • 00:00:00 — Introductions and personal updates from the hosts — Sally Hall and Aji Slater introduce the podcast. Aji shares excitement about an upcoming talk on Alan Turing and the Enigma machine for a Ruby group. Sally discusses her positive experience prototyping a data pipeline with new-to-her AWS services like Lambda and SQS, noting how much easier they seem to use now compared to the past.
  • 00:03:46 — Introducing the ThoughtBot Guides repository — The hosts introduce the main topic: the ThoughtBot Guides. They describe it as a GitHub repo of collective wisdom that provides clear, decisive answers, contrasting with the common “it depends” in software. The guides are organized as bulleted lists with direct instructions, using specific language like “avoid,” “don’t,” “prefer,” and “use” to convey the strength of each recommendation.
  • 00:06:23 — The utility of guides for unfamiliar stacks and collaborative processes — Sally explains how the guides are useful when working outside her primary stack, like with Sass, providing a quick, trusted decision without personal research. Aji adds that they also cover non-technical areas like code review, offering guidelines for both reviewing code and having your code reviewed. They discuss the principle of “avoid selective ownership of code” as foundational to a collaborative team ethos.
  • 00:11:23 — Examining specific guidelines and their underlying philosophy — The hosts dive into specific guidelines. Sally is pleasantly surprised by the recommendation for 80-character line limits. They discuss items like avoiding ternary operators and multiple assignments per line, seeing them as indicators of hidden complexity. Aji highlights the Rails guideline to prefer resource routing, which encourages thinking in terms of RESTful resources and can reveal domain model concepts.
  • 00:19:53 — General principles: simplicity, avoiding future-guessing, and built-in libraries — They explore broader guidelines. “Don’t write code that guesses at future functionality” is acknowledged as a common trap. “Don’t duplicate the functionality of a built-in library” emphasizes leveraging community-maintained code. The guideline to “keep the code simple” is discussed as a fuzzy but valuable touchstone, with specific rules in the guides (like class length limits) serving as concrete applications of this principle.
  • 00:26:57 — The guides as a distillation of hard-won experience — Aji posits that each guide item likely stems from someone’s painful experience, making the collection a “shortcut to years of experience.” They discuss how the guides are backed by links to discussions and blog posts, providing the reasoning for those who want it. This makes them useful not just for personal reference but also for facilitating deeper conversations in contexts like code review.
  • 00:30:17 — Open source guide example and releasing the ‘Michelle’ gem — Aji shares a practical example of using the guides’ section on releasing and maintaining open-source projects to help her release her first gem, “Michelle.” She describes Michelle as a gem that solves the complex problem of adding self-scheduling to healthcare applications by using specific indexes and a materialized view, a solution refined over several projects.
  • 00:33:36 — Conclusion and encouragement to contribute — The hosts wrap up, reaffirming the value of the ThoughtBot Guides as a collection of great advice and hard-won knowledge. They note it was fun to read them cover-to-cover for the episode and express intentions to contribute more to the guides through future pull requests and discussions.

Episode Info

  • Podcast: The Bike Shed
  • Author: thoughtbot
  • Category: Technology News Tech News
  • Published: 2026-02-24T15:00:00Z
  • Duration: 00:34:13

References

Podcast Info

Transcript

[00:00:00] Hello, and welcome to another episode of The Bike Shed, a weekly podcast from your friends

[00:00:14] at ThoughtBot about developing great software. I’m Sally Hall.

[00:00:18] And I’m Aji Slater. And together, we’re here to share a bit of what we’ve learned along

[00:00:22] the way.

[00:00:23] So Aji, what’s new in your world?

[00:00:24] So coming up for me, there’s a Ruby group in Northwest England that I’m going to be

[00:00:31] doing my Enigma talk for. And I’m very excited that I get to talk about Alan Turing and the

[00:00:40] project that broke the Enigma code during World War II on English soil. So that’s pretty

[00:00:46] nifty. I really enjoyed researching that talk, performing that talk, and I’m getting to dip

[00:00:51] back into it and make sure everything’s kind of up to snuff.

[00:00:54] And ready to go. So yeah, I’m pretty excited about that. Unfortunately, by the time this

[00:01:01] airs, that will be in the past, but…

[00:01:05] I’m so glad it went well.

[00:01:06] Thank you. Yeah, if you’re interested in seeing a talk about the Enigma machine and object-oriented

[00:01:16] programming, you can Google that one or find it on the ThoughtBot YouTube channel.

[00:01:20] We’ll link to it in the show notes.

[00:01:21] Yeah, there you go. We can do that. We have that.

[00:01:24] Thanks, Alan Turing. My absolute favorite mathematician,

[00:01:29] which is a very normal and cool thing to have a favorite of.

[00:01:33] Oh, absolutely.

[00:01:34] Alan Turing is probably a big part of why I tried to be a cryptographer right out of college and

[00:01:39] didn’t land. But yeah. What is new in my world is what you were about to ask me.

[00:01:46] It is.

[00:01:48] I am working on a project where we’re putting together like a quick prototype of basically,

[00:01:54] a data processing pipeline. And so I’m having fun with all these bits of AWS that I haven’t

[00:02:01] actually used before, like Lambdas, SQS, and DynamoDB, and API gateways. And it’s just like,

[00:02:11] honestly, I’ve been pleasantly surprised at how easy it is to use these things,

[00:02:14] because I feel like the last time I dug into new AWS tools was a long time ago,

[00:02:21] and they were not easy to use. And it was horrifying. So I’m in this,

[00:02:24] weird position where I’m like, am I having a pleasant and easy experience with new AWS tools?

[00:02:31] I mean, new to me, AWS tools. So that’s, that’s been nice, actually.

[00:02:36] Yeah, that sounds great. That is not the usual feedback that you hear of people exploring and

[00:02:42] branching out into AWS.

[00:02:44] Yeah, so good job, whoever made these slightly easier to use at AWS. I’m sure there are a lot

[00:02:49] of you and you did great.

[00:02:50] Yeah, that’s awesome. Yeah, there’s so,

[00:02:54] so,

[00:02:54] so many tools there. And I’ve only had the opportunity to use such a small fraction of

[00:03:02] them. And there’s so much power there that is usually incredibly difficult to work with. So

[00:03:08] I’m glad to hear it’s going differently.

[00:03:10] Yeah, yeah, it’s been nice. I’ve even, you know, written some permissions policy things,

[00:03:16] and that was, did not make me want to die. So yeah, excellent.

[00:03:21] I don’t know if Amazon’s doing better. I’m doing better, probably a little,

[00:03:24] a little bit of both. That’s probably true.

[00:03:26] Yeah.

[00:03:27] Take some of the credit there.

[00:03:28] Okay. Gosh, I’m smart.

[00:03:32] You do have a favorite mathematician.

[00:03:33] I do. That’s fair. I also have a math tattoo. So

[00:03:40] we’ll, we’ll save comparing nerdy tattoos for another episode. And I think we could

[00:03:46] get right to the chase. I had wanted to talk a little bit about the ThoughtBot guides.

[00:03:53] This is something that it’s a, just a repo published on GitHub. We’ll put a link in the

[00:04:00] show notes of words of wisdom. It’s a comforting place where no one ever says it depends.

[00:04:09] You know, I feel like so many answers in software are, it depends, which is always true,

[00:04:15] but it’s nice to go to a place where someone has, many someones have taken the time to think about

[00:04:20] it and gone, well, it’s this.

[00:04:22] Yeah.

[00:04:23] Just to be sure, we all say it depends many, many, many times a day in New York here at ThoughtBot,

[00:04:30] but these are a few things that we have thought through. Like you said, many of us over the years

[00:04:37] have thought through what the recommended way forward that is sort of the happy path that we

[00:04:44] have found as a company as we’re building out software. And so, yeah, it depends, doesn’t,

[00:04:51] doesn’t happen here.

[00:04:53] No. Yeah. It’s, it’s a well organized set of guides, really. What a good name that specify

[00:05:03] what we think you should do, what you should use, how you should approach things.

[00:05:09] Very straightforward. Most items are not even a full line.

[00:05:15] Yeah. Yeah. It’s essentially a collection of bulleted lists almost.

[00:05:21] And they’re all very direct.

[00:05:23] clear for example in the ruby guides one of the items is prefer detect over find yeah there’s no

[00:05:30] beating around the bush or saying well in these cases you want to do this or that which is

[00:05:35] i feel implied right we all understand that absolutely no one statement covers every single

[00:05:41] case right right there’s actually at the beginning of the guides one of the things that i like

[00:05:47] there’s a note on the the wording that is used throughout the rest of the guide being avoid means

[00:05:53] don’t do it unless you have a good reason don’t means there’s never a good reason

[00:05:57] prefer indicates a better option and it’s alternative to watch out for and use is positive

[00:06:03] instruction and that’s about it that’s all the kind of rhetoric that goes into these if there

[00:06:09] are incredibly nuanced situations they’re probably also not really in here these are for those

[00:06:16] decisions that might have to be made a hundred times and just an easy

[00:06:23] you

[00:06:23] path forward to a version that works yeah they’re a good place to go when i’m i find it especially

[00:06:30] when i’m you know venturing outside of my home stack so the things that are in you know the ruby

[00:06:38] and rails guides are mostly things that live in my head right but if i’m gonna go use python for

[00:06:45] some reason that’s not a good example because there’s only one item there i’m working on some

[00:06:52] sass right so

[00:06:53] sass i don’t use all the time but sometimes i do and it’s nice to be able to go and say like

[00:06:59] okay this says prefer mixins to extend so i don’t have to do my own research on those two different

[00:07:05] approaches and decide which one’s the better approach for my project because i’ve got decades

[00:07:11] of thought about experience behind this four-word sentence that answers that question for me

[00:07:16] yeah yeah it’s a great place to be kind of a jumping off point for unfamiliar people to go to

[00:07:23] your areas or to kind of check in really quick with the thoughtbot hive mind as to what has kind

[00:07:31] of gone into these decisions along the way it’s not really surprised that ruby rails is the thoughtbot

[00:07:39] go-to stack and so that is actually covered right up at the top the first link in the guides is

[00:07:46] about our preferred tech stack if you’re a thoughtbot follower or someone who works at

[00:07:52] thoughtbot you’re probably familiar with the thoughtbot stack and you’re probably familiar with

[00:07:53] i don’t think there’s going to be a lot of surprises in here we like ruby and rails we

[00:07:59] have a gem called suspenders that kind of bakes in a lot of these preferences that are mentioned

[00:08:06] in the guides to starting a new project we use postgres whenever possible things like that

[00:08:12] there’s also a lot in here that isn’t directly language and tool related right so there’s guides

[00:08:19] for like postgres but there’s also guides for code reviews

[00:08:23] how to review code how to have your code reviewed that are just as straightforward and clear and

[00:08:29] decisive and opinionated as our other and i find those really useful as well yeah i really love

[00:08:35] like you just said that there are not just code review guidelines for doing the review but also

[00:08:42] a little bit of helpful tidbits for having your code reviewed so both sides of this part of the

[00:08:50] collaborative process

[00:08:53] the code review section some of the things that really resonate with me are it’s a very short

[00:08:59] little line but avoid selective ownership of code and it gives a couple examples but i think that

[00:09:05] has always really stuck with stuck with me even from just glancing through these before i was

[00:09:10] with thoughtbot that taking the position of a shared ownership of a code base is where a lot of

[00:09:22] collaboration kind of

[00:09:23] stems from and a lot of the other guides lines in the guides about code review and such kind of

[00:09:30] come from that ethos a little bit that we’re all in this together and we’re all working towards the

[00:09:37] same goal yeah because really that’s the problem the fact that you’re doing code reviews means that

[00:09:43] your team is sharing ownership of the code right if you write a code and i review it and it goes

[00:09:47] into the code base like we both contributed to that even if i didn’t write any of it i’m not going to

[00:09:53] write any of it i am on board with it so if there’s a bug in it i can’t say your code broke this

[00:10:00] because i was on board with that code

[00:10:02] our code broke that right exactly yeah and we’re we’re all going to be maintaining it together so

[00:10:11] whether your fingers were the ones that hit the keyboard to put it into the pr doesn’t mean that

[00:10:18] you’re the only person that’s ever going to touch it and so we’re all sharing in this and we’re all going to be

[00:10:23] it might be someone else on the team that is going to have to change it or address something in the

[00:10:30] future it might be somebody that’s not even on the team but handling that situation not in the guides

[00:10:35] actually maybe it might actually be there might be a few things in here about legacy code so i’m

[00:10:42] gonna yeah scratch that that actually might be in there never mind yeah if it’s not maybe we should

[00:10:48] write it yeah this is an ever uh

[00:10:53] adjusting document as well there are recent updates to these these are not things that have

[00:10:58] been set in stone and kind of left as commandments or anything a long time ago this is a living

[00:11:07] document as to how thoughtbot thinks about building software as the guides say programming

[00:11:13] well and programming in style although not only about programming building software well and

[00:11:19] building software in style there you go so as we were looking through these

[00:11:23] is there anything that you were surprised by surprised by that that one’s a bit of a reach

[00:11:29] i was trying to see if there were some but i apparently am a little more familiar with these

[00:11:37] than i sort of expected either through reading the guides or just hearing them while pairing

[00:11:42] with other thoughtbotters this is a small one but i was a little surprised by i was pleasantly

[00:11:48] surprised by the recommendation to

[00:11:53] send lines at 80 characters and wrap lines at 80 characters i i do that obsessively and it’s not

[00:12:00] always necessary it’s not always in everyone’s kind of edit or configure anything like that but

[00:12:05] i really love being able to put several files next to each other in my view screen and so having that

[00:12:13] 80 character limit avoiding horizontal scrolling super helpful for me to be able to compare

[00:12:18] multiple files at once and i was pleasantly surprised to see that in there

[00:12:23] how about yourself i’m trying to i feel like there was something where i was like

[00:12:26] oh that’s not how i do that but i think that’s probably right

[00:12:30] you know i should have written it down maybe it was write down good ideas

[00:12:35] yeah but i would say that there are some things in here where i’m like i understand why we’ve

[00:12:45] made that assertion but that’s not how i want to do it yeah and i think the note on the language

[00:12:52] and different things that you’re talking about is that it’s not how i want to do it

[00:12:53] allow the opportunity for there to be differing opinions and different approaches

[00:13:00] that don’t necessarily go against the guides but kind of aren’t the 10 000 foot

[00:13:08] view recommendation like one that i see is not always conformed to i guess is to avoid

[00:13:17] ternary operators and avoid multiple assignment per line that is one that

[00:13:23] i really like and find myself pointing out now and then because i think that it is a little bit

[00:13:32] more than a stylistic choice to avoid ternaries it’s something that can expose some complexity

[00:13:40] a little bit if you have to write something on five lines for a quick if statement as opposed to

[00:13:48] sliding it all into one i think a lot of the times

[00:13:52] will

[00:13:53] choose a ternary because there’s a lot of stuff going on on the screen looking at the text of a

[00:13:59] file and to choose a ternary usually means that you’re kind of acknowledging that there’s a lot

[00:14:04] going on and you’re obfuscating it a little bit or trying to make it look a little easier

[00:14:08] but i think that’s one of those things that can be an indication that there’s too much going on

[00:14:15] and that might need to be addressed as you’re adding or changing whatever you’re doing in the

[00:14:20] file right now yeah that’s an interesting way of looking at it yeah i think that’s a good point

[00:14:23] of thinking about it that there it’s almost like a a way to disguise complex code as less complex

[00:14:29] code at the very least that’s what i’m doing in my head whenever i think ternary do i really want

[00:14:35] to put five more lines in here and if the answer is no then then maybe i should be rethinking how

[00:14:41] i’m putting the one line and that’s a lot of the guidelines that are kind of syntax related

[00:14:47] are things like that that the recommendation can

[00:14:53] open up maybe a deeper conversation or different different thoughts about how you’re approaching

[00:14:58] something they’re less the kind of thing that’s going to get picked up by a linter or an auto

[00:15:05] formatter i think there were more of those in the guides before those tools were as ubiquitous as

[00:15:12] they are but the ones that have stuck around are the ones that have a little bit more staying power

[00:15:19] essentially right they that they speak to something

[00:15:23] in our process right yeah and although the guides all each of these items is generally just a short

[00:15:31] line with the what to do but not why many of them link to either a pull request to the guides where

[00:15:39] people discussed it or like more in-depth explanation or i think i think it’s possible

[00:15:46] that some of them even link to blog posts so it’s nice that it’s like here’s what to do if you don’t

[00:15:52] care about why

[00:15:53] there you go if you do care about why here’s why yeah yeah exactly and i really do like that there

[00:16:01] are so many resources in the thought about blog that can be linked to from here probably a lot of

[00:16:09] these came out of blog posts or the other way around and so that’s all just right there for

[00:16:16] many many of these recommendations so something that also speaks to

[00:16:23] a deeper thought in a short phrase to me is the one in the rails page under the routes heading

[00:16:30] that says prefer resource routing over generating routes individually that’s it that’s the entire

[00:16:36] bullet but i feel like that contains multitudes right it is to think about your application

[00:16:43] in a certain way of resources that have restful actions as opposed to these kind of one-off

[00:16:53] actions that could end up getting a lot more complex or having to add a lot more actions or

[00:17:01] that some ideas maybe haven’t fully coalesced properly if you took the approach of thinking

[00:17:10] along the line of resources you might actually uncover some concepts in your domain model that

[00:17:16] can be super useful down the line yeah i find that every time i’ve encountered in something i’m

[00:17:22] working on i’m like oh my god i’m going to have to do this i’m going to have to do this i’m going to have to do this

[00:17:23] something i’ve written myself routes that are not resource routing and i feel like there have

[00:17:29] been times where you know you open a pull request and you’re like i know i shouldn’t have done it

[00:17:32] this way but maybe nobody will say anything and then somebody will like they should and then i’m

[00:17:36] like dang it i didn’t want to have to do the whole process of figuring out how to turn this into a

[00:17:41] resource but every time i do i’m like oh this is actually much clearer and much simpler and works

[00:17:47] much better for this use case yeah i definitely agree it’s something that is baked

[00:17:53] into rails at such a fundamental level and it’s it’s there for a reason and every time not every

[00:17:58] time but many times when i’ve kind of crossed that line i’ve recognized the usefulness of why that

[00:18:06] was there i find that that specifically is something that people who are experienced developers but

[00:18:13] new to rails get tripped up on i think the idea that you don’t have to manually specify the routes

[00:18:23] as explicitly as you do in a lot of other stacks surprises people

[00:18:28] so it’s not that they’re avoiding the resource routing it’s that if you’re not familiar with

[00:18:35] the resource routing it’s not a thing that feels obvious right yeah another one of the pitfalls of

[00:18:42] the rails magic that it requires a little bit of tribal knowledge or kind of familiarity with the

[00:18:48] framework before you can get the most out of it although the delight when people discover that

[00:18:53] it’s always very nice yeah yeah i agree another one along those lines is this is not in the

[00:19:00] rails section but in the general guidelines is to don’t duplicate the functionality of a built-in

[00:19:06] library and i think that comes up a lot in rails development that there might be another way to do

[00:19:15] it that is a little more exciting or have a little more comfortable api or something like that but if

[00:19:23] you’re not familiar with the rails version of a thing we think that you should prefer to use the

[00:19:27] railsy way to do it not only because it’s already right there in the framework but a little bit that

[00:19:34] it puts maintenance burden on the rails team and the community instead of having to do something

[00:19:40] yourself yeah yeah don’t create new maintenance burdens for yourself you’re doing that with every

[00:19:47] line of code as it is don’t do it more than you need to right yeah uh one that i really

[00:19:53] like in the general guidelines don’t write code that guesses at future functionality

[00:19:57] i find myself and other people get caught in that trap so often and like this is what the

[00:20:05] requirements are today but i imagine a near future where the requirements are going to be that so i’m

[00:20:11] just going to go ahead and write that which isn’t to say you shouldn’t consider the future right

[00:20:16] like you should be aware that things can change but i don’t think i’ve ever preemptively written

[00:20:23] a feature that was you know future functionality and gotten it right oh yeah 100 that probably is

[00:20:30] the thing you’re going to need but not the way you’re imagining it right now exactly exactly

[00:20:34] yeah and the way you can think about the future is doing good design hygiene is that a phrase it

[00:20:41] is now and building things with the ability to change later right you don’t have to guess at what

[00:20:50] the exact requirements are going to be

[00:20:53] yeah no that’s a that’s a great one that’s a great one another one in the general guidelines

[00:20:59] that i’m drawn to is keep the code simple and at first i maybe bristled a little at that thinking

[00:21:08] that well like simple is is fuzzy that doesn’t really help how like is this a useful point of

[00:21:16] view is this a useful like bullet for for this section and the more i thought about it and

[00:21:21] getting into complex things like that the more i thought about it the more i thought about it

[00:21:23] complicated back and forth with myself about what does simple actually mean i think that the

[00:21:30] fuzziness actually helps in this instance that it can be sort of a touchstone or a guiding star but

[00:21:38] it doesn’t have to be applicable to specific situations like right away this is the general

[00:21:45] guidelines and it’s something that you should kind of always have in mind but it’s not prescribing

[00:21:50] certain actions although there’s i

[00:21:53] feel like from that idea we do prescribe certain actions in the more specific guides right so what

[00:22:00] you were mentioning about like the ternary or multiple assignments in one line avoiding those

[00:22:05] i think is a way of keeping the code simple so even later sections of the guides are

[00:22:14] stemming from and paying attention to things that are said kind of higher up in the hierarchy

[00:22:19] so while getting into a complex thing like that i feel like from that idea we do prescribe certain

[00:22:23] actions that are said kind of higher up in the hierarchy so while getting into a complex thing like that i

[00:22:23] complicated diatribe about what simplicity means is not usually helpful and it would be a little

[00:22:29] ironic in this case this is the bike shed so right that’s what we got to do what are some things that

[00:22:38] that make something feel simple like how would this show up in in your thought process i think

[00:22:46] for me this guide is a way of helping make decisions should i do it this way or that way

[00:22:53] i look at them both and go which one feels more simple then that’s a point in that favor of that

[00:22:57] one things that make code feel simple to me are well-named variables and functions and objects

[00:23:07] single responsibilities things that just do one thing yeah it should be easy for someone who you

[00:23:15] know is familiar with the language at least to come in and look at this code and go okay i generally

[00:23:20] understand what this code is doing yeah yeah

[00:23:23] if you’re doing something that feels clever syntactically clever it’s not simple like that’s

[00:23:29] not i don’t want that here it’s true it’s true every time i get that feeling of like oh i did

[00:23:36] something neat i feel clever with that i give myself the points and then redo it in a more

[00:23:45] readable way yeah copy that into your little like things that make me feel smart repo and then

[00:23:51] yeah

[00:23:53] which is also smart oh i like that it’s this quote that i reference and can never remember

[00:23:59] who said it but the idea of like this letter is so long only because i haven’t had time to make

[00:24:04] it shorter applies to code too like this code is so complicated because i haven’t had time to make

[00:24:10] it simple right making complex ideas and interactions simple in the code is incredibly

[00:24:19] difficult it’s very challenging and that’s i i feel like

[00:24:23] that’s the sign of a really great developer like i when i see someone on my team who

[00:24:27] can do that and make it look easy and they’ve got you know they’ve solved what felt like a really

[00:24:33] difficult problem in a pr and you look at the code and you’re like this makes so much sense

[00:24:37] and it’s very easy to read and clear what’s happening like that is someone i’m very excited

[00:24:41] to work with because that’s not easy to do and no doubt there are many many squash commits that

[00:24:47] make it look that easy because it is hard like you’re saying yeah yeah i doubt i doubt that was

[00:24:52] the first attempt to make it look that easy because it’s so hard to make it look that easy

[00:24:53] you make it work and then you make it simple yeah there are some other things like kind of

[00:25:00] peppered throughout the guides that i like that i think kind of fall into the idea of what simple

[00:25:06] is or little indicators or flags that something might be more complex than you think it is i think

[00:25:15] actually a lot of these that is maybe one of the reasons why they’re in there it’s because you can

[00:25:22] solve something in dozens of different ways we’re going to give you this guide here because we found

[00:25:28] it shows you when you’re being complex right some of these are like do it the harder way around

[00:25:34] because that will show you if you’ve gone the really hard way around without realizing it and

[00:25:41] then just some other things like there’s one in the i think object-oriented design page that was

[00:25:48] when a class exceeds 100 lines it may be doing too many things

[00:25:52] and in ruby seeing a ton of punctuation these are things that like send my simple sense off

[00:26:00] they’re not wrong in any way but they they are like let me think about this a little bit more

[00:26:05] yeah yeah i think sandy one of sandy metz’s measures is like levels of indentation

[00:26:11] if it’s real jaggedy on the left hand side it might be too complex

[00:26:16] yeah and there’s another one in here that seems very superficial that i think

[00:26:22] speaks to that exactly about not using the inline class definition with like colon colon

[00:26:30] but to actually nest and that is one of those things that it seems incidental but if that

[00:26:39] makes things indent quite a bit then at the very least you are very aware of that decision

[00:26:46] if that’s the way that is the best way forward you’re kind of making it with all of the things

[00:26:52] obvious right it’s explicit it’s right there this feels like the more i look at this this

[00:26:57] feels like a shortcut to years of experience at these lists you can see every single one

[00:27:04] of these items probably has behind it some real painful moments of someone not doing this

[00:27:12] encountering problems and realizing oh i should i should just do this most of the time

[00:27:18] so it’s sort of a distillation of and again going back to like if i’m

[00:27:22] looking at the guides for a stack i’m not familiar with right it’s sort of a distillation of

[00:27:28] lessons probably learned in the hard way by other people that i can shortcut to that’s great that

[00:27:34] that is really how i feel about a lot of these and like you’re saying before if you don’t in

[00:27:40] the moment need all of the explanation or logic behind it or anything you can just kind of follow

[00:27:46] in that experience and know that there is a lot of logic and explanation behind it

[00:27:52] being the kind of person that i am i’m always going to read this though i i’m always going to

[00:27:57] wonder about the why absolutely yeah because because the guide said so is is almost never

[00:28:03] enough for me it it is usually enough for me well it oftentimes is enough for me but whenever i want

[00:28:12] to bring that up with someone say in code review and i’m i’m never just going to stop with well

[00:28:20] the guides say so and that’s where the code review is going to be and i’m never just going to stop

[00:28:22] linking to the blog post linking to the pull requests and kind of the supplemental information

[00:28:28] can come really in handy then because if you want to have a deeper conversation about a decision in

[00:28:35] the code then there is usually a easily digestible reference so that you can start with the same kind

[00:28:42] of understanding and jumping off point as you discuss the more specific case of the one that’s

[00:28:48] actually in your code base yeah and that also allows for

[00:28:52] you know i am familiar with the guides understand where they come from and trust them so although

[00:28:59] i’m curious and want to know the why i don’t feel like i need to read the why to be convinced that

[00:29:04] this is good advice yeah that’s another good point yeah but i work with that but

[00:29:09] right if i’m collaborating with someone who doesn’t work with that but or isn’t familiar

[00:29:16] with that but and i try to just say well the guides say to do it this way their very valid

[00:29:22] response might be to do it this way and i try to just say well the guides say to do it this way

[00:29:22] and it might be that is a random github repo i could write whatever i want to in a random github

[00:29:29] repo and tell you this says this so do it so i think part of the usefulness of the guides

[00:29:37] comes from both the many links backing up these assertions right so like the pr discussions or

[00:29:47] the examples or some of these link to the ruby guide or the rails guides themselves things like

[00:29:52] but also your relationship to thoughtbot or your trust in thoughtbot as a useful source

[00:30:02] which obviously my opinion is it is a useful source i think we’re fairly good at this stuff

[00:30:09] not to toot my own horn but toot are there any others that you wanted to kind of pull out and

[00:30:17] highlight as we’re sort of breezing through towards the the end of our troll through the

[00:30:22] guides

[00:30:22] one that i found recently helpful and that i’m now realizing i maybe should have had a different

[00:30:27] what’s new in my world is there’s a section on releasing and maintaining open source projects

[00:30:34] it mostly talks about how to accept a github pull request for an open source project like

[00:30:42] line by line commands for doing it but i found this incredibly useful recently when i released

[00:30:48] my first ever open source gem michelle michelle

[00:30:52] tell me about it if you’re familiar with gilmore girls you may be familiar with

[00:30:56] michelle gerard the front desk person who is really unpleasant to have to schedule an

[00:31:02] appointment with which is what you want in a front desk person yeah so michelle is a gem

[00:31:08] that helps build helps you put self-scheduling into your health care application

[00:31:15] oh so in our experience i’ve seen you know built apps that integrated with various ehrs electronic

[00:31:22] and those are not built for self-scheduling all of the scheduling functionality and most

[00:31:28] healthcare software assumes that there is a human being on the phone

[00:31:32] but with a lot of these applications self-scheduling is a really important feature

[00:31:39] right it lets people i don’t like talking on the phone right or maybe i want to schedule an

[00:31:45] appointment and the only time i’m able to sit down and look at my calendar is the time when

[00:31:49] the people on the phone are not at work right so it can really help open up your

[00:31:54] healthcare situation to more people but going through all of the providers you have and all

[00:32:01] the locations you have all the different kinds of appointments they offer and then knowing okay we

[00:32:07] start appointments on the 15 or on the 30 is a lot to wrap up into a single http request

[00:32:15] right it takes a while to figure all of that out i’ve been in a couple projects

[00:32:19] where we tried different approaches and ended up having to table the self-scheduling feature

[00:32:24] and finally we landed on something that worked really well which was a bunch of specific indexes

[00:32:30] and a materialized view which was complicated to figure out but once we got it was really helpful

[00:32:35] so i’ve extracted that into a gem so that if you want to add self-scheduling to your app

[00:32:40] you don’t have to think through the horrible sequel

[00:32:43] and can have a query that quickly will answer

[00:32:49] you

[00:32:49] when can i see a doctor wow yeah that is such a ubiquitous problem to solve that never seems to

[00:32:58] have something that’s easily at hand to solve that so i’m really excited that there is something

[00:33:03] that can get you all of or most of the way there that we can just reach for and plug into new apps

[00:33:09] because i feel like that’s something that i’ve tried to solve over and over again so i’m pretty

[00:33:15] excited about that and the open source guides helped me a little bit with that so i’m really

[00:33:19] excited about that and the open source guides helped me a little bit with that so i’m pretty

[00:33:21] excited about that and the open source guides helped me a little bit with that so i’m pretty

[00:33:21] excellent excellent yeah not just syntax not just uh code review but there are a lot of great little

[00:33:29] bits of advice and hard won pieces of knowledge here in the thoughtbot guides and so i think

[00:33:36] they’re they’re great tools there’s something i reference a lot and it was it was really fun to

[00:33:41] have the encouragement of doing this episode together to read them cover to cover yeah

[00:33:48] absolutely

[00:33:49] and i’m gonna try to remember to contribute to them more yeah i took a couple of notes and

[00:33:55] hopefully they will make their way into prs which will then have long discussions that we can

[00:34:01] link at the end of the bullet when we merge it sounds wonderful excellent should we wrap it up

[00:34:08] i think that’s a wrap

Visão de gráfico