: 0:00

Welcome to the Zeal Interestings Podcast. I'm your host, Chris White. My special guest today is Adam Wathan. He's the host of Full Stack Radio, The Creative Nitpick CI, the cofounder of Refactor UI and the Ceative Tailwind CSS. Welcome to the show, Adam.

Adam Wathan: 0:12

Thanks for having me man. I'm glad to be here.

: 0:14

So I'm super glad to have you. Super excited to ask you about all the things you're doing. And I thought we'd just jumped right into it. What do you actually do? What do you consider like your main focus right now?

Adam Wathan: 0:25

Sure. So this was actually something I was thinking about it a little bit recently, trying to sort of figure out what is my mission statement, I guess that kind of defines all the different things that I do. And so I used to work for a few different web agencies so as just full time web developer and I eventually left to kind of do my own thing- create training products and stuff like that. So I like to think of what I do is just like trying to help other developers make awesome stuff easier and in more enjoyable way. Um, so I usually, you know, that involves doing things like teaching, so I've put out a book and a couple of video courses on different topics from, you know, refacturing backend PHP stuff to tester in developments to most recently a course on advanced view component design. And I also create open source tools like Tailwinds CSS for example. And most recently I'm working on a project with a friend of mine, Steve Sjogren, that you sort of alluded to, which is this refactoring UI you book and it's more than a book. It's hard to kind of figure out exactly what it is, but just kind of a big collection of, of stuff that's hopefully going to help other developers get better at a Ui design so they can build their own stuff and rely less on other people. And uh, have a little bit more fun doing it and get a little less frustrated when they're trying to put together a whole project on their own.

Chris White: 1:48

That's awesome. To get off on my first tangent, I've actually noticed among people that have worked in agencies or consultancies like that, like teaching and educating thread is always there. Have you noticed that as well?

Adam Wathan: 2:00

I never really thought about it, but now that you mention it, I think that's definitely true. Like a lot of the companies that I used to, um, kind of, well still admire but admired, you know, a lot more intentionally when I was like in the agency game, companies like ThoughtBot and stuff like that who made a really big name for themselves by teaching and sharing what they know and um, yeah, I think that's definitely true. You see it a lot more with, with consultancies I think that you do with product companies, although there's some product companies out there that do a really good job teaching what they've learned, building their stuff too.

Chris White: 2:34

Yeah, I've seen that, I've seen that. I think I feel like it just attracts like, uh, people who are, who like learning and who liked teaching for sure. I've definitely found that pattern to be true among my coworkers. And so a lot of different projects, a lot of them kind of focusing around education and learning. So seems like Refactoring Ui. Your most recent project. Is that book published or is that kind of a work in progress?

Adam Wathan: 2:57

Work in progress, so we kind kicked it off as like a full time cameron, try and get it done thing about two weeks ago and we're hoping to have it out, uh, end of November, beginning of December. So that's kinda the big thing that we're pushing on right now.

Chris White: 3:12

That's great. That's great. I was actually under the impression that it was, yeah, that was like a content platform or like teaching platform and you know, you have a lot of YouTube videos associated with that and those are great. We've actually shared those a lot among my coworkers. So I definitely recommend anyone check them out.

Adam Wathan: 3:29

Yeah, yeah. We started with just kind of this idea for sort of a brand that we thought would be, it would resonate with developers, Refracturing UI. Like what other design education resource is using words like refactoring.

: 3:43

That's right. That's right.

Adam Wathan: 3:44

So yeah, we just started off kind of sharing. I mean the main thing has been like these tips on twitter. Then Steve and I have put together that have done, performed really well in terms of people seem to really enjoy them and really been able to apply them and improve their stuff. And then Steve started doing some screen casts and stuff to where people would submit their own projects and he would do a screen cast recording where he'd go through and talk about all the changes that he would make to sort of improve it, which people have, uh, have really enjoyed too. And uh, you know, so we've been doing that for like a year and a half, something like that and all sorts of different mediums. Then we decided it'd be cool to try and consolidate all this into a more sort of premium thing. Something that we could get paid for so that we can continue putting together this sort of thing. And we started with for a long time thinking, oh, what should we name this product that we're going to make? And eventually just decided, let's just call it the same thing that we've been calling everything else. I have to refund some precedent for that. We felt a little less weird about it, but it can be a little bit confusing to know like are you talking about like refracturing Ui as a entity that puts out all this stuff or specifically like the book or whatever, but

