The Changelog: Software Development, Open Source - Lessons from 10k hours of programming (Remastered) (Interview)

Episode Date: October 17, 2024

This week we're going back in time to one of our top performing shows of all time where we talk with Matt Rickard about his blog post Reflections on 10,000 Hours of Programming. These reflections are about deliberately writing code for 10,000 hours. Most don't apply to beginners. He was clear to mention that these reflections are purely about coding, not career advice or soft skills. If you count the reflections we cover on the show and be the first to comment the amount of reflections on this thread in Zulip, we'll give you a coupon code to use for a 100% free t-shirt from the merch store. Good luck...

What's up nerds? You're listening to The Change Law. We feature the hackers, the leaders, and the innovators leading the world of software. And this week, Jared and I are going back in time to one of our top performing shows of 2021, really of all time. And we're talking to Matt Rickard about his blog post, Reflections on 10,000 Hours of Programming. These reflections are about deliberately writingions on 10,000 Hours of Programming. These reflections are about deliberately writing code for 10,000 hours. Most don't apply to beginners. He was clear to mention that these reflections are purely about coding, not career development or soft skills.

And if you count the reflections we cover on this episode and be the first to comment on this thread in Zulip, we'll give you a coupon code for a free t-shirt, a hundred percent free t-shirt from the merch store. Good luck. A massive thank you to our friends and our partners over at fly.io. That's the home of changelog.com. It is the public cloud for developers who ship, developers who are productive, and that's us. That's you too. Learn more at fly.io. Okay, let's talk to Matt. Hey friends, you know we're big fans of fly.io, and I'm here with Kurt Mackey, co-founder and CEO of Fly. Kurt, we've had some conversations, and I've heard you say that public clouds suck.

What is your personal lens into public clouds sucking and how does Fly not suck? All right, so public clouds suck. I actually think most ways of hosting stuff on the internet sucks. And I have a lot of theories about why this is, but it almost doesn't matter. The reality is if like I've built a new app

for like generating sandwich recipes because my family's just into specific types of sandwiches that use Braunschweiger as a component, for example. And then I want to like put that somewhere. You go to AWS and it's harder than just going and getting like a dedicated server from Hetzner. It's like, it's actually like more complicated

to figure out how to deploy my dumb sandwich app on top of AWS because it's not built for me as a developer to be productive with. It's built for other people. It's built for platform teams to kind of build the infrastructure of their dreams and hopefully create a new UX that's useful for the developers that they work with. And again, I like, I feel like every time I talk about this, it's like, I'm just too impatient. I don't particularly want to go figure so many things out purely to put my sandwich app in front of people. And I don't particularly want to go figure so many things out purely to put my sandwich app in front of people. And I don't particularly want to have to go talk to a platform team once my sandwich app becomes a huge startup and IPOs and I have to like do a deploy. I kind of feel like all that stuff

should just work for me without me having to go ask permission or talk to anyone else. And so this is a lot of, it's informed a lot of how we've built Fly. Like we're still a public cloud. We still have a lot of very similar low-level primitives as the bigger guys. But in general, they're designed to be used directly by developers. They're not built for a platform team to kind of cobble together. They're designed to be useful quickly for developers. One of the ways we've thought about this is if you can turn a very difficult problem into a two-hour problem, people will build much more interesting types of apps. And so this is why we've done things like made it easy to run an app multi-region.

Most companies don't run multi-region apps on public clouds because it's functionally impossible to do without a huge amount of upfront effort. It's why we've made things like the virtual machine primitives behind just a simple API. Most people don't do like code sandboxing or their own virtualization because it's just not really easy. It's not there's no path to that on top of the clouds. So in general, like I feel like it's not really fair of me to say public cloud suck because they were built for a different time. If you build one of these things starting in 2007, the world's very different than it is right now. And so a lot of

what I'm saying, I think, is that public clouds are kind of old and there's a new version of public clouds that we should all be building on top of that are definitely gonna make me as a developer much happier than I was like five or six years ago when I was kind of stuck in this quagmire. So AWS was built for a different era, a different cloud era. And Fly, a public cloud, yes, but a public cloud built for developers who ship. That's the difference. And we here at Change.io are developers who ship. So you should trust us. Try out Fly, fly.io. Over 3 million apps, that includes us, have launched on Fly. They leverage the global anti-cast load balancing, the zero config private networking, hardware isolation, instant wire guard VPN connections with push button deployments, scaling to thousands of instances. This is the cloud you want.

Check it out. Fly.io. Again, fly.io. well matt look up to the changelog 10 000 hours is a lot to put into anything. And at some point you hit mastery. And in your blog post on the subject titled Reflections on 10,000 Hours of Programming, you quoted Malcolm Gladwell from Outliers, quote, The key to achieving world-class expertise in any skill is to a large extent a matter of practicing the correct way for a total of around 10,000 hours, end quote. So 10,000 hours to master a skill, that's where we're at. You got some lessons here you've shared, reflections for you, but lessons for us.

So let's dig into those. Where do you begin when you reflect on 10,000 hours of anything? Well, I mean, you know, just when I think about 10,000 hours, I mean, it's a long time. You know, I think about how long I've been doing this and I've been programming for probably 15 years now. And this is a lot of time to do anything. So, I've had tons of failures along the way, learned a ton of things. And I've been trying to blog more and write down these ideas so that I don't keep on making the same mistakes over and over again. So, it's a lot for me as well. It's the dry principle that I do adhere to. Don't repeat yourself when they're mistakes.

Don't repeat your mistakes. Dry them, as they say. What is 10,000 hours? So if we assume eight hours a day, five days a week, let's say eight hours a day times five, right? Times, call it 50 weeks a year, that's 2,000. So if you're working like a typical nine to five, take a couple of weeks off for vacation, that's 2 it 50 weeks a year. That's 2000. So if you're working like a typical nine to five, take a couple of weeks off for vacation, that's 2000 hours a year. And you got 15 years.

So you're well over the high water mark. Did you do the math or you just, you just like, yeah, I'm there. No, I do the math. And you know, I spent a lot of time in open source as well. So it's like, it's not even a nine to five, it's like a six to 12 or, you know, whatever. I mean, it's an all day thing. So you're well over, where did you get, where'd you earn your keep? You've had a couple of different jobs. You want to tell us about your, the 10,000 hours you put in, where it was and what kind of stuff you worked on?

Yeah. So, you know, just been programming a bunch, programmed a bunch in school after college, worked in New York for a bit as a programmer, came out to the West Coast here to work at Google and worked on open source. I worked on Kubernetes and kind of specifically a bunch of subprojects in Kubernetes. So I was a maintainer of Minikube, kind of the local development environment for Kubernetes.

Scaffold, which is kind of a Kubernetes tool to help you build and deploy your apps. And then Kubeflow, which is a machine learning kind of toolkit on top of Kubernetes as well. In addition to that, like I've just been kind of hacking on all sorts of open source projects, I wrote this configuration language Virgo, which is kind of for it's you can think of it as like, if YAML was for kind of graph-based configuration instead of more hierarchical. And then, you know, built a computer vision bot for RuneScape, which was just a game that I used to play as a kid. Nice. A ton. And, you know,

learned a lot about programming through that just because, you know, I was always too lazy to mine the rocks or click the buttons all day. And just like tons of projects like that. Awesome. Well, you can learn from experience, but you can also life hack and learn from other people's experience. So I loved this post. You had 31 things that you've reflected, and it is specific to programming. These are not large life lessons or people lessons, you say.

These are like specific programming lessons that you've learned and i thought let's get some of these out and we're not going to cover all 31 here we'll reference the blog post of course but it's nice to have the one-liner because you can kind of it can resonate with you or maybe shock you but then i think it's even nicer to have a conversation around these things hopefully they become even more sticky or more real to people. So we're just going to go down, pick a few, see how long we last, and talk about some of these reflections of yours. Sound good? Sounds good.

I have a bonus for a listener too, by the way. Since we don't know how many we'll cover, and there's a free t-shirt in mind here, I'm curious if someone can listen closely, and the first person who can say how many we cover, if we cover all 31 or not, or at least how many we cover in the comments gets a free t-shirt. So the first person to do that comment gets a free tee. Okay. What do you think, Jared? Sounds good. We'll have to partially cover a few and still have arguments over, was that actually one?

