Ep. #120, Bedrock Layout Primitives with Travis Waith-Mair of Plex

Brian Douglas: Welcome to another installment of Jamstack Radio. On the line we've got Travis Waith-Mair. Hey, how you doing?

Travis Waith-Mair: I'm doing awesome. How are you?

Brian: I'm doing great. And you're an individual we only just recently jumped on a call a few weeks ago, but I've been aware of your work and aware of you through actually Antony who's been on this podcast twice already. AJCWebDev, shout out. Yeah, I wanted to have you come on and talk about your work with Bedrock, really. But I'll stop there and have you introduce yourself and tell us who you are and how you got here.

Travis: Yeah, I'm Travis Waith-Mair. I'm currently working for Plex, the media company. It does media servers, as well as we have free content. But I've kind of been all round, worked for different places, including PluralSite and AnonymyLabs NR1. But I'm probably most famous for my open source library called Bedrock Layout, actually Bedrock Layout Primitives but most people just end up saying Bedrock Layout because it's kind of a long name, which involves a React and a CSS framework that allows you to basically do composable layouts to compose pretty sophisticated layouts with just individual parts. I call it the Lodash of web layouts.

Brian: I don't know, I saw that in your tagline. I guess ignorant for me because I haven't used Lodash in a while, since I think the internet or JavaScript devs were like, "Hey, we don't want to use Lodash anymore," so I stopped. Do people still use Lodash?

Travis: I don't think people directly use Lodash anymore. In fact, I've never brought it in on purpose on a project of mine. But it's famous enough that it seems like everybody knows what it is, and it kind of explains the concept of what I'm trying to do with Bedrock so that's kind of why I do the Lodash of Web Layout because it's that same idea. Individually all these utilities don't do a lot, but when composed together they do some pretty complicated things.

Brian: Yeah. I guess what I use now is a Hooks library called Rooks, which is not like Lodash. It's not apples to apples, but it is the massive... It will eventually be a massive library of just random hooks that do random things on the web, and Lodash... I know we have a lot of bootcamp grads and a lot of new engineers, and maybe missed the Lodash phase. But Lodash is a bunch of JavaScript helper libraries so if you wanted to concatenate streams because it was easier to type concat instead of... I guess it wasn't part of the standard lib for a long time.

Travis: But there's a lot of stuff that's in there that are now part of the standard libs like map and reduce, and all these things that didn't exist and now they are in there. That's kind of why if it's in the standard library, just use the standard library. But it does a lot of really cool things, it allowed you to do things that you can now do with sets and maps and things like that, that you couldn't do before easily. Yeah.

Brian: You say that out loud, because you've been writing code for so long, you've been writing code for a while, I've been writing code for a while, I forgot a lot of that stuff wasn't in the standard lib. I use map and I think I just used reduce on a problem recently, and it was one of those situations where I was like, "Oh yeah, of course reduce is going to work. I'm going to type reduce and then it'll do the thing that I think it's going to do." But I forget that JavaScript used to not have that in standard lib. I want to get into more about Bedrock, and I could see where the Lodash for a design system, grid systems, but I want to go back and found out more about your background. How did you find your way in? You mentioned PluralSite, you're at Plex now, how did you find yourself writing code?

Travis: I actually have a bachelors degree in Business Administration. I used to be a stock broker.

Brian: Oh wow, amazing.

Travis: In fact, I even for a period of time thought I wanted to be a doctor and I was a Pre Med. So I've had a bunch of career changes.

Brian: Wait, the Pre Med, was that before the business, stock broker life, or was it after?

Travis: Actually, it was kind of in the middle. There was this really weird phase in the middle where I was in business, I did stock broker because I was married and I had a kid at the time and I needed something stable. I was working at Fidelity Investments as a temp during their tax season and they said, "Hey, we like you. We're going to bring you on full time and we'll get you a license." And I'm like, "Okay." And I fell into it. But the thing with the stock broker's license, if you don't use it for two years it goes away so you feel like you can't ever leave the industry because you never want to lose that license that you worked months to get.

So I ended up doing that for a while but I was never satisfied as a stock broker. I went from Fidelity to eTrade, to Wells-Fargo Investments, and in that process I'm basically working call centers. So I'm not doing really cool, sexy things that people think that you're doing and I'm basically like McDonald's for stock, so I like, "Hey. Would you like fries with your Apple stock?" Or whatever. That's basically what I was doing.

