Interview Intro

‍

Richard Rodger:  [0:00:00] Welcome to the Voxgig Podcast. We talk to people in the developer community about developer relations, public speaking and community events. For more details, visit voxgig.com/podcast. All right, let's get started. 

‍

Today I'm talking to Adam Christian, who is the CEO of Stateful.com. I love talking to early stage founders and Stateful.com is a really cool startup. The basic idea – and of course it's about developer experience – is to make your README file executable. And they do this by being deeply integrated into VS code, so everything just works.  Back in the day, Adam used to work for Sauce Labs, where he picked up a ton of experience around community building and reaching out to developers. So, let's get started. [0:00:50]

‍

Main Interview

Adam Christian

‍

Richard Rodger:  [0:00:52] Adam, welcome to the Fireside with Fireside with Voxgig Podcast.  It's great to have you on today, and as we've just realized, we randomly met eight or so years ago, in my hometown of Waterford, Ireland. So, it's great to be talking again, after having randomly remembered you; we met in person. [0:01:08]

‍

Adam Christian:  [0:01:10] Yeah, great memories of early JS Conf days; that one definitely stands out. So, fond memories of Ireland for sure. [0:01:17]

‍

Richard Rodger:  [0:01:19] It was great to have you guys over here. We were running conference, not really knowing what we were doing. That conference was run in a medieval castle with three-foot thick stone walls. We were trying to do workshops with no wi-fi. Things you learn running conferences. [0:01:39]

‍

Adam Christian:  [0:01:41] I think this was one of those experiences where I wound up with a bunch of people sitting on the grass around a big, beautiful tree, talking about features maybe coming into Node. And it felt like – wound up being the best way to do that. [0:01:54]

‍

Richard Rodger:  [0:01:58] Let's talk about Stateful and let's talk about an interesting term you guys have coined, README ops. So, I'm not going – I'm going to stop talking and you tell me what that is. [0:02:10] 

‍

Adam Christian:  [0:02:12] Yeah. One of the primary challenges that we've identified that continues to exist for developers is this thing where you wind up at a repo or you wind up back at a repo app for some period of time, and you're in this place where you have to get productive on this thing again. 

‍

And having spent years doing developer tooling, we wound up saying, "There is this space here between the human at the keyboard and this whole ecosystem of pipelines and dev ops stuff that has pushed everything out into the cloud, where there's still a person interacting with a  UI and a checked-out repo, and what is this thing?" 

‍

And we found it challenging for months to figure out what to call this, and nothing seemed to work. And I was pitching a candidate that we were in the process of hiring and I explained this whole thing, and I just said, "What do you think this is?" And he goes, "Well, obviously, it's README operations." And I just love that, because README is such a specific thing, but also such a loaded term, with such a history. 

‍

It means a lot to developers; it's this interface to the code that you're trying to work with. And even though our stuff works with any markdown or MBX file and any repo, README ops is the closest we can get to clearly triggering those feelings in a developer that targets this really particular space that we're spending our time thinking about. I hope that makes sense. [0:03:52]

‍

Richard Rodger:  [0:03:53] Yeah. And that mirrors my own experience as a developer; you're sitting in front of the README. And the thing you do, so far as I understand, is – the examples in the README actually work; you can run them. [0:04:05]

‍

Adam Christian:  [0:04:08] Yeah. So, the place that we're starting with README ops – and we see such a big, cool ecosystem that we hope emerges from this, and that's in a large part why we're doing this in an open-source way and a community-focused way – is that this space needs to be filled for different technologies and different kinds of documentation that live in repos and the COI and in VS code and other editors. 

‍

So, we're – really, what we're trying to do is, use Runme, the VS code extension and the COI as a place to start to invite people into that community. And right now, to put it as simply as possible, if you have – if you're in a repo, either in a COI or in VS code, and use our tool in VS code, you can parse and turn that markdown file into a runnable notebook. 

‍

And I know that historically, notebooks and VS codes have been really popular with data science and ML people. But for the meantime, given the great built-in facilities in VS code, we've found that that's a really nice vehicle for giving folks a really clear and understandable both editor and runnable experience for markdown files. 

‍

And running means that you have the inputs and the outputs and environment variables in config, and secrets and all that kind of stuff. And so, we want to get to a place where that runnable notebook is the easiest, smartest and best way for somebody to get their local environment into a productive place. [0:05:48]

