Chris Coyier: The Long Game of Maintaining CodePen

Speaker A: Foreign. Welcome to Maintainable, the podcast where we explore the art and sometimes the mess of software that lasts. I talk with seasoned practitioners who spent years navigating technical debt, untangling legacy systems, and helping teams build software that can survive change. Because good software isn't just about shipping fast, it's about making it last. I'm your host, Robbie Russell. On this episode, I'm joined by Chris Coyer, co founder of Codepen, a platform that's been evolving for over 15 years and is currently navigating a long running trans into its next chapter. Chris joins us from Bend, Oregon in the United States. Chris Coyer, welcome to Maintainable.

Speaker B: Thanks for having me, Robby. My pleasure.

Speaker A: So, Chris, I have to ask, given your experience in the industry, what do you believe are a few common characteristics of, dare I say, well, maintained software?

Speaker B: Oh my gosh, right off the bat you're into it, man. Here we go. I was thinking about, I mean, of course I am. You know, you have this podcast on your calendar. You can't help but think about the main topic at hand here. And you know, I am interested. I would almost like to see data on like all the guests you've asked that question to. Like, how many people give a very, like, straight up technical sling? I love that. I want to like, know lots of stuff about like, technical ways to make it software, but I really feel like what it is is a human being who, who cares, who is incentivized and has the resources to maintain that software. Maybe like 90% of it. If you had garbage software that just ancient code full of bugs or all that, and you really needed to like, fix. You needed to maintain it, you needed to like keep it going, grease the wheels, whatever. More than fingers on the keyboard, you need a person, you know, who's like, like, wants to maintain it, that it's like mostly a, uh, people problem and like less so a code problem.

Speaker A: If you were to go in and do you feel like you can assess that by just looking at, say a. If you could just. Someone just sent you a link to a private GitHub repository, do you feel like you could. There'd be any indicators that would make it kind of allude to that?

Speaker B: Good question. Like, maybe that's what the green dots are for because they get made fun of a lot, you know, like mostly, you know, uh, you know what I'm talking about is the like light green, dark green grid of dots on GitHub that show commits over the course of a day, a week, a month, a year. And that kind of thing. I do think there is something it's easy to make fun of and be like, hey look, the carpet at this airport looks like GitHub or whatever. But I think the point of that is like if you see this sporadically light green spread on GitHub, you can be like, look, they care on an almost day to day basis about this piece of software. Um, that's like decent. I wouldn't, I'm like careful about commits because that can be like dangerous territory when you evaluate someone's performance based on like how many commits they're doing. That's like not great territory. But uh, you know, depending on the. If it's like an open source piece of software that's been like lightly worked on for five years, I mean, geez, that's great.

Speaker A: You know, in preparing for the conversation and maybe actually provide a little bit of context for our listeners that might not be familiar with codepen. Could you. How would you describe what codepen is today?

Speaker B: Sure, yeah, it hasn't changed like dramatically from the early days, but it's very front end focused. And I think what people mostly have in their brain of what codepen is, is like these three boxes are kind of four. It's HTML, CSS and JavaScript and you write them and then the fourth box is what they all smash into. You know, it, it combines those things into a complete document which may require some steps, you know, not just combining them and you know, but, but also like you know, processing your sass down into CSS or whatever. Then it makes a document and it shows you in the iframe. And the ideal is that, you know, it's kind of like a stop typing situation. You like write a little code and you stop and then it's like, oh, okay, let me get that together for you in the iframe, ideally as fast as possible. And the point is like a speediness from I'm thinking about this and I need to get it out of my brain onto a, uh, seeing the result of it. But avoid like making a new folder in your computer and opening that up in an IDE and then making files individually and then spinning up a dev server and then being like, oh, but I'm, I prefer writing in SaaS, so I need to npm install that and make sure there's a little bundler or something. Those are kind of like steps that are in the way of you getting an idea out of your head. But people use CodePen for more than just like that. Some people use it as almost like their art Portfolio like they just make art and they could do it anywhere. But a reason you might do it on codepen is because there's like this social network ness of it that we. I try not to make it too much like a, like a game or whatever, but it's, it has the hallmarks of some social media stuff that exists in that space because it has views and hearts and comments and, and then you land on codepen and you're seeing a feed of other people's pens that are that. So it has, it has these like social network qualities. If you make some of your art, perhaps if that's what you're building on codepen, that you get some of these kind of vanity metrics with it and that can just be appealing. And the bigger the network, the bigger those numbers are. Not that our numbers are that big. They're not that big, but they're. But it's, it can be satisfying to like get some hearts and stuff on the thing that you build. Some people do it for that. There's a lot of prototyping, a little component to show to somebody at work. So they do that and then they keep it private because nobody needs to see that and they share it. There's some real time stuff built in, so we see it used for interviewing. You know, like, build this little component and let me like kind of watch you as you do it. And so my elevator pitch has always been a little weird on it because like there's like 20 reasons you could use it, which is tricky, you know.

Speaker A: While preparing for the conversation, I was trying to think back to like what was like your earliest memories that I had because I didn't personally use it a lot, but I got shared a lot of links from like employees when they're like. And I was like, oh, I found a bunch of links in like Slack and, and things where they were experimenting with it themselves on mostly from like our front end. More front end focus when they were trying to experiment with something like, oh, I think maybe something like this or like, look what this cool thing I did and to kind of show off or like, look what some cool thing that somebody else did with it. And I thought it was things like that. And so I was always a little bit more on the back end side of things. Do you identify as a front end developer?

Speaker B: I do still. I probably always will. I don't know, maybe it was just my formative years spent in that way. I spent a lot of time like thinking and writing about the front end. Although I'll say I write, I probably write more backend code these days. And then, you know, JavaScript is weird because, like, what is it? It's both kind of, you know, when

Speaker A: you first set out to build it, what problems were you. What was the initial problems that you were trying to solve?

