I got to talk with Micah Godbolt this week! Micah is is a long-hauler at Microsoft working on Design Systems and such. His CodePen account looks a lot like mine: steady consistent usage of “just trying to figure something out” Pens sprinkled with some ideas that somehow seem to click with the wider front-end world. I found it fascinating that putting the word “Design Systems” into his book title “Front-end Architecture for Design Systems” was suggested by the publisher, and they were right! Turns out the term Design Systems clicked a lot harder since the 2016 publication and I’m sure hasn’t hurt sales!

Time Jumps

Sponsor: Linode

Visit linode.com/codepen and see why over a million developers trust Linode for the infrastructure.  From their award-winning support (offered 24/7/365 to every level of user) to ease of use and set up; it’s clear why developers have been trusting Linode for projects both big and small since 2003.   Linode offers the industry’s best price-to-performance value for all compute instances, including shared, dedicated, high memory, and GPUs. Linode makes cloud computing simple, affordable, and accessible allowing you to focus on your customers, not your infrastructure.  Visit linode.com/codepen, create a free account and you’ll get $100 in credit.

Transcript

[Radio channel adjustment]

Announcer: Today, on CodePen Radio.

Chris Coyier: Hey, everybody. CodePen Radio 367. I have an old pal joining me here on CodePen Radio. Micah Godbolt. How ya doin', Micah?

Micah Godbolt: I'm good, Chris. Thanks for having me on the show.

Chris: Yeah, you're just over the range, as it were.

Micah: Over the range and through the woods. Yes, in Portland.

Chris: Yeah, quite literally. Portland, yeah. I'm over in Bend, so yeah. It's funny how they're just far enough away that you don't get to see your pals in one or the other as often as you might like. But still, it feels good to talk to a home state fellow.

Micah: It feels -- exactly -- local. Close to the state.

Chris: Lots of stuff we could talk about. It doesn't hurt to have somebody that uses a profile photo with a CodePen logo on the hat. You know? It's kind of--

Micah: [Laughter] You know--

Chris: It's an easy way to get on the show, for a record.

Micah: I lost that hat a while ago, and I was super bummed. I need to order another one because it was one of my favorite hats.

Chris: Oh, no. You can't. Those are long gone, man.

Micah: ...even--

Chris: I have a personal staff, which, if you really are nice, I can send you one.

Micah: Apparently, I'm going to have to come out to Bend so I can get one of those hats because I left--

Chris: Maybe that should be the bar. Yeah, you've got to come visit.

Micah: I think I left it at a conference or something, and I was so mad that I lost that hat because it was a classic.

Chris: Oh, I'm sure it was stolen. You know?

Micah: Yeah. [Laughter] Probably sold on the black market.

Chris: [Laughter] Yeah. Those are cool, though. That's when I formed my love for legacy brand hats.

Micah: Mm-hmm.

Chris: They're just so nice. Anyway, maybe we'll order some more someday, but getting out of the merch game doesn't bother me. Not exactly our core business.

Micah: No doubt.

Chris: Might as well leave them wanting.

00:01:42

Chris: You're at Microsoft.

Micah: Correct. I've been there five and a half years now, which is the longest stint I've literally ever had at any single job in my entire life. [Laughter] It feels weird but good.

Chris: Most Microsoft employees I know are pleasantly secure and pleased with their role, which is cool.

Micah: Yeah. It's been fun to kind of watch the company. I joined five and a half years ago, and the company has changed dramatically since then and just continues to improve and do good with their choices. I'm just always happy to kind of see that and see that even play out in the market. It's fun to see what we're doing and be part of it.

Chris: Real allies of the Web for at last that amount of time.

Micah: Which again is a huge change. Five and a half years ago, it was kind of like, "Uh..." Now, IE 11 is officially dead, dead, dead, dead, dead.

Chris: Yeah.

Micah: We're doing a ton of great work in Chromium, and we're trying to push everything forward as much as we can.

Chris: Mm-hmm. Yeah, and actually provably doing that, which is cool. I don't know how involved you are with that. I think of as--

During our heyday of conference action stuff, you were the front-end architecture guy, or at least kind of tried to pin that term down.