Call center, if anyone's ever done that kind of work before, it's demoralizing. They know to the second how long you've been on the phone and if you've missed your schedule even a little bit, they're on your back. It was crappy, I hated it. My wife's from New Zealand and we hadn't been back there for eight years and I was thinking of going into medical, so I actually got accepted into their medical program in New Zealand.

Partially as a way for to try out the career, to see if that's something I wanted to do, as well as an excuse to go back to New Zealand to see if that's where we wanted to be for the next phase of our life. Did that for a bit, but it ended up not being really where we wanted to be. We came back to the States and that's when I went back into the stock brokerage world, but not as a broker, but as a compliance officer. I did that for about four years until I moved to New York, Upstate New York, not Manhattan.

Brian: Not in the scene? So when you were doing the call center work, you were obviously not in New York then?

Travis: That was all in Utah. Yeah, I grew up in Utah, that was all in Utah. In fact, Utah is one of the biggest-

Brian: Call center place?

Travis: Brokerage. It was call center places as well as brokerage places because a lot of these places, they'll go to the coast but then they'll have their second biggest place in Utah because it's such a business friendly state. Yeah, then costs of living was pretty cheap. Utah now is extraordinarily expensive which is why I've left Utah. But then cost of living was really cheap, so they could hire some good people pretty cheap. But yeah, I moved to Upstate New York, started working for Morgan Stanley as a compliance officer, and then I lost my job.

In that process of being a compliance officer I started dabbling in programming with Excel, with macros. In fact, I kind of theorize Excel is a lot of financial people's gateway drug into programming.

Brian: Yeah. I'm sitting here listening and it was mine. I also have a finance degree and my goal was actually to be one of those call center people, and sell stocks to retirees and stuff like that. I graduated 2008 so I couldn't actually find a proper role to get my foot in the door, so I had the sales role.

Travis: That's the worst time to have tried to get into the finance world, 2008.

Brian: Yeah. But I did a sales admin role where I was actually inputting deals through Excel and using macros to automate all that process. So I'm right there with you, it is a gateway and there's a reason why Excel is still such a strong piece of software years later.

Travis: And it's amazing what you can do with it. It started off with, as a compliance officer, I'd need to go review trade blotter. A trade blotter, for anyone out there who doesn't know, it's all the trades that a financial advisor does and there's some rules they have to follow, like they can't put their trades for the same stock in front of their client's trades. They have to take the worse potential position.

So things like that, we have to make sure that they're not making trades without their client's permission, unless they have a power of attorney on file to do those, so we had to review all these trade blotters to make sure they're not doing incorrect things. They were just Excel spreadsheets and I would do the same filtering and all the things on the spreadsheets over and over again, so I started recording macros but then the macros would break so I would go into the macros to see how I could make them work dynamically for any spreadsheet.

Well, then I started finding out that you could also make ACTP calls right in Excel, and so I started actually screen scraping and doing HTTP calls for data that I had access in other systems so I wouldn't have to manually go back and forth to different screens. I'd just bring that data right into Excel, and at that point that was mind blowing to me, that I could never leave Excel and just do all my compliance work. Most of the time, it would take people like 50 hours and I was getting it done in 30 hours because I was saving that much time.

Brian: I have a very similar experience but I'll save my story. Well, actually most people know my story. I was recently on the Code Newbie Podcast which I'll link that as a pick. But yeah, so what's the point that you got to building layouts? How did you get interested in that?

Travis: So I made the transition when I got fired.

Brian: Okay. That's a perfect time to make a transition.

Travis: My wife and I had been talking about that switch because it got to the point where the only thing that made me excited every day was coming in and finding a new way to optimize my job through Excel or something else. I started learning JavaScript as well, because their websites were still old enough. The finance world is really slow at adopting technology and their websites were still old enough that their scripts were still directly right in their HTML so I could read all the scripts for some of the web pages I was using and I was recreating them in Excel to redo some of the things.

So I was starting to learn JavaScript just through reverse engineering, and it was around that time that I made a mistake as a compliance officer and it was enough that they were like, "Yeah, we're going to let you go for it." The crappy thing about the finance world is that if you make a mistake, if you go from a job, they put that on a record permanently. So if you go to some other job out there, they know what kind of mistake you made and if they hire you, everybody knows they hired someone who made that kind of a mistake, and they're like, "We like you, we think you'd be a good asset, but we don't want your record on our record, so sorry."