‍

Richard Rodger:  [0:05:49] So, can you work with any README file, or do I as the dev – is my open-source project or the SDK for my service – do I have to do anything? [0:05:58]

‍

Adam Christian:  [0:06:01] No. The beauty about this is that we parse markdown and MBX; we take into account things like front matter. And all we do is – out of the box, the thing should render – anything that's a runnable command should become runnable.  Anything that's a shell command, for example, should become runnable. And then we have a number of annotations that are transparent to markdown renderers that you can in-line with each command.  That adds behavior to how the thing runs, whether it's in the background process or whether you pop up the terminal or it's long running type of thing. 

‍

So, it works out of the box, but then the code owner can tailor the behavior a little bit for people. Or if you're a user and you say, "Actually I want this to behave differently right here," there's a UI built into the notebook for adding that stuff. And it saves it back to markdown so that you could check it in if you wanted to. [0:07:07]

‍

Richard Rodger:  [0:07:08] Nice. And that's the notebook concept, which is really – I've always been a little jealous of the data science people and their Jupyter notebooks. Because it is a really nice DX, right? [0:07:22]

‍

Adam Christian:  [0:07:23] We find it to be a really easily [draftable?] Time: 0:07:27 experience, because when you look at a markdown file, there are style guides out there and there are norms and things like that. But when you put it into this runnable format, you start to see things like, okay, this is the getting – dependency setup section. 

‍

This is the pinging API endpoints to validate that things work section. This is the – run the test and all that other assertion stuff section. And we're looking at tons of these files to make as many of them work well as possible. We're starting to get a lot of clarity around what are the different kinds of things people do.  And there's many different – there's the README and contributing and all this other stuff. So, we're also classifying this stuff to figure out what the relationships are, so as this thing grows, we can do smart things around all of them. [0:08:20]

‍

Richard Rodger:  [0:08:21] And who – so, who do you see as your primary – there's the end users, who are experiencing README in a new way. But are you primarily interested in working with open-source coders now to make their projects more accessible? Or are you starting to look at people who have SDKs or APIs? [0:08:45]

‍

Adam Christian:  [0:08:47] Yeah, that's a really great question, and something that we've actually been thinking about and going back and forth on. And right now, out of the box, the dev ops person or – not dev ops person, anybody trying to get their environment set up. The more complexity there, I'd say right now, the more value you get on of it. 

‍

So, if you're inside of a company and you need to provision a bunch of systems and install a ton of dependencies so that you can interact with an app, that's been where we've been thinking. But recently, it's become more clear that just getting people into a place where they can do some work is really important for us. And then that involves the open-source folks and potentially interacting with web components and things like that. 

‍

So, we built something called the Runme Launcher, which we're about to deploy at [BlockoSun?] 0:09:47] right now. But the idea is, you can use deep links in the VS code, so that you can have - on your web code or whatever it is, you click the link. Launches the VS code; checks the thing out, brings up the rendered notebook. And we think stuff like that [gives answers?] Time: 0:10:02 can be really helpful for open=source projects, to get people to a place where they should be able to contribute. 

‍

And you can see where this goes, where if a potential contributor gets stuck running through the runnable markdown that was called contributing MD, that we can do things like help report those error messages to maintainers or automate the way you log an issue or whatever it is. So, the shorter answer to that is, we want to be really good at both, and we're working hard to try to prioritize things on both ends of the spectrum, so that people in both those positions clearly get value quickly. [0:10:40]

‍

Richard Rodger:  [0:10:42] Yeah. I can definitely think of a couple of scenarios where I would have found it useful. With some of our clients, you have a scenario where there is a complex setup. It's a private setup; t's a bunch of docker files or whatever, to get a particular system running. And if there was a level of automation and documentation and support around that, that would be super useful. 

‍

The other one that I've just run into is – we just finished a project for a client and I think we had integrated about 15 different third-party services. Which meant that we had to sit down, read 15 different READMEs, documentation pages, API. 15 different ways of installing the SDK, 15 slightly different ways of authenticating or getting a key or whatever. And it was driving me nuts by the end of it, because there's no tooling to help you get up and running. You just to have to dig around with all these different READMEs. So, I can – I think I would have found it useful. [0:11:59]

