The Infra Pod - How Github grew from 0 to millions of developers, and now bringing that to Devops! (Chat with Ted, ex-CTO of Github)

Episode Date: October 14, 2024

Ian and Tim sat down with Ted Nyman (ex-CTO of Github, CEO of Cased) to chat about how it feels like to be part of the early days of Github, how did it made its way from a little known project to what it became today. We also discussed about Ted's new startup Cased and how it's transforming Devops as well.

Welcome back to the pod. This is Tim from Essence VC and Ian, let's go. Hi, I'm Ian. I am so excited. Today we're talking about something very cool with a very cool person. I'm super excited to have Ted Nyman on the show. Former CTO at GitHub and currently started a new company company uh called cased so ted why don't you tell us a little about yourself like what's give us the five line bio five line by okay well i'll do long lines there'll be five lines but each line will be quite quite long so uh let's see so i'm

ted i i live in the beautiful bay area we've lived here 18 years now, so that's a long time. Let's see. I'm a software engineer. Most of my work has been in infrastructure. We used to call it ops, which I still call it ops sometimes, a lot of the times. And then systems. I worked at a company that folks may remember called Bank Simple. We were one of the first neobanks before it was cool.

And then after that, I joined GitHub. I was one of the first systems engineers at GitHub, where I scaled a lot of the Git infrastructure, databases. Redis was probably my big specialty there. We had one of the biggest Redis clusters, I think, in the world at that time. We basically put anything and everything in Redis. After that, I became VP of engineering and then CTO for a few years. So as we kind of transitioned from sort of early GitHub for a very flat structure into kind of a growing org. And so I built the engineering org there. And then, yeah, recently, I started Caste with Ben Blykamp, who was also another early GitHubber. We're working on more developer tools focused around deploys, anomalies, and figuring out how we can use AI to make some of that stuff better.

So, Ted, you were really early at GitHub. What was it like? When did you join? What was the first, like, being an early employee? What stage was the company at? I have so many questions. I think everybody can learn from the early days of GitHub. Because all we see, like most people, all they see now is, you know, this multi-billion dollar revenue run rate company that's attached to Microsoft,

right? Like that's what we know today. But there's so much about the founding story of GitHub that is still like unique and interesting. Yeah, so I mean, I joined GitHub. I mean, I knew a lot of the early people, but I joined right around the time we started to basically grow the team. So I was probably maybe 40, 50, something like that. The company remained really small. So one of the interesting things about GitHub is, you know, GitHub was founded 2007. I think the product was released 2008. And the company really stayed under 10 people for the first three, three and a half years.

Didn't take any VC. In fact, you know, it's hard to remember this now, but that was actually a big part of their early days. It was kind of the imagery of the company that wouldn't take VC and, you know, had very strong, obviously, you know, it was an open source place, right? You know, eventually the company grew, expanded into businesses,

but those first few years were really driven by sort of this instant product market fit that the company had. And it's something that I think when you go out and you start like I have, start your own company, and you realize, you know, product market fit sometimes just doesn't come on day two, and you have to find it. It's an interesting challenge. But yeah, GitHub really just had the perfect product market fit, you know, like generational product market fit.

It came out at a time when you had a rapidly growing number of developers, right? It was sort of the height of the Web 2, right? So all of a sudden, you've got this dramatic increased amount of people who are building both apps, who are building web apps, infrastructure scaling, all kinds of stuff. And of course, you know, open source, right, which had been around and had been used, but had never really had a single place. That single place became GitHub that served this sort of virtuous cycle of legitimizing open source. Then as open source became more legitimate, that helped GitHub grow.

And so you ended up with this very, very virtuous cycle. And the other thing, of course, that GitHub did, and I don't want to overstate it, but I think it is true, is it was one of the first developer tools that was really thoughtful about, we didn't use the term then early on, but, you know, developer experience, right? And user experience. And developers really, really sort of fell in love with the tool, right? To the point where, you know, people still do, you know, unaffiliated with GitHub, wear GitHub hoodies, put on stickers, not just to do it, but like a show of things. So I think when we look at the early GitHub, the two important threads

are right time, right place, and really just caring a lot about developers. And I think that level of care extended. I mean, it's now, companies will be more than 15 years old. I think it still has that feeling. We'll see how it does in the future. Obviously, it's a different world now, but I think those themes are extremely important to understand as part of the early success, I think.

