Latest / The Pragmatic Engineer / Efficient scaleups in 2024 vs 2021: Sourcegraph (with CEO & Co-founder Quinn Slack)

Transcript

Efficient scaleups in 2024 vs 2021: Sourcegraph (with CEO & Co-founder Quinn Slack) · The Pragmatic Engineer

• 0:00
  SPEAKER_0: Every decision that I made back in 2021, I now regret.
• 0:03
  SPEAKER_0: The backdrop was that developers were so in demand and you had a lot of people that had understandable but unrealistic expectations.
• 0:12
  SPEAKER_0: A lot of our manager's time was spent managing the growth and trying to manage in peacetime mentality.
• 0:20
  SPEAKER_0: In hindsight, it was not peacetime, and this idea of how do we do everything a little bit faster?
• 0:26
  SPEAKER_0: How do we do everything higher quality?
• 0:28
  SPEAKER_0: How do we say no to more things?
• 0:30
  SPEAKER_0: I think a lot more companies have adopted that now, and I think a lot of companies, and us included, I really wish that we had done a lot more of that back in 2021.
• 0:37
  SPEAKER_1: Welcome to The Pragmatic Engineer Podcast.
• 0:39
  SPEAKER_1: In this show we cover software engineering at big tech and startups from the inside.
• 0:43
  SPEAKER_1: After each episode, you'll walk away with pragmatic approaches you can use to build stuff whether you're a software engineer or a manager of engineers.
• 0:50
  SPEAKER_1: In this episode, I sat down with software engineer-turned-founder Quinn Slack, to talk about how the reality of tech scale-ups have changed over the past few years.
• 0:58
  SPEAKER_1: Quinn is the founder and CEO of Sourcegraph, a code search tool and code intelligence platform.
• 1:03
  SPEAKER_1: Sourcegraph was founded in 2013 and has raised a total of $248 million in funding so far.
• 1:10
  SPEAKER_1: In my conversation with Quinn, we cover details on how Sourcegraph changed how it operates in 2024 versus three years ago in 2021, practical AI and large language model use cases and advice on how to best use them, why Sourcegraph changed from location-independent pay to location-based pay, and a lot more.
• 1:28
  SPEAKER_1: Let's jump in.
• 1:29
  SPEAKER_1: Before we kick off, would you mind starting how Sourcegraph started, which has now been 11 years ago, and how did things evolve since then?
• 1:37
  SPEAKER_0: Yeah, I have been a developer all my life.
• 1:40
  SPEAKER_0: I love coding, can't pry me away from it, and I love that you get to build something and then just get it out there to millions of people and nobody knows where you're from or what age you are.
• 1:50
  SPEAKER_0: It's this incredible equalizer and this incredible sense of creation, but I found that that spark of creation, you don't really get that when you're working in these massive code bases.
• 2:00
  SPEAKER_0: So I was working on some patches to Chrome and OpenSSL and Firefox, and to even understand those code bases, I would set up a code search tool, and at the time, this was back in 2009 or so, the code search tools are very primitive.
• 2:14
  SPEAKER_0: It felt like you were on old MSDOS library computer.
• 2:20
  SPEAKER_0: And then I went in and worked inside some big banks and they had so much code they had things like SharePoint and it was so hard to figure out who even owned this code or why is it broken.
• 2:30
  SPEAKER_0: So we just said, "There's got to be a better way," and my co-founder, Beyang, he had been at Google where they famously have this amazing code search tool that everyone loves.
• 2:38
  SPEAKER_0: They got a lot of great internal tools, but this is like the most loved.
• 2:41
  SPEAKER_1: What's it called?
• 2:42
  SPEAKER_0: It's called CodeSearch.
• 2:45
  SPEAKER_0: One word, capital C, capital S. So we knew that there was a better way to do it and we just wished that we had that kind of amazing code search tool inside these big banks or inside these projects that we were hacking on in opensource.
• 2:59
  SPEAKER_0: So we decided to go start Sourcegraph, and we knew that code search was something that was in this perfect intersection of something that we would use ourselves that we could build, and that would be really valuable, because ultimately, it means bringing all the code from all these different code bases, many cases, different code hosts, different languages, and it was this thing that every developer would use.
• 3:21
  SPEAKER_0: And there were not a lot of tools like that at the time because everything in developer stuff is so fragmented.
• 3:27
  SPEAKER_0: Different languages, different editors, different CI systems.
• 3:31
  SPEAKER_1: Tons of repos everywhere.
• 3:33
  SPEAKER_0: Yeah.
• 3:33
  SPEAKER_0: People are so opinionated, but code search was this odd gap that we could fill and make the best code search and then from there there'd be so many other things that we could do being the only tool that's got all the code and all the devs.
• 3:45
  SPEAKER_0: So 11 years later, here we are.
• 3:47
  SPEAKER_0: We probably thought that it would take us a year to do all of this, but 11 years later, here we are and we got Uber as a customer, as you said.
• 3:54
  SPEAKER_0: They were one of our very first and now we got a ton more and loving every single day of it.
• 3:59
  SPEAKER_1: Awesome.
• 4:00
  SPEAKER_1: But speaking of changes, so one change that has been a huge one is how scale-ups... So you're a scale-up.
• 4:07
  SPEAKER_1: How large is Sourcegraph roughly in terms of people, funding?
• 4:11
  SPEAKER_0: We have about 180 people on the team and that's globally distributed.
• 4:18
  SPEAKER_0: As far as funding, I believe we've raised a little over 200 million.
• 4:24
  SPEAKER_1: And speaking... So you're considered what a scale-up is.
• 4:27
  SPEAKER_1: You passed the early stage startup, you're actually like a mid-stage, late-stage scale-up depending on how people put it.
• 4:33
  SPEAKER_1: I mean, I don't want to put labels on it.
• 4:35
  SPEAKER_1: The point is you've kind of gone through... You're really in that growth phase, and in 2020 and 2021, this was a very different time to build a scale-up like yours than it is today, and I'm just curious to hear back then, before you knew how the world changed both in terms of LLMs, both in terms of the funding environment, what were you seeing back then and what were your goals and how has the reality changed in terms of Sourcegraph, and also talking with other founders?
• 5:06
  SPEAKER_1: How do you see this big shift on a lot of things?
• 5:12
  SPEAKER_0: I feel like we've been doing the same thing that we set out to do 11 years ago and there's a lot of consistency.
• 5:19
  SPEAKER_0: I think that's been really good for us.
• 5:21
  SPEAKER_0: We've had this mission to make it so everyone codes and our product Code Search has stayed the same.
• 5:27
  SPEAKER_0: We've done stuff on top of that with Cody, and for us, it took us a while to get that initial traction and Uber was one of our first customers, but that was even five years after we started the company, and-
• 5:40
  SPEAKER_1: Wow.
• 5:40
  SPEAKER_1: So it was like five years to close your first, or one of your first big clients.
• 5:46
  SPEAKER_0: Yeah, I'm glad we stuck with it and there are a lot of reasons why I think for our product, for our market, it took us longer to get there and we were getting a lot of users along the way, so there's never any doubt, but it took us a little longer and what that meant is by the time we were scaling up, by the time that kind of pandemic frenzy was leading to massive dev hiring, massive investment in everything software-related, we had history, we had staying power.
• 6:11
  SPEAKER_0: It was clear that we were committed and we'd been moving in this direction for a long time and we were able to make better use of that money, better use of that momentum than I think a lot of companies that were one or two years old at the time and hadn't quite found their identity.
• 6:28
  SPEAKER_0: It's not to say that it was easy, but it really accelerated our growth in an incredible way.
• 6:34
  SPEAKER_0: I mean, more than 30x growth in terms of revenue just in those few years of the pandemic.
• 6:41
  SPEAKER_0: And then of course we and many other companies in our situation saw that a lot of the customers that we had sold to were really struggling due to the economy.
• 6:51
  SPEAKER_1: This episode was brought to you by Paragon, the developer platform for building customer-facing native integrations into your product.
• 6:58
  SPEAKER_1: Whether you need to build two-way syncs with your customer's CRMs, ingest your Google Drive files or Slack messages as context for RAG AI app or provide them cross-up automations and agentic workflows, the list of integrations your team needs to build will never end.
• 7:12
  SPEAKER_1: With Paragon's SDK embedded in your integration platform, you just need to define the integration logic.
• 7:18
  SPEAKER_1: Paragon handles are the plumbing including authentication, event listeners, frictional web hooks, rate limit circumvention and comprehensive monitoring.
• 7:27
  SPEAKER_1: This is why engineering teams at AI21, Copy.ai, and over a hundred other engineering teams at B2B SaaS companies use Paragon so they can ship integration seven times faster and focus on their core product.
• 7:39
  SPEAKER_1: Visit useparagon.com/pragmatic-engineer to see how Paragon can help you accelerate your product's integration roadmap today and get a $1,000 credit on their pro and enterprise plans.