Speaker B: Oh, for sure. I mean, that one was. Is. Is kind of easy because it was. And this is way back. Like codepen's old. It's like 15 years old or something, you know, maybe longer now. I, uh, a blog I owned and ran also for 15 years, it's a little older than codepen called CSS tricks, which still exists to this day. You know, the team's running it, it's owned by DigitalOcean now. They're doing a good job keeping it going. But it was just me in the early days for the most part. And I have guest authors and stuff. But all those early posts, I was trying to show off literally HTML and css. Like I just want to show you stuff, you know, and the name is a little cheesy, but there was plenty of literal CSS tricks on CSS tricks, you know, and I was trying to show you how to do that. And you can, you know, write a pre tag and escape your code and display a chunk of HTML and a chunk of CSS in a blog post. That's, you know, plenty people do it every day. That's like a common way to do it, but it's not nearly as satisfying as seeing those chunks of code and then what they produce also, that's way more satisfying. And I never really solved that in the early days of CSS tricks. I'd show you the code and then I'd have like a link that would say View Demo, you know, and I'd put class equals button on it and whatever. You clicked View Demo. And even this was before anything in the codepen kind of market because there's plenty of other apps like JSFIL and jsbin and whatever, they all have some of those predate codepen itself. Those were kind of cool.

Speaker A: But I.

Speaker B: Not that I helped the situation, but I felt a little weird linking to a third party platform for something that was so fundamental to what I was doing. Like, oh no, what if it goes away? I'll be up shit creek, you know, So I, what I did was I just.

Speaker A: Which happens with the Internet.

Speaker B: Yeah, it happens. It happens.

Speaker A: Although things disappear. Like web apps and websites go. And like, it's great that we have the Internet Archive for things like that, but it doesn't always render HTML CSS properly, right?

Speaker B: Especially something that had a backend component like those things do. If I had known what I know now, then maybe I would have never done it though. Because if you're a codepen competitor, you never die. None of them have ever stopped working. They just live forever. Well, that's fine. I just feel like it's funny, you know, Sometimes you feel like, God, if you laugh, if you last 15 years, maybe you're the last man standing. But nope. Anyway, I would link to a PHP file that had the HTML and CSS in it. Used PHP because I needed includes because I wanted to have a branded header and a branded footer. So every demo had like include header php or whatever the top of it. And then, you know, it was just on you to view source if you needed to. I mean, the blog post had the code in it, but the demo was just the demo that still exists. There's just an examples directory if you like, FTP into the CSS Trix web server. There's, you know, hundreds and hundreds of these demos all in a folder. And I was like, it was okay for a number of years, but Once apps like JSFiddle and JSbin were on the scene, I was like, oh, it's so much nicer to just see it all at once. But they didn't really have an embed, you know, like a, you know, like a YouTube embed or whatever. But like, m a way to. My dream was like, you're looking at the code on the left and the iframe on the right and I can put that right in a blog post and it'll make the blog post so much more compelling. I wanted that so bad. The, uh, early days of Codepen were just to do that. We had that feature kind of from day one. I was like, you go, but. But then, like, what's the app where you build it was separate from the code that you get to embed it. So then we started working on the code to build it and I was like, should it just be like an open source thing? You know, you run it yourself on your own server. That was what it was to begin with. But then we're like, oh, it's. I think we were just dumber then, like, because. Because we had stuff. How do you do auth and open source it? I don't know. You know, I'm sure, like, that's a little ansier, a little more answered now. But I was like, do people want like our auth strategy? Exactly. And what if we start taking Payments. Do we ship our billing code in an open source repo? That seems weird. And then the architecture started being like, well, you know, we have these Rails servers that serve the main app. But then we have, you know, eventually we had like Lambdas for Pro doing the code processing and all this. And it was like. To open source it was like, okay, just spin up these eight servers. And it started feeling like nobody's, nobody's going to do this. You know, like it's hard enough for us to get one implementation going that it felt, uh, we like didn't know how to open source it well, so we just didn't. And we said instead of having it be this thing that would run at like CSS tricks.com demos or some crap like that, we'll just call, we'll just name it, we'll buy a URL for it, we'll run it there. And that's what we did. And to this day, if you go to like JSFiddle or something, you just, you just land right on the editor and we're like, we're going to not do that. We're going to have. That was an early decision to be like, that's. You click a link and you go to that. But the homepage. Then we have this opportunity to have a landing page when you're logged out that explains what the app is. Then when you're logged in, it can be this like, what's the coolest stuff that people built on this app today? That was like an early choice to be like, because we built like an admin dashboard that's like, okay, people are logging in and building stuff. What are they building? I want to look. So we would look and then we would start. We built this little system with a little like ASCII star and you could click the star and then it would put it into a, uh, just mark it as picked equals TR in the database. And the feed would just be the latest ones that were picked equals true. And you could paginate through them to see all the cool ones. They were just handpicked here we still do it. That little ASCII star is still in there. Still does that. Although it now it just kind of like informs a ML, uh, model kind of thing that factors that into many other factors and stuff. But yeah, that, I mean that was the early days. And then we made the embeds and they worked. You know, you get a little iframe and you can put the iframe in a blog post or documentation or whatever. And then from Then on out, I didn't post a single blog post that didn't basically have a Codepen embed in it. And to this day, it's about. It's probably about 50% of all the traffic to Codepen is us serving an embed.