Brian: Wow, that's wild. Imagine that was the same case for developers, like if you took down production. It's like, "Oh man, he took down Netflix. You won't ever work in this business ever again."

Travis: "You were the reason why AWS was down for half a day and all the websites stop working." And I get the point of it, they want to weed out bad apples who continually just move from firm to firm and do bad things, but it's also crappy. I made a mistake, I owned it, in fact I brought the mistake up to them and like, "Hey, this is a mistake," but it was big enough that they felt they had to let me go. I kind of thought that was fair, but it was also crappy because I could never get into it again.

But it also gave me an excuse to switch industries because when you're high enough in an industry and at that point I had four kids and a wife who was supporting me, and I was in Upstate New York which is not cheap, even though it's not Manhattan expensive but it's still not cheap. I'm not willing to just jump ship and move to another career and start over, but when I've lost my job already my wife's like, "You've been talking about this forever. Let's just make the change."

And so, yeah, there were boot camps at the time but I had no money coming in. I was on unemployment and relying off my church to help me, top me up and pay my rent some of the months during this period of time. So I wasn't joining a boot camp, whatever I could find online for free I was doing it. The funny thing was when I started learning React, I did not understand something with React when I threw it on Twitter just because I didn't understand, and some guy started helping me, and then a few years later I was looking back through my tweets. Found out that was Dan Abramov who was helping me and I didn't even know.

Brian: Oh, really? Just some random dude.

Travis: I thought it was just some random dude, I didn't know enough to know that he was someone I should be like, "Wow, he's helping me out on Twitter."

Brian: Yeah. Dan's a great guy. I remember Dan before Dan was Dan, around the Redux, pre-Redux times. But anyway, long story short, yes. So you're working on Bedrock, what problem were you solving?

Travis: Yeah. So I eventually started working at R1 through a couple... It was my first senior role and specifically they wanted a design system built, and so that was the team. I was the first one they hired, I ended up getting a team of four people, plus a designer. We were building this design system, and the thing that we were trying to solve was our designer really was big on layout and spacing and people actually following the design system spacing scheme because it's really as a developer, and I'm guilty of this, I think all of us probably are, to just start throwing some rems and ems until it looks right.

You're like, "Yeah, that looks about right."And it's about pixel perfect or throw in a random margin here, random whatever. And it works, until you have to do something else and then it breaks, and then you have to go fix all of it, and we're pretty lazy as developers. We're going to do the thing with the least resistance, which is usually just throw in a margin top or throw in a padding bottom and just quickly throw in whatever random number instead of the actual scheme that the design system wanted to have.

So we started building these layout components, started off with this stack, and all of these were based off Hayden Pickering's Every Layout, if you've ever seen that. That's kind of what they started off with but we had stacks and inlines and just things to put things inline. But they started growing in complexity, depending on what design pattern we wanted to do.

So if you wanted to do a split pattern which would be like you have one thing on one... Just basically a side bar and a main content, but sometimes you want to have different levels of splits, like different fractions of one third or whatever. Anyway. We started creating more and more of these design patterns that were to give a vocabulary for the designers to give to the developers, so like, "This is a cover pattern here."

Or, "This is an inline cluster." And basically it would easily define not just the spacing scheme, but what design pattern and responsive design pattern we were trying to follow. So that was really cool, feeling really proud about that, and I really wanted to move that design system to open source. It was all internal. If you've ever worked on an internal design system, it's all the complications of having it open source without any of the benefits of open source.

So we had to deal with an internal MPM repo and we couldn't use a lot of open source tools that automatically just plug into things like Open Sauce or things like that. That doesn't easily plug right into open source repos and I wanted to be able to use those, and so I set up a meeting with my manager. I knew it was an uphill battle, but I wanted to at least present it, get the idea in.

And so he comes into the meeting and I'm like, "Hey, I just wanted to talk about the possibility of open sourcing our design system." And before I could even talk about the benefits and all that, he's like, "No, we're not going to do that. It's never going to happen." Shut me down before I could even say a thing, and I was like, "Uh, whatever."

Brian: Yeah, what was the reasoning for not even approaching it?

