Jerod Santo: It’s now time for Sponsored News!

Next Edit understands the ripple effect of code changes

The newest feature from our friends at Augment Code one I’ve wanted my entire career.

Every dev out there knows the pain that follows updating a field in one file. Now you’re hunting throughout all the various places in the codebase to update SQL queries, tests, and type definitions. What should be a simple change becomes a tedious game of find-and-replace.

Next Edit is their solution to this problem. It extends beyond the cursor by understanding the ripple effects of your changes and automatically suggests necessary updates across your entire workspace. While you code, it’s scanning your codebase, identifying dependent files, and generating contextual suggestions that keep your code in sync.

And guess what, Next Edit is available today to everyone using Visual Studio Code. All you have to do is pull the latest update to the extension and Next Edit will be there to help you get more done.

Curious how Next Edit does what it does? The team behind it also shared their AI research behind the feature.

Cool stuff! Links in the newsletter.

Kevin Ball: Well, and one of the things that React introduced that was so different, and that I remember – you were at that JSConf when it was announced. And you talked about “Alright, we’re going to put JSX in here, we’re going to have everything in one component, we’re not going to separate concerns…” And it was panned. I was not at the conference, you were, but I just remember the ripple effects coming out and people were like “What the heck is this…?”

Kevin Ball: There’s the zeitgeist. I think, also – I mean, most of us are bad at foreseeing the ripple effects of our actions, especially if it’s in doing something that we haven’t done before. I doubt he in any way anticipated the level of blowback he’s gotten. And if he did… Actually, I would bet at this point still he doesn’t understand the long-ranging implications of that.

[00:40:08.21] There’s this concept of – I’m trying to remember what it is, but… Trust cascades, and you lose trust, you lose trust, you lose trust, you don’t see impact in your customers for a while, and then at some point it falls off a cliff, because you’ve passed a threshold… It’s hard to see in real time the long-ranging impacts of burning the trust to the ground.

Eric Bailey: Yeah, we’re already – and it’s interesting, we’re starting to see quantitative, and qualitative as well, if you read some of the community feedback… But quantitative results for that kind of mindset, where we’re investing in our design system Primer, making some structural changes, which has like a really good ripple effect… And for the human-facing impact, that’s amazing, because that means more people can use GitHub. And then for the numbers go up kind of folks, it’s great, because our audit risks go down, which means our legal liability goes down.

But also, things are just kind of getting generally more stable on the frontend perspective, because we are encouraging folks to take those bespoke, one-off implementations and replace them with something that’s been kind of battle-tested, and in addition, you just get some accessibility for free.

Mat Ryer: Tea. A little ripple of applause for tea. Some tea fans in here. But if you liked tea so much, you wouldn’t have thrown it in [unintelligible 00:19:29.14] harbor in Boston, would you? Which - I think that’s how they invented ice tea. Isn’t it? They’re like “Actually, this is pretty good.” Okay, tea. You say tea. Gophers say… [fail alert] No. You lose another life. Okay, Chioma, back to you. You nailed it last time with water, plain water; it’s up there. What else?

Jerod Santo: I mean, it just ominous. You’re like “Don’t make a big decision, because it’s gonna cause other big ripple effects.”

Amal Hussein: Yeah, so well said… And that’s a good pivot to just say “Okay, well, what can we do to help you all?” We didn’t get to talk too much about the backstory in terms of OWA’s kind of organizational like structure, but essentially, you all were volunteering and doing all this stuff in addition to your regular day jobs. And then in the past year or two, I can’t remember, and – when I say “you”, it’s Alex and James, who are here on the podcast today, are two people that have been working on this full-time, just because it took up that much energy to kind of do all this work with regulators… And we are so thankful, we are so thankful for that. Really, we had Alex Russell on the show, and he said that the work that you all were doing is orders of magnitude just like some of the most important work that’s happening on the web… And I would agree with him on that. You’re working on the upstream, upstream, upstream problem that has like this huge ripple effect downstream. And I’m very emotional even just really trying to think of how important this work is… Because ultimately, it just comes down to impacting the health of the web, consumer choice, people’s ability to not be limited by gatekeepy app stores when trying to ship products… Ultimately, it ties into just like freedom of speech, freedom of expression, freedom of all kinds of things. And so we need to be able to keep a healthy and open web, despite being on these closed ecosystems in terms of platforms. So just really, thank you all so, so much for the work that you’re doing. So how can we help? What do you need from people, from – how can people get involved? What can people do?

