• GitKraken
• GitLens

Allen: Welcome to It Shipped That Way, where we talk to product leaders about the lessons they’ve learned helping build great products and teams. I’m Allen Pike and today’s interview is with Eric Amodio. Eric is the CTO at GitKraken, is the creator of GitLens, and previously worked on VS Code at Microsoft. Welcome, Eric.

Eric: Hey. Thanks so much for having me. Great to be here.

Allen: I’m excited to have you on the show and learn all about your world. I have had this background in the Apple development world for many years, but now as I come out more into the broader world of web development, which is actually my background even before Apple Development, I’ve been enjoying really having conversations with folks like yourself who have created and are working on really big and influential tools in the broader non-Apple ecosystem space. I’m really excited to learn about that broader code collaboration, working with large teams, running large open source projects.

Eric: Yeah. I definitely grew up in much more of the Microsoft and not Apple space, so come from different areas. My first language was really Basic and the other things, but my first thing that really got the aha moment for me was Visual Basic. I was in high school or something and just created. There wasn’t really open source at that time. There was, but it wasn’t a big thing at that point because I’m old. But in that point, it was just creating shareware stuff. And so I actually created a little POP notifier at that point when POP was just coming out. Just little desktop notifications for email and actually took down the whole college network or school network at that point. It was a lot of fun. Just getting adoption on something that you put out in creation, that was just the hook for me. Just being able to create things.

Allen: Let’s get into that and let’s dig into some of the various fun things that you’ve built. How about you give us a little bit of a summary before we get into GitKraken and large teams and supporting legacy code bases and all the open source. So summarize a bit your story so far. You can start there in college with building an email client that takes down the network and build up through Microsoft and some of the things that you’ve done to set the stage.

Eric: Yeah. Yeah. For me, I was involved in computers since I was a kid, building them, putting them together and so I wanted to go to school for hardware. I had always done some level of programming and playing around with programming at a really young age, but it wasn’t as fun for me at that point. The hardware stuff I was much more interested in. Visual Basic changed the nature of it, whereas I could create the things I was seeing in my head much more easily and effectively and then try things really quickly and throw things out there. And the shareware thing just was really interesting of just putting stuff out there, getting other people to use it and just seeing that adoption, seeing the community come up around some of these things was just … That really solidified the bug for me. I think that’s one of the challenges too, going in school and the rest is we start programming from the fundamentals. I’m sure it’s changed a lot since I was in school, but it’s a lot of the fundamentals and that sort of stuff, which is good to know, but it doesn’t get you really interested in the creation. For me, programming, while I love programming, it’s really about the creation. It’s the expression of creating things and taking these ideas from nothing, putting them out there, showing them, getting usage and adoption and that’s guided me throughout.

Allen: I feel that 100%. My tool, like you I started with Basic, but then I got hooked on Borland C++ Builder. It shares a bunch of spiritual similarities to Visual Basic. It’s a tool in the ’90s for making Windows apps that you just start clicking around and you’re a kid basically making stuff and the world is your oyster/you know enough to be dangerous.

Eric: And it is fun. Something for me too is it’s that easy entry but then start really pushing the boundaries. Fast forwarding to creating GitLens and the rest of it is trying to take a system and just VS Code extensions and what VS Code provided at that point in time and then being able to push the bounds and bend the system to your will and express that sort of stuff. So the same thing with Visual Basic was just like how can I get it to do the things I want really quickly, get the basics but then layer on more into that. So I was always interested in learning and continuing the system and learning how Windows worked underneath the Visual Basic so I can hack the actual HWINs behind it and start writing to lower layers. For me, it was that creative expression. Building things. And a lot of the times, most of the things that I’ve built are all really about scratching my own itch when it comes down to it. It’s like I wanted this tool, so I built POP notifier. I was at a company, we used email a lot and it Outlook was just very minimal. Outlook didn’t have notifications and stuff yet at the early stages so I built a app that plugged into Outlook to build that. I built a lot of extensions to Visual Studio because I had to live in that environment. So I built things for Visual Studio and then build command line tools, expand stuff into … Anytime I like … In diving in and living in tools and stuff, if there’s extensibility, I find myself trying to customize it to how it fits my workflow better and that stuff and then start offering those tools up. And GitLens is an extreme expression of that which grew into something far larger than I would’ve ever expected.