Speaker A: Let's take a moment. For the teams running Ruby apps, if your Test coverage says 90%, there's a decent chance it's lying to you. Because coverage doesn't tell you what you didn't test, uh, in your last pull request, it just tells you a story about the past. That's where Undercover CI comes in. It looks at your pull request and shows you exactly what changed and which parts of that change weren't tested down to the method level. And honestly, this becomes even more important than if your team is using AI coding tools, because AI can help your teams move faster, but can also generate code that looks finished long before it's actually well tested. Several Undercover CI customers have apparently been seeing this firsthand, especially with AI generated pull requests that skip over edge cases or only partially cover the changes being introduced. So instead of chasing a percentage, you're answering a better question. Did we actually test what we just merged? For teams maintaining Long Live Ruby apps, this hits a nerve. You don't need another dashboard. You need to see the gaps while the code is still fresh during review before they turn into bugs a week later. If that sounds familiar, it's worth a look. Head over to undercover CI.com it's free for public repos. Private repos start at $69 a month per GitHub organization. And they set up a code for our listeners. Use maintainable 15% off your first billing cycle. Run it on your next PR and see what your coverage report didn't tell you. Out of curiosity, from a monetary perspective, I would assume by you having like someone embedding an iframe and having like a widget that you would load in your. In their own personal blog. That is going to be infrastructure costs to your company to. To codepen. Right. So how is.

Speaker B: How did we afford it? Yeah, I don't know.

Speaker A: Yeah, how did you afford all that to. To make that work?

Speaker B: I don't think we thought about it. We just rolled with it. You know, I don't know how we afforded it. It was not cheap even early on, but I don't know, it probably wasn't too bad. Like, we think that's like kind of a good problem to have and it kind of still is. Like, if your site is so popular that your hosting cost Goes up. Okay. A lot of businesses would beg for that. Dude. You getting eyeballs and traffic and people visiting your site, you did it. That's the hard part. So if you can't monetize that, then, dang, bummer. Basically, you screwed up.

Speaker A: You know, approximately how many engineers have worked on the back end and the front end of your application itself over the years?

Speaker B: Over the years. Fifteen, maybe.

Speaker A: Actively these days, just for some context before we get into some of these other topics.

Speaker B: Yeah, we're only six right now. Just. We trimmed down again and, uh, we could certainly be bigger than we are. But there's, you know, I don't even know how to talk about that. It's almost like I could hire somebody today, but it's this big roll of the D, whether it's going to be like a good fit or not or how that's going to go. And we've had a couple that didn't work out super good. And the cost of that in a small business can feel so high and feel like, oh, I just don't have the energy to go through that again. And we're okay. We're not so backlogged that we can't possibly operate leaner. So we just operate leaner at the moment.

Speaker A: I'm curious, do you and your team use the metaphor technical debt very often in your day to day work?

Speaker B: We do. I often wonder if we use it correctly or I use it correctly, other people use it correctly. I almost want to turn it back on you. Do you have a really clear definition of what you think it is?

Speaker A: No, I don't. That's why I like to ask this question, because I think for our listeners, it's just that everybody has. I mean, some people might go back and be like, well, Michael Feathers said in this one book, or when Ward Cunningham defined the term, he meant it this way. And I'm like, well, that's not necessarily how the, uh, you know, everybody refers to it. Some people might refer to it as like, well, it's just code. I disagree with, you know.

Speaker B: Sure. It's just, it's like, yeah, what is it? You know, I do think that whether you're using it perfectly or not, it generally means I'm either paying for this right now or need to pay for it. Not forever in the future, like probably sooner than later. I need to pay for this. And pay for it doesn't mean like dollar bills. It means probably in my time and emotion about this. Yeah, that you made a choice either intentionally because you believe in the premature Optimization as the root of all evil or something. So you intentionally ship some code that wasn't optimized, knowing that you're like, I'm going to pay for that soon. I'm going to go back and make that faster. So that's like a one like pretty clear version of technical debt. Or you could see like, you know, we had our Rails app. Oh, um, I think we used something before Rails. Rails was like step two for us, but we still have that and it was pretty much 15 years ago when Rails went in. And at the moment we're like, no, no, hate on Rails, but we are moving off of it. And you could consider Rails just technical debt for us because it's the thing that's on the way out is that technical debt then I guess is our code that's not typescript yet. Technical debt, I guess.

Speaker A: What is the rationale for migrating? I say that as someone that comes from the Ruby on Rails world. So out of curiosity, tell me more about that decision or is it the architectural thing or how is your team thinking about that?

Speaker B: It's speed. It's like how much servers can straight up handle load. And if we have a site that's like a light JavaScript front end that communicates with a uh, go backend that coughs up the data, it's a hundred x lighter than Rails or something like that. And that turns into actual money for us because like you know, when the whole app is Rails, if the whole app was Rails right now, every single page was served in that way. We have to like horizontally scale that up on AWS to make sure that there's enough servers being load balanced and stuff. And those servers are more memory and CPU intensive and just cost more money. And then we'd have to, you know, we'd like, we have to write scripts and stuff. Sometimes we're like, okay, well we have to migrate this column to some other column. If you were to write that in Ruby, it'll be like, okay, well it's going to take like a week to run that. Whereas we can write a Go script to do it in the database and it runs 12 minutes or something. There's things that are like really orders of magnitude much, much faster. And so it was my, my CTO made the decision is like, I like this language Go, and I think you all can learn it. Everybody knows JavaScript, uh, codepen, it's more the same but it's like it's not a particularly difficult language to pick up because it has that like typescript, like quality of like every, every freaking thing you hover over, you can click and it will tell you what it is and what it's doing.

Speaker A: If I recall, I think you're using GraphQL as part of this is the API.

Speaker B: We are and that's good benefit for us too. We, we were using GraphQL in rails too though we have some Rails jammed. We've been GraphQL for a long time and I don't know why it stopped being cool because I, I still think it's cool. I'm a big fan of that approach but I really like our Go GraphQL API. It's very easy to reason about for us and add auth to and it has a structure to it that I appreciate. I feel like as a Rails guy you probably appreciate the structure of I don't know, there's a routes file and the routes point to the controller and then you look at the controller and then whatever the logic is in certain places and you have nice little services and it's not that different from app to app. I think Go did not impart that structure. It doesn't impart any structure really but you can and at one point we're like we're going to be really structured particularly with this API of there's a resolver and the resolver has no logic in it. If there's any business logic it has to go to the logic file and logic file never touches the database directly. It touches the files that are in the data folder. And so we imparted this really strict logic that there's like no breaches to our, our choices that it feels like very easy to reason about And I

