351: Learning in Public

It's Joël's first episode as host of The Bike Shed! 👋

Joël has fellow thoughtbotter Steve Polito join him to talk about the benefits and drawbacks of "learning in public" and how there are many, many different ways to do it.

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. I'm Joël Quenneville. And I'm joined today by fellow thoughtboter, Steve Polito.

STEVE: Hey, Joël. Thanks for having me; excited to be here. And congrats again on the new hosting gig.

JOËL: It's exciting to record with my first guest, and I'm excited that you get to be a part of this. And together, Steve and I are here to share a little bit of what we've learned along the way. So, Steve, what's new in your world?

STEVE: Well, on the professional side of things, I've been working on a Rails backend application that connects to a React frontend. And specifically, it's in the healthcare space. My biggest, I guess, struggle but also [laughs] thing that I've learned the most from this project is working with an inconsistent API can be very challenging. And that's been the consistent theme with this project.

But from that, I'm learning a lot. Because prior to this, I'd done a lot of work with just traditional CRUD apps where it's just all-encompassed in the Rails application. So you're kind of in control of everything. This is my first time where we're very much dependent on a third-party API. I'm learning a lot, but it can be challenging at times. But we've gotten in a space now where it's a lot more predictable, and therefore, working with it is easier. That's on the professional side of things.

Personal side of things, I, for whatever reason, decided to run a marathon in September, which means all of the training has to happen in the heat of the summer. I live in New England, and it's been unbearably hot the past two or three weeks, which means training has been unbearable. [laughs]

JOËL: Ouch.

STEVE: Well, I mean, that's what I get for signing up for a marathon at the end of the summer. So I look forward to just working with the unreliable API versus [laughs] doing this right now. That's what's going on with me. What's going on in your world, Joël?

JOËL: For long-time listeners of the podcast, they'll know that former host, Steph Viccari, has been working on a slow test suite. And part of that work has been converting some old Test::Unit tests over to RSpec. I've been working on the same project with her, and so the saga continues.

One of the really frustrating aspects of this work has been the Test::Unit tests rely a lot on fixtures which are just full of mystery guests. The fixtures that are just loaded at the top of the file refer to a few thousand records in the database, most of which are not relevant to the test that I'm trying to convert over.

The problem is that I don't know which ten records, you know, which two users out of the 100 defined in the fixture file are relevant. They're not referenced directly anywhere in the test. But if the RSpec conversion that I do fails, it will break because some user is not present in the database. And so I need to reverse engineer the code and figure out what is missing, which user record is just assumed to be in the database.

STEVE: Yeah, that sounds frustrating. Honestly, until working at thoughtbot, I didn't quite understand the concept of mystery guest. Because when I learned Rails, I just did the Michael Hartl Rails Tutorial, which, in an effort to make it as easy as possible, he just kind of does vanilla Rails. So there's no Factory Bot or RSpec, for example, and it's all fixtures. And it works very well for teaching you how to build and test an application without getting bogged down with too many of the extra things that come along with that.

So I always thought, okay, fixtures, cool, no big deal. Why does everyone always use Factory Bot?[laughs] Like, what problem is this solving? And I'm realizing now because I've run into this too, the issue that it’s solving is this mystery guest, so that's one of the issues that it's solving. And that's just one of those things that I didn't really appreciate until I would run up against it in a similar situation you're describing now where you're writing a test. It might even be a very simple test, right? Like five lines or something, and you're just expecting something trivial to happen.

And it's failing, and it's failing for the wrong reason. The message is so cryptic. And you're just like, what is this thing talking about? It's like referencing something that has nothing to do with the test. And that pain right there is the pain of a mystery guest. I just didn't have a name for it until listening to these episodes. And now I can appreciate why you want to avoid that type of stuff and also why Factory Bot is helpful for that.

JOËL: I think it's the kind of pain that tends to bite you more when you're modifying the tests later on than when you're writing them upfront. And since now, with the work that I'm currently doing, it's all modifying existing tests, I'm feeling this pain on a daily basis. Does that track with your experience as well?

STEVE: Yeah, pretty much. And then what ends up happening is you're working on a feature, and the test fails for the wrong reason. And then you realize 30 other tests fail for the wrong reason. And then, before you know it, you've spent four hours going down a rabbit hole to clean up the fixtures, or the mystery guests, or the implied setup that might be shared across other tests. It's just such a momentum killer, first of all.

