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

Episode Date: October 8, 2021

Today we're talking to Matt Rickard about his blog post, Reflections on 10,000 Hours of Programming. Matt was clear to mention that these reflections are purely about coding, not career advice or other soft skills. These reflections are just about deliberately writing code for 10,000 hours, which also correlates with the number of hours needed to master a skill. If you count the reflections we cover on the show and be the first to comment on this episode, we'll get in touch and send you a coupon code to use for a 100% free t-shirt in the merch store. Good luck...

What's up? Welcome back. This is The Change Log. We feature the hackers, leaders, and the innovators of the software world. Today, we're talking to Matt Rickard about his excellent blog post titled Reflections on 10,000 Hours of Programming. Matt was clear to mention that these reflections are purely about coding, not career advice or other soft skills. These reflections are just about deliberately writing code for 10,000 hours, which also correlates with the number of hours needed to master a skill. Also, in the first part of the show, I mentioned winning a free t-shirt from our merch store. Here is how to win. Be the first person to comment at changelog.fm slash 463. Comment the exact number of reflections we talk about on the show, and we'll get in touch from there. Good luck. Of course, big thanks to our partners, Linode Fastly and LaunchDarkly. We love Linode. They keep it fast and simple.

Get $100 in credit at linode.com slash changelog. Our bandwidth is provided by Fastly. Learn more at fastly.com. And get your feature flags. Powered by LaunchDarkly. Get a demo at launchdarkly.com. This episode is brought to you by our friends at Influx Data and their upcoming Influx Days North America virtual event happening October 26th and 27th. Influx Days is an event focused on the impact of time series data.

Find out why time series databases are the fastest growing database segment, providing real time observability of your solutions. Get practical advice and insight from the engineers and developers behind InfluxDB, the leading time series database. Learn from real-world use cases and deep technology presentations from leading companies worldwide. You'll hear from folks like Tani Ng from WP Engine on how they transform monitoring into an observability platform with InfluxDB and Martin Mucha from Red Hat on how they're using Telegraph and InfluxDB to gain network visibility, just to name a few.

Also, for those who'd like to get hands-on with Flux, our listeners get $50 off the hands-on Flux training when you use the code CHANGELOCK21. Again, this event is happening October 26th and 27th. Learn more and register for free at influxdays.com. Again, influxdays.com 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 it's a lot of time to do anything. So I've had tons of failures along the way, learned a ton of things. And I've been trying to blog more

and write down these ideas so that I don't keep on making the same mistakes over and over again. So it's a lot for me as well. It's the dry principle that I do adhere to. Don't repeat yourself when they're mistakes. Don't repeat your mistakes. Dry them, as they say. What is 10,000 hours? So if we assume eight hours a day, five days a week, let's say eight hours a day times five, right?

Times, call it 50 weeks a year. That's 2,000. So if you're working like a typical nine to five, take a couple of weeks off for vacation, that's 2, 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 watermark. Did you do the math or you just, you just like, yeah, I'm there. No, I did 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 It's like a 6-to-12 or whatever. I mean, it's an all-day thing.

So you're well over. Where did you earn your keep? You've had a couple different jobs. Do you want to tell us about the 10,000 hours you put in, where it was, and what kind of stuff you worked on? Yeah, so I've just been programming a bunch. Programmed a bunch in school. After college, worked in New York for a bit as a programmer. Came out to the West Coast here

to work at Google and worked on open source. I worked on Kubernetes and kind of specifically a bunch of subprojects in Kubernetes. So I was a maintainer of Minikube, kind of the local development environment for Kubernetes. Scaffold, which is kind of a Kubernetes tool to help you build and deploy your apps. And then Kubeflow, which is a machine learning kind of toolkit on top of Kubernetes as well. In addition to that, like I've just been kind of hacking on all sorts of open source projects. I wrote this configuration language Virgo, which is kind of for, you can think of it as like, if YAML was for kind of graph-based configuration instead of more hierarchical.

