Jerod Santo: What I’ve realized over the years - I didn’t realize this as a young person - is how communication is like the… I won’t call it the trump card, just because that word has been sullied in the minds… But it’s a cross-referential – it’s like just the best skill that helps in every niche, every area of the stack, every business… And if you add that to whatever you’re doing, you are ahead of the game, or you’re ahead of where you were for sure. That’s a skill you want to stack. And it moves with you.

[00:27:57.27] In software, one of our problems is we invest in skills that become irrelevant. And that’s a real challenge. I mean, it’s not something to be taken lightly, and it’s a difficult thing to see what’s coming next, and to be at least well-versed in it, if not competent, if not excellent at it… And not wasting a bunch of time on something that’s going to go away, like your Cordova book that you wrote and your company decided “No more Cordova.” That’s kind of just like a sunk cost at that point, unless you’re gonna take your skills elsewhere… And that’s been a real challenge, and one of the reasons why we exist even, and why I got involved in the Changelog back in the day, was just trying to stay relevant, know what’s going on, keep up with the trends… Do you have advice for new developers on that front, like how to invest in things that are going to last, or how to float above that area where you can become, like, “I spent six years becoming the best jQuery developer in the world, and now everybody wants to React.” I mean, even that’s a David reference, but… You know? That happened; it’s happened to all of us. And you’ve lasted a long time in this industry, Dan.

John K. Thompson: Yeah, and thanks for the opportunity. As you said, this is my third book. I’ve written mostly about analytics up to this point - how to build a team, how to invest in a team, who to hire, who not to hire, how to structure it, and all that kind of stuff… But I started my career 37 years ago, and I was a programmer, and an analyst, and everything I did just seemed to revolve around data. It was just all data, data, data, all the time. So it just struck me that data was the thing. And I switched my career to be part of the business intelligence, and data warehousing fields… And I did that for decades, and I’ve been thinking about it for a long time.

[04:18] When we were raising our two kids, that are 25 and 23 now, we were always talking to them about “Hey, how’s that game going? What are you doing?” They’re “Oh, it’s free. We love it.” And it’s “No, it’s not free. You’re giving them your information about who you are, and your age, and your behavior, and what your elasticity is, and what your tolerance is for trading this and trading that, and what the price is…” So we’ve always had this conversation over our dinner table about “There’s no free thing. If you think it’s free, then you are the product… Your behavior. You are what they’re selling.”

So I’ve been thinking about it for a long time, and I’ve been part of the data industry for almost four decades, as I said, and a lot of it - Daniel, I know you’re here in the Midwest, I’m in Chicago, you’re in Indianapolis… Chris, I think you’re somewhere in the United States…

Craig Wiley: [24:08] It’s a really good question, and it’s one that we spend a lot of time thinking about and working with companies on how they’re thinking about this problem. The companies who I’ve been most impressed when I hear their strategy around these things - it really comes down to where they choose to buy, versus build. And from that perspective, one of the things that I think deeply about, and that I think others do as well, is this idea that if you can buy a solution, whether it’s a Contact Center AI - our intelligent virtual assistant or contact agent in your call center - or our document understanding, these technologies that are powered by AI, these make a ton of sense for companies to buy, because for most folks your contact center isn’t the primary point of differentiation for you.

Now, as you move further down the stack, I think the question becomes “Where are you comfortable using AI to accelerate your business and gain efficiencies in your business? And where are those efficiencies tied to your competitive advantage as a company?”

Fundamentally, the idea of buying your AI makes a ton of sense if it’s something that you’re very comfortable with your competitor buying as well. But when it comes to what you should build, it really comes down to “Where are the unique areas that you think you could express some differentiation in that industry?”

So if I take retail as an example, we’ll see retailers who are happy to buy a recommendations system, but they wanna optimize the back-end and their supply chain deeply, because that’s how they believe they can stand out. Or maybe they wanna highly optimize their promotional capabilities, or their forecasting capabilities… Whereas others may say “Listen, forecasting and supply chain - I’m happy to work with a partner and get the best-in-class, that is easily available to me… But I really wanna stand out on our usability or our recommendations, and things of that nature. That’s how I plan on setting us apart from others.”

I think that’s a conversation that companies have been having for a long time with regards to the software they’re building. If I think over the last decade of the number of industries where the leader in that industry has almost become a hybrid software company - whether it’s a retailer who’s become more or less a software company, or a healthcare provider who has a giant software investment… You know, the same decisions that have powered that kind of investment over the last decade, I think now we’re seeing that same set of decisions behind applied to how they’ll invest in intelligent computing, and where they’ll choose to build versus buy.

I’m not seeing kind of a wholesale, like hey, people are giving up Notebooks and are only gonna go buy from now on, or vice-versa. It’s really around how companies will choose where they are willing to build, versus where they’re willing to buy, and how that aligns to their strategy.

Johnny Boursiquot: That’s huge, yeah. Awesome. So we’ve been talking about the technical pros and cons, some of the challenges, some of the things that you need to watch out for… I feel like we’ve been more sort of telling our cautionary tale than anything else. I think we all agree on the panel here that serverless - I’ll use that term because I can’t think of a better term; it’s a marketing term, but I can’t think of a better one to encompass all the things that make up serverless… But we know in general that it’s a good thing. It gives more options, more ways to build the right abstraction into your infrastructure, into your world, whatever business problems you’re solving… But from an opportunity standpoint, for Go developers, what is the draw? Why should I invest time in learning how to do serverless?