• 7:51
  SPEAKER_1: Start your free trial today.
• 7:53
  SPEAKER_1: That is useparagon.com/pragmatic-engineer.
• 7:58
  SPEAKER_1: It kind of sounded like you also saw... So you saw this really big increase in 2021 or 2020 in customers and interests and I guess companies opening their wallets to become paying customers, but I'm interested in what were things that you changed and how you actually ran the company let's say from 2022 or 2023 in terms of any practices, hiring?
• 8:22
  SPEAKER_1: Did you see different issues which retention, those kinds of things?
• 8:27
  SPEAKER_0: Yeah, I read this one quote from someone that said, "At every decision that I made back in 2021, I now regret," and I really identify with that.
• 8:39
  SPEAKER_0: The backdrop was that developers were so in-demand and you had a lot of people that had understandable but unrealistic expectations.
• 8:50
  SPEAKER_0: They would join a company where they saw the market cap of that company or the valuation of that company grow by 10x from the time that they started interviewing until they got the offer in some cases, and that expectation is something that cannot be sustained by any company even in a really frothy environment even if that continues.
• 9:13
  SPEAKER_0: I, as CEO, ultimately wish that I had been way more aware of this, but found that there were a lot of people that I think at a lot of companies, Sourcegraph included, joined because they saw it as a rocket ship and did not join because they absolutely love code.
• 9:32
  SPEAKER_0: For us, that's the most important thing.
• 9:34
  SPEAKER_0: When we hire a new engineer, we want to know that they absolutely love code and same thing probably for other companies with respect to their mission, and I found Sourcegraph with a team of people that were all incredibly talented but didn't have that same kind of hacker, that founder, that let's create something from zero to one mentality that we had earlier, and that made it harder.
• 10:01
  SPEAKER_0: I also saw us growing, and a lot of my time, a lot of our manager's time was spent managing the growth and trying to manage in the kind of peacetime mentality, which I mean in hindsight it was not peacetime.
• 10:19
  SPEAKER_0: Yes, money was freely available, but it was the most amazing growth opportunity and I see so many more ways that we could have seized that.
• 10:28
  SPEAKER_0: And this idea of how do we do everything a little bit faster?
• 10:32
  SPEAKER_0: How do we do everything higher quality?
• 10:34
  SPEAKER_0: How do we say no to more things?
• 10:36
  SPEAKER_0: I think a lot more companies have adopted that now and I think a lot of companies and us included, I really wish that we had done a lot more of that back in 2021.
• 10:44
  SPEAKER_0: There was some new features, new products that we came out with that I don't think should have made the cut and that's on me as CEO, I should not have allowed that to happen.
• 10:54
  SPEAKER_0: There were people who, especially early career people, who I think that we did a disservice by not telling them that their stated goals, being like their idols in the coding world, requires really hard work, especially in that early career time.
• 11:10
  SPEAKER_0: It requires working nights, it requires working weekends, it requires grinding, and that's not something that they have to do, but if they want to achieve their stated goals, they have to do that.
• 11:21
  SPEAKER_0: One of the really awesome things we did was bring on Steve Yegge as our head of engineering.
• 11:27
  SPEAKER_1: You got him out of retirement, right?
• 11:29
  SPEAKER_0: Yeah, that's right.
• 11:31
  SPEAKER_0: I think that he was looking for this kind of opportunity, because he built a lot of this stuff around CodeSearch at Google and when we were starting Sourcegraph, we thought he was our nemesis and he was our biggest enemy.
• 11:41
  SPEAKER_0: He was going around at Emacs conferences and talking about the thing he was building, and ultimately, we found him and just such awesome fit in what he wants to do and what we needed.
• 11:53
  SPEAKER_0: And even though he had been at Google and a lot of people at Google, it's not a startup hard-charging environment, but he just naturally had that, and so that just focus on we are building something, let's just iterate faster, do everything faster, let's hold the standards incredibly high, that's the kind of mentality that I think we and every company probably needed a lot more of.
• 12:19
  SPEAKER_0: Him coming on was an awesome just infusion of energy and momentum for us.
• 12:25
  SPEAKER_0: And when I think about the difference how we work today versus how we work back in 2021, it's just so much more focus, so much faster shipping.
• 12:37
  SPEAKER_0: Everything that we do used to be primarily self-hosted enterprise and that meant that the feedback cycles were at least a month for customers to go and try something.
• 12:47
  SPEAKER_0: Well, we now have it so we can ship many times a day and we ship new versions of Cody and Code Search many times a day.
• 12:54
  SPEAKER_0: We've just sped up everything and we've got a team that celebrates that rather than that sees that as something that's stressful.
• 13:01
  SPEAKER_1: And then from this period of this really big boom in 2021, what is the biggest learning that you're taking away from yourself or that you would advise your former self?
• 13:11
  SPEAKER_1: Something that's sticking with you.
• 13:13
  SPEAKER_0: For me, it's stay really close to the code and the product, and I love coding, I started the company because I love coding.
• 13:23
  SPEAKER_0: Our product helps other people code and if I'm not coding all the time pretty much every day, then I'm not going to be as fluent with all the new stuff that's happening.
• 13:33
  SPEAKER_0: I'm not going to know every single corner of our product as well as I should to make the right decisions.
• 13:39
  SPEAKER_0: And there's a lot of people who if they hear that the CEO at this company codes, they might think, "Oh, I'm going to be cleaning up a bunch of messy CEO code."
• 13:50
  SPEAKER_0: I try not to code in the line of production as much, but we've gotten to the point where it really does help me do a better job as CEO, make better decisions, and where it's something inspiring and it gives people from all kinds of different functions, whether it's engineering managers or PMs or even our CFO, it gives them inspiration to go and code more and says that it's okay.
• 14:14
  SPEAKER_0: Because there's a lot of advice out there that says unless you're a full-time software engineer, you shouldn't write a single line of code, and I just think that's crazy.
• 14:20
  SPEAKER_0: It was crazy back then and it's even more crazy with AI that makes it so much easier for people to dip their toes in coding.
• 14:27
  SPEAKER_1: It is interesting, because I don't hear many or even any CEO say that they do code daily.
• 14:33
  SPEAKER_1: CTOs, I do hear, but I guess if anywhere it would make sense when your product is a tool that developers use day in and day out.
• 14:42
  SPEAKER_0: Yeah, the Shopify CEO codes and I love to see that.
• 14:46
  SPEAKER_0: I bet there's others.
• 14:49
  SPEAKER_1: Awesome. So are you conscious of doing it or are you doing it because you love doing it, or is it both?
• 14:51
  SPEAKER_0: Both, you couldn't pry me away from it.
• 14:53
  SPEAKER_0: You can go check my commit logs in the Cody and Sourcegraph repos.
• 14:57
  SPEAKER_0: Coding all the time.
• 14:58
  SPEAKER_1: It's all public as well, right?
• 14:59
  SPEAKER_0: Yeah, that's right.
• 15:00
  SPEAKER_1: Love it.
• 15:01
  SPEAKER_1: What is your approach in thinking of how you approach this space?
• 15:05
  SPEAKER_1: We've seen approaches for what GitHub Copilot is doing.
• 15:09
  SPEAKER_1: There's other more bold approaches like Devin building a fully autonomous AI agent.
• 15:15
  SPEAKER_1: What is your thinking of what works today and what you're hoping is going to work, let's say, tomorrow?
• 15:21
  SPEAKER_0: I am so excited by this space.
• 15:22
  SPEAKER_0: I think it's so obviously the future of software development.
• 15:26
  SPEAKER_0: How do you eliminate the toil from humans?
• 15:28
  SPEAKER_0: And there's two things that matter.
• 15:31
  SPEAKER_0: One is the context, what information does the AI have access to?
• 15:36
  SPEAKER_0: And two is how are you thinking about automating it and on how you're thinking about automating it?
• 15:41
  SPEAKER_0: We take a different approach from what I see other people doing.
• 15:45
  SPEAKER_0: I see a lot of people fixated on let's get a totally new UI for software development that is not in the editor and that stuff demos really well.
• 15:58
  SPEAKER_0: I think we'll probably even get there eventually, but I kind of think that's like those auto company CEOs who 20 years ago would get up on stage and show off a dumb-looking concept car with no steering wheel.
• 16:11
  SPEAKER_0: It looked kind of dumb, and yeah, it's probably the future, but that kind of thinking is not what got us to where we actually in San Francisco where I live, have self-driving cars that are going all around the city.
• 16:23
  SPEAKER_0: What got there is putting a steering wheel in the car and going from the human driving 100% to 99 to 98 to 97, collecting the data along the way and having the AI bite off the easy parts first.
• 16:36
  SPEAKER_0: The things that are rote that are part of every task, like updating a bullet in a change log.