‍

Adam Christian:  [0:12:02] It's really early days and there's a lot of thinking going on around things like, should a runnable notebook – it knows a lot about your code base. It knows the operating system that it's running on. We could hide all commands that are for Windows if you're on a Mac or vice versa. There's more conventions that the more structure there is around how people organize those files and how they name them and what they're meant to do. We could do smarter things with them. 

‍

And one of the places that is on the very short-term roadmap for us is testing. [It?] Time: 0:12:42 brought –it's a huge problem for markdown files and all documentations. But we believe strongly – and one of the principles of this README ops thing is that your docs should live close to your code so that there's a relationship there. 

‍

And the more we know about the commands that are required and the way that these things are structured, the smarter we can do about – the smarter we can be about doing things like automated testing. So, if you have a set of commands in a README file – and the first versions of this are going to be ugly, because we're going to try to find ways to run through that README in an automated way from a GitHub action or something. 

‍

But as we get a little bit more thoughtful about how we organize and annotate this stuff, we can actually get to a place where your markdown documentation is running as part of your test suite with you doing very little. And we think that that's where this should ultimately go, at least a piece of the puzzle. [0:13:47?]

‍

Richard Rodger:  [0:13:48] Yeah. In some of my open-source projects, I struggle with documentation, But I definitely want to have a situation here the code examples in the README are also unit tested and they're up to date. And I've had to come up with manual hacks to do that when I've done it, and mostly I don't. So, that would be pretty cool. [0:14:12]

‍

Adam Christian:  [0:14:13] It is an epidemic in open-source especially. I'm sure it's a big problem inside in companies too, but half the time when I try to go hack on an open-source library, for example, a lot of those steps to get to where you need to be no longer work. If you have a project on GitHub, you see that there's constantly package updates showing up as PRs, and it doesn't take very long before the thing doesn't work at all. And so, what could be more important than people's ability to get the thing working, in my opinion. [0:14:49]

‍

Richard Rodger:  [0:14:50] Right, exactly. I'm sold. If you're a developer and you suffer this pain, you could be as well. We want to talk about developer relations, so I'm just going to bring it back to that. Because what I'm also interested in is, okay, you've got developer tooling; makes sense. But do you – and as a startup, do you have an explicit developer relations strategy, or is it more organic in terms of building a community? I'm really interested in your thinking around how you're going to execute on developer relations. [0:15:28]

‍

Adam Christian:  [0:15:30] Yeah. That – so during my time at Sauce, the learning here was really gradual and really important. Because at the end of the day, we were evangelizing a mantra, which was continuously integrate and continuously deploy your apps, and this is hard and here's why. And so, the place that we're at now is that the new mantra that we're evangelizing is, your documentation should be treated the way your code is, or better maybe even, given how important it is. 

‍

And for me, we saw other companies during our time at Sauce go try to build an enterprise product and sell it to heads of engineering and heads of test automation. And what we found to be really successful was for us to be physically out there in the world, talking to developers who were passionate about quality and were going to be the advocate for what we were trying to accomplish inside the organization. 

‍

And there's not – early on, there wasn't a lot of those people out there, but as time grew, they got louder and they brought people with them. But there is a similarity in what we were doing at Sauce, in that we had test runners that were open source for every permutation of language and testing framework that people wanted to use. And we were trying to standardize around a common API in a very complicated ecosystem. 

‍

And given that code bases are so complex and the technology stacks people are using and the systems that they're trying to integrate within the cloud is so vast, that for us to really do this well, we need to get people out there in the community who care about the quality of docs and the on-boarding and process of getting productive with repos, and to have them help us understand and potentially contribute. But at least give us some of their time and thoughts and feelings to help us focus on the next big blocker, while we try to tackle what we think is a pretty big thing. 

‍

So, in short, the community aspect of this all is our single biggest priority at the moment, maybe in competition with just execution on the product side. But we know how important it is for us to have a passionate community contributing. So, we have invested heavily in our blog; we are spending a lot of time paying attention to discord and reaching out to people. 

‍

We're doing everything in an open-source way and trying to communicate the things that we're doing when we're doing them, and trying to – when we put this stuff on the internet, paying close attention to the responses we get from folks and trying to get them to engage more with us so that we can tune where we're going. [0:18:46]

‍