What do you think it is that GitHub got right early on? I often think about companies as a series of miracles. As an entrepreneur, you should probably only found companies where you can stage the miracles. It's like, okay, I need this miracle to happen, and that gets me this. And then that enables this other miracle to potentially happen, right? Instead of hoping that you have seven miracles that all have to happen at the same time. So what do you think it is that GitHub got really right?

If there's one thing or two things early on that were like, oh, this is actually fundamentally defined the company and is why it worked. I can put an interesting perspective on this because I was not yet an employee when I met the people there. But that actually, I think, is it in a sense, right? The founders would go out. I mean, it's hard to, again, overstate this, and develop these really deep relationships

with open source communities, right? Ruby on Rails moved to GitHub, I think in 2008, maybe 2009. Whenever that happened, you know, looking back, you wouldn't have known it at the time, right? But looking at that now, that sort of set on this course where all of a sudden, okay, this is where open source is going to happen, right? And, you know, this was a much smaller, like you said, sort of these small miracles, right? In retrospect, they all become obvious, but that started it, right? The level of, you know, I mentioned, you know, sort of thinking and caring about developer experience

in that way, which was deliberate, right? That wasn't luck. There were other things that were luck, right? You know, the secular growth of the tech industry, GitHub didn't control that, but that happened to coincide, that was a bit of luck. And, you know, remember there were other other products, too, that were doing this. You know, Bitbucket a little later.

There was a product that I don't know how many listeners will remember, but it was called Launchpad, which was for Bazaar, which is a version control system that I don't know if anyone remembers anymore. I think that. But, you know, there were other things that were happening. And, you know, if you look, I remember there's a graph. I remember, I mean, now it seems silly to even think about, but SourceForge, you know, people will remember that were happening. And, you know, if you look, I remember there's a graph, I remember, I mean, now it seems silly to even think about, but SourceForge, you know, people will remember that too. You know, SourceForge was the dominant place of, certainly of open source hosting, right, by far. And, you know, so you had a set of factors, like you said, you know, staging them. One was also the growth of distributed version control, right? This is a fun thought experiment.

And I think Scott Chacon wrote about this recently. He was one of the founders of GitHub. Like, it wasn't so much Git. Like, it could have been Mercurial, right? Like, they're basically the same. I mean, Mercurial maybe even has a better UX, right? But it so happened that some distributed version control system happened to be Git, was the one associated with GitHub. And once you ended up in this sort of virtuous cycle of more

open source going, more open source going, you know, a story I tell all the time, GitHub didn't have a real team plan for several years in the beginning, right? It was like only user plan, individual user plan. So if I wanted to bring GitHub to work, right? It was like only user plan, individual user plan. So if I wanted to bring GitHub to work, an individual had to like put their credit card in and you'd change your username from, you know, Ted to whatever my company name was. And I would invite people to my own repos.

That was how it was, like, there was literally no orgs, right? But people would do that. They would put it on their own personal credit card because there was just so much developer love, right? Which is so hard to fake, but people started to sort of identify with the product, right? Another small thing that I think is underappreciated is actually URL structure, which sounds like, wait, how would you become a successful company based on URL structure? But, you know, everyone had github.com slash your username, right?

And that, again, was really cool. You know, if you go back to 2009 in San Francisco, let's say, and by the way, a lot of this was highly localized in San Francisco, to be clear, right? It's hard to understand this now. The developer community was much smaller. And, you know, you could go to a meetup in San Francisco in 2009 and, like, everyone was there. It sounds like I'm telling old stories of, like, rock and roll in the 1950s. But, like, it really was like, you know, it was like, oh, this is the person who founded this and that.

And so in those sort of, you know, salad days, those halcyon days of developer tools, once you had this sort of cool idea of namespacing everything to the individual, people started to kind of take pride in that, and that shifted it to that. And you ended up with, and again, I know this sounds silly in retrospect, but you ended up with like these mini celebs, open source celebrities, right? Someone like, like, why cats? I don't know, some of the older time people remember this, but you know, and And that started, like, another trend, right? Where all of a sudden you could become a famous programmer on GitHub, right? And so GitHub became this sort of, like, aspirational platform, right?