• 16:42
  SPEAKER_0: That's the dumbest thing, but I think we all can understand intuitively that an AI can do a pretty good job of taking your diff and updating your changelog and that's the thing that humans often forget to do or bad at doing or make typos when doing.
• 16:56
  SPEAKER_0: And I think that the way we get toward 100% automation is not by setting the expectation that we can do 100% and then disappointing people in some different interface, and if the tool only gets 90% of the way there, then you got to switch to your editor and it's painful.
• 17:11
  SPEAKER_0: I think the way we get toward 100% automation is by starting at zero and that change log thing might represent 0.1% of dev work, and we just keep on piling up those 0.1%'s that we can give a little bit more structure to, that we're using AI, but we're not just dropping the whole thing and having AI spit out a one-shot thing or something where it iterates with itself, because AI checking its own work, it's like piling shit upon shit.
• 17:38
  SPEAKER_0: It does not end up good.
• 17:39
  SPEAKER_0: You got to bring ground truth in.
• 17:40
  SPEAKER_1: And when you say changelog, just to set things straight, because I think that's something that I know you're doing, but not as many places are doing.
• 17:48
  SPEAKER_1: By that you actually mean the changelog of the product, right?
• 17:51
  SPEAKER_0: Yeah, that's right.
• 17:52
  SPEAKER_1: Well, actually that's an interesting concept where you're doing it, Linear is doing it, some companies are doing it.
• 17:58
  SPEAKER_1: I think it's making a comeback now, but it kind of disappeared for a while.
• 18:03
  SPEAKER_1: Why do you see changelogs being important?
• 18:07
  SPEAKER_1: That's an interesting area.
• 18:09
  SPEAKER_0: Well, people just want to know what's new in this release.
• 18:13
  SPEAKER_0: So when they get the new version of Cody or Sourcegraph, they'd just like to see that.
• 18:17
  SPEAKER_0: So she's got sections for changed and fixed and added.
• 18:20
  SPEAKER_1: Do you think there's a connection between shipping changelogs and a focus on shipping important and good stuff?
• 18:29
  SPEAKER_0: Yeah.
• 18:29
  SPEAKER_0: Well, even maintaining a changelog requires discipline and even that is hard to do.
• 18:37
  SPEAKER_0: To have one very simple process that developers remember to do at all the right times, even that is difficult.
• 18:43
  SPEAKER_0: And changelog, it also is a really easy way to see, "Did we actually ship a lot?"
• 18:50
  SPEAKER_0: If you don't have much to put in your changelog, well, that should scare you.
• 18:55
  SPEAKER_1: I guess this is... Yeah, this is doing two things with one... You're achieving multiple goals with just one thing.
• 19:02
  SPEAKER_1: Two birds with one stone, pretty much.
• 19:03
  SPEAKER_0: Yeah.
• 19:04
  SPEAKER_1: I love it.
• 19:06
  SPEAKER_0: So going back to the two parts of AI.
• 19:10
  SPEAKER_0: For AI to get close to 100% of what a software developer can do, which is way far in the future, part of it's just the approach to autonomy.
• 19:18
  SPEAKER_0: We're taking this kind of bottom-up approach, but the other part is you got to get that ground truth in, so you got to make it so the AI can check its work.
• 19:26
  SPEAKER_0: You cannot have the AI review its own code.
• 19:30
  SPEAKER_0: That can help if you're a junior engineer, you want a quick pass, but that can't work, especially when you have many different invocations of it.
• 19:39
  SPEAKER_0: You ultimately need to see does the code type-check?
• 19:42
  SPEAKER_0: Does it pass tests?
• 19:44
  SPEAKER_0: Does it deploy?
• 19:45
  SPEAKER_0: When it deploys, is there a large number of errors?
• 19:48
  SPEAKER_0: I mean, if you fast-forward this all the way to the logical conclusion, you want to see does this code change result in increased revenue when you send real or maybe shadow traffic toward it, and no one is even close to doing that.
• 20:02
  SPEAKER_1: Forget about AI, even just having an elite software engineering team at a company that is building amazing products and generating great revenue, I would argue that even they're not doing the last step, for example.
• 20:14
  SPEAKER_1: Do you think it might be that these AI tools might make us more ambitious to actually do that?
• 20:19
  SPEAKER_1: Could that be that we might be able to... The companies, the teams that actually use smart automation and they free up their time, they'll have more space for these more ambitious?
• 20:30
  SPEAKER_0: Yeah, I think so.
• 20:31
  SPEAKER_0: I think because you're going to see the tooling landscape get turned over a lot now that AI is going to be a primary consumer of these tools.
• 20:39
  SPEAKER_0: So think about the logging tool, the issue tracking tool, the deployment, the security scanner, all these things they were made for nice UIs and enterprise features for humans to consume, but what's the AI version of Datadog when you don't need all those bells and whistles, but you just need something that is really fast that can pipe some of the performance and log data back to AI?
• 21:02
  SPEAKER_0: I think you're going to see a lot of stuff turn over.
• 21:04
  SPEAKER_0: You're going to see also there's now increasing ROI from really fast builds.
• 21:10
  SPEAKER_0: It was always the case for humans, but a really fast build is something on the order of 30 seconds or a minute, and most companies are nowhere even close to that.
• 21:20
  SPEAKER_0: But if you have a really fast build, let's say that given a dirty Git repo, a diff on your local machine, if you could have one command that runs all of the tests that are necessary because of that change, and if that could run in 100 milliseconds or 500 milliseconds, then you could have the AI iterate, try a thousand different code changes, see which ones pass.
• 21:43
  SPEAKER_0: If you can then bring in really fast feedback under a second from performance data or the security scanner, then you can help the AI iterate, help it narrow the search space and make that iteration more successful.
• 21:56
  SPEAKER_0: And I think knowing that that will be really valuable, I'm already seeing a lot more investment in really fast builds, really fast everything.
• 22:03
  SPEAKER_0: I mean, even in the Node.js world, you went from really slow nodes, slow NPM.
• 22:10
  SPEAKER_0: Now there's a lot more competition.
• 22:12
  SPEAKER_1: What are the areas that... Because I think we've seen AI is really good when you can bring in context, what are areas that you see these type of LLMs or this type of AI not necessarily be that good to use in terms of... I'm not just talking about coding, but in terms of the developer process, building software basically.
• 22:33
  SPEAKER_0: I think it's really nuanced and you have to have a good mental model of what's actually happening to know how to use it.
• 22:39
  SPEAKER_0: That's something I don't think we do as good of a job as we need to about creating in our users.
• 22:44
  SPEAKER_0: I think a lot of tools need to get better at that, and one example of this is we see some people go and ask Cody just free-form text question, "What are all the calls to this function?"
• 22:55
  SPEAKER_0: Or, "What's the history?"
• 22:58
  SPEAKER_0: And just that question, we don't kind of... It's not a command line that's completely arbitrary.
• 23:04
  SPEAKER_0: They got to at-mention this stuff and we can do some stuff to detect it, to bring in that right data, but we haven't necessarily thought of every kind of data that's been brought in.
• 23:14
  SPEAKER_0: So think that if you're using AI, you want to understand that basically the way that code chat works in any product is same thing if you ask ChatGPT the question, but you paste it in a bunch of files that you think are relevant above your question and that's what it's going to be, and a lot of people don't understand that and it's just an expectation-setting game.
• 23:39
  SPEAKER_1: The debuggers really make a huge difference in making your tools, your workflow better.
• 23:44
  SPEAKER_1: I'm not sure we have that with here.
• 23:47
  SPEAKER_0: Yeah, that's I think a component of letting it iterate, letting it try things, letting it understand the context, see what are the actual values that this variable can hold at runtime, then that is really important data and really good committed human engineers will go and get that data, but the embarrassing thing is developers probably spend 95% of their time using printf debugging and don't actually use these tools, and going back to what we were talking about earlier around all these dev tools that proliferated in 2020 and 2021, so many of them actually are amazing products, but devs just don't remember to use them.
• 24:27
  SPEAKER_0: And I think there's also this kind of value unlock that you can get if you make it so easy for a dev to use this flashy new-fangled production runtime perf tool if it's in their editor, if it's one click away, if it's so easy for them to get the data, they don't need to go and sign in again or remember which tab to go to.
• 24:46
  SPEAKER_0: That is a way for that tool to go from being used by 1% of the devs at a company to, I don't know, 50% daily.
• 24:53
  SPEAKER_0: Just that little change, bringing it into the editor.
• 24:55
  SPEAKER_1: There is a fear, especially for new grads entering the software engineering market or hoping to enter the software engineering market.
• 25:01
  SPEAKER_1: They're seeing all these powerful LLMs, Cody, Copilot and a lot of other things they are capable of doing way more than we've seen just a few years ago, and there's this fear saying, "Are our job's going to be in demand and especially as a new grad, will I have a future in the industry?"