Perhaps you work somewhere where the only provider you’re allowed to use is GCP, or maybe it’s only AWS; why should you spend time learning any one vendors? Or even if you wanna go cross-vendor, why would you wanna invest time and effort into learning the right way to do serverless? Because it’s not just about the syntax, it’s not just about the code; it requires a different way of thinking. It requires you to learn a bit more about building these kinds of distributed systems. Why as a Go developer would I want to invest this time?

Bartlomiej Płotka: Yeah, totally. It’s kind of an everyday question almost, if we should invest in some amazing feature… And especially deletion is an interesting one, because we usually - at least in our ecosystem of like Prometheus, and the Thanos project, as well as Mimir, and Cortex, and Flare even… You know, all those kind of like distributed systems - or not distributed; like time-series database, or sort of kind of like storages for different observability data, we kind of store it in immutable storage. So once you kind of like try to delete something, it can cause problems, and it can cause costs. So that’s kind of like the question - when we should add, how much of the flexibility in deletion we should add, and sort of those stories. It really, really depends, and what really helps is to have this budget of how much cost you want to kind of add to the system… Even like developing a feature is a cost; spending engineering time, and testing, and maintaining it.

I really kind of try to recommend into using the same pattern for discussing how much you want to invest in efficiency of something, if we should make it faster or not, or we should maybe disable some feature because it was kind of slowing the system… This is exactly the same discussion as you would have should you add some feature, because again, it’s just worth thinking about efficiency. Again it’s still kind of some cost; it will be some cost of like maintaining, and so on. So everything, ideally - ideally, in an ideal world, you know the cost of it, so you know if deletion is… How much deletion requests will cost, kind of roughly CPU time, and if you have the capacity in your cluster. So this should be kind of like the core discussion to have, and if users are willing to pay for that, sure. But if, for example, you want to kind of minimize the cost, maybe you should disable this feature. It really depends on what user you are in, and what project this is in… But generally - yeah, speaking about data, numbers is kind of helpful. And treating everything as the whole package. Not just features as readability, and maybe complexity of the code, or API, or configuration, but also add efficiency on top, like roughly the cost, essentially - it just helps to make the decision.

Nora Jones: It’s a good question. It all depends on how much you want to invest in it. We strive to make the tool itself really self-serve, so you don’t need that. We’re trying to guide you through – within the application itself, it doesn’t assume that you’ve ever done any sort of incident analysis before. It kind of assumes that you have probably just written something up like in a Google Doc, or you haven’t really thought about this space as much. So we really aim to make the tool self-serve. However, we do have a few customers that are really invested in getting good at this, and those are customers that are actually hiring full-time incident analysts… Whereas some organizations, they’ll just have people do it as part of their job, and they’re an SRE, they’re software engineer. So I think with those organizations - yeah, they’re really trying to build it up and really trying to make it a thing, but it doesn’t necessarily need a human guide. It needs champions for sure.

Alice Merrick: Yeah. And feel free to skip them. No question on the survey is mandatory. If you don’t wanna respond to a question but you still wanna give us some data, answer the 5 or 10 questions you wanna answer, and that’s better than not participating at all. So you can determine how much you want to invest in it. If you wanna answer everything in perfect detail, and go through everything very slowly, you can. But you can also just fill out a couple of pages and be like, “Yeah, I’m done.”

Carlisia Thompson: Talking about beginners and teaching, I have a question for Todd that’s more generic. I would like to know your opinion about whether kids should learn how to program early on? I will volunteer my opinion - I say usually kids should not be spending time programming early on. Maybe when they are early teens they could start learning, because I think kids should invest time in learning especially how to write. There is so much reasoning and logic that goes into writing, and programming is so much about reasoning and logic, and writing is so important for so many aspects of our lives, that I think you have to make time for programming and you have to cut time from somewhere.

I’d much rather have kids spending extra time in writing, rather than programming. When they get to a point where they can assimilate things at a faster rate, which will be when they are older, they can pick up programming really quickly. People think that they need to get kids into programming early because it takes so long to learn programming - I don’t agree with that. I think when you’re ready, you learn fast. So what’s your opinion on that? When your students come into your class, do they have a background in programming, do they start early? Do you see there is a difference? Who is better prepared to learn as far as you can tell?

Kevin Ball: I’m going to challenge your premise a little bit on this. This is just pushing a little bit here, which is - let’s take the example of component-driven development. Component-driven development - the industry has pretty much normalized on that is the most productive way to do UI development. You break things down into components, you subdivide them in that way, and you do that. And there are a slew of different frameworks that allow you to do this in different ways, but the sort of raw platform in JavaScript does not have a good solution for this. Web Components are *beep*. They’re terrible. They’re not a valuable way to do this, because one of the key productivity boosts of this component-driven development is thinking about your UI in a declarative manner. And Web Components, for reasons that I do not understand, chose to maintain an imperative programming model.

So where I’m going to this is - if you invest time and energy in learning how to do component-driven development using one of these declarative frameworks, whether it is React, whether it is Vue, whether it is Angular, whether it is Lit, whether it is one of these other things, abstractions on top of the platform, that understanding, that model - while the framework details will vary, and that piece is not as portable, the mental model for how you do that development and do that breakdown is, and it is something that is going to be more valuable to you in moving from project to project, than if you had tried to do everything from scratch without that mental model.

Adam Stacoviak: That means revenue was in place potentially… So you really were able to, I guess, navigate this acquisition, this acquihire, knowing that – I’m sure you got some sort of payout yourself as part of it, but then also the next thing in, to continue to be able to invest in Elixir - I can imagine how that would make you feel pretty secure about your next steps.