Chris White: 4:52

yeah, that's really interesting. I've found that like many bloggers will name their book after their blog when I used to follow more like cooking blogs, like a lot of when they come out with their book, they'll name after the blog just to kind of keep that brand continuous. Add like a handy sub title to make sure that you know the book. Yeah. That's awesome. That's awesome. Is this your first time producing a book?

Adam Wathan: 5:15

I've never done like a physical book. I think this one we're going to try and do a physical versions of but still going to be primarily digital.

Chris White: 5:23

The target audience that sounds like it makes more sense.

Adam Wathan: 5:26

So and I think there's a lot of advantages to digital in terms of being able to push out updates. So you want to have a new chapter or someone finds some grammar typos, stuff like that. And you know, no matter how much editing you do, you're always gonna be something slipped through the cracks.

Chris White: 5:43

It's hard to do version control on paper.

Adam Wathan: 5:46

Exactly. But at the same time everyone always says like, oh, is it going to be physical? It can be physical because people like to to hold the real thing and read it. But there's going be a bunch of other stuff that comes along with it that will make sense in any format other than digital anyways. So it'll probably end up being like kind of a web portal that'll have all the content from the book plus a bunch of visual resources and stuff like that as well. But we're, we're hoping to do a physical one just if for no other reason than I would really love to like hold a book in my hand that has my name on it. You know what I mean? That's a cool feeling. Well I think it'll be cool.

Chris White: 6:23

Yeah. I've, I've heard anytime I've talked to like a technologist, has this either done a book on site or decided to do it as their main thing that I've always like Kurt, the recurring message that it's kind of a painful process, like just a lot more work than any of the content publishing routes that we know about already. Have you found that to be true? Do you mean in terms of like putting together a physical book versus before digital? Even just across both, like it seems like there's just a lot of, you know, if your goal is to produce what you're calling a book, there's like this goal of like having all the content completely produced and ready and finalized and and I've heard, I've heard that that just can be kind of a slog.

Adam Wathan: 7:06

Yeah, it can be for sure. I mean it's a, it's a big thing to, to commit to, right? I think what's made it easier for, for me and what I've been doing, taking to even more of an extreme on this book than I did with the first book that I put together and is just trying to structure it in a way that every piece of it is like sort of as isolated as possible, so I don't know if you've read like rework, like the 37 signals, rework book, are they always like structured our stuff in these like just these individual assets where they're kind of like categorize together because some of them are unrelated subjects, like maybe all the ones related to marketing go here and the ones related to getting started go here or whatever. You can basically flip to any page in that book and just read a chapter sort of in isolation and you get the full message like it's not depending on some previous part of the story that you haven't read or something. Yeah, I'd love that format. I really liked that format. Yeah, right. It's really digestible. It's just a really great format I think, and I don't see it often. In fact, you often see the opposite where people look at something and they think, okay, well this has to be a book, but it has to do my best to like book it up. You know what I mean? Like

Chris White: 8:15

right in the introduction where you're explaining all of your flaws and approaches and things like that.

Adam Wathan: 8:20