00:02:58

Micah: I did and, actually, I wrote a book called Front-End Architecture, and O'Reilly came back and said, "Well, how about we say Front-End Architecture for Design Systems?" I was like, "Eh, it's not really. I don't really know what this design system thing is. It's more front-end architecture. But sure, why not?"

That was a smart marketing move on whoever's choice that was because--

Chris: Oh, they were right, it turns out.

Micah: Yeah, they were. That's totally the term that took off, and it'd be silly not to do that now.

Chris: But is that what you meant? You kind of were meant to say design systems, in a way?

Micah: Yeah, I didn't know what a design system was. When I built my first design system, I was working at RedHat. They basically asked.

We had all this UI code, and they were like, "How can we use this UI code from a website over on this other website?" I was like, "Hoo! Well, first, you've got bootstrap, and then you've got all the CSS and all the JavaScript, and really, you've got to take all of our CSS and JavaScript, and then somehow untangle all this HTML. Then you can move it over."

Chris: Right.

Micah: Or I can just rewrite all of it and make it more portable and it'd be easier to move it. They're like, "Okay, go ahead and do that."

Chris: They bought the rewrite? Oh, wow.

Micah: They bought the rewrite, and I was like, "Ooh, you called my bluff. Well, shoot. I guess I better start."

Chris: Uh-huh.

Micah: Then they asked how many times I'd done that before. I was like, "You'll be the first, so we'll see how it goes." [Laughter]

Yeah, I had no idea really what a design system was. It was very still new at that point, so I was calling it front-end architecture because back-end architects were a huge thing in Drupal. They came in at the table early. They made all the decisions about how we're going to build all our content types.

Chris: Okay.

Micah: And how the site is going to get pulled together. Then they put all the markup together. Then went [raspberry], "Okay, front-end guys, make this look like it's supposed to look like in the Photoshop docs."

Chris: Right.

00:04:46

Micah: I'm always like, "You know, if only there was a front-end architect there at the same time as the back-end architects, we'd have a better product at the end of the day when it gets spat out."

That's basically what design system turned into being is the product that the front-end architects would build to be able to turn back-end code or back-end intent into front-end code. We got there eventually. It just took a little bit of time and it was kind of a fun journey.

Chris: Open up the amount of seats at the table in beginning, and it reminds me of, in a way. Yeah, maybe around that same time, in my brief stint at Survey Monkey, somehow that--

I think I maybe raised my hand for it like you did. I still have a really old GitHub repo that's like Survey Monkey design patterns - or something. I called it design patterns. I think I got that right because I feel like there's still a distinction between a design system and design patterns. Design patterns are a smaller circle in the Venn diagram where it's just like this is the thing that's a dropdown menu - or whatever. Whereas a design system probably you can think about the tokens, and you can think about other uses that - I don't know. And rules.

Micah: Patterns are often compositions of lots of other components, like this pattern is something we use on this page, which is ten different components put together in a particular way - or something like that.

Chris: Yeah.

Micah: And doesn't have to be exposed with a single API or anything.

Chris: I remember at the time, our goal was just Web usage and just, like, I want to have some named things that I can compose pages out of. I want our own bootstrap, in other words.

I'm sure it worked out. Who knows where they're at today, but it's crazy how much it's taken over, hasn't it? My gosh.

00:06:40

Micah: Pretty much, and everyone is building their own. We're investing tons of money at Microsoft into trying to build a design system right now because we had several kind of patchwork systems that built out of different parts of the company.

Chris: Okay.

Micah: Built out of Office, which is what I got involved in. Another one built out of Teams. Another one built out of Azure. All these different systems.

This is just Web, and all these different design systems built out that, as we tried to unify it on a single design language, we still had this problem of, well, we have all these different teams building these controls out. They're all slightly different. How do we take an experience from one team and then render it in someone else's application?

Chris: Okay.

Micah: How does an Office Calendar show up somewhere else and look correct? A lot of the work was done to try and unify those together, bring those in a common system, have all those tokens and everything that's required to actually make that scale across.