Before, you know, like Guillermo Rauch, Vercel. Before Vercel, he was known for a bunch of open source JavaScript stuff, right? And that was all because, you know, he was on GitHub, right? You could launch your career on GitHub. You know, now, again, it's all because, you know, he was on GitHub, right? You could launch your career on GitHub. You know, now again, it's the thing, you know, GitHub is your resume. I don't know if you remember that from years ago, but you really could, and people did, just do a bunch of open source projects, go get a job at some place or start a company, and that really worked.

And that was a really huge breakthrough where GitHub, you know, when you throw around this word like empower, right, whatever that means nowadays, but like GitHub really did, I don't know if empower is the right word, but it enabled individual developers anywhere in the world to build a career. since that was able to do that. And then all the business stuff almost came as just icing on the cake. Once you've had all those developer load, it really works. So those are some, there are others. And that happened fast, right? That was relatively quickly. And by the time eventually Series A came around, 2012, you had so many developers there

that it was who wanted to write the check kind of thing. And that was a little bit of why that happened. And so I'm very curious because I think you mentioned this word developer love over and over. Yeah. I think a lot of times people never live through that era. You can't really describe it, right? It's so hard to describe developer experience, describe developer love. Like you hear these adjectives,

like you just feel like, sure, right? But I don't think it's like a binary thing, right? It's not like you have love, you don't have love. There's usually like a bar of equality that really has able to like, oh, well, that company really has developer love, right? Is there any way to describe what the developer love feels like?

For audiences that doesn't live through that, you just by default, of course, GitHub, right? Everybody shows up for different things. But back then, it's not a consensus. No. It was weird to do that. And so I think also a lot of people say, we're going to build developer companies,

so we're going to have best developer experience and love. They don't actually know what it means. So help us here, sir. Yeah, that's a great question. So I think one of the things that happened, again, I'm speaking from both prior to joining when I was one of those developer love people, right, to after

when I joined. I think a few things, I'll say this from a hiring perspective. I know this sounds wild. People would have joined GitHub to work for GitHub for free, right? So it reminds me of like, you know, I don't know if you, if anyone, if you know any like architects, like not software architects, but like actual architects, you know, and many of them when they graduate college, like would pay

to work at the elite, you know, whatever the world's best architecture firms are, right. For the experience of, of that. Now I'm not saying GitHub was at, at that level, right. But I would say just that this is matter of fact, like I would interview people, this is as late as, I mean, this is as late as 2015 even, right? So forget, you know, I mean, this is late. And, you know, people would describe this as their dream job, right? So that, and it was not about, you know, the perks or anything like that. It was just people began to identify, and this is maybe goes to part of your part about developer love, and like literally identify with the company as part of their identity, right? Like going back to that github.com slash my name, people just wanted to feel

associated with the company, right? And again, like that, when people say developer love nowadays, and they're like, people will say, oh, you know, I really like this product because it makes AWS easier. And like, that's cool, right? But that's not like love, right? And I think it goes back again to like, people are like, they literally owed, some people owed their careers

to having been able to grow on GitHub, right? I think that feeling is that, right? Where it's not just that, oh, this is a tool that, you know, I enjoy using. It's that, you know, this has helped me personally. I know it's a weird comparison, but if you talk sometimes to people, if you go to like, you know, Dreamforce at Salesforce helps this, right? There are some people, I mean, I'm not one of them, but there are some people in the sales world who feel this way about Salesforce, oddly enough, because Salesforce, for them, made them their career, right?

They were the person at such and such company, you know, some old school company. They brought in Salesforce in 2000 and whatever, and they started to build stuff on it. They became the Salesforce expert. And Salesforce, which they feel very closely, up close about, was the thing that made them their career, right? So I think the developer love thing can be through obviously the quality of

the products. But, you know, to put it really vividly, it's like, has this product impacted me personally? And I think that is so hard to do, right? I mean, if you ask me to write out how to do it, there's not an easy playbook for this, right? I think, you know, like if there was a playbook for this, you could build multiple, you know, billion-dollar companies. There isn't. You need a bunch of those factors. But I think some of those at least explains a little bit of the feeling of it.

