#048 – Shaping the Future of Software Development with Idan Gazit (GitHub Next)

Itiel Shwartz: Hello everyone and welcome to another episodes of the Kubernetes for humans podcast. My name is Itiel Shwartz and today with me in the show we have Idan Gazit. Idan, can you please introduce yourself?

Idan Gazit: Hi, my name is Idan and I lead a team at GitHub called GitHub Next, which is the team that originally created GitHub Copilot and then like 50 other things, Copilot Workspace. and I’m going to be like the least knowledgeable about Kubernetes person that this podcast has ever seen

Idan Gazit: because uh, thankfully I got to skip right over most of the Kubernetes time. I was I was at Heroku where we had our own thing for containers.

Itiel Shwartz: If you come from Heroku like your you know your dislike towards Kubernetes makes more sense maybe.

Idan Gazit: I don’t I don’t dislike that’s Hold on. Wait, wait, wait. We’re starting off on the wrong foot here. I don’t dislike Kubernetes. I’m just an idiot. There’s a very big difference between those two things.

Itiel Shwartz: Yeah. But Kubernetes is so nice that once you get to know him, like you are either an immediate fan or you know you don’t really want to you want anything to do with it. And I think Heroku is like in a way the opposite of Kubernetes like much more opinionated, right? Much more I’ll give you what you want. But you know maybe you you share about your like journey story and then we bump maybe into Heroku versus Kubernetes.

Idan Gazit: yeah uh my journey uh doesn’t make sense at all. It’s not it’s all over the place. I’m like a designer slashdeveloper slash product mix in in English. Everybody everybody knows like the idiom jack of all trades, but everybody forgets the back half of the idiom, which is in master of none. so yeah, I’ve I’ve sort of I’ve done a little bit of a lot of different things, which is great for my current job where we need to do all kinds of different things as part of chasing how do we make software development better. and of course, how we run our software is a big part of how we make our software. So to in that context is where I sort of give a [expletive] about Kubernetes and it’s clearly a dominant way that people package up applications at scale nowadays. uh, and sort of how do we how do we reason about that and how do we make it so that it’s easy to do at scale, but it’s also easy to do not at scale. I think the sort of the common critique of of Kubernetes is like it’s great if you’re a Google which you know obviously that was kind of the point. um less great if you’re like you know three people you know is one of the common failure modes of startups is like I know we’re gonna use Kubernetes and then three minutes later they’re just like oh no um because it’s complicated you know it’s not easy to do things at scale um and it’s not always right to take tools for at scale and pretend like you’re going to have a good time doing like little like I have five servers um um so so yeah so my journey is all over the place. I know enough to be dangerous in some contexts. but that’s about it. So um um

Itiel Shwartz: maybe share like the key highlights like how did you ended up in Heroku and then GitHub and like what are like give give like the most of the journey.

Idan Gazit: well I’ve always been sort of like uh I’ve always been a web technologies guy. uh and that led me to um I mean like because I’m ancient like the dinosaurs, you know, I got my start in web stuff doing Perl back in the day like a zillion years ago. and then later, you know, I did uh all kinds of stuff and eventually I found my way to the uh Django community, which is where I really fell in love with the community for the first time.

Itiel Shwartz: Like the Python Django community, right? Like for all of our not like

Idan Gazit: Yes, exactly.

Itiel Shwartz: Python fanboys, I do like Python, but don’t I don’t really like Django. It always felt very like a cult kind of framework like either you get it or you did or you don’t and I never got it. So yeah, share a bit about that.

Idan Gazit: So I was I was eventually I joined the Django core team.

Idan Gazit: I fully drank the Kool-Aid. I was a member of the cult.

Idan Gazit: and um I loved it because for a number of reasons. at the time I remember I was looking at at um web technologies that were like the post-PHP era, right? PHP was like everybody was just like blah like all of my logic, all of my display, everything like you know mix all the concerns into one file. The benefit of PHP is that you know going from nothing to I have a little web thing was very very fast. But as soon as you wanted to scale that, it got messy. And so the at the time the response to PHP was Django for Python or Rails for Ruby. Yeah.