Chris: Well, at least you know that high-level basic of "We have a problem and we need to solve it for our problem." Even that, I feel like, gets conflated sometimes. I feel like the most famous design -- at least it was for a long time -- was the Lightning Design System from Salesforce, which was (and still is) for them. But if you Google it, you get this page that's like, "Here's our alignment utilities and stuff." That's really neat to look at, but it's like, "Not for you." I always find that confusing. Who is this for? I feel like every design system needs a big banner at the top of the page that's like, "Hello, looksie-loos." You know?

Micah: [Laughter] Thanks for stopping by.

Chris: Welcome to see how we do things, but this is not really for you to download and use. But that gets confusing because Google made material design, and they have advocates that are like, "It's not really for Google. It's for you."

Micah: Yeah.

Chris: That's so different and weird to me.

00:08:41

Micah: I think Salesforce is in a similar position to Microsoft in that we have a lot of third-party developers who are trying to build experiences that fit into our experiences. Whether you're building something in SharePoint and it's your app, and even Salesforce builds stuff that shows up in SharePoint, so they might possibly use our design systems to build out dropdowns, buttons, and so forth so that their experiences look like Office when they sit inside of an Office application.

We certainly have first-party versus third-party and ensuring that the product works for both. The primary focus is definitely making sure that first parties can really build on it and is strong for that. But always with that mind it is open-source. We know that we have an audience that needs to use those. And we ensure that we're not breaking them and keeping them from being able to use that product.

Chris: It's kind of my favorite use case is, like, "This is for us, but it's also if you're building third-party stuff that's kind of (ostensibly, at least) for us."

Micah: Yeah, exactly. It's still going to benefit us, and I think that's kind of it. It's for the benefit of us because we want those other companies to be able to build experiences that fit seamlessly in our experiences. It's not necessarily for them to go out and build their own apps and do cool things, which I've heard of people doing it. It's fine. It's great. But our main focus is definitely so you can build experiences that look like Office or Teams or whatever when they're inside of those native applications because we do host so many third-party applications inside of it.

Chris: Mm-hmm. These are the problems you're thinking about at work, huh? That's cool.

Micah: Every day. Every day. [Laughter]

Chris: Cool.

00:10:24

[Guitar music starts]

Chris: This episode of CodePen Radio is brought to you in part by Linode. That's linode.com. Visit linode.com/codepen and see why over a million developers trust Linode for their infrastructure.

Award-winning support offered 24/7/365 to every level of user. Ease of use. Ease of setup. It's clear why developers have been trusting Linode for projects both big and small since 2003. Linode offers the industry's best-priced performance value for all compute instances including shared, dedicated, high memory, GPUs.

Linode makes cloud computing simple, affordable, and accessible, allowing you to focus on your customers, not your infrastructure. Visit linode.com/codepen and create a free account. You'll get $100 in credit. Thanks for the support, Linode.

[Guitar music ends]

00:11:24

Chris: You know it's just serendipitous timing a little bit, at least to fuel the conversation a smidge more, there's this Josh Comeau guy. I've never met Josh, but he's this great blogger and has this big CSS course lately. I don't know if you've come across his site.

He published an article. He mostly writes on his own blog, but said, "This is my first Smashing Magazine article," and it just came out yesterday. It was called "You Don't Need a UI Framework."

He was pointing at things like material design or bootstrap. Part of it to me is like, "Hey, grain of salt. This guy sells a course that's about not using UI frameworks. Cool."

But he's a great writer and he made some good points in there. I think my favorite point of it -- because I think he gets asked, like, "Why would I--? Isn't there a world in which, especially with how grateful stake frameworks are?" If you have a little bit of back-end chops, you could throw up a Next.js site and throw a nice, modern data store behind it and build a crud app so fast. But you have no design chops. I feel like there are lots of people in that bucket these days, perhaps coming out of code schools, whatever.

I think having great design skills is still a little bit rare in our industry. Why wouldn't I just throw one of these -- there's a proliferation of them, really pretty, beautiful pattern libraries -- at a site? That seems to make some kind of obvious sense, like, "Yeah. Why wouldn't I?"

00:12:53

Micah: Well, it's the same reason that I'm not writing my Node code from scratch. I'm not writing my own version of Node. I'm building on top of--

