Both Alex and I, the co-founders of CodePen, spent time trying to whittle down hopefully interesting and practical advice for you from our experience in running a SaaS company for a decade! Let’s go back and forth, combining into a top 10 like we did in the show.

🔟 Alex: The High Low Principle

Only do things that are either:

As in, they take a long time but are going to make a big difference. Or they won’t take too long, don’t ask too much of you, but are still helpful. This is the answer to the build vs buy conundrum. It’s a buy for everything in between.

9️⃣ Chris: The Co-Founder Relationship is at the heart of the business

Every relationship between people at a company is important, but the relationship between the founders is crucial. It sets the culture and makes everything work. The company cannot continue with a broken relationship at the founder level. They say it is like marriage, and that analogy isn’t far off.

Chances are, you’re going to find out you are very different people who think and feel differently about all sorts of things. You need to get along, you need to respect each other, you need to trust each other, but you can’t avoid hard conversations (as much as I would like to).

8️⃣ Alex: Build Minimalist Tech

Do more with less. Just because you didn’t write it doesn’t mean it’s less complex. Just because you did write it doesn’t mean it’s less complex. You might have to add technology in the short term as you’re migrating to what will end up with more minimal tech. It is a focusing of you and your team’s expertise.

7️⃣ Chris: You’re probably undercharging people

You’re probably undercharging people for your software product. Software is always difficult to build and maintain. It’s likely your intuition leads you toward lower prices, but every experience we’ve ever had with higher prices (and raising prices) has been positive. Fewer people than you think will care, revenue goes up, and your time is better compensated. Plus, there is a weird correlation between your high-paying customers being chill and low-paying customers being more challenging.

6️⃣ Alex: One thing at a time

Only do one of these at a time: learn new tech or solve a new problem. Do not do both. One is a magical number. Do one thing at a time.

5️⃣ Chris: Nobody has the same thing in their brain

Making sure everyone is on the same page is hard. There are so many business constructs designed to get everyone there: meetings, documents, emails… and yet, if you think everyone understands what is happening the same way you do, you are not right. But keeping everyone together is still a vital part of the process. Try to get better at expressing what is in your brain and sussing out when you think it might be different than what is in other people you work with’s brains. Time spent communicating is time well spent.

4️⃣ Alex: Honesty defines your culture

Honesty is a fundamental part of your culture. That is, honesty or dishonesty, like it or not. Honesty is better. Be honest about your work, your management, and yourself. Remember that honesty has nothing to do with being nice. Being nice doesn’t mean being honest. Being mean doesn’t mean being honest. But being honest might mean uncomfortable conversations.

A person’s success in life can usually be measured by the number of uncomfortable conversations he or she is willing to have.

— Tim Ferris

3️⃣ Chris: Time is precious and easily chewed away

Anything and everything is a threat to your time. Slice away what isn’t core to your business. You’ll be drowning for time soon enough, so spend it on what really matters to your business. This is where technical debt comes in, and being careful about where you acquire it. You’ll make mistakes, but a better you can recover from them. Pay the debts and move on.

2️⃣ Alex: Do not poke

It’s easy to poke at problems. Take a guess, try it, and if it seems to work, do it and move on. Don’t do that. Draw a line in the sand. Stop poking. Slow down and deeply understand the problem. Read the source code. You’ll understand the problem better if you move slowly. Eventually, that style of slow problem-solving will feel smooth, and that smoothness will, ironically, help you move faster.

Slow is smooth and smooth is fast.

— Navy Seals saying

1️⃣ Chris: Here are your cheat codes: writing, persistence, and positivity

If anything has given me, and by extension CodePen, a jump in this world, it is these three things. You can build an audience through writing. An audience of people that trust you and like you and will try the things you make. The ability to communicate well with words will serve you forever, inside and outside your company. Persistence is a byproduct of having a good idea, knowing it, and having the wherewithal to see it through. A business is not built in 6 months. Stick with your good idea, it’s the only way. Positivity ties it all together. Writing is your vehicle for telling your tribe, over and over, that everything is going to be great and you’ll be there to help make sure it is.


Time Jumps

  • 00:25 Happy anniversaries
  • 00:45 How CodePen was launched
  • 08:31 The high low principle
  • 12:22 Cofounder relationship at the heart of the business
  • 14:53 Sponsor: Notion
  • 16:28 Building more, with less
  • 20:12 Charge more money
  • 23:24 Doing one thing at a time
  • 26:14 Making sure everyone is on the same page is hard
  • 31:25 Honesty is a fundemental part of your culture
  • 39:16 Time is easily chewed away
  • 43:10 Do not poke
  • 51:22 Writing, persistence, and positivity

Sponsor: Notion

Notion is an amazing collaborative tool that not only helps organize your company’s information but helps with project management as well. We know that all too well here at CodePen, as we use Notion for countless business tasks. Learn more and get started for free at notion.com/codepen. Take your first step toward an organized, happier team, today.

Transcript

[Radio channel adjustment]

Announcer: Today, on CodePen Radio.

Chris Coyier: Hey, everybody. CodePen Radio. I've got my co-founder Alex on this week. It's been a minute since we've done a show. What's up, dude?

Alex: Hey, thanks for having me on.

Chris: Yeah, 379. It's a big moment for us. It's my wedding anniversary today, as we record, so that's kind of cool. Five years, which is half the time that me and you have been married. [Laughter]

Alex: Nice. Nice. Yeah, that is -- it is very much my second major significant relationship. Let me tell you.

Chris: It was just a couple of weeks ago when we hit our kind of official ten-year release of CodePen. There was a brief alpha ten years ago, I think. I literally barely remember; it was so long ago.

Alex: Six months, I think. Yeah.

Chris: Yeah. And then there was a blog post on CSS-Tricks, which is the date that I use to kind of measure it where I was like, "CodePen beta," where we just invited the world. Anybody could sign up. We never had a fancy thing like Dribbble had - or whatever - where you have to be invited. We never coded up anything like that. We just did straight up anybody could sign up on that day, which was, I guess, earlier in July of 20-whatever-12.

So, it's hit the official ten-year kind of public thing of CodePen.

Alex: Ten.

Chris: As a milestone, it's kind of cool. You know? And I've always been a sucker for these kind of developer blog posts that's like, "I've been programming in C# for 15 years, and here's 10 things I learned," kind of thing.

Alex: [Laughter]