And then built a computer vision bot for RuneScape which was just a game that I used to play as a kid. A ton and learned a lot about programming through that just because I was always too lazy to mine the rocks or click the buttons all day. And just like tons of projects like that. well you can learn from experience but you can also life hack and learn from other people's experience so i loved this post you had 31 things that you've reflected and it is specific to programming these are not large life lessons or or people lessons

you say these are like specific programming lessons that you've learned. And I thought, let's get some of these out. And we're not going to cover all 31 here. We'll reference the blog post, of course. But it's nice to have the one-liner because 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 tea okay what do you think jared sounds good we'll have to partially cover a few and so we'll have arguments over was that actually one that's right we won't use any of the real words be ambiguous right all the words have been changed to protect the innocent. Sounds good. Free t-shirt. Why not, right?

The price is right. Just don't go over. Okay, don't go over. Adam will post the official rules in the show notes. Best effort gets the 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 gonna be

fun all right let's pick up on a reflection this seems to be perhaps your favorite or you said you wrote some configuration language yourself here's one about configuration i had not heard of this this is uh 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 try to come up with it myself. I try to coin the term, so it's a new thing. But it's me trying to describe a pattern that I've seen

in 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 it configuration, you know, you start to incorporate environment variables, flags, and eventually, you want to start to check that into version control. So you turn it into a configuration file, maybe YAML, JSON, something like that. And then, you know, as you kind of turn on this this heptagon of configuration and i only called it heptagon just because you know a lot of the ideas came from kubernetes and kubernetes logo has got this the seven points and right just kind of worked out

well but as you're going from kind of configuration files you start to need a little bit more extensibility in terms of templating. And I think templating is something that we're all unfortunately accustomed to a little bit too much. So that's kind of one wheel on the configuration, Heptagonic configuration. And then from templating, you go to kind of a DSL, a domain specific language, and that allows you to have a little more type safety and a little more domain-specific reusable modules. And I'm sure some of us have used Puppet in the DevOps world or there's tons of other DSLs out there. But eventually these DSLs become a little too inflexible.

Maybe the requirements change, the domain changes, and then we go back to Bash. So that's kind of like this never-ending cycle of configuration that I've seen. And I saw this a lot in Kubernetes. There that's kind of like this never-ending cycle of configuration that I've seen. And 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 maybe that's more of kind of a configuration as code or something like Pulumi. But 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? Ooh, 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 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 and the eventual brittleness again of an application because you sort of learn something about it. You provide configuration to the user base so that they can use it in a more flexible manner. And then those flexibilities turn into like, well, this is now a best practice. So all those things solidify to now you want to just hard code them. So almost everybody uses the same flexible configuration in some cases.

I mean, there's a thousand different ways you can slice how this is used in the real world, but that seems to be a necessary iteration process. Yeah, I really like that point. I think it's a lot about discovering what those best practices are and starting to codify them in different sorts of ways. There's an analog to this in economics. Benedict Evans talks about the process of bundling and unbundling. And he says in any given industry, you're either in a bundling process or 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 television, where we were all cable TV, everything was bundled as one, and then we broke out of that individual on demand, subscribed to this, that, the other thing, and now we're in a re-bundling, and it's happening. You can see it with YouTube TV and different aggregators trying to pull together content and that sounds very inefficient like your heptagon sounds inefficient because it's like well we're going around in this circle but what i've heard pointed out is that progress often

looks like a circle when you look at it on its head, like in a two-dimensional plane. But then when you look at it in three-dimensional, it's more like a helix, where it is moving in a circular way, but it's getting better as it goes. And I think with software, that's a lot of what we're seeing is these iterations, and a lot of times returning to the old idea, but you're returning to it with new eyes. You're returning to it with new tools. And so you are building up, but you're not like building blocks on top of each other. You're kind of like circling a wagon, but you're going up, you know, it's like a helix rising, which is slower than we would want it to, but it's still progress, right? Yeah, yeah. I think that's a great point. And I think we're seeing that play out in