Idan Gazit: And Rails was obviously very very popular, but I never really vibed with Ruby even though I did Perl way back in the day. uh and I didn’t vibe with Rails. like the whole convention over configuration always felt like too much magic to me. Whereas Django put a lot of emphasis on sort of readability, backwards compatibility, documentation. Like when I was getting started with the stuff and I was looking at Rails, the answer was go buy the book. which is fine, but like with Django, it’s just like go read the Django documentation, which is really, really good because it was written by a bunch of like English nerds who worked at a newspaper. and so the documentation was really fantastic. And I just loved the culture around how do we make this better? How do we move the web forward? What do we care about making easier? and so that’s what led me to get involved with Django. And then on the back of my sort of uh work in and around the Django community, I ended up at Heroku because there were some other Python people there that I knew and um um so yeah, so I uh I spent uh five and a half almost six years at at Heroku. um post Salesforce acquisition. you know, I wasn’t there before the acquisition. and uh and then yeah, and then when I when I left uh Heroku, I uh I talked with Jason Warner, who was he was SVP of Engineering at at Heroku before he left to GitHub a couple years before I left Heroku. Yeah.

Idan Gazit: So when I left Heroku, I caught up with Jason. I’m like, what are you doing? And he’s just like, well, I’m starting up this new group at GitHub, the office of the CTO, and our job is to is going to be looking at the future of software development. How do we make it better? How do we um make software development easier and more accessible to more people?

Itiel Shwartz: That’s true.

Idan Gazit: And uh and I remember asking him like, how much does GitHub give a [expletive] about this? And he was just like, I don’t know. Let’s find out. so uh and so I was just like, okay, cool. I’m in. Let’s go. uh and and the rest is as they say history. So

Itiel Shwartz: So no, like that’s a super interesting and indeed unique unique story. So you know now that you know what you know like does GitHub like give a [expletive] on that like what’s your thesis? What’s the company thesis? Like what really makes like GitHub tick like in the end of the day it is a big company right? like even a very big even a very big company. So you know share with us your journey there.

Idan Gazit: I mean you’re right GitHub is you know it’s a few thousand people it’s and it we’re inside Microsoft which is

Itiel Shwartz: many many thousands of people. I don’t remember like how much I think it’s like 200,000 people all of Microsoft order of I don’t know exactly. um

Idan Gazit: GitHub is it’s not one thing you know at the end of the day right now GitHub is where everybody collaborates on code. My job is not to make GitHub. My job is to break GitHub uh on some level. My job is to figure out um what GitHub should be in a couple of years. And it says research in my title, but that’s not really true. My job is prototyping. which is not the same as research. Like research is, you know, there’s Microsoft research. Their job is to publish papers about like ah we found like, you know, an n login like complexity like way to search through some data structure. I don’t know like you know that’s when I think research that’s the kind of stuff I I think about and at next our job is well we think we figured out something good and so we build like a shitty version of it um as a prototype and then we can hold that up and say we believe that this is a bet worth making with the bigger business of GitHub. and if GitHub’s leadership agrees with us, if we’ve done our jobs, we’ve made the prototype, we’ve researched it in a user research, like we put it into contact with users. So, it’s a little bit like building a startup over and over again, but it’s small scale and no venture capital and no fundraising, which is great. uh, I just get to focus on what’s going to make life better for software developers in any context whatsoever. And I like the fact that my job is to give a [expletive] about the developer experience of everyone. and that’s great. I love it. So, um, like broader GitHub is, you know, it’s a big business. And

Itiel Shwartz: now, you know, with AI being there’s all this energy around AI and a lot of people are like, oh, it’s good or it’s bad or whatever. But at the end of the day, even setting aside, you know, whatever people’s personal opinions are about AI, I can’t point to another technology that gives us higher leverage over the future of developer development experiences. Like, you know, what other technology am I going to mess around with that’s going to deliver as much impact? Like, could it suck? Absolutely. If we don’t give enough of a [expletive] to make it good. like you know if we give enough of a [expletive] then we’ll make it good and then it won’t suck but like it requires somebody caring and so that’s what we do and now this is a big part of GitHub’s business you know like Copilot is a big deal both revenue-wise and you know sort of positioning wise you know leadership is very publicly stated you know we’re an AI company now and yeah okay everybody else is saying that too but I think in GitHub’s case it mean something because that technology has such impact on the lives of developers. So um