Chris: Just using the old abstraction ladder.

Micah: Yeah. It's like, where do I want to spend time investing work in? For a lot of people that are building out even a demo or a school app or proof of concept or something, there's no reason you have to write a bunch of custom UI code. There's really good code out there that is accessible and extensible and performant. If that's not your focus, if you're not trying to build a cool UI framework, that's going to do you really well. Throw some tailwind in. Throw some material in. Throw in some fluent UI.

Chris: Well, that's where I'd catch you. I think that's the interesting aspect to this because there are a lot of people that make that choice that are like, "Yeah, I get a lot of benefit from picking one of these things off the shelf." Josh's point was you don't, though, actually.

Micah: [Laughter] Okay. I should read this article because honestly, I haven't seen it yet.

Chris: Yeah, well, it's just -- you know, whatever. It's just great clickbait for this time and place.

Micah: I was going to say clickbait.

Chris: Just a little, but then there's another point though that you see a lot of this usage of these libraries, and then, at some level -- I don't know what you'd call that scale I'm talking about -- popularity or usage. Then at some point, really big or successful products, you just don't see it anymore. You know? Maybe at Microsoft you do - or something - because they're trying to wrangle it in -- or Google, or something. But most big, famous sites roll it in-house. They don't just use it--

00:14:32

Micah: Well, and that's, again, I think it comes down to economy of scale and if you have the staffing then to be able to do that. Yeah, you're going to have a lot more flexibility by rolling something of your own. If something needs to get fixed or changed, you have control over the number of tokens and how a style....

Chris: Yeah.

Micah: And where they're generated. But there's a certain point of a smaller team where you don't have the staffing for that.

Chris: Yeah.

Micah: You don't have the money to invest in it yet.

Chris: It could be a staff thing, but here's a point he makes. "No matter how comprehensive the library is, it'll never have all the pieces you need."

Micah: No.

Chris: "Every app and every website is unique, and there'll always be special requirements. Creating a brand new component," this is the clutch sentence, I think, "Creating a brand new component that blends in with all the existing third-party design systems is," emphasis on is, "really fricken' hard."

Micah: [Laughter]

Chris: I think that's a good point. "Oh, it has 85% of what we need. Let's just build the rest of the 15%." You're going to suck up that last 15%. [Laughter]

Micah: Yeah. Yeah.

Chris: That last 15%, you're going to poop the bed, I think.

Micah: [Laughter] Well, and that's the 80/20 rule where if you can get enough value out of that 80% and get something shipped and be good with it, great. But when you're looking at, okay, we've shipped something that's good. Now let's refine and get that 20%. Just awesome. It's going -- you're going to start hitting all those edge cases. You're going to start hitting all of the friction areas. You're going to start hitting the places where we want to do it this way, but the design system wants to do it that way. How do we reconcile that? That 20% is all that gets hit and run into.

That's going to happen every time that you scale. It's one of those things. We're trying to figure that out as well, as we try and come up with a good model for creating new components.

Chris: Yeah.

Micah: We're trying to make that better, and it's a hard thing because, again, those requirements from our teams, we need to be able to do X, Y, Z. And we also have the staffing to do X, Y, Z.

When we have an extensibility model, we can assume that there's going to be a large number of reasonably well-paid engineers that are willing to put the effort in to make that customization. You're not always going to have that.

A solo-entrepreneur working on their little app isn't going to have probably the time and effort and attention to do what we're expecting them to do with our controls because we kind of have a different expectation of who is going to be using them.

It's tough. You're never going to build a system that works for everybody. That's a point where you go, "Well, we just need to build our own and make it work the way we want to." It's a tough decision. Do you start with that? Do you cross that boundary halfway through and just do a little UI rewrite? Do you blend two together for a while until you take it all out?

That's every CTO's nightmare. How do you make this decision? How do we know it's right? What's going to happen if we make the wrong decision?

But that's typically the path you'll go through of, "We can go really fast getting out that 80% mark. Then we hit 80%. How do we get that next 20%? Is it important to get that next 20%? What sacrifices are we willing to live with?" because there's always going to be some kind of sacrifice.