the data stack a bit with a lot of old ideas around tooling around data warehouses. And now that we have cloud data warehouses, you have Snowflake, BigQuery, Redshift, etc. We're bringing back a lot of those old ideas, things like OLAP cubes, there, you know, there's analogs to that now. And just it seems kind of like more of the same, but it's really different once you start to look under the surface well another lesson here is one that we touched on with the prag 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 prag prog book is the chapter on dry so they tried to rewrite it i

haven't read the rewrite very closely to know if they accomplished uh clarifying that but you have a point here one of your reflections says know when to break the rules for rules like don't repeat yourself sometimes a little repetition is better than a bit of dependency. And you link to another blog post of yours called Dry Considered Harmful. You want to unpack that one for us? Yeah, I mean, the dry consider harmful, maybe that's a clickbaity. Yeah, a little clickbaity. And you know, I don't think it's actually that harmful. I think the way that it's been dogmatically used is sometimes a little dangerous. But it's just it's a path that I've gone down too many times of carving out microservices

or creating service boundaries where there really shouldn't be or prematurely optimizing when requirements aren't really finalized and the requirements are never finalized. And just the wrong abstraction at a low level can really cause a lot of issues in terms of refactoring and 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 oh 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 know, is what we do. We're like, well, I'll just throw a true false at the end of this thing. And then I have this extra branch in my function because it didn't actually map onto the use case.

Like I thought it did. So a lot of it's just that enthusiasm. I think of like, ah, here we go. I'm going to dry this sucker up. Feels so good. But it does come back to bite. Yeah. I don't really know how to get around it.

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

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

knowledge so it does overlap these things are not completely black and white but that was what they were trying to say maybe they say it much better in the 20th anniversary edition but that's why we all get it wrong I don't know Matt 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 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. So it doesn't always help you. But it does help me slow down a little bit and maybe just 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 correct against it. So if that means erring on the side of duplication, then that seems to be the most helpful for me. Especially on smaller projects when it's either just me and a few other devs or just me. Duplication, I think, is fine because the knowledge tax is maybe not as high. But on large teams, I think maybe go the extra mile and make sure that you're not repeating yourself because the cost of repeating yourself in that context is maybe much higher.

Well said. I had to just practice this discipline yesterday because I was creating a game board for GoTimes 200th episode. We played Gopher's Say, which is their Family Feud edition. And I wanted a visual aid. And so I found a guy who had written one on CodePen. I just wanted, like, just show me the thing, you know, like how Family Feud works, right?

And you guess it, and they, like, show me what the survey says. And the thing, bing, and it shows a number. And I wanted that for the live show. So I grabbed this guy's code pen i just downloaded it just you know an index file a css file a js file and i started tweaking it so it worked for ours and i know i needed seven rounds and so like programmer me is like all right well now i need a templating language right so i can just template this out and then have like a data json data blob that like represents it and then pragmatic me was like dude just copy and paste this file seven times and write the actual data into the html you're never using this again right and if you do then

maybe you can abstract it later but like just repeat yourself even seven times because i knew that was it i was gonna do it seven times and i was never gonna 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 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 docstring can mean a few different things in different languages. I think for something like Java, 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 I wrote this more as kind of like, it should be maybe a yellow flag, maybe not so much a red flag in terms of when you see this happening.

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

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. Unless you're doing something really clever where it's not that obvious and 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, I think it does make sense to be overly verbose. But if you're writing some sort of business logic, I think it maybe makes a little bit more sense to keep it at the function level or 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 to do this you know or like admitting

this is gnarly this is a little bit gnarly but i couldn't think of a better way and sometimes you just have to move on and come back and you'll it'll come to you but yeah i think the what and the 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 is the how usually more than the why yeah but this ties into another one that you say which is if it looks ugly it's most likely a terrible mistake

but i just love that because it can apply to so many aspects of life. But your point is refactor the code versus making the comment if you can. 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 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 macOS, 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. This episode is brought to you by Retool. Retool is a loco platform built specifically for developers that makes it fast and easy to build internal tools. Instead of building internal tools from scratch, the world's best teams, from startups to Fortune 500s, are using Retool to build their internal apps. Assemble your app in 30 seconds by dragging and dropping from the complete set of powerful pre-built components. From there, you write custom code, connect any data source, API, and build custom