• 25:19
  SPEAKER_1: What is your take on this worry?
• 25:22
  SPEAKER_0: I see the new grad engineers being way more fluent with AI and using AI when coding way more than senior engineers and other people in the industry.
• 25:33
  SPEAKER_0: So I'm not worried about the junior engineers that have that kind of hustle.
• 25:39
  SPEAKER_0: I think they probably do not quite realize how little adoption of code AI there is in the industry and how their relatively early adopting of it is an advantage for them.
• 25:53
  SPEAKER_0: So much so that the people that are interviewing them probably do not even know how coding has changed and how the way that junior engineer codes is so different from the rest of the team.
• 26:03
  SPEAKER_0: Now, that doesn't mean that they're going to get hired by those companies, but that means that fundamentally they're creating value, and two ways to look at this: I think software engineers have taken jobs from other industries for the last 40 years and now it's time for software engineering to turn over, but also the field is constantly turning over.
• 26:23
  SPEAKER_0: I mean, if you were coding the same way today that you were 10 years ago, well, that just would not work.
• 26:30
  SPEAKER_0: So many things have changed, the editors, the languages, the deployments.
• 26:34
  SPEAKER_0: So you're constantly turning over and I don't see any reason to think that this will mean greater shift by any order of magnitude.
• 26:42
  SPEAKER_0: I think people are used to adapting on software engineering, and if anything, think...
• 26:47
  SPEAKER_0: I always want to step back and how do we think bigger about this?
• 26:51
  SPEAKER_0: It will probably mean that the value of a software engineer who knows how to use these tools has gone way up so much so that they might not need a boss, or they might instead of being very far from the value that they create and the product that they create, they might be able to be way closer to that, which means they're going to be doing the job of a PM and an EM and salesperson, and all of that means they're going to make a lot more money in the future.
• 27:18
  SPEAKER_0: So I'm really optimistic.
• 27:20
  SPEAKER_0: I think that people just need to continue to adapt to this change and everyone in software development has been doing that ever since they joined the field.
• 27:29
  SPEAKER_1: And what do you think about the fact that these AI tools, they're here, they're going to get bigger, they will produce a lot more code?
• 27:36
  SPEAKER_1: We're going to see a code explosion everywhere in terms of the produce code.
• 27:41
  SPEAKER_1: How will that impact the industry?
• 27:43
  SPEAKER_1: Because we used to talk about or I remember talking about people, and you can tell me if you agree or not, that the more code you have, the more liability that you have out in the world.
• 27:52
  SPEAKER_1: It needs to be maintained.
• 27:53
  SPEAKER_1: And we were always talking about humans, you need to hire more people to maintain it or bugs are harder to spot, et cetera, how do you think this dynamic will play out?
• 28:03
  SPEAKER_1: Because we're going to see a lot more code, that's for sure.
• 28:06
  SPEAKER_0: Yeah, AI has gotten good at writing new code before it's gotten as good at helping with existing code.
• 28:15
  SPEAKER_0: So it's definitely outstripping its ability to keep your codebase high quality.
• 28:20
  SPEAKER_0: When you have a lot of code, Code Search really helps, so I feel like we're well-positioned to help there, but I think you're going to see AI help with existing code and that's actually the biggest criticism that a lot of people have about these completely agent-first approaches.
• 28:38
  SPEAKER_0: Just like, "Let's automate 100%."
• 28:40
  SPEAKER_0: They might work in some cases on very simple toy brand new projects, but in existing code bases, certainly the kind that most developers work in, they just do not work.
• 28:51
  SPEAKER_0: They cannot understand the code base yet.
• 28:53
  SPEAKER_0: So I think that's the big opportunity, and again, if you're going to make a small change in a really complex existing code base, you got to be really careful.
• 29:02
  SPEAKER_0: I mean, I'm sure you felt it at Uber.
• 29:04
  SPEAKER_0: If you're going to make a change to some core service, you have to see at runtime what are all the things calling it?
• 29:11
  SPEAKER_0: You have to understand all the changes, you have to get all this context.
• 29:13
  SPEAKER_0: You have to really deeply understand that.
• 29:15
  SPEAKER_1: Yeah, and then you do a stage rollout, a really careful stage rollout.
• 29:20
  SPEAKER_1: If it's a really big change, you actually message the other on-call saying, "Hey, I'm rolling this out.
• 29:25
  SPEAKER_1: I think it's okay, but if you see something in your metrics, please, please let me know."
• 29:29
  SPEAKER_1: That's how you kind of do it because you don't know if you're going to break... In the end, what you care about is will it have an impact for the business specifically?
• 29:38
  SPEAKER_1: Will users or paying customers get stuck or complain, et cetera?
• 29:43
  SPEAKER_1: And that's probably not going to change in the end.
• 29:45
  SPEAKER_1: We just have new ways of doing it.
• 29:47
  SPEAKER_1: Actually, feature flags are a relatively new way.
• 29:50
  SPEAKER_1: They came in 10 or 15 years ago, mainstream that is.
• 29:54
  SPEAKER_0: Yeah, and until code AI tools know how to do a staged rollout, know how to notify the on-call person, until they know how to work with feature flags, they're not going to be able to make those kind of changes safely, and what I've just described, that ability to work with all these other tools goes way beyond any agent that's out there today.
• 30:13
  SPEAKER_0: So I think we will get there.
• 30:14
  SPEAKER_0: We want to be the ones to build that certainly.
• 30:16
  SPEAKER_0: I'm sure that we're not the only ones.
• 30:18
  SPEAKER_0: And when that exists then I think you can have AI go and clean up all the really messy code.
• 30:23
  SPEAKER_0: So I think it's actually fine if companies are incurring a lot more tech debt, incurring a lot more messy code to move fast because their asses probably will be saved in a few years by AI, but it's a bet you got to make cautiously.
• 30:37
  SPEAKER_1: Yeah, and I think it is good to remember that there's always trade-offs, right?
• 30:41
  SPEAKER_1: So assuming you move faster, you might be accumulating tech debt, which is fine.
• 30:44
  SPEAKER_1: Again, just be aware of it.
• 30:46
  SPEAKER_0: Yeah.
• 30:46
  SPEAKER_1: Talking of the Sourcegraph engineering culture, last year I did a deep dive or we did a deep dive in the Pragmatic Engineer on how the company worked and some of the things that just stood out as a short recap, we'll have the article in the links, but you have a culture of default transparency, globally equal salaries.
• 31:05
  SPEAKER_1: It was a full remote work environment.
• 31:08
  SPEAKER_1: You have DRIs, which stands for directly responsible individuals for your projects.
• 31:16
  SPEAKER_1: You had job fairs back then, I think.
• 31:18
  SPEAKER_1: I'm not sure if Steve Yegge brought that in or that was there before.
• 31:22
  SPEAKER_1: And you had RFCs, requests for comments, and a lot of them you actually published and you also had well-defined levels for the ICM manager track.
• 31:29
  SPEAKER_1: This is just a summary.
• 31:31
  SPEAKER_1: So this was a year ago and back then this was up-to-date.
• 31:35
  SPEAKER_1: I'm interested in the last year or year and a half, what are things that have changed in terms of the engineering culture or the company culture at Sourcegraph, or at least tweaked?
• 31:45
  SPEAKER_0: Yeah, most of those are still in place with some tweaks.
• 31:47
  SPEAKER_0: One big change has been this idea of job fair.
• 31:51
  SPEAKER_0: So just to give some context, we found ourselves where we had built Code Search and that was a successful growing product and we knew that we needed to make a big shift in the company's priorities to go and build Cody as well and to tap AI.
• 32:09
  SPEAKER_0: There are a few ways we could have done that.
• 32:11
  SPEAKER_0: We could have built it as a feature in Code Search, we could have had the same people trying to build both, but we wanted to make a bigger shift because we knew that it was the future, and that's what we've been saying for the last 11 years.
• 32:23
  SPEAKER_0: So job fair was this idea that instead of well-defined teams that had long-term ownership over areas, basically every month or every other month, everyone would just rearrange to work on the most important things that we would stack rank, and it was good to kind of shock the system to get people really quickly working on the new thing, but as a lot of the team anticipated and as we knew, it's not something that works forever and it doesn't create that kind of long-term ownership, and as an all-remote company, it doesn't create that kind of team camaraderie.
• 33:00
  SPEAKER_0: So it's clear that it would expire pretty quickly as a way to work.
• 33:07
  SPEAKER_0: That's something I don't think I quite appreciated as much, I think other people did on the team, but for me as CEO, I have this idea that everyone just always wants to work on the most important thing and they're okay switching on a dime, and even if they're okay with doing that, that doesn't get the kind of quality that we need, and it's frankly hard to manage.
• 33:26
  SPEAKER_0: So we did that for I think about six months and then we had enough stability, we had shifted enough people over to Cody that we went back to the much more normal way of just long-lived teams.