Birk Jernström: Yeah, yeah. So for all of the maintainers out there, I think the key thing is – I’ve spoken to hundreds of different companies as well, of how we can get more companies to invest in open source. I’m very bullish, and we can get into that as well, but… I believe that the route to open source sustainability for individual maintainers is to look at all of the things that they’re doing beyond the free code that they’re giving, that is value-adds that they’re already giving today, such as support, issues that they’re crushing, to like Discords that they’re creating and managing… And that’s where I think you can take a step back and think about how can you package this in an offering where you can actually get people to sponsor you to get these additional benefits, to also benefit you as well.

So I would start small. Like, sign up to Polar, start using issue funding. If that floats your boat, start using donations and sponsorship. But I would encourage you to start offering some membership benefits. And we’ve designed them to make them really compelling without breaking the principles of open source in the sense that you can have paid memberships, where you can offer premium posts, premium content and insights to what you’re building, and your projects, and your progress, what have you. We can also set it up to be early access, so that automatically those newsletters become publicly available after, say, a week.

And so if you’re offering a Discord today, and you’re writing some updates, set that up as a tier where you’re giving early access to those updates, create some roles on Discord where there might be a channel where those people that are sponsoring you, you can chat with them and maybe pick their brains earlier, and so forth. Just give those types of benefits. Because the truth is – the paradox of open source is that it’s immensely valuable, but the value is also in commoditizing the value. And it’s really hard to get money from something that has been offered for free. But recognize that you’re giving a lot more on top, and experiment with Polar, how you can capture that into more funding with our tools, while still being in the best interest of your community, without completely going proprietary, of course. Striking that balance.

The other audience - who was that? That was like people who wanted to contribute, and more on like the backer side.

Scott Johnston: And in doing so, we think that it is both growing the developer community because there’s more and more devs coming into this market… 27 million devs, going to 45 million by the end of this decade… And what we see is - and you’ve referenced it at the top of call, Adam… Docker can be pretty complex, and we see that are our responsibility is to keep lowering the friction for new developers coming into the market, to get up to speed, onboard, and be productive. And that’s first and foremost to grow the community. And then if a subset of them come down and say, “Hey, I need those management features and security features”, great. But first and foremost, it starts with growing the community.

A specific recent example - in the last couple of releases we’ve launched something called Docker Init, which very deliberately patterns off of other XYZ inits out there in the developer world, where you point it at a directory… Say you’re a Python developer, you point it at your directory, do Docker init in that directory, and we automatically generate the .dockerignore, automatically generate the Docker file, automatically generate the Docker Compose file. And those - because we’ve heard from the community that “Hey, I’m getting my head around Dockerfile”, or “Hey, I’m getting my head around Docker Compose. That’s a high bar for me to get on-boarded.” So we’re like “Okay, let’s provide some automation tools.” And what I’ve just shared with you, Adam, is 100% kind of free. It’s just like “Hey, help get up to speed.”

So that’s an example of how the commercialization has allowed us to invest in developer-facing value that is first and foremost about growing that developer community, helping them onboard, helping simplify their experience… That is first and foremost how our business works, and then again, if they go and work for an organization, that organization needs security, manageability and observability, then there’s a paid-for a set of features for them as well.

Rachel Potvin: Yeah, great question. I feel like this is a podcast unto itself at some point, if we ever wanted to do that, because there’s so many things… And it’s overlapping with culture, as is everything; that’s going to be my answer for everything today too, but… An example where it overlaps with culture is like code review. I love the culture of prioritizing code review above your own work, right? It’s not always feasible. I’ve definitely had problematic situations where a poor engineer in Europe woke up with so many code reviews in their inbox, because all of the Americans, right before signing out, were like “Oh, he’ll be up soon”, and then that person would just be drowning in code review.

But in general, having code owners, and the ability to affect large-scale codebase evolution requires people doing effective code review. And a failure mode I’ve seen is where – you know, I had another principal engineer who was reporting to me at GitHub, who made a pretty simple change into – basically, to keep it simple, the way Go worked at GitHub. And so basically, everyone writing Go code at GitHub had to review his simple code review. And that should be fast and easy, right? But it wasn’t. I needed to get involved to escalate for teams outside of my area to say “Hey, after a month, you still haven’t prioritized this code review. You need to do it so that we can roll out this change.”

And so really having good code review tools… Again, we talked about design review - very important. And then developer experience, and like at what scale are you going to start thinking more about your developer experience is really important from a code health perspective. I’d love to tell you a little story about deployment at GitHub, because it really resonates with many of the startups that I’ve spoken to recently… GitHub got into trouble with its deployment strategy, and is on the right track now, thankfully, but it’s a surprisingly common story to see that in developer experience build and test times get longer, and there’s test suites running that don’t need to run, and so on… But like deployment is a particularly painful one, and I would say there are like three areas where it really hurt at GitHub. One was just the volume of changes got too high; too many people wanting to deploy. And so there, if we’re only considering GitHub’s primary deploy target, which is github.com, just the number of different people wanting to deploy changes on this fairly manual process that required human engagement, started creating friction.

GitHub has this kind of unusual “deploy, then merge” strategy. So for code changes, you actually deploy your code first, check that everything’s working, and then merge back into the main branch, so that main is always available for rollbacks. It’s kind of an unusual strategy that I wouldn’t necessarily recommend, because it’s part of the scaling challenge… But GitHub moved to using deploy trains to help with that volume of changes, and this is still very manual though… A conductor, who would be the first person who got on the train, would be responsible for shepherding the change.