Idan Gazit: so so yeah I don’t know it’s a messy answer

Itiel Shwartz: and like I think it’s like a messy word but you know like you said something that it’s like building like multiple startups in a in a single place like what’s the main driver like you know when I think on GitHub and I’m sure that’s not the case but I think on you know like a nice UI over like Git obviously right like that’s that’s the core right I share I collaborate operate it triggers my CI/CD which is nice but like we don’t use GitHub Actions for for example so like what will be a good day what will be a success what’s the main KPI that you guys are striving is it to make developers happy to bring more developers save time yeah like multiple questions here

Idan Gazit: I mean on some level the my answer is yes

Idan Gazit: yes yes to everything um there is what GitHub the bigger business cares about. I can speak less to that because that’s like corporate priorities and there’s bazillion people and whatever is like the message du jour. I’m not going to get in the way of that. My job is not to give a [expletive] about the message today. My job is to look into the future and try to understand what it’s going to look like. For example, what if AI could write code alongside me as a developer? Like, is that likely to succeed? No, it wasn’t. You know, when we were starting out on that, but if it succeeds, that would be a huge deal, right? And so, my job is to to scout that out. Our job is not to ship the final product of everything. Our job is to scout away from where the business is today to find new sources of food for us um and to figure out what’s going to be good, right? Like you know what’s a source of food for GitHub? Well, something that has value for developers. So my job is finding value um and like what’s the KPI of that? How many things escape the lab? like you know if we make something and it’s good good enough that it grows up to be a product that earns revenue that’s success um you know but the nice part of this is that I get to also care about what makes developers lives better in a lot of jobs caring about revenue is the only thing right like you know it’s like did we find revenue great

Idan Gazit: in my case like what’s good for revenue new also has not 100% but a lot of overlap with what’s good for developers. and finding ways to make developers like more powerful, more aware like of more things um uh like you know right now how is my code performing in production? I don’t know. Do I have like some kind of monitoring system that’s telling me this? Is it good? Did I have to figure out how to monitor it? I don’t know. That sucks. What I really want is like while I’m typing my code for like, you know, I think a lot about Iron Man and JARVIS, you know, it’s like, you know, it’s like I want Jarvis to be like, um, I profiled the code that you’re typing and it’s going to result in like a 30% hit to your p95 latency. That’s a bad bad maybe you don’t want to do this, right? I don’t want to wait until I’ve finished like my coding. I’ve done a PR. Everybody’s reviewed it. I’ve merged it. CI ran, my tests were green, and then finally got packaged up and deployed. And then it ran. And only then do I discover, oops, I tanked the performance. Right? That’s a long time to wait to find that out. Why? in the future if I wave a magic wand and I have fantasy developer future why can’t I find that out at development time like um so production like if you think about sort of the software development life cycle you know everything from like here’s where I design and author code here’s where I collaborate on code this is what GitHub owns right uh here’s where code runs and how it runs and how I monitor it. Like I want all of that to be a holistic thing where like information can flow freely from each stage to all the other stages so that I can be smarter sooner. um that’s you know a good example of like you know wave a magic wand. How do I make things better for developers? Make them smarter, sooner, faster. that no I think it’s a it’s a very interesting point you know when I look at the competition le let’s say GitLab right like is like a notable like competition they are putting a lot of emphasis on the completeness of the solution or at least they try like to take you from the very boring static code all the way to production with GitHub I always feel like it’s It’s not really there. It’s not really the like production and GitHub to me feel very very far far from one another. So, do you think like it’s different? Is it going to change? Is it interesting? Does it make sense?

Idan Gazit: the shorter answer is I don’t know. And also, this is the spicy part. I don’t care. um or it’s not really that I don’t care. I think I care in the broader business sense. Yeah.