Allen: I think probably most folks, at least a lot of our audience, is engineering leaders and founders and things, so a lot of folks are going to be familiar with GitLens considering that it has ridiculously large install phase. But not everybody will have … Especially in Apple ecosystem or if they’re more on the product side of things. So how about you summarize what GitLens is and its success so far?

Eric: Where it started, the humble beginnings were really just like I was working on a team, we were adopting Git and I was the Git expert and just trying to get people onboarded to help that flow. So dealing with that pain of onboarding to Git because Git is harder. And it’s changed a lot over the years but it’s still not as accessible and that’s why we have our-

Allen: I typed revert and it didn’t revert. I have detached head. This sounds bad.

Eric: Exactly. Yeah. The command line is not user-friendly. That’s where it started and then I also at the time just fell in love with VS Code as an editor. I was much more used to Visual Studio. I did not like the experience because really at that time it was really big, really slow, lots of stuff. So getting into a much faster sublime text and then VS Code was really interesting. So they came out with the extension API and that’s where I started playing with that. And then very quickly it started with just like, well, can I show some Git stuff to make that flow a little bit easier? But then it also really quickly transitioned into what are the things that I do a lot as a senior lead dev of diving into an existing code base? And it was really about … I was always walking back through history. It was like how did we get to this point? Before I go and make these changes in this big system how did I get here? Am I going to make the same mistakes again because this code, looking at it objectively from the surface it looks weird. Well maybe it’s weird for a really good reason or maybe it’s not.

Allen: Or maybe it’s not.

Eric: Exactly. And so just being able to make that. So some of the first iterations were just can I make it easy to just show you the diff of the previous version and keep walking back in history? And then it was, how do I surface that information even easier? And so that’s where the inline blame started coming with where your cursor is. So at any point in time you can see how recently this changed and by what and then give you a little bit more insight. Hopefully there’s a reasonable commit message, but it would tell you a little bit more about why that code is at that state and then be able to walk back through there. So that guided a lot of it and then it snowballed into getting used and just continue building out tooling and was my obsession for quite a while.

Allen: So you say snowball into getting used and obviously it’s one of the great joys of building products to have traction and people are using it. But as I understand it, getting used is tens of millions of downloads. It’s not like, oh, a few people using it now. And so that then obviously offers opportunities once you have both user base and you also have the compounding experience of building a tool then is being used by tens of millions of people and it’s being used. Perhaps obviously a tool like that is especially useful for large teams that are working on large existing code bases with a lot of curious artifacts that may be for good reasons or maybe not. And so that led you to GitKraken now. Tell us about how that came together.

Eric: GitLens as it continued to expand and grow that GitKraken is a tool with a similar spirit. It’s like trying to make Git and deal with that and work with your team and manage merge conflicts and make that stuff more accessible and easier to understand. And then they had a strong focus on visualization. And there’s some level of visualization that both of us tried to do. They had a really strong graph visualization. GitLens never had a graph visualization, but that was something that had been asked for from the beginning, but it was like never made it high enough on my to lose sleepover work to build that out. But there was other features too, like interactive rebase. They had a really visual interactive rebase. GitLens had a very visual interactive rebase and there’s a lot of similarities between the two of them. And so we approached things in a lot of similar ways. But also being in the IDE affords a different use case from someone on the desktop. So they approached, we had lots of conversations on how things could work together, where a bigger picture can go. So yeah. I joined GitKraken two and a half-ish years ago bringing GitLens into that fold and became the CTO and then continued to build out the much bigger vision of rather than just purely being a set of GIT tools, really moving into collaboration and how teams work together better. And if we can really focus on changing how we code … If we can get collaboration much earlier in the process to share things early, we can get much better outcomes at the end.

Allen: And that’s one of the core fundamental things about engineering leadership is like, okay, well we have this shared goal and we have all these individual engineers with their various strengths and context and understandings. How do we translate that into one, a coherent high quality code base given that for any successful product, the code becomes too complicated to be in any one person’s brain. We have all these separate unconnected brains, so how do we manage that?

Eric: Context is hard. Yeah. That’s one of the challenges of smaller teams. Smaller teams can move very quickly because in general, your products are simpler and so you can hold more of the code base in your head and the more you can hold in your head the easier it is to iterate and see the edges and refactor and change. We need to rely on a lot more tooling to make that happen once things get to a certain size.