[01:13:53.09] And then there’d be all sorts of gamification that happened. I had a teammate who was like “Why am I always the conductor every time I want to roll out a change to the monolith?” And it’s like “Well, because everyone was hanging back, waiting for someone to take that role, and then you jumped on, and you were the sucker who every time –” Yeah. [laughter] And so this is a bad experience…

And, then I started hearing from people too, like “Well, I won’t even try to deploy something after lunch, because if I ended up being responsible for that - who knows? I’m gonna be stuck till after dinner, waiting around… So I’m just gonna wait till tomorrow.” And so you can see the sort of like aggregation of friction there, and how much that slows down development. It’s just not acceptable.

In DevSat - I mentioned the satisfaction survey - deployment came out as the highest friction. And then like all these other side effects that affect code health, like people writing bigger changes, code review becoming more difficult, changes being deployed become more risky… So an increasingly problematic situation. And that was just for .com.

And then - and this is a situation that happens at a lot of startups, too. github.com isn’t the only deploy target for GitHub. There’s GitHub Enterprise Server, which is an enterprise-focused product, where customers deploy GitHub Enterprise Server on-prem. And for them to do upgrades, they require downtime, right? And so the way this worked was they replay all the database changes, update the code… But database changes are unpredictable timing-wise. I already talked about how way too many database changes happen at GitHub because of partly active record, and sort of the way the monolith is sort of like not well componentized across the data layer… And so then GitHub Enterprise Server’s customers started having an unpredictable amount of downtime for their upgrades, which is a problem.

Also, most of the GitHub engineering teams were really focused on .com. So “I got my feature out to .com. I’m done. The ops team can deal with whatever.” So then this poor ops team is managing the upgrades for Apple, and IBM, and all these big customers, but also lots of small customers… Debugging becomes more difficult because “Is your feature in the enterprise server deployment, or is it not?” There’s a whole challenge with feature flags. We did a really fantastic tech debt cleanup actually around feature flags, where there have been so many feature flags at GitHub that were on permanently, or never been turned on, or on in the worst case scenarios that are like different configurations for different enterprise customers… And so that became problematic as well.

And then the third piece to the deployment puzzle at GitHub, which was really enough to say “Stop. We’ve gotta really invest in how we do deployment” was on-prem enterprise product is not the state of the art; it’s not where most companies want to be, and so GitHub really had to develop a cloud SaaS offering for enterprise customers. And this is something GitHub has been working on for years. There’s a lot of pressure on it. Obviously, downtime for upgrades in a multi-tenant SaaS product is not a thing, right? And so there has to be a way to propagate deployment to that endpoint in a healthy way as well.

There was lots of pressure from leadership to get this product out the door quickly, and so GitHub did try to take shortcuts, tried various strategies to replay changes from .com to the cloud, and never could work, never could scale. Especially the frequency and unpredictability of the time required for database changes just made that untenable; like, how do you interleave code changes and database changes with the right timing, with the right lead time? The enterprise product would always end up getting so far behind that it could never catch up to .com. So that just wasn’t working.

Abi Noda: [01:26:19.14] A couple of things I would say. One is that I just empathize with anyone in that role. It’s hard right now, and we take it upon ourselves personally to try to solve this problem; that team of one out there, that’s kind of on an island and it’s sinking, it feels like it’s sinking… Especially right now, with the economy, and people getting laid off. We’ve seen a lot of DevEx teams get laid off, or reduced. It’s been tough at times. And so what we’re trying to do - and this probably also exists outside of what we’re trying to do… My advice would be you need evidence. Speaking from my own personal experience, it’s hard if you’re on an island to make the case for developer experience, and you’re going to be – you need weapons. You need some artillery, and things like our paper. Things that really put credibility to this as a discipline, for one. But another thing we’re working on is - people don’t realize the top companies like Google do this. We’re trying to make that more visible.

Then there’s the FOMO factor, like “Hey, Google does it.” That’s usually enough for the tech industry to take new practices on, “Hey, Google does it” or “Spotify, does it. Netflix does it.” Third is more – not just “Hey, they do it”, but market insights on this. We have a lot of data we’re gonna try to start sharing around how much do companies invest in this. It’s a lot. There’s a lot of headcount at mature organizations going into developer productivity. And so if you’re a team have wine, it should be easy for you to say, “Hey, look, all these other companies - this is what they’re investing; you’re investing one. Not even one, because this ship is sinking right now.” “Hey, look, this is what we should be doing if we want to be able to ship software as fast. If we don’t do this, we’ll just get slow.” But if you want to be fast, this is what it takes.

The other thing I would say is that a lot of these folks we talk to have tried a Google form, and they’ve had not a great experience. They didn’t get good data from it. They didn’t get a good participation rate. It fizzled. They’re not even typically doing it anymore. I mean, I’ve heard crazy stories. I’ve heard people tell me “I walked around the office with an iPad, begging people, handing out candy to fill out the survey, and got 30% participation.”

So just don’t let your prior experience with surveys taint your hope and optimism around what they can offer, because I think there’s a lot more to surveys – like we talked about earlier, all the science… There’s a lot more than meets the eye, and a lot of people kind of write surveys off based on a single experience that wasn’t really representative of what’s possible.