Chris: I'm going to click the shit out of that. You know? [Laughter]

Alex: Yeah. That's--

Chris: Because they put developers in this little bit of a--

Alex: It works every time.

Chris: Yeah, like a reflective mindset, which I kind of enjoy. You know? So, I thought that's what we'd do, and I proposed to you. Let's do a "We've been running a software company for ten years. Here's what learned," kind of thing. Or "Here are some insights."

Because it's ten, I thought we'd both do five. And for this show, we did not talk about - at all - what each of our five were, so I have literally no idea what Alex is going to say, and he has no idea what I'm going to say.

The only thing we did talk about is that we both struggled with it in different ways, I think, just because it's so - I don't know. Why did you find it difficult to think about?

00:02:32

Alex: Yeah, I mean for me, I wanted to provide something that was unique to our experience. We've had ten years doing this, and we made all the classical mistakes and some of the less classical mistakes.

I had a difficult time trying to provide something that I hadn't heard before. A lot of the cliches end up applying after ten years.

Chris: Yeah.

Alex: So, I wanted to give something unique, something that I hadn't just stolen from someone else.

Chris: Mm-hmm.

Alex: That was a little difficult to narrow down.

Chris: It was for me, and part of the difficulty for me is that we're not reflecting on a complete journey by any means. I've never felt more in the thick of it ever, maybe, at CodePen than now. We're on a huge project. We're really trying to bust ass on CodePen, but we're doing it kind of like this is going to be a big release that nobody has really seen yet, and we're trying to be really considerate and smart and reflect on our ten years while we're doing that work. It's like, I almost don't feel ready to be talking about advice when we're so in the thick of it, but I tried anyway. Regardless of that.

You're right about the cliches. They pop to mind so easily that I think some of mine might come across as cliche, but I tried to lean into it and think, you know, reflect on the cliche almost, like is it true, is it not true. How do our unique experiences jive with the cliches?

00:04:13

Alex: Yeah, I almost feel like being in the middle of it, being in the thick of it is helpful for the honesty of the advice because we talk about this all the time. A lot of times, a story will be rewritten based on the success or failure of the result, right?

We have this advice to give over small successes and small failures that we've had, but we can't rewrite history at this point and be like, "Well, this is how we knew we were going to succeed," and spin it into a really nice, beautiful, coherent story, like we knew the whole time we were going to do this because of all these other things that we noticed.

Chris: Yeah.

Alex: And so, there's a bit of honesty in doing it in the middle versus in the end where you know the end result and being able to spin the yarn so that you come out looking like the hero.

Chris: Yeah!

Alex: Hopefully, this is a little bit more helpful for everybody out there trying to build something.

Chris: What's his name? Ask Henry Ford at the end of his career, "What does it take to build a big, successful company?"

He's like, "Well, you just pull yourself up by your bootstraps and do it." You're like, hmm. You're on your deathbed, man. [Laughter]

Alex: Yeah.

Chris: Of course, you get to just give these little cheesy--

I don't know if he actually said that or whatever, but when you're too far removed and you're too successful for too long, anything you say you can convince yourself that that's what it took. You know?

Alex: Yeah. Yeah, like if you asked George Washington Carver if he knew about peanut butter the whole time, you'd be like, "Oh, yeah. I knew peanut butter and jelly was going to be big." [Laughter] You know?

Chris: [Laughter] Huge.

Alex: It would be easy to say that after the fact because it's your big seller - or whatever.

Chris: Yeah.

Alex: He did a lot of things with peanuts - for everybody out there who doesn't know George Washington Carver.

Chris: [Laughter]

Alex: Did a lot more with peanuts than just peanut butter, so a little historical tidbit there.

00:06:03

Chris: What else was I going to say about this? I want to jump into the top ten, but I like reflecting on that too, that we're definitely in the middle of our journey here and thus hopefully more honest for you.

Oh, this is what it was. It was that there are probably some people out there that would happily trade shoes with you or I, that look at CodePen as something that's already been successful and is already a good, healthy startup, and doing all the things that they would hope to do in software.

To that, I'd say, "Cool. Yeah." We have had some success. We pay ourselves. We're a profitable company. A lot of people know who we are. It opens doors - yadda-yadda.

Then there are some people that would look at us and just be like, "Meh, they really didn't hit it."

Alex: Right.

Chris: "There was no huge return for the investors. Nobody is retiring off of this thing. It's not a feather in the cap of anybody quite yet."

I think both people would be kind of right. We're right in this weird middle stage.

Alex: Yeah, it's definitely a matter of perspective. I can tell you that after ten years, the bloom is off the rose. I don't know if that's the phrase.

Chris: [Laughter]

Alex: But you know we've enjoyed working for ourselves, but it's something that doesn't quite have the romantic vibe that when we started because we've just learned so much. It's a lot of work.

Some people who would say, "Oh, I pine for the idea of being able to work for myself and find it beautiful," and sometimes there are days where I honestly pine to work for literally anyone else.

Chris: [Laughter] Yeah.

Alex: And so, you have tough days. And so, you could judge us in many different ways, and I think it'll really influence how you take the advice we have. But nonetheless, we're here to give it.

Chris: Right. Yeah. It changes day-to-day. It's a fricken' rollercoaster. It is kind of cool that we invented all the money that we pay ourselves out of thin air, essentially, by convincing people that our product is cool, and that's that.

But yeah, some days it's like, "God, I wish I could just punch a clock. Jesus Christ." [Laughter]

Alex: Yeah. Yeah. You have your days. Yep.

00:08:06

Chris: All right. Who wants to go first? Are you ready?

Alex: Uh, yeah. I mean I'm ready. I'll go ahead and go first with my first one.

Chris: All right. All right.

Alex: So, just to load it back up, I'm doing five. Chris is doing five.

Chris: Yep.

Alex: For anybody who doesn't want to do math out there, that means ten. We've got a top ten.

So, I'm going from least important to most important.

Chris: Okay. Okay.

Alex: Is that how you're doing yours?

Chris: Oh, sure. Let's do that. That sounds good.

Alex: However you want to do it. All right, so again, trying to give what I hope is unique advice.

One of the ideas that I've kind of tried to follow here, for lack of a better term, I call it the high-low principle. What that means to me is I think that when you're a software company, you can choose to build so many things. I think there's a sweet spot for the kind of stuff you should build.

