The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Thu, 17 Oct 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...
Thank you.
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 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 100% 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 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 Headster. 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 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 have to go talk to a platform team once my Sandwich app becomes a huge startup and IPOs and I have to 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 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 just no path to that on top of the clouds. So in general, like I feel like, and 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.com. 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 WireGuard 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 there are mistakes. Don't repeat your mistakes. Dry them, as they say. Oh, yeah. 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 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 did 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 sub projects in Kubernetes. So 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, 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.
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 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, get a free T. 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. 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. 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's going to 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 going to let you explain that to me because I've never heard of this before.
Yeah, I mean, you've probably never heard of it because I, you know, I try to come up with it myself. I try to coin the term. So, 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 hard-coded values or bash. So you go from like hard-coded 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. You turn it into a configuration file, maybe YAML, JSON, something like that.
Then as you turn on this heptagon of configuration, and I only called it heptagon just because a lot of the ideas came from Kubernetes and Kubernetes logo has got the seven points and just worked out well. But as you're going from 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. 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 that 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. Cause you sort of learn something about it.
You provide configuration to the user base so that they can use it more different, you know, in a more flexible manner.
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 and 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 process or an unbundling process. And 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 and 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, et cetera. 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 Prog fellas 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 Prague Prague 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 clarifying that. But you have a point here, one of your reflections here.
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 you know the requirements are are never finalized and you know just the wrong abstraction at a low level can really cause a lot of issues in terms of refactoring and 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 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 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 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. 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.
Every piece of knowledge in your system should live in one place and one place only. But because the acronym was DRY, and it's such a catchy thing, and it's easy to remember to repeat yourself, as soon as you start repeating something, you just immediately apply it, right? But that's not the point. It's not about the code that you write. Now, some code 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. 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, 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, 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, you know, 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 Gopher's 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 CodePen. 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, a 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. Cause 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'd you learn this? And why do you believe this?
Yeah, I think a doc string 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.
Mm-hmm.
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? Are you commenting every function? How to get to the point where you need to explain every single thing? 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 you know 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 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. And sometimes you just have to move on and come back and it'll come to you. But yeah, I think the what and the whys. Those should be inline comments, not the hows. 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 as the how, usually more than the why. But this ties into another one that you say, which is if it looks ugly, it's most likely a terrible mistake. Yeah.
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 Bukhdiye, founder and CEO of Socket.dev. So Faraz, you put out this fire post recently on X. And I'm going to 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 XZutils 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 us 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 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, 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 Linux distros 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. One, obviously, wow, there's literally states out there, countries that are trying to target open source now. Clearly, there's 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 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 dot dev.
And by our friends over at Superbase, 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 suit base is build no weekend scale to billions what's your vantage point on this as cto of super base
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. 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 Superbase. That will change in the future as well. Now you have to write your schemas. You shouldn't have to do that in the future again. Just focus on the cool thing that you want to build.
Well, Superbase 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 all. 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.com.
So anytime you reflect on 10,000 hours of programming, surely Stack Overflow comes into those reflections. And turns out it did because one of 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 post 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 in 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 look at the code, right? Code can't lie.
That's true. Maybe that's the loophole. Definitely got to check the date on the stacker. 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 on 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 online. 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. 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 FFmpeg with these flags from my app? I just say that because we call FFmpeg 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? No. 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. And I end up on Stack Overflow a lot. And I never look at FFmpeg 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 problem? 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. Just because you're not accessing an API on HTTP. You're not accessing an RPC. You're actually taking a dependency on some code.
And sure, there might be a documented way that these functions are public and 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 uh to 30 seconds uh you know that makes sense right right you're not going to look at the you might not even look at the man pages for uh for fm that mpeg on that no i'll just google that immediately and end up on stack overflow yeah
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 had 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 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 stake. 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, 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 is open source.
Yeah.
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 workarounds. And when someone else builds on that foundation in a similar way, you know, I think that doesn't work out too well. So even though there's a lot of terrible code and Kubernetes, and you know, I wrote a lot of 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?
Yeah.
You want to be good?
You got to get lucky. Well, I think, you know, in the case of say the ghost in your 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 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's what are other people using? What are other people using as dependencies? And all that work will shake out who's great. I almost stopped you at TikTok, but I'll let you keep going. All right. I know. So 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. And so that's how you find the best. All right. I take it back.
Do not work in a Silicon Valley. One right here. It was a good effort though. Well, we're talking about other people's code, reading their code, learning from them. Number 14. I'll give you guys this one listener. Number 14. This definitely counts as a lesson. Use other people's code religiously.
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 they 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 getting into to some degree. A lot of the other rules are around 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.
I have a half written blog post 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 device 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. 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 they need a dependency on, let's say, like LeftPad or something like that.
But if you're, you know, if you're writing more kind of higher level application code, you know, I think you got to ask yourself, what goal, what are you trying to achieve here? You know, 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, Devize is a good example from maybe five, 10 years ago now where all of the authentication things, like instead of rolling your own, you use Devize and then you worked on Devize with the Devize 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 auth. And now you're just adding lines of code to my project when I upgrade, and I don't care. Not in Devise's case. It's pluggable. It was pretty good software. Still is, probably. But you know what I'm saying? Like 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 a lot to think about these things. Mm hmm.
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 hard line 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. I agree with you. I think context doesn't 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. 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 can still be in a small team. So you're always sort of like resource aware. 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, you know, even in a big org, you could be a small team.
True. There's also business decisions that go into a lot of these things beyond like 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, 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 it because I was there. I'm still there in a lot of regards.
Oh, yeah. Well, we've all been in the tangled mess before. Like, 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 basically just like 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, et cetera, because the cyclomatic complexity, while it is a kind of a relatively good or bad, it does correspond to the number of test cases 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, And 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. Two, 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, to 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 so 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 of 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 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 in 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, you know, even, you know, deleting a package dependency in my mind still counts as deleting a ton of code. I think 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 on in software, right? It's your, 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 value. 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, 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. Yeah.
just 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 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 like. But like it leads maybe to a lack of or a high degree of confidence potentially. Maybe. Yeah.
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, maybe I would be 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 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-outer. 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 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 it is.
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 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 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 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 down 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. 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 SAS.
I know that when SAS 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 it along. But in SAS, 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. And you just find yourself itising yourself to the point where you're in so many different files that 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 code is actually flowing.
then you can get yourself in kind of a bad spot where 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 kind of real ramifications for oversplitting or
The other thing is you end up rearranging a lot of furniture for no real benefit. 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.
These are all things that are nice for procrastinating, which is something I'm very good at, but they're not great for actually getting anything done. Anytime you're 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 like 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.
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 like 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, debugged for six hours and, you know, I could have 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. Because, like, here's I, it equals this. I'm going to 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 like drive that point home. Cause if you can say, what would the extended version of IB iterator and would it be more useful?
Yeah, I think in the case of like a for loop, I think I is just totally fine. That's my take on it. Like I would use it.
Of course it is. But I mean, like, let's do the exact opposite as a fun case. Let's expand it to like 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. And 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. Like, I don't understand in Go, so if error, not equal null, or if, you know, 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 F-E-R-R. 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 I-18-N. That's a huge win for all of us, right? Yeah.
But ERR, as an abbreviation for E-R-R-O-R, 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 ERR an actual word itself, though? E-R-R?
Yeah.
It's its own 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 when in the go community, when they use ERR, it's representing an error, isn't it?
Yeah. Yeah. I mean, maybe there's a, there's a little confusion because, uh, 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 Cheney'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 of their information. Like, well, that's not useful. How could it be better? Like, well, it's 27 characters long. 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're 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. Because 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, you know, 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 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. 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 Abramov'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. And shamelessly, great artist Steel. And he gave great credit to the Elm folks for coming up with a cool system that Dan learned about and appreciated and said, I'm going to bring that over here.
and everybody benefits 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 people are working on or don't don't niche down or don't go so focused in on a singular aspect of any specific part of the tech world or 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.
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 is 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 know, you always leave these to do's 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 a specific syntax where you can apply criteria to your to-do, whether it's 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 then the tooling provides integrations, I believe, into editors and different linters and stuff to like bring, float those to-dos. It's kind of like with Gmail where you can like push things off till 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 Seaver and he wrote To Do or Die. They're called To Do or Die. And they're 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 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-dos had these, you know, were better than what they 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 Ahmad Nasri, if you want to listen to that discussion as well. Anything else you want to say, Matt, before we call the show?
I mean, thanks for having me. I had such a blast and I've been such a longtime listener. So it's fun to be on the podcast.
It's good to have you, Matt.
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 Break Master Cylinder for those awesome beats. Banging beats. Love those beats. Okay, that's it. The show's done. We'll see you on Friday.