logic and queries to create exactly the right tools for your business. Spend your time getting UI in front of your stakeholders, not hunting down the best React table library. Retool is also highly hackable, so you're never limited by what's available out of the box. If you can write it in JavaScript and an API, you can build it in Retool. Try Retool out for yourself at retool.com slash changelog. Again, retool.com slash changelog. 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 posts you're reading could be out of date, the stack overflow answer

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

Code can't lie. That's true. Maybe that's the loophole. Definitely got to check the date on the Stack Overflow. That's for sure. Because if it's like from 2016 and it's 2021, it might be out of date. Might be.

Yeah, I don't know. That's a hard one too, because it depends. And the reason I say it depends and maybe this is where the difference is is these are reflections about pure coding whereas my example here i'll give is more about using so i've been doing a lot of stuff locally with docker a lot of containers on my local network and i'm doing things with docker compose and just learning more about different ways to extend and use docker compose so their yam 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 Stack Overflow 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 yeah i know i've looked these things up and it's like okay well the man page is a start but holy cow have you seen ffmpeg's man page it is massive i mean ffmpeg i give it praise often it's one of the most robust tools i've ever seen i mean the thing can do so many different things it's amazing and it's incredibly black box i mean even the flags are very weird and i end up on stack overflow a lot and i never look at FFmpeg's source code. Now, maybe in that case, I'm just a user of a tool, and so source code is never going to be where I would go unless things aren't working correctly.

Maybe you just say, well, now the man page is really what I'm kind of thinking about. So contextually, when you say that, are you referring to how to solve my particular language feature problem, or how do I loop over these arrays, or how do I use this reduce function? Or are you thinking, what context are you saying,

look at the source code, or what kind of source code are you referring to? 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 cut this clip to 30 seconds? That makes sense, right? You might not even look at the man pages for MPEG on that.

No, I just Google that immediately and end up on Stack Overflow. I'll admit that this advice would have been good yesterday, actually, for me. Matt, you're a day too late, man. 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. 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 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 i've learned tons of things other times you're like

what the heck is going on well if it's ugly's ugly, it's probably a huge mistake. You will level up as a developer. You will better maintain your application. You'll better own and operate your application. And you'll be much better at vetting dependencies being willing to do that. So I think Matt's advice there really pays dividends because not only are you getting at what is true, but you're also getting familiar with all your entire stack versus just the parts that you're used to maintaining. I think black box is kind of a lie. Like there are some things which they can be a black box for a while, but that's just somebody else's abstraction, right? And so you're going to have to, it's going to leak eventually. And so be willing to dive in there and look at that code. Now, when it comes to learning, you have another one here. Only learn from the best. So when you were learning Go, you were at the standard library.

Now, I produce Go time, and I know that there's people that wrote the standard library that may say, eh, 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 maybe the Go standard library is a little strong for most people. Maybe it's not at maybe the right level of readability for most projects, depending on what you're doing. But I think, you know, just as a general rule, find the best examples of code and emulate those instead of, you know,

I mean, there's, I look at a lot of the code that I've published as open source. And, you know, I really hope that no one's reading that. Just because it is, you know, it's kind of half complete, sometimes it's maybe not using best practices. I'm doing workarounds. And when someone else builds on that foundation in a similar way, 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. And I think those are the examples that you should be looking at, depending on what you're building. I actually learned a similar lesson to this from a fellow named Brian Tracy, but it was more in the sales vein and more of a self-development vein than it was simply programming.

But the analogy is very similar. Basically, if you want to be good at something or excel at some way at something, look at who's already doing it really, really well and emulate them. So the practice essentially is if you want to do something really well, find out who's doing the best currently at it or writing the best current version of it and emulate what they've done. Not so much to copy them, but to follow their path to greatness and you may branch off and find your own path but follow the greats to greatness and you may be great yourself i like that now how do we identify the greatness luck you want to be good yeah you're 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 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 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 who was stealing engineers away from others in many ways it was gavin belson the evil bad guy