• 33:38
  SPEAKER_0: I think though that I'm glad that we did that shock to the system because I feel like if we had gone any more slowly in that transition, then it would've been a real struggle for us to keep up that momentum.
• 33:53
  SPEAKER_1: And then just to explain how that job fair worked, so you stack ranked of like, "All right, here's number one project, number two project," discussing with the people who decided and then people saw that that was a clear priority.
• 34:09
  SPEAKER_1: Did you also say, "Here's how many people were expecting?"
• 34:13
  SPEAKER_1: And then I guess people just worked out... I guess the top project probably got more applications, if you will, than you expected and you channel it down?
• 34:22
  SPEAKER_0: That's right.
• 34:23
  SPEAKER_1: What was the motivation?
• 34:24
  SPEAKER_1: You said it was good to have this shock to the system, which I agree, it sounds like a pretty disruptive, but I mean in a fun way.
• 34:32
  SPEAKER_0: Mostly fun.
• 34:33
  SPEAKER_1: Yeah, mostly fun.
• 34:34
  SPEAKER_1: But what was the thing that made you realize, "We should just do something where we have people choose the most important thing, try to balance those things?"
• 34:45
  SPEAKER_0: Some of those projects that we started in 2021 that I ultimately see or regret allowing us to get started with, and that would not make the cut today, they had a life of their own.
• 34:56
  SPEAKER_0: And it's not that they were terrible ideas, they were good plausible ideas, but they were not the ones that we were aligned as a company around as being the very top priority projects, and at the same time, we had people working on them that were working hard, that were satisfying customers with them, and it's hard to change that.
• 35:17
  SPEAKER_0: You cannot change that without a shock.
• 35:20
  SPEAKER_0: People were holding onto it and I don't blame them for it.
• 35:23
  SPEAKER_0: We needed to make that really clear that we needed them to change, that they weren't doing anything wrong per se, but that we needed the company's priorities to change.
• 35:32
  SPEAKER_0: And in a world that people were coming out of where there was always more headcount, you could always do more by adding more headcount, I think a lot of people had gotten used to the idea that if they were working on something that showed some promise, that they could keep doing that.
• 35:47
  SPEAKER_0: And you didn't see in 2021 a lot of, "Hey, this thing is good, but it's not as good as this other top priority."
• 35:54
  SPEAKER_0: So that shock to the system ultimately it mostly worked.
• 35:59
  SPEAKER_0: Going back, there'd be a lot of things that we could do to communicate it better, just be more upfront with this as a shift, but what's funny is I see how much of a mindfuck it was based on seeing how the sausage was made and how difficult it was and how many things we could have done better, but there's a lot of people on the outside who say, "Wow.
• 36:17
  SPEAKER_0: You shifted to AI so quickly, can you tell us how to do it?"
• 36:20
  SPEAKER_0: And VCs are having me talk to other portfolio companies.
• 36:22
  SPEAKER_0: So I think the grass is always greener.
• 36:24
  SPEAKER_1: I do sense that a lot of things that you're saying, we're kind of getting a little bit back to basics in the sense that my view is that it's a great company if everyone works on the stuff that they want to work on, but it's even a better company if it has a long-term future, which means that it actually has a business that they're focused on and the company communicates whatever that is.
• 36:45
  SPEAKER_1: And by the way, this business changes.
• 36:47
  SPEAKER_1: So in your case, this was clearly you've seen the future coming, which has now arrived, and sounds like you kind of just communicated this way.
• 36:56
  SPEAKER_0: And again, wish we had done it sooner, wish we'd done it more clearly, but we get better.
• 37:02
  SPEAKER_0: And I mean, ultimately every engineer wants to be working on something that's high-impact to the business and that is rewarding, and I really believe that in 2021, there were a lot of people that were afraid to tell engineers that something else was more important, more of a business priority, and there wasn't that kind of financial pressure.
• 37:21
  SPEAKER_0: So I think it's a much healthier, much more sustainable world that we're in today where developers working on something that has a clear tie to the business, they should feel a lot more secure.
• 37:30
  SPEAKER_0: They don't because the world has changed and they see even the big tech companies doing layoffs all the time, but if they're creating business value, then they should feel a lot more secure than they were kind of on a foundation of bubbly money.
• 37:43
  SPEAKER_1: No, I absolutely agree, and I think we're unfortunate that we're seeing big tech let go people even from profit centers or the cash cow businesses, but the reality is that the closer I look to... The companies that are either smaller or more rationally run, it is true that if you are adding business value and doing a good job, your position should be very secure.
• 38:07
  SPEAKER_1: And I think it's a great thing as a software engineer for you to have tools to know like, "Am I providing value for the business?"
• 38:15
  SPEAKER_1: And this goes back a little bit to what we talked to, would it not be nice to connect to your code changes to revenue?
• 38:21
  SPEAKER_1: I mean, there will be some downsides, but overall, I think there will be... If we even attempt to do that, and eventually we're going to get there for sure, we will have attempts and failures, but that's the history of software engineering, isn't it, in terms of failures?
• 38:36
  SPEAKER_0: Yeah, and AI can make it so software engineers are much closer to the customer, much closer to the value and don't need as many other kinds of people at the company.
• 38:45
  SPEAKER_1: This episode is brought to you by the EnterpriseReady Conference, a one-day event in SF, bringing together product and engineering leader shaping the future of enterprise SaaS.
• 38:53
  SPEAKER_1: The event features are curated list of speakers with direct experience building for the enterprise.
• 38:58
  SPEAKER_1: Speakers include people from OpenAI, Vanta, Checker, Dropbox, and Canva.
• 39:03
  SPEAKER_1: Topics include advanced identity management, compliance, encryption, and logging, essentially a complex features that most enterprise customers require.
• 39:11
  SPEAKER_1: If you're a founder, exec PM or engineer tasked with the enterprise roadmap, this conference is for you.
• 39:17
  SPEAKER_1: You'll get details, insights from industry leaders that have years of experience navigating the same challenges you face today, and best of all, it's completely free since it's hosted by WorkOS.
• 39:28
  SPEAKER_1: Spots are filling up quickly.
• 39:29
  SPEAKER_1: Make sure to request an invite at enterpriseready.com.
• 39:33
  SPEAKER_1: That is enterpriseready.com.
• 39:36
  SPEAKER_1: When it comes to compensation as Sourcegraph, you are very early to be transparent on the compensation that you offer, and now we've actually seen in the US multiple states have passed regulation that mandates doing exactly the same, so in California and in New York.
• 39:51
  SPEAKER_1: So a lot more companies in the US are now actually disclosing how much they're offering for the positions across the US, especially when they're hiring in California.
• 40:00
  SPEAKER_1: What is your take on this change?
• 40:04
  SPEAKER_1: We're seeing from a jobseeker's perspective, just more transparency on earnings.
• 40:11
  SPEAKER_0: I think that it's the right thing to do for most companies and they should do it.
• 40:17
  SPEAKER_0: That's why we've done it for a long time and we've had a pretty kind of sophisticated and transparent way of doing compensation.
• 40:25
  SPEAKER_0: It works for our team and we have always had to do some things differently, even being more transparent about this, because back when we started the company in 2013, devtools were weird.
• 40:39
  SPEAKER_0: We could not compete and pay the same salaries of someone in, I don't know, FinTech or social local mobile stuff in 2013 and SF, so we needed to cast a wide net.
• 40:50
  SPEAKER_0: We needed to find people that really loved what we were doing that were... First two people we hired, one was in South Africa, one was in Phoenix, and we needed to cast a wide net.
• 40:59
  SPEAKER_0: So a lot of the kind of weird practices that now a lot of companies are doing came about because we were forced to do it early on.
• 41:08
  SPEAKER_0: I don't know what the impact is though of this compensation transparency, because most of the people that are looking at these salaries, a lot of their compensation comes in the form of equity, and software engineers in general do an abysmal job of understanding the value of equity compensation, and what you see on Hacker News is people grumbling where they have not ever had a good outcome there.
• 41:35
  SPEAKER_0: The people that have had good outcomes, they don't go on Hacker News and comment back.
• 41:40
  SPEAKER_0: So there's a very skewed and very poor understanding overall of equity compensation and that's not included anywhere in the offer.
• 41:49
  SPEAKER_1: Yeah, that's true.
• 41:50
  SPEAKER_1: Well, I think is it is a step forward that we're actually seeing the cash part at least, and sometimes the bonus is included, so that gives you a baseline at least.
• 41:59
  SPEAKER_1: And I guess one thing that you are doing very differently is that you're offering the global... How do I say this correctly?
• 42:09
  SPEAKER_0: That's something we changed actually recently.
• 42:11
  SPEAKER_1: Oh, you've changed it?
• 42:12
  SPEAKER_0: Yeah, so one of the things that we used to do just initially out of simplicity is no matter where someone was located, we would pay the same amount for a given role, location-independent pay.