Amal Hussein: Yeah. And I think for me, just again, to give some more context to where my kind of extreme trepidation or what seems like a very conservative answer - I’ll give you some context… It’s not just me and my team and my engineers that have that cost. It’s like our ops team, our security team… There’s a huge ripple of people in different parts of the company that are impacted when you introduce large new technology into the stack. So I just want to put that out there. Like, it’s not just devs. It’s SRE, it’s ops, it’s security… And for teams it’s platform teams, it’s all kinds of stuff. So just think about it that way.

Scott Ford: So, yeah, I think all of the economic factors that are going on right now, so inflation, interest rates, two wars, the small/medium-sized bank failures… I think Silicon Valley Bank really caused a lot of VCs to really pull back some money. I’ve heard stories of companies that were funded with, say, $30 million, had their funding pulled… And so the business had to shut down. Or the investor was just like “The money I’ve given you, I want back”, or “The money I haven’t given you yet, you’re not getting.” So that’s definitely a challenge that’s going on right now.

I kind of think of like that VC funding almost as like plankton in an ecosystem… And like that dries up, and the smaller fish get affected first, and then they’re not using services from the bigger fish, and then so they start to get affected… So I think there is kind of like that ripple effect to the ecosystem.

Cory Doctorow: So I’ll tell you the hypothetical that I lean into here, that I think is technically interesting… Which is the idea that the more IT we have, the more computers and networks we have, the more just-in-time coordination we can do. And that means we can do things like – say we need to manufacture just an ungodly number of prefab construction elements to do things like relocate whole cities, or house tens or hundreds of millions of refugees. That itself is an energy-intensive process, and it’s kind of an own goal to do that in a way that that produces more carbon than you’re offsetting here.

And so I imagine things like solar factories in the Mojave, which is not – this book is all set in the suburb of Los Angeles I live in, in Burbank, which I decided to do before lock down. I started writing the book before lock down, but then I found myself stuck in Burbank. Normally, I’m on the road four to six months a year; I found myself stuck in Burbank for a couple of years while writing this book. It was actually really good. I was able to really nail the terroir as it were.

So if you’ve got a factory out in the Mojave that’s solar-powered, people can work that factory when the sun is shining, and when doing low-clinker solar centering is available to you. And then when it’s not a great day to do it, they can find people to hang out and party with… Because we have this coordinative capacity with our networks that is not present in the earlier world.

[00:20:12.12] When I was a kid, if you wanted to meet up with your friends on a Friday night and go to a movie downtown, you took the subway downtown, and you would call their house from a payphone with a quarter. And you’d either leave a message with their parents or on their answering machine saying “Can you tell Zach that Cory is downtown, and if he wants to get a movie, he should leave a message with you and I’ll call back? Or call my mom. She’s at home. And I’ll call back and find out. We’ll arrange a place to meet.” That was how we used to coordinate; it was really hard. And now it’s just like, you’re in a group chat, and you’re like “Who’s up for doing something?” and then a few seconds later you all converge.

So we have this incredible group forming and coordination capacity that we’ve never had before, and I ripple that out through the whole society. You know, there’s all this panic right now about the great reset, and this idea that no one’s going to own anything, and it’s kind of this right wing talking point… But there’s a version of that that’s really quite utopian, right? Because for my sins, I’m now a 52-year-old suburban homeowner. And that means that three or four times a year I’ve got to put a hole in a wall. So I need to own a drill. So I have the minimum viable drill, right? The $18 drill from the hardware store, whose signal virtue is that it doesn’t explode in white hot shrapnel every time I turn it on. And that drill is not an asset, it’s a liability. I have to store it, I have to use it, I have to risk my life with it all the time… But economically, it doesn’t make any sense for me to go and buy the kind of drill that someone who makes a lot of holes has.