You're in this headspace of like, okay, here's the feature I'm working on. Let's just bang this out real quick; no big deal. I want to go to lunch in a couple of minutes. [laughs] And then you're trying to fix this test because it's failing for the wrong reason. And then you keep pulling the string, and you're like, oh, okay, well, there must be a mystery guest or something, but that took like 20 minutes to figure out.

And then you figure that part out but then maybe fixing that mystery guest involves either updating that particular fixture, which could then fan out and cause other tests to fail because it depended on that fixture to have certain properties. Or you have to create a new fixture. But if you create a new fixture, there's now an extra record in the database. And that could break other tests because they are maybe expecting there to be a certain set of users and other things.

But that's just one of those things that early on, I would listen to episodes like this or hear about mystery guests, and I would be like, I just don't get what they're talking about. If you have a few fixtures, how is that so hard to keep straight in your head? And sure, at first, it's not a big deal if you have maybe two fixtures or something.

But then it quickly just reaches an inflection point where either there's more than one person on your team, or you have to add more fixtures or whatever. And then it just reaches an inflection point where it's just not sustainable anymore. And that sounds like that's obviously the point at which this project is at, and that's where you're trying to rein it back in.

JOËL: Yes. So it's definitely making the conversion from Test::Unit over to RSpec more difficult. I've been trying something a little bit clever to try to figure out what data is actually needed because that's my core problem. I have a Test::Unit test that doesn't define any initial setup data. It just assumes that data has been created by fixtures at some point. But there are thousands of records in the database. So which ones do I need to port over to this setup phase of my RSpec test?

What I've been doing is hooking into Active Support notification and watching the records that get read from the database from the Test::Unit tests. And that can tell me, oh, it's these ten that this particular test is using. Those are the ones you're going to need to convert over to your setup block.

STEVE: That's clever. I like that. So you were just looking at the logs essentially. Or did you have to do any puts statements or anything? Or was it just the default internal logging mechanism that Rails has under the hood?

JOËL: The simple version of this would be to look at the logs, so tail the test log file. I'm trying to be a little bit fancier and hooking into Active Support notification, which is something built into Rails that allows you to just listen to certain events in the system and then do actions based off those events. So I can subscribe to any database read and then say call this block when a database read happens. And in that block, I can then update a stats object that, over the course of the test, will then tell me what objects have been read from the database.

STEVE: Oh, okay. That's clever. I'm glad you shared that too. Based on this discussion of mystery guests, I feel like that's just a good use for that tool. I almost wonder if there's an opportunity not even to abstract that because that'd be too much work and overkill, but just, I don't know, make like a gist or something and just reference that for the future.

Because I feel like this is the type of thing that other people are going to run up against...or maybe even a blog post or something because it's just like, if nothing else, it would be good for future Joël to be like, how did I do that again? Oh, yeah, here it is. Like, it's in this blog post I wrote six months ago. So I could just copy and paste the code snippet and call it a day.

JOËL: It's funny you mention blog posts because we have a lot of these conversations internally at thoughtbot. And without fail, someone will eventually comment, "This is great content. You should turn it into a blog post," to the point where we now have an emoji reaction for you should make this into a blog post.

STEVE: Right. That's what's really maybe special about the software industry is there's just a lot of knowledge share built into it just with open-source software, for example. I mean, that's already a form of knowledge share. It's not a blog post, but it's a form of knowledge share. And I just think getting into a habit of just sharing these little artifacts, big or small, whether it's a blog post or just a code snippet, is really helpful for a variety of reasons.

But one, and in this case, to go back to the issue that you've been facing on the client work is you just explained...We talked about a lot of things; two of them were like, what's the mystery guest? That's helpful for some people to know because until very recently like I said, I didn't even really understand what the pains of mystery guests were. And then, we also talked about a potential solution to that.

So a naive approach is tailing the logs, but then you took it a step further with that clever solution to use that notification object. And if we weren't recording this right now, that might be lost in the ether forever. Maybe the people you're working with on your team would know about it, but that would kind of be it. So I think there's an opportunity for you to maybe abstract that into like a code snippet or blog post or something and just store it away for later so that future Joël or another developer can learn from that.