you know essentially the 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 it kind of ties into what i was just talking about when i was saying you know don't be afraid of looking at the said code i was saying you shouldn't use it if you don't it doesn't mean you have to understand it but you have to be willing to dig

into it i think that being said you say like you, go ahead and use anti-corollary, as most code is terrible. Sometimes it's easier to write a better version yourself. So, well, these seem to be a little bit contradictory. Like, use their code, but don't use it when it's bad. Yeah, I think what I was trying to say there was that all code is terrible to some degree. So even if you look at a library and you 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, maybe 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 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. 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-inventing-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 writing more kind of higher level application code, 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, you know, just to show there's a ton of others.

But sometimes it makes sense to just use other people's code in that case. Would you also say it's like proven ground, where if you're at a lower level, you're on less proven ground, so there's probably less code to potentially even choose from, even if you could. And maybe where you're in more proven ground, say a front end where things are sort of stabilized or something like that, it makes a lot more sense because maybe even the user base of that dependency might be great. They've got a lot of community happening there, a lot of support coming in,

so it makes zero sense for you to invent here rather than dependency yourself. Yeah, I think that's a great point. Yeah, especially around certain projects where the community rallies into a specific project. I mean, Devise is a good example from maybe five, 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. And so you have way more eyes on it. 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? A piece of software, it depends. It can start off completely fitting you. And then a few years later, it's like, this thing's heading in a direction that I don't like.

It's time to jump ship or find an alternative or start writing it yourself. There's a lot to think about with these things. I think it goes back to your earlier point about the cycle of bundling and unbundling as these libraries just grow to accomplish all use cases. As your API needs are much smaller, maybe it makes sense to break out and enroll your own to actually reduce that API surface and it ends up being actually a more stable and maintainable piece of code. So we had a show on JS Party with Ahmad Nasri, who was NPM's

CTO for a while. He also started Kong, or he was involved in Kong. Been around the block, has seen a lot of things. And he takes a very 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 episode. Maybe we'll link up to it because it's an interesting conversation. But I but I thought wow here's like a real context independent

I agree with you I think context does matter but he's saying like nah pretty much if it's not unique to you you're wasting your time and your cycles you should be outsourcing that and you should only write the code that makes you, your company, your org, whatever unique and different or add something to the world

versus reinventing I think in small teams that makes sense for sure. And even if you're in a big org, you 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 even in a big org, you could be a small team. There's also business decisions that go into a lot of these things, beyond merely the engineering decision making.

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

still there in a lot of regards oh yeah well we've all been in the tangled mess before like this is the dependency hell side, right? 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 independent paths exist in your source code. So think of 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. This episode is brought to you by Sourcegraph. Sourcegraph is universal code search that lets you move fast, even in big code bases. Here's CTO and co-founder Byung-Loo explaining the problems that Sourcegraph solves for software teams. Here's a use case that we hear about all the time. It's this scenario where you're a developer who's new to this area of code. Maybe you're new to the team as a whole, and this is part of your onboarding experience. Or maybe you've been on the team for a while, and you're trying to make a change to a code

part of the code base that you're less familiar with. So an issue gets assigned to you, you start coding away, but immediately you stop because the very first thing you have to understand is the context of the code that you're trying to change. If you don't understand that context, it's likely that the change you make is going to get rejected or it's just not going to be, it's not going to make sense within the context of the broader code. This is a natural point where Sourcegraph comes in.

You know, before Sourcegraph, how you would do this, you might go to your editor, you would clone down a bunch of related repositories to whatever issue you're trying to fix, open them up in your editor, and you'd use your editor as kind of this code browsing utility. A lot of people do that. Other people might find that annoying, so they'd go to a code host interface, open them up in your editor and you'd use your editor as kind of this code browsing utility. A lot of people do that. Other people might find that annoying. So they go to a code host interface,

you know, like GitHub and read through the code there. With SourceGrav, you basically have this single search box that is your window or your portal into all the code inside your company. And so you can immediately jump to the relevant pieces of code. You can click around, walk forward and backwards the reference graph of code, jump to definition, find references, use multiple tabs. You can share links with colleagues that you want to ask about a particular section of code. It's just this very natural interface for doing these kind of mental model building exercises that we all do when we're trying to understand a particular piece of code.