Amal Hussein: Yeah, this is why I wanted to have this podcast discussion, because there’s just a need to teach people “Hey, when you’re making comparisons, understand what to compare.” And yeah, obviously, people don’t understand, Bun couldn’t exist without Node. Literally. And so understanding that not only did people from the Node community directly contribute – directly or indirectly contribute to the shaping of Bun, but understand that there’s certain things that can happen in a new shiny runtime like Bun that can’t happen in Node.

For example, Node actually is running and distributed on lots of machines, changing things drastically around how cache is managed on packages, or whatever… All these things have huge ripple effects in the wild when you actually have like consumers. And edge cases are not like edge cases; they’re like actual bugs. And so I don’t know, I don’t even think it’s a fair comparison even from that perspective… How can you compare something that’s new, to something that actually is in the wild, serving customers, right?

Amal Hussein: [25:51] Dyno man, okay? His whole thing with “Oh, I’m only gonna publish ESM”, which, I respect their decision to do that… But the implication of that is that you might not be running the right version of Node; your customers might not be running the latest version of a browser that would support said language syntax. There’s some serious ripple effects, and so then are you kind of transpiling your dependencies? How do you even manage that process easily, as a team? So there’s pretty big downsides.

But the flip side of this is that unfortunately, Node dependencies have been stuck in 2014, because no one is publishing “modern JavaScript” as their final output. So you have bytes in bytes of JavaScript that could be removed from the web, and we could be better optimizing all sorts of things… And there’s an initiative that I tried to start many years ago, and just got really busy, but kind of trying to say “Hey, can we have a standard around how we publish our dependencies? …because we should be able to publish modern JavaScript, and not hold the web back.” So that’s a whole thing to – right now, the web is very much held back by all of the third party JavaScript that’s in 2014 code. Minus Dyno man. So yeah, any thoughts on that?

Daniel Whitenack: Yes. It does though, I could still actually use it, because it’s only on the release date. So on the release date, which was this week, as long as you didn’t have greater than 700 million monthly active users, you can use this in your business for commercial use cases, and I think that’s going to have a huge ripple effect downstream. And we can talk about the model itself here in a second, but maybe just - I’ll pause there to get your reaction on that, Chris.

Bram Adams: There’s a YouTube video that I watched recently that was talking about criticality. I don’t know if you guys have ever heard about this, where it’s basically - imagine like a huge sand pile, and then you drop one more grain of sand and it causes the whole sand pile to ripple. So there’s a thing in neuroscience right now where they’re basically testing that on the human brain, where they basically think that the human brain is always in like sub-criticality state, where it’s like, if you imagine all of your brain firing at once, that’s like a seizure, and if you imagine your brain not firing at all, that’s like a coma. So somewhere in between that, your brain is always just kind of like exciting certain neurons, and then kind of backing off, and then exciting other neurons, and then backing off… And it has to do it in a way that it doesn’t cause the neurons to excite all of the neurons in your brain all the time. So there has to be like a barrier that basically like turns off and says “No, don’t go past here.” And then it turns on and off really quickly. So I don’t know how your floppy disk would cause the brain to go critical state, but I’m sure if you uploaded a whole gigabyte, your brain would immediately just fry itself.

Amal Hussein: Yeah, and we also can’t forget GPTZero, which is this product that came out to kind of help basically an AI recognize when content has been generated or created by another AI. It’s helping professors and anyone really who is looking to validate that the content that they’ve received was indeed not created by a machine. That’s really funny. It’s like the battle of the AIs has already begun.

Yeah, I mean, it’s really cool. I think you were kind of spot on, Nick, earlier, when you said – I think either Nick or Kball said not every company will have access to this… And I think the economic ripple that that kind of creates is going to be very interesting… Because it’s sort of like the resource war, it’s like “Well, is your house by the water? Great. Iif not…”

So it’ll be interesting how that kind of shapes our economic landscape… But I think what’s tremendously more exciting for me is that, similar to pivotal technologies like the iPhone, I think there’ll be a whole new class of companies, and tools, and for every job that gets eliminated, there’ll be N number more that get created. I think it’s just how do we kind of shift people to kind of change their habits and change their mindsets to understand that this can be an assistive tool for existing jobs, it can be assistive, and then for jobs that may be affected by this, how do we retrain and reskill?