Yeah, yeah. When no one really wants that, people want you to get to the point. If you can fit a lot of interesting points in there, that's great, but be clear and concise and don't just fill it up with stuff that's just meant to increase the page count or whatever. But anyways, we've been trying to take that same sort of 37 signals base camp inspired approach to how we're structuring this book where every chapter is totally independent, which makes it a lot easier from the writing side of things because I can just kind of look at our table of contents and see, okay, well which, which chapters aren't done yet? Pick the one that I'm kind of feeling most inspired to write today and just write it on its own. I don't have to try and write the whole book from beginning to end and have it make sense. It's like one continuous story because it's just not designed to work that way, so it ends up feeling more like writing for your 50 pretty short blog posts than it does try to fit, trying to create one big piece of content, if that makes sense. That's awesome. Yeah. I've found that format to be just super duper consumable and it doesn't make sense a lot to have to consume a book and like small pieces, but it's so much easier to do it that way. And if, uh, if chapters just kind of stand on their own and make sense in our individual great lessons that, that sounds really valuable to me, I would look forward to reading that. Yeah, exactly. So we're kind of betting on that being a format that people are gonna, you know, enjoy and get value from and uh, we'll see, see how it goes. So. Awesome. Awesome. You kind of alluded to it earlier, but how does three factoring Ui as approach to teaching Ui lessons differ from like other kinds of books or courses and things like that? I think the main advantage that Steve and I have kind of working together is that he's a designer, right? That's what he's done forever, is the Ui designer. He's sort of been an artistic person his whole life, sort of like that right brained creative sort of person. And I've always been like a developer who likes math and likes things that are measurable and concrete and really analytically minded and we've been working together on just like side projects and stuff could be actually live in the same town. Great. Um, and have been friends for years. So we've been working on stuff together for a long time and just over the years working together I was, I started picking up things that he was doing that was making stuff look better that he never would have really liked thought to explain to me in the way that I was like noticing him doing it. You know, just little things like offset your box shadows vertically so they'll look like more natural. Just little things like that that most designers just don't really think to, to point out a lot of the time because it just seems like second nature to thinking more compositionally where it's like, how do I keep moving these things around until the light goes off in my head and it's right. Exactly right. So working together, I feel like we have this interesting opportunity that we've been trying to sort of take advantage over the last couple of years of taking the stuff that he's really good at. Figuring out like how to dissect that into a way that makes sense to me as like a developer in a way that I could apply to my own stuff and sort of like filtering his knowledge through me so I can like tell that to my tribe of people who are, you know, other developers and just trying to help bridge that gap. And uh, so far I think, I think it's going really well. Like we have Steve's going 35,000 people who follow him on twitter for these tents and stuff now, and there's a lot of people who have signed up for updates on the book and stuff and, and uh, everyone's saying like these are types of men and super helpful because it's just so much more tactical and specific than that, we don't really talk about stuff like understanding color theory or the different types of type faces, like a humanist fond phase versus a grotesque font or you know, things that maybe are interesting to someone who's pursuing design from like for. It's like artistic merit

Chris White: 12:26

from like an art school one o one kind of perspective.

Adam Wathan: 12:30

Yeah, exactly. But for someone who's just like, I want to build this cool tool to solve my own problem, but when I hit the Ui it just looks ugly and I don't know why. And it's kind of killing my motivation. Inspiration to even work on the code, you know, we're trying to help people get those super quick wins to just Polish their stuff and make it look good but not, not understanding why. Like we made sure to explain that to, but it's very much coming from this goal driven perspective of like, okay, do this thing specifically and this is going to look better and also this is why it looks better in case you're interested in that and sort of taking that approach is just seemed to work a seemed to work pretty well for us. Again, I think just the advantage is being able to work together and sort of filter this knowledge from a developer's perspective instead of just someone who thinks like a designer trying to teach something to a developer but not necessarily being able to sync up and how they think about things and really communicated in a way that really resonates. So

Chris White: 13:33

yeah, I liked that a lot as a work in different contexts but in one context. So it's building small applications just on my own with no designer support, nobody's templates, bootstrap, et cetera. Like I was. I was intelligent enough about it to know that it was bad but not really intelligent enough to know. I know that like this much margin will make it look less bad, but overall like compositionally always would be like a total mess

Adam Wathan: 13:59

and I think that's a lot of the developers. I think a lot of developers care about design and they see beautiful designs on the Internet and they're inspired by it, you know, and they think they go to like stripe or something like, wow, this looks so sick. I wish I could make something that looked like this even though they don't want to be a designer, they just want to be able to produce for their own sort of thing. So

Chris White: 14:22

refactoring Ui is kind of a bucket in your life and how long you've been doing educational things and trying to bring new things to developers to help them work on another part of that story. His tail and CSS, right? He can't tell the story of how that kind of came about and what your goals are for tailwind css.

Adam Wathan: 14:39