Allen: Yeah. So I’d love to dig in a little bit into some of the tooling and both the state of the art as well as future directions for that. But something at that point of bringing GitLens into the fold of GitKraken, which is already established successful product of its own that has a business behind it and business model. Tell me a little bit about that journey of going from, okay, we have this open source project and it’s popular, but we’d like to make it sustainable so that it keeps getting better. The famous thing that most software projects industry come up with at some point when they start as a free side experiment. How did navigating that go and any interesting lessons or surprises from going through that?

Eric: That’s a huge challenge in there of take something that has a very large user base. A following. I wouldn’t say we had a strong open source community with contributions. We got some, but it was really around the edges, minor bug fixes and that sort of stuff. But it was a lot … Issues and engagement and stuff like that that we had a lot. And there’s a lot of obviously usage of it. And then transitioning to bringing that into GitKraken and then trying to layer onto that. It was definitely a challenge for us to figure out. One of the things that I wanted to do and GitKraken wanted to do was not damage that in any way. Not hamper it. Not oh, we’re going to turn this into everything that you’re doing, you’ve got to now pay for. We really wanted to continue the open source and continue building that, but also provide some level of capabilities on top of that that were paid features to continue funding and expanding what we wanted to build there to continue to invest in the entirety of the product. The challenges there are open source community is challenging in of itself.

Allen: Would be challenging? It sounds like a win for everybody. The product is still free, you’re adding more functionality. I’m sure everyone was perfectly happy and no one had anything to say.

Eric: Exactly. It would be nice. There’s a level of appreciation or just an expectation that is a little bit too strong of a through line through our communities of that everything should be free and everything can’t be free. People need to eat and need to pay bills and all of this stuff. So there isn’t the free lunch so these things have to happen in some places. And I think one thing that also makes it a little challenging is that when you’ve got big companies, Microsoft and Google and others who can easily afford to have these open source projects that to the users are completely free, it changes the nature,

Allen: VS Code is free, why can’t GitLens be free. Microsoft can afford it. Why can’t Eric?

Eric: Yeah. VS Code is free so everything that’s part of it should also be free. That is some level of expectation. It’s changing over time. But Microsoft even has seen in that with Copilot. Copilot is not a free product. It’s a paid extension on VS Code and their reviews on that are not very good at all for that product.

Allen: Interesting.

Eric: And it’s purely on how dare you ask to pay rather than the merits of the product in and of itself. So that is definitely a challenge. A lesson that I took away from it is it was much harder than I would’ve expected it to be. I didn’t expect the same level of angst that we got to it because we were trying to be really thoughtful of how we did it. We literally did not take away a single feature that was free. We only added on. As well as adding a bunch of free features, we added a set of paid. We thought that this would not be as negatively received. We were wrong. I mean it depends. Right or wrong is hard to judge because there’s always a vocal minority that completely drowns out the majority. So on the majority side we were fine because usage was still continuing to increase dramatically. We’ve got people signing on to pay for the new features and that sort of stuff. So from that side it was fine. But I really also wanted to serve the entire community and not have some of the negative outcomes from some of that. Some of it would’ve been really to reach out to the community about the plans before they happened. Just been a lot more of throw stuff out there of this is where we’re thinking of going, these are some of the things we’re thinking about doing and getting a little bit more engagement. I can’t say that it would’ve had a significant difference to the plan of what we would ultimately deliver because I think what we ultimately delivered was the most generous and most community forward that we could do at that point. But I think it would’ve helped take the community along that trail and see the thinking behind it and explain the thinking behind it rather than it just coming up and then trying to explain it later. These are the reasons why this stuff happened. Explain why we’re about doing these things before it happens, I think would’ve been something very valuable for us to do.

Allen: Yeah. Well that’s to some degree a good lesson. But also there’s always a little bit of a trap I think in business where you’re always going to have some type of customer. Free user or free product isn’t exactly a customer. But some type of user who is going to be mad at you because the thing that they want or need is not financially viable and is not a sustainable business. And that if you did the thing that they want, you would stop existing and then they’re going to be mad at you because that’s a frustrating thing. You can explain all you want and some percentage of them will be like, oh, I do see. But there’s always a bit of a … You have to time box. As product owner, as a person building a business, building a product, you have to time box how much you do the right thing and try to do right by people who are just wronged by the universe, by they want a thing that isn’t financially sustainable at all. And then pivot to, okay, how do we make a great thing for everybody who is willing to either pay or be supported by the free version of the paid thing and be part of that ecosystem? Don’t be too hard on yourself I guess is what I’m trying to say.