Kevin Ball: Yeah. And I think a lot of folks just have not internalized that. And this is going to change that. Because suddenly, these folks – it’s going to be visible. And there’s all sorts of interesting and weird ripple effects, right? Those big tech companies can do that because they have massive revenue streams relative to employees. They have figured out businesses or business models where they get massive leverage on engineering employees. If that was the salary across the board, there’s tremendous numbers of software businesses that today are viable, that would not be viable, right? Because not everybody’s able to make that amount of revenue per software engineering employee. And so this is gonna – I don’t know, it’s gonna have some really interesting downstream…

Brendan Burns: Yeah, I think one of the things – Ganesh mentioned the upstream team, which is another team in my organization that focuses on engagement with the Upstream open source project… And I think in order to do a good job of both understanding how releases happen, and also potentially influence how releases happen, we have to be engaged. And we’ve had members of my team be the release leads for the open source project; not for AKS, but for the whole Kubernetes open source project. It’s a totally thankless job effectively, of like herding all of the cats of this giant project into a release… But that means that we have an intimate understanding of not just what each release looks like, but also how the broader release is evolving. And recently there was a slowdown from four releases a year to three releases a year… Effectively a reaction to the broader community saying like, “Oh my gosh, we cannot keep up with this pace of change.”

I think the developer community as well, the internal Kubernetes developer community as well sort saying “We need to slow down. We can’t just keep jamming more and more code into this thing.” But I think the real difference that I see in releasing Kubernetes versus releasing it for AKS is exactly what Ganesh is talking about, which is… You know, for AKS a lot of what “at scale” means, or at hyperscale means, is incredibly diverse customer workloads… From large-scale machine learning batch jobs, all the way through to real-time serving telephony, even like teams calls. And the upgrade has to work for every single one of them. The upgraded Kubernetes has to work for every single one of them. And it’s not even just about the workload, sometimes it’s also about like what API features did they decide to use?

[42:08] And one thing we learned early on in the Kubernetes project is no matter how much you call it beta, if it’s stuck around for two or three years, you may as well call it GA, because people will have treated it like it’s GA, and you will have set the expectation, because it hasn’t changed… And the minute you change it, it causes amazing ripple effects. And frankly, you can’t – once you have a certain number of users, you don’t have the option of saying like, “Well, but we said it was beta, and you’re all broken. Good luck.” That doesn’t fly in AKS really, at a certain scale, because it’s the principle of least surprise, I guess, at some level. Like, if you haven’t touched it in two years, people are going to assume that it’s stable, because it was stable.

So I think that’s the real distinction that is important for all of the Kubernetes providers, especially for Azure, because that’s the one I worry about is “How do we get that rock-solid reliability so that when the person presses the button, or when the Event Grid that Ganesh was talking about triggers, and someone automatically upgrades, it works?” And then tracking also. We keep track of the SLO for that upgrade, to make sure that we actually are validating it, and that we are achieving it. And sometimes that involves actually going back into the release and finding fixes, and Ganesh mentioned, carrying patches to help while you’re upstreaming those patches, and things like that… As well as, of course, something that Ganesh didn’t mention, which is making sure that also we handle CVEs, and we get notifications as a provider actually in front of the CVE release, because we’re on the embargo list… And so we can ensure that our customers are patched and secure on day zero of a vulnerability, and that they can either choose to upgrade, or in some cases, they’ll receive an automatic upgrade, kind of depending on the severity of the security issue.

Kris Brandow: I will say, I’ve worked with quite a few product managers in my past, and other business people, who are very understanding of the fact that we do need to fix technical debt in codebases and we need to fix these things that bother us… The thing that I have always noticed - I think engineers have a lot of the curse of knowledge, where it’s like, they understand things so well that they just think everybody understands them, whether it’s these people over here that are like “I’ll give you the time, but just assure me that you’re sure that at the end of this time this thing will be done.” So they enter with that, and then we say “Oh yeah, yeah, we’ll definitely get it done by then.” And then that two-month thing actually takes four months, and they’re like “Okay…” And then you do that three or four or five more times and then they’re like, “Hey, look, you’re always wrong with this. So how am I supposed to just trust that this time you’ll be right?”