Yeah, sure. So as a kind of utility focused css framework that myself and a few other people I collaborated on, it released late last year. It was sort of born out of basically the specifics of the story is I've always used bootstrap for was kind of a starting point, um, like, like a lot of people make sense and when who's trapped before or was coming out, they were switching from less over to sas. That's just changing the CSS, preprocessing preprocessed where they were using. And I've always loved last and hated sas for a bunch of nitpicky reasons that are probably not worth getting into. But um, when they announced that they were going to be switching to Sass, I was like, Eh, I don't really want to switch to sas. Maybe I'll start putting together my own little less space framework, trying to sell the same sort of problem, give myself sort of a starting point for new projects so I could kind of hit the ground running a little bit faster. Right. So I started kind of putting together something at. Basically what I did is I started building a project and decided, okay, I'm going to read all the css from scratch using less but no framework but sort of thinking about the css that I'm writing from like a framework mindset, like trying to author it and sort of a library ish way so that I can bring it around to other projects. So be careful not to name things so that there were specific to the content of the project that I was working on, you know, thinking of about it in like a css that hopefully I can apply to different projects that have different types of content sort of way. Um, so I just started building this thing and creating the components that I needed, buttons, inform influence and cards and whatever. As I went, kind of just kept that in a folder that I would copy around to new projects. And over the course of a few projects, like every time I bring it to a project I would notice like, okay, these buttons that I used on the last project, I don't really want the buttons to look at it this way. So I need to sort of take those out of the framework so that I can edit them and kind of leave those as part of the project and I just started noticing from project to project which pieces of the framework were like surviving and it was always these really low level utilities like stuff for controlling the spacing between two components or adding a box shadow stuff that was just like mostly just applying one css property. A friend of mine, Jonathan renting kind of saw me doing this and wants to try it on one of his projects because he had never worked this way before where you're using a lot of these little utility classes. He tried it and really loved it and said, you know, we should try and figure out a way that we can turn this into something that we can both like installed from npm and use because at this point he was still just like a folder on dropbox that you would copy paste in your project. And it's a project template but not like a framework of any kind now. Like a real dependency or anything. Right. So we were trying to figure out how can we, let's try and make it as portable as possible and not a copy and paste fish way. So we just kind of worked on it, worked on it. I was working on my project, he was working on his and we were just trying to figure out like, okay, well what do you need different than mine? And that sort of drove a lot of decisions around like okay, well how does need to be customizable versus not customizable? And it started as this last framework but going down this path and making sure that it can output what Jonathan needed and what I needed. We started running into roadblocks in terms of what was just realistically possible with less in terms of dynamically defining how many break points are going to have or how many colors and things like this are actually almost easier. And Sas because sas is that more imperative in terms of being able to like loop over a map of things and generate everything. Whereas last year to do all this funky recursion stuff and things start to get really, really out of hand and really hard to maintain really, really fast because it's now a real programming language, so I'm trying to do programming language things with it. So after kind of hitting some of those roadblocks and another friend of mine turned me onto post css, I didn't really know what you could do with it originally. Filmed the examples I've seen of posts, ess based tools, so like autoprefixer, right, which goes to your css fall, kind of scans it for properties and duplicate those properties with the appropriate prefixes to, you know, improve bras for support, stuff like that. That's a great tool, but I never really understood like how can I use post css to critic a CSS framework? Is that really in the scope of what's possible? And through sort of talking with this friend of mine, David Hensville, who had worked with it a little bit before I started to figure out like how to use post css to sort of generate css. So css has this concept of our rules, right? Which are like media queries are an APP rule or char said, isn't that rural or import an rule and because post css, all it does is kind of Parse the CSS file and turn it into like an abstract syntax tree that you can walk and manipulate. It doesn't force you to follow like the CSS sex super strictly. It will parse anything that looks like css even if it contains at rules that aren't real outros and CSS Spec. Oh, interesting. So that was sort of like the secret sauce to figuring out okay well we can have the user put these custom am rules in their css templates and we can lock those rules for post css. When we find one of those roles we can replace it with a bunch of generated css. So we eventually through kind of experimented with that and came up with this approach of having a css framework that is really like a tool for generating css from a javascript based config file. And that config file is really like. It's more like a design system in Jason that it is like a config file per se. Like it lists all your colors, your type faces that you want to use, your spacing scales and stuff, like all your sort of constrained choices for this Ui that you're building, kind of like variables or settings file that you would have in many projects. But the insight of like a framework. Yeah, yeah, yeah. So yeah, we were able to write this to other basically takes that configuration as a dependency, looks in your css file for these sort of markers where you want to inject kind of tailwinds code until when will replace this rural like tailwind utilities with all these utility costs is generated based on the information in this config file and it was so much easier than doing it with less because you could do it all with Java script, like it's a real programming language now. So all the strategies that you're used to using to write maintainable code are all available to you instead of trying to, you know, really abused the stress, the limits of what a preprocessor like lasts was designed to be able to do. It sounds like you narrowly avoided using sas, which is what you're trying to get away from in the first place. I even, I even tried to use that so at one point, but it just, it just didn't really feel right. Like there's, there's one thing that I always did with last. This was the thing that I liked about last and I have you worked with like last sure projects before or they coincidentally just all of my projects of the last five years had been in sas so I have not been exposed the differences really. So you know how in Sas you have a mixed sense where you do like at mix in, give it a name, specify some properties and then somewhere else you can say add, include and then they mix in and it'll kind of dumb. So something that you can do in less. That was kind of cool was the syntax for defining and mixing and actually looked exactly at the syntax for defining a class. So since in Sas do you want them to have a mix in for like A. I'm trying to think of a good example. Like A, a box shadow extend or something, right. So maybe you would do at Mixon large shadow and that would let you just mix it in this large box shadow in the places. So instead of doing at mix in large shadow you would just say doc large shadow, just like a class and then define it. And the thing that's interesting about that is that would actually produce that class and the output to as long as you didn't put any parentheses at the end of the class name because it kind of, it sees parentheses is like okay, it's a parametric. Makes Sense. So that means it's a mix him we're not going to render and the style sheet, but if it has no parentheses then it's a class but classes can be used as makes sense. So then anywhere you want it to mix that in, you would just say dot large shadow inside of another class and it would just show up there. So it's a lot less verbose, it sounds like really clean syntex. Yeah. And the thing that's neat about it is less is not really picky. Well, nothing that's not picky. It's semantics around like order are very different. This sas, sas is like to use a mixing, it has to be defined already so that makes sense. Have to be defined before they used, whereas in less than Mexicans can be defined after and be used in classes that are defined earlier. So that meant that what I was doing in less of all the time is I have these utility classes like dots Fiji primary or something, right, for setting the background color or something to whatever, my primary brand color ones. And then for a primary button I would mix in that bg primary class, but that button could be defined before the utility class so that the utility class had a higher, not higher specificity. It's the same specificity, but it would override it because it's defined later in the style sheet. Yes. I want it to be able to make it possible to support that workflow with tailwind, which sas was just going to make really hard to do. So, uh, anyways, as a result of kind of wanting to support all on stub tail and also has this feature where you can say apply and then specify a list of other class names and it'll copy those class name or those definitions into this specific class. So telling generates all these utilities for you and then for your own custom components and stuff like that. So say you're creating a card for your project and you want to define what a default card looks like. Maybe it has this specific shadow, this border radius was background color. You can just say add, apply, and then list all the utility classes that you wouldn't be used to build, build that card purely an html. We'll just like seven classes and then you can just apply that doc hard class anytime that you want. But instead of class just being loaded with properties with arbitrary values, you're sort of constraining yourself to your existing sort of toolkit of predefined utilities. So it makes things a little bit more consistent. And I think also frees your mind to work a little bit faster because you're not playing around with like, oh, should this be 15 pixels or 16 pixels? It's like, well the spacing scale has four, eight, 12, 16 and 24. So I just got to pick the one that looks closest to what I want. It gives you like a following, a design system that you've set out much easier. Yeah, exactly. That's kind of the history of the project. And so it was kind of hard to figure out the best way to explain some of these things because once you're so deep in something, it's easy to sort of forget what people don't know already. Right, right. So one thing that's interesting is, is it because you are applying this post processing, using posts, css, are people using this in like vanilla, CSS, less ancestors? Is it specifically enabled for one of those? So you can use any preprocessor with it with which is Kinda cool. So it works the same way that autoprefixer would crying. So it can just work on anything. We have run into issues where some people don't have the right mental model in terms of like understanding when the stuff gets generated because your last or sas or whatever has to get compiled into css and then that css gets processed with posts, ess to some people want to be able to access a tailwind color value in their sace and they can't because that stuff doesn't exist until the SAS has no longer sas anymore. Get it. So you kind of need to fully embrace the framework or find out, find ways to use either. I think, yeah, I think click. What ends up happening is that people who are using a preprocessor with it are mostly just using preprocessor features that are syntactical and not really related to like specific values they're trying to create. So they might be using like nesting is the most common one. That's what everyone wants to css preprocessor for that and variables generally. Right. Nesting of variables. It's usually the first thing, like it's the primary function for preprocessing and most of my projects. And then if you're. If you're using tailwind and sort of embracing the workflow that the framework tries to encourage, um, you do really need variables. Um, so you end up just using it for nesting and uh, there's, which is very useful on. It's totally especially useful. You can just like just for nesting media queries, if that was the only thing that I could do, so we worked at it to me, right. That would still be a very worthwhile require in your package, Jason, but you can get nesting support with just post css to music. They used to be a tool called css next, which is still around but deprecated now in favor of posts ess preset, which is kind of taking the same approach that I'm kinda like Babel presets. So it's kind of designed to, uh, give you future css features now. Right? Which cool thing, there's like a future CSS SPEC for nesting, so as opposed to assess plugin designed to let you use that syntax now. And once all the browsers supported that processing step can get removed and things will just kind of work. Right? So yeah, on my own projects I'm typically just using, you know, call it plain css, but it certainly isn't because he doesn't understand it because it has stuff. I'm just using future planes, css, I'm using a combination of post css plugins and not really using a processor at all anymore. Um, I mean that's also still a preprocessor not a process here, at least not in the way that it's people like me abuse it for, to bend it to our will in terms of like what it was designed for, like autoprefixer is why post css exists that, yeah, that is opposed processors taking bouncy assessment, processing it. But the things that people do with it, it's hard to, uh, to call it a true post processor. It's really just another pre processor been very cool. Very cool. So it's been out since the end of last year. You mentioned A. Yeah, I think we released it on Halloween last year. Very cool. So closing in on a year, a year, next month will be, it sounds kind of cool. Awesome. What would you put the status of the project in which you call it already successful or do you feel like there's a lot still to do? What are your goals for it? There's a lot still to do, but I had been pretty impressed with how much it's taken off. I'm like, I don't know. I'm trying to think here. Like what do we got in terms of. So we've got like 6,400 stars on get hub. Not that that necessarily means a lot, but you know, it's something, it means something. It's gotten over 300,000 downloads on Mpm, which is total. So you know, probably$100,000 from me, but you know, we have 71 contributors on projects which just really good and awesome sign of health. Yeah. So it's, it's really active. I'm still working on it, pushing new code and fixing bugs and we're implementing new features every month for sure. I use it on all my projects and we've got a pretty active slack channel with like 800 people in it and I'm hearing more and more everyday people using it on more and more real projects for. I like it still doesn't have like a one point Oh version. So a lot of the stuff is people just playing around with it, but I know what procter and gamble use it on a site recently, which was pretty awesome. Wow, that's pretty cool. Yeah. I know a lot of companies are just in general moving to a similar CSS offerings approach, like a lot of other frameworks that exist out there that are similar in terms of what they provide. Like tacky yawns is another really popular. I'm like functional css framework and like Heroku. This tack ons, for example, they recently switched from their bootstrap based setup. Get hub uses their own. It's called primer. Is there like internal framework which was very bootstrapy at one point. If you look at it now, there's so much of it as utility based, and I interviewed Diana mounter who's she's like the design systems to lead a get hub and I was talking to her about like what they've been doing in primer and it sounds like they're just moving more and more and more towards these utilities. She described it as like the developers feel like they have like super powers now because they can just do something and it does exactly what they want and they don't have to worry about all this global css breaking stuff and stuff like that. So

