UX

View on separate page

Transcript

Hey everybody! And welcome to another episode of How I Built It, the podcast that asks, “How did you build that?” Today, my guest is Stacy Kvernmo, a UX/UI Developer at OddBird. I met STacy on another podcast and was really excited to talk to her about a number of tools and views she has about creating good code while working on a team. We talk about process, UX, and more in this episode. We’ll get to all of it, but first, a word from our sponsors.

Sponsors: This season of How I Built It is brought to you by two great sponsors. The first is Liquid Web. If you’re running a membership site, an online course, or even a real estate site on WordPress, you’ve likely already discovered that many hosts have optimized their platforms for a logged-out experience where they cache everything. Sites on their hardware are great for your sales or landing pages, but struggle when your users log in. At that point, your site is as slow as if you were on $3.00 hosting. Liquid Web builds their managed WordPress platform optimized for sites that want speed and performance regardless of whether a customer is logged in or logged out. Trust me on this. I’ve tried it out and it’s fast, seriously fast. Now, with our single site plan, Liquid Web is a no-brainer for anyone whose site is actually part of their business and not just a site promoting their business. Check out the rest of the features on their platform by visiting them at BuildPodcast.net/Liquid. That’s BuildPodcast.net/Liquid.

It’s also brought to you by Jilt. Jilt is the easiest way to recover abandoned shopping carts on WooCommerce, Easy Digital Downloads, and Shopify. Your E-commerce clients could be leaving literally thousands on the table and here’s why. 70% of all shopping carts are abandoned prior to checkout. Yes, you heard that right. 70% of shoppers never make it to checkout. That’s why you need to introduce your clients to Jilt. Jilt uses proven recovery tactics to rescue that lost revenue. It’s an easy win that lets you boost your client’s revenue by as much as 15% and it only takes 15 minutes of your time to set up. Jilt fully integrates with WooCommerce, EDD, and Shopify. You can completely customize the recovery emails that Jilt sends and match your client’s branding using its powerful drag and drop editor or you can dig into the HTML and CSS. Even better, Jilt’s fair pricing means your clients pay only for the customers that actually engage. You get to earn a cut of that through Jilt’s partner program. Whether you have clients that process one sale per month or 10,000 sales per month, be the hero and help them super charge their revenue with Jilt. Check them out at BuildPodcast.net/Jilt. That’s Build Podcast dot net slash J-I-L-T. Now, on with the show.

Joe: Hey everybody and welcome to another episode of How I Built It, the podcast that asks how did you build that? Today, my guest is UX Designer and UI Developer, Stacy Kvernmo. Stacy, how are you?

Stacy: Hi, good. How are you?

Joe: I am fantastic. I did okay on the name there?

Stacy: You did great.

Joe: Excellent, excellent. Thanks so much for joining me today. We met from being on the podcast, Lunch with Brad, which I think we were on the very first episode. Right?

Stacy: We were. I keep singing that theme song over and over again. I just love it.

Joe: It’s constantly stuck in my head, so good on Brad for that. I will link our episode in the show notes if you guys are interested in hearing that, but I was very interested to get Stacy on the show because I think that she offers a unique kind of point of view from what I normally have on the show, which is a lot of developers. Stacy, you are a UX Designer and UI Developer at OddBird. Is that correct?

Stacy: That is correct.

Joe: Cool.

Stacy: I’ve been there for about two years and I love every minute of it.

Joe: Nice. Very nice. What does your day-to-day look like there?

Stacy: Well, we do a daily stand up in the morning and just kind of schedule out what we’ll be working on. Everyone is an equal part of the business, so we all take responsibility for ourselves. We have certain workflows in place to make sure that everyone is always busy with a task and whether it’s doing a proposal for a design or implementing the design or reviewing the design. We do a ton of code reviews. Everything is a hundred percent tested, so we all kind of take a really big part in every project that we build together.

Joe: Very cool and we’re going to be talking a bit about that process. Kind of the process and UX a little bit in today’s episode. Just one more question before we really get into it is while I met you through I guess a WordPress centric group of people, you don’t really work too much in the WordPress space. Is that accurate?

Stacy: I mean, I started working in WordPress in 2009 and for many years I was exclusively WordPress. Worked at WebDevStudios with Brad and Company, then when I took a job right after that, they used WordPress very sparingly, so I didn’t get to do it as much as I’d like, but I still co-host the Word Press Naperville Meetup Group, so I always had my fingers in it and kind of my finger to the pulse. I just didn’t use it maybe on a, more like a weekly basis rather than a daily basis and nowadays, I decided to build my own little app site app using WordPress, so question and answer website for yoga. That keeps me kind of current on all the things that are going on in WordPress, so I still have something to talk about.