Chris: Fascinating. Looking at some of your Pens, just for fun -- I know we'll talk about that, but let's try to connect the dots here a little bit.

There are some. Some of the ones that get hearted the most are ones that are named something really, really normal like Responsive, Multilevel Nav.

00:18:11

Micah: Actually, that's a great story, though. That was one of my first Pens that I wrote when I was first learning really Web at all. I think Brad Frost did a website that was responsive UI patterns, or something like that. Maybe there's a link in there.

Chris: Mm-hmm.

Micah: I might point out to it. They had a whole bunch of these different patterns. I was like, "Oh, these are really cool." What I want to do is recreate some of them. Maybe it was a bunch of JavaScript stuff. I want to try and do it only with CSS - or something.

I was using that as something to model off and trying to recreate some of them. That really kind of blew up, I think, because of that. I think maybe even that pattern got added to the page or something.

But, yes, that responsive, like CSS only, touch navigation, it was hilarious how much that blew up. Still to this day, I think I still get comments on there. I'm like, "Don't use this. This is really not the right way. It's probably horribly inaccessible. It was an experiment in using CSS." But it was fun. It was interesting to have something blow up like that. It was my first experience seeing that.

Chris: Oh, yeah. That's awesome.

00:19:30

Micah: Another one, which I don't know if you're going to jump to next, is the multicolumn equal height, multicolumn. Is that in your list as well?

Chris: Oh, that's one that's in a category itself in your Pens. It's kind of like you can -- [Laughter] It would just be so easy today. It's almost hard to wrap your mind around why this was ever hard.

Micah: Oh, yeah. Well, it's just Flexbox at that point. It's box ... done.

Chris: Yeah, or Grid or anything. There are multiple. But in this case, you floated some boxes. Obviously, some of them can be taller than other ones because there's no mechanism with float to tell multiple elements to be the same height. So, thanks, JavaScript.

Micah: Yes, exactly.

Chris: Figure out which ones are all in the same row. Even that is a little tricky. You have to test their top position to make sure that these three or these four or these six or this one - or whatever - is all in the same row. Once you have them figured out, figure out what the tallest one is.

Micah: Mm-hmm. Then set....

Chris: Then set the height on them. Of course, all of these early Pens are all jQuery'd up, which I really appreciate looking at.

Micah: Oh, they're just jQuery out the ears.

Chris: Yeah. [Laughter]

Micah: Definitely, I don't take full credit to that. I'm pretty sure, in that Pen, I link out to the original. I think the difference was I made it responsive or something. I added a bit more functionality to it.

Chris: Possibly. It looks like you bound it to the resize function too. It's one thing to do it once. But it's another thing to--

Micah: Exactly, to be able to do it over time. Actually, the fun part with that Pen was, again, I was at RedHat when I did my first big design system.

Chris: Mm-hmm.

Micah: I came into their code. I joined when they were working on it. I was looking at some of the JavaScript. I was like, "I recognize that!" There was literally that resize or the equal height code.

Chris: Oh, my gosh.

Micah: I made it into their codebase before I even showed up.

Chris: No.

Micah: That code got around.

Chris: Yeah.

Micah: That Pen was a lot of fun.

00:21:25

Chris: It's actually not. You could rewrite it today that it would be a little bit more efficient and stuff.

Micah: Oh, I'm sure.

Chris: The most criminal thing is there was so much of this in the early days of responsive design where we didn't have all the same tools. There was a lot of binding to resize.

Micah: Mm-hmm.

Chris: Which was just a performance nightmare, so it was nice.

Micah: Yeah, so there's some debouncing that needs to be done.

Chris: That's probably the worst line. Yeah, big time.

Micah: It worked. Back in those days, it worked, and that was the most exciting part.

Chris: Yeah. It sure did. It sure did.

Micah: What designer didn't want equal height columns?

Chris: Yeah, right. That was back probably in the days where we just put the scripts in the head too. It was like, "Yeah, you might as well." You know.

Micah: Mm-hmm. And you have no control over the DOM because usually this Drupal or something and they're spitting DOM out.

Chris: Yeah, good point.

Micah: The designers are saying, "Hey, can those columns be equal size height?" [Laughter] We're like, "No!"