Chris White: 31:44

I've consulted in on a couple of larger engineering organizations and the difference between CSS happiness and css unhappiness on the developer side seems to be these design systems. Because when you're, when you know you've received from from whatever design team, usually they will have like places where it doesn't. It's not very, you know, you'd look at a three year old design guidelines. Stock and new designs will usually follow those guidelines is so you're like, well I could use the. Now I have to implement new css to kind of override these guidelines and you know, it doesn't feel it stops feeling very cohesive and so if everything isn't a system and if there are changes to like this whole overall design kind of guidelines, it has to be moved through the system to be successful then that, that just feels really good as a develop.

Adam Wathan: 32:34

Yeah, for sure. Like even in situations where you get designs that don't necessarily match like the design system, like maybe someone needs the 13 pixel font and your system says you only have 12, 14, 16 and 20 or whatever. I've definitely found that I like, I've been happier when I've worked at places where I can decide to, okay, well that's 13, but that's not part of the system so the solution isn't add 13 in the css somewhere. It's used 12 or 14 on my own discretion, you know what I mean? And it kind of working in that sort of like don't treat the pixel perfect. Photoshop mockups, that's the source of truth. Just kind of use that match as close as you can without deviating from the system. I found that's always been a more productive and also just results in a lot more maintainable css code base because it's writing maintainable. CSS is a skill that

