Blog
Bio
The Technician
No Imperfections Noted
The Jeff and Casey Show
Jeff and Casey Time
Casey Muratori
Seattle, WA
Jeff and Casey's Guide to Becomming a Bigger Programmer
Original air date: June 9th, 2014
Subscribe. If you’d like to have the latest episode of The Jeff and Casey Show delivered fresh to your computer every Monday, you can check out our list of RSS feeds and other subscription options here.
Transcript
Jeff:
Hey, everybody. Welcome to the Jeff & Casey Show.
Casey:
Hello and welcome…
Jeff:
No flip-offs.
Casey:
But that’s how we start the show.
Jeff:
No. I don’t like that.
Casey:
That is the magic. That’s part of the magic.
Jeff:
I don’t…
Casey:
Those are magic fingers.
Jeff:
I don’t like this.
Casey:
Magic fingers…Anyways, welcome to the Jeff & Casey Show.
Jeff:
That’s right.
Casey:
I feel like this is going to be another one of those sort of… Another one of those days, if you will.
Jeff:
Okay.
Casey:
Because you have decided that we are going to go headfirst back to the topic of programming which always generates some kerfuffle. It generates kerfuffle.
Jeff:
Okay.
Casey:
Usually positive which is actually amusing. I assume that that’s because our audience is self-selecting in some sense.
Jeff:
Yeah.
Casey:
Like, people who don’t sort of share our attitudes towards things, maybe, would be less inclined to listen to the show at all. So we don’t get a lot of blowback I feel like if you were just a regular dude, like you were one of those programmers or whatever the fuck and you posted something like “Object-oriented programming is bullshit”, I feel like that goes off the rails quickly. Like, everyone on the stock exchange is freaking out, right?
Jeff:
Right.
Casey:
Like, there’s all kinds of… The Reddit, sub-Reddit is blocking you and unblock… Like, shit goes down, right?
Jeff:
But we don’t get a lot.
Casey:
But we don’t have that problem.
Jeff:
Yeah.
Casey:
We mostly get people who are rational and supportive or simply discussing the matter.
Jeff:
Right.
Casey:
We don’t get the blowback which I suppose is good. It’s a good position to be in. Anyway, we got feedback from the programming topic that we… Someone had written in… It was [ Andres Leano ], actually, who… In fact, he wrote back after that, thanking us for doing that podcast and still didn’t include how to pronounce his name. I even talked about it. I was like, “Say how to pronounce your name.” I don’t know how to pronounce his name.
Jeff:
Awesome. So this is on that Agile Scrum thing…
Casey:
The Agile Scrum thing…
Jeff:
Right.
Casey:
We did a big talked. We talked about a lot of stuff that wasn’t so much Agile Scrum thing. It was more like I was kind of giving a framework for why I don’t think it’s that important.
Jeff:
Right.
Casey:
And you were talking about how you think there’s a different part of the problem that’s important to you and so on. So we didn’t really ever deal with Agile Scrum because we just didn’t think it was that important which I think is true.
Jeff:
Okay.
Casey:
Anyway, we got feedback on that one from a couple of different people, actually. And they were mostly talking about what do you think is a good idea to do. Like, it was sort of like, “Well, okay. If you have to give some more concrete steps along the lines of things we talked about…” ‘Cos we kind of, in that one, mention stuff, right?
Jeff:
Okay. Do they mean, like, for big projects? Or are they talking about for their personal…
Casey:
I think personally. I think they’re talking about things that you can enact…
Jeff:
To be a better programmer?
Casey:
To be a better programmer, not if you’re the manager of some large division of IBM, integrating software integration people or something, what you do. But more like, “I’m a person. I want to program better. I feel like there is room for improvement in my programming and I would like to do so. But I maybe don’t have a lot of concrete ideas about how to. What should I do?”
Jeff:
Okay.
Casey:
That is basically… And both Dale Kim and someone named Trey, who never includes a last name…
Jeff:
Just Trey.
Casey:
Just Trey but his email address… Like, the first part of his email address, not the domain or whatever, the first part is [ Side Oats ].
Jeff:
Okay.
Casey:
Now, I don’t know what [ Side Oats ] are.
Jeff:
Maybe that’s his last name, Trey [ Side Oats ].
Casey:
I know it’s like steel-cut oats and stuff like this. So yes, he is Trey [ Side Oats ] as far as I’m concerned because I don’t know…
Jeff:
Alright.
Casey:
I’ve got nothing else to go on.
Jeff:
Okay.
Casey:
They both wrote in and had sort of similar… I’m lumping their two questions together because, in some sense, they were the same in that way.
Jeff:
Okay.
Casey:
So that’s the question…
Jeff:
Alright.
Casey:
For this episode of the Jeff & Casey Show…
Jeff:
Is how to become a better programmer?
Casey:
I guess so.
Jeff:
Okay. It’s this separate thing of, like, how do you become a better team mate with your other people and stuff like that which I’m completely unqualified to talk about, right?
Casey:
Okay. Yes.
Jeff:
Like, that’s just…
Casey:
Yeah.
Jeff:
Yeah. Well, I guess there’s a couple things. There’s… I mean, the biggest thing, I think… And people aren’t gonna like this but the biggest thing is I think you just write a lot of code.
Casey:
Yeah.
Jeff:
Like, the big… And in a lot of times, that comes down to, “Oh, there’s just nothing that interests me.” And I’ll just say the easiest thing there is just pick something small.
Casey:
Okay.
Jeff:
Grab an iPhone game that’s tiny and just replicate it. Just do it.
Casey:
Okay.
Jeff:
And like… Don’t [ know if I can sell it ]…
Casey:
Oh, you mean like pick someone else’s iPhone game…
Jeff:
Just go and… Just go and do that whole process once. And you’ll learn a lot of stuff.
Casey:
Okay.
Jeff:
In terms of how to become a better programmer is some weird kind of other things.
Casey:
Okay.
Jeff:
“Put your coat out there for other people to look at.”
Casey:
Oh.
Jeff:
And try to write a library that somebody might use.
Casey:
But what will that do?
Jeff:
If you put something out there, like, “Oh, hey. Here is my Zlib decoder.”
Casey:
Right. Yeah.
Jeff:
Alright? You’re gonna get a lot of feedback on that, depending on if people even see it.
Casey:
But a lot of it’s gonna be wrong. I’m just gonna be like, “Where’s the C++ wrapper in this shit?”
Jeff:
Totally. But you’re going to get feedback…
Casey:
So you might not know…
Jeff:
Yeah. I mean, you may not be able to tell what’s good and what’s bad.
Casey:
Right.
Jeff:
And hey, that’s going to be true at your work, too. Like, you’re gonna be getting your managers saying, like, “We really should switch to this or that or whatever…”
Casey:
Yeah, that’s true. Yeah. Right, right.
Jeff:
You’re going to get mixed feelings, mixed feedback there, too.
Casey:
Yeah.
Jeff:
Bt you will get… It’s very easy, when you write your own code, to get kind of lost in not… In your own stuff.
Casey:
Yeah.
Jeff:
Like, “This is the way I do it,” and… And then somebody else… As soon as you talk about it with somebody, or someone else looks at it and is like, “Why didn’t you think about this?” Even if it’s wrong, it’ll at least think about, “Oh, I never thought about that. I never thought about organizing it. So, like, I’ll give you my little pet peeve is 90% of the encoders or decoders of a particular file format…
Casey:
Yeah.
Jeff:
Put the encoder and decoder all on the same thing.
Casey:
Okay.
Jeff:
And I hate that.
Casey:
Okay.
Jeff:
Split those off because they’re rarely going to be used in the same program.
Casey:
Okay.
Jeff:
They do happen when you’re writing a [ Paint ] package.
Casey:
Yeah.
Jeff:
But most of the time, you’re writing a loader…
Casey:
Okay.
Jeff:
Or you’re writing a tool that reads in something and I need to just write that. I don’t need all that other stuff that I need to get working and maintain and all that…
Casey:
Yeah.
Jeff:
It should just be one thing. And then the other thing I would say is start…
Casey:
Well, it sounds like there’s a separate problem in there, in some sense, right? Which is that the fact that there is more maintenance work necessary for the encoder and the decoder than just either one of them separately, that to me is sort of a red flag to begin with because there should be no more maintenance work to the end user in getting both of them running than there is in getting either one running. But oftentimes, that is not the case. Oftentimes, it’s like, “Ah, fuck,” it’s like, calling all extra functions in the encoder that’s, like, using some Windows thing. So really, I would say that there’s almost a meta thing wrapped in the statement you just… Where it’s just like, why is it even an issue? Like, why would porting one, for example, or linking one create more problems… I mean, linking both create more problems than…
Jeff:
Yeah.
Casey:
’Cos normally, I mean, you shouldn’t care which…
Jeff:
And [ I can tell ] you what they are. I mean like, a lot of the issues you’ll end up seeing with this are, like, “Hey, the encoder allocated a shit ton of memory and has a lot of complicated code that it drags in that are from other libraries.” The decoder needs none of it. And usually, the encoder is running on a PC. And your decoder has to run on everything. So having them together means I now need to figure out a way to de-couple those.
Casey:
Yes.
Jeff:
So there’s that. I’d say the other thing is spend a lot of time turning on the debugger in disassembly mode…
Casey:
Yeah.
Jeff:
And then, look at what your code is doing. And you won’t understand it at first.
Casey:
Okay.
Jeff:
It’d be like, “Uh…” You get all symbols. But you’ll start seeing patterns, like people are incredible at discovering this stuff. You don’t need… A lot of the times, you won’t need an assembly book for a lot of what you’re going to do there. Most of it is self-explanatory after you’ve looked at it for a while.
Casey:
Okay.
Jeff:
Get used to doing that because you’re gonna start seeing things like, “Hey, this line of code generated a shit ton of stuff here.”
Casey:
Yeah.
Jeff:
And you can start thinking about the fact that that’s a heavy… Like…
Casey:
Right, right.
Jeff:
That because it’s generating, that means there’s a lot of stuff happening there…
Casey:
So the meta thing there that you’re basically saying is…
Jeff:
Understand the machine.
Casey:
Be aware… Yeah. Be aware of what your code is actually doing on the CPU as opposed to just semantically what you thought it was doing in terms of the language that you happen to write it in…
Jeff:
Yeah.
Casey:
Which is really not actually all that relevant in some level.
Jeff:
Yeah. Right.
Casey:
Okay.
Jeff:
Yep.
Casey:
Yeah. I agree with that. That is a problem… Like, that’s especially a problem when they start in situations where if people learn programming at college or something or they teach them in Java or whatever the fuck…
Jeff:
Right.
Casey:
So there literally is no assembly language to look at because you would have to first get the [ git ] to run and then look… I don’t know. Maybe there’s debuggers now that let you do that. In the old days, there certainly weren’t.
Jeff:
I was talking to…
Casey:
You know, because it’s just the [ byte ] code. You could look at the Java [ byte ] code but that ain’t gonna tell you anything.
Jeff:
I had an interesting talk. I was talking to somebody the other day about… He was saying how little… How much most of his programming is not based on algorithms and strong computer science stuff. It’s all based on “how can I make this more robust”, “how can I make this run on more platforms easily”…
Casey:
Okay.
Jeff:
And he’s like, “That’s just not something you really spend a lot of time with in writing code, writing things that are…” You know, when you go through college especially, you spend a lot of time on kind of the design of the thing that you’re writing.
Casey:
Right.
Jeff:
And then, the day to day programming, it’s not a lot of that. It’s like…
Casey:
Right.
Jeff:
Like writing, you generally come up with the skeleton of what your story is…
Casey:
Yes.
Jeff:
And then you spend a year doing all the day to day tactical writing stuff of “I’ve got to fill this whole story in”.
Casey:
So yeah, I mean, I guess I would say on that front, this touches a little bit on what I said in the original one which is just that there’s oftentimes… In actual production code, there’s usually a very big difference between what you would’ve known was the optimal thing to write and what you actually wrote. And the reason for that is because of this elaborate set of trade-offs in terms of what’s gonna be easiest to maintain, what’s gonna be easiest to debug, what’s gonna be easiest to deploy, what’s gonna be easiest to port, what’s gonna be the quickest to do because every…
Jeff:
Right, what kind of hand-off to another program…
Casey:
Yes, every hour I spend on this is an hour I’m not spending on some other piece of code. And was that other piece of code more important in terms of the [inaudible 10:58] of this particular, whatever we’re baking. I don’t know what you’re making but whatever you are making… And so, you end up in a situation where unfortunately, yeah, a lot of that stuff… I mean, there’s definitely cases when you are on the forefront of algorithms, when you are pushing a certain envelope there. And that’s definitely… Depending on what sort of code you’re working on day to day, I think at RAD, that does happen fairly frequently. There’s times during the year when you’re gonna push on some part of the product. And you’re doing something that no one’s really ever done before in that particular segment. Like, if you’re doing the… Like, certainly on Granny, we did some stuff, you know, that was like… No one’s ever done this particular thing before that we’re doing or whatever. So we’re kind of pushing forward into that space where we’re like, “How do we do this algorithm in this way,” or whatever, right? So occasionally, that happens. But it’s not the majority of what you do. That’s more of what a researcher does at some level, you know?
Jeff:
Yeah.
Casey:
So it is true that the vast majority of the work on the products that you do is the day to day…
Jeff:
Yeah.
Casey:
And you’re making a lot of… It’s mostly about dealing with trade-offs and not about, “Oh, yeah. Like, the optimal way to phrase this problem so that it ran in [inaudible 12:14] with the…” You know, it’d be interesting if that was most of your job but it’s not. It’s really not. And that’s the thing you do. And you get probably a huge perception of it because if I’m gonna go give a paper on like, “What did we do on Granny that was cool?” I’m gonna write up the new algorithm thing that we figured out that people hadn’t done before because that’s the paper. But that was 3 weeks of my year, right?
Jeff:
Right.
Casey:
The rest of the year was all the mundane shit that makes this product actually function as a product, right?
Jeff:
Right.
Casey:
And I think that’s true of most projects. So you get the impression because when you look at the things, you’re like, “Oh, you know, we went and we saw the [inaudible 12:54] paper or whatever.” And it’s like, “Here’s this cool [ lighting thing ] we figured out.” It’s like, okay. But actually, that dude’s year was not implementing that algorithm. It was all the shit and, like, “Oh, meshes had to come in with the different [ UV’s ] to make the algorithm work. So I had to work on the pipeline to break them up at the right stage. And oh, fuck, that was too slow. So we had to optimize it for the artist because they needed a quick…” That is what you’ll hear from those people when you ask them, “What did you actually spend your day to day on?” It wasn’t the month it took them to come up with the cool lighting algorithm and perfect it, right, unfortunately.
Jeff:
Right.
Casey:
That was not… It was… Those days were sparse, like were [inaudible 13:29] with all this other shit. So anyway…
Jeff:
Well, in programming, the other thing that’s hard just in terms of the subject anyway is that you have this thing where if you’re a good… Being a good programmer is a separate thing than shipping products a lot of the time. So you have this weird thing of you’ve shipped a product but you might be ashamed of the code that’s inside that. That happens a lot with programmers…
Casey:
Well, if you’re not, you probably aren’t looking that [ part. ]
Jeff:
Yeah.
Casey:
Like, you know, I definitely have…
Jeff:
So it is… I mean, that’s a weird thing.
Casey:
Yes.
Jeff:
It’s like, I think filmmakers are comfortable with their film as it looks, as being representative for the work that they did. Whereas we…
Casey:
You think so?
Jeff:
I think so.
Casey:
You don’t think they’re mad like, “We could’ve done better on that shot,” or, “Man, that’s so ugly there. We didn’t have the right lighting…”
Jeff:
I think that they’re critical.
Casey:
Okay.
Jeff:
But we’re, like… We’re critical of things that our end-users don’t see.
Casey:
Okay, that’s true.
Jeff:
Like, hey, this app runs. It does everything.
Casey:
Right.
Jeff:
It may even not have any bugs that people see. But I know underneath it’s fucking disaster.
Casey:
There’s bugs in there. There’s shit going down.
Jeff:
Yeah. And it’d be, like, “Oh, I made a painting,” but I happen to know that the painting was made with radioactive materials.
Casey:
Right, right, right. Yeah.
Jeff:
And it’s slowly deteriorating.
Casey:
Yeah.
Jeff:
And you’re just like, “I hope enough people see this before the painting dissolves or something.
Casey:
Well, I definitely… Yeah, it’s interesting. I mean… So one thing I would say that you sort of, that slipped in there, too, that’s worth emphasizing, is I feel like getting a single code-base to compile on many platforms is definitely something you should do.
Jeff:
Yeah.
Casey:
That’s just, like… Everyone should do that and get comfortable with doing that. At a minimum right now, I always… And I may end up…
Jeff:
That’s a really good point, though.
Casey:
Yeah, yeah, yeah. I may end up switching away from this a little bit just because I’m so sick of Microsoft that I may even not even compile on them anymore, most of the time. But I generally do stuff like, “Okay, my laptop is Linux and my desktop is Windows or something…”
Jeff:
Right.
Casey:
So that I’m always compiling and running correctly on at least 2 platforms all the time.
Jeff:
Right. That’s a good point.
Casey:
And I feel like that’s a good habit to get into. I wouldn’t necessarily push it to an extreme because of the thing we talked about before where nowadays, a lot of platforms are just actively hostile. You will just waste a ton of time just trying to fucking get the build to execute on your iPhone or whatever the fuck because of the [inaudible 16:02] and all that stuff. But on any platform that’s relatively open any platform that you can just write code to and run it, it is worth taking some time and going, “I’m gonna write a thing and I’m going to learn how to seamlessly deploy this code across many platforms in a way that isn’t ugly. I’m gonna take a look at that.” And you know, you need to sit down and go, “What are the actual operating system services that this depends on? Let me isolate those out. Let me have a clean break so that there’s just some files in a directory that’s just like, ‘Here are the different platform-specific files. There’s the Win-32 one. There’s the iOS one.’ Whatever. I’ve got them in a directory. And then there’s another directory that’s got just the code that compiles everywhere.” And that’s most. It should be 99% of your code. So you just have [ a little, right? ]
Jeff:
Right.
Casey:
Doing that is a good exercise because it will force you to think about an API boundary in a place where you can’t really fake it. Like, every other time that you do an API design exercise, you can lie to yourself because there isn’t some actual overarching thing. But you know when you’re doing this exercise, if you start having a bunch of [ IF deaths ] all throughout your code like [inaudible 17:21] you know you fucked up, right?
Jeff:
Yeah.
Casey:
So it’s different when it won’t fucking compile if you did the thing wrong versus, “Oh, this API isn’t quite as good as it should be, right?
Jeff:
Right, right, right.
Casey:
So I think that’s a good first step. And everyone should probably learn to do that. I take it for granted now because most people that I know just know how to do this. And I’d actually… The first thing that I worked on after I got out of high school was actually a product that ran on multiple platforms. And so I, right off the bat in the commercial industry, was sort of acultured into this boundary thing.
Jeff:
Right.
Casey:
And I feel like that was a very good experience of learning that that is how something should work.
Jeff:
Right. And it doesn’t mean using Java or something that distracts the differences. You want to think about different compilers, different tool chains…
Casey:
Yeah, yeah, yeah. I want you to put…
Jeff:
Different ways…
Casey:
I want you to pick some situation where you are interfacing directly with the operating system so that you have to handle the wall off.
Jeff:
Right.
Casey:
I’m not talking about, “Yeah, I downloaded [ Glut ] or something and it had a bunch of shit that I called and I don’t know, it kinda worked.” Like, not that. I’m talking about you directly call the operating system. And so, I don’t know if you can do stuff like that. I suspect you maybe can in Java. I’m not sure. But obviously, in C, you can totally do this.
Jeff:
Right.
Casey:
So just do it in that or whatever the fuck. And do a Linux version. Do a Windows version. Maybe do a Mac version. But unfortunately, the thing with doing a Mac version is you’ve got to write an Objective C. I don’t feel like that should be part of the exercise. I don’t give a shit about Objective C. Fuck platform benders that make you write in different languages. I don’t care about that. So that’s not part of the exercise. That’s drudge work that they’re making you do because they don’t care about you.
Jeff:
Right.
Casey:
So I was thinking more focus [ on the you getting a better] programmer and doing that part. So I would say that that’s probably a pretty good idea.
Jeff:
Yeah.
Casey:
But anyway…
Jeff:
And this is about… I mean, the advice I’m giving at least is very much about programming and not necessarily getting things done, which is a separate thing of, like…
Casey:
Yeah.
Jeff:
“Hey, if you want to be a good programmer, eventually, everyone of those little…”
Casey:
Unplug the internet. Just unplug the internet.
Jeff:
Well, let’s say you write something…
Casey:
That’s tip number 1.
Jeff:
And you’re like, “I’m using this library and this library and this library.”
Casey:
Yeah.
Jeff:
Slowly go try to writ one of each one of those yourself so you understand like…
Casey:
Yeah. Yeah.
Jeff:
“Hey, I didn’t just cut and paste this code. I actually wrote this. I understand it.” I think there’s some things that just become good habits that you get into that you’re forced into by limitations in language, too. So you try using something that’s a little outside your skill set in terms of, like, C or instead of C++, try to use something with some constraints because you’ll think a little bit more about the fact of what’s going on.
Casey:
Yeah. And I guess the nice thing about C, as well, is it kind of is well-suited to the thing that you were saying before, as well, of looking at the assembly.
Jeff:
Yeah. That’s true.
Casey:
Because one of the nice things about doing it in C… If you’re doing this exercise in C and you’re gonna combine them… So I’m gonna do the OS thing, right… Is C… So in my opinion, C was the last time someone came up with the great language. Like, I’m just gonna put that out there. Like, I have not seen a language after C that was great. Every language that’s been after C has not been very good. And that doesn’t mean that I think that C is the best language to write everything in right now.
Jeff:
Yeah.
Casey:
But what I mean is for the problem domain that C was trying to tackle, they did an exceptionally good job.
Jeff:
Yeah.
Casey:
And there’s plenty…
Jeff:
I’ve heard the same thing about that Go is like that for tool sets separate--… Like, when you’re writing tools, it’s supposed to be that good there, too.
Casey:
What do you mean by tools?
Jeff:
Like, hey, if you’re writing something where you’re trying to just… When you’re trying to get stuff done and actually be like, “I just don’t want to have to think about allocating memory for the string while I’m doing this and this,” the standard place you use PHP or whatchamacallit, Python or whatever… I heard Go is actually really good for that kind of thing.
Casey:
Well, but again… So I would…
Jeff:
So I’m just saying that…
Casey:
I would object to that. Now, I have not used Go. I mean, I have seen Go. I have not used Go. So I would suspect that if I went and looked at Go, I would strongly disagree with that attitude.
Jeff:
Yeah.
Casey:
And the reason why…
Jeff:
I’m saying people that I actually respect I think really like it. So…
Casey:
But I will say the reason why. The reason why is because what is the problem domain that Go is trying to solve, right? And if it really was making “tools” (which I guess I’m not sure exactly what that necessarily encompasses, right), I strongly suspect that compared to how well C abstracted assembly code (which was its goal), I between Go blows by comparison in terms of how easy it is to create tools. If tools is the thing that you are trying to make work really well, I between it’s not even point 1 C is worth of it. That’s my guess.
Jeff:
I don’t know. We could find out. My guess is if you want to make something that is a good tool-building language, having something with an insanely huge, big, reasonable runtime is a big part of that. And the run time is supposed to be amazing.
Casey:
But that really has nothing to do with the language.
Jeff:
Well, no. It does because a lot of the things that make something where your runtime actually [ distracts ] nicely, need certain things that are language-dependent like…
Casey:
Well, no. But what I mean is the runtime library is separate from the language. Now, you can say the language is good for making runtime libraries and that’s a totally fair statement.
Jeff:
Yeah.
Casey:
But I would say that just the language that’s good in general is good for libraries but that’s a separate issue altogether. So I’m saying that the fact that there’s a huge runtime library has nothing to do with the quality of the language.
Jeff:
Yeah, it depends. Like, if you’re saying that…
Casey:
Like Python has a massive, great runtime library, apparently, right?
Jeff:
Yeah, that’s true.
Casey:
Everything is in Python. But I’m pretty sure that no one has said that about Python although maybe they have.
Jeff:
Yeah. Anyway…
Casey:
Yeah.
Jeff:
So continue. So yeah, you liked… C is your last big one. The other nice thing about C is that at least you’re gonna be aware of what’s going on because you’re gonna be able to look at the assembly and you’re not gonna be able to look at the assembly with Go.
Casey:
This is what I was saying. So what I was gonna say is C, you know, as a language is designed to sort of hoist up one level from assembly language. And it did a spectacular job at that. It’s not perfect, alright. We need a new one. We could use a new one even of that, right? But whatever. And everything after that has pretty much been garbage in my opinion. It has been things that get some distance along the trying to do shit but it, in no way, approached the degree to which they were able to solve that problem elegantly. It just did even come close.
Jeff:
Yeah.
Casey:
Because there’s so much that you would want to do. Like, let’s say if you were writing a language for writing tools like that, I suspect I would immediately go, “Okay, this is…” Compared to how well C abstracted assembly for me, the readability gains, the ability to share a code with it, to read… You know, basically to write things and leverage the sorts of things that people were doing by hand in such a good way… I suspect that Go is nowhere close to the same leverage game is I guess what I’m saying, that ratchet. But there are ways, I bet you could get that ratchet and I don’t think they got it. So we’ll see. My cursory inspection of Go, which when it first came out, I read when they were sort of explaining it like “here’s what we have”, I was like, “This doesn’t impress me at all.”
Jeff:
Yeah.
Casey:
But, you know…
Jeff:
I would say that the other thing…
Casey:
I haven’t programmed in it. So I have to withhold judgment.
Jeff:
Yeah, I would also say…
Casey:
What am I talking about. I didn’t withhold judgment. I have to withhold final judgment.
Jeff:
Final judgment, yeah. I would also say a big problem with Go is just a lack of really good debuggers. And that’s a big part of being a programmer…
Casey:
Oh, is there?
Jeff:
And being aware…
Casey:
They don’t have that? You can’t just…
Jeff:
It’s just GDB and whatever. I don’t know if they have Visual Studio bindings yet. And I don’t know how well CGDB works…
Casey:
You would think…
Jeff:
With it… I have no idea.
Casey:
You would think that… Although, I guess Google mostly uses… They use Ubuntu, right? That’s the standard…
Jeff:
Yeah, they’re mostly Linux as far as…
Casey:
Okay. So, yeah. So then, they can’t run Visual Studio anyway…
Jeff:
I’m sure they do have some people but they… They go to crazy extents to, like, build other platforms with their server farms. So I know that, by default, it’s a lot…
Casey:
Okay. So anyway…
Jeff:
But yeah, it is hard to… I think it’s hard to become a good programmer, personally, if you don’t spend a little bit of time looking in the debugger, interacting with the code in this way where you’re watching the thing. Very often, you can have code that runs perfectly fine. But you’re really not aware of what it actually is doing until you’ve stepped through manually and actually watch it happen.
Casey:
Yes. So I would agree with that and I think C is a good language to do it in. It’s simple to learn.
Jeff:
Yeah.
Casey:
It’s not a super complex language, right? It’s simple to learn. You can call most operating systems from it now.
Jeff:
Yep.
Casey:
You know, and whatever. And it’s a good language, right?
Jeff:
Yeah. It’ll also focus on, like, you’ll be writing stuff that is… It’s not a great tool for writing fake tools and shipping stuff like… I mean, it’s totally possible but it is slow-going because, like, hey, even doing something like getting a window up in Windows is actually a lot of C code.
Casey:
Right.
Jeff:
But that’s okay. When you’re just trying to…
Casey:
Yeah, because this is an exercise.
Jeff:
We’re talking about the exercise of becoming a better programmer.
Casey:
Yeah.
Jeff:
Like, having to grind through all that stuff…
Casey:
Yes.
Jeff:
And then think about the fact of, “Hmmm… That’s really ugly to create a window. How would I put that into a function to call that would bring up the window that also brought the window up on Mac OS?”
Casey:
Yes, exactly.
Jeff:
Like, “How would I do that?”
Casey:
Yes, right.
Jeff:
It’s a good exercise.
Casey:
So if you don’t already know how to do all these things and you haven’t already gone through these experiences, those are definitely the baselines, like, let’s do that. So you’re getting out of school or whatever and you haven’t had the experiences, go do that stuff. Start. Do it in C. See what the assembly is. Understand what’s going on. Look at the difference between a release and debug assembly. Learn that shit. And do the abstraction layer. Learn how to get that going. Make it clean. Make it nice and perfectly separated…
Jeff:
Right.
Casey:
So you literally have no, in the code… You know, in the shared code in the platforms, there’s no hint of the lower level stuff that’s being abstracted for you. Get all that stuff going. And that’s all good. That’s all kind of day 1 shit. That’s the shit you should kind of just have under control.
Jeff:
Yep.
Casey:
I think as things go forward, I would say there’s a couple things to watch out for. So thing 1 is that your metric should always be what is the efficiency of this code in totality over its lifetime, right? A lot of times, people, you see stuff and… Like, I can remember, like going way, way back… In fact, right before I went to RAD, I definitely had this problem where I didn’t have a good critical filter for what people were saying was good programming, right? Because I don’t think about this at all now. It doesn’t even enter my brain because I’m so past it. I’m so over it, if you will. But there was a time in my life where I definitely had this thing where, you know, you’d read a book on how to program properly, like, “Effective C++” by Scott Myers or something… These books are shit. That book doesn’t have a single tip in there that will make you a better programmer. Not one. But I read those books and was like, “Oh, this is how good programmers program. They fucking put private and they put the [ operator equals ] in there so that people don’t copy back or something, right?” And the thing is, basically, you have to kind of be… You have to be the dude who figures out that the evangelical dude who says like, “You’re healed. Walk now, my child.” Those are fucking [ snake oil ] salesmen. They’re preachers who ask you for $1,000 to send you a prayer cloth. They don’t know anything. They’re just the people who have figured out how to make money selling shit about code. And what you need to do is you need to develop your own critical reasoning skills to look at things that people proffer or say worked well for them or that you should do and figure out, “Would this actually save me programming time? Does this save programming complexity? Will this make my code more efficient in the long run? Will it make my code easier to bug? Will the amount of effort that I need to do this thing meet or exceed the level of debugging?” Because one of the things I see sometimes is they’re like, “Great news, guys. We figured out this new programming technique that makes it so you won’t have this overriding buffer bug,” or whatever. And it turns out that overriding buffer bugs take you 6 hours to debug over the lifetime of your project and this thing takes 7 days over the lifetime of your project doing, right? And a lot of C++ isn’t like this. They spend a shit ton of time up front to save what was a tiny bit of work you would have been doing.
Jeff:
Right.
Casey:
And you’re like, “These don’t add up, guys,” right?
Jeff:
And that might be different if you’re writing stuff that’s like security software or whatever. But if you’re still at the point where you’re thinking about… If you’re writing security software and things like the string cat and string copy are the place where you have a lot of security problems, like, just changing that stuff is not gonna be all that important.
Casey:
Well, I wouldn’t actually say it that way. I just say, like, whatever you’re writing, you know what the requirements are.
Jeff:
Yeah.
Casey:
Right? You know what your objectives are. If you don’t even know what your objectives are, then you need to go back to square 1. You should know what it is. So if this is security essential, whatever it is, right?
Jeff:
Right.
Casey:
And then, you need to go, “What techniques would actually be the most effective to ensure the things that I’m trying to get, right?
Jeff:
Right. If you’re trying to get performance, if you’re trying to get…
Casey:
Whatever it is that you need…
Jeff:
Robustness of if you’re trying to get all those, there could be different trade-offs…
Casey:
Whatever it is that you need… Yes, you need to think about, “How much time will this thing save me that I’m going to do? Will it save me any at all? And is it more likely to increase these things that I want in the end goal?”
Jeff:
Yeah.
Casey:
It’s all a global trade-off. And there’s a couple… There’s some nuanced bits of that. One that I have problems with a lot… And I try to be better about it now but one that I typically have problems with a lot is code mutates over time. And so, when you’re writing code, you need to write in more flexibility at the head end and then the flexibility tails off as you get towards the tail end, right?
Jeff:
Okay.
Casey:
And what I mean by that is it’s tempting times to write code properly for its current use case first.
Jeff:
Yeah.
Casey:
In fact, you do this…
Jeff:
I do this…
Casey:
Way too much.
Jeff:
Yeah.
Casey:
You’re way worse than me but I still am bad.
Jeff:
Yeah.
Casey:
Which is like, “Oh, I see. Okay. I don’t want to do an extra buffer copy here because that will be wasteful. So I’m gonna do it in place and this blablablabla…” And the problem is when you approach a problem and go, “I see what the optimal thing is to do here,” and you do it, then what happens is you spend… You expend this energy which you probably shouldn’t have expended to do it right. But worse than that, later on, you’re gonna find that you have to change that because the requirements or the thing that you thought you were doing changed as you experimented with how you were solving the problem. And now, you’ve wasted time twice, essentially. Whereas if you’ve just done the stupid thing, you would’ve been fine.
Jeff:
Right.
Casey:
It’s under the category of premature optimization is the root of all evil as [inaudible 33:36] said but it’s more than that because it’s not… It doesn’t just apply to optimization. It applies to anything you do in the code. Leaving your code space is important. And it’s not just about optimality. It’s about feature. So if I can do something where I give myself a little more room… This thing needs to be able to scale… “Well, maybe I’ll let it do scale and cropping. Just because I’m gonna do that so that I can just call it and know that I can get that thing to happen.” While you’re in that piece of code, while it’s fresh in your mind, have some awareness about what this thing might be able to do. Do the simple version of the relatively feature-full thing…
Jeff:
Yeah.
Casey:
So that it’s there… As the code matures, you will have it there to lean on instead of doing the bare minimum thing in the most optimal way which will then, you will find yourself constantly having to revisit, expand, un-optimize and re-optimize… And that’s no good.
Jeff:
I guess it’s hard… Yeah, that’s a hard one to describe because I also will say, at least for me, 90% of my bugs are bugs in things that I tried to write before I was using them…
Casey:
Yes.
Jeff:
A feature. Like, write what you need…
Casey:
I see.
Jeff:
It’s important.
Casey:
Yeah.
Jeff:
But don’t be like, “Alright, well, eventually I’m going to need this sort of material here. So I’m just gonna have this here but I’m not gonna use this for a long time.”
Casey:
Okay, yes. That’s true. Yes, that’s a good point.
Jeff:
But that’s a different thing than…
Casey:
I might say… You know, here’s the way to say it.
Jeff:
You’re talking about code flexibility…
Casey:
Yeah.
Jeff:
Not features…
Casey:
Features, yes. It’s true. I [inaudible 35:23] Yes, you’re right.
Jeff:
It’s a different… So it’s a very… It’s related but…
Casey:
So let me say it this way. Here’s a good way to say that thing — “Don’t write the code in the way that makes it harder to add those features that might be added later.”
Jeff:
Yes.
Casey:
So you don’t have to put the feature in but don’t do something in a way that’s going to box off the code at the early stage. When you put the code in, try to do it in the slow but flexible way first so that when you come through later, you will have an easy time morphing it into the thing that it actually needs to do rather than finding yourself needing to keep revisiting it. And that’s just giving the code room to breathe.
Jeff:
Yeah.
Casey:
And that’s important. And I do it better now but I’m still… I could be better even than I am and I know that.
Jeff:
Yeah, that is the hardest thing for me.
Casey:
You are [inaudible 36:11]
Jeff:
That is why…
Casey:
I don’t mind saying it.
Jeff:
There is an extent of complexity of a problem I can tackle.
Casey:
Yeah.
Jeff:
Because I will write that code in what I call in my head the right way, right from the beginning.
Casey:
Yeah.
Jeff:
Which means at each step, if I figure out the “more right way”, you have to go back and revisit that. And so, you end up with this horrible N2 thing where you write up and then you write back down and then you write up and then you write back down. And that affects the size of the things that I can tackle because that is…
Casey:
Yes. Well, your N has to be low. If you’re N2, your N has to be low…
Jeff:
It’s true.
Casey:
Because when it hits the critical point, there’s no turning back.
Jeff:
Yep.
Casey:
There’s no recovery, I should say.
Jeff:
Another thing that people can think about to become a bigger programmer is…
Casey:
A bigger programmer…
Jeff:
A better programmer…
Casey:
Let’s say bigger. I like that.
Jeff:
To be a bigger programmer…
Casey:
Jeff & Casey's Guide to Becoming a Bigger Programmer.
Jeff:
Is be more systematic about the things that you fix. In the terms of, like, “Okay, you have a bug…” And once you have a bug and it’s reproducing, you can fix it. And sometimes, they’re hard. And sometimes, they’re easy. But at the end of the day, they’re not that bad once you have something that reproduces. But try to keep track over a couple months, “What is the thing I keep getting bit by? What are the problems I keep getting bit by?”
Casey:
Yeah, that’s a good idea. That’s a good idea.
Jeff:
And you may be surprised over and over and over again, I do X. And if X is something that is a change that you can do… Sometimes it’s not. Sometimes it is something philosophical or something just about you as a programmer. Like me, I have a very hard time, psychologically, working on stuff that I know is sub-optimal before moving on.
Casey:
Yes, right.
Jeff:
But that limits me but it also, just the psychology, “how I am”…
Casey:
Yes.
Jeff:
So, you may find that out about yourself which is useful information to have.
Casey:
It’s good to know. Even if you can’t change it or don’t change it, it’s good to know what the situation is, right?
Jeff:
Yeah. And sometimes, you’ll be like, “Alright, you know what, every single one of these bugs, at the end of the day, really had to do with this particular trait that I do in my code. Is that something I can fix without much…”
Casey:
And it also might be a case of aligning your priorities.. Like, you do a good job of working on the kinds of problems where that isn’t an issue, right, in some level? It’s like if you know that you have a certain psychological way that you program and you don’t think you’re gonna fix it anytime soon…
Jeff:
Yeah.
Casey:
Can you put yourself in a position where that is not a weakness. There’s nothing wrong with that, right?
Jeff:
That is…
Casey:
Don’t be a linebacker if you’re a quarterback. Don’t be… Like, what’s your body type, right?
Jeff:
Yep, that is what’s the most important thing at RAD is finding those things that people… Where their little superpower is and putting them in that place.
Casey:
So here’s one thing that I will say. Well, okay, there’s a bunch of stuff now, having to try and kind of go back and unpack all of the things, pro-tips or whatever. So there’s a couple things that I would say about coding, looking back. On the bug front that you just talked about, what kind of bugs do you have. So one thing that I’ve said often and that is totally true (and I swear I’m not making this up in any way)… People often ask me why I hate const because I always say I hate const. So sometime around 2001, I stopped putting const in at all. So like, around the Granny 2 time frames…
Jeff:
Yeah, you were a heavy const guy before.
Casey:
So Granny 2 has const at the interface layers because I know people like it but below there…
Jeff:
You don’t want to force people to const.
Casey:
Yeah, below there, I didn’t use it. And in my personal products now, so everything after Granny 2, there is literally no const. Const does not appear in the code base. So people ask me why I don’t use it and it’s like, in that time… So in what will be coming up in 15… A decade and a half, fairly soon here, I have literally had no bugs where I write to memory that was not supposed [ to be written, too ]. Zero. And the point there is just I know myself well enough to know I never make this mistake. It’s just not a mistake I make. And mind you, I have bugs in every… Every time I sit down and run my program, there’s a bug just like everyone else. So it’s not a case of me not making bugs. It’s just that’s not the bug I have ever. Once you know that, then you can stop using things to prevent that bug. If you know you never have bug X, stop writing… Don’t type const if you don’t have to type const. It’s lots of stuff you save, a lot of typing you save by not having that, right? And I think that that’s just sort of a way to reinforce the thing I was saying before about understanding the time and where it goes. If you know that something you’re doing is catching bugs, then you can evaluate how bad were those probably likely to be, like I kind of knew what they were. And how much was the effort to catch them? Like, what was I doing? Was it just typing const? Was it something more elaborate or whatever? And that’s the kind tradeoff you need to make. If you’re the type of programmer who never makes a const mistake in their code, const is a waste of typing for you. So stop doing it. It was completely worthless. If you are shipping code to other people who need const, you put it at the boundary layer. But otherwise, you’re fine. And there’s lots of stuff like that. It’s like, okay…
Jeff:
So the important thing to take away from that is not const… You don’t use const…
Casey:
Right, right.
Jeff:
Because you know… You’ve thought about this critically.
Casey:
Yes.
Jeff:
And for you, it doesn’t make…
Casey:
Exactly.
Jeff:
Yeah. And that’s what people should be thinking. It isn’t necessarily like… In fact, a lot of these programming pearls and programming tips and all these are just like, “Here’s a list of rules to follow…”
Casey:
Right, but…
Jeff:
Which is really not…
Casey:
It depends on the process.
Jeff:
Programming’s not like that.
Casey:
You know it’s not…
Jeff:
It’s psychological and weird…
Casey:
Yeah, yeah.
Jeff:
Like, I do still use const in places, pretty much just for strings…
Casey:
Yeah.
Jeff:
And it’s almost like it’s something for my fingers to do while I’m thinking about what to fill in the function with. It’s like, it feels good in a way.
Casey:
Okay.
Jeff:
And I don’t love… I don’t think it’s ever fixed a bug but it’s part of the psychological part of, like, “What is the way that causes you to type stuff in?”
Casey:
Okay. Yeah.
Jeff:
And there’s lots of things that are just like that but just think about those things, like… I feel like for a lot of people, C++, the reason they use objects and classes there is not necessarily because they like object-orientation or because they necessarily get anything out of the V tables or anything. It’s because it provides them a mental framework to start typing code in.
Casey:
Right, right, right.
Jeff:
Like, “I type class. I type public. And then I do…” It’s like…
Casey:
Yeah, yeah, yeah. Right, right, that’s how it goes.
Jeff:
It’s one of these ways to jumpstart your typing.
Casey:
Yeah.
Jeff:
If that’s what it takes, it’s what it takes. Use what you do and then think about what you’re doing…
Casey:
Well, and…
Jeff:
And artists are better about this than programmers are.
Casey:
Right, they have a process.
Jeff:
Artists are thinking about their process all the time.
Casey:
“How do you do this?” “Well, first I do this and then I do that. And that produces grass that looks good,” or whatever.
Jeff:
Right. And they evaluate after, like, “Eh, I didn’t like the way…” They’re a little bit more fluid than we are.
Casey:
And the other thing that I would say on the flip side of that const thing… So let’s say I was the opposite kind of programmer where I’m always fucking getting it wrong, like I’m always writing to shit that shouldn’t be written to and whatever, that’s my thing.
Jeff:
Yep.
Casey:
Then what I would do is I would literally, my default method of coding would be that I would have mem protect shit going… Like, when I’m building debug, it would… Like, mem-protected out the ass.
Jeff:
Yeah.
Casey:
Like, everything would be getting its own pages. I’d be mem protecting and un-protecting on entries and exits of functions… Like, I would design my programming style around catching this bug because I know that it’s my worst bug.
Jeff:
Right.
Casey:
And I have it all the time and it’s hard to detect, because that would be…
Jeff:
Right.
Casey:
Writing to memory you shouldn’t be writing to but that doesn’t cause… Like, it’s not no pointers. I’m talking about, like, I wasn’t supposed to modify the structure. If, for some reason, that’s a problem you’re having a lot, then you want to structure your coding style around not having that bug. And so, I do stuff like that all the time. Like for example, I do clear to zero a lot which is inefficient. You don’t need to… You shouldn’t be clearing to zero right? But my way that I always code now is everything always gets cleared to zero, period. And if I find that I need speed back, I will go at the end and do just the [ init ] that I need, right?
Jeff:
Right.
Jeff:
And it’s called Jeff R.
Casey:
That’s not what it was.
Jeff:
What?
Casey:
What happened was when we originally were gonna use Perforce, we tried initially going that Jay had done it at [inaudible 57:25] where each person has their own [inaudible 57:28]
Jeff:
Oh, right.
Casey:
So there was a Casey M and a Jeff R and whatever, right?
Jeff:
Yeah, and that…
Casey:
But then it was, like, the fucking Perforce is such a piece of shit that it made that impossible. It’s like, “Fuck it.” [ There’s just one. ]
Jeff:
Right.
Casey:
And then we were like… So I just deleted mine and moved myself to Jeff R. I didn’t do it on purpose. It was just, that was… I was, like, “Well, I’m not gonna be at the company forever. It’s your company. You will.” So I’m like, “It might as well be Jeff R,” so it’s not, 30 years down the road, Casey doesn’t work here anymore and it’s Casey M is the master [inaudible 57:53] I felt I made the logical decision.
Jeff:
Yeah, I get screwed with the master Jeff R which is my name because it started out…
Casey:
That’s your fucking fault.
Jeff:
But it started as this is the C dep master for Jeff.
Casey:
Yes.
Jeff:
And then somewhere along the line, everybody’s using it.
Casey:
But that is your fucking fault.
Jeff:
No, it is.
Casey:
That’s [ your fault ]. We don’t need to bring the listeners into that. They don’t need to know master Jeff R. C dep and master Jeff R…
Jeff:
Is best forgotten.
Casey:
If you had to go, like… When you and I go up to programmer heaven and we’re at the gates and they’re deciding whether to let you in, all the rest of the shit that we may have done right, that’s not gonna be what’s focused on. They’re gonna bring up C dep…
Jeff:
“Let’s talk about C dep.”
Casey:
And they’re gonna be like, “What is this?” And I’m gonna be like, “It’s his fault.” And you’re gonna be, like, pointing at me and going, “It’s his fault.” And they’re gonna send both of us down to programmer hell. That is true.
Jeff:
Yeah.
Casey:
Anyway, so moving on… Yeah, so I think those are generally the case. And I would say that that probably extends to code to a large extent, as well, which is there is an overhead. Code, in some sense, when you think about code, code is definitely a language. And I think it occupies language skills sorts of parts of your brain. Like, it’s a lot of words and things and semantics. And these semantics are fluid in the fact that they’re constantly getting redefined. And what I mean by that is if you look at what you do on a daily basis, when you’re moving into a new code area, you’re gonna write this thing, gonna write this image loader or whatever the fuck, what you are doing when you design an API and when you functionally decompose that space, when you make the code and you make the thing, you are essentially coming up with a new set of semantics for that thing. How do I say I want to load the image? What comes back from that? What do I then… What can I pass that to? What is the grammar of this new thing that I’ve made? It is all very linguistic in that way. There are things that do and don’t sound right. And some of them are not rigid. It’s not science. It’s a very fluid thing that’s much more like language going on there, I think. And I feel like what happens a lot there is very much like, “Oh, you know, I was in Britain for a few weeks and I kind of picked up a little bit of an accent.” Like, there’s this sort of thing that happens which is when you are working on the particular piece of code, your brain is warm to that semantics, those rules, how things work in there, how the code works… You are familiar with a lot of what the functions actually do at a low level. You have a lot of ability to make quick progress without making mistakes. And when you go work on some other piece of code for a few months, that becomes more stale. Now, if you’re a good programmer, I think most good programmers, it doesn’t become too stale. It’s not like you’re gonna go back there and go, “I have no idea how this thing works. I don’t know what I’m looking at,” because usually, your style is very consistent and you did things… You know, good programmers tend to be very meticulous and repetitive about how they structure things. So your brain always has this bit of information that’s how I structure things. And when you come back, you will see and you’ll go, “Oh, okay. This probably worked like this. This probably worked like that because that’s the way I would’ve written it, blablabla…” But there’s some things you will forget. You are not as ready to speak that language fluently. You’re a little bit hindered from when you were at your peak.
Jeff:
Yep.
Casey:
And so, the thing that I want to emphasize there is sometimes, you have to respect the tradeoff. I think if John Blow were here and he had the third microphone, he would say something like, “Always do the simplest thing,” or “Always do the minimal thing and move on.” And what I would say is I take the position a little further down than that. I think that there is a cost to always doing the simplest thing and moving on and revisiting later when you need to go. And the reason for that is because there is this paging in cost that, because it takes time to get back up to the same level of fluency with any particularly piece of code that has any level of complexity, you will introduce more bugs. You will be slower at doing what you’re doing. You will end up rewriting something that didn’t need to be written because you didn’t realize there was an easier way to do it because you weren’t [ all paged in ]. And so, I think that when I look over my history in programming, I think there are definitely a number of times when I did that lazy evaluation process, which is a good idea (you don’t want to over-engineer) but a lot of times, I feel like if I’d just gone, “No, okay. This is a pretty core thing. Let’s do it right and hard right here and get it so that this is bulletproof. Slap [ our aggression ] test on there. Make this a pretty solid thing,” as if I were shipping it as an STK. Make that call. And so, I guess what I would say is as you get to be a better programmer, I don’t think you want to fall rigidly into one or the other camps there. I think you want to think about it. That’s, I guess, why I said [inaudible 63:09] on that but maybe I wouldn’t. I don’t know. I won’t speak for him. But I know he said this publicly and stuff. My opinion on that is you want to make judgment calls. You want to get good at making judgment calls about when is the most efficient time to do work because if I can say, “I’m gonna spend another week on this thing and really get it solid and good as a real thing,” that’s oftentimes a good idea. So don’t let the fact that lazy evaluation of code… You know, just in time code, that that is a generally pretty good idea. Don’t let that dominate the thinking because it goes both ways. And you, I think, are actually the person who taught me this. We had this discussion before where you’re like, “You should do it right when you know you need something. Do it right. Take the extra time to do it right because it will pay back.” And it does. And so, learning to make that judgment call…
Jeff:
It’s also just so cheap, generally, to do it when it’s fresh.
Casey:
Right there, yes. And that’s the key. That is the key observation is that no matter who I’ve ever seen, programmer-wise, even if they don’t think so, I’ve never seen someone who really is as good 6 months after the fact as they were that day. I don’t really believe… Maybe there’s an idiot savant out there who’s like, “No, all the code is in my head, man,” and that’s true. But for 99% of the programmers out there, they are worse 6 months down the road at modifying the code.
Jeff:
Well, it’s a psychological thing, I think, a little bit, too. And again, maybe someone’s psychology is different but it’s like, there’s something very satisfying to finishing something with all the corners sanded off, nice and finished, and then moving on…
Casey:
Yeah.
Jeff:
Than walking away, knowing you’re gonna have to come back to this. So part of that is psychological (at least for me) of like, this feels, “Yes, I’m less efficient.” Sometimes I don’t use the code again but I feel better. And how you feel has a big impact on how effective you are.
Casey:
Oh, absolutely.
Jeff:
Like, if you know… That’s the bigger cost of shitty code than bugs, than anything else is like…
Casey:
And if you’re constantly walking on jank… Walking on jank all the time definitely has a psychological cost, as well, because even if somehow the total time cost didn’t work out to be different, the not having to constantly stop and revisit a piece of code to fix a bug in it or add a thing that you didn’t do, that just in time interruption definitely has a psychological toll, I think, probably to it for different people.
Jeff:
Yeah.
Casey:
And so, assessing that is also a part of that problem. So being aware of that, I think, is probably a pretty good idea. And I think… I say the linguistic thing and I really do mean it on some level because I don’t know if anyone…
Jeff:
That’s an interesting way to think about it because I think about…
Casey:
I don’t know if anyone’s ever had this but… I’ll give you a concrete example.
Jeff:
Yeah.
Casey:
But you can keep going if you want to say something.
Jeff:
No, no, go.
Casey:
So, I’ll give you a concrete example, and I’m hoping this will resonate with some people. I think it will. So when I come back to a piece of code… And you have to internalize this in your head. So I write a lot of code. There’s a file that says… It might be a 5,000 lines code, right? That’s one of multiple files in a system, potentially, that I’m working with, right? So we have tens of thousands of lines of code that are relevant to maybe something that you’re doing. When you come back to that, you can tell not just in a theoretical sense but in a practical sense, it would take hours for you to even read it all.
Jeff:
Yeah. Right.
Casey:
Okay? So just stating the obvious, you’re not gonna read 6 articles, 6 magazine articles worth of text, in 15 minutes. It’s not gonna happen, right? And so, what I feel like sometimes, I’ll come back to code I haven’t seen in quite some time. And I look at the file. And what I realize is it’s like gibberish on the page, that first second. I don’t know… If you think about this, try it sometime. Go back to a code you wrote a year ago or something. Open it up. It’s like gibberish on the page. You look at it and it’s almost like… My brain’s like, “I don’t even know what I’m looking at on some level,” right? Work with the code for a few hours and, all of sudden, it’s like you know everything… You just know everything that’s in there. It’s like there are thousands of lines you aren’t even seeing and you know… You even have a sense in your brain, or at least I do, that they’re there even though they’re off the screen. And…
Jeff:
Well, that…
Casey:
You know what I mean? It’s like there really is, I feel like, a very… It’s like coming back to a book again. And there really is this thing about your brain really does generate this whole model of the thing that doesn’t persist. It doesn’t persist fully. And you come back to something and it’s cold. And it really is just a bunch of text on a page that you can’t read very quickly. And then when you get back to it, you’re not You think you’re looking at your code. You’re not reading your code. You knew the code already. You are seeing little bits of it and your brain is immediately knowing what that for loop does. It didn’t read every bit of the for loop. It just knew what the fucking for loop did. And that’s… It’s important to appreciate that because if you don’t stop and think about that, you may think that really what you’re doing is just looking at the code. And I could look at this code now or look at it later and I’m still looking at the for loop. It’s like, “No.” One time, you were looking at the literal symbols on the page, parsing them, figuring out what they meant, building a model of it. And the other time, a day later, 2 days later, whatever it is, after working with this code for some time, you just fucking know. And your brain accessed the thing that’s like that for loop and you knew everything it did, right?
Jeff:
Right.
Casey:
At least if you’re a good programmer, you did. That’s how I feel. I don’t know. Maybe you don’t have that feeling. That’s the feeling I have.
Jeff:
I don’t know. For me, the way… I don’t know if I use the same part of my brain. Part of my brain I feel is more spatial, like the shape of the code, the way the code is whether it’s dense or light or…
Casey:
Yeah.
Jeff:
It’s very simple stuff, so there’s not very many columns and huge runs of that and then that. That part stays fairly strong with me for a long time, that feeling of it. So when I see things… When I’ve lost that, I have a much harder time. Then it’s like, really slow-going until I get really used to it again and then we’re… Yeah. I mean… Yeah. But…
Casey:
I guess another way to say it was intuition or something like it plays a much bigger role in your code-writing than I think people appreciate in the sense that I didn’t sit down and go, “Okay, an octree is a thing that splits space into 8 subdivisions and this is a recursive function that recourses through the octree and it gets down to this level and it does blablabla… And so, I’m going to put the thing that inserts an entity into its free list here because it will have these implications. That’s not what actually happened. What happened is my brain has completely fucking internalized the octree code, the whole goddamn thing. And when I thought “insert an entity”, I immediately thought of where that goes.
Jeff:
I see.
Casey:
Right? And it was not a cognitive process. In a year, it will be a cognitive process. I’ll go, “What the fuck is this function? Okay, block update entity, what is that doing? Okay, there’s an octree here. Okay, here are the split plains,” right? So the modifying of that octree after the weeks that I wrote it… In the week that I wrote it, it’s all just… It’s instant. It’s like I just know where everything goes and what everything does. And I don’t have to think about it, right? Whereas after that’s not the thing I’ve been working on for several months and I’ve had no interaction with the code, when I come back there, yeah, I still know how a fucking octree works. I may even know how I wrote this octree but I don’t just immediately know. And like you said, it’s almost spatial. It’s like, “That’s right here in the file.” I could fucking point to it if you gave me a big listing on the wall. I’d be like, “It’s over here.” Right? And it’s that brain, that huge acceleration, neural structure, that you built in your brain that it doesn’t stay intact. It goes away a little bit at least for me, you know.
Jeff:
Well, I also find that for me, I’m constantly mapping what I’m doing on to my set of shapes. Like, this is one of those…
Casey:
Yeah, yeah. Yeah.
Casey:
Because I find there’s a lot less bugs if everything’s always zero because you know the thing runs the same at all times. And in fact, there’s data… There’s good backup data that this is a common problem, too, because a lot of studies have been shown across large [ code bases ]. Microsoft Word had one, I think, where they’re just like, “Uninitialized variables is a massive source of bugs.” I’m like, “You know what, we can limit that right now. Done.” The system always returns zero at memory. All members are required to be zero at the store.
Jeff:
The stack’s hard.
Casey:
What?
Jeff:
The stack’s shitty. I still get…
Casey:
You do have problems, that’s true. You do have the stack problem. Fortunately for that, that one I don’t ever really have…
Jeff:
Yeah.
Casey:
Because I use declare anywhere, you don’t, which I guess is harder. But I use declare anyway. So I just have every variable has to get a value on the line.
Jeff:
Okay.
Casey:
So in some sense, I still do just clear to zero. If for some reason, I was programming in your style where I can’t use declare anywhere, I’d set them all to zero right there.
Jeff:
Yeah.
Casey:
I’d be like, when I do [ In X ], I’d be = zero.
Jeff:
No, no, no. Yeah, yeah. If you can do… Yeah, yeah.
Casey:
Even though the variable’s initial value isn’t zero, right?
Jeff:
It’s just not enforced is the reason. And when things aren’t enforced, at least for me, I find that it’s hard to…
Casey:
Yeah. But I don’t find that that’s as big of a problem for me. I find that if I do have un-init problems, they’re usually…
Jeff:
Un-init…
Casey:
On stuff that came back… On heavier-weight stuff that came back. I heap stuff. So I just say that shit gets cleared.
Jeff:
I don’t super have a lot of init issues, personally.
Casey:
Yeah.
Jeff:
That’s not usually the one… I have really… I have stuff all the time where you’re like, this code path does do an init and this other one didn’t.
Casey:
Okay.
Jeff:
And now you’re like…
Casey:
“Oops.”
Jeff:
All of a sudden, “Why is this…”
Casey:
“What the fuck?” Yeah.
Jeff:
That happens all the time but that…
Casey:
Yeah.
Jeff:
Init doesn’t usually help that.
Casey:
So, yeah, so I’m fine with that. Like, I just was using that as an illustration that it’s not like I’m like, “Oh, you’ve got to get rid of everything.” It’s like, “No, no. I just… I know what kinds of bugs that I have in common with everyone else. I know which kinds I don’t.” And so, I protect against the ones that I do and I don’t protect against the ones that I don’t because your brain works in a certain way and there’s bugs that you’re just not likely to have. And there’s other bugs that you are. And so, you might as well focus on those.
Jeff:
There’s another good thing that people can do, I think, that is useful in terms of getting better, too. And that is when you work with somebody else on the project, when you’re working on their stuff, follow their style. Just don’t… Like, hey, if you’re in here and you’re on this project, just go do… Like, when you edit their files, use everything the same way. Try to use their case. Try to use their weird way of doing it. Just get used… Just do that. Not for because it’ll… Not because it’s better and not even necessarily because you’ll learn something from it…
Casey:
Yeah.
Jeff:
But keeping the flexibility of, like, “This is why… I know why my style is better.”
Casey:
Okay.
Jeff:
Like, this is… Normally, when you’re looking at your own code, it’s very hard to analyze, like, “Why is this code sucky? Like, I wrote this. I know exactly how this works. It’s a set of if’s.”
Casey:
Okay.
Jeff:
“It’s very… I can think about it. I don’t have to analyze it in a way. I just… Because it’s all right there, it’s in my personal flavor.”
Casey:
I’m not sure I follow you.
Jeff:
What’s a better way to say it?
Casey:
I don’t know. If I could, I would say it for you.
Jeff:
I’d say I feel like it’s harder to be critical on code that you have written yourself versus code that other people have written.
Casey:
Okay.
Jeff:
When you look at somebody else’s code, it’s very easy to go, “Here’s where I think my mind is ambiguous, on why is this after this? Why do you do this check here and then do this other piece of code here when this piece of code really belongs with this one? Why is this clause in the middle of this?”
Casey:
Okay. Alright.
Jeff:
And you’re like, “Well, that really should be up there with the other thing.”
Casey:
Okay.
Jeff:
I think that in your own code, it’s very hard to see those kinds of, like, “When I’m reading this code, where does my mind become confused about what’s happening?”
Casey:
Okay.
Jeff:
Because you wrote. That’s still kind of pre-warmed in your head of like, “Of course, that’s just this.” Whereas as soon as somebody else looks at it, they’re like, “Wait a second, why do we initialize this variable here and not up here?” And you’re like, “Well, because we didn’t need it ‘til then,” like that kind of thing. And so, it can be useful to write in somebody else’s style just because you either maybe will learn something… It’s not my experience that you do. But you will become… You’ll get better at looking at code critically beyond just “does this code work or not”. You’ll get used to looking at code for things that are, like, aesthetics like, “This is a cleaner way to look at it. This is a nicer way to do it.” And I think that following somebody else’s style is a good way to become better at that.
Casey:
So I’m just gonna let that one stay because I have no idea what you’re talking about but maybe the listeners do. And so, they can take that to heart and I will just pretend it never happened.
Jeff:
Well, you might be really good at… You might just be good at looking at your own code and being critical about it. I find that when I write code…
Casey:
I don’t understand what that’s… But I’m saying I’m letting it skate. Let’s let that slide because I think it’s not gonna resonate with me but let’s let it resonate with anyone who it happens to resonate with.
Jeff:
Right.
Casey:
And we’ll leave it at that.
Jeff:
What I’m saying is you should write all your variables with all your variables for a week using one letter.
Casey:
Yeah, you’re all about the one-letter variable names, that’s true.
Jeff:
Yep.
Casey:
So what I would say, moving on, if we could just pass over that… Just thinking about some things maybe more on the advanced side of shit… So when I think about stuff that’s gone poorly, bad situations… So one thing that definitely has happened to me multiple times is… I guess I would… So I would phrase the nugget (the cautionary tale, if you will), is always or rather there probably is a net win, overall, to treating all of your code as if it is shipping to a customer instead of just the actual code that it’s shipping to the customer.
Jeff:
Yep.
Casey:
And the reason that I say that…
Jeff:
You [ shouldn’t have ] [inaudible 51:28] I 100% agree with that.
Casey:
So I’ll be a little more specific here. So one thing that happened to me many times around, and in some sense the injury is ongoing, is that I would write a tool for my project that I just like…
Jeff:
For your purpose…
Casey:
Whatever gets shit into this thing is fine because I’m just trying to have this thing work for doing my thing.
Jeff:
Yeah.
Casey:
So it can be the ugliest, nastiest, fucked up, barely running thing. And that’s fine because this is not going out the door. I think I’ve done that 4 times at RAD and 3 of them are still in use on most of the project because they got disseminated, repurposed, fucked in the ass by new code that other people wrote. They are bolted together like a Frankenstein monster at this point because they weren’t running well when I was using them because they only barely worked. And now, they’re that, plus other people’s shit code. It’s like, some of those are just nightmares. And they have probably caused a fantastic amount of money’s worth of time if I had stopped and gone, “Okay, you know, having…” In hindsight, looking back… Because all of them, I wrote when RAD was 3 people, really.
Jeff:
Yep.
Casey:
So I don’t blame myself too hard for this but if I could go back, I’d go, “Hold on. These things always take on a life of their own.”
Jeff:
Yep.
Casey:
Things always take on a life of their own. Things get re-used way more than you think they will. And the fact that they’re shitty is not a reason why they won’t get re-used because you have to think, “Why are they shitty? They’re shitty because I had something better to do and I just wrote what I had to do.” Everyone else will be in the same position and they’ll go, “I could just take this thing that someone else shit out and save myself the time of shitting it out.” They will then use it and add their shit to it. So if instead you look at it and go, “Alright, if I’m gonna make the first tool at my company or in my space or whatever that does this thing, I should just stop and go, ‘Let’s do reasonable software engineering. Take a little more time, it’s not that much that it will take,’ because the amount of time you will spend debugging and that other people will spend debugging and that other people will lose because the tool is shitty over the next 10 to 20 fucking years…” It’s been 15 years at this point for some of those tools.
Jeff:
Yeah. I run tools that…
Casey:
You will save so much time.
Jeff:
Yeah. I still… I have…
Casey:
You run tools that I wrote in 1999.
Jeff:
I have a lot of tools that I wrote that I use when I used to program in Turbo Pascal.
Casey:
Scary.
Jeff:
Yeah. So I still use a lot of that stuff.
Casey:
Yeah.
Jeff:
I very much resist that kind of change. And it’s usually because I’m too busy not to. I’m like, “Ah, fuck.” And it’s that small thing where you take that, like 5% hit forever. And you go, “Wait a minute, in retrospect, I’m burning all this time.”
Casey:
Yeah.
Jeff:
But it’s way easier to burn 5% of the time over a long period of time than losing 100%, like when we have to do… Because you get into these situations, especially when you have things that live for decades.
Casey:
Yeah.
Jeff:
Where switching is almost impossible, where you’re like… Everything would have to grind to an entire stop.
Casey:
Right, we’d have no idea what’s going on. Yeah.
Jeff:
To a halt for a month. When are we gonna all be at a point where I can burn… That’s the get thing from Perforce, I’ve been meaning to switch forever.
Casey:
Right, but everything’s Perforced up.
Jeff:
Well, I mean, the more practical problem is at what point can I shut everybody down for 3 days or 4 days or whatever, 5 days a week…
Casey:
Right.
Jeff:
Whatever it takes to move over. It’s like, the answer is none. We’re never at that time. So, like, eventually we’ll do it.
Casey:
Right.
Jeff:
But when you have your own control of that, I’d say that’s very good advice.
Casey:
So I will…
Jeff:
Assume that…
Casey:
I have a meta piece of advice, as well.
Jeff:
Yeah. Try not to write stuff that’s in tool mode versus customer.
Casey:
Yeah, it’s like, don’t do it. You know, and I don’t learn. I didn’t learn
Jeff:
You know what your customers might be inside or outside of the company but they’re still customers.
Casey:
Yep.
Jeff:
And you might as well do it right, yeah, ‘cos you’ll be surprised.
Casey:
And I don’t learn the lesson. I should’ve learned the lesson. I didn’t really learn the lesson. I’m telling you now. Maybe you are younger. You will learn out there, having this piece of advice from me, you will be able to internalize it earlier and not have a pattern of these mistakes which I would say that I have had. And you can avoid that. And so, that would be potentially a good thing. I would also say, as a meta piece of advice, one thing that I always did on all of my internal tools is they’re prefixed with my name. So there’s…
Jeff:
So you get blamed for it forever and ever.
Casey:
That’s what I was gonna say. Don’t do that. I’d always named them… There was, like, crappy cases, [ re-targetable ] API, that one… Don’t say that. Just make it rappy. Make it [ re-targetable ] API. Get the “Casey” out of there.
Jeff:
No, get the “Casey” in there so you can call him up.
Casey:
[ C dep, ] Casey’s dependency, generate… Don’t… No, it’s just “dep” now, right? Take the C off the front of your tool because then, when someone’s like, “What is this garbage?” “I think Jeff wrote that,” right? I can… There’s a plausible deniability that happens. And now, the other thing you can do if you want to take it to the next level… And I don’t know that you do but if you do…
Jeff:
Put somebody else’s name.
Casey:
Put somebody else’s name.
Jeff:
Oh, that’s awesome.
Casey:
Right, I could’ve called them [inaudible 56:51] and then it’s like, “Whose fault is this fucking pile of shit that we have to use?” And I’m like, “Jeff wrote that, I think. It says right there on the front. On the byline, it says Jeff.”
Jeff:
That’s even…
Casey:
That’s what I should’ve done. I didn’t think of it.
Jeff:
You sort of did do it with Perforce. Do you remember why?
Casey:
Yes, but it wasn’t an accident. It wasn’t volitional. I should’ve done it volitionally.
Jeff:
The initial depo was RAD but we didn’t like the layout and I was like, “This sucks,” and you’re like, “Let me make a new depo…”
Casey:
No, no. That’s not what it was.
Jeff:
And if I have that to hang on, then I usually have a good way to get started in getting it to work.
Casey:
Yeah.
Jeff:
But, yeah. That could be completely personal but… Yeah.
Casey:
Yeah. Well, I tend to work on larger code bases. So…
Jeff:
You’re also doing… You tend to also work on a lot of different things where I tend to refine…
Casey:
Yes. So that’s why I do tend to lean on semantics a little bit harder because I need a lot of names to sort things through.
Jeff:
Yes.
Casey:
Whereas if you know you know you have a lot lesser names and a lot more operational stuff going on inside those fewer names then you’d… You know…
Jeff:
Yeah.
Casey:
Then you’re talking more about the bodies of functions and less about the functions. And at that point, you tend to be more spatial because there is no name for a line of code.
Jeff:
Right.
Casey:
They’re just a line of code. [ They don’t have a name… Well, ] unless you’re one of the people who puts a label on every line.
Jeff:
Right.
Casey:
There is no name for a line of code. So at that point, you are definitely spatial. And I’m not way too inside the code. I can see it. It’s like, “Oh, here’s the lines that do the thing.” You just… Your brain immediately goes that’s what it is. So I do it. It’s absolutely a spatial thing. But then sometimes, as you get bigger and bigger, you know, semantic… You know, you’ve got to start being linguistic about that sort of thing, as well. But, you know…
Jeff:
Yep, yep, yep…
Casey:
Either way…
Jeff:
Yeah.
Casey:
So, I don’t know. I’m trying to think of other things that maybe we haven’t touch on, coding things that people… You know, if I have to say right now, I feel like… This is why I think… I was talking about this on the previous podcast. I feel like right now, the reason that I emphasize the tools and the language problems a lot is because I feel like at this point, I can identify a lot of things that I do poorly, day to day, when I code. And I realistically just don’t think they’re going to get any better without tools… Like, I feel like I’ve made the tradeoffs I can make with the languages and tools that I had. And the problems, you know, when I hand something off to someone, I’m like, “Yeah, I know why this was shitty,” or, “I know what the problems are with this and I just didn’t feel like it would be an efficient use of my time to have done this better.” Like, I feel like I’ve made good decisions about the tradeoffs of time versus what was going on given the constraints I had.
Jeff:
Right.
Casey:
And that includes experimentation. Like, sometimes, I build experimentation into the project which means [ it’s not… It could’ve ] been if I didn’t experiment with new system X, right?
Jeff:
Right.
Casey:
So all of that is true. But in general, I feel like, “Nope.” It’s like I pretty much handed out something that was the most efficient I could’ve done in this time period but there’s all these fucking problems with it that I can immediately identify. So I am very far from being able to hand something off and go, “No, I think it’s all done right.”
Jeff:
Right.
Casey:
Right? And you know, with Granny, I hit some more higher levels with that because I worked on it for many years and it kept getting refined and refined. So I can say like, “Yeah, there’s a lot of parts of this that I think are done really right or something like that,” whereas things where I did for a month or two, it’s like, “No,” you know, they didn’t have that kind of refinement or whatever.
Jeff:
Right.
Casey:
But on the whole, I’d say my day to day programming has gotten pretty efficient in terms of the tradeoffs. But the problem is its only gotten efficient in terms of the tradeoffs, right?
Jeff:
Right.
Casey:
It’s like, my code didn’t get all that great. My tradeoff balancing I think got great. Like, if you had to say, you know, what makes a great programmer these days, it’s not the fact that the code was great. The code’s better maybe than a non-great programmer’s code but it’s better because they made the tradeoffs right. They did the tradeoffs as good as they could. And what I’m more interested in now at looking at and going… It’s like, well, most programmers I know would probably say the same thing. They wouldn’t be like, “Oh, yeah. You know, I shipped this game and whatever, I shipped this thing. And man, the code is so good. There’s nothing I could’ve fixed about it.” Nobody says that. No one’s gonna say that to me. They maybe have certain parts that they’re like, “Yeah, really, I spent some time and it’s really great. This one part’s really great.” The rest they’re gonna be like, “Nah, it’s fucked up. I could’ve made this better. I could’ve done this. This part’s slow. This part’s sloppy,” whatever, just like I’m gonna say about whatever thing I do. And so what interests me more, going forward, is like, “Hey, what can we do to start eating away at that part? What can we do that’s like… What can we do that starts allowing programmers who have hit the wall in terms of the tradeoff efficiency?” So we know these people could take 10 years to write this piece of code that you wrote in 2 months. What have you got for me, right? We know that they would end up with something better than the 2-month job. How do we close that? And I talked about that a lot last time. And I think that that really is the main thing we need to start focusing on in terms of improving stuff because I would like to stop having to be all about the tradeoffs and all about giving advice like on this where it’s like, making better tradeoffs instead of saying, “Make this pristine code,” because honestly, the truth is, you’re never gonna make that. And if you do, if you are shipping pristine code fairly routinely, it probably means you’re not getting that much code done is the problem. You’re making that sacrifice. And I feel like maybe…
Jeff:
Or your domain is so fucking small and…
Casey:
That’s what I mean. You’re not getting a large body of work done that you could’ve been getting done if you accepted something else. You’re not making the efficiency tradeoffs, perhaps, in the most effective place. And so, what I’m interested in mostly when we look at code things is figuring out how do we get past that barrier that I feel like a lot of programmers hit eventually. It’s after a long time but they hit eventually because I think that will make it better all throughout the process, having the tools that allow you to do that. But I don’t see, unfortunately, I really just don’t see anybody making any progress in that area. So I feel like it’s gonna be one of those thing where some bunch of really production-oriented programmers are gonna have to stop for a few years and go, “We are going to really try to solve this problem.” And it’s not some fucking random conscious research fellow somewhere who shits out a new interpreter or like a web dude who makes another Dollar sign-oriented programming language or whatever. It’s gotta be people who are like, “We’ve been in the trenches. We know what the problems are. How do we start leveraging up the efficiency of these things so we’re not making so many tradeoff decisions every day and we’re just doing the right thing every day? How do we get there?”
Jeff:
Right. Right, right.
Casey:
Because I said before, I think there’s a lot of good programmers in the game industry anyway. And I think a lot of them know how to write code that’s better than what they’re writing. And I’m interested…
Jeff:
There’s just no way to do it.
Casey:
I’m interested in looking at how do we give them the ability to write the code they know is good. And I think there’s a lot of things baked in there, like a lot of rapid iteration stuff, a lot of reused stuff that we could do that makes it so that when you sit down to do this algorithm, you can quickly experiment with what you believe is the right thing to do rather than going, “Oh, alright. If I write a fucking thing to do that, it’s gonna take a week for me to get that working and blabla…” And…
Jeff:
Well, also…
Casey:
You know, I’m getting out of that space.
Jeff:
Yeah. And also thinking about things like, “Oh, hey, when I’m writing this, I’m thinking about it and not the writing of it,” right?
Casey:
Yes, exactly.
Jeff:
Which is always how programming is right now…
Casey:
Yeah.
Jeff:
Which is very rare… Like, you’re not… What programming is…
Casey:
Yes.
Jeff:
At least at this stage, is not describing the constraints.
Casey:
Right, yes.
Jeff:
It’s usually like, figuring out how to describe those constraints in the language which is weird, which is different…
Casey:
I would actually say it’s worse than that. I would say it’s a little bit worse than what you’re saying because when you’re a novice programmer, it is exactly what you said. But when you’re actually an expert programmer, I would say that the problem is it’s not even figuring out anymore. You already know… Like, it’s not figuring it out. It’s doing it. It’s like, “Yeah, you know how to sit down and get A Star implemented,” or whatever. But it’s gonna be a fucking annoying ass thing to do.
Jeff:
Right.
Casey:
It’s like, it wasn’t figuring out. It was just the time that happened. And it was a lot of cruft work. And basically, you’re constantly… You’re caught between 2 really bad options like option 1 is you use a “higher level language” that’s slow as fuck and doesn’t debug properly and has all these drawbacks and whatever and still isn’t fucking high level which is awesome… Like, you go up there to supposedly high level and it’s still not fucking high level.
Jeff:
Right.
Casey:
Which is amazing. But that happens. You’re like, “Oh, I’m gonna write in Python.” It’s fucking still low level, basically.
Jeff:
Right.
Casey:
Right? So it’s higher level but it’s not high level, I would argue. So you can do that and have a piece of shit at the end. But at least, maybe the iteration time is faster if you assume that the debugging worked at all. Maybe it’s actually worse because the debugging’s worse. Or you go low level and you have to write a bunch of manhandle-y shit but at least the debugger works well and the thing you get at the end will be performance so you can judge the speed aspects of it accurately and see what the machines are doing. Both of those are bad options. What you wanted was the high level thing that’s efficient. That’s what you wanted and you couldn’t get that. And so, it’s interesting to go… How do we start looking at really “let’s talk about coding” not as a set of those tradeoffs but rather as a “what is the real optimal thing”? You know…
Jeff:
Yeah, even separately… Yeah. Yeah. Yeah, yeah… No, I agree with that.
Casey:
Yeah.
Jeff:
It’s weird how much the time, when you’re given a task to do… Most people have been programming for a long time. If you say, “This is what we need to do,” it’s not writing that that’s hard. It’s like, the 2 stages of, “Well, how am I gonna do that in this language I use?”
Casey:
Yeah.
Jeff:
And then, B, “How do I do that in the language that I use that other people can use it?” Like…
Casey:
Right, the abstracting it to a reasonable thing…
Jeff:
Well, where are they gonna get the memory? Like, if you write it for yourself and just allocate the memory all over and like, fuck it… And then you’re like, “Well, no, I have to do this thing so it can be used.” And then you’re like, “Well, that kind of ties in to the OS level,” and so now you end up with this thing where what you had originally off of it, there’s a very generic thing that has nothing to do with the OS. All of a sudden now, you’re thinking about, like, how the OS does its backing stores. And you’re like, “How did I get there?”
Casey:
Yeah. [inaudible 81:52]
Jeff:
Yeah, you’re like, “Oh…”
Casey:
And yeah, and you end up in that… Like, that’s the classic thing, right? And you’re like, “Oh, well, okay. So we’ll use a language [inaudible 81:59]” or something like that. And now, you’re in this situation where you’re like, “Oh, you ship it to someone and they had to use it on the PS2 and there was no memory and so, they had to pull that part out.” And now, you have to actually go back and… It’s like, it always comes… Like, everything comes around in both ways. No matter which road you pick, you’ll end up in trouble. And the reason that I pretty much always write things in C ends up being just because that’s the route that I found to be less hassle, actually, at the end of the day. But it’s always a tradeoff. I would much rather be able to do high level stuff in a way that I could push down and get the efficiency that I need. But you know, that’s not realistic, right? So… Oh, well….
Jeff:
Yep, yep, yep.
Casey:
Life goes on.
Jeff:
Well…
Casey:
Any other [inaudible 82:42] before we wrap it up…
Jeff:
How are we gonna summarize this?
Casey:
Well, I think this is a… It was a discussion about…
Jeff:
Somewhere…
Casey:
I think we listed a number of things that [inaudible 82:49]
Jeff:
There’s no lists in terms of… There’s no magic bullets. There’s thinking about the code you write.
Casey:
Yeah.
Jeff:
Thinking about, “Hey, I got nothing done today. Why was that?” Was it, “Oh, I didn’t really want to do it”? Why did you not want to do it? Is it hard? Or is it because you know you’re gonna be touching old code? Just thinking about… Analyzing the way you work and doing that is probably the best way to get better. You’re gonna think about… Even if you don’t figure it out, just thinking about it… And not in, like, a “I’m gonna feel guilty about ‘I didn’t get anything done today’”.
Casey:
Yeah.
Jeff:
Don’t look at it like that. Like, “Why didn’t I?” You really didn’t want to write this? Why is that? What about this problem is bad? And that’s not to fix that problem. It’s just to be thinking about getting used to analyzing the way you do things and then figuring out… You’ll find out a lot about how you actually work that way, I think.
Casey:
Yeah.
Jeff:
Yeah. Anyway… Alright, no, I got nothing else, I don’t think.
Casey:
No…
Jeff:
I mean, I’m sure there’s a hundred things I’ll think of… We did this on the fly but…
Casey:
That’s true.
Jeff:
Yeah.
Casey:
I guess we could also say as sort of a semi-reference… So I’ll also point out that reevaluating how you’re doing things frequently is definitely also important in a sense. For example, I used to use a lot of C++ before I came to RAD. And at some point during the end of Granny 1 and when I started Granny 2… I’m not sure why I decided to do it but I think it was just having the fact that people at RAD were more C-ish. And you were definitely… You were like a straight C dude. I mean, you didn’t even compile in CPP.
Jeff:
Yeah.
Casey:
Right?
Jeff:
Yeah, still don’t. You use CPP’s when you have declare anywhere.
Casey:
Yeah, I use CPP’s for a couple of things. I use declare anywhere and I also will sometimes use constructor destructor for automatic, like, profile counters and shit like that that do [ in and outs ]. So I would use a few features now and again but I just don’t ever really use any C++ “design patterns”.
Jeff:
Yeah.
Casey:
You know… So yeah, I mean, I see nothing wrong with using C++ features if you know why you’re using them and they were a good idea. Totally fine. I just don’t like to like, “Oh, yeah, we have person class and then employee inherits from the person…” And you’re like, “Nope, don’t do that. Don’t… Just stop that.” So anyway… But yeah, I would say I used to do a lot of that and then Granny 2, I tried… What I did was I said, “Well, okay.” I used [ C++ ] here. There’s templates in the Math library all over the place and handles and there’s classes and all this shit in Granny 1. And I’m like, “For Granny 2, I’m gonna start with C and then see what C++ features I start to type in.” And then instead of [inaudible 85:41] try doing them without them and see what it ends up looking like. I just decided, “Let’s see what C looks like versus C++ for a number of things,” because when I grew up, I only programmed C. I didn’t have a C++ background at all. And so, it was really I got out of high school that I started programming C++. And I programmed that for about 5 years before I came to RAD and then, you know… And what I found was that it wasn’t good at all. I was like, none of.. Everything got better when I stopped using C++. It was like, it’s just better. Period. Like, all these things, inheritance, classes, templates, they are just worse. Like, not a little bit worse, not some of them are worse and some of them are better. They are actually just all worse. And I was like, “All of these patterns that I used in C are better. They’re more stable, easier to debug. Faster. More…” Like, everything was better. So I was like, “Okay.” I answered that question for myself. I now know fairly definitively that C++ is ass and I’m not gonna use it anymore. And so, at some level… And the const was [ similarly ]. At some point, I was like, “Why the fuck am I typing this? Has it ever caught a bug?” And I was like, “I can’t think of a time it has ever caught a bug. I’m gonna stop typing const.” And the first time I hit a bug, I will reevaluate. And I never hit a bug.
Jeff:
Yeah.
Casey:
To this day. And so, I think those are important things to do because you can get into situations where you’re doing something habitually. And if you never stop to reevaluate that and go, “Is this actually good programming practice? You know, think… And if you can’t figure out a way to measure it, that should be a red flag, too. You should be able to think about what makes this code good or bad. If you don’t even know that, then you need to go back to square 1. So think about it — How can I tell if my code is good or not because that’s important right there. You need to know when you look at this stuff whether it’s producing better code. You need to think about what that means because if your entire conception of what is good or bad code is, like, people have told you to put stuff in the private section of the whatever and that’s the way you’re thinking… Like, rule that someone said, that some programmer told you to do… You need to get past that right away and go, “What is actually causing code to go out the door well? What am I actually having bugs on? What am I actually taking time to fix later?”
Jeff:
Right.
Casey:
You need to start looking at actual results-driven evaluation of your code. And until you get to that point, you really can’t do anything else. So that’s definitely a thing to think about. So… That’s probably a good final tip — Results-driven. It sounds like something Don Mattrick says on the Zinga thing. “We are a results-driven company driving customer values…”
Jeff:
“Our employee efficiency with our employee robustness…”
Casey:
Yes.
Jeff:
Towards a better tomorrow.
Casey:
Do you have any idea what any of those words meant? And he’s like, “Nope. I made them all up. I made them up?
Jeff:
I think he knows what all the words mean but he’s using them skillfully to avoid saying anything specific. Right? Because that is… Like, you know, “optimizing process” sounds good.
Casey:
Yeah.
Jeff:
And it sounds like that will turn into money.
Casey:
Yeah.
Jeff:
Because you’re probably spending money on process…
Casey:
You’re optimizing.
Jeff:
And you’ve optimized it.
Casey:
I mean, it’s being optimized.
Jeff:
Yeah.
Casey:
When do you not want to optimize?
Jeff:
This is a total… Like, we need to do a whole thing on that — business talk.
Casey:
Alright, next podcast will be business speak.
Jeff:
We’ll do that. Business speak.
Casey:
Alright.
Jeff:
And McGruff.
Casey:
And McGruff. Well, we’ve been covering McGruff the Crime Dog for many weeks now…
Jeff:
Yeah, we’re gonna get on that. Yeah.
Casey:
Take a bite out of crime, Jeff.
Jeff:
Alright, everybody, if you’ve got any comments on this, give us an email at Podcast@JeffAndCaseyShow.com.
Casey:
Yes. Or don’t because we’re kind of out of things to talk about with the programming. Like, that’s what I’ve got for you — Go out and be a better programmer. I can’t help you. Sorry.
Jeff:
Not that it works, anyway. Everything’s breaking. So we’re gonna be in this bad place no matter what.
Casey:
Well, and pretty soon, I mean…
Jeff:
No matter what, you take it personally and you’re like, “This is a…”
Casey:
Yeah.
Jeff:
“I’m a craftsman.”
Casey:
Right.
Jeff:
“Like, I make furniture… I make code.”
Casey:
[ Tears and rain. It’s tears and rain. ]
Jeff:
But you’re gonna slowly be surrounded by more and more poop around your diamond anyway…
Casey:
Yes.
Jeff:
So that’s a separate little sadness.
Casey:
Yes, it’s definitely a sadness because it is true that the amount of code that a user experiences that is written by you compared to all the rest of the code they experiencing day to day… I mean, you know, yes, you could be like, “I am going to be the bright light of reason in the dark world of chaos or whatever. I’m going to bring order to the madness.”
Jeff:
Right. You can be the candle in the darkness.
Casey:
But it’s gonna be 5 minutes of their day that something didn’t crash and then they’re gonna go right back to open Facebook’s fucking feed, iPad feed, and bam, crash. Ran out of memory for the PHP interpreter. God knows what the fuck they shipped, right? So at some level, it’s true, there’s nothing you can do about that unless you really… If you’ve got some big old hairy balls and you’re gonna do, like… You’re gonna write the next operating system or you’re gonna revolutionize stuff. And man, if you do, that would be awesome.
Jeff:
More power to you.
Casey:
But unless you’re gonna go on that, yeah, you do have to put it in a little bit of perspective and go, “Yeah, you can go and be a great programmer and you should do it for the internal integrity, you should do it for the Buddhist quest for your personal enlightenment. But be realistic about what that’s going to mean in the grand scheme of things. You do have to maybe not set your hopes too high. So…
Jeff:
Alright, everybody. Well, we will see you next week.
Casey:
We will see you next week. If you want to contact us here at the Jeff & Casey Show, Podcast@JeffAndCaseyShow.com. You can check us out. You can get us on Twitter at @CMuratori because Jeff has rage-quit Twitter. You can no longer contact him.
Jeff:
Yeah, we should probably do a podcast on that.
Casey:
We will.
Jeff:
I rage-quite everything.
Casey:
You did. So yeah, you can hit me up on Twitter but you can’t hit Jeff up and I’m sorry.
Jeff:
Yes.
Casey:
So…
Jeff:
And it’s also JeffAndCaseyShow.com…
Casey:
JeffAndCaseyShow.com.
Jeff:
We’re working on some web stuff so it’s a little hard to find.
Casey:
Yeah, it’s pretty part-time so…
Jeff:
That’s the problem. But yes, it is JeffAndCaseyShow.com where you can see all the shows.
Casey:
You can.
Jeff:
And there are transcripts. There are cartoons, illustrations…
Casey:
Yes.
Jeff:
That…
Casey:
There are comics up there that Nolan drew.
Jeff:
That Nolan did that are really funny…
Casey:
Yep. For the second season only, though.
Jeff:
For the second season, yeah. Alright. Well, thanks, everybody. And we will see you next week.
Casey:
See you next week.
Site design and technology © Copyright 2005-2014 by Molly Rocket, Inc., All Rights Reserved.
Contents are assumed to be copyright by their individual authors.
Do not duplicate without their express permission.
casey muratori
the jeff and casey show - season 4 - episode 16
prev
next
mollyrocket.com