• 42:24
  SPEAKER_0: A couple months ago we moved to zone-based pay and thoughtful transition period.
• 42:30
  SPEAKER_0: This is a big change in many ways, and part of the reason why we did the location-independent was because it was a simple thing to do.
• 42:40
  SPEAKER_0: It's actually hard to come up with what is the right compensation multiplier for this city and the world and all these edge cases, and another thing is because there's a lot of appeals to the fairness of doing that.
• 42:53
  SPEAKER_0: What we've learned since then is there's a lot of ways that it is fairer, there's a lot of weird incentives that it sets up, and it ultimately means that everyone who does get the same equity compensation still as shareholders, a company that cannot hire efficiently is at a real disadvantage.
• 43:20
  SPEAKER_0: So we still pay well above median salary, we still are very competitive in compensation, but you just end up with these weird incentives.
• 43:30
  SPEAKER_0: And that's something that GitLab saw.
• 43:33
  SPEAKER_0: They are a company that many people might assume would do location-independent pay because they pioneered a lot of the all-remote stuff, but they never did that.
• 43:41
  SPEAKER_0: They always had zone-based pay.
• 43:43
  SPEAKER_0: And at a certain point we looked around and there was one company in the world that we could find that had more employees that was doing location-independent pay, and we looked at their stock chart and it was just a nosedive down.
• 43:53
  SPEAKER_0: So we were just a big aberration there.
• 43:57
  SPEAKER_1: It's interesting that you shared how your thinking has changed, because again, I feel that the companies evolve, the world also changes, and you just want to make sure that you're doing whatever makes the most sense based on where you are.
• 44:10
  SPEAKER_0: Yeah, that's right.
• 44:12
  SPEAKER_0: And for engineers really put on your shareholder hat and think, "If you didn't actually work at this company but you were just a shareholder, what is the right thing to do?"
• 44:22
  SPEAKER_0: And that's not just the financial side of it, it's the people working at the company want the company to stay around and they want to be able to retire or buy a house on the equity, and that shareholder hat, another way to think of it is put your shelf in the shoes of the CEO.
• 44:40
  SPEAKER_0: That is a mindset that I think software engineers would do well to adopt more.
• 44:44
  SPEAKER_0: I'm not saying always think that, but put that hat on a little bit more, and I think that that will make a lot of these decisions make a lot more sense and you'll probably find greater calm and understanding.
• 44:59
  SPEAKER_0: This kind of connected to understanding how you're actually creating customer value.
• 45:02
  SPEAKER_0: I think that'll give you a lot of calm.
• 45:05
  SPEAKER_1: Yeah, and I guess one thing that I definitely saw, what I looked into why companies stopped doing the same compensation globally is one thing that handcuffs you is you cannot hire from places where the median compensation is a lot higher, typically in some of the biggest tech hubs like New York, San Francisco, London, and that can be a choice, and especially early on that can make sense, but that's a definite downside.
• 45:32
  SPEAKER_1: Any company that does it either has to do weird workarounds of doing so or doing that, and you can already see that there's just no... Everything is a trade-off, right?
• 45:44
  SPEAKER_0: Yeah.
• 45:45
  SPEAKER_1: And as you say, I think you're right on it is worth thinking about the business side of things.
• 45:50
  SPEAKER_1: Again, if you're on a rocket ship, that's a great place to be in.
• 45:55
  SPEAKER_1: If you're on a plane that's kind slowly crashing down, it doesn't really matter if... It's a different flight, isn't it?
• 46:03
  SPEAKER_0: Yeah.
• 46:04
  SPEAKER_0: Yeah.
• 46:04
  SPEAKER_0: I think that any company that still maintains location-independent pay past 200 employees, I think it's a symptom of a company that struggles to be real with their employees and to treat them as shareholders, and that is the kind of thing that probably means that company is going to have a reckoning at some point in the future.
• 46:24
  SPEAKER_0: So you want to see companies that are thinking long-term, thinking shareholders, thinking, "How do we make money?"
• 46:30
  SPEAKER_0: Because ultimately that's where all the salaries come from, from making money.
• 46:35
  SPEAKER_1: You're better off with a company that's around for 80 more years than one that's not going to be around in two years.
• 46:40
  SPEAKER_0: Exactly.
• 46:41
  SPEAKER_1: Absolutely agree.
• 46:43
  SPEAKER_1: So you've now been a CEO at Sourcegraph for more than 10 years.
• 46:46
  SPEAKER_1: It's 11 years, isn't it?
• 46:48
  SPEAKER_0: Yeah, that's right.
• 46:50
  SPEAKER_1: Coming up.
• 46:50
  SPEAKER_1: So I was interested in a few things.
• 46:53
  SPEAKER_1: I don't think I know many software engineers who have been CEOs for this long, and I guess you've now been a CEO for way longer than you have been a software engineer, but just thinking back of when this whole thing started out, because you were a software engineer before, how was the initial transition into this CEO role back in 2013?
• 47:14
  SPEAKER_0: Well, when you're starting out, you feel like a software engineer because a founding technical CEO should be coding 95% of the time, and-
• 47:23
  SPEAKER_1: That's what you did.
• 47:24
  SPEAKER_0: That's what I was doing.
• 47:26
  SPEAKER_0: I remember that moment when Beyang and I coding up the first version of Sourcegraph and we had this spark when it saved us two or three weeks, because we found this piece of code that existed and we'd only been building it for a week.
• 47:38
  SPEAKER_0: So it was like a time machine, it had given us net time.
• 47:42
  SPEAKER_0: And it's been an absolute journey since then.
• 47:47
  SPEAKER_0: I have learned so much in particular once we really started to grow near the end of 2019 and-
• 47:55
  SPEAKER_1: How many of you were around that time and then after?
• 47:58
  SPEAKER_1: So I'm trying to figure out what the growth means.
• 48:01
  SPEAKER_0: Yeah, we were around 25 people at the end of 2019 and now we're around 180, just under 200.
• 48:10
  SPEAKER_0: So we've grown quite a bit, and I think software engineers, they naturally can do a lot of things.
• 48:21
  SPEAKER_0: If you're coding, even if it's not a software product for developers, you're going to be able to talk to your customers, you're going to be able to talk to investors.
• 48:32
  SPEAKER_0: People are very comfortable and familiar with the idea of a software engineer who's now a CEO.
• 48:37
  SPEAKER_0: Even in the Fortune 500 software engineer CEOs are very much over-represented relative to most other majors, like the CEO of United Airlines is a computer science major, and you can find so many examples like that.
• 48:48
  SPEAKER_0: So it's not that hard of a transition.
• 48:52
  SPEAKER_0: There's so many amazing advisors and mentors who will help, and for me... I think everyone's personality is different, but for me, the real growth was trusting my intuition because as you grow, a lot of people have really good advice, and also as you grow, they see a CEO who was CEO of the company when it had zero revenue and now when it has this much, and especially as a company that's quickly growing, you don't think the CEO is some expert genius that knows everything and every function, and the reality is they don't, but you still need a single direction, a single focus.
• 49:31
  SPEAKER_0: You need that CEO to be overruling to create that focus, and that can be tough because that ultimately means overruling people that probably know a little bit more in this direction about what the CEO is overruling, but the company needs a single direction ultimately.
• 49:47
  SPEAKER_0: And that was a struggle for me to learn because I would hire these really smart people and why wouldn't I just do everything they say and trust them fully?
• 49:55
  SPEAKER_0: And it's not about trust, it's about getting that alignment on a single direction.
• 49:59
  SPEAKER_0: That was tough and I've gotten a lot more confidence in that over the last couple of years as we've grown.
• 50:04
  SPEAKER_0: I see that in a lot of other software engineers too when they hire this expert salesperson or expert marketer, they can't fully just outsource that whole function.
• 50:15
  SPEAKER_1: And when you say you see it with a lot of other software engineers, you mean other software engineers turned CEOs?
• 50:20
  SPEAKER_0: That's right.
• 50:21
  SPEAKER_0: Yeah, a classic example is a company is starting to grow, they hire a marketer, and that marketer makes the website read just yuck, and they do these kind of slimy things and the CEO thinks, "Well, that person has been at other companies before," and a lot of times the marketer is like, "I've been at these other companies before, and the CEO set really clear ground rules about what we should and shouldn't do.
• 50:49
  SPEAKER_0: I don't hear any of that, so maybe I should do these things."
• 50:52
  SPEAKER_0: That has not happened at Sourcegraph, but that's exactly the kind of thing that I see, and you need the CEO to keep that ethos of what developers love and how do we win their hearts and minds.
• 51:04
  SPEAKER_0: Even if you have a great marketer that understands that they want to see the CEO enforcing that as well.
• 51:09
  SPEAKER_1: Do you think you have to go through this learning?