Liana Leahy: Sure. I mean, it’s a tough and challenging gig. There’s a lot to do. You need to understand your industry and your company, and you need to know your users. I mean, that’s number one - who are your users? And if you’re in a company that makes software for everyone, like Facebook, it gets a little harder. I worked at the MBTA for a while, which everyone rides the T so who is your user? Getting to really understand the jobs to be done is one of the frameworks that we use… Like, “What is it that the user is trying to do? What are they trying to accomplish with your product?” and understanding that need and that niche that you’re trying to fill with your product - super-important.

Also, as a PM, you’re aligning stakeholders around the vision, so you have to have a real good picture in your mind and be able to communicate that picture of what you’re building, and not just that feature, but the overall, like “In a year from now, what is this product gonna do and be? What is the strategic direction of what it is that you’re building?” And how is that gonna help your company? Why should they invest in building this product? How is that going to help the company move their needles?

And then you’re prioritizing what you need to build. So you’ve got like a list of features that you know that you need, that’s on your roadmap… But when does this fit in? How do I put that all together? And then you’re rallying the team around all of that work.

[12:10] You’re prioritizing the product features, capabilities… And then in a lot cases, some product managers depend on the organization, but you’re helping to deliver that feature. So being that person that can help remove roadblocks, get people the answer to questions that they need… Really championing the team and letting them focus on the development work, while you’re chasing down answering their questions about the feature from commercial teams or operational teams of the business.

Chris Benson: [12:07] That begs the follow-up - if you’re in a company that is wanting to move… You may have dabbled in deep learning, but there’s so many organizations out there that are still not fully in, they’re not at a mature level, they’re exploring it still, and they’re trying to understand how to be productive without wasting lots of money and focus on that. So how should a company be thinking strategically? So not just the practitioner who’s doing the labeling themselves, but if you’re leadership and you’re wanting to invest in workflow and in infrastructure to support it, how should you be thinking about that in terms of what your company is trying to achieve, so that you get the best out of your practitioners when you have them go in and actually do the thing?

Adam Stacoviak: [15:56] So there’s a significant investment that you’re putting into people, right? You’ve seen the model be wrong, so you’ve defined a new model; you assumed this model could be right, and it requires some capital to make it happen. You described how your economics are, that if you get a couple people to pay upfront – and I’m sure the way you accept classes and build out classes is based on “Well, we have to have four, or five, or X pay upfront. The remaining amount can be pay zero” and we can define that model, which we haven’t done yet, but… It seems kind of interesting how you’ve done that, because you’ve got to invest in people, and that means you have to have the right people in place. So this prerequisite - has that always been there, or did you sort of like stumble upon it and said “Wow, we really need to have a filtering mechanism… How do we do it? Here we go.”

Phillip Carter: Yeah. So it was kind of funny, because after we – basically, one of our major success metrics was “Well, how many users are using the new net?” We reached about 5 million, and that was sort of like a major benchmark, and we hit it. And I just had a conversation with my PM director, and I asked him “So what’s the next big thing? I mean, this was really ambitious, and we knocked it out of the park. What’s the next big one?” And he’s like “I don’t know.” And that was because he was switching jobs over into another department, offered a VP position at Microsoft. I’m like “Oh, that’s why you don’t know. Okay. Well, I guess maybe I’ll look around too”, because I really liked the team that I was on, but you know, you complete an ambitious arc and you’re like “Okay, well, let’s kind of look around what’s out there. Maybe there’s something new.”

There’s clearly a lot of interesting stuff going on in developer tools outside of programming languages… So like looking up stack, what are the things that are there? So I ended up talking with some folks at Honeycomb, just because I didn’t know anything about observability at all. But I was aware of Liz and Charity, and I was aware of like a general consensus among some of the .NET developers that I knew that Honeycomb was doing things the right way, or the better way, or whatever. I’m like “Okay, cool. Let’s explore. What’s the worst that can happen?” Like, it’s not for me? Alright, cool.

So I chatted with them, kind of did the whole interview loop… I really liked the people, and was kind of sold on some of the initial vision. Because Honeycomb - it came out before Open Telemetry, but it was still very, very early stages when Open Telemetry was formed. And Honeycomb as an observability tool is fundamentally different from the rest of the market. It has this ambitious goal of “We really want to help developers reshape fundamentally the way that they introspect their systems”, and this gets from super-high level, like how you do an analysis workflow… Instead of saying “Oh, I’m going to look at my logs, and then I’m going to go look at traces that correspond to that, and see if I can find a match…” And like “Oh, I have this metric that says it’s up. Alright, cool. Are there any logs that relate to this time range, or something?” Kind of a broken debugging flow compared to what we do. And that kind of attracted me.

[00:28:08.25] But then at the same time, they’re like “Well, there’s also this whole other thing with Open Telemetry”, where regardless of our product shape or what we think people should be doing best, there’s this open standard that’s evolving, that is ambitious enough that people – it captures the majority of what people care about. And we have some pretty big customers, who are like - them continuing with Honeycomb is pretty contingent on us being quite deeply involved in the project.

So one of our larger customers, quite literally, in clear contract terms, was like “You need to be significantly involved here, because we’re taking a bet on standardizing on OTel, and we’re taking a bet on using Honeycomb across all of our teams. And I do not want one of those pillars to falter in some way. So I trust that you care about your business, but do you really care about OTel? Figure it out.” That’s what the role was scoped to, was “Okay, we’re going to take a bet on OTel. Great. We did it. Mission accomplished! But what is that bet? What are we doing, though? Where should we point our time, and our limited number of engineers we have? Should we hire for this? For how many? What are the most important things to invest in? What are the major problems that people have?” All the big stuff.