The high-low principle, to me, means only build things that have high value and require high investment or low value and low investment, and buy everything else in between. For example, we purchased a very nice app called Appcues. It helps us give tours and tips and do surveys and advice to people on CodePen. For us, the return on that is kind of in the middle. It's nice. It's more than a low-value thing for us, but in order to build that out internally, we've learned, it would be a very high investment because that is a product.

I love the idea that we just purchased it, and we didn't try to build it in-house. We've done that before where we've kind of tried to build things that we thought were medium investment and had hopefully about medium return, and I always felt like that was a mistake. So, when I'm looking at what we should build versus what we should buy, I kind of try to use the high-low principle to determine that.

Chris: It almost made my list too. I really wanted to weigh in on build versus buy because that's one of the cliche things that gets talked about in building a business land, and it's so nuanced that I thought I might just take a hardline position on it just for fun and just say buy. It's buy.

Alex: [Laughter] Yeah.

Chris: [Laughter]

Alex: Yeah, honestly, it's cheaper to buy most things. With today's Web, there are so many software products, so many solutions. Even if it's not perfect, you should really lean towards buy.

Low investment is you've got things that we can do with scripts and things like that we just build them. We don't even think about them.

Chris: Yeah. Right.

Alex: You know, half a day to a day's worth of investment, we tend to just automatically build those things and just move on.

Chris: Yeah. Yeah.

Alex: But yeah, that's kind of a principle we try to follow.

00:11:12

Chris: Oh, I say it because we do that because we've had experience with doing too much building, I think, generally. That's just because that's how we lean because we're just nerds that way. And that anything that we bought, we've generally not regretted. And that we were not rich. We never had really deep VC stuff, so it's like--

Let's say you were in the other boat, which is also really common for startups is that you have a bunch of other people's money. You should spend it. [Laughter]

Alex: Right.

Chris: You know?

Alex: Right, but you should spend it on--

When you're talking about the big investment, your big investment in tech tends to be staffing and everyone's time. And so, when you're looking at spending it, investing in those high-value projects are huge. The day-to-day stuff, sure, just build it in-house, the small things, little things that you need done, automation, you know, sending emails, whatever it is. It shouldn't take you too long.

Chris: Yeah.

Alex: But if email is a significant part of your business, maybe you buy it -- I'm sorry. Maybe you build it. It's up to every business to decide, but I think that's really helpful in determining what you should and shouldn't do.

Chris: Hmm.

Alex: All right. Let's hear. Let's hear your top, your five.

00:12:22

Chris: Yeah, mine. I guess it'll be nine. I'll try to arrange it. It was a wildcard for me to go from least value to most, so don't read too much into this, but I'm just going to start with this one and it's because it's a cliche that I already mentioned already is that kind of marriage thing.

The co-founder relationship is absolutely at the heart of the business. It establishes the culture. Having that be a high-functioning relationship is so crucial in a way that I didn't understand the whole time. You know it's just like, "I don't know. We're partners. Obviously, we work together."

Alex: [Laughter]

Chris: But knowing how much we've gone through and how much up and downs there are and how it's the tiny little domino at the whole stack that if it were to fall over, it's over. It's absolutely over. You know? It's just so vital.

The marriage analogy that people throw out there, that's just the way it is. You know?

Alex: I was just going to say that there are ways that you can work with each other but not be synchronized, and that's a huge part of it.

For a long time, we built things together and didn't necessarily always agree on how to do it and didn't have those deeper discussions, and we fought through that, and that's tough.

Chris: It's tough. You're also going to find out that--

I think, in the beginning, it's tempting to be like, "We are simpatico, man. We are aligned with this. We both want the same things. We are like everything is fun."

Alex: [Laughter]

Chris: You're just going to learn a lot about each other, like you would in a marriage, and you're going to find out that you're different fricken' people. Me and you are different fricken people in a lot of ways.

Alex: ...right now.

Chris: But we still need to get along. You still need to respect each other. You still need to trust each other, and you're going to have all these hard conversations that, for me, just suck, but I see the value in them, and so now I almost cherish them (kind of thing, you know).

Just knowing how we both have had our own weird journeys with conflict diverseness that's just been nothing but bad for us. [Laughter]

Alex: Yep. Yeah.

Chris: I just wanted to cover that.

Alex: Yeah, it's always been a real struggle, a real struggle for us.

Chris: It really is.

Alex: Avoiding the difficult discussions. Yeah, I actually allude to that in one of my bullet points here. Yeah, it's been huge.

Chris: Yeah. Go ahead, then.

Alex: Well, I can't. I can't because I have to go in order, Chris.

Chris: Can't jump ahead. Yep. Yep. Yep.

Alex: I can't jump ahead. [Laughter] It's that important to me that it's not the next one. [Laughter]

00:14:53

[Guitar music starts]

Chris: This episode of CodePen Radio is brought to you in part by Notion. That's notion.com/codepen. Go there to get started.

Notion is a beautiful tool. We use it a ton at CodePen. One of the main things we use it for is we use it as a team. Right? Everybody who works here has an account on Notion and they log into it.

It's almost like an information base. There's all kinds of information about how we do things and how we code things and how customer support works and how our marketing and advertising stuff work. But it's for planning ahead. It's for planning this podcast ahead and CodePen challenges ahead.

But probably most importantly, it's for our active projects, like what are we working on, what should you be doing right now with those projects broken up into phases and individual tasks and such, and then what's coming up later. We've recently just went through some work digging a little deeper into the Notion feature set and doing more with our tasks like that.

For example, we've given them estimated how much time they're going to take. At least just rough estimates. We can kind of see how much work is ahead on a sprint or a block of work (in a way).

They even have a timeline view that's a bit like a Gantt chart, so you can kind of see, well, once we finish this, we can move onto this, where these two things can go in parallel, and stuff like that. Some real project planning stuff built into there, but it's not too opinionated like, "You must do your project planning like this."

You can use it a little more amorphously than that, kind of take notes in there, and put whatever you want wherever you need structure, however you need to. A really powerful app in that regard.

Thanks so much for the support, Notion. I bet your team would get a kick out of it for sure. Learn more and get started for free at notion.com/codepen. That's notion.com/codepen to help you take the first step towards an organized, happier team today.

[Guitar music ends]

00:16:53

Alex: Yeah, so my next one, it's about following a strategy of tech minimalism (is what I call it). It's building more with less, and that's something that's been incredibly helpful.

