50: Making Long Bets: How GitHub Next Shapes the Future of Software Engineering with Idan Gazit

Erika (00:00) Welcome to the Overcommitted podcast, your weekly dose of real engineering conversations. I’m your host this week, Erika, and I’m joined by.

Brittany Ellich (00:08) Hey, I’m Brittany Ellich.

Erika (00:10) We met while working on a team at GitHub and quickly realized that we are obsessed with getting better at what we do. So we decided to start this podcast and share what we’ve learned. We’ll be talking about everything from leveling up your technical skills to navigating your professional development, all with the goal of creating a community where engineers can learn and connect.

Okay, let

Today on Overcommitted, we are joined by Idan Gazit, the head of GitHub Next, which is a group dedicated to exploring emerging technologies through building prototypes and tools for software developers. Previously, he was a core team member of Django, a principal engineer at Heroku, and a founding mentor at Google Campus Tel Aviv.

Idan brings a unique perspective that bridges design, development, and research, making him the perfect guest to discuss how to continuously evolve your skills and explore the cutting edge of software development. Welcome, Idan.

Idan Gazit (01:08) Thank you so much. Now I have to like stop blushing because that was quite an intro. So thank you for having me.

Erika (01:14) Well,

we’re so excited to have you. To kick us off, what’s one thing you’re currently building or obsessed with learning right now?

Idan Gazit (01:23) I mean, perennially, I’m like dissatisfied with all the interfaces that I have to everything because I’m always just like, this could be better. And especially for things with AI where we don’t necessarily yet understand the final form of like what this wants to be when it grows up. so, ⁓ I don’t know, like

This is not so much a next project is just something that I’ve been tinkering with on the weekends is like a better interface for like chat with AI because I frequently have conversations that branch a lot. And then I don’t necessarily want all those branches in the context history. It’s like eating up tokens. And so I kind of want like.

Erika (01:50) and

Idan Gazit (01:56) a Git style branching thing, but for my conversations with AI. So I can go on a side quest tangent and then unbranch, come back to my main thread, something like that. So ⁓ it’s so easy now. Anything that I think about, I could just be like, hey, Claude, make that for me. Thanks. Bye.

Erika (02:07) Mmm.

Yeah, that’s

so interesting. Yeah, like gives a window into like your thought process and how you like, how you think about things and go off on different tangents. I definitely identify with that.

Idan Gazit (02:26) It’s,

mean, I kind of want this for my real life conversations too, because frequently it’s just like, we go off on a tangent and then.

15 minutes later, we’re like, what were we talking about? How do we get on this topic? And like, I want that before my AI conversation so I can safely be like, you when it’s just like, you you should blah, blah, blah, blah, blah. And I’m like, what’s a blah, blah, blah? I don’t know what that is. Like, you know, go explain that for me. And then I, it’s like a wiki walk, you know, 43 clicks later, I’m like, how did I get to the topic of, you know, spaghetti bolognese? I don’t know. ⁓

Erika (02:35) Yeah.

Yeah.

Mm-hmm.

Yeah, let’s go back to the thread. Yeah. Well, awesome. So we are so curious to hear more about sort of what goes on inside of GitHub Next and sort of the perspective, your perspective behind some of these projects.

Idan Gazit (03:03) So yeah.

Erika (03:18) You know, you’ve described that one of your philosophies is that about 80 % of these projects are described as experiments fail. But some of them are really successful. Copilot was an outcome of GitHub Next. So from your perspective, having worked on so many of these, what are some of your favorites and maybe what has been the most disappointing?

Idan Gazit (03:41) Wow, that’s a doozy of a question. Well, first, know, sort of like what is next? Let me start there, I guess. And what’s the purpose of a GitHub Next? Like why bother having such a team? It’s the long bets team. Our job is to make long bets, right?

The entire company, you know, all of of GitHub’s engineering org is focused on on making and improving the GitHub of today and the GitHub of tomorrow. And there are a lot of things that are risky that, you know, GitHub’s engineering naturally shies away from because you don’t.

want to go on flights of fancy, you if like, you know, this team is off in that direction and that team is off in that direction, then you’re not aligned, you’re not shipping things, you’re not necessarily paying attention to what customers want. But on the other hand, long bets can be very valuable. For example, go pilot, you know, if you’d asked me at the start of that process, like, is AI really gonna write code for us that we’re gonna actually want?

I would have been like, I don’t know, know, it’s maybe it could be like, if we did, it would be like, you know, big if true, but, but the only way to know if it is true is to make it. and so in some senses, next is like an insurance policy. It’s like, let’s spend 1 % of like the engineering effort of the company on things that the broader, more conservative engineering org,