Speaker A: like so is it safe to assume that your CTO there or your team then had to kind of define, kind of pull together what your own conventions or that that structure would look like. And so. So how do you think about that long term as a business owners thinking about that like from a recruitment long term maintenance perspective of being like well we have our way of doing things. This is our current opinion on how to do this. I would say the argument for something like rather we can get an argument about the uh, performance benefits of Ruby on Rails or other insert other framework but to kind of come up with your own framework approach is not be able to do that.

Speaker B: Right. There might be some cost that it's too bespoke but nobody knows what we do. Uh and you can't even prove it during interviewing really because you're just, you know there's so many aspects to That. I think that is a good point. If you're hiring somebody and you're like they're demonstrably knowledgeable about next JS or something, you can, they can, they'll just be useful immediately because you have that too. And it imparts these conventions that kind of can't be broken and it's React. And React is already pretty opinionated and blah, blah. I don't, I don't lose any sleep over it. Uh, I guess that might be true a little bit. But I think there is this. Maybe I'm not smart enough to speak about it exactly because. But like Go you. Like I said, you can hover over anything. There is no doubt as to following a logical thread about how code is working in Go all the way down to the language of Go itself. You can click down and see what a native implementation of a For loop is or whatever. Every single thing you can click. I feel like you can set up VS code to be like decent in Ruby about that, but mine is currently broken or something. I feel like I can't click anything in my Rails apparently. Um, it's all magic to me all the time. Rails is already kind of magical and I don't have my thing set up or if I click on it it'll like take me to the next logical place to take me. And it makes me salty about our, our Ruby code.

Speaker A: Okay. I mean that could have been an address with maybe some pair programming with, with, with me, but we could uh, we can figure that out. I also think it's interesting, um, it'd be interesting to hear how that, how far into that migration are you at this point?

Speaker B: Oh, ah, good question. Maybe 75 or something. It's pretty far. Anything new gets created in that way over into the new stack, but there's just some old legacy technical debt if you will, that is in that old world. And it's fine, it's like not urgent to switch anything over. It's just kind of a long term mandate to be like, yeah, let's port that over. You know. And it uh, just feels a little good when we do. And you can log into the AWS console and look at charts and stuff in these, these very few Go servers we have that just barely 2% CPU usage, you know, just, just barely breaking a sweat. Even though it's doing, it's serving just a ton of users, you know, it's just nice to see and it's. Yeah. So you know, no shade on Ruby or whatever. Um, it's, it's, it's served us well for a long time and probably will for a long time. You uh, know, once in a while I'll bring up, I bring up like, ah, that'll be nice when we pull out this piece of the app or whatever. To have some of our long term employees be like, like that's never gonna happen.

Speaker A: Might just have to coexist a little bit there.

Speaker B: Yeah.

Speaker A: I'm curious, you know you have kind of like this massive API. Do you recall how you thought about where do you pick things to start migrating first, regardless of the tech stack? But like how do you prioritize things like that?

Speaker B: That was a, that's a great question. We had this goal when we made the new API because it's, it's a lot of surface area and to this day it is, it is not done. Those two APIs maybe 75% overlap there too. Of do these APIs return because they had to be exactly the same. All the queries and mutations are named exactly the same. They return data in the exact same format. They are typed exactly the same. They need to be the same. And we had this mandate like even if it's not like you don't love it in the Rails app, how it was implemented, you would make different choices now don't do it yet. Don't do it. It just, just one to one it how it used to be. And I would be terrible at that because I'm, I'm really bad at like oh, we'll just do it this better way. And then it' incompatible because you might have a page that may or hit one and not the other or whatever. So employees did the right thing and being like do not touch the behavior. But we had this goal, we just picked one page that was served by Rails and we wanted to make sure it was served in our new framework, uh, by the new API. And it was so low stakes. It was the about page so codepen IO about and it was kind of like a static page, but not quite because there's kind of like an application frame around it. So you have this header and the header you're either logged in or you're not. And so it had to do that. And then there's certain things you could click and there was certain. There's even like a uh, in the dropdown menu that would have your profile and the logout link and all this a menu, there'd be a line that said upgrade to Pro. Well, shit, now it needs to know if you're pro or not. And ideally when you click Upgrade to Pro it, open up a modal and it would allow you to upgrade. So really, while you're doing the about page, we had to make every one of those APIs work.

Speaker A: Worked.

Speaker B: And if we get every single thing that you can do on the about page done and we can render that page in this new framework, then we can, I don't know, put one little feather in our hat and say, okay, that page works now. Now let's do the next page. The next page should be a little easier and the next page will be a little easier after that. And yada yada. There was some introspection stuff done too, though. That was like, can we. GraphQL has like a. I think people turn it off on Prod, but there's like some endpoint that you can hit that's like, here's everything that's a part of this, this graphQLPA. And so you could hit both APIs and get it and then kind of like diff them and be like, here's the red, here's what's not implemented in one.

Speaker A: Is the API primarily to serve those like embeds? Or are you taking a lot of any writes from users? Is like, are they writing anything into your database via your API, or is it primarily for like.

Speaker B: Not via like, like a traditional API? Like we just. You hit write, um, not none, but low. There's plenty of write APIs because you know, if you heart something or leave a comment or mostly you're on pens. Those are all write APIs, but those are internal. They're not. You can't like force a pen, save from an API. We don't have that yet. Of course, we've wanted it forever and plan on releasing it, but it's kind of like we want to make sure the GraphQL API is like done and then you have to think of this like, new kind of new AUTH layer that's the world now and not your own app. So like, how are you doing? And is it tokens or what? And it's all ready for that. We built a really nice AUTH system internally that we're very happy with, but we just haven't taken that final step of like giving it to the world.