WordPress, I love it. It really does hold my heart. It does so much for people wanting to build a website that may not have all the technical skills and it’s just amazing what you can do. I am a designer, front-end developer. I don’t know all of the PHP database stuff, how to do everything that some of the back-end developers do, but with WordPress I can get like 85% there doing what I want. Then, there’s always plug-ins to help me along the way, so I really owe a great deal of gratitude to WordPress and the community around it.

Joe: Yeah, that’s fantastic. Again, I want to reiterate what you just said because I’m a developer. I have a Master’s in Software Engineering, but I’m in the education space now, so I’m very happy that I could get my own WordPress LMS website up and running without having to code much of anything. If I want to make customizations, I can, but I want to focus on the content without having to focus on writing this monolithic thing, this big, giant application. Cool.

We’re going to talk process and UX and we’re going to use this project that you worked on at OddBird called Herman Style Guides. Can you tell us a little bit about that? How you guys came up with the idea and why you made it?

Stacy: Yeah, so design systems have been growing in its popularity I’ll say over the past years and we’ve always had a design system approach to building. We basically will build these toolkits and hand them off to our clients to continue maintenance, so we’re building a system to let them handle their system. It’s un-opinionated. We came up the idea basically because we wanted a way to extend our already documented code and display it so the whole team could see, the whole team can get onboard with what patterns exist and why it even matters. I mean, patterns are a huge part in development as far as keeps a visual inventory of everything that exists, so your team is fully aware of it. It creates this shared vocabulary, so when you have these meetings and say your project manager is referring to a component that needs to be built, you guys can use the same language so everyone can communicate on the same level. It reduces technical debt and minimizes long-term maintenance. There’s so many good things to why patterns matter and to expose those patterns through a tool that’s automated is going to be key moving forward if you are building any sort of scalable project or if you’re working with a team.

Joe: Yeah, absolutely. This rings true so well for me. I can really relate to this because I mean, when I was at Crowd Favorite I worked on massive projects with maybe, I don’t know, thousands, tens of thousands of lines of Sass for our CSS. What would happen is we didn’t have something like this, so I would make a class for a button. Somebody else would make a class that had the same styles, but it would be later in the code or he didn’t know where it was, so a design system could potentially prevent stuff like that from happening. Right?

Stacy: Yeah. I mean, and consistency is key. We have a very specific way we set up our files in order to avoid that. Also, all of our code is well-reviewed by at least one person, every single line. It sounds tedious, but when you get into that mode of doing those code reviews, you learn not only so much about what that code base is doing, but also what it takes to write good code. You start communicating about it and it makes you think about your code and helps you to plan for these types of patterns. What you may have overlooked, someone could maybe see pretty easily and to have that conversation can save you a lot of time in the long run from having to maintain all those disparate pieces.

Joe: Yeah. I mean, not to mention it will make you a better coder over time. Right? Especially if your code is what’s being reviewed. It’s a nice way to kind of put egos aside and know that I’m going to be better, the reviewer is going to become more familiar with the project, and most importantly, the project is going to have the best code base possible.

Stacy: Oh yeah. I did a presentation a few years ago about code review and the benefits of. I did a WPSession, so for those familiar with that.

Joe: Yes.

Stacy: Shout out to Brian. That’s actually how I got the job at OddBird because I met Miriam Suzanne at a few conferences and she heard my talk about doing code review. Since they were such big fans of the code review process, she thought I’d probably be a good fit with just that in mind that I care that much about code review. I think a lot of people, maybe they’re not in a big enough team or they think they don’t have time, but it’s so valuable to growing, like you said, just your own skills, but also to just continually build better projects because if you’re the only, let’s say, front-end developer on your team, you might think you don’t need it. What happens when you leave? Someone else needs to know what’s going on. Maybe that is a back-end developer that can transfer that knowledge, so they have some sort of working idea of what’s going on in that code base.

Joe: Yeah, absolutely. You didn’t give that talk at a Word Camp by chance, did you?

Stacy: I did at three SassConf, CSS Dev Conf, and I don’t think I did it at any of the Word Camps. No.

Joe: Okay. I went to a code review talk at a Word Camp a few years ago. I was going to just like freak out if I had seen you without realizing.

Stacy: Was it Chicago?

Joe: It’s possible. I was at Chicago 2014.