doesn’t wanna reach for those sort of like higher fruits. like, look, we have lower hanging fruit to pick. And sort of in service to the business. And also defending us from, there’s like 59 startups doing things. What if one of them tries to disrupt GitHub? Like get between us and developers in some fashion. It’s better that we do that to GitHub than that somebody else does that to GitHub. So that’s kind of the purpose of Next. And then,

That 80 % stat, I don’t know, that’s not a real statistic. That’s just something that I sort of pulled out. the idea is that if we’re not failing a lot of the time, we’re not actually advancing the state of the art. It means that we’re being too conservative. And then what’s the point? We already have a whole engineering org that’s sensibly conservative because it doesn’t want to ship defects, because it wants to focus on delivering value.

Erika (05:29) ⁓

Idan Gazit (05:49) ⁓ so, so we try to fail enough that we’re truly taking a stab at advancing the state of the art. I don’t know. Does, does that, does that make sense?

Erika (05:59) Yeah,

yeah. Yeah, and I mean, I kept the 80 % in there, because it’s a figure that I’ve heard other sort of like venture aligned groups mention something along that number. And like,

Idan Gazit (06:15) Yeah.

Erika (06:16) I guess within that, it’s like, what does failure even mean? Like, you know, do you get a kernel out of it that then becomes the seed for the next project? like, is failure, you know, we sunset it, we never look back. So I guess, you know, to be fair, like it’s hard to quantify exactly what that is. ⁓

Idan Gazit (06:37) Yeah,

mean, for sure, there’s different classes of projects at Next and there’s different levels of failure. Maybe I’ll flip it around and talk about like, what is success? What does winning look like? The highest category of success is we’ve identified new products in market.

Right? Ideally, load-bearing revenue generating ones. That’s the most success that we can possibly have. And copilot, you I hope the bean counters remember that one for a long, long time because I really like my job. I’d like to keep doing it forever. But, you know, that’s a thing where there’s a revenue graph that I can point to and it goes very up and to the right.

And so that’s absolutely sort of the top. Then one step down from that are projects that are like ingredients projects. It’s like we’ve come up with a technology or a technique or something that can turbocharge an existing product, but it’s not its own product, right? Maybe you can add a capability to an existing product in the lineup.

So that’s like sort of one step down from that. then the bottom rung of value that we sort of aim for are learnings. You know, there’s a new technology, everything about AI is new, but like, here’s a technique, let’s try to apply it. Let’s get our hands dirty with it and get wise with it. If next is sort of the scouting team, then sometimes we just got to go out ahead of the rest of the business and scout.

So that we can say like, this technique, this technology is ready for prime time. Like we could actually build products on top of it, even if we can’t articulate it ourselves yet. Or maybe it’s not ready, but we can wager an estimation of like, look, today the models can tackle this complexity of thing. But in six months.

based on sort of like how we’re using it what we’re able to try to squeeze out of the models today, we imagine that it’ll be possible to do this. And that’s something, that’s a useful input into sort of the planning process for product. And at the end of the day, that’s what Next serves, right? Like Next reports up into the product org because we’re a product search function, right? Even though we’re a bunch of engineers. So, yeah.

Erika (08:43) Are there any projects that maybe were not that like stereotypically successful like revenue generating project, but you have a soft spot in your heart for that you look back and you’re really glad that it happened? Well.

Idan Gazit (08:57) Yeah, all of them. No, I’m just kidding.

There’s a lot of projects that I like. I think there’s one in particular that stands out to me, probably not any of the ones that you’re thinking of, but we did a project some time ago called Get a Blocks, which was…

basically a question of like, if we could make the UI of .com itself mutable and composable? know, ⁓ let’s say you’re Sentry or you’re Stripe or you’re just an open source org and you want to be able to ship like little micro apps that live inside of the .com UI.

Erika (09:21) Hmm.

Idan Gazit (09:35) I mean, we see this with a lot of our competitors that sort of offer limited customizability of their interfaces with third party things. But this is tricky. It requires like, you know, a lot of security considerations and how are you like, you know, what’s the contract on on.

like what these things can do and what surfaces are they allowed to touch? And how do we pave over things like API access? Like I want a custom component in .com to be able to talk to the GitHub API as somebody that has access to that repo, if they have access to the repo, to be able to like show me, I don’t know, like use the API to show me like a dashboard of issues and pull requests in my open source project, like.

why can’t we let open source maintainers just build that for themselves and then have that be the repo page? Because why do I need to see the list of files in the repo when I land on the repo page? Who cares about that? So that was a project that we did. And it didn’t work out because there wasn’t enough corporate will.

at the GitHub level to say, you know what, like, this is something that we want to take to market. And it’s not something that like, we could take to market ourselves, like, you know, just go into the monolith, like bare handed and change it, you know, that’s never gonna happen. So a lot of times that’s kind of the flavor of next projects that don’t work out is not that it’s a bad idea. It might be an idea whose time has not yet come.