JOËL: That's a really good point, Steve. Creating public artifacts like that is a form of...I've heard it referred to as learning in public before. And that's actually a topic that I think you've really demonstrated mastery of. You are great at sharing the things you've learned or even the questions you have with your colleagues, and the team at thoughtbot, and the broader developer community. What was your journey into starting to share in public like this? Because I know it can be really intimidating, especially for someone who's early in their career.

STEVE: Yeah, that's a good question. So a very brief background on my career history is I'm not classically trained, so to speak, and I'm doing air quotes for those listening. When I say, I'm not classically trained, what I mean is I went to school for graphic design. And there was some overlap with web design, obviously.

But I ended my collegiate career really just knowing how to use Dreamweaver and knowing a little bit about HTML and CSS and barely anything about JavaScript, and I didn't know anything about server-side languages. That was my base. And I was fortunate enough to get a job at a small WordPress agency. I got really good at understanding WordPress and how to configure a website and then making it look like the Photoshop document.

JOËL: There's a shocking amount of the web that runs on WordPress.

STEVE: It's a huge amount. And what's nice is that it doesn't...as you just heard, I didn't have a lot of experience with making production websites. So WordPress made it easy enough for me to get my feet wet. But I would run into a lot of problems. And I was the only developer at this agency, so I couldn't turn to my co-worker and say, "Hey, can you take a look at this real quick?" It was just me and Stack Overflow. That was it.

The reason I'm saying this is because Stack Overflow and being the only person at the agency forced me to learn in public but from a different mindset. I wasn't necessarily learning in public; I was desperately trying to solve a problem by the end of the day. And it just happened to be in public because I would have to either go on Google or Stack Overflow or forums to find the answer.

JOËL: So were you asking questions on these sites then? Like, you were going into a chat room and asking questions or going to Stack Overflow and asking questions.

STEVE: Yeah. If I couldn't find a solution quickly, I would just go on there and just shamelessly ask questions which they were, in some sense, naive questions. Looking back at them now, it clearly highlighted that I didn't understand the fundamentals, but that's okay because I know I didn't. [laughs] And I'm sharing that with everyone right now, so it's not like it's a secret. Because that was the only way I was going to figure it out, like I said. And I didn't have anyone at that agency to ask for help.

So that got me into the mindset of just ask for help. But it also got me into a mindset of...one thing was, okay, I can't just paste the entire error message, like, the entire 3,000-line error message from the logs onto Stack Overflow. That's not going to help anybody. No one's going to answer that question. I needed to start to get good at distilling down the problem into its smallest part to then be able to share it, so I would at least incentivize someone to answer it versus pushing them away because who wants to read a non-formatted log file dump?

JOËL: That is a skill in and of itself.

STEVE: Yeah. I mean, it took time, don't get me wrong. And at first, I was posting those [laughs] giant log files. I would just say, "Hey, can you help me?" [laughs] And it's like, there's no context, and it's just 3,000 lines of gibberish. So obviously, I quickly learned, well, I got to make these bite-size. But then, from there, I slowly learned over time thanks to the community, and just the advent of the internet, and searching and everything like that.

But then I got to a point where I was confident enough with the skills I was learning that I wanted to start giving back and if nothing else, it was really just to help future Steve. So when I would run into an issue that I couldn't solve, typically at this point, it was like WordPress or Drupal issues. Once I was able to solve it, I would then write up a blog post with that solution, and they were very simple posts.

And just by chance, they happened to be very search-engine friendly because I would just, like, the title of the post would be basically the error message or how to do X in Drupal. Obviously, as a software developer, no shortage of problems, right? Like, every day, you're going to run into something that you actually just do not know the answer to. So I would just amass dozens of these problems. And if I found one interesting enough, I would post about it. And I just got into a habit of that because, like I said, if nothing else, it helps me for the future.

But then it's also nice to know there's certainly going to be someone else out there who has the same issue. And it's kind of exciting to think someone on the other side of the globe is going to possibly search this thing and maybe land on my website or something, just like I have done countless times where I've put in something into a search engine, and I land on someone's website, typically the thoughtbot website, [laughs] and I read the solution there. So it's exciting to be part of that.

JOËL: Were you ever afraid that somebody else would come along and tell you your solution is wrong?