And GitHub still continues to have that for, you know, quite remarkably so, I think. I mean, I can remember, like, is 2011, 2012, 2014 timeframe, I was a junior developer trying to make my way. And I do remember plotting through my profile and uploading my code. And I had the mug and I had the shirts and I had the stuff. And that's so, like, if I had to encompass it, it's like, GitHub kind of captured this moment for a lot of engineers, you know, which was a here's my moment to participate in something bigger. It's the same time that LinkedIn was getting big, you know, Facebook had gone public. It was here's my place on the internet and GitHub allowed you to identify and it was a part of your identity. And it is very difficult to cultivate that. Like, I think it's actually something specific to like that generation of products at that moment in time.

And every generation has their founding, like the TikTok to Gen Z, Instagram for millennial, or Facebook for millennials. These all have these generational moments. Do you think there's a specific feature that GitHub built that helped really define the company? Was there one thing? Yeah, so this is going to sound funny. I mentioned a little bit of the URL structure. Obviously, pull requests are the obvious answer here. And I'll put this back to an emotional aspect of it.

Many people can recall when they made a pull request, maybe a minor one, to a prominent open source project, and it got accepted, right? Many people will actually fondly remember that. And again, it's funny to put, but it's almost like it's a dopamine accepted, right? Many people will actually fondly remember that. And again, it's funny to put, but it's almost like it's a, it's like a dopamine factor, right? You know, it's important to remember GitHub started,

the early lines about GitHub were social coding, right? We don't hear that anymore. Now it's the best AI platform to build, to develop a board or something. But originally it was social coding, right? And this was in an era of, like you said, Facebook, the beginning of Twitter, right? Where like people were starting to like get hooked on software, you know, right?

And for developers, you know, who were not necessarily interested in how many likes they got on, I don't know, you know, Instagram wasn't out yet, but whatever. You know, the equivalent for a developer would be, yeah, like getting a PR merged, right? It was cool, like, you know, again, back to the tech kind of celebrity concept, like, you know, if you did a PR to Redis in 2000 and whatever, 11, and Antires, who was, you know, the founder of it, looked at it and liked it, that was like, oh, my God.

That was, you know, like, oh, wow. Like, you know, that's like, like, I don't, you know, who's the guy in Twisters that everyone likes nowadays? That, that, that handsome guy, whatever. It would be like him saying you're, you're a good actor or something like that, right? So, I think that, that, that, you know, as silly as that sounds, that's there. And yeah, I mean, like like you said i think it did capture a particular moment in time where you so strongly identified github with being a developer right almost like a sports team people were rooting for it right yeah that's very hard i mean i i think the weirdest comparison that i have nowadays and but it's not at that level,

maybe would be like when some people are like really into open AI for some reason, but even that's not quite at the same level. You do see some of that kind of almost a fan type activity, right? But yeah, it's a set of those things. I think one of the things you talked about, you know, one of the big moments for GitHub was Rails moving to the platform. For the audience, I remember this a little bit,

but what was the product experience delta for these people? What were they doing before that made moving to GitHub just make sense? What was the delta? Because oftentimes, I think, when we think about developer experience or developer love, we don't talk enough about what's the functional impact on their day-to-day. There's all these identity things, but something came before all that. Before the branding and the marketing, it was the actual product experience. What was that like?

I'll use an example of another web framework a few years later. So Django, which was not on GitHub, eventually moved over. I remember I was at DjangoCon in 2010. It was in Portland, I remember, and there were discussions about whether they should move to GitHub or not. And most people did not want to, right? Like there was actually pretty strong opposition at that time. They didn't want to move because they were concerned, like what happens if GitHub, you know, it's a for-profit company, right? Previously Django had been on a self-run subversion server. They had a self-run subversion server. And they didn't want to move there. They were like, well, what is that? There was also weird language stuff

because GitHub was written in Ruby and was associated with the Rails community. So certainly you wouldn't want Django. I'll tell you one thing that did happen, I remember, is Django released some version. I don't remember what it was. And their subversion server crashed. And so you couldn't clone Django on like the day of the release. And I think that maybe, if I remember this correctly, was part of the thing that eventually led them to move.