Speaker A: Is that primarily like you're using React then on the front end and then so the REACT is consuming that, that GraphQL and so to render all the widgets and, or what have you and. And then people can type things.

Speaker B: Exactly. And it uses Apollo too, at a relatively heavily heavy GraphQL library. But it, it handles like caching, which is a big deal with GraphQL. And it, it does all the efficient stuff too. Like there might be, I don't know, 150 components on a page, and each one of them, like the spirit of writing that component is like if that component needs data, it's got its own little GraphQL query that asks for it. But that might mean that 35 of those components ask if the user is pro or not, like on a paid tier. And you would never make 35 HTTP calls to ask for that information. And Apollo is like the technology that looks at all the queries that all the components need on a page and kind of like normalizes them or whatever. So it's only ever asked once. That's what that caching layer is all about, is like it asks once and then all the rest of the components ask the cache, which you don't even really see happening. It just works somehow.

Speaker A: I'm not that familiar with Apollo. I've heard it referenced a couple times recently and I have to check that out.

Speaker B: Sometimes people reference it in a why would you ever do that to yourself? Kind of way, but I don't feel that way. I think it's kind of nice. It also, uh, it has little like bonus things for react. Like it has these reactive variables which is, is like, I think in the same kind of spirit as signals, um, which is all, all hot in JavaScript land.

Speaker A: Hey listeners, it's Robby here. You know, it wasn't all that long ago I'd find myself debugging a weird issue in one of our clients Rails app. I log into one platform to track down the error, only to realize it was tied to some performance issue. And guess what? That meant hopping over into a completely different tool and trying to match things up based off of timestamps. If I was lucky. And let me tell you, my productivity didn't exactly thank me for that. Enter app Signal, our podcast sponsor and the tool that eliminates all that back and forth. They bring error tracking, performance monitoring, host metrics, custom metrics, uptime monitoring, and logging into one seamless platform. It's a single source of truth that helps keep your app running like a well rehearsed symphony. Whether you're working with Ruby, Elixir, uh, Node, Python, or tracking front end errors in JavaScript, AppSignal has your back. They're always adding support for more languages and frameworks too. And here's the best part. AppSignal won't break the bank. Plans start at just $23 US a month. Plus they're ISO 27001 certified and fully GDPR and HIPAA compliant, so your data is safe. Oh, and because you're a loyal maintainable listener, you can use the promo code maintainable at checkout for 10% off your first year. So head over to appsignal.com, tell them that your good friend Robby from Maintainable sent ya and start making your app. See. You know, I know you've mentioned also the idea of like letting the browser do what it's good at, particularly when it comes to things like focusing on accessibility and performance. So where do you see teams tend to overcomplicate things?

Speaker B: Today I saw a good blog post that I could relate to that was kind of crapping on the SHAD cn. I'm sure you've heard of that, right? It's these little like, they're like components that you NPM install and then rather than it being a dependency, it just barfs all the files out into your system. So they're just version controlled and everything. It's a nice system I think and it has a little bit of that like bootstrap like quality from back in the day. Like oh, every site just looks like the same because they use these Shad CN components or whatever, but they're really nice, right? But this particular blog post was about the checkbox element which in HTML is input type equals checked and now you have a checkbox, it's one line and that's it. And the shadcn component is like enormous, you know, an enormous amount of files that depend on other files and has dependencies and all this stuff. And it was like, what are we doing team? That is a one liner baby. You don't need that. And I'm sure it's got its reasons and all that, but I do, I try to think in that way, does this thing need to be that complicated or can we write input type equals checkbox and we're definitely like an input type equals checkbox kind of company.

Speaker A: You know, you've been around the industry in the front end world, I mean long enough to see that sometimes given that even the CSS Tricks website, like there's things that you, you needed tricks back in the day to do things that are now probably first class citizens of the browsers. You know, there's that you can browsers do improve or get new uh, features added over time and then can you recall any scenarios where you're like, oh, now that this was available in browsers, we can now remove A bunch of complexity from our style sheets or something.

Speaker B: Yeah. And I mean it happens. The more satisfying ones are when you can remove JavaScript to do a particular job. One that's that we're like kind of halfway through at, at the moment. I don't, I think it's used here and there on CodePembo. I don't think we've ported all our components to it yet. Is the um, the anchor positioning stuff in css which is like you can take an element and say hey, go position yourself next to this other element. And there's some caveats to think about but for the most part it's pretty powerful. That was forever the job of JavaScript. It would go look at the other element. It would perform geometry and math calculations to see where the other element might fit. It had to do this stuff called edge detection to make sure that you weren't doing something stupid like hanging it off the right side of the page when there's not enough room over there and possibly causing a horizontal scroll bar and stuff. That type of stuff is now I think, I think the anchor positioning API in CSS is what they consider baseline now or whatever. It's like it's implemented in all the browsers so you can get. And the libraries to do that kind of work were sometimes not particularly small. I don't think they were like hundreds of kilobytes, but they were probably dozens of kilobytes sometimes. And to be able to just yank that and just be. And express that, uh, the expression of it I think is just as important as like the performance weight is that you're like writing it in the language that makes sense. In the same place that says I want you to be 2, 250 pixels wide. You're also saying also go attach to this element and hang off the left if you can, but hang off to the right if you must and hang off the top if you can, but hang off the bottom if you can't. That those are the same types of things you're trying to say and putting them in the same language feels good to me.

Speaker A: I can see how that can be advantageous. Again, I'm not a front end developer, so I don't particularly have a lot of experience with that, but that I know people on my team do. Out of curiosity, with your something like a codepen, I'm imagining that how often are people inter. What's your mobile usage like look like these days? Is there. My assumption would be that a lot of people are probably viewing maybe a Blog post that has some embeds or something like that on their mobile device because they're maybe scrolling on their phone or what have you. But then are people tending to like log in and do a lot of work on their mobile devices or is that.