That's right. We won't use any of the real words. It'd be ambiguous, right? All the words have been changed to protect the innocent. Sounds good. Free t-shirt. Why not, right? That's right. The price is right. We won't use any of the real words. It'd be ambiguous, right? All the words have been changed to protect the innocent. Sounds good. Free t-shirt. Why not, right? That's right.

Could be the price is right. Just don't go over. Be under. Okay, don't go over. Adam will post the official rules in the show notes. Best effort gets a t-shirt. This audience is software developers. You know, we are pedantic, so we want to have the specifics laid out in code if possible.

Can you put in a smart contract, Adam? That would be appreciated. Yeah, I want to write it in Ether, honestly. It we want to have the specifics laid out in code if possible. Can you put it in a smart contract, Adam? That would be appreciated. Yeah, I want to write it in ether. Honestly, it's gonna be fun. All right, let's pick up on a reflection. This seems to be perhaps your favorite or you said you wrote some configuration language yourself. Here's one about configuration. I had not heard of this. This is reflection number 30. Oh, I probably shouldn't list them now because we're making it more difficult. This may or may not be in your list. And this is about the heptagon of configuration. Matt, I'm gonna let you explain that to me because I've never heard of this before. Yeah, I mean, you probably never heard of it because I, you know, I tried to come up with

it myself. I tried to coin the term. So it's, you know, it's a new thing. But it's me trying to describe a pattern that I've seen in kind of software configuration, where configuration seems to evolve through specific increasing levels of flexibility and complexity before returning to either hardcoded values or bash. So you go from like hardcoded values, which are the easiest, the simplest configuration, but provide very little flexibility. And as the program surface starts to increase, and with that configuration, you know, you start to incorporate environment variables, flags, and eventually, you want to start to check that into version control. So you turn it into a configuration file, maybe YAML, JSON, something like that. And then, you know, as you kind of turn on this,

this heptagon of configuration, and I only called it heptagon just because, you know, a lot of the ideas came from Kubernetes and Kubernetes logo has got the seven points and just kind of worked out well. But as you're going from kind of configuration files, you start to need a little bit more extensibility in terms of templating. And I think templating is something that we're all unfortunately accustomed to a little bit too much. So that's kind of one wheel on the configuration, Heptagonic configuration. And then from templating, you go to kind of a DSL, a domain-specific language, and that allows you to have a little more type safety and a little more domain specific

reusable modules. And I'm sure some of us have used Puppet in the DevOps world, or there's tons of other DSLs out there. But eventually, these DSLs become a little too inflexible. Maybe the requirements change, the domain changes, and then we go back to Bash. So that's kind of like this never ending cycle of configuration that I've seen. And, you know, I saw this a lot in Kubernetes. There was a lot of Bash in Kubernetes and a lot of configuration. Maybe we skip the DSL part. And, you know, maybe that's more of kind of a configuration as code or something like Pulumi.

But, you know, maybe we'll go back to hard-coded values at some point. I guess what's the takeaway there? Is it like just stick with Bash and everything will be better? Or is this like necessary complexity? Or is this cycle virtuous or vicious? That's a really good question. I don't know if it's either. I think it's just necessary complexity. And I think it's important to know maybe where you are on the spectrum. Because I do think that you need to, you can't necessarily jump from something like hard-coded variables or environmental variables to going to a DSL. You know, I've never really seen that work out.

So I think you do need to increase the complexity, but in a way that that complexity can be absorbed by the projects or the developers. Almost like the process of iteration is necessary, right? Like the, you almost learn something, you said as the surface area of the program evolves, it's almost like this iteration through the flow, this heptagon is necessary to sort of like flesh out the brittleness or the flexibility, then the eventual brittleness again of an application because you sort of learn something about it. You provide configuration to the user base

so that they can use it in a more flexible manner. And then those flexibilities turn into like, well, this is now a best practice. So all those things solidify to now you want to just hard code them. So almost everybody uses the same flexible configuration in some cases. I mean, there's a thousand different ways you can slice how this is used in the real world, but that seems to be a necessary iteration process.

Yeah, yeah, I really like that point. I think it's a lot about discovering what those best practices are and starting to codify them in different sorts of ways. There's an analog to this in economics. Benedict Evans talks about the process of bundling and unbundling. And he says in any given industry, you're either in a bundling processling and unbundling. And he says in any given industry, you're either in a bundling process or an unbundling process. And it's just, it's cyclical, right? So an example of that is like television where we were all cable TV,

everything was bundled as one. And then we broke out of that individual on demand, subscribe to this, that the other thing. And now we're like in a rebundling and it's happening. You can see it with YouTube TV and different aggregators trying to pull together content and that sounds very inefficient like your heptagon sounds inefficient because it's like well we're going around in this circle but what i've heard pointed out is that progress often

looks like a circle when you look at it on its head, like in a two-dimensional plane. But then when you look at it in three-dimensional, it's more like a helix, where it is moving in a circular way, but it's getting better as it goes. And I think with software, that's a lot of what we're seeing is these iterations, and a lot of times returning to the old idea, but you're returning to it with new eyes. You're returning to it with new tools. And so you are building up, but you're not like building blocks on top of each other.

You're kind of like circling a wagon, but you're going up, you know, it's like a helix rising, which is slower than we would want it to, but it's still progress, right? Yeah, yeah, I think that's a great point. And I think we're seeing that play out in the data stack a bit with a lot of old ideas around tooling around data warehouses. And now

that we have cloud data warehouses, you have Snowflake, BigQuery, Redshift, etc. We're bringing back a lot of those old ideas, things like OLAP cubes there, you know, there's analogs to that now. And just it seems kind of like more of the same, but it's really different once you start to look under the surface. Well, another lesson here is one that we touched on with the brag, Prague fellows themselves around dry. This is always controversial dry. And it's because we all think about it a little bit differently,

or I think that we all misunderstand what their point was. They did point out on that episode when we had their 20th anniversary show that one of the most misunderstood points in the prag prog book is the chapter on dry so they tried to rewrite it i haven't read the rewrite very closely to know if they accomplished uh clarifying that but you have a point here one of your reflections says know when to break the rules for rules like don't repeat yourself sometimes a little repetition is better than a bit of dependency. And you link to another blog post of yours called

Dry Considered Harmful. You want to unpack that one for us? Yeah. I mean, the dry consider harmful, maybe that's a clickbaity. Yeah, a little clickbaity. And, you know, I don't think it's actually that harmful. I think the way that it's been dogmatically used is sometimes a little dangerous. But it's just more of a point about how, as programmers, we have a bias for abstraction. So understanding that we have that bias and trying to keep it in check, especially when it comes to duplication versus encapsulation. I just think that it's a path that I've gone down too many times of carving out microservices or creating service boundaries where there really shouldn't be or prematurely optimizing when requirements aren't really finalized and the requirements are never finalized. And just the wrong abstraction at a low level can really cause a lot of issues in terms of refactoring and just added work down the line. Yeah, I think we fall prey to this because we're such pattern matchers.

And as soon as you spot that pattern, you're like, ooh, opportunity. Some of that, those abstraction layers are the power in software, right? Like the ability to build those abstractions are what give us leverage. And so every time we see one, we think, boom, I'm not going to repeat myself. I'm going to dry this sucker up. But like you point out, oftentimes that second iteration, that second usage is not actually generalizable or it looks generalizable until you find the third one, which, you know, just throw another param on the function, you know, is what we do. We're like, well, I'll just throw a true false at the end of this thing.

And then I have this extra branch in my function because it didn't actually map onto the use case. Like I thought it did. So a lot of it's just that enthusiasm. I think of like, ah, here we go. I'm going to dry this sucker up. Feels so good. But it does come back to bite. Yeah.

I don't really know how to get around it. It's just, you know, I keep on falling prey to it over and over again but maybe that's just kind of the name of the game what do you think comes out of the falling prey to it again and again do you think that uh it's a necessary thing that you just learn from and grow from as a result of like just this awareness that it's not efficient to repeat yourself. Instead of saying don't, let's say maybe not repeat yourself or should not versus don't. And it's kind of a little softer on the – it's maybe just being more aware of the times when there are the patterns that you should – said Jared, like the pattern matching. To just be aware that these can lead down bad roads if you repeat yourself too often it makes sense to