STEVE: I wasn't necessarily afraid because that comes with the territory. Honestly, fortunately, I've never really had a situation where someone was outright mean or disrespectful. For the most part, I find folks are very helpful. But it does help like I said, if you distill those questions down and make it simple for someone to help you with. But yeah, I mean, that is one of the...I don't want to say risks, but that comes with the territory of learning in public, which is you might face criticism.

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: One thing that I really appreciate with some of the things that you share on social media is kind of like what we say here on the show, sharing a little bit of what we've learned along the way. So you get to follow Steve's journey. And it's like, I'm trying this problem; here is the solution I have so far. It seems to solve some problems, not everything. Tune in tomorrow to hear how the problem keeps developing.

STEVE: Yeah, exactly. That's kind of why I try to make sure I'm giving back at least half as much as I'm taking, so to speak. So in these transactions, like on social media, I'm stumped on something or maybe not even stumped, but I'm just, like you said, exploring an idea. And I want to have it peer-reviewed, so to speak. I mean, in some ways, some of these things are almost like a Twitter code review, right? It's just like, instead of having the formality of doing it on GitHub or whatever, it's just like, here's a snippet, quick gut check here.

And then what's nice is that people are nice enough to respond with what they think. They'll reference other posts or other projects that might touch upon that. And what's nice and what I hope is happening with these exchanges is maybe someone learned a little something about what I just posted. Because I know that I'm certainly learning something from the feedback I get.

And then again, it's almost like code review. You get this nice history of what this idea is about and then different stances on it. And then it just sort of serves as a little bit of a learning tool right there. And then yeah, I'll try to follow up later on, like, hey, here's where I landed now. But maybe it's a little more fleshed out.

JOËL: What are maybe some drawbacks of this concept of learning in public? Are there some reasons you might not want to or not be able to do this?

STEVE: I do think there are...maybe not drawbacks, maybe just risks. An obvious one I can think of is if you're working on proprietary software; for example, you legally probably can't share anything that you're working on. So that makes it challenging because you can't just straight up take a screenshot of your editor [chuckles] and be like, "Hey, look at this cool thing I'm working on today."

That adds a little bit of a roadblock because then you probably have to simplify it or, I don't know, anonymize it in a way that it's just generic. So it just adds a little bit of extra work. But in some ways, that might actually be a good thing because then you've simplified the problem to its purest form, so to speak.

Another drawback we kind of touched upon is you're opening yourself up to criticism, that can be a challenge. Everyone communicates differently. People may not want to use Twitter, for example, to learn in public. They might just want to have a personal blog and do it that way.

JOËL: Turn off the comments.

STEVE: Exactly. Turn off the comments. If you're someone that is hesitant of criticism or just being on social media in general and all that, learning in public can be whatever you want it to be. So what I mean by that is we talked about Twitter and social media. That's kind of an obvious way to learn in public. But another way is you could just have some GitHub repos or your own personal blog, you know, things like that.

What's being implied here is learning in public means, like, public, anyone could access it. But I want to challenge that because public could mean different things in different contexts. So at thoughtbot, for example, we have our dev channel, and people post there all the time. And that's public in a sense, but it's not public to the world. So it's a little more controlled. You know that you're going to get helpful feedback. It's a safe space to do that.

So I would encourage folks listening now that work in an agency or just work in software development in general see if you can create your own dev channel at work or something like that if you don't already have something like that because that's a good way to, I guess, encourage people to learn in public.

JOËL: I love that you're redefining public a little bit here and the idea that public could just mean your team at work or your company. That's a concept that I really like because now maybe it's a little bit less intense to share with them. And it can be something as simple as today I learned. It could be a question about a particular technical thing, or here's the thing I did; it works. Is there a better way to do it?

STEVE: Exactly. If you think about it, code review is a form of learning in public that's built into our day-to-day job because it encompasses a lot of these things. You have to be...I don't want to say ready to take criticism, but it's very common to open up a PR, and you're going to get feedback on it.

The reason I'm hesitant to say criticism is there's a connotation of just criticize me and the person is being rude or something; I don't mean that. I just mean someone who is being critical of your work in the sense that they're making sure it meets the requirement. And it is quote, unquote "good code" given the constraints. So you have to open yourself up to criticism that way.

You're also creating these little artifacts because, in code review, there's going to be a back and forth. Someone might suggest a change; someone else might praise or just give you a shout-out to be like, "Hey, I've never seen this before. I've never seen this method before or this pattern before. This is really neat. It reminds me of something I learned over here." And they might paste a link to something else.