Erika (10:48) you

Idan Gazit (11:00) But sometimes it’s also just like, know what, the business had other priorities and Next can’t afford to sit around pining for like, you know, a product that doesn’t, that like the business doesn’t want to prioritize and go big with. And so it’s, you know, after a little while we shut it down and we moved on and that’s the core behavior of Next. have to like give away all of our babies, you know, and we hope they lead good lives out there in the big bad world.

But if they don’t, we have to move on. That’s the job.

Erika (11:28) Yeah. Yeah.

And this is, mean, in that answer, it’s like it’s the summary of what makes software development endlessly satisfying, but also like endlessly challenging. It’s because you always have to balance the idea and the technical limitations and the buy-in, the time cost. Yeah, it’s not…

It’s not always an idea to pen to paper kind of a process. There’s a lot of collaboration and a lot of pieces that need to be done.

Idan Gazit (12:04) No, is rarely straightforward.

And like the considerations are, you know, it’s not always technical, right? It can be business, it can be product, can be people matters. like, you know, whatever. We want to do something with a certain team, but that team is currently a little understaffed for whatever reason, you know, like some people are out on leave, maybe they need to do some hiring, I don’t know. And…

then it doesn’t matter if it’s a good idea or how much they want to, they don’t have bandwidth. And if we don’t have a path to market, then okay, we don’t need to kill it. It’s not like we need to like erase it from our brains. We can stick it on the shelf and maybe pull it off the shelf in a couple of months when they’re in a healthier spot and they have more bandwidth to like take a thing. So.

So it’s a lot of that sort of interdisciplinary navigating of all these different concerns. At the end of the day, winning is we’ve, something has left our orbit. It’s like when things escape the lab, that’s success.

Erika (13:02) Yeah. In those moments where you have to, when you come up against an obstacle and you kind of have to navigate that decision, what are some of the things that go through your mind and how do you adapt in those situations? I don’t know if you have any examples or thoughts that come to mind.

Idan Gazit (13:23) it’s a good question. I don’t know. I, I mean, part of it is just being honest with ourselves, which sounds easy, but you know, it’s, it’s maybe one of the hardest things to do is to like really look hard in the mirror and be like, do we believe that this has legs? And if not, not to be sentimental about killing things and moving on.

That’s the true adaptive thing. It also requires reading the room. It’s like at the end of the day, my customer is GitHub’s leadership, right? Because I can’t roll up to engineering and be like, please change your priorities, kthinkspy, right? I don’t have standing to do that. So really, my job is to…

find the evidence that I need to take to get a C-suite, their leadership, and say, here’s a bet that we should make and here’s why we should make it. And then if they agree, they are empowered to turn around and be like, here’s new marching orders for the broader business. want this to be prioritized.

So if we don’t believe that we can get to that, then it’s not a good use of our time and we need to just, you know, like park it and move on. And so that adaptiveness, I think the question that’s hiding inside your question, which I don’t have a pat answer to is how do you know when you’ve crossed that threshold? And that I think is as much art as it is, it’s way more art than it is a science.

⁓ Like I don’t have a flow chart for like, know, up until day 142, thou shalt make the thing. And from 143 onward, don’t like, you you should stop. It’s never like that. It’s always like, okay, like, do we still believe that we have a path to impact here? Because as an innovation team, if we’re squandering our time, I’m not going to get to keep my job. Like, you know, if I’m just, you know, like la-di-diing off there in the cloud.

I need to demonstrate impact or at least demonstrate that we’re responsible stewards of the long leash that’s been granted to us. So the best way to demonstrate that is to just say like, okay, know what, even if it’s a good idea and we should do it and whatever, like, you if leadership doesn’t vibe with it and we can’t find a way to make them vibe with it, then move on. Like, you know, I think that’s the key behavior there.

Brittany Ellich (15:35) So I think that working for an innovation team is probably pretty aspirational for like a lot of software engineers. Like it sounds incredibly cool to be building all of these things and, you know, doing the future basically. What does that actually look like day to day though? Like what does your research and design process and building process look like? it as, you know, is it as aspirational as it sounds?

Idan Gazit (15:57) Yeah, well, okay, let me preface and say I love what I do and I love how we do it. But the Rose is not without its thorns, right? Like, let’s not pretend that this is utopia because it really isn’t. You know, from the side…

It seems like it’s all unicorns and pixie dust. Like, oh, we get to do whatever we want. And nobody really thinks about the darker underbelly of this thing, which is every time we pull a rabbit out of a hat, leadership is just like.