When you build more of your technology with less tech, you become more of an expert in that technology. You get to reuse that technology.

One of the recent moves that we made internally was we moved -- we did two really significant moves. One of them was we moved from MySQL to PostgreSQL, to a very recent version of PostgreSQL 13. And we're getting to build a lot more with that piece of technology.

We're building some internal queue systems that we need. We're building some search technology that we need. We're building obviously database technology we need, and we're probably going to throw in a little bit of analytics in there.

Chris: How is that minimalist? Is it because it's all PostgreSQL-based, so you're not reaching for other things?

Alex: Right. Yeah, so the idea there is that we're building more. We could have a database that's specifically for analytics.

Now, we don't have those needs because our scale isn't that large that we need it. We could have another queuing system that is specific. We could wrap it in Cue or something like that. Something really significant, we could bring in Kafka.

Yes, those technologies would probably be a better fit, but we don't have the ability to support them. And that also means we would be worse at using those technologies. And so, doing more with less is a really key, vital part of us having expertise, deep expertise, in the technology we use. It's really been influential.

The second significant technology choice that we made is Golang. We're slowly moving to Golang, but the beauty of doing something like that is we get to remove a lot of the layers that we normally would have in our stack. It's added a lot of capability to what we can do. A lot of times, if we can't do it with Golang, it's just another reason to buy a solution for us.

That's been really influential in my thinking, like, how do we build this? What do we build? Where do we outsource this piece of technology? I'm really happy with that.

Honestly, any time we get to remove an entire piece of tech from our stack, it makes me overjoyed. And that's been really helpful to try to follow that.

00:19:38

Chris: Both of those are thick with some interesting nuance almost opposite thinking, though. In both cases, you had to add new technology in order to achieve the minimalism. It seems counterintuitive.

Alex: It really is. It really is, and we tried. We tried those things out. We dabbled before we jumped head first.

Chris: [Laughter]

Alex: So, that was not a decision we made in haste. When we take on a new technology, it's the opposite of being minimalist but, over time, we will have less and less and so more with what we have.

Chris: So far so good. All right, here's mine. It has to do with money on this, so this is another -- a little bit of a cliche one, but I'm not even going to add that much nuance to it.

You're probably undercharging people. You should charge more money for your software product.

We've had a couple of moments, and some of them even outside of CodePen, where the only change made was changing the pricing of the product to be more. And in both cases, it was unbelievable what happened.

You just make more money. Nobody cared. Nobody cared.

I mean nobody is a rounding error. You know? [Laughter] I'm sure there are a few people that care, and there'll be people that write in to tell you that they care at any time under any circumstances.

Alex: Right.

Chris: They'll be like, "Yeah, I don't know if this is worth..." that kind of thing. But just in our experience, we've seen it be that way, and here's the reason. Nobody is particularly happy with their lowest-paying customers.

You'll find -- and this is our business and from hearing from others -- that the ones that are the most annoying, that demand the most of your time, and the most of your attention, are the lowest paying customers. [Laughter] In our case, it's often free. I hate to say that.

Alex: Right.

Chris: But that's kind of the case too. Then we have these really big teams and high-paying customers that you never hear from at all.

It just makes me think of how much that's just -- people tend to underprice their products, and it's just kind of general advice to not do that.

00:21:48

Alex: Yeah. In the end, you're kind of undervaluing your product in that way. It allows you -- a higher price does allow you to provide a better result. It's not just being a capitalist and just charging more and getting more and more money and stuffing it in your pockets. It's the ability to provide a better service; more value to everyone who does pay you.

That's really significant in a really noisy market. There are so many solutions to so many of the things that we build these days that being a really high-quality product and providing that is honestly just pleasurable, great for everybody around (including the people paying you). So, it ends up being a really good solution.

Chris: Yeah. I mean it's not so subtle, but we will be doing that at CodePen at some point.

I'd do it tomorrow. It's all baked into this larger project that we're doing, so don't worry. We'll be taking our own advice.

I'm not trying to scare you. It's not like we're going to go absolutely crazy, but the value is going to be more commensurate.

Alex: We believe the value will be skyrocketing, so.

00:22:51

Chris: You know the one I think about? Not to drag this out. But I always think of Gusto because I feel like we pay Gusto $30 a month or something. Like, are you fricken' kidding me?

Alex: Slightly more, but.

[Laughter]

Chris: Is it $50 or something? It's not hundreds.

Alex: Slightly more. Yeah, I don't know the exact number. It might be around $100. It's something like that.

Chris: That's crazy. For being like our whole HR department, I feel like their pricing is way jacked up to be too low.

Alex: Don't give them ideas. They listen to those kinds of things.

[Laughter]

Chris: Yeah, I don't want to pay you more. I just think it's a funny example.

All right. You're back. You're back to Alex.

00:23:25

Alex: Okay. Yeah, so this is a little bit aligned with the tech minimalism, but it's more about how you go about building things.

I would say that one is a really magical number. One is magical because I like doing one thing at a time. And let me explain what I mean by that.

Chris: Woo...

Alex: Doing one thing at a time means that you're only solving one new problem at a time. For example, when we were determining whether or not we should use Golang, what I did was I solved an old problem, which for us was sending emails, with Golang.

What that meant was I only had to solve one problem, and that problem was how do I use Golang. [Laughter] That problem wasn't, "How do I solve this problem with sending emails?" because it wasn't new to me.

I knew the email provider we were using. I knew where the templates were. Our customer base, we had tables, we had everything. The only thing I had to do at that point was port a bunch of Ruby code to some Golang code.

Similarly, when we're solving a new problem, we do not use new technology to solve that new problem. We want to make sure that we have expertise and have confidence to solve the new problem with the technology choice we're using.

We've made that mistake before. I remember when we were building projects. I think we had three or four new technologies. Projects, at the time, was a significant departure from what we were doing from Pens.

We were solving many new technological problems but also solving new business problems. It was just overwhelming. And if you want to narrow it down to the least number of things, least number of problems you're solving, one is -- you can't solve zero because you end up unemployed if you're solving zero problems.

Chris: [Laughter]

Alex: But one is right there. And so, that was a really significant thing to learn. And so, now that we're taking on this much larger, significant project, we've had several years of learning Go, learning all the other technologies that we're using. And the only problem we're solving is the business product problem that we're trying to build. That to me was really, really significant.

00:25:52