Travis: It was a battle he didn't want to even try to fight with legal, and I get it, but it was like if there was anything to open source, the design system was the easiest thing to open source because it has no business logic in it. The intention is to make it decoupled from any business logic so it could be used universally, and it was the easiest thing and he's like, "Only if I really felt there would be a really big benefit." But which in my mind there are benefits to open sourcing it, but he'd shut it down before I could even tell him all these benefits. He just decided automatically from the get-go, so I didn't even bother going through all these things because he'd already shut his mind off to it.

Brian: Yeah. Sorry, what was the company? Their business, what was the business?

Travis: They're healthcare, they're revenue cycle management for healthcare. They take advantage of the inefficiencies of the US healthcare system by having it so doctors can actually get paid by the insurance. That's basically what they do.

Brian: Yeah, the bread and butter side of developer tools, so I could see your manager thinking, "Okay. Well, we have a business that's not selling to developers." So what I'm working on, and I'm literally pitching a company and a business of open source is actually super valuable for a company like R1, where you have a design system that's everyone using, then everyone is going to be like, "What is this company? Should I go work there?" And then there's always an unending pipeline of developers that are interested in working for your company because of this one open source project.

The other things, sorry, this is just for the listener because I've been doing a lot of pitching on this idea. Of all the repos that are on GitHub, 280 million, only 200,000 have more than five contributors. So if you have an open source project that's used by you and your other four team members, you're now in the top .01%. So now you get pulled into the React conferences and all these other conversations because you have to have a design system. I know we haven't gotten to this point about Tanner, but Tanner works for a very small startup as well, I don't know how small they are now. But less than 50 people, for sure.

Travis: Yeah, yeah. He was the only frontend dev for the longest time there, not just the head of frontend development, he was pretty much also the only one for ages. That's actually a good segue, because it was around this time that I was taking the bus a lot, actually it was just prior to R1 but I was taking the bus a lot into R1. There's this guy that he would always get off and we ended up just talking.

It was actually the train, we'd take the train and the bus, but we would be talking a lot and then we just started geeking out about web development and different things and he'd show me things he's doing. Then one of the times he started showing me something he was working on and I realized he was working on a React table. I'm like, "Wait, you're Tanner Linsley? This guy that we've been using your open source project in what we were doing?" He's like, "Yeah, yeah. That's me." I'm like, "I didn't even know that was you."

Anyway, he was super down to Earth and if you ever go to a conference, for all the listeners out there, if you go to a conference or just use an open source thing, sometimes we kind of put these people up on pedestals. Especially the speakers and all that. As we've already brought up two instances, Dan Abramov and Tanner Linsley, some people who could be considered pretty big people in the open source community, and they're super down to Earth. They'll just sit there and talk to anybody. So if you're ever at a conference, go talk to the speakers afterwards, you'll get so much insight and have so much fun talking to them.

Brian: Yeah. You also get to see how approachable... not approachable they are, but also how approachable the work they're doing is because a lot of that starts with a small idea. So with your design system, it starts with, "We just want to have consistent patterns that we can pull from the shelf and everyone be on the same page when it comes to building web apps."

Travis: Yeah. We have this design system and we have these layout components as part of it that I'm really proud of, and I just got shut down. I called this my revenge driven development moment, that I'm like, "What would it look like to build these components, without the design system? Just bring it in?" So I started playing around, and just locally on my computer, building up a Mono repo using Learner, of these components, and just started playing around with that idea.

I totally got rid of all the spacing scheme, I made up my own spacing scheme just randomly, based of T-shirt sizes just to get something started. Just to give some timeline, I started doing that like a week just before Christmas because I took that as a break, later the next year, I think it was sometime around May or April, I decided, "Hey, let's go put this on GitHub."And I made my first commit, I started manually pulling things into that repo and just started making it work.

So it was all based off style components because we had decided our design system would have style components, and a lot of those early assumptions... I started building things based off of early assumptions of how people might use it, and then I actually got someone who started using it come in called Clavio and they started... at least one person on their team started bringing in, like, "What about this? How do we do this kind of pattern?"

We started collaborating, and I started realizing the way I thought people would want to use it was not the way that they were using it. Luckily I wasn't too far down the path that I was able to backtrack and actually build some things. But it started proving to me, this isn't just fun for our company or fun for me to build, a lot of people want these kind of patterns and want these tools in their libraries.