So that's one meaningful thing, right, where you didn't have to run your own subversion or whatever server. All of a sudden, yeah, now, okay, cool. This is one less thing I have to worry about. And I don't need to worry that when I do a big release on the big release day, you know, people can't check out the repo, right? For the context of open source contributors, though, once things were on GitHub, first off, you saw an immediate increase in the number of contributors. The friction to contribute was substantially less because, first off, you universalized the contribution flow. You may have had little differences how you put together a set of commits or whatever. But everyone knows how to click the fork button, right? Before, you'd go to like Rails slash contributing or whatever. There'd be some process.

Maybe you send an email patch. You have to go to some other self-hosted server that they run, create an account there, get that account verified, get your email. So the amount of friction to new contributors was very high, right? Existing contributors were usually fine because they're like, well, I have account verified, get your email. So the amount of friction to new contributors was very high, right? Existing contributors were usually fine because they're like, well, I have a workflow, whatever. But the newer contributors, you know, was hard. So by moving your open source project to GitHub or starting it on GitHub, you immediately increase the probability that you're going to have more contributors, right? You know, you can think about it, do a thought experiment,

like some of the stuff that's taken off the last few years. Like, if they were just on self-hosted ketosis instances and they said, hey, check out our website on blah, blah, blah, dot dev. Like, you just don't have the critical, you know, mass there, right? You're kind of out there. So, ironically, the centrality of a distributed version control system, you know, had that audience, right? And then in terms of workflows, pull request workflow is better. People started to adopt an issue-based workflow, you know, which was very useful. So you had that in one place. People used to have the repo in one place, then you'd have some other issue tracker, like Ruby had like Redmine,

if anyone remembers that, was like this extremely slow issue tracker. So now you've got this integrated workflow, right, of an issue, a pull request. There weren't discussions then, but people would use discussions in issues. And so you end up with like a whole system in one place for running, obviously we're talking about open source projects, but it was also obviously that came into companies. The other thing to note is that people got so used to the pull request flow in open source that by the time you would join an organization, you know, everyone kind of knew that flow, right? There used to be a thing where you'd have to like get onboarded when you join a

company into their version control system, right? I remember talking to people at GitHub, you know, who would say things like, you know, when we were just doing research and stuff, and they'd be like, yeah, you know, I joined the company, and I kind of like never really knew how to like, really make a contribution, like, I would just kind of like, send it to somebody else, and they'd put it into their patches, like people, these seem so ridiculous now, but having a single unified workflow across all of it's quite remarkable, right? A, you know, 20, 30 million, 50 million developers all know how to do a pull request workflow. And the details may be different where you, you know, you do this particular thing or you stack them or whatever. But the basic concept of the pull request as this sort of universally

known way of developing software is new. A fun experiment I like to do is like, ask a person who's only been around pull requests in GitHub and ask them, how did people contribute before? It's like asking what came before the universe, right? No one really knows. And the concept is ridiculous, right? So I guess my advice on this, and I don't know, we're trying maybe to do something like this

in case one day, would be, if you could build something where people cannot fathom what things were before, that's really cool. It's hard to do again, but that's the kind of impact, I think, that you saw in that workflow change. So what is Caste? Tell us what Caste is about, where the story comes from. And obviously you learn a lot from someone from GitHub, right?

So yeah. Segway. Yeah, so Caste, C-A-S-E-D, Caste. So we are a platform for deploying and then running software, which sounds, what does that mean? And it's actually a nice segue back to GitHub. So GitHub had a very particular way of deploying software that was extremely effective.

It let us deploy 100 times a day. And it was based around this concept of what we call branch deploys. And I think a good way to think about branch deploys is you separate your world into two things. You have branches, which represent changes of, you know, they're change sets, right? Usually manifested in the form of a PR. And then you have environments or targets, which could be like things like production, staging, could be in particular instance, whatever. And these two things are not the same, right? So the idea is that on any given moment, any of these targets, any of these environments

can have any branch running on them, right? And that includes production. So nothing's spectral in this system, right? When you start developing that concept, a bunch of really cool things start happening, right? So first off, you stop doing these terrible, like, branches that are called staging or production, right, which invariably create merge conflicts.

They slow developers down. The second thing that you do is you start to be able to have a really nice way of testing in production, which people don't like to say they do, but everyone does, and doing it in a way, by which I mean, doing it as the final stage in your CI, CD. So you've passed tests, you've run it in some other environment, but now the ultimate test is how does something actually work in production, right? And so if I can just lightweight deploy a branch to production, I can test it out, I can see what happens.