Richard Rodger:  [0:18:48] I'd like to talk a little bit more about the mechanics of doing that, because I've struggled with it myself in the past, so I'm interested in how you make that happen. It occurs to me that if you compare the time we last met, which must be eight years ago maybe, the role of the developer advocate and the idea of developer relations has blossomed in that time. 

‍

And it just occurs to me that anyone who is a developer advocate is going to be super interested in specifically what you guys are doing. And I just wonder, should you guys be targeting that particular type of developer specifically, rather than just developers in general. That – developer advocates and open-source maintainers, I would think. [0:19:38]

‍

Adam Christian:  [0:19:42] I think the ramps and the demo-ability of what we're doing lends itself really well to both tutorials and documentation and people standing on stages at conferences trying to get to a specific state that they can demo something else. And I would love to see a world where this whole bubblegum and chicken wire program that people go through to try and to get something working, to show it off, is just a click. 

‍

And I would love it if we had input from that community and wound up being the default way that people get to that place. But it is really important for us to not forget about the fact that when you're sitting inside of a company working on an app, there's a lot of internal systems that you need to interact with and provision, and this automated testing story is really strong for everybody. 

‍

So, it's really hard to pick and choose, and the way we're approaching that is, we're trying to put forth to the community what our next set of steps is on our roadmap. We recently put out a blog post about the road to testability for Runme, which is, we want to do something – I don't want to say quick and dirty, but rudimentary, that gets the point across, to get people to engage with it. And we're in a place where we're experimentation driven. We're going to build cool stuff and put it out there and if folks pick it up and run with it, we'll do more there, and if they don't, we'll move on to the next one. Does that make sense? [0:21:28]

‍

Richard Rodger:  [0:21:29] Yeah. And I want to talk a little bit about the mechanics of those interactions, because engagement with the community, marketing to developers – I put it in quotes, scare quotes – is critical to what you guys are doing. But in terms of the day to day, do you guys run a content calendar? Do you allocate an hour a day to writing blog posts? What – how – take me through your strategy, and then how do you execute that tactically? [0:22:01]

‍

Adam Christian:  [0:22:04] I do not have a – any kind of a traditional marketing background at all; I've been very uninvolved in what people I think would call marketing. But I have been really involved in developer evangelism this whole time and spent a lot of time at conferences in the hallway talking to people after those conferences. So, when the conference scene disappeared during the pandemic, that was a scary moment for me, because I didn't know any other way to reach folks, other than reading comments on GitHub issues. 

‍

We've had a lot of discussions about this recently, and I think the way that we're going to approach this is schedule around content. And we want to be doing a mix of product roadmap related stuff, a little bit more visionary or explorative kinds of things, and then peripheral content around what's going on in the VS Code ecosystem and the ephemeral environments, ecosystem as an extension of that, as code spaces live in the cloud and people like this idea of doing all of their development and standard environments off somewhere, and we also want to explore that. 

‍

And so, there'll be a schedule of content that keeps coming out. We're going to try to make sure that stuff shows up in smart but thoughtful places. But the CTA across all of this attention that we're trying to generate, is going to be two things. One of them is try Runme, tell us what you want and be – join discord and talk to us. We just want touchpoints with people who care about this. [0:23:53]

‍

Richard Rodger:  [0:23:57] So, it's very direct, very hands-on community engagement, more than traditional marketing calendars, that type of thing. [0:24:05]

‍

Adam Christian:  [0:24:07] Well, yeah. And we – doing this stuff out in the open, we're going to be asking a lot of people. We're going to say. "We released this thing and we're going to show up in your DMs and we're going to show up in your Slack communities or we're going to email you directly, however we can get you, to see if we can get you to try it and be really honest with us. 

‍

Because we found that that's the only thing that maters in all of this product development stuff is truthful responses around whether it adds value or not, and it's really hard. We're doing a few other things I can't quite talk about yet, but we are investing significantly in this goal of building a thriving community. [0:24:53]

‍

Richard Rodger:  [0:24:55] I have a couple of really badly documented open-source Node modules; be careful what you wish for. Talk to me about Stateful, the company. This is – it seems to be an open-source based product, but tell me a little bit about Stateful and your journey and how you came to build this particular product. [0:25:18]

‍