dry up things you know what i mean to treat it more loosely it's like an awareness thing well it's worth pointing out what their the rule really was or is that they point out in the pragmatic programmer book and the repetition is not about code that's where we all get it wrong like anytime you're repeating code it's bad so don't repeat yourself so let's create a function name it etc abstract a function what they were talking about is knowledge in your system like every piece of knowledge in your system should live in one one place in one place only but because the acronym was dry and it's such a catchy thing and it's easy to remember don't repeat yourself as soon as you start repeating something you just immediately apply it right yeah but that's not the point it's not about the code that you write now some code it does

represent knowledge so it does overlap these things are not completely black and white but that was what they were trying to say maybe they say it much better in the 20th anniversary edition but that's why we all get it wrong I don't know Matt what has anything helped you I mean you're writing this as a reflection so you've

obviously thought about it do you just tread more softly I mean, you're writing this as a reflection, so you've obviously thought about it. Do you just tread more softly? I've introduced the rule of three for myself, which I think I got from Jeff Atwood's Coding Horror blog, where he's like, you have to use something three times before you'll generalize it. Because I have found that it's usually that third use

that points out how bad my abstraction is. But I've also found out sometimes it's like the sixth or seventh use, you know? So it doesn't always help you, but it does help me slow down a little bit and maybe just like bite the bullet one more time. What have you found? Yeah, I think the distinction that you made

that the knowledge shouldn't be duplicated and is not so much about the code, I think that's a really good lesson. For me, I try to understand the bias I have for abstraction and, you know and correct against it. So if that means erring on the side of duplication, then that seems to be kind of the most helpful for me, especially on smaller projects when it's either just me and a few other devs or just me. Duplication, I think, is fine because the knowledge tax is maybe not as high. But on large teams, I think maybe go the extra mile and make sure that you're not repeating yourself because

the cost of repeating yourself in that context is maybe much higher. Well said. I had to just practice this discipline yesterday because I was creating a game board for Go Times 200th episode. We played we played go for say which is their family feud edition and i wanted a visual aid and so i found a a guy who had written one on codepen i just wanted like just show me the thing you know like how family feud works right and you guess it and they like show me what the survey says and the thing bing and it shows a number and i wanted that for the live show so i grabbed this guy's code pen. I just downloaded it. It's just, you know, an index file, a CSS file, a JS file. And I started tweaking it so it would work for ours. And I know I needed

seven rounds. And so like programmer me is like, all right, well now I need a templating language, right? So I can just template this out and then have like a data json data blob that like represents it and then pragmatic me was like dude just copy and paste this file seven times and write the actual data into the html you're never using this again right and if you do then maybe you can abstract it later but like just repeat yourself even seven times because i knew that was it. I was gonna do it seven times and I was never going to touch this again. And I had to like exercise the discipline because programmer engineer me had

such sweet solutions for how I could generalize this sucker. Maybe turn it into a web app that other people could use, you know, that inclination. What helped was I had to have it done in like an hour and a half. And so I'm like, don't start coding, just hard code the values and move on, man.

It's tough. It's tough to fight that urge to generalize. Let's move to the next one. Here we have a reflection of yours around code comments. You say, if you have to write a comment that isn't a doc string, it should probably be refactored. Every new line of comments increases this probability and then you have a link to a more nuanced take which is from the linux kernel

documentation which i did not read because who has time for nuance right first of all tell us what when you have that it's not a doc string what specifically do you mean by a doc string and then how did you learn this and why do you believe this yeah i think a docstring? And then how do you learn this? And why do you believe this? Yeah, I think a docstring can mean a few different things in different languages. I think for something like Java, you know, maybe it's a little bit more defined, but basically just a comment that describes what the function is actually doing. And maybe that feeds into some sort of language server or automated documentation. Right. So you're talking about inline comments, like contextual things, hints. Exactly. Okay. And, you know, I wrote this more as kind of like, you know, it should be maybe a, you know, yellow flag, maybe not so much a red flag in terms of, you know, when you see this

happening. I think that I linked to the Linux kernel documentation, and I think they describe it very well. And they say, you should never really try to explain how your code works in a comment. It's much better to write the code so that the working is obvious. And you want your comments to tell what your code does, not necessarily how. And I think that's kind of the right way to go. When you're really trying to explain exactly how your code works, then maybe you should refactor it. And maybe that's a sign that other people are really going to have a tough time understanding what's going on, even with a comment. Is there a best practice for commenting then?

Like, are you commenting every function? Like how to get to the point where you need to explain every single thing? Like if you're going to explain what it does versus how it does it, how often are you personally commenting in your code? Is it frequent? A lot? Yeah, I would say in terms of inline comments inside the function, I would say rarely, you know, unless you're doing something really clever where it's not that obvious and, you know, you can't get any sort of context clues from variable names or control structure. I think it's pretty rare to see that. I mean,

it also depends what kind of program you're writing, right? If you're writing a really low level library, you know, I think it does make sense to be overly verbose. But, you know, if you're writing some sort of business logic, I think it maybe makes a little bit more sense to, you know, keep it at the function level, or, you know, put it in maybe a different place. Yeah, I think the rules change entirely for like library authors, maybe API designers versus to keep it at the function level or put it in maybe a different place. Yeah, I think the rules change entirely for like library authors, maybe API designers versus somebody who's writing application code,

business logic. I think the rules change. The best practices change. Most of my comments are apologies to my future self. Like, sorry, I couldn't think of a better way to do this. Or like admitting this is gnarly. This is a little bit gnarly, but I couldn't think of a better way to do this you know or like admitting this is gnarly this is a little bit gnarly but i couldn't think of a better way and sometimes you just have to move on and come back and you'll it'll come to you but yeah i think the what and

the wise those should be inline comments not the house because the how can change right that's implementation details oftentimes we see jokes because the comments describe something that no longer exists you know like comments become out of date especially when you're saying how that's the most out of date thing because that's going to churn is the how usually more than the why yeah but this ties into another one that you say which is if it looks ugly it's most likely a terrible mistake but i just love that because it can apply to so many aspects of life. But your point is like refactor the code versus making the comment if you can. Like refactor the code so it's readable and clear.

But then you say if it's ugly, it's most likely a huge mistake. Where'd this one come from? I love it, but I'm not sure where you drew that conclusion. Yeah, definitely personal experience here. When I was working on Minikube, a lot of the complexity is around, you know, it's spinning up a single node Kubernetes distribution on your laptop. So not only are you one layer deep with containers, you're also another layer deep with the fact that it has to run in a virtual machine on your laptop. And so that's Windows, that's Mac OS, we optionally spin up a VM on Linux. But I found myself working with

some pretty undocumented virtualization libraries on Mac OS. And you know, I was starting to think, maybe this is not the most maintainable way forward. And so I think that's one piece of personal experience where when it was ugly, it was maybe not the right way to go. Okay, we're here in the breaks. I'm here with Faraz Bukhdige, founder and CEO of Socket.dev. So Faraz, you put out this fire post recently on X. And I'm gonna paraphrase, you say the XZ package backdoor was just the tip of the iceberg. Give me just a peek behind the scenes of this incident and what you mean by it's just the tip of the iceberg. Yeah, so I think the XZ utils backdoor was really eye-opening to a lot of developers.

It showed the vulnerability of the open source ecosystem. You had this maintainer who had been tirelessly maintaining this package for 15 years, who was targeted by nation state actors, who created, like literally, it's like a spy movie, right? They had multiple personas, fake personas, that were contacting this poor maintainer and working on him psychologically

to convince him over the course of two years to add them to the repository and give them publish permissions. And they did this through a bunch of kind of negative messages, but also by being helpful and by sending good, positive pull requests. It's really like, I really think it's out of like out of a spy movie, just kind of the level of effort that they put into this. And what they were able to do is get access to this package. This is built into pretty much every Linux server out there. And what this would have let them do is it would let them SSH into any server and run any command on the server without knowing the password, without being authenticated to the server. So this would have been like a world ending, potentially kind of an attack, right? It would have been probably

the worst attack we've ever seen. I'm not exaggerating. It could have been that bad, but we were lucky through a total accident. Uh, this backdoor dependency had made it into the beta builds of some popular Linux distros, but it hadn't made it all the way out to the stable version yet. And a developer who was testing out the beta versions of these, uh, Linux distros noticed, uh, some,ros noticed some weird behavior. He noticed that his SSH connection was taking half a second too long. And so he pulled the thread and traced it back to this backdoor dependency. And we were all saved because of this total accident.