Speaker B: It seems like it. It seems like people comment about it more than I think they would in that, you know, I'll get some kudos because we've TR to handle it. Well, I don't know. I lived through the responsive web design days. Like I care very much that a website renders and looks and behaves well on a small device. Even though there's some logical part of me that seems like, why are we doing this so much on the editor part of codepen, maybe the browsing part we can put a lot of time into. In fact, I just, I should, I forgot to post about this and get my kudos or whatever I find after all these years, I put in a swipe gesture on our, you know, our feeds are kind of, are kind of like horizontal line code pen. And uh, now you can, you can go to the, the feeds and just swipe with your finger, which is. So I probably should have did that five years ago or more. You know, that part makes sense to me to optimize for mobile because maybe you're, maybe you're just chilling on the couch and you want to just look at some cool art that people made on codepen or games or whatever else, because you just, you're a front end nerd and you geek out on stuff like that. But the editor, it's kind of like, is anybody truly, actually honestly real question here coding on their phone, are they? Because you could, I could kind of see that the answer is no, that you're not really, you're not real, honestly, honest to God, doing work on your phone. But I feel like that's dangerous to say that. Part of my brain wants me to say that and like, just be like, I don't care about our mobile experience. You know, one way you can handle this to this day, this works on the web. Don't put that freaking meta tag in your HTML that says initial width, device width or whatever. There's some meta tag that makes it kind of the width of the page, be the 420 pixels or whatever it is of your phone. If you just put that, at least I'm pretty sure on Android and Chrome, it just zooms out the whole page. It looks like your desktop website on your phone and then you gotta pinch and zoom into it. I feel like Nobody does that. But it's not totally off bounds. I was like, maybe that's the solution for our editor, is we just have the zoomed out look and then you zoom and pan around to use the app. That would take zero seconds of dev time. It would cost us zero dollars to do that. But we didn't. Instead we made it totally responsive and everything shrinks and we just did all the work to make sure it's responsive instead. And like I said, I think a lot more people that I think of are like, thank you for making this work really well. And we get bug reports. The new beta. We have CodePen 2.0, which I don't have to dig too much into. There's a. We upgraded the editor that we're using because we didn't hand write the, like the code editor part of that. That's an open source library called codemirror that we use. It's really nice, is much nicer on mobile now. And people are like, ooh, you know, good to go. But for example, it uses some virtualization technique or something. Let's say you have like a megabyte of text and it's in this editor. It doesn't render and syntax highlight the whole megabyte of it. It renders the viewport plus another 50% maybe. And so. But. But okay, yeah, it is. And it's performant and nice. But for Some reason on iOS, if you like, you know, you hold down and then you get the little handles with the little dots on them and you can drag to select text or. Which I think is. It's fine. Like I don't have any better idea for selecting text on a touch screen. But for coding is a little rough, you know. But there's a option that pops up above that and you could say select all and it will select all the text. Somehow you need to deal with that in JavaScript because you're not actually rendering at all. So if you don't deal with that, you're just gonna get the viewport plus 150% but not the full text. Somehow they deal with it on iOS. But we have an open bug report right now that Chrome on Android, it just selects the. That 150% of the viewport and delete and then you hit delete and then you see the rest of the document that you didn't select all. So it's like. But you look at a bug report like that sitting in your. In your to do list and you're like, ugh. You know, like, it's going to be a monkey patch to the library or we need to talk to the open source library and make a reduced test case and make sure they agree with it and that it's reproducible and then maybe they'll fix that, input a patch out. But that doesn't help our user and how important is it to that user? And then like, let's say people like that we have mobile, are they, you know, just to be all, ah, capitalist about it, I guess. Are they paying you? Does it actually matter to the business of your business if we actually fix this bug or not? Because it may not. It might be like, oh, people like the editor, neat, but there's zero percent of your paying customers or something. I don't know that data, so I'm not making decisions on it right now. But it, it does kind of matter.

Speaker A: You know, I'm always curious about like tooling and how far some orgs will go down the, say, the rabbit hole of how much they're going to cater to very, very small number of potential users. At least our perception of. I'm like, who's really doing that? In the same way, like, there's certain tasks that we probably all rack our head over. Like if someone sends me a link, do something on my. And I'm on my phone, I'm m. Like, this is not a phone activity. And like they're booking trips multiple countries on their phone. And I'm like, I can't. I need to go to my laptop and look at this stuff in a browser. I need to, I need tabs.

Speaker B: But is that because we're. We've crossed the 40 barrier or something?

Speaker A: I don't know how old, maybe I'm a couple years away from 50. But yeah, I think it might be a little bit of that. But then I'm just like, I don't know how people.

Speaker B: What about the like. But what if Amazon back in the day said, oh, nobody's gonna buy a rug on their phone. They made the wrong choice, then they didn't. But there was a time in history where you could have thought that and done that in your brain and you would have been wrong.

Speaker A: You would have been wrong. But editing, maybe editing some code on there. I mean, I guess there have been a couple times I've used the GitHub editor to fix some text, but I haven't made any huge syntax code changes to my projects and sent a pull request to get merged for production.

Speaker B: Yeah, but uh, if I was GitHub, I would put a lot of thought and time and effort into this. When you are six people like us, it's surprising to me that we did.

Speaker A: No, I can appreciate it that, you know, you think about, you know, as, as you're, you're prioritizing the types of projects that your, your team is focused on catering towards evolving the platform versus just maintaining a day to day. How does your team currently. Do you separate? Do you have people that are kind of focused on just responding to things that are going on? Do you have like a, with a smaller six person team like that?