great, when’s your next album coming out? And then the expectations are even higher. It’s just like, well, your last product went on to make $11 bajillion. When are you gonna have another banger like that? And can we have it now? Can we have it yesterday? That’s the energy of it. all that freedom also comes with sort of, I don’t wanna say an emotional cost, but there’s definitely like,

performance stress around that because that’s the only, know, I can’t keep plugging away at a backlog and be like, you know, we burned down 50 % of the backlog in the last quarter. And that’s my, and that’s my performance self-review for this period. And then I’ll, you know, I’ll get a, I’ll get a positive review on that. No, like I have to be like, we pushed the boundaries and we took this many shots.

And this many of them succeeded, like land on target. So I have to have that conversation with people who are like, when we hire into the team, I need to make sure that the people on the team that are coming in sort of understand that and appreciate it when they’re coming in the door so that they don’t come in with like fantasies about like, we’re just gonna work on whatever we feel like. And no, like that’s not what this job is. Like, yes, we do.

And it can engender some amount of also like envy or jealousy or like negative vibes with like the rest of the business. Cause the rest of the business is like, Oh, I have to like, know, keep hammering away at this backlog and you’re out there like frolicking in a field of daisies. Like, you know, you have no plan. Um, and it’s true, but it’s not true at the same time. Like, you know, so I have to sort of make sure that people understand that. Um, how we work.

I’d say that we’re actually at an interesting inflection point. you know, right now you’re, you’re sort of catching us at this interesting inflection point in the very early days. Well, in the very early days, nobody cared about what we were doing because we were an unproven thing, you know, until we did go pilot. I couldn’t get the time of day from like the rest of the business. cause they’re like, my whatever thing is on fire. Like either you’re here to like grab a bucket and help us or go away. Like, you know, I don’t.

It’s cool that you’re talking about flying cars and all, but like I have a fire on my doorstep, go away. And then after we did Copilot and that itself was, you know, a thing that we held onto all the way to the market, right? Like we did all the initial prototyping, we did all the product work and then Next, actually like two thirds of Next kind of got.

seconded into EPD for a while to just take it to market all the way. And that was a messy process also, because people are like, wait a minute, it’s like, I joined this team, what do mean now I’m reporting into that team? So there’s also like people considerations there. And then after the success of that, the desire from leadership was just like, look,

As the team that’s sort of out there, the tip of the spear of this stuff, we want you to be prototyping more and delivering less. Like, don’t hold it all the way to market. Turn over prototypes to the rest of the business to be productized so that you can do the prototyping loop faster.

because it’s such a fast moving dynamic field, like, you we have to do that. And so for a couple of years, that’s what we did. And so there was a, you know, there was what was at the time Copilot X, which was kind of a branding exercise is like six projects in a trench coat, like.

you know, you know, like copilot for docs and copilot for CLI, which is totally unrelated to the current copilot for CLI. This was like, I want something that can give me a terminal command for doing something that I don’t remember all of the arguments I need to pass into the whatever. Like, you know, and at the time this was like, whoa, this is really cool. Now it’s just like, yeah, table stakes.

⁓ so a lot of projects like that and even bigger efforts like Copilot Workspace and Spark, you know, these were efforts that where we ran out ahead of the business. But then instead of holding onto those products all the way to market, we had to figure out a way to hand off to the rest of the business. And, candidly that didn’t really work. It turns out. and there’s a lot of reasons why maybe it didn’t work, but,

I don’t think that really matters. know, that’s just a form of blame game that is not helpful to the business. And so now what we’re doing is a little bit reverting to how we worked with original copilot, which is that Next is going to conduct fewer explorations. That’s the cost.

because we’ll hold on to explorations for longer in order to go all the way to market and secure signals of product market fit ourselves. Like not take it to prototype phase, not that we ever did it like this, but like we’re not gonna check it over the wall, be like, draw the rest of the owl, okay, thanks, bye. So.

That handoff process is just, it’s full of, it’s a minefield. It’s really hard on all levels to make that work and to make sure that you’ve imbued the new owners of this thing with the vision for what it can and should be. Cause in the prototype phase, I’m not doing all of those things. It’s a lot easier to do that.

internally when we’re still holding onto the products. So those are the ups and downs of how that process works. And that’s how we’ve changed how we work. I haven’t gotten into the cycle of how we actually do the research process. I can get into that. But I just said a lot of words. So your turn.

Erika (21:49) This might be a part of that second question, but where do the ideas come from?

Idan Gazit (21:54) you, the ideas are, no, it’s, it’s a surprise. the ideas come from everybody at Next. It’s not, it’s not like, you know, it’s, you know, the, leaders of Next, you know, sit high atop the mountain and commune with nature until we have some transcendental ideas. That’s not how it works. Nope. Our cycle is actually, well, okay. First, it starts with hiring, like folks at Next.