Chris White: 33:29

I've. I've found that to be very difficult. I found that regular front end, back end code maintainability on that. There's a lot of conversation about that, but I've found that whenever I get, you know, as a consultant bouncing around between different projects, whenever I get on a project that has an older code base, the biggest mess is the CSS.

Adam Wathan: 33:48

Yeah. No one respects the CSS. Right. That's the problem I think, and it's sort of. I think that the problem is we've sort of had an ingrained into our heads that like the way to style something is to write css, which I. When you say that, it's like, yeah, of course that's, I just saw something, but I think like the way that you should style something should be to apply existing css. Got It. Because then your css isn't growing linearly with the size of your code base. Right? Right.

Chris White: 34:21

And your goal is a, as a developer and as a product, is to have cohesion and make things, you know, make everything kind of hang together well and easy to consume and understand.

Adam Wathan: 34:32

Yeah, if you're running two regular traditional, not regular css necessarily sas, whatever, but you're working on a project that has global style sheets and that's how things are styled. Well it's hard to maintain stuff that has global reach on your code base. We're changing something can have unexpected side effects on a page that you didn't even know existed. Whereas if you can work in a more market driven approach where you style things by adding classes had already accessed, anytime you add a class to an element that's like a localized change, right? Like cost to this div isn't going to change how this dip over here Lux, but changing the border radius on some class in your style sheet could affect it. Anything in the system you don't know where all that stuff is being used and it's hard to get good insights on that really, other than just doing these big graphs on your codebase anytime that you want to change what a glass does.