Eric: Absolutely. Yeah. I think where it becomes more challenging … It’s more of a personal thing. It came from a big project or with lots of people involved. This is something that I spent literally five, six years building purely myself and created a lot. It’s just personally hard to get the negativity on, oh, it’s been destroyed when it literally has only gotten significantly better without even talking about any account, payment, anything. Those are all cordoned off and just the main products. So what you’re saying is absolutely true. Things I have to check of like, oh, here’s another negative review. I can’t let that detract from all the good that we’re doing, the things that we’re creating, the tools that are improving workflows and the things that we’re really focused on. But it is the nature of the beast too. It’s just like negativity eclipses positivity too often. So it’s also just making sure that we keep remembering that.

Allen: Yeah. There’s a famous dynamic that happens as you get fame or traction or users or scale or whatever. Which is that you have this set of … I don’t call them coping strategies, but they are coping strategies that leaders use to still maintain empathy and humility and humanity, but not just get completely subsumed by the … Even if it’s only 0.1% of all people at a certain scale. If you run Apple and even if 99.999 you have the highest customer sat ever, there are literally a million people who hate your guts even if you’re doing the best job. And obviously Apple has a lot of reasonable things that you can complain of. But whatever, think of the company that is most loved and doing the best. Literally the best run company on the entire planet at that scale. Just part of the journey of leveling up, I guess.

Eric: It’s definitely something you learn as you grow there. Not having dealt with that before it was a new experience. And so trying to build those muscles. So yeah, that was definitely learning.

Allen: So now good GitLens is part of GitKraken and you’ve been evolving the tools. I want to dig into that and a bit about what you’ve been learning and how teams are the state of the art and beyond of tooling for team collaboration building software together. But there’s one little blip of part of the story that we skipped over or very, very briefly hand waved, which is that you worked on Microsoft on VS Code. That’s interesting. Tell me a little bit about that and what you learned doing that. And that was in the pre GitKraken era, I guess.

Eric: Before GitKraken, after GitLens and after GitLens was pretty popular. But yeah, I had worked with people at Microsoft on different teams through GitLens on the live share and getting that exposed through GitLens and working with that team and launching that thing. And then I became a lot closer to the VS Code team. So there was a lot of things about joining the VS Code team to expand the Git stuff and the rest of it. I’ve created other extensions and I created an extension called RemoteHub, which basically let you virtually open a repository that it was hosted on GitHub without having to clone it locally, go and browse and all that stuff. So I created a rough prototype. I could never ship it fully in the marketplace. It used all private and proposed APIs that extensions can’t take advantage of. But I created that strong proof of concept. So one of the things when I joined that was one of the things that I wanted to start building out. So I joined up in Microsoft four or five years ago. Somewhere around there. And then started building out the timeline feature in VS Code to start bringing file history and that features. Some of the stuff from GitLens but a version of it to get into VS Code proper and then took over the Git extension and so continued managing and start building out some stuff there. And then one of the big things that I was trying to do was to build out this remote hub version, which eventually became vscode.dev And github.dev. So if you go to GitHub repo and hit dot, you get launched into a VS Code experience and then you can virtually open files, make edits, commit back, all that stuff. So that was one of the things that I was really thrilled to be able to build. It was actually interesting that GitKraken had approached me. Forget which year it was, but I think it was like 2022, 2021 in February. I was like, well I really am not leaving Microsoft until I ship this thing that I fought so strongly to get. I really wanted to see it through completion to get it launched. And so I ended up actually leaving Microsoft and joining GitKraken in October and we shipped the VS Code and GitHub dev in September. So I really just wanted to make sure that project that I spent a lot of time and effort and actually got the Microsoft machine to move.

Allen: Nontrivial exercise.

Eric: So that was a lot of fun. That was really interesting project. It was really interesting to see how decisions sway in Microsoft. Because there was false starts of started building it and then we were like, no, we can’t build it because it could compete with other things. Then external forces started coming into play and then it got back on the table. It was really interesting to get a different glimpse to some of that big company side that the VS Code team is largely insulated from but I hadn’t also experienced before. So it was an interesting learning experience.