tend to be, first of all, from the more experienced side of the spectrum. The average level at Next is Staff Plus, which is very weird. There are no other teams at GitHub that are like, I think we have one member on the team is Senior, and they’re the…

like most junior member of the team and they’re not gonna stay senior for long, hopefully usually it’s a good example of growth when somebody is sort of reaching for more that way. So first of all, we hire folks that are very experienced and so they have good Spidey senses about like what could be or what should be. Second of all, we tend to hire folks who are hybrids of one form or another.

They’re not like just a backend engineer, just a front-end engineer, just a designer. It’s like everyone across Next is sort of like a mix of skills. And we have demo day every Thursday inside the team. And a little bit like Google’s mythical 20 % time, which I don’t think was ever really a thing, but like we actually try to make it a real thing. Like, sure, we have the projects that we’re committed to.

but everybody in the team is expected to.

mess around and produce demos of things that are interesting to them. Because that experience, know, what we’re buying there with that experience is the ability to say like, you know, I believe that this might be something interesting for us to chase. And here I built a little prototype and now we’re showing it to each other every Thursday and they’re janky and they’re half broken, whatever. But the point is, is that we’re showing things to one another. And then the first signal that we’re looking for is like, do other people on the team get excited? You know, are

they with their wealth of experience looking at this mean like yes this has legs I want to work on this that’s a signal that we’re looking for and inside next people sort of self-assemble into squads around projects

⁓ you know, like this person is maybe stronger design and this person is stronger programming languages. And this person has a lot of experience with, you know, I don’t know, static analysis and like, maybe those are the skills we need for this specific project. And so then those are the people that get together and pursue the thing. and then at some point we sort of pick, we have like sort of discovery season, which is like hack week, but a couple of months long where we’re sort of like.

banging our heads on the wall and trying to figure out like, where’s the tech gonna be in six months and 12 months and 18 months? And then like, what’s ridiculous today that’s gonna be commonplace in that future? And then let’s build for that. And then we select projects that we, from those demos that we feel excited about, and then we sort of fund those and work on them for a longer period of time and kill the ones along the way that we see are not really growing as fast that we want.

So that’s kind of our cycle and how we think about that the projects come from everybody on the team and frequently from previous projects that we do. Like we do a project and then we’ll identify like, you know, sort of like a side quest and like, that’s interesting. But like, we’re busy now with this main quest. Let’s stick a pin on that and come back to it. But sometimes that doesn’t matter because the tech moves so fast that by the time we come back to it, we’re like, actually.

That’s a solved problem now. We don’t actually need to do anything about it. So, no rules. We’re just making it up as we go, just like parenting, know, kind of a thing.

Brittany Ellich (25:33) Relatable.

That’s a great segue actually into my next question is about how things have changed with AI. I realized recently that working with GitHub during the last four years or so of AI transformation has been really cool because I have access to a lot of tools first. Thank you, by the way, for Copilot. It’s awesome. And I get unlimited AI spend.

Idan Gazit (25:55) it’s so much better today, right?

Like the thing that we made way back when, it’s like you look at it now and it’s like primitive, like, you know, it’s like dinosaur stone age levels of bad. So I can’t take credit for the modern copilot. It’s so much better.

Brittany Ellich (26:06) Mm-hmm.

Yeah, yeah, it’s, mean, it’s, it’s changed so much over the last four years that I’ve been at GitHub and, ⁓ I can’t even imagine what it’s going to be in the future, but you work specifically on innovation and for the future. like, how are things changing in your world when, you know, you can build a prototype within a thought and, you know, the, the cost to do these things is I would imagine lower, but then that comes with a lot of other trade offs, I’m sure. So.

curious how that’s working in your area.

Idan Gazit (26:40) I don’t know if you like to read science fiction, but like good science fiction is not about like laser beams and aliens. Good science fiction is about like, what if society, but something was different, right? And I think a lot about that in the context of the projects that we’re doing is like as much as we’re in the age of AI and you know, like will wonders never cease.

This whole field is still in diapers. Like, let’s remember that like in the progress bar of like this AI transformation, we’re still at like 0.23%, like along the path here. We’re still using yesterday’s tools with tomorrow’s technology bolted onto the side of it effectively. you know, it’s like we talk a big game about.

AI native. It’s not just us. mean, everybody in the industry, AI native and blah, blah. But do we really understand what AI native really means? Like, you know, it’s, it’s, we’re all talking about faster horses. Who’s going to figure out the car. and so, I don’t know.

me personally as somebody who cares a lot about interfaces, I’m that proverbial man with the hammer and every problem looks like an interface problem to me. It’s like, if we only could come up with the right interface for this, then the tech will sort itself out. But the reality is that it’s a mix. So we try to think first about, like in the science fiction sense of like,