I can do the other stuff that CASE does, which is, is there an increase in anomalies, right? Is there an increase in errors? Is performance bad, right? All kinds of things that you really want to know in production before merging into your main branch, right? So what branch deployers let you do is it gives the developer a ton of ownership over every single deploy. It allows them to monitor and understand what happens when they deploy. So there's no, you literally cannot throw something over the wall, right? Like the developer owns every single deploy. They are responsible for monitoring it. So what Case does is through a web UI, which I think is really nice, hopefully, an API, and then a bunch of other integrations like with GitHub, we make that trivial for anyone

to implement, right? So you basically can implement the GitHub, and not GitHub Flow like GitHub Flow is described in blog posts, but literally the way GitHub deploys software. And on top of that, you layer in a whole bunch of workflows, right? So for example, say I don't want something to go out to production unless it's gone through, you know, n number of deploys or minutes on staging. And we have confirmed on staging that exceptions have not

gone up by X, Y, Z percent, you can set up automatic these kinds of workflows, right? And then automate that. So that we started from. And then obviously, we're in this era of generative AI and AI generally. And we thought, well, cool, if we're building something like this, what might be interesting? And so we started to layer in things like log analysis. So for example, after I deploy, let me look at the logs and see what's happening. That's difficult to do manually, but LLMs are actually pretty good at it. So we do that. Another fun thing around deploys is say a deploy fails. Why did that deploy fail? Well, we can probably figure that out by looking at logs and some other stuff.

And then the other fun thing around this is how do we correlate exceptions? So say I want to know that this deploy is responsible for this new bug that we got. Well, cool, we can track that back. So almost like a sort of automated Git bisect, right? But focused on the deploy. So CASE really is trying to bring a lot

of these practices to anyone and to do this without requiring like a platform as a service, right? So you don't need to pay for, I mean, this is a hot topic in the world right now, but you don't necessarily need to pay for a whole platform to get this. You can deploy this on AWS, you can deploy this anywhere you want and get that sort of like really good developer experience so that's that's what we're building very cool well i want to jump into what we always been known for the sort of spicy future section spicy futures given your experience we talked quite a lot about github i know we've only touched on somewhat about your about case but I think you really want to bring that sort of like new experience, right?

And also this sort of like connection, like you mentioned to the engineer. So I'm actually very curious. What is your take of a spicy future here? Yeah, awesome. Okay, so I mean, I think you have to bet, I mean, you don't have to,

but I think you should probably figure that the AI stuff is real for coding. You know, we'll see what happens with these agents, right? But clearly, we're in a new world where a large percentage of code is going to be written not by human beings, right? Like, this is already happening. It's going to continue to happen so i think the biggest question i think for me and when i think about developer experience is if engineers move from the sort of author role into more of let's say the editor role right which i think we're already seeing how does that shift most of the things that we think about and care about in developer experience so one is just simply like pull requests, right?

Like I suspect that in a few years, AI is going to review most pull requests and do most of that, right? So if that's true, to my earlier premise around, you know, is GitHub, you know, GitHub was key on the pull request, that feature no longer is interesting, right? Like maybe the pull request concept goes away, right? Does the AI look at your code and say, okay, this is ready for a pull request, and then another AI reviews it? All of the interesting things about developer experience have been around the ergonomics of human beings writing and reviewing code. If they're not doing that anymore, how much does developer experience even matter? I think it matters, obviously. But there is an interesting question as to, you know, is it almost like many of the things that we've cared about and think matter, do those become less interesting? And this isn't in a year, but it could be in

five or 10. And then sort of like, what is the value prop, I guess, for all of us building developer tools, right? The spicy take is that if we're in a truly automated world, many of what developer tools foundations have been based on maybe doesn't matter as much. I don't necessarily want that to be true, but I think that would be an interesting question. And then the question, which is interesting to talk about, is like, what does the world look like? You know, what do we start building for developers? I think that's an interesting 10-year question, I guess. One of the things I keep asking myself is,