Allen: Yeah. That is interesting because obviously large companies are infamously … It’s more complicated to get things done, to get them shipped, there’s more interest, there’s more teams, there’s more coordination and collaboration and buy-in that’s needed. But Microsoft I think is a particularly interesting case and I find I’m particularly curious when I talk to people who have had some time working at one of the groups there is because even less so than a lot of companies, Microsoft is not a homogenous organization. Even Apple isn’t homogenous even though it’s probably the more homogenous large orgs. But Microsoft is a patchwork of all sorts of different teams with different origins like GitHub. Was an acquisition that has totally different culture but then of course has been in part of Microsoft for quite some time now, but it’s still very different. And then all these different teams all have different business motivations, all these things. And so I hear sometimes very conflicting stories like, “Oh, I worked on this team at Microsoft. All of those problems that you hear about, they weren’t there.” Or someone else is like, “I worked on this team at Microsoft and all those problems work 20 times worse than you hear.” And it’s like, oh that’s interesting. So it’s interesting to or hear you say at least from the scope that you were on that the VS Code team was relatively insulated or I guess set up for success in the scale of how bogged down any given team could be and still trying to make the world a better place and ship good products that they were set up.

Eric: Yeah. It’s mainly a mini startup. Very just purely engineering led. Very different experience from a lot of the other teams. I was on the VS Code team, but because we were also doing stuff with GitHub on the GitHub dev and interfacing with the GitHub teams, there was a lot interface there, but it was also as part of that project was also bringing just VS Code to the web as some of that for code spaces. So it was like the code spaces team, which was some of GitHub, some of Microsoft and different teams. And so there’s many different dynamics. And then also what came up in that same period of time was Copilot was being incubated. So I was involved in the very early stages of Copilot and trying to get Copilot into VS Code. So my hacking skills of bending VS Code of displaying different things. And so I created some prototypes to get … Like the inline suggestions before it was actually baked into the product and turned into real APIs to support it. So doing some hacking around that stuff to help that team. So that was a really interesting experience of seeing Copilot start from something in the beginning was really laughably unusable to very, very quickly in a few short weeks become so much better every iteration. It was unreal of how quickly that changed.

Allen: Did it give you that feeling? This is some time ago now. You were some of the first people in the world to see this thing that’s probably changing our entire industry forever in deeply fundamental ways. In those weeks as it was starting to become so much better and really start to actually work and you could see the shine, did it feel epic? Did it feel like oh wow, this is a big deal?

Eric: Yeah. To be honest, I had been playing with auto complete AI stuff before that. I had talked to Tabnine and I had worked a little bit closely with that Tabnine team. I used the Tabnine product, which was really the pioneers of getting that richer auto complete. But was a very limited set. And Copilot was trying to be like can we auto complete bigger? And in the first few versions that I was playing with is I can’t use it. It’s so wrong so often. This is not even remotely close to what Tabnine’s doing. And then it was a matter of a month where it was like, okay, I’m not using Tabnine anymore. And it was just like wow. It was just shocking of where it went from just really just not good to, this is really getting what I’m thinking. Because a lot of the Tabnine stuff was originally a couple of words at most at that point. And then this would do much more full statements and then they were trying to do multi statements. The multi statement stuff never panned out at that point in time.

Allen: Obviously it has panned out.

Eric: Panned out quite well but it was just getting that line. It became amazing. It was just insane. It was just like any of those things. It was scary good, but also scary because things that it could generate a lot of times it may look reasonably good … Got the intent really well, but hey, that variable doesn’t actually exist. Yeah. It makes sense that it could but it doesn’t. That thing doesn’t exist. That’s changed a lot over the years to make that a lot better. But that was worrying as someone who understands the code base and understands what they’re working on, that’s easy to pick out. And in type checking also makes that easier. But if you don’t understand that, it becomes much more problematic. And that’s just a challenge with AI in general.

Allen: Absolutely.

Eric: If you understand the areas, it’s really valuable tool, but if you don’t, it’s a valuable scaffolding tool, but you don’t know if it’s right or not and it becomes hard to judge and it’s also human nature to defer to the computer as being the expert if you don’t know better. It’s a challenge with these tools as we continue to evolve them before they really are the expert. And we’re getting closer.