what’s the universe gonna look like if something is true? Because like we don’t train models here, right? Like we ride on top of OpenAI’s models, Google’s models, Anthropics models. And so they’re constantly putting out like a drum beat of newer, better models. And then…

we can invest energy into techniques to say improve how we select context, right? That’s a deep technical problem that like everybody’s bashing their heads against. Or we can build better interfaces, but the two are sometimes related. It’s just like sometimes if I build the right interface and through that, I get the humans using the thing to leak their intent.

about what they want to accomplish in a better way. Or like, you know, if I give you a to-do list somewhere in the application, like that to-do list is not going to look like an AI feature, but maybe that’s the feature that makes AI somewhere else possible. Because like by dint of you using that to-do list over here, I’m able to automatically generate commits over there because like you’re checking things off. And so I now have this semantic information about what your intent was.

So like everything kind of ties together in those ways. And yeah, I think that those are the sort of the hard questions for us. And also like, it doesn’t make sense for us to focus on the kind of things that the models are gonna do for us. Like sometimes we’re like, like, you know, can we do a better job of context selection or prompting in order to get it to like focus on a given thing? Maybe if we wait three months.

and like Opus four seven comes out and all of a sudden it just one shots things that previously like we had to like carefully construct context around. And so that’s the crux of our sort of like bets. It’s like, as the models get better, what parts are just gonna be solved for us? And it doesn’t make sense for us to try to attack those problems and instead try to attack like, you know, fundamental things about how we’re gonna use this stuff like.

I’ll give a concrete example.

I can generate a lot more code now, right? Like Opus 4.5 is really an inflection point. I’d say that the biggest moment since original copilot, because all of a sudden it’s crossed this like invisible threshold of utility where I can dispatch it on harder tasks, on longer tasks, and it delivers. But eventually all the models are gonna be that good, right? Like they’ll become fungible.

And then the question is, like, okay, like in a world where I can generate so much more code, when’s the right time for me to align with my fellow developers? Like the pull request is, that’s what built the house of GitHub that we live in, right? Does the pull request still make sense as an after the fact artifact in a world where I could in the span of time that it takes me to get to

the pull request and sort of how we’ve done development since forever. Like I can create 15 pull requests now in that same time. Is the pull request too late to align with my fellow developers? Like, do we need to move that communication sooner? That’s a very different world. What does that world look like? And if that world is true, what tools do I need? You know, those are the kinds of, so it’s like, it’s like asking those science fiction societal questions.

and then working backwards from that into like, what are the tools gonna look like if that’s true? So those kinds of things, and that’s how we try to think, but it’s like, it’s very squishy and hard to define, but you know it when you see it kind of a thing.

Brittany Ellich (31:29) Yeah, that’s really fascinating. think that’s a yeah, there’s a lot of problems that have come up that I’ve never thought about before. Like what happens when I have to get 15 pull requests reviewed before I can get something in and, you know, making sure that they’re small and reviewable enough that somebody can actually look at them. ⁓

Idan Gazit (31:45) Right,

but like it’s like six of one half dozen of the other. It’s like, which side of the problem do we attack it from? Do we attack it by making code review easier so that I can deal with like the firehose of PRs that’s now coming at my face? That’s one side to attack it from. Or do we try to like move that communication that would normally happen late in the process?

Brittany Ellich (31:52) Mm-hmm.

Idan Gazit (32:07) to be spread out throughout the process so that it doesn’t feel like I have this one big hurdle that I have to get over. I don’t know. There’s more than one way to solve that.

Erika (32:20) Yeah, and it’s different depending on the project or on the team or even on the developer too, right? Like the process for one team or one person, like whether it’s comfort level or like security review or checks and you know, the speed of development that’s required, like yeah, there’s so many different developers, so many different projects happening. Like you can’t make everybody happy, but like you can think about what might help.

this group or that group or you know whether it’s the most people or people in this area.

Idan Gazit (32:51) or whatever open source versus enterprise, know, like what does an open source maintainer need when they’re working by themselves and scratching their own itch? What does an open source maintainer need when their project gets big and now they have a zillion people coming out of the woodwork with like, want a pony. Versus what do teams at different businesses need, right? At the end of the day, like a lot of businesses rely on GitHub and

They’re pretty diverse too. There isn’t like one business persona. So it’s a pretty broad set of targets to aim for. And sometimes you have to aim for one at the expense of the other and the other way around. And it’s tricky to balance that.

Brittany Ellich (33:28) Yeah, that makes sense. One of the things I’ve heard alluded to a lot in the age of AI is how this is also the age of personalized software where you can go make software for yourself with like an N of one and it can be perfectly however it is, however you want it to look and act and feel. And it, it’s so easy to build something with AI that sometimes now it’s going to make a lot more sense to build instead of to buy and pay for a subscription for things.