Stacy: I spoke there in 2014, but I think I spoke about design.

Joe: Okay.

Stacy: I kind of flip flop every year between design and code.

Joe: Nice.

Stacy: That was my design year.

Joe: Cool. Very cool. Awesome, well I’ll definitely link to the WP session. Brian is a good friend of mine and of the show. We have the Herman Style Guides. It’s an open source project. Can you talk a little bit about how it works so we understand what kind of work went into it and then we can talk about the process behind building it?

Stacy: Okay. Yes, I mentioned it’s an automated style guide tool. It hooks directly into your Sass and if you’ve ever used SassDoc before, that’s kind of … In 2015, I tweeted that I wanted something like a Pattern Lab or a Hologram to have a baby with SassDoc because I love the idea of documenting mixins and variables and how to use them, what is required, and where else they’re dependent upon. I love the idea that SassDoc has with documenting their code, but I also really wanted some sort of visual preview. That’s what some of those other tools were giving at the time.

When I found out, when I started talking to OddBird that this is something they’ve been working on … I wasn’t there when it was just an idea in their head. They had already started and when I found out that they had started this tool that was kind of like my dream tool for documenting design, I was so onboard from the beginning. It takes code that’s already in your Sass and will use SassDoc, it’s built on top of SassDoc, I said that, and uses … Is it Sass export or JSON export? It basically takes all that information in the SassDoc that you’ve documented and exports it to JSON, which then displays it on the front end with the data that’s needed.

You can call some templating examples. We use Nunjucks and it hooks in to, like you can actually import the Nunjuck macro and say we want to show this button style, so import the buttons and then the little template tag. You could just use straight up HTML if you want and then it also produces that visual rendering. If you have it to include those templating files, you’re not really reproducing that markup, which a lot of the other style guide tools, you’ll see them, you know, you have to create a separate markdown file and then put the markup there even though the markup is probably created in some sort of templating language somewhere else. We’re trying to get to the place where we don’t duplicate code, we’re just calling it. I think that’s part of the magic that Herman provides for us.

Joe: Yeah. I mean, that’s awesome and as a developer I can say that documenting is, I don’t want to speak for everybody, but I will, it’s our least favorite thing. Documenting and things like that, it’s tough because we spend most of our time, especially if we’re doing client projects at a bigger level, we’re spending all of our billable hours on the project and some might view the documentation part as a way to burn those billable hours when in actuality it’s going to save you hours in the long run, especially if it’s a recurring client and you need to jump back into that code base at some point.

Stacy: Yeah. I mean, this is built like with budgets in mind. It’s a very easy tool to integrate into your existing code base without taking a lot of extra work to get it to do what you want. To get it to display certain patterns. As a UX designer and I do the front-end development, too, so I kind of float in between both worlds, but if I am only doing UX design on a project and I don’t really have a deep knowledge of what’s going on in the repo at the time, it’s so important for me to know what patterns exist so that I don’t keep creating just slight variations of the same pattern. I think that there are people who think that self-documentation is the way to go and I think that that’s certainly one opinion, but if you are unfamiliar with the project or if you’re coming in maybe as a junior level developer, you might not know why those decisions were made or where the code snippet came from.

Sometimes, just posting a link to like a CSS tricks article and saying, “I found this here,” or a CodePen, really helps you understand why those decisions were made. I don’t care how awesome your function names are at explaining what’s happening, sometimes the context of why it’s there to begin with is missing. I think documentation, we strongly believe in documentation. It’s going to save you so much time in the long run. If this project is maybe like a temporary micro site, whatever, you don’t need a design system. You probably don’t need that much documentation, but if this is something that you want to keep iterating on, it’s almost a requirement these days.

Sponsor: If you build WordPress websites, you should join your fellow WordPress developers from around the world for WordSesh, a must-attend virtual conference on July 25th, 2018. WordSesh has been highly curated to provide you with the absolute best possible experience. Every presenter has been hand-picked for their experience and perspective. Each topic complements and builds on the others and the virtual swag will be amazing and useful. You can see the full speaker lineup and register for the live event and its recordings at WordSesh.com.

Joe: Yeah, absolutely. I’d love to get into the … Well, so the title question is how did you build it and this was already kind of in-process when you got to OddBird, right? From a process standpoint, maybe you can take us from the beginning, like what does a kick off look like, how do you divvy up the jobs, and when does everybody get involved, that sort of thing.