It's mind-blowing to me for a couple reasons. Like one, obviously, like, wow, there's literally states out there, countries that are trying to target open source now. Clearly, there's like a team behind this. They probably didn't just work on this one dependency. They were probably working on getting access to many other ones in parallel. If you just look at the time between the emails they sent to the maintainer, they were about a month between some of these emails. So they were probably working on other maintainers and trying to get access during that time.

So that's really scary. I also think it's pretty scary to see kind of the fact that it took an accident to find the attack. It makes me think like, how many have we not caught as a community? How many have we missed if this one was caught by a total accident? It was eye-opening to a lot of people

and it made people realize that there really is a threat in the open source ecosystem. And it's not because most people are bad, it's the opposite. Most people are good, but there are a few bad actors out there taking advantage of the trust in the system. That's really where we come in. We're trying to give every company the tools to protect themselves from those types of attacks.

And that's what we do at Socket. Okay, friends, go to socket.dev. Security dependencies. Socket is on the front lines of securing the open source ecosystem. They're a developer-first security platform that protects your code from both vulnerable and malicious dependencies. Install the GitHub app or book a demo. Again, socket.dev. That's S-O-C-K-E-T.dev. And by our friends over at Supabase, here in the breaks, I'm here with Ant Wilson, CTO over at Superbase. So Ant, I know our listeners know a lot about Superbase, but who are you? So I'm the CTO at Superbase. And so I care a lot about the platform, whether it comes to uptime, security, availability, but I'm also

extremely passionate about bringing Superbase to more developers. Okay, so bringing Postgres to more developers. I'm a big fan of that. We love Postgres here at Changelog. A lot of developers feel like the main choice or a primary choice for them is Amazon Web Services, AWS, right? No one gets fired for using Amazon Web Services, but Superbase is build no weekends, scale to billions. What's your vantage point on this as CTO of Superbase? When I started in my career, AWS was kind of like new and shiny. And it was so cool that you could go to this website and spin up infrastructure.

And then they give you all the tools to manage it. You can drop into the console. You can kind of do whatever you want. And you pay for it on a usage basis. If you use a little bit, you get a little bit. If you use a lot, you pay a lot. The expectations of developers have raised since then and I think will continue to be raised because I no longer want to manage my own infrastructure. I don't want to drop into the console every time I get an additional 10,000 users on my platform to tweak

the knobs and make sure that the service is still up. Oh by the way I've now got to go and make adjustments to the API gateway to allow for a new geography or whatever it is. I don't want to do that stuff. I want to concentrate on building the cool stuff that I imagined the night before and I think just giving people the ability to focus on the cool thing you want to build and not have to worry about the infrastructure anymore is kind of the promise of super base that will change in the future as well you know now you have to write your schemas like you shouldn't have to do that in the future again just focus on the cool thing that you want to build well super base is open source you can self-host it if you want to it is postgres for life it is open source for life authentication

instant apis edge functions real-time subscriptions storage vector embeddings things for ai it's got it. And no servers managed by you. Just build your app. Build it in a weekend. Scale to billions as you grow. Learn more about their recent launch week at superbase.com slash launch week. Or go to superbase.com and get started. Once again, superbase.com.

That's S-U-P-A-B-A-S-E dot com. So anytime you reflect on 10,000 hours of programming, surely Stack Overflow comes into those reflections. And it turns out it did. Because one of your your findings or one of the things that you believe now, after all this time, is that browsing the source is almost always faster than finding an answer on Stack Overflow. Now, I kind of agree with you, but I also kind of disagree. So I'd love to have you elaborate a little bit on this one. Yeah, I mean, this is one that I've found super helpful just because the code can never lie. And the documentation could be out of date. The blog posts you're reading could be out of date.

The stack overflow answer could be out of date. But if you're looking at the right commit, then the code necessarily can't be out of date. I do think that it's maybe a little bit language dependent. I write a lot of Go. So, you know, there's Go docs, there's the code organization and Go is maybe a little easier to grok than something like JavaScript, where APIs can kind of be all over the place. And you're using libraries that might be nested 10 libraries deep. But for the most part, I've found that just looking at the code is the right way to go. Now, what if you're looking at some code

on Stack Overflow? Still could be. Still looking at the code, right? Code can't lie. That's true. Maybe that's the loophole. Definitely got to check the date on the Stack Overflow, that's for sure.

Because if it's like from 2016 and it's 2021, it might be out of date. Might be. Yeah, I don't know. That's a hard one, too, because it depends. And the reason I say it depends, and maybe this is where the difference is, is these are reflections about pure coding, whereas my example here I'll give is more about using.

So I've been doing a lot of stuff locally with Docker, a lot of containers on my local network, and I'm doing things with Docker Compose and just learning more about different ways to extend and use Docker Compose. So they're YAML files, configuration essentially. And I'm not going to go read the Docker source code to learn about Compose because the docs are pretty good. So in that example, but that's not pure coding. That's not that core flow either.

It's kind of coding, right? I'm coding a config file, which isn't necessarily coding. You're using a thing. It's sort of the ambiguous middle there of coding. Yeah. It's almost like a good example is like, how do I properly call FFM peg with these flags from my app? I just say that because we call FFM peg from our app. I know I've looked these things up and it's like okay well the man page is a start but holy cow have you seen ffmpeg's man page it is massive i mean ffmpeg i give it praise often it's one of the most robust tools i've ever seen i mean the thing can do so many different

things it's amazing and it's incredibly black box i mean even the flags are very weird. I end up on Stack Overflow a lot, and I never look at FFmpeg's source code. Now, maybe in that case, I'm just a user of a tool, and so source code is never going to be where I would go unless things aren't working correctly. Maybe you just say, well, now the man page is really what I'm kind of thinking about. So contextually, when you say that,

are you referring to how to solve my particular language feature problem or how do i loop over these arrays or how do i use this reduce function or are you thinking what context are you saying look at the source code or what kind of source code are you referring to yes your own other people's for me i think it makes the most sense to look at the source code when you're taking a dependency on a library. I think that's the most obvious one for me. Yeah. Just because you're not accessing like an API on HTTP, you're not accessing an RPC, you're actually, you know, taking a dependency on some code. And sure, there might be a documented way that, you know, these functions are public, and you know, these are the ones you can use. But for the most part, I think once you're at the code level, you should stay at the code level. If you're at the binary level, if you're at the CLI level, yeah, I think

it makes a lot of sense to look up, how do I, you know, cut this clip to 30 seconds? You know, that makes sense, right? You're not going to look at the, you might not even look at the man pages for FFM. No, I just Google that immediately and end up on Stack Overflow. I'll admit that this advice would have been good yesterday, actually, for me. Matt, you're a day too late, man. A day late and a dollar short. So I'm having Matt Billman and Christian Bach from Netlify on Founders Talk soon.

And I was digging into my personal site, which actually is using Netlify. And so I was going to make some updates to it. It's a Jekyll site, essentially. And I'm using a plugin called Jekyll Assets. And something changed with Jekyll since the last time I updated in 2019 to 2021. So now I guess Jekyll Assets works differently. And so things that were working once were now broken. And I was digging through documentation rather than source code. And I wasn't finding my answers. I think if I'd have taken your advice and just dove into the source code a bit more, I can understand a bit more how I might be able to pull assets like I'm expecting, because I can see the coaching. That's a great example.

Rather than the documentation be obsolete or non-existent from my use case, I can actually read the docs on how assets cause an image, for example, and what happens as a result. Let me add on, I think that's a great example there. And let me add this to what Matt is saying, because I believe this to be true.

If you have a library dependency that your application relies upon, and you're afraid to, or for whatever reason will not peek under the covers and grok its source code, you should not be using that piece of software. You should be willing, ready, willing, and able to read the source code of your dependencies. Now, sometimes those people are better at writing software than you are. I've learned tons of things. Other times you're like, what the heck is going on? Well, if it's ugly, it's probably a huge mistake.

You will level up as a developer. You will better maintain your application. You'll better own and operate your application. And you'll be much better at vetting dependencies, being willing to do that. So I think Matt's advice there really pays dividends because not only are you getting at what is true, but you're also getting familiar with all your entire stack versus just the parts that you're used to maintaining. I think black box is kind of a lie. Like there are some things which they can be a black box for a while,