And I was just given the mandate to go and shape that into “Where do we point our force vector?” if you will, and “How do we keep doing that?” And then how do we start, a) trying to start skating where the puck is going, of like the project is evolving in this way… Can we make sure, at least at a very minimum, does the Honeycomb product not get destroyed by this thing in some way? We don’t want to be caught by surprise, in some capacity. But then also, b) okay, well, we do have a perspective here. How much of our perspective on observability aligns with the overall perspective of Open Telemetry? How do we make these things come together in a way that fits very well, and works for everyone involved? And how do we ultimately demonstrate that we are leaders in the project, instead of just consumers of this open standard? That was the main thing. And that’s what I did for about 3 years or so.

And being a startup, I kind of had my hands in all kinds of different places, but I was always very fundamentally rooted in being an Open Telemetry maintainer, which I’ve been since - -gosh, I think like the end of 2021… And trying to fix all kinds of problems that like “Oh, someone’s trying to use Open Telemetry plus Honeycomb, plus this language, plus this environment that they want to run in. It falls over in this way. Okay, great. Is that a legitimate bug? Is that a documentation problem? Is that like they wanted to use an API in this way and they couldn’t figure it out, and we need to add a more convenient API to something to just make it more obvious for someone how they accomplish something?” Just multitudes of that kind of work over the course of the years, and just being much more involved in the project and trying to shape what are the things that we try to make good in this big open standard that none of us have the time to really work 100% on all the time. And yeah, I don’t know… Kind of [unintelligible 00:31:10.17] stuff, but did that. Still doing that, frankly.

Kris Brandow: [00:32:16.06] I actually kind of feel the opposite. I think Go is potentially going to be the first language that undefines backwards incompatibility. That makes it so that backwards incompatibility is not a thing at all. I think there is a very good opportunity for Go to do this with the way it’s set itself up so far, if the Go team decides to invest in a few more tools. Go has pretty much already jettisoned the entire idea. I mean, it was never really an idea that Go version 2 would ever be a thing… It was just a name to give to kind of next gen features. And with the way that modules work now, where the version in the module dictates what feature set you’re going to use, it is possible to change the language in the future in ways that would be backwards incompatible in another language, but continue being compatible because the compiler can switch out its tool chain at will.

So yeah, you can still compile that old code using your current Go command. It’s just going to go grab a different tool chain and compile the code with that. And I guess technically you could say that’s backward-incompatible or backward breaking change… But for the consumer, it doesn’t really feel that way at all. And there’s a small effort to take some of the ideas from Go’s distant past with Go fix, and with this tool called Eg or Example, to actually be able to rewrite code for you, so if you do make a backward breaking change, the code will just be rewritten automatically to the new thing… Which I think also really reduces the amount of like “What is a backward breaking change?” If you just build that into the compiler as well, and the compiler can just do this for you automatically, then it can just look at the context of “What is this module code written in? Oh, it’s this version, and we have this other version. I know how to map these two versions together, so I can just automatically translate it.” And you just reduce or remove almost all of the backwards incompatibility things that you might come up with.

And I think if you add that with the ability to do the v2 modules, you really just remove the need to ever create something like Go 2. Like, I don’t know what would be in Go 2 that would be something we can’t use the current tools or some of the upcoming tools to remediate.

Tom Occhino: [00:15:52.22] There is a business there, yeah. It’s very interesting, the contrast. One of the things I’ve loved about being at Vercel versus Facebook was Facebook had a business that was over there, that was funding everything that we needed to do, and it was enough for us to make our own engineers more efficient, to level up the quality of our applications… But we didn’t really have to concern ourselves with how other companies are adopting our technologies. So that means that, you know, we collaborate, we build an open-source community, we benefit from recruiting, and thought leadership, and all these things… But there was no sort of like “On the balance sheet, here’s the value that we derive.” And I think being able to invest in open-source technologies from the angle of “There’s kind of a business that’s funding the open-source development, but I’m more directly connected to the customers” has been a really enlightening and great experience. We now can talk about business outcomes for our customers, and how the sort of frameworks and the technologies that we built led to those business outcomes.

But one of the things that both companies kind of have in common is Facebook famously said “We don’t build services to make money, we make money so we can keep building better services.” And Vercel is kind of the same way now with open source investment. We don’t build Next.js to make money; we have a business that makes money, so that we can keep funding Next.js development. And I like being more directly connected to the customers, and seeing the ways that our framework improvements enable them to achieve better business outcomes, which is a much more direct link than I had at Facebook.

Quincy Larson: Yeah, well, if you compare freeCodeCamp to an organization like Harvard - 400 years of history, the oldest university in the United States; an endowment of maybe like 100 billion… At least 60 billion, I think, last time I checked. That’s a lot of money that they have, that they can draw from to do different initiatives, to invest in research, things like that. And if you look at what they’re trying to accomplish, first of all, they’re trying to bring people from all over the world, they have to deal with immigration offices, and all these different countries… They are also trying to house those people, feed those people, maintain partnerships with the vendors on the campus, keep the gym equipment up to date, manage sports programs, interface with all different kinds of regulatory bodies… They have this very structured kind of traditional university system that dates back hundreds of years, where professors go from adjuncts, or postdocs, to associate professors, and then full professors, and gradually get tenure… And for every professor, they usually have an administrator or two as well, who’s running various programs… They have a lot they need to comply with. Curriculum is just one of many, many things that they think about. freeCodeCamp is all we think about. We’re a community that has a giant curriculum, and then we have lots of extra curriculum resources, and stuff like that. But it’s really just the core gameplay loop of come into the community, learn a whole bunch, then turn around and start contributing as an open source contributor to the codebase, or start creating courses that we publish on the YouTube channel, or start writing articles, writing full-length books that we publish on the freeCodeCamp publication… That’s kind of – because all we’re focused on is just this one specific thing, and we don’t have any of that stuff. We don’t have an office, we don’t have a football team… We don’t have any of that stuff. But we can just focus on this core thing. But it turns out, what a lot of people actually care about when they go to a university is not whether there’s going to be a really nice, lazy river around the dormitory facilities, or something like that, right? It’s not whether like “How many climbing walls do they have?”, you know? It’s not those kinds of things. It’s “What am I going to learn, and how am I going to use that to get a job?”