Adam Christian:  [0:25:21] It's – boy, it feels like a long journey at this point.  My initial conception of a product that needed to exist in the world was around – I'm spending a lot – I was spending a lot of time in one on ones with engineers. And I was saying a lot of the same stuff, which was, how are you managing your time and how do you know whether you're making an impact? And think about the correlation between your happiness and how productive you were.

‍

And so, we went through a number of permutations of trying to build an inbox for engineers around managing their own productivity. And we wound up in – using VS code as a vehicle to inform – to give us data that we could try to connect to those things to give to engineers. I'll make your great manager engineering lead away. 

‍

And we found that we built this product; we called it Strava for Devs. It's a VS code extension; we put it out there into the world. We got some really good feedback; we also got some very terrible feedback of people saying, "Why are you trying to gamify my coding and why are you all up in my VS code, putting awards and boxes places and things?" 

‍

And we thought, why – well, I know people love this. Because we think it's really cool, but we have hard time explaining exactly how this makes your life better, in the way that maybe somebody with a health tracker on an Apple Watch or something will look at it a couple of times and then put the thing in the drawer, or [in ordering?] Time: 0:27:05 or something like that. 

‍

And so, we took a step back, and it was a painful experience to pivot. As you probably know, it's emotionally challenging to invest so much and have it not work. But the ultimate conclusion was that we need a pain pill, and looking back at building this whole app, what part of this was the hardest? It was getting engineers at any particular time, on any particular repo, to a place where they can contribute and be productive, and why isn't this solved? And that led to this concept of a README ops ecosystem. [0:27:43]

‍

Richard Rodger:  [0:27:48] It sounds like a fairly classic startup journey. Are you guys self-funded? Did you take investment? [0:27:54]

‍

Adam Christian:  [0:27:56] We did take investment; we took investment from awesome people. We took investment from Fly Ventures, which is based in Berlin, and we talk money from Four Rivers Group, here in the Bay Area.  And (inaudible, 0:28:13) company, and they're awesome people. So, if you want to do deep tech, I would recommend talking to those folks. [0:28:19]

‍

Richard Rodger:  [0:28:22] Yeah, it's a heavy burden, having been through it myself on a pivot, when you have investors and you have to think, what's the – I've got these fiduciary duties, scary word. How are we going to- [0:28:37]

‍

Adam Christian:  [0:28:37] I think… 

‍

Richard Rodger:  [0:28:40] Yeah, how are we going to get to the best outcome for everyone? [0:28:42]

‍

Adam Christian:  [0:28:45] It's just been such a weird time: COVID followed by what's going on with global economics. Us as a dedicated bottoms-up product play, which we've been committed to from the first day, is – means that you have to get traction, and you have to get really significant traction. And that means that you're not in a place where you're going to be able to generate revenue for a long time. And that journey is scary. 

‍

And those folks have seen the show before, and as a first-time founder, I got to say it was incredibly helpful to have people telling you that you're doing the right things and to just keep doing – following your gut and making smart decisions, and leave the rest to the universe, because you can't control everything, even though you'd like to. [0:29:40]

‍

Richard Rodger:  [0:29:42] Yeah. Business is kind of strange. When we met in previous lives – I co-founded a Node.js consultancy at literally just the right time, when Node was taking off. And the only reason I got into Node n the first place is because I used to be a Java coder and my boss gave me an impossible project which had to be done in a month, six months' work in one month. 

‍

Impossible in Java, just about possible in JavaScript, and Node 0.6, I think. And then you have this random serious of events that you – where you suddenly end up hitting the market and it works. It's interesting; they say product market fit is not – you know it when the market is pulling you. You're not pushing. So, you know it when you see it, right? [0:30:41]

‍

Adam Christian:  [0:30:44] Absolutely. Looking back on the Node wave, everybody felt what was going on at the time, but it was a little bit difficult to step back and really see, at least for me, what an incredible gamechanger it was. But as we built for that ecosystem at Sauce, in general, but also especially the Node microphone was really loud, we experienced the market pulling us. 

‍

And we could not keep up, and it was years of struggling to scale. And at the time we were doing everything in our own infrastructure with servers in the data center, and running out of IP addresses and all this kind of stuff. And it was your classic – oh my gosh, how are we ever going to survive this sort of experience? And we certainly at Stateful are not there yet, but I would – I'm terrified but also can't wait, and hope that we wind up in a place where we get to feel some of that again. [0:31:51]