[28:25] And we all come up with these, “Well, it got delayed because of X, Y and Z, and this was it”, but it’s very difficult for us to articulate that. And I think that is part of the reason we wind up with these big, messy codebases, is that we fail to articulate why we need to do this thing, and we fail to go back and actually do some of these steps in agile, of like have a retrospective and ask ourselves, “Okay, this thing that we said would take two months took four months. Let’s actually write down why that thing took four months instead of two months”, so then we know what it is that made it happen like that, and we can give that to the business, but also use it for ourselves. Because I think there’s a lot of projects inside of these large codebases that are like “I wanna fix that thing”, but we go into it without having a strong idea of how long that will take. Because if we did, we might say that thing’s not worth it. Like, two months might be worth it, but if it’s gonna take six months, we might say “Okay, well, it’s probably fine the way it is.”

So I think that’s probably another tip there of like, if you have a big codebase, the way to get it less messy is to be real and raw and honest with yourself and your team about how long is it gonna take you to fix things, and give yourself enough information, even if the business does give you that unlimited runway; even if it is the first time. You say “I need some time to fix this”, and they say “Take what you need”, you still should sit down for yourself to make sure that you have an understanding, so you don’t waste that precious time that you get. And it is quite rare, as you said, Johnny, but there are places that have it. So if you are lucky enough, then make sure you give the gift to the product people of seeing good engineering, so the next place they go they might give that team the same kind of leeway that they gave you, instead of the other way, where they’re like “Oh, well I just had this bad experience, so I’m gonna carry that with me for the rest of my career and spread it to the rest of the product people I know.” It’s like, everything has an effect. It’s a ripple effect, it’s not just an isolated incident.

Amal Hussein: Think like, “Hey, how do I–” it’s not just like, how do I make my website go faster? Making my website go faster also than makes – or making my infrastructure go faster enables all these other websites to go faster, right? So it’s this very interesting ripple.

Kevin Ball: [12:07] Gergely. Okay. The guy who is behind the Pragmatic Engineer, which has kind of blown up recently… And it was sort of a quick mention that oh, Meta is now hiring engineering managers remote always, not just engineers. At least in the U.K. And I think it’s like a hint to a larger story, which is around the continued ripple effects of the move to remote work; how more and more companies, even these large companies, are having to say “You know what - this is not just a during the pandemic thing. The world has changed. We’re gonna hire folks all over, we’re gonna have an ongoing remote plan.” And I think there are some really interesting ripple effects in terms of how it levels salaries across the country and across the world.

I’ve heard from folks who are hiring contractors in Eastern Europe and the Philippines and things like that… Folks who have been in places where salaries were much lower to do software development - they’ve seen 50%, 70%, 100% increases in how much you can earn as a software developer… And I just think it’s fascinating. There’s so many different ripples. One, that’s a lot more money; it basically makes software development even more of an export industry; you can use that to bring money into wherever the heck you are. I think it potentially – like, they’re making this money going to U.S.-based mostly, and some European-based multinational companies, which then means local software development shops are gonna be starved for talent, or having trouble competing, which means - yes, there’s more money flowing in, but there’s also less development for local-facing things. So the world is changing in a way that I find absolutely fascinating, and I’d be curious to hear y’alls take on it.

Adam Stacoviak: Yeah. Ripple delete essentially is whenever you have a large span of time selected, and you wanna delete that time, but also move what’s before it in the timeline back with it when you delete. That’s what ripple delete is. So if you’re listening and you’re thinking “What’s ripple delete?” It does a lot. It moves things around automatically for you…

Zac Smith: [01:00:00.10] I haven’t found somebody who can’t get behind that. Everybody is like “That makes a lot of sense, and I wanna be part of it.” So I think making sure we do that in an open way is gonna be really important.