if we believe truly in the transition from humans are the drivers to humans are the editors, further down the assembly line, if you will. It's kind of the way I think about that, if you think of the writer's room analogy. How does that transition happen? Because if you look at the way that of the way I think about that, if you think of the writer's room analogy. How does that transition happen? Because if you look at the way that developers actually what they do today, all of the tools, like even Cursor, which has grown crazy

and has obviously caught the zeitgeist. They're just on Lex Friedman this previous weekend, which is pretty incredible. If you haven't seen that podcast, I suggest you do. But how does this transition actually happen? And if you do become an editor, don't you need to be a good writer to be an editor? Yeah.

What's your take on that? Yeah, I think you do. So this actually raises another interesting question, which I'm actually worried about for the field, which is, you know, I think this has been articulated in different ways, but you have to learn how to program. And whether you're learning that on the job, or I mean, that's clearly the best way to

learn. You know, if someone comes up, and they've only worked, you know, prompting, they're not going to really understand how the computer works, right? I've been worried about this before AI. It's a lot easier to, you know, I'm going to sound like an old person now, but you did have to, once upon a time, you know, know a little bit about how memory worked, right? Or, you know, even how, you know, what is an HTTP request, right? A lot of people don't know. A lot of people are very successful, productive engineers and couldn't tell you what, you the structure of when i say an hdp request i'd be like literally like what it is like what are the headers what you know um you know how does that go how does that go right um you used to know maybe a little bit about tcp ip like i don't like

there were things you kind of knew um you don't i mean i think i think as an infrastructure engineer you certainly need to know that but there are many engineers who don't. So I was already worried about, you know, losing a lot of those fundamental, and not even computer science, right? Like just fundamental web development stuff, right? Talked to a lot of people, and I don't mean this in a way to, I don't mean this necessarily in a negative way, it's just a fact of life who have never SSH into a server, right? Maybe that's a good thing, but that's a true thing. And these are professional programmers, right? So yeah, I think that's not going to get better with AI. And so I think you could really end up in a really, maybe this is maybe the worst possible scenario where we end up in this sort of transition period between what we have now and what maybe is a world where it's just AI writing everything, where it's like we've kind of forgotten how to do it.

But we haven't gotten to a level where we don't need to remember it, right? And that could be a really awkward thing. It's probably a good thing for people like me who still remember how to run the manual farm equipment, right? Good job security for folks like that. But I do think that that's a problem. And I am actually very interested in how, like, education is going to work, I guess. If junior engineers are going away, and maybe they are, you know, how are you going to learn these things? There's probably a world where there's enormous advantages in having the ability to learn yourself, right? So I think very high agency developers have always had an advantage, but have an even bigger advantage right now.

I think if you're a really talented, self-taught programmer, right, and it's the best time in the world for you right now, I mean, between AI and the programmer, right, and it's the best time in the world for you right now, I mean, between AI and the ability, like, you know, you don't need to go work at Google for four years and get out of there with, you know, the same level of skills that someone who's really, really into learning to program can.

So I think the answer here to avoid that is really high agency, self-directed. And I think this is what we're seeing of sort of like shifting to the individual, right? And much less dependence on like corporate experience, right? And maybe that goes back to GitHub, right? Where showing your skills on open source projects, right? We see it in some of the LLM stuff.

It's a long answer to your question, but I think self-education is going to become really important for developers. Well, there's way too many topics we could cover, but for the sake of time, we probably want to just wrap here. How do people check out more about what Caste is or more thought-provoking exercises from you like where where should we check out you and case uh yeah i wish i had more time to write uh unfortunately well i have i still i still write a lot of code but um uh the best place for case is just cased.com c-a-s-e-d.com we're now open for business so you can sign up we have pretty good docs powered by the the wonderful mintlify which uh i'm not being paid to say this, but they are great if you're looking for a docs platform.

But, yeah, so, and, you know, the cool thing about CASE is you can get started just, you know, trying to, you know, deploy like a test repo, seeing that workflow, getting used to that workflow. And I'm, for me, I'm on the Twitter.com. TNM is me. I post about Deploys and I try not to post too much about college football, although I really I really want to post more about it. But the audience doesn't seem to really care. Yeah. Yeah.

Awesome, sir. Thanks for being on our little pod. And I hope you enjoy it, sir. Yeah, it was a lot of fun. Thank you very much. Thanks so much.