Allen: Yeah. And you have a really good perspective on this because you having worked on VS Code and having worked on the Copilot and having worked on GitLens and now having worked on GitKraken, which are all these tools in and around this question of, okay, we have a large code base we want to try and reason about it, we want to try to be iterating it, we have humans and computers and how can they work together to build better software faster, more effectively? You have so much context on this question that all of us are asking. Some people feel like they know the answer, but I think anyone reasonable has some uncertainty about how is the next five years and how is the next 10 years and honestly how is the next 18 months going to track in our relationship with these language model tools that are helping us build software and how are they changing the nature of software engineering. And think questions as simple as the one that you were poking at there, which is the relative contribution and relationship in between senior engineers and junior engineers. So what are some of the big thoughts? What’s been … I don’t want to say keeping you up at night. I don’t want to tell everyone that you’re not sleeping well, but sometimes I do find myself thinking about these things. But what’s been engaging your mind as you see these things change and as you’re really involved in helping it change with building some of these tools?

Eric: It’s interesting. I think nobody really knows. When it comes down to it is I think we are going to be just like I was in that month that it took Copilot to just take an enormous leap, I think it’s the same thing. I think we’re going to be really surprised and shocked continually in these increments as the state-of-the-art just keeps expanding. Since it came out, the shocks have been still quite amazing. Like a lot of things, I think some of the challenges are the near term. As this technology gets more adopted, it’s going to change the nature of what it is to be a good dev. Right now if you’re a senior dev or that thing these are invaluable tools to be more productive. They just help you take the things in your head. It’s easy to get them out there faster. It’s easy to vet them.

Allen: If it’s a little bit wrong, you can tell .

Eric: Yeah. Being an editor is easier than writing. And so if you can just go and get some of the rote stuff out and easily correct it and that stuff, it’s like an enormous boost. It’s a pretty good boost for even just learning something you’re not familiar with, but you got to do a lot more vetting because you’re unfamiliar. Is this the right way of doing? What are the edges there? My view is over time we’re going to get to the point of … I don’t know how far out it’s going to be. But AI will ultimately become a new compiler. It’s going to just level up the layer of abstraction that we write to. We don’t write assembly anymore and lots of companies don’t write C in other lower level languages anymore and we keep moving up this higher level of abstraction. So it’s like can we express what we’re trying to do at a higher level and still get this stuff out? So it’s going to come down to the systems are going to have to be a lot more testable and just validating this output and that thing and be able to self maintain some of this. And so I think it would be interesting. My thoughts for getting further is as we get to that, you’re just building to a high level abstraction. Just like we don’t care necessarily. When I say we don’t care, I mean we do still do in certain levels. But generally if I’m writing a project for the web, I don’t care what instruction set actually gets generated to run that on that chip. That’s just an implementation detail for having that. And so we don’t necessarily care about the code generation, we just trust that compiler, that transform is going to make that happen. And there’s so many of those layers in our systems already of that transformation all the way down to the actual hardware running it, which has many translation layers it to run. I think we will get to the point of just not necessarily caring about this code because it’ll be easy to generate and it’ll be easy to change. It’s like, oh, generate this thing that’s going to go do that. Oh no, this input is different, change this output. The code’s going to get generated now to do that and you’re going to be tweaking more spec level and test level in and out to go and validate and do that. So managing large code bases and managing large amounts of code may not be something that we worry that much about, but that’s down the line.

Allen: Yeah. But there’s a famous thing where the less code you have, the more you can reason about it, the more you can keep it in your head is what you were talking about. So obviously if we can iterate to a path where LLMs and AI is reducing the need for us to manually maintain larger and larger code basis, then that should in various ways be a big win. Have you seen any … And this is a naive question. But have you seen any efforts or projects where people are defining LM powered or AI powered higher level languages or formats that are built with this in mind? This is also new, so really only last year or two that you could even imagine building something like that. But have you seen any experiments like that?

Eric: Not per se. I think there are some that are taking a “no code platform” and trying to do the generation from higher level blocks to actually going and running it. So there are some of those examples. Some of them, even like the Versaro. I think it’s V zero. Just taking a mock UI and generating the code to go and do that and you can change the UI and generate new code and really iterate on that quickly. So those are starting there. There was some Typescript or … Started by this Typescript team. Another thing about strongly typed inputs and getting that same outputs there to iterate on some of the structures and be able to validate some of the ins and outs of the models. I can’t remember the name of the projects. It’s escaping me right now. But I haven’t seen a ton of that. But more from the UI side rather than the deeper level code of understanding the systems and that stuff.