but that's just somebody else's abstraction, right? And so you're going to have to, it's going to leak eventually. And so be willing to dive in there and look at that code. Now, when it comes to learning, you have another one here, only learn from the best. So when you were learning Go, you were at the standard library. Now I produce Go time and i know that there's people that wrote the standard library that may say yeah don't read this part of the standard library but nonetheless you went after it and of course the standard library is written by expert go developers do you want to tell us more about this particular reflection yeah i think that you know maybe the

go standard library is a little strong for most people. Maybe it's not at maybe the right level of readability for most projects, depending on what you're doing. But I think, you know, just as a general rule, find the best examples of code and emulate those instead of, you know, I mean, there's, I look at a lot of the code that I've published as open source. And, you know, I really hope that no one's reading that. Just because it is, you know, I really hope that no one's reading that just because it is, you know, it's kind of half complete. Sometimes it's maybe not using best practices, you know, I'm doing workar it. There's a lot of great examples of what an API should look like, API versioning, API machinery. And I think those are the examples that you should be looking at, depending on what you're building. I actually learned a similar lesson to this from a fellow named Brian Tracy, but it was more in the sales vein and more of a self-development vein than it was simply programming. But the analogy is very similar.

Basically, if you want to be good at something or excel at some way at something, look at who's already doing it really, really well and emulate them. So the practice essentially is if you want to do something really well, find out who's doing the best currently at it or writing the best current version of it and emulate what they've done. Not so much to copy them, but to follow their path to greatness. And you may branch off and find your own path, but follow the greats to greatness and you may be great yourself. I like that. Now, how do we identify the greatness? Luck.

You want to be good? Well, I think, you know know in the case of say the ghost standard library i think it may have been written by some really well-known and knowledgeable people inside of google for the most part right so i think they're pretty good examples of people to emulate considering their career and what they've touched and what they've brought to market so i think that's a good example there i think otherwise you know you just got to just got to follow your peers, you know, pay attention to the change. Love this podcast, for example, that's how you find greats. You pay attention to the media and the content happening in the space. You know, you pay attention to Twitter, you pay attention to maybe TikTok,

who knows, but for sure, Stack Overflow, for sure, GitHub, for sure, standard libraries, for sure, the package registries, what are are other people using what are other people using as dependencies and all that work will shake out who's great i almost stopped yet tiktok but let's just keep going all right i know so i have a i have a rule i have to mention tiktok at least once every podcast from now on i thought that was silicon valley that's that too you're still working on that one i'll bring up silicon valley if you want we could do it go ahead bring it up right now. What's a good example of the greats there?

Well, I think in Silicon Valley in particular, and this may be just a break or something else, but the way you found the greats there was just by paying attention just to where the money was going, who was getting funded, who was competing, who was stealing engineers away from others. In many ways, it was Gavin Belson, the evil bad guy, essentially the big tech person, fighting the little guy trying to build the best algorithms to build a better internet. You find the best by just seeing who is actually putting stuff in the

market and winning. That's how you find the best. I take it back. Do not work in a Silicon Valley. That was a good effort, though. We're talking about other people's code, reading their code, learning from them. Number number 14 i'll give you guys this one listener number 14 this definitely counts as a lesson use other people's code religiously it kind of ties into what i was just talking about when i was saying you know don't be afraid of looking at the said code i

was saying you shouldn't use it if you don't. It doesn't mean you have to understand it, but you have to be willing to dig into it, I think. That being said, you say like, you know, go ahead and use. And a corollary is most code is terrible. Sometimes it's easier to write a better version yourself. So while these seem to be a little bit contradictory, like use their code, but don't use it when it's bad.

Yeah, I think what I was trying to say there was that all code is terrible to some degree so even if you if you look at a library and say you know oh maybe i could do this better you know sometimes it still makes a lot of sense to take a dependency on that library and use it just because it's been maybe more battle tested it's maybe a time thing in terms of like you know you maybe you could you could write something as good you haven't really tried but is that kind of the the core value that you're trying to drive in in your application or something like that so i think maybe just don't be afraid to take dependencies i mean know what you're what know what you're getting into to some

degree a lot of the other rules are around, you know, not tangling your dependency tree, not taking dependencies on super tiny libraries. But for the most part, I think you have to use other people's code because that's the only way to continue building exciting things. about the continuum between dependency hell and not invented here syndrome and how that we all live somewhere along this spectrum and i think that your appetite changes over the course of a career i know that when i was first getting started i used almost exclusively other people's code right because i wasn't very good at writing code so i couldn't really accomplish very much on my own. Easy example, maybe you're using Ruby on Rails and you're like, I want to do authentication. And it's like, I don't know how to do authentication. And then this was years ago, you would find the devise library and

you would use that code. And all of a sudden I could do authentication. It gave me powers I didn't previously have. Fast forward five, 10 years, I could now write that from scratch very easily, right? Because I've now seen how it works. I've used it. I've got opinions on it. have fast forward five ten years i could now write that from scratch very easily right because i've now seen how it works i've used it i've got opinions on it i've implemented it myself a few times not the entire device library but authentication right and so now my appetite kind of changes and the decision making process kind of changes because it wasn't like hey i couldn't do it myself but now it's should i do it myself? And so how do you make these decisions? Matt, you've put your time in surely you've gone from in certain areas,

can't accomplish it to now you can accomplish it, right? You could code it up. But how do you decide what are the circumstances in which I go ahead and take on that dependency? Or when do I break out the text editor and write it myself? I think a lot of it is context dependent on what you're building. For instance, when I was writing lower level kind of library code, in that sense, I think you want to take as few dependencies as possible, just because it can really complicate some of your downstream consumers. If you know, they need a dependency on let's say, like left pad or something like that. But if you're, you. But if you're writing more kind of higher level application code, I think you got to ask yourself, what goal? What are you trying to achieve here?

If you're working on a startup, I think it makes sense to outsource as much of the non-core value proposition of your application as possible. Sure, you can write your own authentication library, but just look at how many amazing startups have been built on Ruby on Rails, GitHub, Shopify, GitLab, just to show there's a ton of others. But sometimes it makes sense to just use other people's code in that case. Would you also say it's like proven ground, where if you're at a lower level, you're on less proven ground. So there's probably less code to potentially even choose from, even if you could.

And maybe where you're in more proven ground, say a front end where things are sort of stabilized or something like that, it makes a lot more sense because maybe even the user base of that dependency might be great. They've got a lot of community happening there, a lot of support coming in, so it makes zero sense for you to invent here rather than

dependency yourself yeah i think that's a great point yeah especially around certain projects where the community rallies into a specific project i mean devise is a good example from maybe five ten years ago now where all of the authentication things like instead of rolling your own you use devise and then you worked on devise with the devise people and everybody's making that one thing better. And so you have way more eyes on it. You have way more feature development bug fixes while you're sleeping, like that whole community open source flywheel gets rolling. And that's a real benefit. Now, on the other side, a community can move away from you and your project, right? Like all of a sudden they're adding things that you don't want or need and you disagree with.

And too bad the community all thinks this is good, but Hey, I don't need SMS based two factor off. And like, now you're just adding lines of code to my project when I upgrade and I don't care. Not in devices case, it's pluggable. It was, it was pretty good software still is probably, but you know what I'm saying? Like a piece a piece of software it depends he can start off like completely fitting you and then a few years later it's like this thing's heading in a direction that i don't like and then it's time to jump ship or find an alternative or start writing it yourself there's there's a lot to think about with these things i think it goes back to your earlier point about the cycle of bundling and unbundling

as these libraries just grow to accomplish all use cases. As your API needs are much smaller, maybe it makes sense to break out and enroll your own to actually reduce that API surface. And it ends up being actually a more stable and maintainable piece of code. So we had a show on JS Party with Ahmad Nasri, who was NPM's CTO for a while. He also started Kong, or he was involved in Kong. Been around the block, has seen a lot of things. And he takes a very hardline stance that you should only write code that only you can write,

or you and your team. Only write the code that makes you unique and different, and you have the special skill set. Everything else you shouldn't be writing. Him and I actually go back and forth on that, so maybe we'll link up to it because it's an interesting conversation. But I thought, wow, here's like a real context independent, right?