Chris White: 35:29

That's right. That's right. I guess it's the same thing with, you know, oh, in any sort of other system, right. Like you don't, you don't modify your base classes, implement functionality in one place. Right. Exactly. Yeah. That's a great analogy. That's cool. That's cool. Well, I definitely want to be respectful of time here and start to wrap up. I always ask, is there anything that you'd like to promote for you, the podcast, other than what we've obviously mentioned already?

Adam Wathan: 35:52

Sure. Yeah. I mean, um, if you're interested in learning more about the refactoring Ui project, you can just tend to re factoring Ui.com and sort of a, a home page we've created that links out to all of the other resources that we've, we've put out their talents. CSS is just come like you mentioned, I was the full stack radio podcast, which is mostly an interview kind of focused podcast for just talk to people that are doing things I think are interesting. Sounds like a lot like what you do on this podcast and doing that for about four years now, so four years. That's awesome. Yeah, so you can check that out. Aside from that, I've got my personal website is[inaudible] dot me if you're into a tester and development with layer val. I've got a tdd course that's on.com. I've got a course on Vue, component design@advancedview.com. And then the first book that I wrote was a book on teaching some functional programming principles to php developers to refactor a bunch of procedural loops and stuff like that. That book was called refactoring to collections, which uh, you can find them just on my personal homepage there's a book item, but yeah, that's kind of like everything that I do that your entire portfolio, that kind of my entire portfolio stuff. So if any of that stuff sounds interesting, you can go and check that stuff in.

Chris White: 37:13

Yeah, we'll definitely include some links for all that stuff that I definitely am going to try tailwind css on the next side projects. You've definitely given me a great pitch on it. Cool, man. Cool. Cool. Well thank you so much for joining me, Adam, and thank you so much everyone for listening. As always, if you'd like to continue to follow up with us on twitter at coding zeal and see you next time. All right, thanks everyone.