So I had already at that point as well got someone to build a logo, because all good libraries need a logo, so I went on Fiverr, said, "Hey, let's do a logo." And I had something dumb up there. But I'm like, "Hey, let's build a proper documentation website." And so I started really building it and eventually adopted Storybook as the library, because it's just me who's building it and I was already building Storybook just to make sure things looked dry and I was considering using Chromatic for visual regression testing, but I decided to fully adopt Storybook as the whole doc site. Just so I didn't have to recreate the same examples and then the same visual regression tests over and over again.

Brian: That's awesome. And so since you've open sourced it, how much money have you made from this? I'm just kidding. What hopes and dreams have you-

Travis: I have made negative $10 a month, at least.

Brian: Negative $10 a month? Is that hosting?

Travis: Yeah. Well, it's more from the Netlify analytics because I'm curious if people are coming, but I don't want to put Google Analytics in there, so that means I'm paying the $10 a month just to satisfy my curiosity of whether people are coming to my website or not.

Brian: Excellent. As far as open source goes, was it a good decision to open source this? Has it become a burden that you have to continue to maintain this thing?

Travis: It hasn't. Sometimes I wonder if people are using it until I break something, and then I see the issues. It's kind of an interesting set of community where no one's, so far, actively throwing at issues or throwing in things that they want, until something breaks. Then people start throwing in. Like this week I went and made some updates, and all my links broke and somebody threw it in as, "Hey, all your links across your website are broken because you did something with the Storybook update," that I recently adopted.

I adopted Storybook 7 Beta, and it broke all my links, and I didn't notice because it looked good when I first deployed, and so I didn't go click every single link. But somebody else did, and so, yeah, I wanted to go fix the links. So that's the kind of community it is, if it's something broken they'll tell me, but other than that I'm in my own world, hoping that I'm benefiting peoples' lives.

Brian: Yeah. I was talking to Feross, Feross was on the podcast earlier this year. It's like this pervasive incentive in open source, where if you have a project that everyone loves and they're enjoying and they install the updates and there's nothing ever broken, they forget about you. It was basically about sponsorship and sustainability and stuff like that. But you kind of have to sometimes send a notice or update, or if something breaks and you leave it broken for a little bit then there's an incentive for them to talk to you.

It's a challenge in open source if you're doing everything right, that you get forgotten about. But when you're not doing everything right and there's a lot of issues, then people complain, so it's a challenge with open source and it's the awareness problem as well because we were just talking about Lodash, I haven't used Lodash for forever, I don't think. I'm aware of it, I just forgot when we all decided to stop using it.

With Bedrock, I can imagine being the grid system, it's the first thing you think about. I spent time actually working at Netlify and we did a whole rewrite, and the first thing we started doing was like, "Hey, this company is going to get bigger. We should probably do a design system." When we did the design system I was like, "Oh yeah, why don't we have a button component in this?"

And the designer pushed back, he was like, "No. We actually need a grid system first." And we had to make a decision, so that way every time we have this problem, we all know, "Okay, this is how the grid system works and this is our constraints." It wasn't a ton of constraints, it was just we wanted to make it look elegant and make sense because prior to that... I used to say this all the time, but when I joined Netlify back in 2015-

Travis: That was early Netlify, right?

Brian: Yeah. 2015, yeah. I was employee number three, so it was very early. But there was seven different greens on the site, different hues, and it was one of those things where your engineers, Matt who's the CEO, built all the work before I got there. He's not a designer so he was just throwing stuff together. I get there, we're just throwing stuff together. Then one day someone is like, "Hey, can we clean this up a bit?" It's like, "What's wrong with it? It looks perfect."

Travis: Yeah, for a bunch of color blind... That's one of the probably biggest problems with having males be the dominant part of the industry, is that most of us are color blind and so we're like, "Yeah, these greens look good." And designers are like, "No, they don't."

Brian: So what's next with Bedrock? What are you looking to accomplish now that you've been working on this for a little bit?

Travis: Yeah. So the biggest thing I did recently was I moved away from style components as its base. I brought that along because that's how it was built and I was like, "I'm going to own this, for what it's worth." But as I've been open source, I've realized, A, that fixes me with only those apps that are using React and using React with style components. Because most people, if they're using their own CSS and JS library, or their own CSS build stack, they don't want to bring in, and rightly so, another dependency just to style a couple of their grids.