I agree with you. I think context does matter. But he's saying like, nah, pretty much if it's not unique to you, you're wasting your time and your cycles. You should be outsourcing that and you should only write the code that makes you, your company, your org, whatever unique and different or add something to the world versus reinventing i think in small teams that makes sense for sure and even if you're in a big org you still be in a small team true you know so you're always sort of like resource aware right so if you're resource

aware you shouldn't waste time so wasting time would be writing code you shouldn't write and being efficient would be writing code that you should write only you should write so I think it kind of depends still yet but even in a big org you could be a small team there's also business decisions that go into a lot of these things beyond merely the engineering decision making like Mac you were talking about

a lot of these large companies have rolled their own databases internally and they weren't the only ones that needed that but they had specific business reasons to do it or they had specific needs or they didn't want to i mean the context goes on and on and on for these decisions yeah yeah definitely i think size matters well while we're talking dependencies cyclomatic complexity let's squeeze this one in huh because this is like right on topic isn't it yeah yeah yeah it sure is we don't want to change subject number 20 avoid cyclomatic complexity novice coders don't even know that they've tangled the dependency graph until it's too late ouch maybe a little harsh i only say because i was there i'm i'm still there in a lot of regards

oh yeah well we've all been in the tangled mess before like right this is the dependency hell side right like how did i get here i can't get out can you quickly define cyclomatic complexity for those who are unaware of the term or the understanding yeah so it's it's basically just like a an actual quantitative measure of how many, I guess, independent paths exist in your source code. So think of like control structures. So like if-else statements, how many nested if-else statements are there? How many nested for loops are there?

It's something that a lot of static code analyzer tools can tell you. It's not always maybe apples to apples in terms of, oh, this project has a super high cyclomatic complexity and that means it's a bad project. I think you really need to look at it at a relative term, but it's something good to track with your project. And I know there's a bunch of tools for Go that do this. Just to know if you're introducing

some kind of really gnarly control flow in terms of super nested if statements, super nested for loops, etc. Because the cyclomatic complexity, while it you know, it is a kind of a relatively good or bad, it does correspond to the number of test cases you do, you need to cover your code, if you think about it that way. What's up, friends? I'm here with a new friend of ours over at Assembly AI, founder and CEO Dylan Fox. Dylan, tell me about Universal One. This is the newest, most powerful speech AI model to date.

You released this recently. Tell me more. So Universal One is our flagship industry leading model for speech to text and various other speech understanding tasks. So it's about a year long effort that really is the culmination of like the years that we've spent building infrastructure and tooling at assembly to even train large scale speech AI models. It was trained on about 12 and a half million hours of voice data,

multilingual, super wide range of domains and sources of audio data. So it's super robust model. We're seeing developers use it for extremely high accuracy, low cost, super fast speech to text and speech understanding tasks within their products, within automations, within workflows that they're building at their companies

or within their products. Very cool. So Dylan, one thing I love is this playground you have. You can go there, assemblyai.com slash playground, and you can just play around with all the things that is assembly. Is this the recommended path? Is this the try before you buy experience?

What can people do? Yeah. So our playground is a GUI experience over the API that's free. You can just go to it on our website, assemblyai.com slash playground. You drop in an audio file, you can talk to the playground. And it's a way to, in a no-code environment, interact with our models, interact with our API to see what our models and what our API can do without having to write any code. Then once you see what the models can do and you're ready to start building with the API, you can quickly transition to the API docs, start writing code, start integrating our SDKs into your code to start leveraging our models and all our tech via our SDKs instead. Okay.

Constantly updated speech AI models at your fingertips. Well, at your API fingertips, that is. A good next step is to go to their playground. You can test out their models for free right there in the browser, or you can get started with a $50 credit at assemblyai.com slash practical AI. Again, that's assemblyai.com slash practical AI. And also by our friends over at Wix, I've got just 30 seconds to tell you about Wix Studio, the web platform for freelancers, agencies, and enterprises. So here are a few things you can do in 30 seconds or less on studio.

Number one, integrate, extend and write custom scripts in a VS code based IDE to leverage zero setup, dev test and production environments. Three ship faster with an AI code assistant and four work with Wix headless APIs on any tech stack. Wix Studio is for devs who build websites, sell apps, go headless, or manage clients. Well, my time is up, but the list keeps going on. Step into Wix Studio and see for yourself.

Go to wix.com slash studio. Once again, wix.com slash studio. So Matt, number 15, which says most code out there is terrible, was a corollary to number 14, which said use other people's code religiously. I think a corollary, if I know what a corollary is, maybe I don't. Two, most code out there is terrible. Is number three, delete as much code as you can. Does that sound right? It pains you to delete the code that you put so much hard work into writing. I mean, the best code is no code to quote Kelsey Hightower

and his no code repo, which contains absolutely no code, but also no bugs. Yes, that's true. That's right. Bug free and zero dependencies, right? Zero dependencies, easy to deploy, free to deploy. That's right. It's something that's really hard to do, but it's really satisfying when you do it. One kind of example that comes to mind is in the early days of Minikube, we were actually vendoring the entire

Kubernetes distribution into the Minikube binary. That meant the kubelet was in there, all the different components were in there. And maintaining that was a complete nightmare, just in terms of we weren't depending on external APIs, we were depending on actual internal APIs that had no sort of guarantee whatsoever. And so once we were able to move internal APIs that had no sort of guarantee whatsoever. And so once we were able to move over to a different solution, I mean, I probably deleted maybe like 4 million lines of code in one PR. Wow. It was great because our unit test coverage went way up. The tool became much more reliable.

And, you know, we didn't have to spend nearly as much time maintaining all these different patches and different pieces of code. The difference there might be that you didn't write that code, right? You wrote the code to maintain, but you didn't write the formula and lots of code. That's true, but I think even deleting a package dependency, in my mind, still counts as deleting a ton of code. I think if you can delete...

Well, I don't mean to downplay what you did. What I mean is the emotional tie to the code. I think if you can delete... Well, I don't mean to downplay what you did. What I mean is the emotional tie to the code. Exactly. Yeah, it's much easier to delete someone else's code than to delete your own code. Right. But I think, yeah, deleting your own code is definitely much more important. I have never identified

closely with my code. I think a lot of people do, and I do understand why you would, because like you said, you put your, that's your thoughts in software, right? It's your time. It's your effort. I understand it,

but I do not and have not identified closely with my code. In other words, I've always loved to delete my own code. I've never been like, aw shucks, I'm really going to miss you, 40 line function, you know?

I've just been like, good, I don't need to do this anymore because it's always felt like a liability to me it's never felt like something precious to hold on to like other things do i don't know about you matt have you ever felt like some code's been hard to get rid of maybe there's like a there could be sentimental value around something that brought about yeah i don't know i get it like if the whole project disappeared sure you know but like that function why do people identify with these things you think? Yeah, I found it very, very difficult to delete code, especially when the

code's been there a while. It's been battle tested. It represents a lot of toil. You know, maybe it's not that 40 line function. Maybe it's that, you know, 10 line function that you thought was really clever. And, you know, it spent hours figuring out the algorithm too, just to, to figure out that, you know, maybe it should be replaced with something else or something much simpler. Maybe it should be replaced with the 40 line function. Maybe it should. Maybe you should have copy and pasted something off Stack Overflow. Exactly.

Exactly. So that's tough, but it's, it's just so necessary. I wonder if it speaks to confidence in yourself to go psychological. Like to feel like you shouldn't or can't delete it is having less confidence in yourself that you could rewrite it better. You know what I mean? Like you want to hold on to it because maybe you're less confident that you. And so maybe, Jared, to your point, and maybe a hat tip to you might be that you're highly confident in your abilities to rewrite the code better. Maybe I'm overconfident. Overly confident, high confidence, say it how you'd like.

But it leads maybe to a lack of or a high degree of confidence, potentially. Maybe. There's probably lots of factors that lead into this. I will say that version control helps me to leak code much more confidently. Because I feel like if it would be difficult to go back to here ever yeah maybe i would be like more reticent to say you know what i may need this someday i'm going to hold on to it i see a lot of people novices mostly just like comment out huge swaths but leave them right there like this function's just uncommented out but why is

it still in the source code because they don't trust their git foo or something it's like you can get back to that. You know, like that's what version control is for. Go look at a previous version. Finding it might be challenging though. I suppose if you can code search even history, you could. It could be. I think it's like, I might toggle this back on with my next commit kind of a thing.