So to some extent, we kind of distilled the main thing that we thought was important and we just focused on that, and eschewed all the other stuff. And we have that luxury because we’re not a 400-year-old institution with all these existing obligations, and all these perceptions, and stuff like that. We’re a 10-year-old charity, that just kind of popped into being and just kind of grew. And I have a full institutional memory of every single decision that’s been made along the way, because I’ve been a part of it. So to some extent, because we don’t face all the constraints that a traditional institution faces, we can just go –

[01:18:25.24] So in lots of parts of the world, they didn’t have very good phone infrastructure. They didn’t have lots of ground line… And it was a big deal. Even in rural America today, a lot of people don’t necessarily have good phone lines, and stuff. But cell phones came out, and kind of leapfrogged that, and now people just use cell phones. And then similar things with fiber optic cable, the little satellites, and now you can kind of leapfrog that, to an extent. So I view freeCodeCamp as kind of we leapfrogged 400 years of innovation, and stuff, and we were able to look at what everybody was doing and just choose what we thought worked, and focus on something very narrow that we thought we could do. And everything is dictated by budget, and everything is dictated by what we likely can actually affect change in, which is developing a really good programming curriculum, and teaching some English, and creating a bunch of extracurricular resources. The freeCodeCamp YouTube channel - we just published a course on music production using Fruity Loops Studio. So we’re going to be teaching lots of cool stuff. We published a DaVinci Resolve course. And you could argue, “Oh, that’s not math, programming, computer science. That’s video production.” But the reality is by being pretty focused on just a few key things and doing a few key things well, and not trying to be everything to everybody, the cost involved is a tiny fraction.

Jerod Santo: To lay a little bit of groundwork… So there’s been a lot of conversation the last couple of weeks on the various social networks, X being the one with the most vitriol. It highly incentivizes vitriol. Mastodon I’ve seen also vitriolic, but almost entirely one-sided. It seems like the pro Web Components side is like entirely on Mastodon. That’s just maybe my feed. Of course, you follow who you want to over there. So my view of that world. But also, thankfully, in the blog post world, where we can actually have longer conversations and put our thoughts out there… So I think this was kicked off by Ryan Carniato of Solid.js, who wrote a long post titled “Web Components are not the future.” Now, he’s been saying this for a while, so this is not the first time he has said this, but he wanted to make the argument again. And he said a little bit outlandish stuff, specifically he said “Web Components possibly poses the biggest risk to the future of the web that I can see.” To me, that’s over the top. But he also laid out what I think is a thoughtful, well-reasoned case. His opinion. And he’s not uninformed.

And so his biggest problem with Web Components is that they’re built on top of custom elements, and because of that, all Web Components are DOM-based, or related to the DOM, but there are other components that aren’t that way, and so there’s like this limiting factor… He goes into much more detail. And there’s been a lot of responses to that. The most well thought out that I’ve seen was from Cory LaViska; also Lea - is it Leah or Lea Verou? I’m not sure how her first name is pronounced… Has written about it. Cory calls Web Components the present, and basically says “You’re thinking about it all wrong.” So there’s a lot of details here. But people are basically arguing “Is this part of the web platform worth building on, worth continuing to invest in? Or do frameworks and tools and everybody need to just continue or start to ignore–” actually, continue to ignore, because they’ve been ignoring Web Components for a long time…

Adam Stacoviak: Or I guess anxiety point is - will we lose the people that we have in our community? Will they bounce? If you can showcase what’s on the other side of the wall, rather than me assume, as somebody who is not happily, but happily using Slack, given the things we’ve already said… I still like Slack; it’s still amazing. It’s just, they’ve got warts for people like us, communities like us. I feel like that’s the content I would personally – I would look at the data and I think that would be the hypothesis… Get awareness, show off the amazing feature set that really captures 80% of who likes you most, and then show how easy it is to move. And almost make it like “You should be doing this. It should happen today. We can help you.” And if there’s “money to invest”, in quotes - it could be time, it could be people, it could be people hours - is to guide and assist certain organizations on that path.

Autumn Nash: But see, this is interesting, because there are those two – we’re talking about trade-offs here, right? But this trade-off, you’re saying we’re going from the enterprise-ness, we’ll say, but you’re going to open source. But if we don’t invest in maintaining open source, and we don’t invest in the open source community, you no longer have that option. So it’s like interesting how those two things relate, right? And then not only do you need to invest in open source, but you also have to have people with that kind of knowledge. So it’s like, do you want to be locked into a license, or you have to be very careful about making sure that the open source projects stay live and that you have people… Because Kubernetes is a skill. That is a skill, you know?