Speaker B: I see what you're saying. That was uh, you know, that's a wonderful question. Because it's evolving. Well, no, I mean, yeah, yeah, but I just, I want to know how everybody in the world answers it too. Like it's interesting. I want to know. Like I can tell you what I do, but I'm fascinated by what other people do also. There was a time where we're like, we really need to start work on our, the next evolution of what this app can do because we can't just sit around forever. No software can and do nothing and hope that you get to have a business for the rest of your life. You have to evolve it. And that's, that was, I don't know, five, seven years ago. But we're trying to balance. Like this app needs work now though. We can't just abandon the work we're doing now. We could, I guess, but that has costs too in that, you know, leaving buggy software around. Maybe by the time your evolution of your product comes out, you've already pissed off everybody that could be your customer. You know, they've formed their opinion about how you produce buggy software. So why would we give you a second shot or something? And we kind of didn't make that choice. There was a very long period where we'. This, there's a lot of bugs going on here. We're gonna spend a long time just maintaining the crap out of this software. Just fix every single thing that we can fix, pay down as much technical debt, whatever that means, as we possibly can. And we did that for a very long time. And it was really at the cost of not working on, um, an evolution of the product. And we had to very intentionally slowly tilt the scale towards like, okay, that's good enough now. Now the opportunity cost is, is we need to be working on the evolution of the product and the other stuff is going to have to sit because we did what we said we're going to do and we really couldn't measure it. We could measure to the point where like. And this is. Feels like braggadocious to say or something, but at the, at the time where we went on this long bender of just fixing the product, we were down to like almost getting no bug reports. Like surely there was bugs. But at least the uh, like major user facing stuff that people would see was down to essential. Essentially nothing that it was just really stable software and it just does what it's going to do and it still does our classic editor. And then we shifted all of our focus onto the 2.0 product that's out now in public beta, but it's also very stable because then we thought what would be cool about that is maybe we could take the way that we think about and build software and apply that to 2.0. Like let's not move fast on it, let's move really slow and just test the crap out of here it. So that when we release it it's not like last time it was. It's not full of bugs and pitfalls and slowness or whatever it could be. And that's really borne out to be true so far is that this thing is really stable and that feels good. And I think that comes from being maybe, possibly. I don't make um, all about age but like we've just been doing this a long time so we're going to like make good choices this time.

Speaker A: Do you factor in ideal team size, engineering team size, maybe more specifically into how you think about what you prioritize? Like you mentioned like, well, we could hire more people, but then there's like a whole thing. To me, reading between the lines there, it kind of almost sounds like, well, there's not like a huge motivation right now or like need to like let's. We're going to triple or quadruple like our team size in the next two years. Maybe there is, but. And what do we need? What sort of technical decisions do we need to be making now to support that sort of. And knowing that there's a lot of people problems or people challenges and operational workflows that we would need to do. Are you making decisions based off of like, what's your ideal org size? You have like a kind of a philosophy when it comes.

Speaker B: I think so, yeah. I think uh, to me it's almost like two is like a good team size for a particular beefy ish project so you can bounce stuff off each other, but you're really just, you're just kind of coding on the same, you know, feature or beefy ish project kind of thing and that if you put a third person on it, maybe that's okay, but by the time you it put, put four, you're like, you're just stepping on each other's toes. It's hard to split up the work properly. Like that's just like too many for one little project. So if you had those two extra developers, the temptation then is don't put them on the same thing because then you're just stomping on each other. But we could increase velocity if you worked on something else. That's always been how we've thought about it, but we've had trouble with having too many else's and that there's always kind of Alex, he's my, our CTO at the time top that he really, he's always been super, super involved with, you know, code quality and how things are done and what choices are being made and looking at all the code that goes in and all that. But he's always on a project too. Generally if he's pulled in too many directions, it doesn't go well. So we're like, I'd rather have those other two people that could be uh, off on something else do nothing. Which is ridiculous because you can't be paying developers to do nothing. But it hurts us more if in our code quality and, and stuff goes down if there's too many different things going on at once. So scaling is tricky. Like I feel like we're gonna have to do it at some point or I'd like to because I don't want to. I do have at least slightly bigger aspirations than we are. I think that would be okay for somebody who's like, I want to work at a six company, a six person company the rest of my life. That wouldn't be the worst outcome. It's not gonna be sad about that. But I would like to still runs

Speaker A: the business, but over time gets it

Speaker B: have an opportunity to do that. But we would have to start being okay with more projects going on, you know, and I feel like bigger companies, they'd be like, oh, we hired three, four developers and they're just on admin tools.

Speaker A: And that's okay because that's like over

Speaker B: there provides value and it's okay. But it's a totally different team than the team working on the front end of Netflix.

Speaker A: Easier to evolve again, you know, cleaning things up. And I don't know, it seems on theme with the podcast, right? Sometimes we guide the work, sometimes we embed with your team through fractional development. Or team augmentation. Either way the goal is the same. Help your team move forward with competence. If that sounds familiar, you can learn more@planetargon.com secondact Again, that's planetargon.com secondact all right, let's get back to the show. I think about, you know, when I work in the consulting space and so we come into different organizations with different team sizes and I'm always seeing how team structures look like and you know, as teams try to figure out how to the team growth thing there's always like a uh, it's a capacity thing and sometimes that can come down to the capacity of like, like maybe your cto, you know, and it could be like what sort of how many different things can they be juggling or thinking about or putting a bunch of attention at the same time? And like having multiple people, you can't always clone those people right in your team. And so like we'll often as consultants come into like companies will be coming in having us come into a situation where I'm not saying this applies to what you're dealing with but like for other people where engineering teams will be like, ah, we really want to be able to move forward on some more things. But then like sometimes the roadblock for progress is a person. It's like that one person that's like well they're kind of, they're stretched thin and like if you add more to the plate then it's just not going to. And that, that becomes like a.