Chris: [Laughter] No, but I'll make jQuery do it.

Micah: With enough JavaScript we can make it happen. [Laughter]

Chris: Yeah, and we did. We did. It's interesting to think of the whole forest - or whatever - at the time.

Micah: Mm-hmm.

Chris: It wasn't just one thing you can point to. It's a lot of things that I appreciate that insight. That was cool.

Let's say today, though. Let's say this wasn't a weird or bad idea, you know, equal-height columns or a multilevel menu, because a multilevel menu still to this day has some complications.

Micah: Certainly, and to do it right.

Chris: Especially mobile. Yeah. To do it right.

Let's say y'all figure out a way to do it right at Microsoft, and you want to ship it as part of your system or as a component or something. You've got options these days to take it to a more modern problem.

Micah: We do have.

Chris: How are you going to choose to ship some of these components? Do you pick a JavaScript framework in which to make it the foundation of all these components or are you more interested in the Web component world or what?

00:23:20

Micah: Yeah. At Microsoft, we're kind of hitting all of them. I guess by all of them, I mean React and Web components.

Chris: [Laughter]

Micah: I know.

Chris: The two big ones. [Laughter]

Micah: And native as well, all the natives as well.

Chris: Yeah. I can see Vue, but I don't know if I could see making Angular components.

Micah: Yeah. At least not at Microsoft. Yeah, we've talked about Vue, but it's again our product teams use React. And so, we don't have any financial reasoning to build out Vue components.

Again, our third-party model is we want to build out components our first-party can use and then also third-party can use to build stuff that fits in the first-party. There's just not a lot of incentive, as much as we'd love to.

But we are ... React is the project that I work on. Obviously, a React project. Having a navigation menu is something we've built a number of times, and we're rebuilding now. It's definitely something that needs to be codified in a way that can easily be created that has just really good developer experience, as we build pieces together that can be very performant, as we build a lot of controls that show up in just really critical path areas like, say, the Office Ribbon within Office Web.

This ribbon that gets rendered over and over and over again within really critical applications and has lots of controls in it. Look at Ribbon. It's just buttons and dropdowns and inputs and all sorts of stuff up there. There's lots of them, so having those be performant and have those things be themeable, have those things be virtualizable if there's too much content in it.

There's a lot that goes into making those controls work correctly. On top of that, making sure those controls are accessible for keyboard. Make sure they're accessible for things like Narrator or any voiceover technology. And then also make sure they work in high contrast mode and all the various high contrast modes and focus states and so forth.

Again, if we go back to my example in CodePen--

Chris: That's a lot. That's not a problem you want to solve over and over.

Micah: [Laughter]

Chris: You want to solve that once.

Micah: The only thing I solved in CodePen was, "Hey, look. You can do all this stuff with CSS hover states," or something. Everything else is broken. Everything else is horrible in that example. We've moved on to much more complicated problems now where, yes, we can do the interaction of a menu opening and closing with a mouse. We also need that same interaction with the keyboard and correctly with a keyboard.

We also need it with narration, with Narrator on Windows and so forth, and high contrast mode and so forth. It's a challenge. Then also to do it with various themes so that that menu can look correct when it's sitting inside of Teams, and the same control can look correct sitting inside of Outlook for Web because those are the same controls. It's the same code running the same React inside of the browser or inside of the electron application. They might have moved on now, but it's the exact same code.

It's exciting to see that, to see the same code be able to run in these different super powerful, super complex applications and know that we are contributing to those being consistent, to have the same keyboard and mouse interactions, to have the same accessibility model. And we know that as we push performance improvements out and bug fixes out that all those applications get benefit from that. That's amazing.

Chris: Yeah, that's huge. A little more surface area to screw up too. [Laughter]

Micah: Oh... [Laughter] More reason for good testing. And that was my big--

Chris: That's what I was going to say. Testing, I'm sure, is just massive with those things. You can't ship a bug to Word overnight.

Micah: [Laughter] I've never done that.

Chris: Are you crazy? Yeah. [Laughter]

00:27:18