Kelsey Hightower: [unintelligible 01:11:55.02] My daughter is 17. She’s graduating high school. Finished two years of college. She did the early programs, going to UDub in the fall… And when you have a kid, you realize the game ain’t just about you. It’s not about just you being safe. It’s not just about you having everything taken care of. Now you’re making decisions because there’s a person that didn’t ask to be here. You brought this person into this world, and you are responsible for them until they can be responsible for themselves. And yeah, it does change the capitalist completely. You start looking about “What world will they have to live in? I brought them in here, and what world would they have to live in? And then how do I contribute to that?”

So the reason why you save a little extra is not so you can buy something, it’s so that you may need to be able to invest in them, so they can do something. My career has stopped. My professional W-2 career has ended. Hers is about to start. I’m excited about that, being able to be that coach, be that person to do the code review as she started taking some of her CS courses or informatics courses when she gets to college. I’m thinking about what that internship will be. I’m thinking about “Man… Hopefully there’s enough nice people that when she’s a rookie, and she joins the team, that they don’t make her feel like she wants to quit tech. Hopefully, the whole industry has evolved to the point where she can land on a team that knows how to mentor and get her to go from a junior engineer to a senior engineer.” That’s the calculus that I’m currently doing, and then the generation that comes after that.

So that’s been my thing for a little while, Adam. This is why when people DM me on Twitter, I’m like “Just call me, man.” I don’t know who you are. You don’t have to pull rank. You don’t have to tell me what your background is. I don’t need a link to your LinkedIn. You seem like a person that believes that I can help you. Do you know what a privilege that is, that someone believes that one of the most important things in their life, that I can be of help? Come on, man… Look at that responsibility. Because a lot of times you give people advice, and I’ve seen it boomerang back, where you meet someone - I’m walking around San Francisco and a kid runs out and is like “Hey, Mr. Hightower.” I’m like “Damn, I’m not that old. I’m only 43.” He’s like “Mr. Hightower, you answered the phone for me years ago. And you told me to do boom, boom, boom. And I did boom, boom, and now I’m in San Francisco, I’m in tech, I got a job, and I was just eating. I saw you walk by and I had to run out and say thank you.”

Paul Orlando: [01:07:38.27] Oh, that’s a great question, too. My hope is that smart, creative, talented people will be able to better devote their time. So they’ll still do things that they’re passionate about, but if it’s a question of “Hey, I’ve got a lot of options. I’m going to think about timing as a way to make a decision, and then I’m going to do something that I think will benefit from timing, that’s just going to help me along the way.” So related to that, I hope that our cousins in these large corporate environments, where maybe they have in-house labs, or they’ve got like 50 different potential products that they are trying to figure out how to put resources behind, or what to keep, what to kill, I hope that timing will become another way they filter opportunities and decide where to put resources.

Similar things for startups that are pitching for capital, or investors that are evaluating startups. We recognize timing is important. How could I actually step through that with some type of a process that’s helpful, and then get to a place where if I’m the startup, I either represent what we’re doing appropriately? This is why the time is right, in a Why Now slide. Or on the investor side, lots of things we can invest in, but we should be in this area. I don’t know exactly who’s going to win. I’m not predicting which team, if there are 100 different startups doing something similar… But we should have some type of place in this new market.

So I hope it’s things like that, that come out of this. I would really want people to apply this in what they choose to work on, and what they choose to invest in, and what they choose to do. But absolutely, founders do influence what happens in the world… So you can take this book and say “I’m still really passionate about this topic. I’m going to pull the future forward. I’m just going to do it anyway.” Or “I’m willing to wait the 10 years that I think it’s going to take for it to have a supportable business model. I’m gonna get through that in some other way.” But yeah, to your question, I really hope that it’s going to change the way people actually build or invest in companies.

Adam Stacoviak: Do you think the next round would have a mix of maybe reallocation to existing angels, maybe some new angels, and funds as well? What’s your thoughts on how you expand? Because what you’re offering really is you’ve got some conviction, you’ve got some awareness where you’re going, and you’re offering an opportunity to folks… Not just simply people coming to you who really appreciate what you’re doing, and wanting to invest in your company, but you’re also saying “We’re gonna go here, and here is an opportunity for you to be a part of that.” Not just simply the funds, but maybe more angels that are out there that respect you, and appreciate you, and want to invest as well, that maybe didn’t get the invite, or the friend of the friend invite, or the introduction, or whatever… Because when you’ve got 28 angels in your first seed round, realistically, it’s not a lot of people; it’s a lot of people, kind of, but it’s not a lot of people when you’ve been as successful as you’ve ever been in the industry; I think 28 people is nowhere near your network, nowhere near the amount of people you could have had in your seed round, for example, from angels.

Jerod Santo: That’s right. So I definitely saw value in it early on, because I was a consumer, that a lot of people didn’t see. And Adam, my partner, had a really hard time getting other people to see the vision that he saw of how valuable this could be for people… But I saw it, because I was one of those people who was like - I loved listening and hearing the lives of software developers, their decision-making processes, what they invest their time in… And then also just keeping up with new tools and techniques as a developer who was really out on an island in Nebraska, working by myself for small clients… I felt very much out on my own. It really made me feel connected to a larger community, and so I decided to invest in small ways over time.

[00:36:16.27] And I could see some value that I guess other people couldn’t see. Adam saw it, obviously… And I guess that proved out to be good, because over time it’s grown and grown, and eventually he began to go full-time, and then eventually I began to go full-time as we scaled down my consulting business. So yeah, it’s gone really well, it’s been kind of organic and slow and steady; that’s one of our monikers. But we enjoy it, and thankfully, other folks seem to enjoy it as well.