Lessons from 10k hours of programming (remastered) (Interview)

30:53And 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 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.

31:44Okay, 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 weekend, 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.

32:21You 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.

32:56I 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. 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, 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.

33:41It's got it all and no servers managed by you. Just build your app, build on 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.

34:17So 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.

34:54the 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?

35:30Still 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.

36:08So 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 Docker 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 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.

36:46But 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 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 feature problem?

37:28Or 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.

38:05But 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 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 because I was Matt you're a day too late man they lay in a dollar short so I'm I'm having Matt Billman and Christian Bach from Netlify on Founders Talk soon.

38:43And 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.

39:24That's a great example. Rather than the documentation be obsolete or non-existent for my use case, I can actually read the docs on how assets cause an image, for example, and what happens as a result. so 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 at 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.

40:05I'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?

40:46And 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're learning Go, you're 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.

41:30But 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, 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 in Kubernetes, and I wrote a lot of it, there's a lot of great examples of what an API should look like, API versioning, API machinery.

42:10And 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.

42:45Not 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? 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. 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.

43:20So I think that's a good example there. I think otherwise, you just got to follow your peers. Pay attention to the change. This podcast, for example, that's how you find greats. You pay attention to the media and the content happening in the space. 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. It's for sure the package registries, 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. We'll let you keep going.

43:51All 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 can 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?

44:21In 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.

44:56It 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 anacorollary is most code is terrible sometimes it's easier to write a better version yourself so well 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 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.

45:34You 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, maybe you could, you could write something as good. You haven't really tried, but is that kind of 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, you know, not tangling your dependency tree, not taking dependencies on super tiny libraries.

46:10But 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.

46:49And 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. I've implemented it myself a few times, not the entire devise 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.

47:21But 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 LeftPad or something like that.

48:02But 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 code to potentially even choose from, even if you could.

48:47And 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, And Devise 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 Devise and then you worked on Devise with the Devise people and everybody's making that one thing better.

49:30And 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. But 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 like 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.

50:01It was pretty good software. Still is probably. But you know what I'm saying? A piece of software dependency 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 to accomplish all use cases right as your api needs are you know much smaller maybe it makes sense to to break out and enroll your own to actually reduce that API surface.

50:37And 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, like 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 episode. Maybe we'll link up to it because it's an interesting conversation.

51:10But I thought, wow, here's like a real context independent, right? 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 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. True. You know, so you're always sort of like resource aware, right?

51:40So 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.

52:14I 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?

52:51Like, 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 all statements, how many nested if all 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.

53:30I 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 hours over at Assembly AI. Founder and CEO, Dylan Fox.

54:25Dylan, 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.5 million hours of voice data, multilingual, super wide range of domains and sources of audio data. So it's a super robust model.

55:02We'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 with 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.

55:42You can drop in an audio file. You can talk to the play around. 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.

56:16A 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 practicalai. Again, that's assemblyai.com slash practicalai. 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.

56:59Three, 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.

57:32so 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. That's right. Bug free. And zero dependencies, right? Zero dependencies, easy to deploy, free to deploy.

58:15It'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 over to a different solution, I mean, I probably deleted maybe like 4 million lines of code in one PR.

58:53It 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 of 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 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 if you can delete. Yeah. Well, I don't mean to downplay what you did. What I mean is, is the emotional tie to the code.

59:27Exactly. 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 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 gonna 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.

1:00:07It'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 just to to figure out that you know maybe it should be replaced with uh something else or something much simpler maybe it should be replaced with the 40 line function maybe it should maybe you should have copied and pasted something off that overflow exactly exactly so that's tough but it's just so necessary.

1:01:03I 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 onto 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 all you'd like. But like it leads maybe to a lack of or a high degree of confidence potentially. Maybe.

1:01:36Probably lots of factors that lead into this. I will say that version control helps me to leak code, you know, much more confidently. Because I feel like if I could, 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, namuses mostly, just like comment out huge swaths, but leave them right there. like this function is just uncommented out but why is it still in the source code because they don't trust their gitfu 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 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.

1:02:33Not 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? 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.

1:03:05Maybe 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 be a bad idea yes all right back to code that we write not that we delete number 18 organizing your code in the 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 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.

1:03:58And I think as programmers, again, I think we want to split everything up. Every kind of, oh, 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. You know, 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.

1:04:37Yeah, you would think those 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 or like 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.

1:05:14I'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 in the, on the front end, mainly where I play most in SAS.

1:05:49I know that when SAS came about, it was, 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, when you moved it along. But in SAS, I noticed that a lot of people would like compartmentalize like 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 like the regular file. You just find yourself like itising yourself to the point where you're like in so many different files. It's like, is this really helpful?

1:06:22Yeah. 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, 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 hull depending on what level you're working at.

1:06:58So I think it has kind of real ramifications for over-splitting or over, 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, let's not 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 procrastinating, which is something I'm very good at, but they're not great for actually getting anything done.

1:07:28Anytime 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, it starts off beneficial, and then over time you can overdo it.

1:08:02You 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 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 old adage is like, uh, uh, debugged for six hours and, you know, I could, I saved myself, you know, 10 minutes of reading the man page or something like that.

1:09:13Right. 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 the closer it is to being used, the name can be shorter and shorter, like to the immediate context. So a for loop is an obvious one where it's like, yeah, I is fine. Because here's I, it equals this, I'm going to iterate it, increment it, whatever. And then I'm done with it.

1:09:49And it's like, we all understand that. It's I. It's not actually confusing. But if you start naming your variables that are used further down or elsewhere, maybe they're exposed somehow, Now, i or z or foobar or baz, 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?

1:10:26Iterator. 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 would 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.

1:10:53Too 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. 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, 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 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 a 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?

1:11:51Yeah, it is. Well, isn't error 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 in the Go community, when they use E-R-R, 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 maybe there's a little ambiguity there, even though it is case-sensitive. Okay. I think, but yeah, I totally agree. I think when there's convention and you use convention, you know, stick to that.

1:12:27Yeah, 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.

1:13:07I 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, yeah, it's 27 characters long. So let's, yeah. So that's not good. There's such thing as too long. I think the point is making there is like, if you're going to see it frequently, make a brief, right? Cause like, you're going to see it more often, the quicker you get something done that you're familiar with, or going to happen frequently, probably the better.

1:13:47So 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.

1:14:19You'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.

1:14:54Now, you could be a front end developer, you could be a back end developer, you could be a data analyst, a data engineer. I mean, there's just so much that goes into actually writing code. I think like tangible examples are back end engineers can learn a lot about UI and UX from front-end engineers, especially what it means to make a user-friendly CLI or user-friendly error messages. I think sometimes back-end 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.

1:15:34So 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 Abermove'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 you know shamelessly great artists steal 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 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?

1:16:39Or is that the advice then? It 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, you know, we often think, oh, JavaScript or Go. And this is an example we often run across with GoTime and JS Party.

1:17:15Like, you know, which one's better? You know, always a competition and, you know. 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.

1:17:55And 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-dos lying around our code bases and then nothing else happens. Like that's where they are. And usually these things never get done.

1:18:29And 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 do's in a 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 do's and then the tooling provides integrations i believe into editors and different linters and stuff to like bring float those to do's it's kind of like with the 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 clemen 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 to die 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 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 akhmat nasri if you want to listen to that discussion as well anything else you want to say, Matt, before we call the show?

1:21:00I mean, thanks for having me. I had such a blast and I've been such a long-time 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.

1:21:42And 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.

1:22:29We 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.

1:23:01Thank you.