So I eventually moved to building my own CSS framework based off of it, so you can bring in Bedrock just as a CSS framework into a JAMstack or something like Eleventy or whatever, and just bring that in. It's based off of using data attributes, and custom properties. So you get that prop feel like you do with the React components, but it's all CSS. It was really easy with the CSS and JS library that some of the logic and some of the things that I wanted to do, I just did in JavaScript because I was already in that land.

But when I go into CSS framework, it forced me into, "How do I do this in just CSS?" And I've been able to recreate most of everything, the only thing I haven't been able to recreate in CSS was the masonry grid because there's not a way to recalculate the height of every single element in there, without having a reset as observer or something like that, to refigure out what the height is under the hood. I think they're going to have to build masonry grid by default into the spec and just have that done under the hood for you, because I don't think there's going to be-

Brian: You think that would happen with the CSS? I mean, CSS has made leaps and bounds in the last five to eight years. You'd think they'd have something do that dynamic?

Travis: I think they could. I mean, obviously if I'm doing it with JavaScript, they can do it probably more efficiently with C++ and all that or whatever they're using. I just don't think the masonry grid pattern is popular enough anymore that they... It's now just Pinterest. I don't think it's ever going to make it above the line as importance.

Brian: Yeah. It's funny, because I interviewed at Pinterest and that was my interview problem. It was recreate that check system to find out heights and when you should push things to the left and right. It was some trivial JavaScript, it took me a lot longer... I never got the job, so it took me a lot longer to do it at that time, but I think about that problem all the time. It's a fun little side project on the weekends.

Travis: I probably wouldn't have got it because it took me like a year to figure it out.

Brian: Oh really?

Travis: In fact, the day I figured it out it was me just throwing crap and all of a sudden I'm like, "Hey, this is not breaking. It's still working." And it was in a code pen, and so I was like, "Oh crap. Now how do I move this over?" Anyway, yeah, I would not have done that in an interview.

It was just throwing mud on the wall, making it stick, which is kind of interesting. That's usually how real developing goes, but we get interviewed as if that's not how we really develop, where we don't throw mud on the wall and hope it sticks.

Brian: Yeah. It's like, "Solve this problem instantly." Yeah. The whole process of interviews is... Well, it's changed a lot going remote because now you are focused on the remote interaction, so the whiteboard component still exists but I honestly think there's less of an emphasis now because the industry pushed away from that. But solving all the world's problems in a 45 minute coding interview, yeah, I think that needs to change. I've had a lot of bad experiences so I'd rather not do that ever again, but I don't think I'll ever interview for another dev job, ever again as well.

Travis: Exactly. It's a hard problem because I've been on both sides, obviously, and it's the equivalent of getting married to someone by only going on two dates and making that decision whether you want to really get married to that person. So on that, and I can see why they want to do as much as they can to feel more secure in that decision, but it's also like going on dates where you don't actually interact with the person in the way that you normally would, and then deciding to get married. It's a hard decision.

Brian: No, 100%. It is a hard decision. It makes it even harder when the stakes are so high, because dev salaries, they've inflated at a level that now it's like... So if I was going to start a soccer club and go compete on the world stage, in the MLS, if I'm paying every soccer player lower six figures, which is more of like a dev salary, I want to make sure that this player is going to be able to run the gauntlet of whatever amount of games in the season. So I'm going to basically have them run drills and see how they interact, and I think in software it's kind of similar. You're going to run a bunch of drills, see how you interact, and see if you have, I guess, the grit or the sixth sense of like, "I've seen this pattern before, let me go into my matrix brain and pull down the code out of the cloud."

Travis: Yeah. I guess it also depends on the level, like you said. If it's a more senior position, yeah, you're going to throw them through the drills and be like, "Have they seen these patterns enough?" Especially patterns we see in the day to day job, you want to throw those patterns at them. There was one company I went and interviewed for and they did a lot of network calls, and so they grilled me on async fetch calls and what do you do with race conditions, and things like that.

It made sense because that's what they were doing and so they wanted to see that. Just because I was a senior dev, was I a senior dev who had actually done a lot of fetch calls and knew how to deal with that async? Or was I the throw-it-once and don't have to worry about it kind of dev?