• 51:13
  SPEAKER_1: I mean, clearly it's very efficient when you do, or how much of the mistakes that you've done do you think could have been avoidable if only you've listened to, I don't know, better advisors, or how much is this just part of the job of building something new?
• 51:29
  SPEAKER_0: I wish I'd listened to my co-founder a lot more.
• 51:32
  SPEAKER_0: We talk every single day.
• 51:33
  SPEAKER_0: I was just talking to him as I was heading over here.
• 51:35
  SPEAKER_0: He has a really strong conviction and is just really good at catching me when I become a little weak or I'm too nice or something like that.
• 51:51
  SPEAKER_0: So having a co-founder is really good.
• 51:53
  SPEAKER_0: And other people that have been through the times, especially if you're going through a real growth phase, that have been through the times when it wasn't a growth phase, they will have more of a sense of scarcity and more directness, but the advice you get, unless it's from a very close board member or advisor who's really in it, who's sitting in your exec meetings, I think it's probably going to just be platitudes, and there's so much advice out there that if you're a CEO and you're going on Twitter or Hacker News, all you hear is people complaining about their CEO and talking about the dumb things their CEO does, and that can create this mentality as a CEO...
• 52:32
  SPEAKER_0: People assume CEOs are these super confident people, but actually we're just humans, and if all you read is how every other CEO is dumb, well, naturally you're going to start thinking all your employees think that you're dumb and that's going to make you lose confidence, and when I say you, I mean that's how I felt.
• 52:46
  SPEAKER_0: So just seeing enough times of that failing and then really great co-founder, really great board, and now a really great exec team.
• 52:54
  SPEAKER_0: Much better position now.
• 52:56
  SPEAKER_0: But I think it's hard to learn, to just come into the job having that kind of confidence, and most of the times that someone does come in, it's probably overconfidence because you do need to take some feedback.
• 53:10
  SPEAKER_0: Finding that the right amount of feedback to take is really hard.
• 53:13
  SPEAKER_1: Can you summarize how a week of yours or a day of yours, probably a week is a better one, looked like when you were starting out a few years in, when you had let's say 10 people at Sourcegraph and how it looks these days?
• 53:27
  SPEAKER_1: And I'm asking this because I think there's a lot of software engineers who, again, one day they're thinking, "I'm in this job at the start-up or scale-up.
• 53:35
  SPEAKER_1: I'm learning all the skills.
• 53:36
  SPEAKER_1: I'd one day like to start out and do my thing, maybe even become CEO," just like you have because we do see software engineers being CEOs, and it's always nice to get a little bit of window on what it actually looks like.
• 53:48
  SPEAKER_0: Yeah, starting out I closed the loop with the customer.
• 53:52
  SPEAKER_0: So I would build something with our other engineers and I would get it to the customer or user, I would be the one emailing with them to make sure it was actually useful, I would go visit them, and I was involved in every part of the loop, and as we've grown, I've become less involved in some parts of the loop just because I can't and I need to focus in some areas, but the thing that I think every software engineer should do is for the thing they're building, follow it all the way through to the customer actually using it.
• 54:25
  SPEAKER_0: Stay like a dog holding onto that and see, and then iterate with that customer.
• 54:32
  SPEAKER_0: Whatever feedback they have, turn around and fix really quickly even if that means saying, "No, I can't take on more work in this sprint because my thing will be delivered to the customer."
• 54:41
  SPEAKER_0: By the way, any engineering manager or product manager who hears that from an engineer will be so happy.
• 54:47
  SPEAKER_0: They'll be so happy to not give you more work.
• 54:49
  SPEAKER_0: They love to have engineers follow through.
• 54:53
  SPEAKER_0: And for me, I just got to pick what parts do I want to be focused on, and now it's much more at the other end.
• 55:03
  SPEAKER_0: It's earlier on in the product, like what is the future of the product and how can all the different things we're doing slot in together?
• 55:11
  SPEAKER_0: How can us bringing in more context make it so that Cody today gets better and Code Search and the stuff we do with agents and automating software gets better?
• 55:20
  SPEAKER_0: There's technical stuff there, but there's also strategy.
• 55:24
  SPEAKER_0: And then also with customers, it's not the minutes after we deliver a new version to them, but it's after they've been using it for a few weeks, going in and visiting them, sitting with their users.
• 55:34
  SPEAKER_0: And the thing that I love as much as coding is getting in a room at a customer site with 20 people who use Sourcegraph and just hearing their complaints, hearing their feedback, and I might show a couple of slides, but then we just get our laptops, we sit next to each other and I show them how I use it, they show me how they use it, point out ideas, and I absolutely love that.
• 55:59
  SPEAKER_0: So that's a week in the life.
• 56:01
  SPEAKER_1: Well, and that's just what you did, right?
• 56:03
  SPEAKER_1: That's why you're in Amsterdam.
• 56:04
  SPEAKER_0: Yeah, that's why I'm in Amsterdam.
• 56:06
  SPEAKER_1: I mean, this sounds very different to how I would've imagined the CEO.
• 56:11
  SPEAKER_1: My imagination would've been like, "Oh, I have a lot of meetings.
• 56:15
  SPEAKER_1: I set strategy.
• 56:16
  SPEAKER_1: I meet with my exec team.
• 56:18
  SPEAKER_1: I have one-on-ones," but what you've described was very different.
• 56:23
  SPEAKER_1: It sounds like you're doing... And correct me if I'm wrong, but it sounds like you're prioritizing way more of like, "All right, let me be out with either the customers and see how they're doing it or in the product, see what's going on."
• 56:38
  SPEAKER_1: The things I didn't hear you say is meetings, alignment, strategy, OKRs.
• 56:43
  SPEAKER_0: I do that stuff too, but it's a little more boring and I now have that confidence to admit that's boring.
• 56:52
  SPEAKER_0: There's so much advice out there that says CEOs need to just be doing that stuff, but ultimately, if you're product company, the product and the customer, those are so important, and if you get those right, other things are so much easier.
• 57:04
  SPEAKER_0: If I am explaining or communicating or aligning some strategy and I bring back, "Hey, here's what the customer said to me yesterday when I was in Amsterdam," that means that whatever I'm saying is probably going to be more right, and other people are going to get aligned around it better.
• 57:25
  SPEAKER_0: If instead I do a ton of work to make an awesome strategy doc and slides, but I don't bring in that visceral sense of the product and customer voice, one, it's probably going to be wrong, and two, everyone's going to think that's a bunch of bullshit.
• 57:37
  SPEAKER_1: Is it fair to say that you've kind of found what is important?
• 57:41
  SPEAKER_1: Because what I sense from your job, you have 180 people in the company, so many customers, your email inbox probably is flooded with things.
• 57:51
  SPEAKER_1: There's just too much to take on as a person, but what I'm sensing is you actually figure it out what is important, the number one, and then you probably do a best effort everywhere else, but you make sure that these things, the customers and the product, you do that and you clear that out.
• 58:06
  SPEAKER_0: Yeah, that's right.
• 58:07
  SPEAKER_0: And if I'm not able to focus on customers and product, then I figure out how I can get into a state where I can get back to that, and that means getting the right leaders, getting the right alignment, but I try to fix that as quickly as possible.
• 58:21
  SPEAKER_1: This is awesome.
• 58:21
  SPEAKER_1: It's also encouraging to hear, because I think when I think of as a software engineer, if me or if someone in my position will one day become in your position, which is a CEO of a pretty big company, I would have... my initial fear would be it must be overwhelming and you're pulled in all these directions, and unless you've been an exec or someone else, you can't even do it, but you're the proof that you can do it and you can figure out how to actually... It sounds like you're actually having fun with this.
• 58:49
  SPEAKER_0: Oh, yeah.
• 58:50
  SPEAKER_0: I have a ton of fun and I make a point to do things that I consider fun, because I will do those things 100 times better than the things that I think are boring, and I believe that Sourcegraph is will be incredibly successful.
• 59:06
  SPEAKER_0: Ultimately, that's going to be the test though.
• 59:09
  SPEAKER_0: So let's come back in 10 years and let's see how this goes.
• 59:15
  SPEAKER_1: Let's go back.
• 59:16
  SPEAKER_1: Let's wrap-up with some rapid questions if you're okay with that?
• 59:19
  SPEAKER_0: Yeah.
• 59:20
  SPEAKER_1: So I'll just ask a question and just shoot what comes to mind, and it doesn't need to be long, it's just the first thing or the first answer, so sound good?
• 59:34
  SPEAKER_0: Yeah.
• 59:34
  SPEAKER_1: So what was your first programming language?
• 59:37
  SPEAKER_0: Perl.
• 59:38
  SPEAKER_1: Perl.
• 59:39
  SPEAKER_1: Do you still use it?
• 59:41
  SPEAKER_1: Love it?
• 59:41
  SPEAKER_1: Hate it?