All right. Learn how Sourcegraph can help your team at info.sourcegraph.com slash changelog. Again, info.sourcegraph.com slash changelog. 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 uh 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 bugs. Yes, that's true. That's right, bug-free.

And zero dependencies, right? Zero dependencies, easy to deploy, free to deploy. 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 k 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 four million lines of code in one PR. Wow. It was great because our unit test coverage went way up. The tool became much more reliable. And, you know, we didn't have to spend nearly as much time maintaining all these different patches and different pieces of code.

The difference there might be that you didn't write that code, right? You wrote the code to maintain, but you didn't write the four million lines 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 lines 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. Exactly. Yeah. It's much easier to delete someone else's code than to delete your own code. 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, that's your thoughts in software, right? It's your time. It's your effort. I understand 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 oh 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 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 could be sentimental value around something that brought value. Yeah, I don't know.

I get it. If the whole project disappeared, sure. But that function? Why do people identify with these things, do you think? I found it very difficult to delete code, especially when the code's been there a while, it's been battle-tested, it represents a lot of toil. Maybe it's not that 40-line function,

maybe it's that 10-line function that you thought was really clever and it spent hours figuring out the algorithm too, just to figure out that 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. So that's tough, but it's just so necessary. I wonder if it speaks to confidence in yourself, to go psychological. 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 over confident, high confidence, say it how you'd like, but it leads maybe to a lack of or a high degree of confidence, potentially. Maybe. There's probably lots of factors that lead into this. I will say that version control

helps me to leak code much more confidently. Because I feel like if it would be difficult to go back to here ever, 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 comment out huge swaths, but leave them right there. This function's just uncommented out, but why is it still in the source code?

Because they don't trust their git foo or something? You can get back to that. 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. 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? 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. 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, 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. Yeah, you would think these 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 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 SaaS. I know that when SaaS came about, you can always add import CSS files, for example, 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. You just find yourself idising yourself to the point where you're in so many different files.

It's like, is this really helpful? What's the downside to over-organizing? Hard to find things. I think cyclic dependencies as well. I think it could put you in, let's say, 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 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 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 over-splitting. The other thing is you end up rearranging a lot of furniture for no real benefit right at the end of the day you're supposed to be pushing your project forward anytime you're just rearranging furniture which is like i'm going to put things over here wait a second that has to actually go here nah i liked it better when it was the other way and you're just these are all things that

they're nice for procrastinate coding which is something i'm very good at but they're not great for actually getting anything done like anytime you're spent dealing with this other cruft, you're not making progress. Where we like to be is flow, right? We like to be where we're just solving problems, making progress. No one's in the flow as they're renaming files and switching from camel case to snake case or in a cyclical dependency hell.

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

this point yeah unfortunately that's why i called it reflections on programming not maybe lessons okay we're trying to draw some lessons but we'll just have to reflect with you. Yeah, I mean, I think the only lesson is that definitely, at least personally, I have a bias for naming variables as short as possible. And that is probably one of the most unhelpful things you can do to your teammates and to your future 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 i 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 right yeah we were debating the pros and cons of

abbreviating variables on a go time episode that i happen 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 I'm going to iterate it, increment it whenever.

And then I'm done with it. And it's like we all understand that 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 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, 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 I be? 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 would think it's an iterator.

Like that variable is one that you're using to iterate. So I'd call it iterator. Something like that. So would it be more helpful or less helpful if it was for iterator?

You know, if the variable was iterate instead of I. It's too much typing, man. Too much typing. Too much typing, right? So the answer is no. Not more helpful.

This is why Matt likes to make them as small as possible because it's just annoying. Right. Like it's just a balance of like this annoys me even with tab completion versus this is,