And so I didn't accept the job, but I actually kind of felt proud that I could actually get through that interview and they wanted to hire me, so that was something that I was proud of. But yeah, for the more junior devs, I still remember one time we asked that question to someone who we wanted to bring in as more junior, and his answer was the perfect answer.

He was like, "I actually don't know what you're talking about, so I'd probably Google everything." And this was the guy, he ended up being the one we would actually offer to him the position because he was like, A, honest about not knowing what his skillset and be like what he would actually do, like, "I'd just Google that until I worked on it and see what other people did." It was like, yeah, at your level, that's probably the best thing you could do.

Brian: Yeah. Honesty is the best policy. Sometimes you've got to fake it until you make it. Yeah, I don't know. I'm glad I'm at this side of my career where I don't have to go through this hard interview questions. I hope that as we start growing in scale in the team at Open Sauce that we don't go through the hardest and trying to figure out if you know specific details about network calls in the browser and stuff like that, because I don't think I could answer that. It's one of those things that I just haven't seen it, haven't touched in a while. There was this thing that I was doing last night and it took me a while, it was something trivial like a developer thing and I had to look it up. I just couldn't figure it out, just because I haven't shipped code that way in a long time.

Travis: It's like RegX. When you do it you feel really smart because you figured out how to do something, but then once it's set, you never touch it again because it's now doing the thing you want and so you never remember RegX again. So RegX is one of those things that everyone fears because they don't do it enough to have built that pattern in their heads of like, "Oh, I obviously need to do this." There's people out there who can do it, but most people who deal with RegX end up just googling it because someone else figured it out and it's a lot faster to use their RegX.

Brian: Yeah. That's totally amazing. So I did want to transition us to picks, I know we're approaching the end of the time we had allotted. But I appreciate Travis talking about Bedrock, and also your upbringing and the story into being a dev. There's a lot of correlation. I'm glad we've connected because I'd love to talk more about your background in finance, because I kind of lived through you and your finance role because I never got one.

Travis: Totally fine, we can totally geek out on what you could've been.

Brian: Yeah. So speaking of geek, now let's switch to jam picks. These are things that we're jamming on. Also, sorry, listeners, definitely check out Bedrock. I didn't even mention the GitHub repo, but if you Google... Sorry, if you GitHub. I don't know if Google or GitHub... What's the right verb on that? But Bedrock-Layouts is the org and then the repo is Bedrock. But we didn't even mention Bedrock Solid as well, because you started messing around with it.

Travis: Yeah. That was another reason for the CSS library, it allowed me to do Bedrock Solid. But yeah, we can geek out on that in a future podcast maybe.

Brian: Okay, excellent. All right, let's talk about picks, jam picks, these are things you're jamming on. Could be music, food, technology related. If you don't mind, I'll go first. I've been a heavy Slack user for a very long time, but it's been a while since I've been a small engineering team or just a small cohort of engineers, and we've been trying to figure out how do we keep people updated but also not have to have another meeting.

I'm a big fan of not doing a standup call, I don't mind standups in person, but standup calls tend to be... There's a sense of dread for me to have another call, break my day and then go sit and listen to somebody over talk about something that should've been one minute. So I was looking for standup bots, basically, for Slack and I've landed on DailyBot and DailyBot is pretty nice because I've also never been on this end of the engineering where people report back to me, as opposed to me reporting up to somebody else.

So DailyBot is nice because I can see what everyone's blocked on, what everyone's working on. It's like a ritual, where you just get pinged by the bot, you type in what you're going to work on and what you're blocked on and you get that consistent conversation every day that you would get with a standup. So I definitely recommend people check out DailyBot. I looked at landing pages of a lot of these small, little Slack applications and this is the one that was recommended by one of the engineers that had used it before.

I'm in a weird position where I continue to look at these small, little SaaS solutions because I want to solve a problem without building it myself. If you asked me five, ten years ago I would've built a Slack integration bot myself, and that would've been my weekend and I would've been like, "Oh man, now I have to support this thing forever because I was over ambitious." But I'm now of the opinion, just go see if someone has built it and will charge you $5 a month for it.

Travis: Awesome. No, I think that's a very good point. Going remote, the one thing you notice is you don't have the other team who sits there outside the meeting room trying to get you out of the room. And so all meetings take longer and standup, the one that's supposed to be the shortest one, ends up being an hour meeting. So yeah.