Stacy: Sure. I mean, since this is an open source tool, it’s not something we’re a hundred percent focused in the whole time. We kind of will do some upgrades as we go when we feel that a certain client project needs it. It kind of has grown with us as we decide what’s important, what do we need for our business to succeed. We do retreats a few times a year and in 2017, the two retreats we had we worked on this tool. The first one we worked almost exclusively on this tool, so one of those days would look like we would have our morning stand up, decide what we want to focus on. We have a whole list of GitHub issues, so public repo, if anyone wants to look through all the open and closed issues. That kind of helps us prioritize what we want to achieve and then we break out into smaller groups where the designers work together to decide, okay, these are the proposals we’re going to make. We’re just going to make quick, sketchy, wire-frames of how we’re going to solve these problems. We come back together. I don’t know what the developers do, but we came back together, discussed our solutions, had some back and forth, maybe we should try this, did you think about that, very open to idea sharing.

I love the fact that everyone contributes to every discussion we have. Then, we break off again, maybe individually this time, and kind of finalize that proposal. Then it goes into implementation and once that’s finished we go into code review and testing. Not only do we write tests for our JavaScript, we also maybe … I don’t know if we have Python tests. I don’t even know if that’s a thing. I don’t really dabble in that world, but we also have, we use True, which is another OddBird tool, open source, it tests your Sass mixins. It checks to see if the arguments you’re passing is like what it’s expecting. It’s a really nice tool. Those are also written before anything gets merged. That’s kind of our process.

Joe: Wow. That’s very cool. I want to focus in on two things here. You mentioned implementation and then code review. We touched on code review a little bit and it’s like one person going through the code. Are they like team events? I’ve heard that code reviews can be all the developer in the room together picking apart code and it’s like a very public thing, but it’s a thing that grows the team. Then, when I was at Crowd Favorite, we had mostly one-on-one code reviews. Somebody would post it in a project room. Somebody else would take it and look at it and make comments. What does your code review look like and maybe you could talk about some of the reasoning behind it?

Stacy: Typically, we are a remote-first company. While half of our team is in Colorado, the other half is, well, there’s two in Indiana, one in South Dakota, and one … I’m in Aurora, Illinois, so we almost always do just commenting in GitHub inline. I think that also provides a lot of value of you can refer back to it later and you see their clear questions. I think there’s a lot of etiquette that goes into code review and I think what OddBird does is right. It’s not why did you do this? It’s, can you explain why you chose this?

Stacy: There’s a lot of ways to make code review painful and there’s a lot of ways to make it educational and we always lean on the educational side. Now, when we’re all together, we can sometimes look over each other’s computers and be like, oh, that’s interesting. What are you doing there? It’s still, even when we’re together, almost all done through the interface. It’s easier to track that way, so that’s just kind of our preferred method of doing the review.

Joe: Sure. I mean, that makes a lot of sense because there’s … I mean, the accountability aspect of it, which again, we kind of leaned on at Crowd Favorite, who reviewed the code and why did they approve it, is it following the standards that we set forth, but also can you explain why you did it this way. If somebody explains why they did it in a comment and that’s suitable, now whoever is looking at that code base learns maybe something new or a new way to do something. Right? I always have a hard time grading or reviewing papers or articles that people will send me to review because you have to straddle the line between this is not the right way to write it and this is not the way I would have written it. Right?

Stacy: Yeah, absolutely. I mean, there’s different thought processes and there’s different methodologies in writing code, but sometimes it comes down to, yeah, is this a preference or is this actually something that wasn’t thought through or followed through with the right conventions that we typically use? We have pretty established conventions. I don’t think they’re written down anywhere, but just from these code reviews you learn to think about the code and you learn to plan through the things before you even write a line of code. I think that’s a huge skill for people who are looking to level up in probably any language, but certainly CSS. CSS is easy certainly, I know people say that all the time, but really good, strategic CSS is like playing a game of chess. You have to think through all of these things that are going to happen in the future to make sure that you’re CSS isn’t going to crumble or grow to many megabytes before you realize there’s a problem.

Joe: Yeah. I mean, that’s especially true with Sass, right, because with Sass you could just do extend, I think it’s you can extend a class and it basically just copies all of the properties from that class into this new class. There’s probably reasons to do it, but maybe a mixin would be better in a different case where you’re not exploding your CSS.

Stacy: Right. Yeah, I mean, there are certain issues with extend and if you’re not careful, you’re probably going to write bad code, so even if you’re writing CSS sometimes you’re going to write bad code. I think it’s all about how you approach those. I don’t think I’ve ever written and extend at OddBird. I tend to prefer mix ins. They don’t produce any code until they’re actually called and you will never have unexpected output. I mean, sometimes with an extend, if something’s written afterwards and the original declaration is overwritten, so it just seems safer to me.