There's lots of reasons why it happens, but I find that a lot. I've never been a commenter out or I'm just like, delete that crap. Get it out of here. Yeah. It's noise. As somebody who is somewhat of a digital pack rat, I can empathize with the person who has a challenge in deleting it. Not because I find it useful or that I'm emotionally tied to it,

but what if I wanted to reference it? What if this could be useful someday? Right. But I also say I like to delete code. It's nice because there's some value in that too, because you can sort of see a better future. And I also say I like to delete code. It's nice. Because there's some value in that too because you can sort of see a better future. And I think it kind of depends really. It depends on how emotionally connected you are to it, what your confidence might be of it.

If it truly, you know, if you do believe in Git, which is totally true. Like if it's in Git. It's in there. Or even anything else. Fossil, for example. There you go. The new and upcoming Git. Yeah, go agnostic. Maybe it's in mercurial who knows maybe well then you've got it in your history so it's not gone

forever that's right but if most code is crap then you know deleting it sounds like a pretty good idea i don't know i'm with you delete as much code as you can but no more don't delete more code than you can that would would be a bad idea. Yes. All right, back to code that we write, not that we delete. Number 18, organizing your code into modules, packages, and functions is important. You mean not just one big function called main? Knowing where API boundaries will materialize is an art. That kind of goes into the dry thing, doesn't it? Yeah.

And something that I think about a lot with the monorepo versus microservices debate, not to even get into that, but just it's really hard to know where these API boundaries are going to exist, especially early on when you're first coding your app. And I think as programmers, again, I think we want to split everything up. Every kind of the user service has its own file, the other service has its own file. But I think a lot of times we maybe prematurely code split, and that causes a lot of issues just on the line in terms of versioning things and releasing things that actually need to be versioned together. And I think if you find yourself in that situation, maybe kind of roll it back up in some regard. Maybe it's not microservices versus monorepos,

but maybe it's just something as putting things in the same package or putting things in the same file. Yeah, you would think this would be small concerns, but they end up becoming large concerns in software architecture, right? It's like where the files go, how I name things, where to put things, especially when you start working on teams, then there's disagreements over how this works. You're introducing logistics into your software by having these distinctions prematurely and having to make sure everything's in the right place, name the correct way, etc.

Start simple and then only i think abstract when it's uh necessary and beneficial that is an art though and it does take time to learn and even you know somebody who's done it for i think you and i are in very similar boats i've definitely been writing software for 15 years i still screw that up i still make the wrong call and then maybe it's hours later maybe it's days or weeks i'm like that was the wrong call. And then maybe it's hours later, maybe it's days or weeks. I'm like, that was the wrong call. I'm going to go ahead and roll that back. I'm going to go back to where I started and go ahead and just try it the other way and see if it works any better. What are the downsides? Let's say over-organizing. Is there an over to that potentially? So you want to organize it and it's an art to do so, but what about over-organizing? Can it be

fatiguing, so to speak? And the reason why I ask this is I often see this on the front end mainly, where I play most, in SaaS. I know that when SaaS came about, you can always add import CSS files, for example, on the front end. But it was less common because it really, in the end, just created one big CSS file on the front end itself when you moved along. But in SaaS, I noticed that a lot of people would compartmentalize little components, and it would be like a five-line

rule set for CSS in there, and it's like, well, that could have been in the regular file. You just find yourself idising yourself to the point where you're in so many different files that it's like, is this really helpful? What's the downside to over-organizing? Hard to find things. different files it's like is this really helpful yeah what's the downside to like over organizing hard to find things yeah i think cyclic dependencies as well i think it could put you in in let's say like a go package or something like that if you over code split but you're actually not respecting the underlying dependencies of how the the code is actually flowing then you can get yourself in a in kind of a bad spot where know, package A depends on package B or maybe a diamond dependency problem where

package A depends on B and C, but then B and C also depend on D. And I mean, you just get yourself into all sorts of package hell depending on what level you're working at. So I think it has, has kind of real, real ramifications for over splitting or over uh yeah the other thing is you end up rearranging a lot of furniture for no real benefit right at the end of the day you're supposed to be pushing your project forward anytime you're just rearranging furniture which is like i'm going to put things over here wait a second that has to actually go here nah i liked it better when it was the other way and you're just these are all things that they're nice for procrastinate coding which is something I'm very good at,

but they're not great for actually getting anything done. Anytime you're spent dealing with this other cruft, you're not making progress. Where we like to be is flow, right? We like to be where we're just solving problems, making progress. No one's in the flow as they're renaming files and switching from camel case to snake case

or in a cyclical dependency hell i mean that's like the worst place to be right i can't even get these things to stinking require each other import each other but it starts off being beneficial because now you're just following a convention you have a convention you're following it starts off beneficial and then over time it can you can overdo it you can overdo it speaking of things that are hard naming variables you say naming variables correctly this is your point this is like three words oh sorry it says name them correctly well that's helpful matt name them correctly lesson learned but then you admit again this is an art name your variables correctly Any tangible advice for us on this point? Yeah. Unfortunately, that's why I called it reflections on programming,

not maybe lessons. Okay. We're trying to draw some lessons, but we'll just have to reflect with you. Yeah. I mean, I think the only lesson is that definitely, at least personally, I have a bias for naming variables as short as possible. And that is probably one of the most unhelpful things you can do to your teammates and, and to your feature self. So you'll abbreviate things and like really condense them down. Exactly. Like single letter, sometimes two or three letters. And honestly, that's, that's not super helpful. At least I found you're saving a few spaces, but you're not really, it's like the, the old adage is like, uh, uh, debug for six hours. And, you know, I could, uh, I saved myself, you know,

10 minutes of reading the man page or something like that. Right. Yeah. We were debating the pros and cons of abbreviating variables on a go time episode that I happened to be upon. And I learned something there, or maybe it was just coagulated there from Dave Chaney, where he said something along the lines of the further away the variable is from being used, the longer its name should be. But like the closer it is to being used, the name can be shorter and shorter,

like to the immediate context. So like a for loop is an obvious one where it's like, yeah, I is fine. Cause like, here's I, it equals this. I'm going to, I'm going to iterate it, increment it, whatever. And then I'm done with it. where it's like yeah i is fine because like here's i it equals this i'm

gonna i'm gonna iterate it increment it whatever and then i'm done with it and it's like we all understand that it's i it's not actually confusing but like if you start naming your variables that are used further down or elsewhere maybe they're exposed somehow i or z or foobar or baz these are like they don't signal anything to somebody who doesn't have your immediate context. I thought that was a pretty good way of thinking about it because I've always gone for this balance of clarity and brevity, but it's always been a hard balance to strike. Would it be more helpful if it was, instead of I, if it was iterate or increment? That's where you can really drive that point home because if you can

say, what would the extended version of i be? Iterator. And would it be more useful? Yeah, I think in the case of a for loop, I think i is just totally fine. That's my take on it. Of course it is. But I mean, let's do the exact opposite as a fun case. Let's expand it to its full word.

Would it be iterate or increment or what would it be? Yeah, I think it's an iterator. Like that variable is one that you're using to iterate. So I'd call it iterator, something like that. So would it be more helpful or I would think it's an iterator. Like that variable is one that you're using to iterate. So I'd call it iterator, something like that. So would it be more helpful or less helpful if it was for iterator? You know, if the variable was iterate instead of I. It's too much typing, man.

Too much typing. Too much typing, right? So the answer is no, not more helpful. This is why Matt likes to make them as small as possible because it's just annoying. Right. Like it's just a balance of like, this annoys me even with tab completion

versus this has a useful symbol. I don't understand in Go, so if error, not equal null. ERR. What's up with that? You're saving literally two letters. Error versus er. But it's a convention of the community, so everybody knows what it is. I don't think it's ambiguous when you see if ERR.

I understand that's the error. But the abbreviation there to me is like, what am I gaining? I'm saving two letters. I understand when you take internationalization and you say I18N, that's a huge win for all of us, right? But ERR as an abbreviation for ERROR, it just seems a little bit silly. That being said, we all do it. We're all on board. It's clear. It's not a problem. I just don't understand the win.

I don't know if that's short for error, though, is it? Yeah, it is. Well, isn't er an actual word itself, though? E-R-R? It's a word. So is it a shortened version of error, or is it just a shortened version of the word? Well, I'm sure, and I don't know, Matt, you're more of a gopher than I am, but I think in the Go community, when they use ERR,