Allen: It’s interesting that you mentioned strongly type without getting into a deep rat hole on programming language nerdery. But it’s interesting that you mentioned strong typing because there’s been this huge trend over the last decade where in programming languages where it’s strongly typed languages like we were talking about C++ before whatever. It’s like of course that’s the way that computers are written. And if you’re writing within a language like Basic that doesn’t have strong typing, then it’s like, oh, that’s just the toy for people to learn like you and I when we were kids. And then strong typing became way less in favor as the biggest applications are being written in JavaScript and Ruby and PHP. And then now in 2024, Typescript is on the rise and we have rust and we have a pendulum moving towards … Not obviously everybody’s writing in type language. Not everything is as rigorous as Haskell or even Swift in strictness about types. But that annotation happens to be in more favor or at least fashion. I think personally that it has a bunch of utility. There’s a good reasons why it’s become more popular. It’s becoming more popular at a time where we’re getting this huge boon of language models that can reason about your code better if it has annotations like that. So one of the things that I like as a thought experiment to ask folks like yourself that could think about this stuff is if you had to bet, would you bet that we over the next five or so years as we are doing more and more LLM assisted software development, that there is further move to more annotated code because it helps the model’s reason about it? Or the other argument that I’ve heard people make is that actually there’ll be a pendulum back away from type annotation manually because the LLMs will be so smart that they can infer the types and they can reason about the software, loosely un-typed software in a more rigorous way, in a way that makes it having the types actually in the code redundant.

Eric: I’ll take the middle of the road. I think you’ll actually get both.

Allen: Boo.

Eric: But I think it will be a pendulum over time. So I think in the near term you’re going to get a lot more of the strongly typed to keep the rails on that sort of thing so that you can validate this stuff. And I think you’re going to even go further with that. But I think as it gets further along where the abstraction for your less writing code and more writing a spec or explaining the systems, then I think it becomes looser again because it becomes harder to get English to be strongly typed. But there still may be strong guides on the blocks and the building and the structures of how that spec is. That would be the strong typing of that model. But it may not feel the same as a typing annotations. It’s more of a structural setup. So I think we’ll get more but then it’ll also go to less.

Allen: Yeah. I think that makes a lot of sense. I’m jokingly booing you. But I think it was actually a pretty sound argument. I could see, and I think you’re saying this, but maybe at least you’re saying a little implicitly I could see it being assembly and that there continuous to be this layer. We don’t write assembly, but the assembly still exists. And you can imagine that whatever programming languages that are the five and 10 year evolution of what we’re using to specify our programs increasingly we’re not as human beings interacting with those programing languages very much, which would free the language design to be ridiculous. You could imagine it being really annoyingly typed, you can imagine it being quite difficult to read it. Obviously there’ll be people like you and I that are maybe too old by then to be like, no, you should be able to read code and you can’t just trust LLM. But then you can imagine a new generation of people who are like, no, but this code that it writes is so much more efficient/easier to test, easier to whatever. And then you can read it. You just got to squint at it and you can figure out what it means. But I’m spending all my time just writing natural language that it’s using to create that code anyway, so why do I care that it’s really obtuse?

Eric: Exactly.

Allen: I don’t know if I look forward to that future, but I’m fascinated. I guess by then I’m not really writing much code myself anymore these days, so I don’t have to worry too much about being the dinosaur that can’t read that code.

Eric: It’s a cycle that we’ve been going through since the beginning. It’s the same like writing to the low level, writing to the registers on the hardware that you’re married to and then coming up to the assembly. A little bit layer of installation. And then coming to the next layer and keep going up. It is a pattern. And just like anything, it’s a generation thing too. What you’re used to doing is like, oh, we shouldn’t go down that. That code is really important. And sometimes at some level, the assembly that the V eight engine generates to take that JavaScript code to run it is important because how optimized that is. But then even that, there’s been a bunch of different LLM stuff of trying to do optimizations on looking at the running code and trying to generate more efficient code to run on that hardware is you can get even further down. Go from not only translating your written stuff but all the way through the stack of just getting more optimizations. Because you can see even chip layout. How the chips execute, how they’re even laid out. It has could have an enormous impact on handling stuff that is hard for humans to keep in their brain like we already can’t. These are enormous things. Yeah. It’s just really interesting where the opportunities.

Allen: I look forward to/dread to the point where we’re getting to LLMs proposing code that just doesn’t make any logical sense at all. And it’s inherently … It was like a syntax error or whatever when a human reads it. But it’s like, oh, but actually that tricks the compile into doing something that’s undocumented functionality but it makes it 20% faster or has some great outcome.

Eric: Yeah. The way electricity flows through these lines and it changes this.