Idan Gazit: But um like you know how complete is our product offering? You know like I don’t know what the feature matrix looks like between us and GitLab and and that’s the part I don’t care about because my job is not to like do this feature or this incremental improvement. It is to create a whole new column in this feature matrix that nobody else has. and so when I think about what that’s like, you know, it’s like I don’t care about refining. This is what I mean when I say my job is not to make GitHub, it’s to break GitHub. It’s not about refining the product we already have. It’s about like taking big jumps forward. These are bets and they’re risky bets. And if the rest of the business spent their time like making risky bets, they would fail more often than they want to because part of betting is losing. uh and the broader business doesn’t want to lose, right? Like you know, it’s like ah this is where our revenue comes from. We can’t afford to mess this up. But the more speculative things that are like further out there um those those require you know a tolerance for we tried something and we failed. um and we learned

Itiel Shwartz: give me your most like you know interesting like failure in in you know in all of this journey and you know you define interesting like everything goes.

Idan Gazit: man, I’ve got a lot. First of all, like you can go to GitHubnext.com and you’ll see every project that we’ve worked on.

Idan Gazit: including the ones that we killed. I think that’s an important thing like part of having a team like Next is being willing to kill your babies. um uh like in cold blood, you know, it’s a really important part of it because like we’ll try

Itiel Shwartz: of the episode like I hope I hope you wrote it down

Idan Gazit: killing babies in like this is indeed a surprise. well, it’s like you work on something and you care about it. You know, it’s like you’ve you’ve you’ve you’ve you’ve taken care of it for like, you know, some amount of time and in many cases you believe that there’s value there. It’s like there’s too much smoke for there not to be a fire

Idan Gazit: um in that direction, but sometimes we just don’t got it. Sometimes the tech is not ready. you know, even when I rewind two years and I think about like, you know, you look now at at at GitHub Spark, which is one of our more recent projects, which basically like what if I could go from natural language to app. We tried this a couple of years ago in the form of a project called SpecLang, which was basically like what if I can compile markdown files into uh apps, right? And at the time, the models just weren’t good enough for it. And also we didn’t have the knowhow to like uh effectively prompt the models into doing this reliably enough. Like it worked 50% of the time, but getting it to work 80 90% of the time is what’s needed for it to go from being a toy to being a tool. and so two years ago we couldn’t turn it into a tool. Now it’s definitely good enough to be a tool in some constrained context. Like would I build consumer-facing super polished apps with spark? No. But most apps are not that. Most apps like their competition is a spreadsheet. I want to do something better than Excel. for like you know the 90% of people you know like I need a basic business dashboard. It doesn’t need to be super slick. It just needs to be functional and clean, you know, and can can I can I have that? Like a couple years ago that So, was SpecLang a failure at the time? It was just like, well, this failed. We’re going to kill it. um uh but was it really a failure? No. Almost always things that we kill are really what I’m trying to like get us to call it just shelving it. I’m sticking it on the shelf because eventually they come back off the shelf in the form of ingredients in future projects. uh but we also have projects that straight up failed like you know I worked very hard on a thing called GitHub Blocks for a year. and the idea was was like extensibility of GitHub.com itself like what if in addition to just having like renderers like I have a mermaid file or a YAML file like you know give me instead of just here’s the text of the file show me something but like what if we could actually have like little apps that run there right um and so we built this out and I think we learned a lot about like what a good contract for extensibility would look like. but we just failed to find traction with it. Like you know, we fielded a technical preview, people played with it, they made some really cool stuff, but not enough that it got GitHub the business to care about it. And I think maybe the important lesson to learn there is if you’re working on innovation things, success is it escaped the lab. Why did it not succeed? It doesn’t matter if the reason was the idea wasn’t good, the execution wasn’t good, the rest of the business had other priorities that still won out over this, or I just couldn’t find a way to persuade the rest of the business to go on that adventure. Whatever the net result is, it didn’t escape the lab. So, it was a failure. do I feel sad about that? Sure. What would have made me feel happier about it if id killed it sooner?

Itiel Shwartz: so you know I think like in the end of the day very much like you know every startup you are trying to find your product-market fit right like building something that if it really works it will be great the problem as most startup you know face themsel is that the line between like huge success and failure is very blurry in another day right like um what’s your take how do I know how do I know that like in a month or a week or whatever. I’m not on the verge of like a huge success for GitHub. How do I decide when to kill the baby in your own words?