Micah: That was my big push with front-end architecture. When I first started, it was this idea that, especially in the agency world, as a front-end developer, every single project we'd go into was this bespoke, like, "Okay, great. We're going to build more buttons and dropdowns and selects again and again and again and again."

Chris: Yeah.

Micah: Like every page has a new button, a new select because they're just completely random new DOM. We're just like, every single thing we do is new and bespoke and all our work is just done in replicating all those styles for each of the pages.

Wouldn't it be great if we could just stop having to build another page of buttons, another page of dropdowns, another page of selects? We could step back and go, "Hey, we've already built all the components. We need to build those pages. Now what can we focus on?" The answer is always better testing, better accessibility.

Chris: Mm-hmm.

Micah: Better theming. We can finally step back from the practice of just building out yet another page and actually do more architectural stuff, like building systems around it. For me, that was the exciting thing was being able to step back and go, like, "Okay. We built the basics. They're solid. They're good. Now how can we make the system even better?"

Chris: That's awesome. Yeah.

Micah: Mm-hmm. Fun.

Chris: It's kind of fun to look at some old Micah Pens, not only the popular ones, but it's more interesting almost to look at what did you do over time. You're one of the most consistent users I've ever seen - in a way. You were making Pens in 2012. It's 2022, by the way. And almost consistently do you make about -- it goes up and down a little bit -- 10, 15, 20 Pens a month. Never missing a month.

Micah: [Laughter]

Chris: You have -- ten years--

Micah: That's impressive.

Chris: Yeah, of making Pens every month. I feel like you're -- on this podcast, I talk to a lot of code artists and stuff that have these more emphatic waves that are really into this for a minute. They go, roar, and make a bunch of creative stuff around that, which I totally get. But I'm not quite -- I wish I was more like that, in a way.

Micah: Yeah.

Chris: But I'm more of a utilitarian, boots on the ground, solving little dumb problems kind of guy, maybe. That's what your account looks a lot like my account, I think.

00:29:39

Micah: Yeah. I've always seen -- Dribbble was out a bit before CodePen.

Chris: Yeah.

Micah: I saw CodePen come on. I was like, "Oh, this is kind of like a digital Dribbble kind of thing." You had the homepage and people doing lots of really amazing, awesome, cool things. Check out my latest, recent, cool, amazing, you know, doing the Mona Lisa with CSS and all those things.

Chris: Yeah.

Micah: Yeah, but for me, I started out with, again, it was some of those proof of concept. Can I take this UI, this picture I see?

I remember doing some buttons or some random UI I just saw a Photoshop doc of. I'm like, "Let me try and build that." It was just this great environment to be able to do that, quickly iterate, and go, "Oh, cool. I got pretty close to that picture over there. That's awesome."

Or, "Hey, can I build this navigation thing?" or "Can I do this JavaScript jQuery thing for building some equal height?"

Chris: Mm-hmm.

Micah: But then after that, it moved on. CodePen for me was really a scratchpad of solving problems. As I've been working within this design system for the last five and a half years now, CodePen had always been our go-to of, "Hey, we need a repro." This goes into how the sausage is made (a little bit), but we have a public, open GitHub repo with our design system.

Chris: Mm-hmm.

Micah: Which means anyone can log issues on our design system.

Chris: [Laughter]

Micah: We're also public. Anyone can see these issues that are being written.

We really try to tell application teams, like, "Hey, don't be posting some internal crazy prototype code kind of thing in there because this is public. Remember that."

Chris: Oh! Right.

Micah: Or don't be pointing to internal code. This is really an open-source thing. Try and treat it as that.

The other thing we try and push away from is we're not in the business to go and debug your application. We'll offer whatever advice we can, but it's not our job to write in, download all of your code, get our environment set up so we can run your app and debug what's going wrong.

Chris: I see. Yeah.

00:31:56

Micah: We're obviously just not staffed to do that. So, if you think there's a bug in our code, you need to prove to us there is a bug in our code. Saying that there is a bug in your app and it's around somewhere where our code is being used is not enough for us to go, "Okay. Well, do you know if the problem is in your code or our code?"