Joe: Yeah. I think I used extend a couple of times and then I regretted it. That’s really interesting. When you bring on, let’s say, a new designer or a new front-end developer, do you onboard them in any way? Are you like, okay, so … because you said that you’re not sure if there’s a clear document, but are you …

Stacy: I’m going to get in so much trouble over this. I’m sure there are. There probably are many Google Docs.

Joe: Right.

Stacy: We have tons of documentation of things.

Joe: Yes.

Stacy: I don’t know if like specific code style is documented. That makes me feel like an imposter that I talk about documentation. I do know, though, that our Sass-lint file will always tell me if I am not writing the correct code style in some of our projects and probably all moving forward, we can’t even commit the code if there is a Sass-lint error. It will tell us, hey, you forgot to put a space between your colon and your property or your value. That kind of saves you from yourself, from all these little tiny errors, having that Sass-lint tool or whatever linting tool you’re using, there’s so many of these build tools that make our lives so much easier. I know people complain about the whole build tool stack because it’s gotten way more complicated. Not just the build tool, but the whole tooling stack. There is a reason for many of these tools to exist and it’s to make everything way simpler. I know it adds a little complexity, but I think overall it certainly benefits us, especially if you have people on your team that can make those steps a little easier when you start a new project. It’s definitely a value that I would not want to let go.

Joe: Absolutely. Okay, so you said you might get in trouble, but you actually answered in the best possible way, which is no, we don’t make new developers read like some boring GitHub document or whatever, we have a linter that shows them the right way to do it and gives them the right … I don’t have to sit down with a developer and say never use the important tag, you know, like you should never use it or whatever or like make sure to alphabetize your properties. That was something that we did at Crowd Favorite. Oh, you have a linter that might do that for you or whatever. Cool. That’s fantastic. Awesome. Man, we’re coming up on time and I want to ask you about testing as well because being on the, let’s say the back end of things, you can have these automated unit tests or integration testing and stuff like that. What does testing a Sass file or what does testing Herman look like?

Stacy: Sure. Well, we’ve documented … Herman is documented itself, so I’ll post all the … I assume we have some show notes here.

Joe: Yeah.

Stacy: I’ll give you all the links, but for a Sass test, in True we would for instance, if you have a mixin and it’s expecting three arguments and you only have two, when you compile that code you’re going to get a little error message in your console that says, “Hey, we noticed that you only provided two. You can’t finish compiling,” basically. It will tell you where and why there’s an error, but again, it kind of saves you from yourself. If you’re going to write a mixin that uses logic, why not test that logic just like any other language would do. I had nothing to do with True. I’ve implemented some tests, but Miriam and the people at OddBird are responsible for that tool and it’s fantastic. It’s great. I highly recommend people go check it out.

Joe: Cool, very cool. I love that. I was just talking to somebody recently about when I got my Master’s degree, we had to go through a class of writing provably correct programs, so we’d have to write mathematical proofs for our programs. Now, it’s like your editor tells you when you’re messing up as you’re messing up. It’s just what a wonderful time we live in as far as coding goes. It’s very cool to see those tools being used on both the back end and the front end because I think, I don’t know, I’m a front-end developer. I straddle the … I guess maybe I’m like a middle developer, I do some backendy things and I’m much more familiar with those kind of tools for the back-end stuff because I think it’s easier to visualize.

Stacy: Yeah, I think with Sass it’s really opened up a lot of avenues that we’ve been missing in CSS. I know we’re rolling out CSS custom properties. They do extend things. They’re slightly different than what you’d see in a Sass variable, but it’s a very similar, like this is a placeholder basically for something else that you’re going to use later. You can change it on the fly, but we never back in CSS days, we never had the ability to do a lot of these cool logic things. We can do loops and we’re very heavy on Sass Maps at OddBird. We feel that code should, you know, we’re creating these patterns, but these patterns need to be meaningful so when you’re creating a color pallet, you don’t want necessarily a giant file of just a ton of colors. Why not group them with what they are meaning?

If you have state colors, so you have your success messages and you have your error and your warning. That’s all wrapped in a state color map tag, so that when you call it later in the style guide, it can be listed under state colors. You can separate it so that people know what’s intention of it, not just the color and just the value or anything, but how it’s supposed to be used in context. You’ll see that type of meaningful relationships all throughout our code. That was probably the most surprising and biggest thing I learned after joining OddBird. I always knew that keeping things dry was important, but I never really thought deeply about code being meaningful and having that relationship that not only is like everything here shares the same background color. That’s not really a good example of relationship, but if they’re all sharing a background color for a specific purpose, then that makes it more meaningful.