Brian: Yeah. And then they turn into syncs, because it's like, "Oh yeah, it turns out this was broken and it's bigger than it was. Okay. Let's go actually take another two hours and diagram what's actually happening with this thing." And that's what standups divulges, but what I love is that now you can see that faster and then you can plan ahead and have the actual meeting. So I'm of the opinion, and my pick is DailyBot, but my other pain is I try to not have meetings Mondays and Fridays, and not because I don't want to talk to anybody.

It's more that I'd rather have impromptu meetings Monday and Fridays so the calendar is completely wide open, so if you start the week and you're like, "Hey, I need to talk to you." Or you end the week like, "Hey, I need to talk to you." Or, "We need to sync up." There's no dancing around, trying to figure out how to fit on a calendar with other folks who have a calendar as well. With most engineers, they don't have a full calendar, it's just writing code. But with me, I tend to have a full calendar and so I try to keep those days open so if we do need to standup or we do it in sync, we can do that.

Travis: Yeah, that's awesome. Ready for my pick?

Brian: Yeah, let's go.

Travis: I've been recommended this for awhile, but I never actually sat down and watched it, but it's Welcome To Wrexham with Ryan Reynolds and Rob McElhenny who bought the lowest tier soccer team in Wrexham, Wales. The lowest. And not only was it really entertaining and a fun kind of documentary, but actually I finally got soccer for the first time by watching this.

Honestly, I've watched soccer at the World Cup and that's not the same type of experience as watching league soccer, and understanding what relegation and promotion... And I certainly can understand that because I started watching Ted Lasso, but really understanding the anxiety of what a tie can give you and I'm totally coming from the US mindset.

NBA is the game I watch most of the time, and so I'm used to watching 100 point games on average, and just the anxiety when you have a close game of basketball where you're trading back baskets and it's whoever can make the final basket and you're going to win by that two points or whatever at the end. That's the anxiety you have the entire game with soccer, and understanding that... I think I could probably actually get into watching it now, now I understand how that works.

Brian: I guess this was after the World Cup, but did you watch the World Cup recently?

Travis: I didn't. I know. I don't know, World Cup, I still don't get it because the game is more about whether you win or not and you're out. But I like league sports a little bit better and playoffs and understanding, because I like to see all the games that lead up to where people actually get positioned and things like that, and totally understanding that a tie still means a lot even though it's a tie.

The one thing I'm still never going to get is the concept of refs giving soccer teams extra time and they just get to decide randomly, like, "Ah, it's about this amount of time." I'm like, "What?" It's like when I was buying this house and the home appraisal, some guy walks around the house and he's like, "Your house is about 350,000." It's just like, "Where did you come up with that number?" I know they have things, but it sounds like you're just making this up as well. Anyway.

Brian: Yeah, it's an interesting sport. I didn't watch a lot of the World Cup because it's in the morning time as I'm making coffee is when the games were on during the week, and I was like, "I'll just throw it up and see." Watch like 10 minutes of whatever match. I'd never sit and watch the entire thing. But it's nice background noise as you're trying to step away from the hard problems downstairs. So yeah, I'm actually going to check out this. It's on Netflix, right?

Travis: It's on Hulu.

Brian: It's on Hulu, okay. Yeah, I've definitely seen it across my feed. But definitely check it out because I have a lot of respect in professional sports. I guess as I get older I'll probably watch golf eventually. But yeah, I have this whole core part of my Open Sauce pitch around finding the best developers and open source. Did I give you the pitch around the NBA?

Brian: Yeah. I kind of alluded to it in this conversation, but if you want to be the best, you have to play with the best. So if you want to be a better basketball player you've got to play with better basketball players, and if you want to be a better developer, you've got to write code with better developers because you won't ever cross that chasm. It's why so many people make the jump to San Francisco or so many people make the jump to a bigger company, because there's better developers at bigger companies, or at least there's more developers. That's the assumption, that they're better, but not always the case.

Travis: Well, there's a higher chance that there's going to be more, better developers that you can latch onto.

Brian: Exactly. Yeah, with that being said, Travis, thanks so much for the conversation. I'm going to go ahead and end it here. Folks, check out Bedrock Layout. Check out Travis and, Travis, we'll have your Twitter in the shownotes as well.

Travis: Thanks a lot.

Brian: And with that, listeners, keep spreading the jam.