So many times it's, "Can you give us a reduced repro? Can you go and create a CodePen?" Here's the CodePen angle. "Can you create a CodePen using our controls that demonstrate the bug that you see?" because so many times they'll take all the code and drop it in. I'm like, "Well, that's not really reduced." There's a ton of other stuff going there. Start pulling stuff out and pulling stuff out until we're left just with our fluent code and the bug.

Oftentimes, they'll get down to that point where it's just the fluent code, and they're like, "Oh, the bug is gone. Wait, where did the bug go?" kind of thing. Like, "Oh, the bug was in this other code we wrote with some other thing that they're doing. That's where the bug is."

Getting down to that reduced repro has always been kind of our, I wouldn't say, lifeline, but it's been such a key part of us being able to triage bugs properly. We needed people to be able to break that down. Even then, walking through the debugging process of start stripping stuff away. Strip away, strip away, until you get down just to the bare essentials of this reproduction and see if you can figure out where the bug is. At that point, it makes it a lot easier to figure out what the problem is. We can also verify if we make this change in our code, will that fix the scenario. We have to make those connections.

For us, CodePen was a really great way to do that because it was public. It was easy to share. Our code was out unpackaged, so you could easily pull it in and get those components right in there.

Chris: That's kind of a clutch moment, though--

Micah: Yes.

Chris: --is the publicness of it that we don't really have a good internal solution. It's like you've kind of got to pass that step. Maybe someday.

00:34:06

Micah: Yeah, so we have an A.K.A., aka.ms is the Microsoft mini URL thing, and so if you do aka.ms/fluentpen, you will get a CodePen--

Chris: Nice!

Micah: --that is prepopulated with all of just the basic imports to be able to render our buttons, dropdowns, and so forth inside of CodePen.

Chris: Oh, yeah. That totally works. [Laughter]

Micah: Yeah, so many times we're like, "Come on. Just go there." If you can reproduce the bug in that, put that in the GitHub issue, and then we can go to work figuring out what's wrong and come up with a solution for you.

If you can't get it in there while stripping away all the other stuff, then we can't be confident the problem is actually in our code and it's hard for us to make a move forward because we don't even always have access to the code they're working in. It's a huge part, a critical part of us being able to do our work as maintainers.

Chris: Yeah, I suppose. I'm sure you get terrible issues sometimes, some low-res screenshot that's just like, "Well, what am I going to do with that?"

Micah: [Laughter] Yeah. Or "Here's a screenshot of our app. It's not working. What's wrong?" I'm like, "I don't know." [Laughter]

Chris: Yeah. It's almost like an emotional thing. I get it. Believe me. Please, preach on about reduced test cases. That's so crucial and vital not only for big open-source maintainers. Not for Microsoft. For anybody. Students, it's useful for.

Micah: Mm-hmm.

Chris: The exercise of making a stripped-down use case is incredible. Oftentimes, it's a tool for solving your own problem because you'll discover what the thing is, let alone--

And then if you can't, getting help is great. It's required for logging the issue. It's just great from all angles.

00:35:52

Micah: And it's also a skill you learn over time. I think, as a front-end developer, that was always my go-to was, like, "Let me reduce this down."

I was having a CSS bug recently, and I still don't really understand it. But it was something where some code, some UI was overflowing the screen.

Chris: Wow. I already knew what you were going to say. I'm like, it's probably a min-content issue. It's always something.

Micah: Oh, it ended up being a Flexbox. It was a flex item in a flex container, and I knew the content lower down was kind of big and wide because there were some demos in our storybook. But I didn't see why I had--

Chris: Flex wrap or something.

Micah: I didn't tell it to flow. No, it wasn't a wrap. The solution ended up being putting an actual width on it. Flex basis wouldn't do it.

Chris: Yeah.

Micah: A width actually did it. I don't even know why. I have no idea why a width in flex-basis didn't. Someone tell me. Maybe it's a browser bug. I don't know.

Chris: I think, yeah. That's what I was going to say. I don't know how--

Micah: It's that reduced use case.

Chris: ...min-content. Yeah, but I think flex-basis says this is where I want to start, but width gives it an intrinsic value.

Micah: Width inside of Flexbox still allows it to grow. Flex grow is still on that.

Chris: know. I know. It does.