Idan Gazit: it’s a good question and I don’t have a flowchart for it. uh unfortunately I would really love to have a flowchart for this um because um it really depends on what’s the scale of the effort. Not everything at next is like there’s definitely sort of let’s call it sort of tiers or categories of of like you know ambition um and really good ideas in like you need to leave like the nuanced part of this uh and business is not good at nuance ever. They always want flowcharts. um is really interesting ideas in the beginning are usually scary and hard to understand. And so you need to leave enough time for them to like figure out their voice and what they want to be like you know um and sometimes it’s just about like you know what’s the framing, what’s the application and you need to leave like room for the people the talent on your team to like figure that out. I think the way that we think about it at Next is um that increasing traction extends the lifetime. Like we’re always hitting reset on like a timer that’s always running out. and either something like makes progress and earns another month of life or not like you know. And so we’re always thinking about like okay like what do we need in order to make progress? Well, we need to prove like this or that part of like the technical thing. Okay, we’ve succeeded at that. We have another month. Now what? Well, now we need to crack something about the UI of it. Okay, we succeeded at that. What about what’s the next thing? Okay, now we need to start getting more people to use it, not just us. um and seeing you know so it’s this is the idiom in Hebrew is like I’ve discovered America like you know right um this is whatever

Itiel Shwartz: it doesn’t work in English like I discovered America it’s not a phrase you know both of us are like Israelis right

Idan Gazit: yeah so I don’t know I would really like to use this it’s not just it’s I’ve discovered America the full name is I’ve discovered America for you um right um like uh so no I don’t I don’t I would really like to use this in English more often but I don’t think I don’t think folks in America would get it necessarily because it’s like what do you mean discovered America’s right here all around me like um so but it’s like we’ve discovered a new continent on the other side of the ocean for every startup what I’ve just described is like yep that sounds like Tuesday um you know every day at a startup is like that but so in that sense is very very familiar but we have a few different efforts going on at once because it’s like a startup-incubation group. and we have a clear path to production. What we need to do is prove some amount of product-market fit and that’s different for different things. And so it depends what’s the like ambition. Sometimes the core challenge is in the user experience. Sometimes the core challenge is in the underlying technology, the prompting, the whatever. Very frequently it’s both. And so like what’s going to extend the timer or what’s going to be the thing that I care about most? It depends on the project. and the only uh thing I have to say about that is hiring good people means that they’re the ones that are in the driver’s seat of evaluating like what is the core challenge? what’s the thing that we’re scoring and measuring based off of? And very frequently there isn’t really a measurement to be taken. It’s like is the UX better? Yeah, it’s better. How many percent better? I don’t know. That’s not how UX works. so uh so again I don’t have like a like a thing like a yard stick but I do think in terms of level of ambition and at the end of the day I need to stand in front of the company leadership and say I believe this is a good bet that we should make. Here’s why. And they have a working [expletive] detector. And so I can’t I can’t be full of [expletive] I need to actually be able to support the thesis and say like, look, we thought of this. And so we went out and we conducted user studies, we tested it out, we let people use it, we have telemetry that tells us something about it, whatever. Like, but for every given thing, it’s different. you know, if it’s a technological thing, it is my telemetry tells me that like, you know, sort of our our prompting strategy is working 80% of the time and there’s low hanging fruit here. We believe that with some effort it could be raised to 90% of the time. That’s like the flavor of sentence that I need to be able to like defend um in a conversation with, you know, decision makers. So um how do we pick? We pick based off of sort of strategic direction and ambition. Our job is not to take the GitHub that is but add a feature but uh but to focus on those more ambitious things and then within those it’s like for each one it depends on what the thing is

Itiel Shwartz: the GitHub that can be and that sounds super cool and you know I can obviously like relate because we’re closed into the end of the episode and I will ask you like the final question that they usually ask but feel free to elaborate like what’s your take on the future like where are we going? what like if we’re going to talk again in a couple of years like what is going to be the biggest trends and so on that you know feel free to everything goes

Idan Gazit: well it’s not a big question at all

Itiel Shwartz: yeah I like

Idan Gazit: um I think a lot about sort of uh the progression of software in general. you know, it used to be something like what are trends that we can point to? More people can do it. That doesn’t mean like, you know, uh, you’ll hear like GitHub’s leadership talking about the 1 billion developers goal. They’re not talking about a billion more of me and you. they’re talking about.