‍

Richard Rodger:  [0:31:52] Yeah. It's a nice problem to have. It's funny; I sometimes advise startups as well, and if you speak to people who haven't lived through that, even though they have a great product idea and a great business and a great team and good investors, you find yourself trying to convince them that it's real, that the magic can happen. It's a funny – you have to have lived it to truly believe. It's a weird thing. [0:32:19]

‍

Adam Christian:  [0:32:22] Yeah. And it took me a couple of years after the Sauce Labs experience to appreciate what a unique experience that is in the world. And now I – in a way, I'm addicted to the startup thing, because what an incredible thing to get tot do in life, right? [0:32:44?]

‍

Richard Rodger:  [0:32:46] It's a bit of a curse as well. [0:32:47]

‍

Adam Christian:  [0:32:50] It's all of it; it's all of it. We all have to be nuts, but we also have to appreciate how special it is, so I try to focus on that. [0:32:58]

‍

Richard Rodger:  [0:32:59] Yeah, it is a privilege to do what we do; it definitely is. But hey, the whole Node thing, that happened – certainly kicked off 2011-2012. Every 10 years, 10-15 years max in this industry, things turn upside down. It's time for a new wave. I don't know what it's going to be. There's a bunch of interesting stuff and machine learning and that sort of thing, but it doesn't feel the same. I'm still waiting to see what the actual next big thing is going to be. [0:33:32] 

‍

Adam Christian:  [0:33:35] Yeah. And part of me wants to be spending speculating around where things go in the future, this next big wave. But also, I have learned the hard way that one foot in front of the other is the more effective place for me to be. But I do think that we need to keep our eyes on the whole ephemeral developer environment stuff. I think that's interesting, but still feels like putting brand new running shoes on. And I want my old running shoes that are comfortable for me and that's my (inaudible, 0:34:17] environment. 

‍

And I also think that thinking about ways that machine learning can augment some of the developer workflow that we deal with on a day-to-day basis – I remember thinking back to – the brittleness problem with writing automated tests was that things are way more dynamic than anybody wants to believe. And so writing integrating tests that actually tell you something useful was, and I think continues to be really hard. [0:34:50]

‍

Richard Rodger:  [0:34:51] Unsolved problem. 

‍

Adam Christian:  [0:34:51] And for us – yeah. And one thing that we're thinking about now is, what does fuzzy mean for developer documentation and what does that mean for testing? And what is data as how these people use these notebooks? How can that influence that? So, bringing it back to the whole quality realm, I guess. I can't seem to get away from it. [0:35:13]

‍

Richard Rodger:  [0:35:15] Even if you don’t have a specific answer right now, you guys are in the right space, because interesting stuff is going to happen with this machine learning. It's not quite there yet, but I've used ChatGPT and used it for real stuff, and it has been useful. Not to write code, because… 

‍

Somebody – I saw a tweet today. Somebody said that you set up one of these large language models to write some code for you and you get a 100-line solution to whatever. And then you have to go through it line by line, the same way you would with a junior dev, just to check everything. 

‍

But at the end of that process, you don't have a junior dev that you've helped grow, that's becoming an asset to the organization. You've just been tearing your hair out because the what the f***s per minute are too high. So, it still makes more sense to invest in the humans for the moment. [0:36:09]

‍

Adam Christian:  [0:36:12] I think so. And Sebastian, my co-founder, who's been on this whole journey from the very beginning and has done a really good job of being a calming presence and a creative thinking presence, continues to say we don't need to have giant learning machine learning models to do this. 

‍

We can do little neuro mets that are augmenting and adding value in a smart way without trying to go all in on any one thing. And that's the way that I want to continue thinking about it is, how can we use some of this technology in a subtle but really smart way, to make people's lives a little bit better often. [0:36:53]

‍

Richard Rodger:  [0:36:56] Yeah. And if you bundle together enough of these incremental improvements, you're – you do end up with some sort of step change. I certainly hope so. I've been coding since '97, and it's the same as it ever was. The servers are better; I don't get 4am calls because a server does some stuff. But the actual day-to-day coding, on a command line, it's the same. The web inspectors are better than they used to be. I used to have code for- [0:37:38]

‍