And the second thing is I think we’re gonna see the OEMs, Dell, HP, CISCO, Lenovo etc, even NetApp, and F5, and Pure, and the people who make purpose-built technology in hardware - I think we’re gonna see just massive business model shifts. The cat’s out of the bag. People want aligned business models as a service… And that’s gonna be a really, really big turn for these aircraft carrier style companies; they’re big businesses that are really used to shipping you the technology and you doing everything, and now they’re gonna turn it and running it for you somehow… We’re gonna feel the ripple effects of that. But I’m so excited about it, because that’s the first leading indicator of how we can make the business models more aligned.

And people sometimes – you know, they originally inferred that Equinix Metal was kind of in conflict with cloud providers… I don’t think so. We’ve recently enabled things like Amazon EKS, and Anthos… Because I see cloud providers as software companies, that when at the right scale, run aggregated infrastructure for you. But when not at the right scale, call it pretty much anything beyond multiple megawatts - they don’t really wanna run the technology for you. They just wanna sell you the software and services. And I think that that’s a pretty aligned model with Hyperscale that we can help support.

And with OEMs, as they move into this as-a-service model, I think we can be super-helpful with Equinix Metal to help them be the best in the world with that. It’s one of the main reasons why 2014 - we’ve been making it so that we can automate hardware, no matter what it is, and where it is, and what runs on it. We might wanna add one other thing - or who owns it… Because it doesn’t really matter, right? Your server, my server, Dell’s server… It’s just a server. And can we make it consumable and usable? That just requires an adjust. That’s a startup guy talking. It just requires a business model change. [laughter]

Peter Bourgon: That would have been so nice. Oh, man. Yeah, a major blunder is the presumption that without a V suffix, it is V0 or V1. This assumption has had so many ripple effects, and it’s like “Ugh!!’ The quasi-proposal to deprecate or make SIV optional removes this assumption, definitely.

Gerhard Lazu: That’s right. A comprehensive understanding, feeling that what you do matters, understanding “Where does it fit what you do?” Experimenting. You’re not working, you’re experimenting. You’re trying to figure out how what you do works. And a very, very small slice of that is shipping. But I would even say it’s not even the tip of the iceberg. I don’t know what to compare it to, but it’s so small, so tiny. And this is something which I am very passionate about. Even though we call this Ship It, it’s insignificant in the big scheme of things. And my mission is to make you understand, listeners, how small and insignificant it is. It’s essential and important, but it’s such a small piece. And don’t think that if you ship, you’re done. No, no, no. It’s not even the beginning.

[40:13] I really like your diagram - this is another one, about perception; the ripple effect. And it applies so well to this, because it’s really difficult to understand and to map your action to something that someone else does, like your end users do.

Jerod Santo: I’ve gotta decide if I’m gonna leave that ripple part in or take it out… [laughter]

Adam Stacoviak: I agree as well. When I read it, I was like “Wow, that’s genius.” So being the genius who came up with this idea… [laughter] What are your thoughts on that? You’ve influenced a massive amount of people to be more inviting to others. That’s gotta have a ripple effect that you personally, having been the person to put that idea out there, have been a key player of. How do you feel about that?

Sahil Lavingia: [01:07:57.21] Yeah, on a very feature-by-feature basis, we’re really excited about discovery, and really launching discovery features on Gumroad to allow creators to build their audiences. We’re working on redesigning all our core UI, our edit flow, and product creation flow, and things like that… And then probably later this year we’ll try to launch a more full-featured, Kickstarter sort of feature set, so people will be able to create membership businesses.

But really the goal – I mean, you can tell when I talk about these things; I’m not that excited about the features, I’m excited about what can creators do if they have more opportunities to get paid…

I think my North Star for Gumroad in a product sense is – Gumroad gives me this financial independence; it gives me this monthly salary, I get to do all this stuff, it’s awesome… How do I take that and give it to creators? How do creators get independent financially, how do creators have 30 hours a week to do what they wanna do? This life that I have is pretty nice, I think, and I think more people would appreciate having it, and how does Gumroad give it to them? How does Gumroad give it to thousands and thousands of people, so that more people can do what I’m doing and have the impact that I’m having? …and that ripple effect will continue onwards.