you know, it has a useful symbol. Like I don't understand in Go, so if error, not equal null, or if, you know, ER. What's up with that 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. Like I understand that's like, 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 err or 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? It's a word. So is it a shortened version of error, or is it just a shortened version of the word? Well, I'm sure, and I don't know, Matt, you're more of a gopher than I am, but I think in the Go community, when they use 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. Maybe there's a little ambiguity there, even though it is case sensitive, I think. I totally agree. I think when there's convention and you use convention, stick to that. If you were to say E instead of ERR, maybe that's a little wrong 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. 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 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 the such thing is too long i think the point is 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 versus error, as an example. If you read that 50 times a day versus once a week, maybe, do it briefly. 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. Open consideration. Feedback welcome. If you're confused by this variable name, you're just like me. I'm also confused. feature so this is what i got please think of a better name yeah open consideration feedback welcome if you're confused by this variable name you're just like me i'm also confused those are the kind of comments i enjoy hey 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 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, 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 frontend engineers, especially what it means to make a user-friendly CLI or user-friendly error messages. I think sometimes backend engineers over-index on complexity and maybe not thinking of the user. And in a lot of cases, it's another developer.

It's one of those things where there's just so much we can learn by looking at these different sub-communities. So it's something that I try to keep an open mind to. That one absolutely resonates with me. One example I cite often, which I'm still impressed by, is Dan Abramov's stealing of the Elm architecture for Redux. 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 know what other people are working on, or don't niche down or don't go so focused in on a singular aspect of any specific part of the tech world.

Is that the advice then? Seems like it is. It's just ideas like that that can 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. 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 of this technology forward. We often think in camps, we often think,

oh, JavaScript or Go. And this is an example we often run across with GoTime and JSParty, like which one's better, always a competition. JSParty. Sorry. But to be able to look beyond the lines of the camps and say, what ideas have you implemented that would translate to our ecosystem and make sense for us to look at?

I think it's something that's been a hallmark for this show really since its inception. We began as the changelog. We began not choosing the Ruby camp despite our Ruby roots in many ways. We didn't choose a specific camp and say, this is the Ruby changelog. We said, this is the changelog because open source was moving fast. It was difficult to keep up. And this show and the blog that came from it was an example of how to pay attention agnostically across the board and to cross-point 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. There is this idea with to-do comments, which talk about commenting and best practices, is that

you always leave these to-dos lying around our codebases and then nothing else happens. That's where they are. Usually these things never get done. 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, 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 like based on a certain time frame or based on a URL that has to, whatever. I can't remember all the different things, but you can add these conditions to these to-dos. And 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 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 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 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-dos 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 provide that for their language of choice. It's pretty sweet. That's awesome. Yeah.

Well, Matt, we've come to the end of our time here. This has been awesome. I appreciate you writing down what you did so that we all can learn from your reflections. We can discuss and pick them apart and agree or disagree, certainly propagating good ideas and your hard-earned experience out there for other people to learn from. I think that's really cool and appreciate you writing up. Looks like you're blogging quite a bit lately. We'll have links to your blog, this article, everything else we

mentioned, that Jazz Party episode as well, in the show notes for everybody, the one I referenced with Akhmed Nasri, if you want to listen to that discussion as well. Anything else you want to say, Matt, before we call it a show? I mean, thanks for having me. I had such a blast and I've been such a 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. All right, that's it for this episode. Thank you for tuning in. What reflection or learning was your favorite from this show? Let us know in the comments. Of course, as you mentioned the show, be the first to comment with the correct amount of reflections we cover on the show at changelog.fm slash 463. And you will be the winner of a very awesome, very comfy t-shirt from our merch store. Good luck to you. Coming up next week, we are talking about the insane tech hiring market with Gary Gay Oros. Don't miss that episode. Big shout out to our partners, Linode Fastly and Launch Darkly. Also, thanks to Breakmaster Cylinder for making all of our awesome beats. And thank you to

you for listening to this show. We appreciate you. Do us a favor. If you enjoy the show, tell a friend. We'd love to have them as a listener. As you may know, word of mouth is by far the best way for podcasts like ours to grow. The Galaxy Brain Move is to subscribe to our master feed at changelog.com slash master. Get all our podcasts in one single feed. Thanks again for listening.

That's it for this week. We'll see you next week Game on