Chris: Yeah, it reminds me of context switching stuff. Is that the right number of things to be working on at any given time is one.

Alex: That's a little bit harder to achieve. [Laughter]

Chris: Yeah. [Laughter]

Alex: But we try. It's difficult. It's easy to get derailed all the time, but yeah. At the very least, when you're getting into your immediate problems, you're doing one. Trying to solve one thing at a time is really significant.

00:26:14

Chris: All right. I joked earlier, [laughter] weeks ago while we were planning this, that we'd drink every time we said communication because I feel like that's going to come up a number of times here.

Alex: [Laughter]

Chris: But I wanted to dig into one of those, and it's about -- I'm not happy with the title, but -- making sure that everyone is on the same page is hard. I mean that in several different ways.

I think of even something like a feature, even something that's like, "We're going to build this." It could be a sub-feature. It could be a little tiny thing, and I have it in my head in some way that that's how it's going to be, that's what it's going to look like, this is what's going to work, this is what it's going to do for users, this is how we're going to talk about it - or something. I have some version of all those things in my head.

I feel like I used to just kind of assume (incorrectly) that everybody also had that same crap in their head too. You know?

Alex: [Laughter] Yeah.

Chris: That they understood it in the same way that I did.

Alex: Which is wild. That we ever assume that is wild.

Chris: Yeah. Just stupid. It's just almost like empathy gone wrong or something. I assume too much out of your brain that we somehow share the same brain or something.

So, obviously, more communication is required so that I can really say exactly what I mean. Let's assume it's this feature thing that we're talking about that I'm showing you what it's going to be. We're talking about the details.

Try to get our brains in synch on what this thing is going to be is really pretty tricky. Even after you think you've done it, I think you haven't done it. [Laughter]

If you let a week go by or something, like your mind has been churning on it in a way that is very different than somebody else's mind has been churning on it, and it's just one of the hardest damn things.

To ever assume that everybody understands this thing in the same way that you do, you'd just be shocked. They just don't. [Laughter]

00:28:14

Alex: Yeah, you end up realizing that you almost need to become a bit of a politician for your ideas in the sense of you have to repeat yourself over and over again, which can be difficult.

You'd be like, "Well, everyone knows what I'm saying, so I'm not going to say it again," and you realize, "No, I actually should say it 100 times so that it's clear to me."

You almost want to have talking points about the feature set that you're trying to -- that you think you want to deliver, but you're doing it within your team, which is not always obvious. You can think that we're on the same page and realize, no, there's a lot of nuance because everything is so much more complex than you ever expect it to be when you get into details.

Chris: Yeah, right.

Alex: I couldn't agree more with that. Sometimes I feel stupid saying the same thing to the same group of people, but then you realize that you're not even in agreement about these details until you've kind of--

Chris: No.

Alex: Sometimes, it doesn't even jive, like someone is distracted. They're not really listening to this point. Yeah.

00:29:23

Chris: I think of things. Where the rubber always hits the road is when a little bit more happens. That it's not just talk. It's not just in somebody's brain at this point.

Alex: Right.

Chris: You'll be coding something and -- all the time, this is very CodePen culture -- they'll be like, "Let me share my screen." Somebody is always fricken' sharing their screen all the time. And it's because I think we've just learned that that's a moment that brings that clarity.

You do it all the time. You show me exactly the line of code that is relevant to what we're doing. Then you're like, "Oh, I see. I had this thing in my brain about how these are going to work, and I see how it just doesn't serve the code in this case."

Alex: Right.

Chris: It's just missing this piece of thing. And it happens with design, too, is that maybe--

Just because historically we've been ahead design-wise a little bit over back-end type of coding stuff, and we'll bring up a mock-up, and then that's the moment where people are like, "Oh, whoa, whoa, whoa. I did not realize that's quite where we were heading with this thing."

It's always that moment, but it's worth doing. You can't avoid it. So, having some kind of demo, whether it's code or not, tends to be the thing that starts to smooth that out.

00:30:38

Alex: Right. I mean, actually, we're fortunate in the white collar world that we get to share a very specific thing like code in that if you're just talking (like an art department) and you're talking about the conceptual idea of what you're going to build or the story you're going to tell, there's so much nuance there. You know?

Chris: Yeah.

Alex: Whereas we can kind of share the exact details, but it's still hard. We're a remote company, and I don't get to bring people over to my screen and show them exactly what I'm talking about.

You don't get to use your hands to describe this thing. It's not always very clear. We're not in the same room. And so, it's really helpful when we have those conversations and kind of try to get to that clarity.

Chris: Two each left?

00:31:26

Alex: Yeah, we've got two each. And so, I guess, jumping off of that, my number two is honesty is a fundamental part of your culture. Whether it's dishonesty or honesty, honesty in and of itself is going to be a fundamental part of your culture.

I've used this quote probably way too many times, but I'll say it again because you have to repeat yourself sometimes. One of my favorite quotes is from Tim Ferris. He says, "A person's success in life can usually be measured by the number of uncomfortable conversations he or she is willing to have."

Honesty doesn't mean that you're a jerk. It doesn't mean being nice. And it doesn't mean that you're mean to people. But it does mean that you try to arrive at a very honest solution or agreement or disagreement.

There are times where you have to agree to disagree and move on. There are times when you have to call yourself out for the thing that happened.

I try to do that as best I can and say, like, "Hey, I made a mistake here. I took down the site." I took down the site for, like, 20 minutes. I didn't take it down, but I essentially broke it for 20 to 30 minutes a couple of weekends ago.

I'm not trying to be self-deprecating. I'm not trying to show everyone how stupid I am either or how honest I am. I'm just being honest about the fact that I did that. I regret it, but I also don't feel a need to overly apologize, and no one else should either when they make mistakes in the search of improving the product that we're building.

At the end of the day, we are cracking eggs to make this omelet called CodePen. We're going our best, and so trying to be honest about our opinions as to what we're building is really difficult at times.

It's really difficult because a lot of times you want to agree, you want to appreciate each other's work. And especially when it feels a bit subjective. I try to be very honest about, "Hey, my opinion is subjective, so it's an opinion and you can take it or leave it."

But if I have something where I'm like, "Fundamentally, I feel like this is an objective thing," or "This is something so fundamental to CodePen that even though it's subjective, we're going to have to go with our opinion."

And I'm going to tell you it's an opinion, it's subjective, and yet we have to go this way because, at the end of the day, Chris and I, we are very much married to this product. And so, you have to have these moments, and it has to be a fundamental part of your culture.