Joe: Man, that’s awesome because if you look at my Sass you’ll see primary color, secondary color. That’s not as meaningful as say grouping things by state. Like, what is this the primary color for or, you know, things like that. I’ll have like link and link hover, so I’ll have some meaningful names, but those groups … Yeah.

Stacy: We do have primary colors, too. I mean, we do the brand colors. We’ll list the brand colors or secondary colors, but then we never call those in the rest of our code base. Those are always used as a layer of configuration for the theme colors, so while we’re using the same color, we’re calling it from a different previously defined Sass Map. There’s been some engineering of the maps that we’re using because Sass can’t … You can’t refer to a color from the same map if it’s a related color, so again, nothing I did, but the smart people at OddBird created sort of an extension of the syntax, and some functions that we can use in order to easily tie those key value pairs together within the same map. Then, when we call them later, we define it in one place and then it gets calculated later, so we’re able to use a human readable format in order to make those relationships consistent, as you would expect to define those types of colors or sizes or whatever you’re using to define.

Joe: That’s really cool. We are at time, but I must ask you my favorite question, which is do you have any trade secrets for us?

Stacy: I mean, going back to that meaningful pattern thing, if you don’t know what I’m talking about, please watch Miriam’s talk at pretty much any of the conferences. She blows my mind every time she speaks and one of my trade secrets is work with people smarter than you and work in teams, because you will exponentially increase your knowledge as well and you can then apply and give back and share that knowledge. She does this talk, I think it’s Code Patterns for Pattern Making, or maybe I’m getting that backwards. It’s on our website. It’s phenomenal and I mean, I worked at OddBird for a while and then when she gave that talk, it all came together for me. Why we’re doing what we’re doing and to be able to fully embrace, oh, okay, now I recognize that this is why we do these things and I think it’s just fantastic. I think it makes me a hundred times better developer in order to recognize what is a pattern and what is a meaningful one and to be able to continue to write code in that way. Definitely recommend checking out her talks. That’s my trade secret.

Joe: Awesome. That’s excellent and I will link that talk in the show notes as well. This episode has some rich show notes, which you can find at HowIBuilt.It/79, which is the episode number. Stacy, thanks so much for joining me today. Where can people find you?

Stacy: I’m on Twitter, but not as often as I used to be for reasons …

Joe: Probably for the best. Yeah.

Stacy: @StacyKvernmo, K-V-E-R-N-M-O, every letter, say every letter if you say the name and CodePen at just Stacy, that’s a pretty cool user name.

Joe: Wow. You got Stacy on CodePen?

Stacy: Yeah.

Joe: That’s amazing.

Stacy: Maybe I’m an insider. I don’t know.

Joe: Yeah, that’s the dream. I want Joe on some platform, which is nearly impossible because Joe is … Well, I guess Stacy’s a pretty common name, too.

Stacy: Well, in development though, I wonder how many women were early adopters of each platform, so I don’t know.

Joe: Yeah, that’s a really good point.

Stacy: Sort of an advantage. I got Stacy K on GitHub. I wasn’t able to get Stacy. Almost.

Outro: Thanks again to Stacy for joining me today! She provided a ton of great insight into coding with a team, UX, and lots more. I strongly encourage you to check out her work and the open source projects she’s working on over at OddBird.

And Thanks again to our sponsors – make sure to check out Liquid Web for managed WordPress hosting. I use them on all of my important sites – they are that good! They are at buildpodcast.net/liquid. They’ll give you 50% off your first 2 months just for being a listener! If you want to save your clients (or yourself) money through recovering abandoned carts, check out jilt. They are over at buildpodcast.net/jilt. Finally, be sure to check out WordSesh. An incredibly affordable, 12 hour online conference with some of the biggest thought leaders in WordPress. get your tickets at buildpodcast.net/wordsesh.

For all of the show notes, head over to howibuilt.it/79/. If you like the show, head over to Apple Podcasts and leaving us a rating and review. It helps people discover us! Finally, if you like the show and what to support it directly, head over to patreon.com/howibuiltit/. We have lots of great perks for backers, and right now, you vote on the official t-shirt. You can support the show for as little as $1/month. If you pledge at $10/mo, you’ll get that shirt for free.

And until next week, get out there and build something.