Allen: Yeah. Exactly. And that happens to be totally reliable across all CPUs for some reason that manufacturing ATSMC or something like that. Okay. So I love that. And before we run out of time though, I wanted to just poke into a little bit the work that you’re doing. Build the full circle. So GitLens, became part of GitKraken and we talked about a bunch of topics around broadly teams collaborating, building tools including LLMs, but also other tools like the ones that you’ve been building so far on helping teams execute and being able to be more and more effective as your code base scales and ages basically. What are some of, or maybe anything that you’re particularly excited about in terms of work that you’ve been doing or things that you’ve been seeing in terms of stuff that makes a really big impact on that? Either stuff that you’ve shipped recently and that you’re finding is being really effective or anything that you’re working on that you’re excited about?

Eric: The things that we’re really focused on is obviously our get roots and understanding that and dealing with that stuff and continuing to expand that. But layering on top of that. Getting the teams to work more effective together and just collaboration more. Even if you consider LLM starting to write more of the code and the rest of it, still the collaboration earlier in the process on the ideas on where we’re trying to go and just getting that flushed out is going to continue to be something that’s going to give you outsized effects when you get to the outcome. So we’re trying to do things in the beginning to be able to make it easier to share code. So we shipped a feature recently called Cloud Patches. It’s really in its infancy. It’s the building blocks for us to build a lot of other workflows on top of. But the intent is to just be able to take something that you’ve written that doesn’t even have to be committed, doesn’t have to compile, doesn’t have to do anything and share it quickly to somebody else to get some feedback, get some direction. It could be pseudo code you can provide to somebody else to, here’s the scaffold of the places I think we should go on this, send it off and be able to make it really easy to apply that. We’re applying that same thing in the near future to pull requests and trying to get that to change the nature of how you review code and effectively just understand that. We’re also focused on helping developers focus. There’s always a bunch of tasks to juggle around. And so we’re trying to do is how we can optimize almost poking you for the things that you really should just get done. They’re small things, they’re team enablers, they’re blocking your team, those things and trying to optimize you to get those things done or provide better signals to your team of like, Hey, that review you assigned to me, I’m not the right one, or I can’t do it. I’m on vacation or I’m too bogged down. Making that a lot easier and all in the flow to work together. And so we’re spending a bunch of time on that. As we start thinking about collaboration one thing that I’m thinking more about, but we don’t have any concrete plans yet of how we’re necessarily attacking the problem, but as LLMs come more into this, we’re almost going … I feel almost take a bit of a step back from collaboration because in a lot of cases I don’t have to ask a teammate about that code. I can ask the LLM where do we do this in this project? Where does this happen? And the tools are getting so much better at answering those questions. The challenge right now is they’re not always right, which adds a whole nother layer of can you trust it? Which we’ll eventually get over that, but that is a challenge now. But as this evolves and you can actually trust it, I have a … Copilot is the perfect word. It is like, I have this thing I can type in at any hour, any day, ask it any question with zero judgment. I could ask it a hundred questions right away and I can get a bunch of answers that I would normally have to go to other team members, other teammates to go and answer that stuff. So there’ll be some level of this collaboration, which is how do we build the tools that are not necessarily just dev to dev, they’re dev to AI as well as that. And then even if you start with collaborative with an AI, how can you get to bring somebody else into that conversation as well and still enhance the AI experience, but continue through that.

Allen: Well, I’m very excited for this future. It seems like you’re thinking about a lot of high value things and obviously LLMs are here to help us, but it’s not just about that and the other people on our team. There’s a lot of opportunities for software to make us a lot more effective. So excited to see how that all comes together. Thank you so much for being on the show. Where can people go to find more out about you and the work that you’re doing?

Eric: Gitkraken.com has that. Our repo’s on GitHub/GitKraken and VS Code GitLens. Our CLI is on there, our newly open source browser extension’s on there. So there’s communities around that. GitHub discussions. You can find me. I’m @EAmodio on Twitter. I don’t post a ton, but definitely still consuming. I run a VS Code Slack community, so you can find that from the VS Code side. And then we have a Slack community for GitKraken as well.

Allen: Awesome. Well thanks for being on the show. It Shipped That Way is brought to you by Steamclock software. If you’re a growing business and your customers need a really nice mobile app, then get in touch with Steamclock. That’s it for today. You can give us feedback, follow us on social media or rate the show by going to itshipped.fm/contact. Until next time, keep shipping.