00:34:16

Chris: What's being not honest about your opinion? Would it be just not sharing it, right? It'd be holding your opinion back.

Alex: Not sharing it or agreeing when you kind of disagree about that.

Chris: Okay. Yeah.

Alex: And I think I struggle with that because I often ask people to share an honest opinion and then fight them on their honest opinions.

[Laughter]

Alex: So, it's really difficult. I think anyone would agree that "Hey, dude. You're asking me to share my honest opinion and then you're criticizing my honest opinion."

Chris: [Laughter]

Alex: There's some real nuance to creating this culture of honesty, and I'm personally working on that. But it's difficult. It's really difficult.

I think a lot of modern tech companies, everybody tends to lean towards, "I just want to be nice, and I want to appreciate your work and appreciate your opinion," yet there are decisions you're making on what you're building where we can't all be appreciated and we can't agree to make everything that everyone wants to make. And there are times where you have to say no to each other or give a critique or admit you're wrong, and that's difficult.

Having a culture -- having honesty, the good version of honesty, be part of your culture I think is fundamental to your success and it's really vital.

Chris: Yes. That's tricky to encourage. That's probably a time when laughter really is like a huge ally because if you really are trying to drag out somebody's honest opinion, they give it, and then you shoot it down, there's no incentive for them to do that again unless you kind of embrace the humor and the irony of that happening, so that almost the next time, they're more likely to do it because, hey, at least it was good for a laugh or something.

Alex: Right. You understand that, hey, I'm not taking myself so serious that I'm not--

Chris: Yeah.

Alex: When I shoot down your idea or I disagree with your idea, it's not because of this version that I see myself as infallible. I'm actually honestly disagreeing with the idea that you have, and so it's important to disagree with the idea and not try to--

Try to sidestep all these things that feel like character--

Chris: Yeah.

Alex: --critiques of the person. You know? Like, "Oh, I'm critiquing you as a person? No, I'm critiquing the idea. Try to focus on that."

00:36:48

Chris: And you better be ready to do it. That's been an extension of that, I've found, is that you live by and we've tried to make cultural too is that you can't just disagree with no reasoning or alternative or backup or anything. Right?

You can't just be like, "I don't like it." [Laughter] That's not good enough.

Alex: Yeah. Like, #fail. That's not good enough.

If we wanted to get just open criticism without an alternative solution, we would just put things out on the internet and people would give us plenty of critique for what they don't like about us.

Chris: Mm-hmm.

Alex: But when you're part of the team, it's like you kind of have to present an alternative. You can't just be like--

You can say, "I don't like this and I can't really articulate why. I'm going to think about it and come back to it." That's totally fine.

Chris: Mm-hmm.

Alex: I feel like that's something I've had to do. Whenever I feel discomfort about a thing, I'm like, "Well, I don't really like this thing. I can't articulate why." In those moments, I will stop and not give criticism but know that I need to put that together. If it's really that important to me, it'll keep bubbling up.

Chris: Oh, yeah. You'll just say it. You'll just say, "I feel like I disagree, but I'm not ready to full-blown disagree yet because I haven't formed my counterargument."

Alex: Yeah and, hopefully, people have felt comfortable enough. I think enough people disagree with me often enough that it encourages other people to disagree with both of us to be like, "Hey, I think what you're saying is not right at all."

Sometimes I would honestly appreciate some yes people around. I'll be honest.

[Laughter]

Alex: We haven't had the level of success where I can just have people just--

Chris: I'm honestly shocked that we don't have more of that because, you know.

Alex: [Laughter]

Chris: I feel like you've got ... once in a while, just to be fair.

Alex: Yeah. I would say we don't quite hire for it.

Chris: No.

Alex: For just like superfans who just will agree with us, so that's just part of our culture, and I've learned to try to embrace it. There's always something to improve, like I said.

Critiquing people who give you honest feedback is not the best way to encourage that along the way, so there are all kinds of things that it requires to have that honesty be part of the culture, but it is because otherwise you're communicating but you're not really getting the value out of the purpose of communicating things.

What's yours? What's your number two?

00:39:17

Chris: I hope I don't steal it away. I feel like this comes from our conversations and discussions in the past, but I'm going to do it anyway.

Time is precious and easily chewed away.

Alex: [Laughter] That's good.

Chris: Anything and everything is a threat to the amount of time you have in a day. We've learned this six ways to Sunday.

We're at an interesting spot and we don't hire for this either, but there's nobody at CodePen at the moment that isn't a parent anymore, so that's interesting. You learn through that a little bit, like how much just your regular life can just such away things, but that's not even what I'm talking about necessarily.

I am talking about just product choices and what you're choosing to work on and how you plan your day and plan your time and plan your team and plan your sprints and all that stuff. Any decision that you've made can chew it away. Even if you've managed to have a pretty straight ship and we like, "We're working on this right now," there are constantly enemies, constantly little things that threaten to just suck away your time.

Alex: All the time.

Chris: Especially when you're in a position like Alex where it's just CTO and in charge a lot of the technological stuff, and those things just straight up take hours of time. A whole day, all the time from Alex, can just [explosion], it's gone.

Alex: Yeah. Yeah, I'm CTO/tech support.

Chris: [Laughter]

00:40:41

Alex: Like someone's dev environment is bugging out. Like yesterday, we decided to sort all our JavaScript imports with this Prettier extension, which is great. It's nice to have these things, and you wouldn't think it'd cause one problem. You're like, "I'm just sorting the same imports we have. No difference."

Chris: Yeah.

Alex: Even today, I'm still trying to suss out one last little issue with that, so it ate up like 2.5 hours of my day just with debugging, sorting, and all kinds of little things.

Chris: Everything. That's a great example, though.

Alex: Yeah. I thought it was completely benign.

Chris: It wasn't quite on the roadmap. It was just kind of a nice to have. Yeah, it's part of the JavaScript spec, as far as I know, that imports don't need to be ordered in some particular way, but that's probably not what the bug is. It's probably got -- the code got chewed up in some way that you didn't expect - or whatever.

Then boom, your time is gone. Then what's more interesting isn't that--

it's still cool that that's going to get done. But it's more interesting what didn't happen then.

Alex: Right.

Chris: What didn't happen is our ability to push the product forward in other ways, and that's the crucial stuff.