Speaker B: And you the one read of that is that a problem? And that you need more Bobs or you need to get Bob to let go or something. Then the flip side of that is that Bob had a lot of value. That the bottleneck of Bob is the quality level of the software and that you can't just get Bob to stop caring or that there will be a problem if you do. So it's tricky, you know, and I don't know the answer to that, you know, like it is.

Speaker A: But Bob's aren't always going to be around and then it's like another how do you build that resiliency as an organization? These are complex things that we deal with a lot with this where it might not be like uh, a CTO level person. Sometimes it'll be like oh, we've got a full time contractor that's been on this project for a decade and they know everything and nobody's worked with this person for more than two years and what do we do in this situation? It's A challenging.

Speaker B: Right. These are amazing questions that, like, uncomfortable probably is. Yeah, yeah, there is. And we all got to live through them. I think you. I don't think you can buy a book and just be like, oh, it's like that. You have to try and fail and adjust and whatever.

Speaker A: It's just part of the deal, you know? So. I kept you long enough, Chris. But there's a couple of closing thoughts for. For our listeners. If. If they're working on a smaller team right now and they're kind of ruminating about maybe migrating to some variation of their tech stack or evolve some of it, like, what would you recommend to them to kind of evaluate if that's a good idea? Idea? Because I know a lot of teams out there are, like, weighing up these options. Or they're like. Or maybe they've not made a decision one way or another. They're kind of like, well, there's. There's talk of, like, a migration, but nobody's committed to it one way or another. And so maybe they stop putting as much energy into taking care of the thing that they're already responsible for because they think that maybe they're going to migrate anyways to something different.

Speaker B: I think of that as, you know, some managers have that trouble of being like, you can't, uh, I don't know, there's a temptation to be like, am I making the right choices? Or. Or I'm the person who says, we're going to switch from this software to this software. How do I know that I'm making the right choice there? Or even if you're an, uh, individual contributor and you want to push on something, you want to say, I can't believe we still use Apollo or whatever. We should pull that out and use something else. It really is on you to be able to articulate that. And if you can't, then you don't know enough yet, and that you need to do more information gathering and work on your. On your arguments. It's almost like the skill of debate or something. I do think that's important. Like, if somebody came to me and said, uh, Astro is a great new framework. I think we should be serving our pages with it instead. Okay, you better have a lot more than that sentence to convince me. Why is that? And if you can't articulate it, then maybe there isn't enough reasons or whatever. I'm gonna say no until you can. Until you can explain why. And there might be reasons. You can be like, well, well, we don't even have SSR server side Rendering. This is a, uh, built in, first class citizen of this framework and I think our web app will be faster for it. And I think that it's not going to impart technical data. Maybe we have an SSR strategy now, but it's really complicated and brittle and it's really simple in this. And I have an example of that. Look at this code versus look at this code. It's cleaner in that way. That's on you. You have to do the work. You can't just be like, God, what's going to be better? Am I going to. Should we do tan stack? I don't even know what it is, but I'm going to flip a coin. The coin said, yes, let's do it. You know, like that's irresponsible and silly. You know, you need like reasons to change. We had reasons to leave Rails. The reason was cost and speed.

Speaker A: Do you think there are always that clear cut though, those reasons or sometimes you feel like you have to kind of place a bet on them?

Speaker B: Yeah, that's. Yeah, you gotta place a bet. We could have been wrong about Go. We could have had the team not embrace it. We could have had that language not be cool anymore. I mean, there's already a little risk of, you know, there's kind of a Rust versus Go thing. Oh, should we, Is Rust safer? Should we have done that instead or, or what? I mean, so far so good. But. But yeah, and then be kind of ready to reevaluate it, you know, because we're using a, uh, next JS and Apollo and all this stuff and I feel like it's. I hate to say the word fine because usually when people say fine, they mean not fine, but I actually mean fine. Like it's fine, you know, like it's. I don't know, like it's rendering pages speedily. I think we're, we're comfortable in it. It's getting the job done. But, but what if, what if it, uh, was a different, more modern framework? I mean, I know the svelte heads are pretty damn serious that it's a much better framework. And is it though, like, as somebody who would be in charge of that. I am. We are not switching to svelte at this point. It's. I don't see the, I can't see it, uh, the benefit, but, but it's there. I'm, you know, like if I could snap my fingers and do it maybe.

Speaker A: And I'm curious, is there a non technical, non programming, non software book that you like to recommend to your peers.

Speaker B: Have you ever had somebody recommend Understanding comics by Scott McLeod? That's a really good one to put on your list of.

Speaker A: Uh, I've not heard of that one yet. I will definitely look that up and maybe grab a copy of that myself.

Speaker B: It's about comics, but it's, you know, the metaphor goes lots of places and I think people can find lots of different things you maybe didn't even know you were looking for in a book like that about how to express yourself. And certainly if you're in software development, it's highly relevant.

Speaker A: All right, I'll include links to that for our listeners in the show notes. And where can listeners best follow your thoughts ruminations about software engineering or threatened development online?

Speaker B: I'm an old school RSS guy and a, ah, big fan of having a personal website. So my personal website is my name dot net. Um, you don't have to remember that, just Chris Coyer. I bought the dot com not long ago so you can go there too. And I probably overpaid for it, but.

Speaker A: Well, I'll definitely include links to both those in the show notes for everybody. And thank you so much for joining us on Maintainable Talk Shop.

Speaker B: My pleasure. And uh, this is going to be a crossover, you know, out there, listeners. Going to have Robby over on Shop Talk show soon too.

Speaker A: All right, thank you so much, Chris. Thanks for stopping by. You've been listening to Maintainable A Planet Argon production editing by Claudia Armbruster Post production by Auden Morgan and Ellis Fensen. Emotional support from the letter M for Maintainable, for momentum, for making things better. If this episode resonated with you, share it with someone who needs to hear it. Keep showing up. See you next time.