I’m curious what your thoughts are on how that changes things for like software companies and explorations at next. And I feel like this almost fits. Maybe that blocks product project comes back because the ability to build things and personalize them exactly to how you and your company need them is so much easier now than it ever was before. Do have any thoughts on

Idan Gazit (34:13) Yeah, mean, yeah, it’s definitely easier to build, right? Like the cost of prototyping is, you know, it’s fallen through the floor. And so we’re previously like, you know, we would naturally spend a lot of our times sort of philosophizing about what could or should be built, because the actual building was a lot more expensive in the new world.

the cost of trying a thing is so low and I can get so much information for so little cost, you know, just by, you know, vibe coding a thing, just to be able to like play with it and get some information about how it feels and be able to like share it with somebody, right? Like if I don’t get the idea out of my head and put it in front of you, I don’t enjoy the benefit of your brain working on my problem.

⁓ and so prototyping is not just like, it gives me superpowers for myself. It gives me access to your brains in a way that I, you know, I could have written a doc, you know, but like, that’s, that’s, that’s not the same. so, so yeah, I think it’s not exactly the question you asked, but I think where my head goes is, is really a question of like.

What’s the purpose of libraries in a world where AI might be able to do things? And I think this is like a fundamental question for GitHub as the home of all the libraries, Is in a world where AI, I can just point it and be like, listen, I want you to use like the YouTube API to like fetch the whatevers in order to like put it on this web app that I’m building. Do I need the YouTube SDK?

You know, like previously it’s like I’d go and NPM install a thing and then I’d read it stocks on how to use it. And then I’d use that library in order to talk to the thing. But like, maybe I can just be like, hey, I like, you know, talk to that and do I care whether or not it’s used the library or it’s just written one from scratch based on the documentation for that REST API, like that’s out there on the internet.

like is the future of code that everything is vended and that we don’t actually share like underlying libraries, maybe. And if that’s the case, then like what does sort of the library of Alexandria for software look like in the future and what needs to be there? Does it look more like the stuff that’s happening now with like Motebook where it’s like all skills all the time and it’s not

actual code. Like, I don’t know, that’s really interesting. It feels a little wild and crazy, but it’s the kind of wild and crazy that might actually come true. So maybe. But I don’t think this really changes the model of like how we operate our job. Like I can sit here and talk with you about it until we’re blue in the face, but the only way to know is to make.

And so our strat is always make that’s that’s always what we come back to because everything else doesn’t really have currency. It’s only things that are made are true. So.

Erika (37:05) Well, thanks for that insight. We are getting your time and we have kind of a fun question related to this superpower idea. So I don’t know if like in your life you’ve ever been asked, I know you have kids, so maybe they’ve asked you or you’ve asked them whatever superpower you would have if you could pick one. But we’re going to kind of take this as like a professional superpower. So part of this is inspired.

Idan Gazit (37:15) Okay.

Erika (37:32) you’ve described yourself as half designer half developer or one part one part so you’re already kind of supercharged in multiple directions.

Idan Gazit (37:42) Everybody remembers the first half of the Jack of all trades idiom, but everybody forgets the back half is in master of none. It’s not like, ⁓ I’m both this and this. It’s like another way to formulate it is like, I’m a terrible designer and I’m a terrible developer at the same time. ⁓

Erika (37:50) HUEH!

Well, something

tells me that’s not true. And that’s true. There might be downsides to having superpowers. Yeah, we know that from all of the superhero stories out there. It’s not always a bed of roses. But with all that caveat-ed, the question is, if you could supercharge one piece of your professional toolbox, what would it be and why? And we’ll let you go last.

Idan Gazit (38:13) Yeah, exactly.

Erika (38:26) bonus points for kind of describing what the improvements on your life would be. So for me, I get in my head so much and like feel like I constantly have like all these gears turning and like the getting it from my head to somebody else and like having that productive conversation.

I’m getting much better at it, but it always feels like a challenge. Like I’ll look back at like whatever I write in Slack or emails that I send or issues that I create. And I’m like, wow, who wrote that? That makes absolutely no sense.

What were you trying to say here? So my superpower, if I could have it, would be crystal clear communication. Everything I say fits right exactly with how you need to hear it in that moment. And yeah, I can look back and it’s all legible and understandable with the exact right level of detail. So that would be, that was my superpower.

Idan Gazit (39:02) relatable.

I mean, that’s, you’re not asking for much there. Like that, but you’re not wrong. Like that’s a skill with no ceiling. I will tell you as somebody who also very much agrees with you on this that I talk with a lot of people who are like early in career in computer science and I’m like, hey, are you feeling stupid? Well, guess what?