Adam Christian:  [0:37:41] We were joking about this not too long ago; we were doing a company offsite. And we were talking about how the world – you look at the media out there on the internet talking about how the world will never be the same again and none of us will have jobs because the AIs have changed everything. 

‍

And then you get into a car and you can't figure out how to even put the letters one at a time into the GPS thing. And I run into this stuff all over in life where I'm like, "Yeah, maybe, but you know what? Right now, it's people and their fingers, and so there's a lot of room between here and there where we can make things better. So, that's where I try to live. [0:38:27]

‍

Richard Rodger:  [0:38:29] That's the thing. If you look at the details of how these large language model systems work, there does seem to be a fundamental upper bound in terms of what they could do. There's very convincing, fuzzy content generation, but you have to go to the next level. Yesterday I was writing a very tight little piece of code, parsing something. 

‍

And I was thinking, it's not like this code can just be pulled from various places of the internet and thrown together. Because there isn't any redundancy in what I'm doing here; every single variable counts. All the off by one errors that are painfully solved, they all mattered. And I didn't see – it would be scary if they could get to that level, but I didn't see how you could write code like that without the proper semantic understanding. [0:39:39]

‍

Adam Christian:  [0:39:43] Yeah. I played with Copilot from GitHub and VS code, and I found I would often go with the AutoComplete, it would be something really different from what I wanted. And I would wind up writing it my own way anyway so that I could understand it completely. Because using whatever thing made me uncomfortable. 

‍

And a lot of what we're talking about on a regular basis is not that we're trying to reinvent the universe. We know that developers and ourselves, we're in our environment. We have it set up; we like our color scheme; we like the key bindings that we have. We like things the way we like them, configured in line lengths, all this kind of stuff. 

‍

And say what you want. Sure, you can put it in a box; you can put it in the cloud, but it's not one size fits all. And we're pretty much banking on that, because we know how important that is to productivity and how little, tiny things can bug you and hinder that. So, that's our reality still, whether we want to believe it or not. [0:40:51]

‍

Richard Rodger:  [0:40:53] Yeah. And I think you're right. You guys are going to pursue – it's a classic product-led growth strategy, right? You have the get the users on the ground first. [0:41:04]

‍

Adam Christian:  [0:41:06[ That's right. We want to get folks using – selling the extension or the COI and interacting with it. And it works in VS code, of course, but VS code is a web app. So, code spaces in the cloud, all the things. We want to see this showing up everywhere as a tool people use to get productive. So, anything that we can do or integrate or whatever it is, we want to hear it. [0:41:32]

‍

Richard Rodger:  [0:41:34] Yeah, I'm going to have to give it a spin. I have a framework that we've been using for years, about 10 years, a microservices thing. It's got about – it's got a community of about 200 plugins. You can imagine the state of the documentation; it's absolutely woeful. Will this solve all my problems, I wonder. I'll let you know that; I'll let you know. [0:42:02] 

‍

Adam Christian:  [0:42:04] This is going to be one of those classic things where if we can get our hooks into folks and we can do a pair effort where we invest some time and effort and folks do their side of it, we can come together and knock down these issues one at a time, these roadblocks one at a time. And that's where we want to be, and we know that that's time consuming and it doesn't scale and all that, but that's part of the learning process, and so we're happy to do that. So, jump in discord and let's figure it out. [0:42:38]

‍

Richard Rodger:  [0:42:38] Yeah. One developer at a time. Cool, okay, I think we'll wrap it up there. Adam, thank you so much. Fascinating stuff. I'm going to look at- [0:42:48]

‍

Adam Christian:  [0:42:49] It was a pleasure. It was a pleasure and I appreciate the chance to talk, so look forward to what happens next. 

‍

Richard Rodger:  [0:42:56] Okay. Take care. Good luck. Bye-bye. [0:42:58]

‍

Adam Christian:  [0:42:59] Thanks. Bye. 

‍

Endnote

‍

Richard Rodger:  [0:43:00] You can find the transcript of this podcast and any links mentioned on our podcast page at Voxgig.com/podcast. Subscribe for weekly editions, where we talk to the people who make the developer community work. For even more, read our newsletter. You can subscribe at Voxgig.com/newsletter, or follow our Twitter @voxgig. Thanks for listening. Catch you next time. [0:43:27]

‍