Matt
Appearances
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Yeah, I think we fall prey to this because we're such pattern matchers. And as soon as you spot that pattern, you're like, ooh, opportunity. Some of that, those abstraction layers are the power in software, right? Like the ability to build those abstractions are what give us leverage. And so every time we see one, we think, boom, I'm not going to repeat myself. I'm going to dry this sucker up.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
But like you point out, oftentimes that second iteration, that second usage is not actually generalizable or it looks generalizable until you find the third one, which, you know, just throw another param on the function, you know, is what we do. We're like, well, I'll just throw a true false at the end of this thing and
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Well, it's worth pointing out what the rule really was or is that they point out in the Pragmatic Programmer book. And the repetition is not about code. That's where we all get it wrong. Anytime you're repeating code, it's bad. So don't repeat yourself. So let's create a function, name it, etc. Abstract a function. What they were talking about is knowledge in your system.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Every piece of knowledge in your system should live in one place and one place only. But because the acronym was DRY, and it's such a catchy thing, and it's easy to remember to repeat yourself, as soon as you start repeating something, you just immediately apply it, right? But that's not the point. It's not about the code that you write. Now, some code does represent knowledge, so it does overlap.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
These things are not completely black and white. But that was what they were trying to say. Maybe they say it much better in the 20th anniversary. But that's why we all get it wrong. I don't know, Matt, what has anything helped you? I mean, you're writing this as a reflection, so you've obviously thought about it. Do you just tread more softly?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
I mean, I've introduced the rule of three for myself, which I think I got from Jeff Atwood's coding horror blog where he's like, you have to use something three times before you'll generalize it. Because I have found that it's usually that third use that points out how bad my abstraction is. But I've also found out sometimes it's like the sixth or seventh use, you know?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
So it doesn't always help you, but it does help me slow down a little bit and maybe just like bite the bullet one more time. What have you found?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Well said. I had to just practice this discipline yesterday because I was creating a game board for Go Times 200th episode. We played Gopher's Say, which is their Family Feud edition, and I wanted a visual aid, and so I found a... a guy who had written one on CodePen. I just wanted, like, just show me the thing, you know, like how Family Feud works, right?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
And you guess it, and they, like, show me what the survey says. And the thing, bing, and it shows a number. And I wanted that for the live show. So I grabbed this guy's CodePen. I just downloaded it. It's just, you know, an index file, a CSS file, a JS file. And I started tweaking it so it would work for ours. And I know I needed seven rounds.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
And so like programmer me is like, all right, well now I need a templating language, right? So I can just template this out and then have like a data, a JSON data blob that like represents it. And then pragmatic me was like, dude, just copy and paste this file seven times and write the actual data into the HTML. You're never using this again, right?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
And if you do, then maybe you can abstract it later. But like, just repeat yourself even seven times. Cause I knew that was it. I was gonna do it seven times and I was never going to touch this again. And I had to like exercise the discipline because programmer engineer me had such sweet solutions for how I could generalize this sucker.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Maybe turn it into a web app that other people could use, you know, that inclination. What helped was I had to have it done in like an hour and a half. And so I'm like, don't start coding. Just hard code the values and move on, man. It's tough. It's tough to fight that urge to generalize. Let's move to the next one. Here we have a reflection of yours around code comments.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
What specifically do you mean by a doc string? And then how'd you learn this? And why do you believe this?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Right. So you're talking about inline comments, like contextual things, hints. Exactly. Okay.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Or like admitting this is gnarly, this is a little bit gnarly, but I couldn't think of a better way. And sometimes you just have to move on and come back and it'll come to you. But yeah, I think the what and the whys. Those should be inline comments, not the hows. Because the how can change, right? That's implementation details.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Oftentimes we see jokes because the comments describe something that no longer exists, you know? Like comments become out of date, especially when you're saying how. That's the most out of date thing because that's going to churn as the how, usually more than the why. But this ties into another one that you say, which is if it looks ugly, it's most likely a terrible mistake. Yeah.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
But I just love that because it can apply to so many aspects of life. But your point is, like, refactor the code versus making the comment if you can. Like, refactor the code so it's readable and clear. But then you say if it's ugly, it's most likely a huge mistake. Where'd this one come from? I love it, but I'm not sure where you drew that conclusion.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
So I'd love to have you elaborate a little bit on this one.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Now, what if you're looking at some code on Stack Overflow? Still could be, still look at the code, right? Code can't lie.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Yeah, it's almost like a good example is like, how do I properly call FFmpeg with these flags from my app? I just say that because we call FFmpeg from our app. I know I've looked these things up. And it's like, okay, well, the man page is a start. But holy cow, have you seen FFmpeg's man page? No. It is massive. I mean, FFmpeg, I give it praise often.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
And so source code is never going to be where I would go unless things aren't working correctly. Maybe you just say, well, now the man page is really what I'm kind of thinking about. So contextually, when you say that, are you referring to how to solve my particular language problem? feature problem or how do I loop over these arrays or how do I use this reduce function?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Or are you thinking, what context are you saying? Look at the source code or what kind of source code are you referring to?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Matt, you're a day too late, man.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Let me add on. I think that's a great example there. And let me add this to what Matt is saying. because I believe this to be true, if you have a library dependency that your application relies upon and you're afraid to or for whatever reason will not peek under the covers and grok its source code, you should not be using that piece of software. You should be ready, willing, and able
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
to read the source code of your dependencies. Now, sometimes those people are better at writing software than you are. I've learned tons of things. Other times you're like, what the heck is going on? Well, if it's ugly, it's probably a huge stake. You will level up as a developer. You will better maintain your application.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Now, I produce Go time, and I know that there's people that wrote the standard library that may say, don't read this part of the standard library. But nonetheless, you went after it. And of course, the standard library is written by expert Go developers. Do you want to tell us more about this particular reflection?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
I like that. Now, how do we identify the greatness?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
You want to be good?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Kind of ties into what I was just talking about when I was saying, you know, don't be afraid of looking at the said code. I was saying you shouldn't use it if you don't. It doesn't mean you have to understand it, but you have to be willing to dig into it, I think. That being said, you say like, you know, go ahead and use. And a corollary is most code is terrible.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Sometimes it's easier to write a better version yourself. So while they seem to be a little bit contradictory, like use their code, but don't use it when it's bad.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Yeah, especially around certain projects where the community rallies into a specific project. I mean, Devize is a good example from maybe five, 10 years ago now where all of the authentication things, like instead of rolling your own, you use Devize and then you worked on Devize with the Devize people and everybody's making that one thing better. And so you have way more eyes on it.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
You have way more feature development bug fixes while you're sleeping. Like that whole community open source flywheel gets rolling and that's a real benefit. Now on the other side, a community can move away from you and your project, right? Like all of a sudden they're adding things that you don't want or need and you disagree with.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
And too bad the community all thinks this is good, but hey, I don't need SMS-based two-factor auth. And now you're just adding lines of code to my project when I upgrade, and I don't care. Not in Devise's case. It's pluggable. It was pretty good software. Still is, probably. But you know what I'm saying? Like a piece of software, it depends. He can start off like completely fitting you.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
And then a few years later, it's like this thing's heading in a direction that I don't like. And then it's time to jump ship or find an alternative or start writing it yourself. There's a lot to think about these things. Mm hmm.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Everything else you shouldn't be writing. Him and I actually go back and forth on that, so maybe we'll link up to it because it's an interesting conversation. But I thought, wow, here's like a real context independent. I agree with you. I think context doesn't matter. But he's saying like, nah, pretty much if it's not unique to you, you're wasting your time and your cycles.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
You should be outsourcing that and you should only write the code that makes you, your company, your org, whatever unique. unique and different or add something to the world versus reinventing.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
I mean, the context goes on and on and on for these decisions.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Oh, yeah. Well, we've all been in the tangled mess before. Like, this is the dependency hell side, right? Like, how did I get here? I can't get out. Can you quickly define cyclomatic complexity for those who are unaware of the term or the understanding?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Yes, that's true. That's right. Bug free and zero dependencies, right?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
That's right.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
I have never identified closely with my code. I think a lot of people do. And I do understand why you would, because like you said, you put your, that's your thoughts on in software, right? It's your, it's your time. It's your effort. I understand it, but I do not and have not identified closely with my code. In other words, I've always loved to delete my own code.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
I've never been like, aw shucks, I'm really going to miss you, 40 line function, you know? I've just been like, good, I don't need to do this anymore. Because it's always felt like a liability to me. It's never felt like something precious to hold on to, like other things do. I don't know about you, Matt. Have you ever felt like some code's been hard to get rid of?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Maybe it should. Maybe you should have copy and pasted something off Stack Overflow.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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...
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
novices mostly just like comment out huge swaths but leave them right there like this function just uncommented out but why is it still in the source code because they don't trust their git foo or something it's like you can get back to that you know like that's what version control is for go look at a previous version
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
It's the dry principle that I do adhere to. Don't repeat yourself when there are mistakes. Don't repeat your mistakes. Dry them, as they say. Oh, yeah. What is 10,000 hours? So if we assume eight hours a day, five days a week, let's say eight hours a day times five, right? Times call it 50 weeks a year. That's 2000.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Yeah, you would think this would be small concerns, but they end up becoming large concerns in software architecture, right? It's like where the files go, how I name things, where to put things, especially when you start working on teams, then there's disagreements over how this works. You're introducing logistics into your software by having these distinctions prematurely.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
and having to make sure everything's in the right place name the correct way etc start simple and then only i think abstract when it's uh necessary and beneficial that is an art though and it does take time to learn and even you know somebody who's done it for i think you and i are in very similar boats i've definitely been writing software for 15 years i still screw that up i still make the wrong call and then maybe it's hours later maybe it's days or weeks i'm like
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Yeah.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
The other thing is you end up rearranging a lot of furniture for no real benefit. At the end of the day, you're supposed to be pushing your project forward. Anytime you're just rearranging furniture, which is like, I'm going to put things over here, wait a second, that has to actually go here. Nah, I liked it better when it was the other way.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
So if you're working like a typical nine to five, take a couple of weeks off for vacation, that's 2000 hours a year and you got 15 years. So you're well over the high water mark. Did you do the math or you just, you just like, yeah, I'm there.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
These are all things that are nice for procrastinating, which is something I'm very good at, but they're not great for actually getting anything done. Anytime you're dealing with this other cruft, you're not making progress. Where we like to be is flow, right? We like to be where we're just like solving problems, making progress.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Name your variables correctly. Any tangible advice for us on this point?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Okay, we're trying to draw some lessons, but we'll just have to reflect with you.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
So like you'll abbreviate things and like really condense them down.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Right. Yeah, we were debating the pros and cons of abbreviating variables on a go time episode that I happened to be upon. And I learned something there, or maybe it was just coagulated there from Dave Chaney, where he said something along the lines of the further away the variable is from being used, the longer its name should be.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
But like the closer it is to being used, the name can be shorter and shorter, like to the immediate context. So like a for loop is an obvious one where it's like, yeah, I is fine. Because, like, here's I, it equals this. I'm going to iterate it, increment it, whatever. And then I'm done with it. And it's like, we all understand that. It's I. It's not actually confusing.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
But, like, if you start naming your variables that are used further down or elsewhere, maybe they're exposed somehow, I. or Z or foobar or baz, these are like, they don't signal anything to somebody who doesn't have your immediate context.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Yeah, I think it's an iterator. Like that variable is one that you're using to iterate. And so I'd call it iterator, something like that.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
This is why Matt likes to make them as small as possible because it's just annoying. Right. Like, it's just a balance of, like, this annoys me, even with tab completion, versus this has a useful symbol. Like, I don't understand in Go, so if error, not equal null, or if, you know, ERR. What's up with that? You're saving literally two letters, error versus er.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
So you're well over, where did you get, where did you earn your keep? You've had a couple of different jobs. You want to tell us about your, the 10,000 hours you put in, where it was and what kind of stuff you worked on?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
But it's a convention of the community, so everybody knows what it is. I don't think it's ambiguous when you see F-E-R-R. I understand that's the error. But the abbreviation there to me is like, what am I gaining? I'm saving two letters. I understand when you take internationalization and you say I-18-N. That's a huge win for all of us, right? Yeah.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
But ERR, as an abbreviation for E-R-R-O-R, it just seems a little bit silly. That being said, we all do it. We're all on board. It's clear. It's not a problem. I just don't understand the win.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Yeah.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Well, I'm sure, and I don't know, Matt, you're more of a gopher than I am, but I think when in the go community, when they use ERR, it's representing an error, isn't it?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Yeah, I agree.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Because when I say, I like to say, Hey, this variable name is terrible too. But like, Lacking any of their information. Like, well, that's not useful. How could it be better? Like, well, it's 27 characters long. So that's not good.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Those are the kind of comments I enjoy. Because you get a chuckle even when you come back to it later. You're like, oh yeah, I couldn't think of a name for this thing. Then you sit there and you're like, hmm, I still can't think of a good one. But sometimes it just comes to you. All right, let's hit another one here. This one's a little bit bigger picture. Technology does not diffuse equally.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
That one absolutely resonates with me. One example I cite often, which I'm still impressed by, is Dan Abramov's stealing of the Elm architecture for Redux. And he came on the show back when Redux first started getting wide use in the React community. And he basically said, yeah, I saw what the Elm folks were doing over there. And it was awesome, their architecture for state.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
and everybody benefits i think when those things propagate across community bounds for sure so individual takeaways there i guess is kind of like keep your head up and and know what other people are working on or don't don't niche down or don't go so focused in on a singular aspect of any specific part of the tech world or is that the advice then seems like it is
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Here's another awesome example. This happened just recently. I love seeing it because it means we're having a little bit of impact out there. So there is this idea with to do comments, which talk about commenting and best practices is that, you know, you always leave these to do's lying around our code bases and then nothing else happens. Like that's where they are.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
And usually these things never get done. And a lot of times it's because you forget about it or it depends on something else changing. Well, there was a cool idea coming out of, I think, the Rust community, and there's also a Ruby gem for this, where they started having these self-destructing to-dos. Have you guys heard of these? So it's like you write your to-do.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
It's like a static analyzer kind of a thing. You write your to-dos in a specific syntax where you can apply criteria to your to-do, whether it's based on a certain time frame or based on... a URL that has to, whatever. I can't remember all the different things, but you can add these conditions to these to-dos.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
And then the tooling provides integrations, I believe, into editors and different linters and stuff to like bring, float those to-dos. It's kind of like with Gmail where you can like push things off till later and then they come back. And that was a really cool idea. Well, then somebody got inspired by that and they made one for Python.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
So that person's name is Clemon Seaver and he wrote To Do or Die. They're called To Do or Die. And they're to-do-or-die Python edition. So we covered that one. We covered the Rust one. And then the Python one cropped up. And then somebody else was inspired by that, Brian Underwood. And he wrote one for the Elixir community in Credo called Credo to-do or deny.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
And Credo is like a linting tool or a best practice following kind of analyzer tool for Elixir. And so now this concept, which was over there in the Rust world of, hey, what if our to-dos had these, you know, were better than what they already are.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
this article, everything else we mentioned that jazz party episode as well in the show notes for everybody. The one I referenced with Ahmad Nasri, if you want to listen to that discussion as well. Anything else you want to say, Matt, before we call the show?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Yeah, it was lots of fun.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Well, you can learn from experience, but you can also, life hack, learn from other people's experience. So I loved this post. You had 31 things that you've reflected, and it is specific to programming. These are not large life lessons or people lessons, you say. These are like specific programming lessons that you've learned. And I thought, let's get some of these out.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
What do you think, Jared? Sounds good. We'll have to partially cover a few and still have arguments over, was that actually one? That's right. We won't use any of the real words. It'd be ambiguous, right? All the words have been changed to protect the innocent. Sounds good. Free t-shirt. Why not, right? That's right. Could be the price is right. Just don't go over, be under. Okay, don't go over.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Adam will post the official rules in the show notes.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
All right, let's pick up on a reflection. This seems to be perhaps your favorite, or you said you wrote some configuration language yourself. Here's one about configuration. I had not heard of this. This is reflection number 30. Oh, I probably shouldn't list them now because we're making it more difficult. This may or may not be in your list. And this is about the heptagon of configuration.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Matt, I'm going to let you explain that to me because I've never heard of this before.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
There's an analog to this in economics. Benedict Evans talks about the process of bundling and unbundling. And he says in any given industry, you're either in a bundling process or an unbundling process. And it's cyclical, right? So an example of that is like television, where we were all cable TV, everything was bundled as one, and then we broke out of that.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
individual on demand, subscribe to this, that, the other thing. And now we're like in a rebundling and it's happening. You can see it with YouTube TV and different aggregators trying to pull together content. And that sounds very inefficient. Like your Heptagon sounds inefficient because it's like, well, we're going around in this circle.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
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
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
these iterations and a lot of times returning to the old idea, but you're returning to it with new eyes and returning to it with new tools. And so you are building up, but you're not like building blocks on top of each other. You're kind of like circling a wagon, but you're going up, you know, it's like a helix rising, which is slower than we would want it to, but it's still progress, right?
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
Well, another lesson here is one that we touched on with the Brag Prog fellas themselves around dry. This is always controversial, dry. And it's because we all think about it a little bit differently, or I think that we all misunderstand what their point was.
The Changelog: Software Development, Open Source
Lessons from 10k hours of programming (Remastered) (Interview)
They did point out on that episode when we had their 20th anniversary show that one of the most misunderstood points in the Prague Prague book is the chapter on dry. So they tried to rewrite it. I haven't read the rewrite very closely to know if they accomplished clarifying that. But you have a point here, one of your reflections here.