Itiel Shwartz: No, because I don’t think a billion people are going to study software engineering and turn into like, you know, Kubernetes experts like um they’re talking about lawyers and doctors and school teachers and people that right now don’t think that creating software is something that they can do. uh but with the power of AI coupled with the right interfaces, I’m not saying that they’re going to create the kind of software that I create, but they don’t want that. They’re not here being like, listen, I have a better way to package and deploy software at scale. No, they’re like, I need an app to help me schedule like, you know, my daughter’s birthday party. and like right now they either use an app that somebody else made or they use nothing or a spreadsheet, right? what’s going to like we talk a lot at GitHub next about lowering the floor and also raising the ceiling like for the professional developers, how do we make them able to do more? And for the people who aren’t maybe developers or don’t see themselves as developers, how do we enable them to even get in the door and do stuff? And so as a trend, 100% the trend is towards more people creating software. And that’s also true when you look at it historically like once upon a time to author software you needed to have like you know a PhD in mathematics and then you punched cards with like you know your software and then fed it into a machine and you had to be super careful with memory and how you use it because there wasn’t a lot of it and now it’s just like the [expletive] do I care? I’m using JavaScript. It’s consuming 80 megabytes just to render this GIF. Like, you know, I don’t I don’t care about that anymore. You know, the the mathematicians at the dawn of our field would would weep to see how we abuse memory now. or maybe not. Maybe they would be very happy. They’re like, “Ah, finally the future came to pass.” So, as a trend, more people it’s easier. um in the sense that power tools makes it easier to build things, right? Like a lot of times people are like, “Oh, is AI going to replace developers?” And I’m like, “I don’t know. Does like a power saw replace a construction worker?” Like that doesn’t make sense. It makes that same construction worker able to build more things in the same amount of time. able to build bigger things in the same amount of time. uh or maybe bigger things that they couldn’t build without it. Like could you build a skyscraper with like a regular hammer and nails? Maybe it would take a zillion years, but with a nail gun is like boom b like you know. so uh uh I think we’re headed towards a new age like when I look at the history of software development there have been moments tipping points like you know when we moved from the teletype to the terminal in the beginning everybody was using the terminals like teletypes and then eventually people were like wait a minute I can edit wherever I want inside the file instead of just on like go to line 43 and apply this regular expression. and then when the GUI was invented, like VS Code was possible on the first day of the GUI, but what did we have on the first day of the GUI? We had Vim in a window, right? like why didn’t we invent immediately like hovers and sidebars and red squigglies and jump to definition and and autocomplete and then Copilot and whatever. All of that, well maybe not the Copilot, but like the rest of that was possible on the first day of the GUI. And so now we’re once again at this moment where like there’s new tech and it’s going to change the capabilities and the interfaces, but we don’t know what to use it for yet. I don’t believe the next 40 years of software development is going to look like the last 40 years, the GUI chapter. And so it’s not a change in display technology, but I think it’s just as as meaningful. And so um I look forward to this future where there’s more people that are able to access it. The people that are at the higher end of the field like you know the sort of they’re not entry level but the professionals are like like every day you go to work and you step into like this like mech suit that enables you to like lift cars and stuff and do more than you could on your own. And that’s like the future that I’m aiming for. So they’re going to be able to like raise the ceiling on what’s possible while at the same time we’re going to have more people coming in and and making software that in the beginning, you know, like all the old-timers are going to be like, “Oh, that’s shitty software.” But to those people, it’s incredibly valuable because it helped them schedule their kids’ birthday party. So that’s what I’m thinking about. and and this more holistic take on software that’s not just focused on like well over here I care about creation over here I care about collaboration and over here I care about operations I want like all of these to be sandwiched a little closer together so that I’m not thinking about the Kubernetes over here and the VS Code over there and the collaboration in the middle but as this sort of holistic way of thinking about the authoring the collaboration and the deployment of software altogether. So, um, that’s what I spent a lot of my time thinking about.

Itiel Shwartz: No, that’s a that’s a great ending. And I think with that we will wrap the episode. Thank you very much, Idan. It’s been a pleasure having you and yeah,

Idan Gazit: thank you for having me. It was a great time.

[Music] Kubernetes for Humans.

This is an AI generated transcript of the conversation