So yeah, code review is a form of learning in public. It's like a very controlled, simplified version of that. And it can also be a good source for learning in public through social media. Because then from that, you get this distilled concept that you can then share to the world or just at work with other people that may not be on your team.

JOËL: thoughtbot has a few, I think, different cultural things that we like to do that all converge on some of these ideas, one being that we have dedicated investment time to try to improve ourselves. Two being that we try to share anything that we create as publicly as possible. So default to making something publicly available unless there's a good reason to keep it private which is the opposite of a lot of companies.

And then finally, bringing that all together, trying to, in the things that we learn, in the work that we do, pull out shareable artifacts. So if you're reading a book, if you're working on a project, is there something tangible you can pull out of it to share back with the team or even the broader world? And that might just be dropping, "Today I learned this," in our dev channel. It might be putting up a little proof of concept repo and publishing it publicly. It might be, as you mentioned earlier, writing a blog post about a cool technique that you found helpful on a project.

So we're constantly trying to find ways to take anything that we've learned and not just make it a personal thing but also try to sort of multiply that to, at the very least, our team but where it makes sense also the broader dev community.

STEVE: Yeah, exactly. I don't know about you, but I feel like there are a lot of similarities with learning in public in their many forms with open-source software. Because open-source software is basically learning in public, right? For folks listening who might be hesitant to start getting in the habit of this, I would just encourage you to look at any popular repository and look at all the open issues.

And what I mean by that is these popular repositories that are used by millions of people they're not perfect. Like, they didn't get it right on their first try. And you can read the source code and you can see everything about it. And it kind of embodies learning in public in that way. So it opens itself up for criticism but also praise. And then it's also just a resource there where you can learn from it.

There are so many times where I'll open up the Rails, like, I'll just go to the Rails source code, not because I need to but because I'm curious, like, how do they do that particular thing? Like, the other day, we were working on something where we had an object or a class, and we wanted it to have two class methods, one called perform, and one called perform with an exclamation point. The details of that don't matter, but I was just kind of like, well, that reminds me of Rails with destroy and destroy with an exclamation point.

And I just want to see how do they do that under the hood? Like, not every single detail, but just how does the destroy method with the exclamation point, like, does the call destroy under the hood? What does it do? And I was just like, well, let's just see what Rails does. And we can kind of copy that pattern for what we're doing over here, which was great. And, again, that wouldn't have happened if we didn't have open-source software, which, again, I think is a form of collective learning in public. It's like, it's the source. It's a result of many people working on it.

JOËL: Even for projects that have only a single author, I think there can be a lot of value there. Long-time listeners of the show will know that I'm a big fan of the Elm programming language. And I've participated in a few Game Jam events where you have a deadline, typically a few days or maybe a month, to create a game based on a theme. And I've built some games using Elm. Later on, people will ask me about particular patterns that can be used in Elm, maybe related to games, maybe not related to games.

And I've been able to link them to parts of that open-source code for the games that I built, which are built under pressure. They're not always great quality. But I can link to a particular section of the code and say, "Here's the pattern we were talking about." And that can spin off a whole conversation.

STEVE: Yeah, that's just one of the many advantages to doing these things. And I should also say, too, you say that I'm good at learning in public, but the same goes for you too. I mean, you're constantly sharing things in the dev channel, writing posts. I want to recognize that too because I think that's a skill that you've also mastered. So I appreciate that.

JOËL: Thank you.

STEVE: You share as much as you do, especially because you have significantly more experience than me. So again, to circle back to the mystery guests, I would hear you talking about mystery guests. I've heard other experienced devs talk about it. But a year or two ago, I'm like, I trust these people. Like, I really trust them. They're smart. They're credible. They have more experience. But I just don't really get what the problem is because I haven't actually experienced it firsthand, but I at least knew to be aware of it. And it was in my back pocket, and I could take it out when I was ready to do a deep dive on that.

So if it weren't for things like this podcast or blog posts or other things like that, I feel like the dev community wouldn't be nearly as...it just wouldn't be at the level that it is now. And I don't mean necessarily even Rails; I just mean software development in general. Imagine if all programmers just worked in isolation and couldn't use information from other developers or imagine that in any career, right? Physicians...imagine if they couldn't do knowledge share.

So I just think being in the software industry, it's just easier to share what you're doing because we make the internet in a way. So it's like, we're already on the internet all day, so we might as well just sprinkle in what we're learning.