Erika (39:30) I mean…

Idan Gazit (39:47) that never goes away. Like, I still feel stupid. The difference in experience is that like, I now know that feeling stupid is just part of the job. Like, doesn’t matter what I’m doing in the beginning, I’m stupid. And I think that that sentiment applies just as well to like communications. It’s like, know, like,

becoming more experienced as a working developer inside a company that needs to ship products means feeling stupid about comms as well as feeling stupid about the code as well as feeling stupid about everything else and then that’s normal and an expected part of the job. like if you’re not feeling it, that means that you’re not challenging yourself. Maybe it’s time to look for a job that’s gonna be more fun. So like don’t feel bad about that.

Erika (40:27) That’s true. It’s always a gross opportunity.

What about you, Brittany? What would you pick?

Brittany Ellich (40:32) ⁓ If I could supercharge any part of my professional toolbox, I would ⁓ choose to reduce the cost of context switching to nothing. Because right now I have, feel like that’s the thing that I struggle with the most is I do a lot of multitasking and thinking about lots of things at once and the cost to go back and forth between those things is very high. And so I would want to be able to like be able to instantly context switch between problems and you know, not.

to slow myself down to remember, yeah, what was the problem that we were going back to? think that’s what I would choose. What about you, Edan? Do you have a super charge that you would like to do in your professional toolbox?

Idan Gazit (41:10) Erika kind of took mine. mean, no, you didn’t take it. was, it was, was up for grabs. But, if, I mean, my job is largely about persuasion, right? Like, you know, I, the charitable way to frame it is I’m like, you know, like the profits of old, I’m like the crazy guy on a soap box on the street corner, like talking about a future that isn’t here yet. And it sounds crazy because it is crazy, but like a year from now, maybe it won’t be crazy.

So my ability to persuade people that whatever is a huge part of my job and I wish I could do it better, always. Yeah, guess, mean, I don’t know if this is like a legit answer, but seeing as ⁓ Erika’s already answered the answer that I wanted to answer, I wanna not sleep, I just want more hours in the day. Like.

Every time I try things and I make something, I’m always fulfilled by it. It’s always energizing. It’s always the best way to know if something is good or not. And that’s the hard part. It’s really hard to tell the sort of like the real McCoy from the runners up just by thinking about them.

I want to make, but there’s only so many hours in the day for making. And as a people manager, I am not supposed to do quite as much making. I miss that. really, I wish I could do more. And so that’s what I want. I want like more time to balance that because in addition to being there for my team and making sure to like run defense and hold an umbrella over them and blah, blah, blah. And also I miss, I miss making things more. And so I want more hours in the day.

And it’s not just like, because it’ll make me feel good, but also because in order to keep the sort of the finger feel of like the technology, I gotta keep using the skills or they get rusty. And so I guess maybe the thing that I’m reaching for here is like, how do I create that healthy balance of both managing and making?

Right now, there isn’t a healthy balance. Right now, there’s a lot more of the management work because that’s what’s needed to make my team successful and to make every one of them successful at their own individual roles. But I miss making, I’m a maker. So I want more of that too. And then how do I get to that question mark? I haven’t figured it out. I’ve been here for six years and I still suck at it. So.

Erika (43:21) you

Idan Gazit (43:22) Yeah, more hours, no sleep. If I could just not sleep, that’d be great.

Erika (43:25) Yeah,

yeah. Well, thank you again, you know, so much for joining us and for this thoughtful and interesting discussion about GitHub Next and all of your processes. And if anybody is looking to find you, find out more about what you’re working on, where would they look?

Idan Gazit (43:44) gazette.me, like my last name dot me is my personal website. I have social media, but I don’t really use it that much anymore. I just find it to be more of an energy suck than what it used to be, like providing energy. so yeah, I guess it’s just the website, but like I’m terrible. I don’t have a blog. I’m, I’m just boring. I’m just.

working away at stuff onto the site. Really, it’s like check out the GitHub Next website. That’s the thing that I should be saying here because those are the projects that’s where my heart and soul goes and where the team is sort of focusing their energy. And by the time this episode goes live, hopefully we will have relaunched the GitHub Next website with like.

sort of more microbloggy place for us to like share little thoughts, not just like big write-ups for projects. And so hopefully by the time this comes out, I will have used that a bunch to write smaller thoughts and then I won’t be quite as boring.

Erika (44:42) Very cool. That sounds exciting. Well, thank you listeners so much for tuning in to Overcommitted. If you like what you hear, please do follow, subscribe, or do whatever it is you like to do on the podcast up of your choice. Check us out on Blue Sky and share with your friends. Until next week, goodbye.

Idan Gazit (44:57) Thank you.