So, how do you fix it? You go to battle for the rest of your fricken' life against that kind of thing.

We've made bigger decisions like, "Oh, we don't have meet-ups anymore." Well, honestly, part of that was that it chewed away time a little bit.

Alex: Yeah.

Chris: It's just not fundamental to what we're doing. We don't self-manage our merch anymore. We got rid of posts as a thing because it wasn't used that much and was causing some technical debt issues.

We fight technical debt. Alex already talked about his tech minimalism thing. That's related in a way, too, because you can get chewed up for time if you're spending a bunch of time on some technology that you don't know that much.

This is broad, but it's broad on purpose. This idea of protecting your time has many enemies.

Alex: So many enemies. Yeah, so many.

Chris: Technical debt being one of them. Recovering from your own bad ideas is, I guess, kind of like technical debt, but it can be more vague than just technology. Why don't we just leave it at that?

Alex: Yeah. Yeah, I think everyone can kind of agree on that one. Parent or not, you still find yourself strapped for time. Although, being a parent really eats up a lot of time, but it's kind of good if you like your kids, like all of us at CodePen do.

[Laughter]

Chris: Yeah.

Alex: Yeah, so -- yeah, I feel like...

Chris: Are you at your number one?

00:43:07

Alex: Yeah, I'm at my number one. Yeah. I feel like I should have a drumroll.

Chris: Oh... [drumroll].

Alex: This is something that it's a little odd, but it's something that I almost feel like it changed the direction of my career and my abilities, and so I feel so strongly about this. I would title it as do not poke.

There is a famous course at MIT. It's called Structure and Interpretation of Computer Programs (SICP), and there's a teacher there or author of that book and course. His name is Jerry Sussman.

He was talking about the idea of why they don't teach this course anymore at MIT. He's describing the idea that a lot of technology has started to become more like biology in that when you're studying biology, you kind of poke at biology.

Biology is so complex, and we're so far from having a complete understanding of biology to the point that we could recreate it that we kind of poke at biology. There are drugs that you are given, and it's not really understood why they work, but we know they do work because we've poked at the problem.

I read that little blurb about five or six years ago and realized that I had been poking at so many things. Right?

Chris: Hmm...

Alex: There were a lot of small problems in CodePen where I would see a result and I wouldn't dig into why it was happening, but I knew that I had kind of a solution, like, "Oh, there's bad data here, and the API gets some -- sometimes, we get a null, so just check for a null on the client. Don't figure out why the database has random inputs that we really didn't expect." [Laughter]

Chris: Hmm...

Alex: What's really frustrating about this idea of saying, "I will not poke at a problem," is it feels a bit like getting braces when you have really bad teeth.

When I was 16, 17, I got braces. I had really bad teeth, and it was horrific because I then had two big problems. [Laughter] One of them was I had braces and the other one was I still had bad teeth.

Chris: [Laughter]

Alex: It was really painful and hard to deal with. When you're starting your career and you want to solve problems very quickly, you can very often feel like everything takes you a lot of time. And you want to just poke at the problem, see if you can find a solution, get it out there, and feeling like you're moving on and being productive.

When I stopped doing that and I started trying to understand and recreate problems, and I started focusing on errors more, I started trying to say, "Well, not only am I going to stop poking and just trying to find a solution. Now I'm going to actually see how I can recreate more and more of these bugs."

It led me to an understanding that has allowed me to solve more and more problems faster and faster over time. That has been dramatic for me personally. It's been a dramatic change in what I can do.

Chris: Oh, that's your secret, huh?

Alex: Yeah, and my problems, I think there's a saying I've heard from military folks that slow is smooth, smooth is fast, and so it's a little bit of that vibe where when you're not poking at a problem, you're really trying to understand it. You have to slow down. Then eventually, that becomes to feel kind of smooth. Then all of a sudden, it seems like you're fast, but the only reason you're fast is because you slowed down to understand how to solve things.

And so, at the end of the day, we get paid to build and solve problems. No one really--

It doesn't matter how capable you are at task management if you can't build with the tools that we have and you can't build reliable solutions with what we have. And so, that for me, it was a huge inflection point.

I said I'm just going to stop. For whatever reason, that article resonated with me. And I stopped poking at problems, and it changed everything for me. And so, I--

Chris: That's interesting. You definitely have been against -- and I'm very guilty of, like, "Oh, there's some error or something," and you just immediately Stack Overflow stuff. You don't even Stack Overflow the top. You just scroll until you start seeing little snippets of stuff that you could start throwing at the problem.

Alex: Yeah.

Chris: That is not what you -- [laughter]. That is the exact opposite of what you're advocating.

00:48:02

Alex: That is the opposite. Yeah, I picked up a weird habit, which is, I will read a ton of source code of the projects that we build on. So, I browse GitHub source code the way some people browse Instagram. I just kind of randomly read code. I like to just--

And you get better at it. You get a lot better at reading other people's code. You get a lot better at understanding things. You end up picking up little tips and tricks.

When I can't solve a problem -- luckily we build on mostly open-source software -- I have the ability to dig into someone else's code that I didn't write and have a fundamental understanding of, like, why did this fail? Why did this thing fail?

One of the things we did recently was, just yesterday, we were deploying some integration tests. Those integration tests were using a domain called codepen.dev that we use internally on our computers.

Chris: Mm-hmm.

Alex: Yet, they were working on production. [Laughter] We were like, "Wait! What?! Why is this working?"

We own codepen.dev. We redirect codepen.dev to codepen.io, so even on the production CI system, our integration tests were running a Web browser running full integration tests with the browser. It was redirecting to codepen.dev, then going to codepen.io. It's the most subtle, insane thing.

Chris: [Laughter]

Alex: When Robert (who was running the integration tests) told me, "Oh, it works," I couldn't stand idly by and say, "Oh, it works. Sure. Let's just move on like it's fine."

Chris: Oh, it's the opposite of Stack Overflowing stuff. You won't even move on when something is working.

Alex: Absolutely not if I don't understand why.

Chris: [Laughter]

Alex: If it should have been failing and it does work, that is still a failure.

Chris: That's the bug.

Alex: That is a bug. I know it's a positive bug, but it is a bug. And so, I had to stop and think, "Okay. You're hitting codepen.dev." He goes, "It's redirecting." I was like, "Oh, okay. Yes."