JOËL: I have a personal note in my notes. It says that the best knowledge is created in the connections between people. So if you're imagining a graph where people are nodes, and the connections between them are edges, all the best ideas are on those edges where interactions happen between people and not just solo geniuses.

STEVE: Exactly, exactly. I like that.

JOËL: Power of collaboration.

STEVE: Right. It's like a neural network or something. It's just like, everything coming together, passing knowledge along.

JOËL: So, Steve, we've talked about how learning in public can be really good for your own personal growth and learning. Are there any other advantages to this approach to work where you're learning in public?

STEVE: Yes, absolutely. I think learning in public is very beneficial for junior devs in particular. And there are a few reasons I think that one of which is I think it helps you stand out amongst other candidates that are applying for a job. I think that just because...if you're constantly sharing what you learn and what you know, and again, these can be very small things. I'm not talking about multi-part blog posts or something. I'm just talking about sharing simple code snippets but just being kind of consistent about it.

Doing that really helps hiring managers to get a sense for how you think, and how you communicate, and how you code because those are all very important aspects of software development. Like, it's not just coding. If it was just coding, I don't know, GitHub Copilot, that would be it, right? We could all just [laughs] pack up our bags and head home. But there's so much more. There's so much more communicating that is involved in the job.

And if you're constantly sharing what you learn, that just makes it easier for maybe a hiring manager or someone to get a sense of how you think, how you code, how you problem solve, and again, how you communicate too because maybe you'll face some criticism like in the comment section or something. I'm not saying that's justified, but also, maybe that's an opportunity to practice your communication skills and maybe ask that person, like, hey, how would you solve this problem? Or, what do you recommend?

Because again, to go back to code review, that back and forth, that exchange that happens every single day. And I just think that if you're learning in public, it's just going to make it that much more easy for someone to get a sense of what you're like before they've even met you.

JOËL: And I think it's a really virtuous cycle here because you mentioned how this is a great way to show your work for potential employers, but at the same time, it's a great way to practice that work. You're talking about how this will help you improve your communication. But at the same time, it's also proving to everyone that you are good at communicating or that you have grown a lot in your communication.

STEVE: Exactly. Yep, exactly. If you're consistent about it, too, you could just scroll through your old blog posts and see what was I talking about three years ago? Versus what am I talking about now? And hopefully, there'll be some improvement and more depth to the articles. And again, it's just a great way to let folks know how you think and how you solve problems.

JOËL: I found that it's not just valuable for junior developers. I think it can be really helpful throughout your career to have public artifacts to point to. I've found that for some of my clients, being able to point back to blog posts I've written, or even conference talks I've given helps build trust, helps to build credibility for some of the work that I'm trying to do.

STEVE: Exactly, yep. And what's really exciting about it is in that moment, when you send that link or send an artifact, that transaction took two seconds. But it just embodies so much of that credibility because it took you years to get all that knowledge. But now, it's just foundational. You have this big foundation of artifacts that you can share. I think that's just wonderful.

JOËL: Keep learning in public. You're building an archive of valuable resources that will just keep compounding in value over the course of your career.

STEVE: Exactly. That's a good way to put it. I like that.

JOËL: Well, Steve, thanks so much for joining us on the show to talk about learning in public. If people are curious to see some examples of how you do this, where can they find you online?

STEVE: If you just search Steve Polito Design, you'll find me, which is kind of a callback to when I was studying graphic design back in college. So that's the best way to find me.

JOËL: So this is a handle on multiple different social media sites?

STEVE: Yep, exactly.

JOËL: Excellent. We'll make sure to link a few of those in the show notes as well. Thank you so much, Steve, for joining us this week to talk about learning in public. Do you have any last words you'd like to share with our audience?

STEVE: Yeah, I just want to thank you, again, for having me on the show. Just for context, a lot of what I learned about software development came from The Bike Shed, so, again, plus-one for learning in public. It helps other people. So it's very exciting to actually be on the other side of the show right now as a guest. So thank you very much. And congrats again on the new hosting gig; so you'll be learning in public too now, so this is great. [laughs]

JOËL: The show notes for this episode can be found at bikeshed.fm. This show is produced and edited by Mandy Moore.

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

If you have any feedback, you can reach us at @_bikeshed or reach me @joelquen on Twitter or at hosts@bikeshed.fm via email. Thank you so much for listening to The Bike Shed, and we'll see you next week. Byeeeee!!!

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