it's representing an error, isn't it? Yeah, yeah. I mean, maybe there's a little confusion because error is the interface that it implements. So, you know, maybe there's a little ambiguity there, even though it is case sensitive, I think. But yeah, I totally agree. I think when there's convention and you use convention, you know, stick to that.

Yeah, I agree. If you were to say E instead of ERR, maybe that's a little wrong, you know, because you're not sticking to convention and you're shortening it a little bit too much. Yeah. Right. I agree. Whatever are the idioms of the language or the runtime or whatever it is, the community that you're working in, follow those conventions

because that's where clarity is just for free. Like you get it for free. And even if your idea is more clear to you, you're breaking convention. And so it's less clear, almost de facto to everybody else. But in the case where there is no convention, I think Dave Chaney's rule of like the further away a thing is from being used,

the more verbose or more information has to be in the variable name. I think that's a pretty cool rule of thumb. Obviously rules are meant to be broken. So there are times where it may not make sense, but I thought that was a, an actual tangible way of a takeaway. Because when I say, I like to say,

Hey, this variable name is terrible too, but like lacking any other information, like, well, that's not useful. How, how could it be better? Like, well like well yeah it's 27 characters long so let's yeah so that's not good

the such thing is too long i think the point he's making there is like if you're going to see it frequently make it brief right because like you're going to see it more often the quicker you get something done that you're familiar with we or going to happen frequently, probably the better. So the more often you read ERR versus error, as an example. If you read that 50 times a day versus once a week, maybe, do it briefly. Yeah. If you can't think of a good variable name, this is where a code comment comes into place.

Apologize. Be like, this is not the greatest name ever, but I needed to finish this feature. So this is what I got. Please think of a better name. Yeah. Open to consideration. Feedback. Welcome. If you're confused by this variable name, you're just like me. I'm also confused. Those are the kind of comments I enjoy. Hey, cause you get a chuckle even when you come back to it later. You're like, oh yeah, I couldn't think of a name for this thing. Then you sit there and you're like, Hmm, I still can't think of a good one.

But sometimes it just comes to you. All right, let's hit another one here. This one's a little bit bigger picture. Technology does not diffuse equally. There's more to your reflection than just that, but I want to stop there and have you talk first. So go ahead and unpack that phrase for us. Why do you think that's the case?

Yeah, I think of it as almost like kind of continuous learning. And we can learn so much from these different kind of sub communities, especially as what it means to be a software developer means just so much. Now, you could be a front end developer, you could be a back end developer, you could be a data analyst, data engineer. I mean, there's just so much that goes into actually writing code. I think like tangible examples are backend engineers can learn a lot about UI and UX from frontend engineers, especially what it means to make a user-friendly CLI or user-friendly error messages.

I think sometimes backend engineers over index on complexity and maybe not thinking of the user and in a lot of cases, it's another developer. It's one of those things where there's just so much we can learn by looking at these different sub communities. So it's something that I try to keep an open mind to. That one absolutely resonates with me. One example I cite often, which I'm still impressed by is Dan Abermaw's stealing of the Elm architecture for Redux. And he came on the show back when Redux first started getting wide use in the React community. And he basically said, yeah, I saw what the Elm folks were doing over there. And it was awesome, their architecture for state.

And I decided React needed that. And so I built Redux. redux and you know shamelessly great artist steel and he gave great i mean credit to the elm folks for coming up with a cool system that dan learned about and appreciated and said i'm gonna bring that over here and everybody benefits but i think when those things propagate across community bounds for sure so individual takeaways there i guess is kind of like keep your head up and and know what other I think when those things propagate across community bounds, for sure. So individual takeaways there, I guess, is kind of like keep your head up and know what other people are working on or don't niche down or don't go so focused in on a singular aspect of any specific part of the tech world. Is that the advice then?

Seems like it is. Yeah, I think your example from Dan is amazing. I think it's just like ideas like that that can kind of pop up in a lot of different places. And you can look at it and say, oh, my God, this would be amazing for the project or the part of the stack that I'm working on. And, you know, I just think there's so much cross-pollination that can still happen. And it's just such low-hanging fruit in terms of how we can push all this technology forward. Yeah. We often think in camps, we often think, oh, JavaScript or Go.

And this is an example we often run across with Go time and JS Party, like which one's better? Always a competition. JS Party. Sorry. But to be able to look beyond the lines of the camps and say, what ideas have you implemented that would translate to our ecosystem and make sense for us to look at? I think it's something that's been a hallmark for this show really since its inception.

We began as the changelog. We began not choosing the Ruby camp despite our Ruby roots in many ways. We didn't choose a specific camp and say this is the Ruby changelog. We said this is the changelog because open source was moving fast. It was difficult to keep up, and this show and the blog that came from it was an example of how to pay attention agnostically across the board and to cross-pollinate those ideas. I think this is like core DNA for us and phenomenal advice from you. Here's another awesome example. This happened just recently.

I love seeing it because it means we're having a little bit of impact out there. So there is this idea with to-do comments, which talk about commenting and best practices, is that you always leave these to-dos lying around our code bases and then nothing else happens like that's where they are and usually these things never get done and a lot of times it's because you forget about it or it depends on something else changing well there was a cool idea coming out of i think the rust community and there's also a ruby gem for this where they started having these self-destructing to-dos have you guys heard of these so it's like you write your to-do it's like a static analyzer kind of a thing you write your to-dos in the specific

syntax where you can apply criteria to your to-do whether it's like based on a certain time frame or based on a url that has to whatever i can't remember all the different things but you can add these conditions to these to-dos and And then the tooling provides integrations, I believe, into editors and different linters and stuff to float those to-dos. It's kind of like with Gmail, where you can push things off until later, and then they come back. And that was a really cool idea.

Well, then somebody got inspired by that, and they made one for Python. So that person's name is clemon siever and he wrote to do or die they're called to do or die and they're uh to do or die python edition so we covered that one we covered the rust one and then the python one cropped up and then somebody else was inspired by that brian underwood and he wrote one for the elixir community in credo called credo to do or deny and credo is like a a linting tool or a best practice following kind of analyzer tool for elixir and so now this concept which was over there in the rust world of hey what if our to

do's had these you know were better than what they are already are that idea is picked up and kind of propagated around and like way more people get to benefit because these people were paying attention to other camps and willing to put the work in to like provide that for their language of choice. It's pretty sweet. That's awesome.

Yeah. Well, Matt, we've come to the end of our time here. This has been awesome. I appreciate you writing down what you did so that we all can learn from your reflections. We can discuss and pick them apart and agree or disagree. Certainly propagating good ideas and your hard-earned experience out there

for other people to learn from. I think that's really cool and appreciate you writing up. Looks like you're blogging quite a bit lately. We'll have links to your blog, this article, everything else we mentioned that jazz party episode as well in the show notes for everybody.

The one I referenced with Akhmed Nasri, if you want to listen to that discussion as well. Anything else you want to say, Matt, before we call it a show? I mean, thanks for having me. I had such a blast and I've been such a long time listener.

So it's, it's fun to be on the podcast. It's good to have you, man. Yeah, it was lots of fun. Appreciate it. Well, that was fun. We went back in the past. We learned about some cool reflections of 10,000 hours of programming, not career advice, although that is good, and not soft skills, but actual coding, what it takes to become a master software developer. So, which reflection was your favorite? As we mentioned in the intro and during the show, be the first person to comment on this thread in Zulip the correct number of reflections mentioned in this episode. And you've got yourself a free t-shirt from our merch store and if you've never been there go to merch.changelog.com now you know okay so we took the

week off we brought you a blast from the past well we had a scheduling issue last week and so we just didn't record an episode sometimes that happens and in this case, thanks to Matt, we brought you a gem, a banger of a show, Reflections on 10,000 Hours of Programming. This is the podcast that just keeps on giving. I hope you enjoyed it. Okay, so a massive thank you to our friends over at Fly, our friends over at Socket, our friends over at Assembly AI, and of course to our friends over at Wix for the awesome work they're doing on Wix Studio. We have awesome sponsors. I hope you love them and anything you do with them in reflection of this podcast supports us and we appreciate that. Big thank you to Breakmaster Cylinder for those awesome beats. Banging beats. Love those beats. Okay, that's it.

This show's done. We'll see you on Friday. Game on.