Everything became clear, but it's important to even know when something works and you don't understand why. And so, if I could give anyone advice, it's like, "Hey, slow down. I know it's frustrating. I know you want to feel super-productive. Slow down. Do your work slowly but methodically because you build on this knowledge. Two years from now, you will be so happy."

The same way as if you got braces. Three years from now, when you have no braces, you will feel amazing. You will be so happy that you slowed down three years ago, four years ago. So, just start doing that now.

For me, it changed everything, and I felt infinitely more capable than I was before I had that concept.

Chris: That's nice. That's Alex's cheat code.

Alex: My number one.

Chris: Smooth as--

Let's do it again.

Alex: Slow is smooth. Smooth is fast.

Chris: Slow is smooth. Smooth is fast. [Laughter] It's like a mathematical proof that shouldn't work but it does.

Alex: All right. What's your number one?

00:51:20

Chris: Well, that's nice because while you ended with kind of a personal cheat code, in a way -- well, that's not a cheat code. You had to work really hard for it, so it's not like you're jumping ahead, but it was definitely a little bit of a recipe for success, and that's how I'm going to end mine, too, with a couple, a grab bag of things that I consider in the category of cheat codes for building a software company - in a way.

One of them is just really personal to me. It's like if you -- even if you're listening to this show or you know who I am or CodePen is, there's a good chance that it was rooted historically in the idea of the fact that I used to -- I used to and do -- [laughter] I used to do drugs. I still do, but I used to, too.

Alex: [Laughter]

Chris: I used to write a lot about everything. I just write - write, write, write. And content creation, like this podcast, too.

There is a decent chance that you heard of and used CodePen not only because that it's a good product (and that's our main focus) but because of writing that I did elsewhere. It's a cheat code for some level of success in the software industry is being able to write well for public consumption and create content for it. That's a cheat code.

Another one is persistence. I've always thought that, too. When I thought I had a good idea, I just never stopped doing it. Ten years is a big milestone for us. That represents persistence in creating something. We're still persistent about it because that--

It's not stubbornness. It's not sticking to an idea that somewhere in your head you think is bad or something. We adjust bad ideas to be good ideas. The persistence is sticking with an idea that you think is good until you see it through. That's just one of my grab bag of cheats is persistence.

The last one -- I just felt like we should end with some positivity -- is literally positivity. We've kind of founded CodePen's vibe on that a little bit. We celebrate people that do a good job. We find ways to elevate people's work. We find ways to welcome everybody and try to be proud for them of the cool things that they can do. That is just good vibes.

I think if there's success to be had in this type of industry, being positive about people and the work that they do is just going to work out nicely for you and I think is a part of the recipe of our success so far.

00:53:51

Alex: Yeah, I want to elaborate a tiny bit on two of those.

Chris: Mm-hmm.

Alex: The first one, 100%. I think a developer, designer, whatever you are that can communicate, that is the ultimate superpower, and I think it's one of your superpowers is your ability to write and communicate. Very personally jealous of your ability to bang out writing and communicate.

Chris: [Laughter]

Alex: It's huge. And then second of all, about the persistence. I still remember, ten years ago, someone wrote into us and sent us an email and said, "Why should I put my stuff on CodePen? How do I know you're not going to be gone tomorrow?"

I still remember that you wrote back, "Well, everything I've built, I've stuck with. I've been building CSS-Tricks for a long time. And I can't guarantee you I'm going to be here, but I can guarantee you that I'm going to try to be here."

Everything I've built, I've stuck with. And even to this day, we're still building out CodePen. We're still working on it. We're still improving it.

That was really interesting because, ten years on, whoever wrote into that, if they stuck with us, their stuff still works. Their stuff is still on CodePen.

00:55:00

Chris: We should find that email. That'd be interesting.

Alex: Yeah.

Chris: We should dig that up. I remember that, too. I remember that because you can't promise. I can't.

Remember Team America?

[Laughter]

Chris: That South Park movie, he's trying to sleep with a girl - or whatever. It was a joke scene, and he's like, "I promise I will never die."

Alex: [Laughter]

Chris: It's hilarious.

Alex: Yeah. Just a little bit of that.

Chris: Yeah. It wasn't bravado though. It was like, I can't. I mean how can I zoom to the future and tell you? But I can tell you that the reason we started CodePen is because I didn't trust the competitors, hilariously. I didn't want to put my stuff on their platforms because I wasn't sure they'd be around.

But you know who I can trust to be around? Me. So, that's what I'm going to do.

Alex: Yeah. Yeah, and we've stuck with it ever since, and we bend over backwards trying to make sure that stuff still works.

Chris: Yeah. And you know what? Why don't I end it on a fricken' rainy day instead?

If this were to implode -- we've even talked about this during dark times -- we're not going to wreck your content. That we'd never do. Even if we had to give up on CodePen, just something really horrible would happen, which I promise it won't, even then we would protect your content.

Alex: Yeah, it actually means quite a bit to us that you spend your time and share the links internally, externally, whatever it is, what work you have. That is protecting all that content, saving it, backing it up is a key.

I call that the cardinal sin. You cannot lose anyone's data. You cannot 404 their links. That matters very much to us.

Chris: Right. Yep. Never done it. Never gonna.

Alex: Nope.

Chris: All right. Well, that was fun. I guess I could say I'm not 1000% shocked by yours, but you articulated them quite nicely, and I haven't heard them said quite in that way yet, so that'll be cool to write down. I think that's what I'll do is I'll take our time putting the show notes for this one together and make it more like a blog post so that you can read down through ours, alternating like we did them on the show, and attribute them to us, and just put a little text of one last opportunity for us to articulate ourselves on what those ones were.

Alex had cool names for them.

Alex: Yeah. It'll be awesome that you can learn in 30 seconds what we've learned in ten years, so it's really cool.

Chris: Yeah.

[Laughter]

Alex: It's really efficient time spent on that blog post for you if you want to read it.

Chris: All the next startups, they're going to shoot right past us because they didn't have to learn.

Alex: [Laughter] Yeah, they didn't waste ten years doing two things at a time [laughter] or three, God forbid.

Chris: Yeah.

Alex: You realize you should do one.

Chris: All right, man. Here's to another ten years. It won't be that long, but you know.

Alex: [Laughter]

Chris: Here's to the next phase of our existence.

Alex: Yeah. All right, everybody. Thanks for listening.

Chris: Yeah. See ya.

Alex: Bye.

[Radio channel adjustment]