• 59:42
  SPEAKER_0: I've not used it.
• 59:43
  SPEAKER_0: I understand that Perl is quite big in Amsterdam.
• 59:46
  SPEAKER_0: Dutch and Perl are the two languages of Amsterdam, and I love all programming languages, but have not used Perl since 1999 or 2000.
• 59:57
  SPEAKER_1: You're probably not alone with it, but the booking.com folks will be using it.
• 1:00:01
  SPEAKER_1: They have a few hundred thousand lines of code, but they're the biggest Perl.
• 1:00:05
  SPEAKER_0: It's an amazing company.
• 1:00:06
  SPEAKER_0: They've done amazing things with it.
• 1:00:09
  SPEAKER_1: Yeah.
• 1:00:09
  SPEAKER_1: What is a handy utility or app that you use that is not related to Sourcegraph through your day-to-day or anywhere else?
• 1:00:17
  SPEAKER_0: Getting the right screenshot or screen recording tool is critical and then you'll use it like 10 times a day.
• 1:00:24
  SPEAKER_0: So also Loom is a really good one.
• 1:00:26
  SPEAKER_0: Loom, CleanShot and Kazam.
• 1:00:29
  SPEAKER_1: What is Kazam?
• 1:00:30
  SPEAKER_0: It's on Linux, but screen recording.
• 1:00:34
  SPEAKER_1: Awesome.
• 1:00:35
  SPEAKER_1: What is an exciting early-stage startup that you know of?
• 1:00:39
  SPEAKER_0: I love Ollama, which lets you run AI models on your laptop, local inference, and when some new open-source model drops, they have it available in minutes it seems, and it's amazing.
• 1:00:52
  SPEAKER_0: And you also can build so many things on top of it.
• 1:00:55
  SPEAKER_0: So Cody supports Ollama, so you can be in a Faraday cage on an airplane over the Pacific and you can still get Auto-complete because it's Ollama running locally using StarCoder II or Llama.
• 1:01:06
  SPEAKER_1: Oh, not anything you would've done, would you?
• 1:01:10
  SPEAKER_1: What's your favorite book or a favorite book?
• 1:01:14
  SPEAKER_0: I love the LBJ biographies, the Lyndon Baines Johnson, a U.S.
• 1:01:19
  SPEAKER_0: President back in middle of the 20th century by Robert Caro.
• 1:01:25
  SPEAKER_0: They are the most in-depth biographies ever, and you really get to learn about someone.
• 1:01:30
  SPEAKER_0: It's about 4,000 pages, so it's quite an investment, but highly recommended.
• 1:01:35
  SPEAKER_1: Any biographies that you've enjoyed recently?
• 1:01:38
  SPEAKER_0: I'm reading one about Gandhi now and have read one about Admiral Nimitz from the World War II in the Pacific.
• 1:01:49
  SPEAKER_0: I love biographies.
• 1:01:50
  SPEAKER_0: Just for me, understanding how other people came to make these really hard decisions, and one thing that always strikes me going back to this idea of finding the fun in your job is you read about the Admiral that was leading the U.S.
• 1:02:05
  SPEAKER_0: war effort in World War II, and he golfs and plays tennis all the time, and when he goes back from the front to Honolulu, it must take him weeks, and we have this idea that everyone must be on all the time, and in many cases doing things that they don't like, but I think so many great people in history realize that if you can make a few good decisions every single year, then that's what matters most in a leadership position.
• 1:02:33
  SPEAKER_0: So that gives me a nice sense of what are those few decisions that I need to make?
• 1:02:39
  SPEAKER_0: And it's not about being in every single little thing.
• 1:02:41
  SPEAKER_1: How can listeners be helpful to you?
• 1:02:43
  SPEAKER_0: Keep coding, keep writing a lot of code, and when you try new AI tools when coding hold a really high standard and bring that feedback back.
• 1:02:52
  SPEAKER_0: There's a lot of hype out there.
• 1:02:54
  SPEAKER_0: I think though, that where we are today is so early and we're only going to get there by software engineers seeing through the hype and actually making sure that these tools are incredibly useful for people doing all kinds of things.
• 1:03:05
  SPEAKER_0: So feel comfortable saying that the emperor has no clothes and push all of these tools to get better and better.
• 1:03:12
  SPEAKER_1: So I guess try this stuff, but then validate and just keep it real, right?
• 1:03:17
  SPEAKER_0: Yeah, that's right.
• 1:03:18
  SPEAKER_1: Awesome.
• 1:03:19
  SPEAKER_1: It was great to have you here today.
• 1:03:21
  SPEAKER_0: Thank you.
• 1:03:21
  SPEAKER_0: It's great to be here.
• 1:03:22
  SPEAKER_0: I'm a longtime reader, a longtime fan, and it's awesome to be here.
• 1:03:26
  SPEAKER_0: Thank you.
• 1:03:28
  SPEAKER_1: Awesome to have you.
• 1:03:28
  SPEAKER_1: Thanks a lot to Quinn for this conversation and for sharing more on how Sourcegraph operates with insider details.
• 1:03:34
  SPEAKER_1: Here are my three takeaways from this episode.
• 1:03:36
  SPEAKER_1: Takeaway number one, as software engineers, it's increasingly important to understand what value you add to the business.
• 1:03:43
  SPEAKER_1: A big difference between 2021 and 2024 is how companies are much more focused on efficiency.
• 1:03:48
  SPEAKER_1: This means they're hiring more conservatively and less likely to fund teams with headcount that doesn't contribute to the focus of the company.
• 1:03:55
  SPEAKER_1: As a developer or manager, try to figure out how much your team contributes to revenue or savings or other key goals of the company.
• 1:04:02
  SPEAKER_1: Are you working in what the company would consider a profit center or what is more of a cost center?
• 1:04:08
  SPEAKER_1: We did a deep dive on this topic in the Pragmatic Engineer.
• 1:04:10
  SPEAKER_1: Check out the article linked in the show notes below.
• 1:04:13
  SPEAKER_1: Takeaway number two, AI tools are great to eliminate the toil that developers face.
• 1:04:18
  SPEAKER_1: There are AI tools that position themselves as their goal being to replace developers or replace whatever job they're trying to do.
• 1:04:27
  SPEAKER_1: I found it sympathetic that Quinn did not think this is a sensible path.
• 1:04:30
  SPEAKER_1: His approach is to start by using AI tools with some of the dumbest things, like generating the changelog for a software release.
• 1:04:37
  SPEAKER_1: I mean, assuming you generate a changelog.
• 1:04:39
  SPEAKER_1: And then you can take tedious tasks where these tools could help and see if you can automate some more.
• 1:04:44
  SPEAKER_1: Do this one step at a time, and it will actually help devs and teams, and it's a lot more achievable than saying, "Let's replace this whole complicated workflow with AI."
• 1:04:53
  SPEAKER_1: Takeaway number three, the reality of location-independent pay is that it stops being sensible above a certain company size.
• 1:05:00
  SPEAKER_1: Sourcegraph was one of the few companies that offered the same base salary regardless of where people worked at.
• 1:05:05
  SPEAKER_1: They did this until they grew to about 200 people and then switched this model to a location-index model.
• 1:05:11
  SPEAKER_1: Quinn was honest about why they did it.
• 1:05:13
  SPEAKER_1: It was because keeping this location-independent pay would've not made for the company from a business point of view.
• 1:05:19
  SPEAKER_1: Basically, location-independent pay means that the company can hire very easily in low-cost regions, but it can be hard or even impossible to do this in high-cost regions.
• 1:05:27
  SPEAKER_1: It also creates this weird incentive where employees are incentivized to move to a low-cost region where they can save more.
• 1:05:33
  SPEAKER_1: In the end, I don't know of any company that with more than 200 people that pays location-independent.
• 1:05:38
  SPEAKER_1: All large companies have some kind of indexing it on location, and the best company is just pay the top of the local market.
• 1:05:44
  SPEAKER_1: We cover more about compensation in the article, the Trimodal Nature of Software Engineering Salaries in the Pragmatic Engineer, which you can check out in the show notes below.
• 1:05:52
  SPEAKER_1: Finally, if you'd like to find Quinn online, you can do so on his blog, slack.org and on Twitter/X and LinkedIn as linked in the show notes below.
• 1:06:01
  SPEAKER_1: If you'd like to learn more about Sourcegraph's engineering culture, check out the two-part deep dive published in The Pragmatic Engineer called Inside Sourcegraph Engineering Culture also linked in the show notes.
• 1:06:10
  SPEAKER_1: This was the second episode of The Pragmatic Engineer Podcast.
• 1:06:13
  SPEAKER_1: Thanks a lot for listening and watching.
• 1:06:15
  SPEAKER_1: If you enjoy this episode, I very much appreciate if you would subscribe and leave a review.
• 1:06:19
  SPEAKER_1: Thanks, and see you in the next one.