14: You are NOT Google

Wolf surfaces five fundamentals to becoming a better developer (that you probably didn’t even know you didn’t know)! This is a fiery one! Jim asks questions, and also questions Wolf's choices.

Takeaways

• The problem comes first—ask more questions
• Start with the simplest thing that could reasonably work
• Measure before you optimize (but don’t be stupid)
• Understand what’s actually an error
• Test so you can evolve, and so that you don’t waste time, money, and effort

Links

Solution from Marlon for Jim's problem of maximizing a terminal window vertically

https://github.com/Runtime-Arguments/MaximizeVertically

Hosts:
Jim McQuillan can be reached at jam@RuntimeArguments.fm
Wolf can be reached at wolf@RuntimeArguments.fm

Follow us on Mastodon: @RuntimeArguments@hachyderm.io

If you have feedback for us, please send it to feedback@RuntimeArguments.fm

Checkout our webpage at http://RuntimeArguments.fm

Theme music:
Dawn by nuer self, from the album Digital Sky

Transcript

Jim: 0:05

Welcome to another episode of Runtime Arguments. I'm Jim McQuillen, and as usual, my friend Wolf is here.

Wolf: 0:12

Hi.

Jim: 0:13

Hey. So today's episode is about what we feel is essential knowledge and process for programmers. It's a big topic. When we started talking about this episode, we thought we'd cover the essential tools and knowledge for programmers in one go. Everything you need to know to be a programmer or become one. And as we dug in, we realized the knowledge and process side, how to think about problems, how to approach solutions, that's substantial enough on its own. So we split it into two episodes. I think you'll appreciate it because otherwise this thing would be like three and a half hours long. So today is all about the thinking and approach. How do you understand problems? How do you start solving them? When do you measure? How do you handle errors? These are the things that separate programmers who build the right thing from programmers who build the wrong thing beautifully. We'll have an upcoming episode about specific tools, editors, debuggers, source control, testing frameworks, all that stuff in a couple of weeks. Today, though, is is action-packed. And like Wolf reminded me, uh, the tools only matter if you're using them to solve the right problems in the right way. So let's start with the knowledge and process that makes you an effective programmer. So before we get into that, Wolf, how was your week?

Wolf: 1:45

Uh, you know, sometimes I have exciting weeks, sometimes I have boring weeks. This was just an ordinary, work-filled week. Um, I got lots of coding done. I feel good about that. Um, no emergencies. Uh I I saw the doctor. Doctor's super happy with how much weight I've lost. That that felt good, but basically ordinary.

Jim: 2:07

Ah, that's good. I uh well, I was out of town last week uh visiting uh a customer, and uh as usual came away from that with all kinds of work to do. So this week was really super busy. I'm I I'm kind of wiped out right now, but that's a good feeling, you know, when you when you did a lot of good work. Uh so that was cool. Um, you know, feedback. We love feedback. Uh we have just a little bit uh this week. Um, you know, the last episode was about terminals. I did a lot of talking about the history of terminals and how we got to where we're at. And one of the things I said in that episode was I'm using Alacrity on Mac OS. And the one feature I wish I had was the ability to uh maximize my screen vertically without going full screen. I just want the terminal window to take up the full height of the terminal. I've been unable to figure that out. Well, you remember uh I've mentioned our good friend Marlin, uh the meta engineer uh boy wonder. Um he came up with a way for me to do that using AppleScript. Um, and boy, if you ever try to use Apple Script, it's a tough slog. But he showed me how to do it. I'm able to uh take hold of my current window uh with a hotkey and expand it to full height. And boy, it just makes that tool do everything I need to do now. So I'm really appreciative of Marlin for that. Uh I think that's all the feedback we have. We want more. Please send us more feedback. Uh we will include the link to the feedback uh uh feedback at runtimearguments.fm if you send email there. Um I'll have the link in the in the show notes as well.

Wolf: 3:58

That is the correct address, yes.

Jim: 4:00

Yeah, as well as contact information so you can contact uh Wolf or me and um let us know what you think of these episodes. If you want us to do other topics, if you like the topic, if you had a problem with something we said, please tell us. We appreciate it. Oh, you know, let's get into this episode. I'm gonna start with a quote from uh Bjarn Stroustrup. Uh, if you're a C developer, uh you'll know that name. He's the guy that created C. And he came out with a book in like, I don't know the date, 1988, something like that. Wrote the book on C. And in that book, there's a quote that I remember reading it the first time, and I thought it was so impressive, I had to highlight it, and I I wrote it down and I carry it with me in my phone wherever I go. And here's the quote The purpose of programming is to deliver a product that satisfies its users. The primary means of doing so is to produce software with a clean internal structure and to grow a group of designers and developers skilled enough and motivated enough to respond quickly and effectively to change and opportunities. And I think if you listen to this podcast uh and pay attention to it, uh you will gain some skills that will help you achieve uh that goal that uh Mr. Straussstrup uh mentioned uh in that book. So let's have at it.

Wolf: 5:30

Wolf, you ready? I am. Um I'm pretty passionate about this topic. And uh like Jim said, we we start the person who's gonna do the research or presenting or whatever, whoever is going to be the expert for that gets an outline of what they're going to say. So we we don't stray too far. So when we first started, uh as Jim said, I built an outline for knowledge and tools. And I think that outline was in the neighborhood of 30 pages. That's too much.

Jim: 6:09

Yeah, we shoot for we we try to shoot for like 12 pages in an outline. If we're 12 or 13 pages, it it's still it's gonna be on the high side of our of our the the amount of time we want to put in it. But um uh that one was 30 pages long, so we knew we had to cut.

Wolf: 6:26

Yeah. So uh I split it into two topics, um one for knowledge and process and one for tools. Um, and I cut the outline in half. I did dive a little deeper. Um, and the fact is that outline, the outline I have right now, it's still too big. Uh the ideas matter more than the details. So I'm gonna try to focus on the top level and to skip over details. Um, so yeah, I've got the outline in front of me. Uh there might be parts that you actually really care about, and I hope you do, and if you hear something that you wish we got into, something for us to explore further, feedback. Just tell us. Maybe it's something that'll be worth an episode, maybe it's just something we'll respond to with email or a Mastodon post uh or or whatever. But absolutely let us know what you want to hear. Um, so the combination of a huge outline um and my passion for this topic, I really care about writing the right thing in the right way that does the right job for the right amount of money. That combination, I'm gonna be fighting that the whole time trying to say less. Uh also, I do have opinions on languages and tools and process, but um my opinions don't matter. Um I'm gonna talk about tools and preferences uh in future episodes, but what matters most is, and here we go, let's get on the horse. Number one, the problem comes first. Uh, for every one of these top-level items, I made an elevator pitch. Here's my elevator pitch. Um I know you know how to write it. But do you actually know what to write? Um, programmers, no matter what level they are, from the very beginning ones, the ones who aren't even on your team yet, to you, to me, to whoever the most uh advanced principal or whatever you have on your team, the chief fricking scientist, every single one at every single level, they are going to uh not ask enough questions. They are going to start coding because they know what the answer is, or they think they do, but they don't actually know the question yet. Um so the most important thing to know um and for so many different reasons, is I I'm gonna use uh specific words for it this time. What are you getting paid for? And I don't mean the company you work for, the salary. I mean the customer. The customer is buying something. Whoever it is that you're writing something for. Maybe you're learning a language, maybe you're writing a word processor, I don't know what you're doing. Whatever it is, there's a customer. The customer might be you, the customer might be the IT department, the customer might be some people uh out in the world who work for some other company, but they know what they want. And you don't. You need to find out what they want because that's the yardstick by which you are going to measure your success. And understanding what the real problem you have to solve is must come before making up answers about how you're going to write the answer. If you get in your car and start driving, and you get to Cleveland, and then you look at your map and realize, oh shit, I was supposed to go to Pittsburgh, you have just wasted a long time and a lot of effort. And your customer is not going to pay you for Cleveland because they wanted Pittsburgh. So um there are um specific metaphors that people use to talk about this. I'm not gonna go deep into them, but a very common one is when you're climbing the wall. The question isn't can you climb the wall? The first question is, is your ladder leaned up against the right wall? Uh because you can climb all the way to the top of the wrong wall and it's absolutely zero help. So, number one, you've got to understand the problem. That's what comes first. And when you do understand the problem, then you'll start to understand the different things about it that you might care about. Uh, the business I'm in right now, I work on high-resolution maps. So, of course, the first thing that occurs to me is um databases and graph theory and Dykstra's shortest path algorithm. And you know what? There is not one customer in the world who either knows the name Dykstra or cares what the shortest path algorithm is. Do you know what the customer thinks? The customer thinks, I need gas. I definitely don't want to get gas in that shady part of town. That's not where I want to go. I needed to know that. Um, it happens that yeah, maybe Dykstra's shortest path is part of the answer to how I tell them where to go. But I didn't really know that until I understood that was part of the problem. So, the first things you have to ask, what problem am I actually solving? Not what code am I writing. Who is going to use this and how do they think about the problem? What does success look like for them? Because by the way, they're the ones who are gonna tell you when it's done. And they'll tell you by signing the check or not. Um you can know in advance because when they tell you what they want, you can write tests. I'm gonna get to that. Uh you're probably gonna care how this gets deployed and updated. Um I'm only gonna talk about this right here and for ten seconds. There's a big difference between you building a website because you can fix it anytime, day or night, and everyone who uses it instantly gets the fix. A difference between that and you shipping somebody a Raspberry Pi. If you work for Raspberry Pi and you made a circuitry mistake, giving them a fix uh that's a whole different problem. So you care about that. And you care about how will I know if it's working. This is different from what does success look like for the customer? Is the thing that you are doing, which assumedly is the thing the customer asked for, is that thing actually producing the correct answer? Um so those are the things to ask. We're gonna talk uh in the tools episode about programming languages and your team and the problem. The programming language that you choose is which language best fits the problem. And here I mean something bigger than what the customer wants, because the problem here means also what does your team know? Um if you're doing an AI problem, Python might be the answer. If you're doing report processing and working with strings, Perl might be the answer. If you're writing something that runs on an iPhone, Swift might be the answer. Uh those things are based on the problem. But also, it matters what your team knows. If nobody in your team knows Rust, but Rust would have been the answer, well, that's some strikes against Rust. You might need to consider that. And uh the other tool that is absolutely key to talk about is this. We're gonna go into detail in a later episode, but source code control. I don't care what you use. I like Git, but maybe you want subversion, maybe you want jujitsu, maybe you want anything. I don't even know. It doesn't matter. What matters is source code control, no matter which program it actually is, gives you the power to experiment, to undo, to go back to known release points. I don't care if you're on a team, if you're working alone, if it's a uh MVP, whatever it is, day one, before you write your first line of code, you need to initialize your source code control machinery. So that's topic one. Know the problem.

Jim: 15:51

All right. Uh um I I love everything you're saying. I just wanted to point out one thing, uh uh relay, uh something I've experienced. You talk about you you need to know uh the customer's problem. Uh have you ever run into the situation, uh, and believe me, I run into this every single time, where the customer describes their problem in terms of what they think the solution is. Oh my God. That is always how they describe it. And and I it just makes me have to ask questions. What problem are you trying to solve? They don't give it to me right away. They they tell me what solution they want.

Wolf: 16:27

That's right. And there's a very common metaphor for this. Uh I don't I don't, I think it was Henry Ford maybe who said it. But um if you asked the typical human being um at the turn of transportation um what they wanted to use, they would have asked for a faster horse. Um they didn't know that a car was the answer that was going to change their minds about everything.

Jim: 16:56

Yeah, because they weren't describing the problem. They were describing what they thought was the solution.

Wolf: 17:01

That's right. So uh there's a couple things to draw from that. First of all, um you've got to draw out the problem. Uh you can't l i i you know, you'll it's the same when you talk to your doctor. Your doctor has to do the exact same job with you. Um you'll go in and say, I need something because of my upset stomach. But that's the symptom. What's the actual problem? The doctor cares about the problem if they're a good doctor. You're a good programmer, I'm saying to all of you listeners out there. The thing you care about is what's the problem. Not what's the uh symptom or the solution that they think they have. Every once in a while, uh the solution is what the customer thinks. Um It turns out that bookkeepers before the invention of spreadsheets, if you told them what they wanted, I mean maybe they would have said, you know, calculators or something like that. But if they had some foresight, they would have said, really, really smart what we do now, spreadsheets. Um, and that's what we got, and that turned out to be the right answer. But sometimes it's the wrong answer, whatever they say, and you gotta suss it out. You have to understand when they think they know better than the actual answer, but also you have to make sure you understand when you think you know more than the actual answer. It's worth figuring out because you're wrong more than you're right. Um just like when you're searching for something, it's always in the last place you look. It's the same with answers. Okay. Number two. Are you ready for number two, Jim? I I am. Let's go. Alright. Start simple. You are not Google. Um this topic name is its own elevator pitch. Uh when you start off solving a problem, a lot of times you start thinking about the problem like you're going to have millions of hits per second, or you're going to have a database with a billion rows, or some other thing, some other thing that is not your problem right now. It's the problem maybe you want to have. It's the problem you imagine having. Maybe someday it actually will be the problem you have. But you know what? Right now it's not. And you don't have to write Google's answer. You can write something simple. That solves your actual problem. And that's what you want to do. But there's two sides to this coin. One of the sides is premature optimization. And I know you all already know premature optimization is the root of all evil. That's a Don Canute quote. But um there's a difference between premature optimization and not being stupid. Um for instance, uh if you start off and say, I've got points in a geographical world, I'm gonna need to find the nearest thing, obviously I need a KD tree, or whatever. Um do you really know that? That's that could be premature optimization. That is you doing a complicated thing instead of the easy thing because you anticipate how hard it's going to be. Let me give you something from the other side. Um simple data structures. Uh let me name a couple, and you ought to know the differences between these. A list, a set, a dictionary. Th these are ordinary things that make up the bulk of a lot of ordinary programming. Lists and sets work differently. Lists are ordered. If you want to find something in a list, you step through it. Uh and you look at each item until you find the one you want. If your list is n items long, that means you do n operations. Or, you know, n over two, but that means n. Uh in a set, if you want to find out if something is there, you just ask. Are you there? And it's an it's it depends on the actual implementation, but typically amortized it's a constant time operation, O one. Often it's actually O log n or something. But um what matters is you need to know, do I step through? Does order matter? Or am I mostly doing membership tests? And between those two, you know. Oh, I should use a list, oh, I should use a set. That's not premature optimization. That's not being stupid. Um so don't prematurely optimize, do uh use the appropriate um basics, do be smart. Um it's a fine line, but ask yourself, am I making this choice because it fits what I know about my problem or because of what I fear might happen in the future? But you're not Google, you're not Facebook. Uh it's critical, it's often forgotten, their problems are gigantic, even bigger than you can imagine. And yours aren't yet. And by the time they are, you'll know. You'll know better. Um so solve your actual problem at your actual scale. But this also means that you need to know what already exists and where to find it. Um, the standard library is fundamental to your toolkit, whatever language you're using. Um in the f in the standard library of Python, for instance, there's tons of stuff having to do with lists and sets and dictionaries and iterating and uh there's a uh a ton of different tools. You should not write those yourself. Absolutely don't get involved in um uh not invented here syndrome. The skill is awareness and knowing where to look. It's not in being able to write that thing. Uh and here is where Jim and I kind of have a disagreement.

Jim: 24:18

You know, I I don't disagree with anything you've said. Here's here's what happens. Uh Wolf and I have this rule. Whoever uh owns the episode, and in this case, this episode is owned by Wolf. He created the he came up with the idea, he created the outline. But whoever owns the episode gets to decide what the content is. And I had a different idea what the content was gonna be uh when we first started talking about it. And at first I was surprised that he didn't have the same idea. And then as I read through his outline, I thought, ooh, this is a great idea. So I'm really happy with it. But I wanted to point out kind of where I thought this episode was gonna go. Um, and for me it was essential knowledge, and and I was thinking more like um knowledge, like we'll start process and stuff. I was thinking more about like the the fundamental knowledge. Uh I think you should have uh uh knowledge of of low-level program languages like C. I used to think assembly was was a requirement, but nobody's using assembly anymore, right? Unless you're doing embedded, and even then you're probably not. But uh, you know, I think you should have knowledge of of the C programming language. I think that helps you understand uh systems. And you might be programming in Python or Rust or or anything. Um, but knowing C, I think just just helps. Uh I I think you should have knowledge of HTTP, the HTTP protocol. Uh there's a lot in there. I I work with these kinds of things all day long. And knowing how cookies work and how headers work and how uh authentication works, I I think that's crucial because everybody now is working with APIs. You're doing RESTful API calls, right? Uh so I think uh a fundamental knowledge of HTTP is is great to have. Um well, if you did mention data structures, lists, hashes, all that stuff. Very, very important. Um uh that that probably should have been first on my list. Um, you know, hashing functions, you don't really need to know uh the innards of uh hashing functions like SHA 256 and and those kinds of things, but knowing that the there's differences and knowing which one to use when, I think is important. Um SQL. I program in SQL a lot, and I think anybody doing any programming, well, I mean there's a lot of people doing programming that don't require it, but I think a a good understanding of SQL uh is important. You know, a lot of people are afraid of SQL. Uh I just love it. I I love how I can pull data out. Um I've just got a couple of more here. Um you know, I mentioned SQL. Well, how about no SQL? You've got uh MongoDB and CouchDB and uh several others that don't use SQL for holding your data. I think it's a good idea to know those things. Um if you're writing programs and you're uh you know you're reading in the documentation that uh what Python passes by reference mostly, or both, right? When you call a function in Python. Um knowing the difference between pass by reference and pass by value, I think is really important. So that you understand, you know, if you're passing a data structure through a function that passes by value, that's a lot of data you could be pushing to that you know onto the stack for that function call. Um I think it's good to understand that. Circular references, there's one that'll get you get you in trouble with uh memory allocation if you've got a circular reference. A lot of people don't even know what that is, but I think you should. Uh and then by far, the number one thing you should know uh the tool in your toolbox, I think, is regular expressions. Uh I can tell you the number of fundamental notes I have met.

Wolf: 28:10

They just they don't even know what a regular expression is. They see it and they're like, what the hell is that?

Jim: 28:17

Yeah. Yeah. So so basically the things I just listed about, that was the episode. But Wolf has taken it so much further, and and uh he's got a lot more to talk about. So I'm kind of excited to get back to that. So um uh this is the end of my little little uh discussion on the topic. Wolf, do you disagree with anything that I've said?

Wolf: 28:39

Uh right off the bat, I have to say uh at least two things. First, absolutely, everything that you just said, if someone knows those things, that knowledge helps them. They are a better programmer because they know those things. Uh SQL is going to help you solve problems you didn't even know you had. Regular expressions, they will become a tool that uh lets you do things you didn't know you could do until you find out that sometimes you actually need a parser and that regular expressions can't do the thing that you actually wanted. Um I don't disagree that any of the things you said are valuable, but lots of times I feel like the things you need to know are more strongly related to your domain and the problem you're trying to solve than they are to just to being a good programmer overall. If you're not working with a database, SQL actually isn't going to help you. Um if you're doing your work in Python, understanding C, now I I have an ex an exception for this, understanding C is not a gigantic win because Python and C are very different. However, there's a thing in C that anybody who actually knows C understands is a problem for a lot of people, and that is understanding the concept of a pointer. Now, a pointer, which takes some getting used to to really understand it, is actually a very specific case of a more general concept, that of indirection. Indirection is a big deal everywhere. Understanding pointers is absolutely three-fifths of the way up the ladder to understanding indirection. If you get pointers, you already know indirection almost entirely. You just have to figure out how to recognize it when you see it. Um, pass by reference is an example of indirection. Um I gave in this name. It just happens that when I passed the name in Python, that name refers to the same underlying bytes in memory. Well, in the actual implementation of the Python interpreter, it's because there was a pointer. You don't need to know that to be a Python programmer, but you do need to understand in direction. Um they're strongly related. So I absolutely agree that the things you said, they are worthwhile. Um, but I think that you don't actually need to know about web protocols unless you're working on web stuff. You don't need to know C or assembly language unless you're writing stuff that is gonna need C or assembly language. Uh you don't need to know how to drive a stick um unless you have to borrow your grandpa's car.

Jim: 31:56

All right. Well, I I will say this. Um HTTP is useful for RESTful APIs. I don't really consider that web programming. That's just API calling these days. But yeah, uh I uh so we have different ideas, but uh we're both going in the same direction.

Wolf: 32:14

I think we are. Uh there's valuable knowledge. Um, there's some valuable knowledge that on your side of the fence, Jim, uh, I feel you believe is universally valuable, and I think is more strongly related to certain areas, but we both value it. That's what that's what I think.

Jim: 32:33

All right, I'll take that.

Wolf: 32:34

So we're we're agreeing and we're disagreeing.

Jim: 32:37

I I guess I I think that every programmer is solving the same problems I'm solving. And and that's just not the case.

Wolf: 32:44

You know, um everybody thinks that about almost everything. Yeah. Uh everybody thinks, well, I'm not, I'm not even gonna get into it. I do want to um touch on uh while we're in the what you are going to be writing and what you need to know part of the episode. Something small. I'm gonna try to spend just a couple of seconds on it, and that is this. Um, you know, when you see a race car driver, his job is driving around the track. Guess what? That's his job for eight hours or however long that he actually spends running around the track. He has five times that much job doing other stuff to be able to do that. When you think about being a programmer, you think about writing code. And especially uh when you're new, you think about writing brand new code, uh, which is a thing that you don't get to do nearly as often as you wish you did. But it turns out that a lot of our job, I don't know how many of you used to watch Norm Abrams, the master carpenter on this old house, and he had a show of his own called New Yankee Workshop. Um, he had an hour-long show where he'd build something really neat, a beautiful cherry wood chest of drawers or a dining room table or something. Absolutely gorgeous. Of that hour, he spent um, you know, 20 minutes actually building the table. The other 40 minutes, he spent building the things, normally called jigs for woodworkers, that helped him build the table. When you're a programmer, you do the same thing. You write the scripts that help you do a release. No customer is ever gonna get that script. You're not shipping it to them. You are gonna ship them the release. A part of your job is building these jigs. They belong in source code control. They deserve care. You do want to treat them with respect because they're real work. Um, but they're not the thing you're shipping. They don't have to be perfect. You just have to get them to do the right thing in a way that is reliable and fixable. It's part of your job. They should be in source code control. Let's remember it. Abraham Lincoln, I think it was, said, if they gave me six hours to chop down a tree, I'd spend the first four sharpening the axe. Um I think that is a perfect description of the thing that we do. So don't be afraid to write these scripts. Like everything else, start simple. They are not the goal. Don't make them be the goal. They're a step on the way to the goal. Sometimes you'll see, oh, I could make this faster? Great. Go spend 10 minutes to make it faster. Do not spend two weeks to make something fast. That's not right. Um, and that is the last point you gotta know when when you're done, when it's time to leave them alone. Yeah, maybe you'll edit them again in the future, whatever. So um, start with the simplest thing that can possibly work. This is for your answer to the real problem, this is for your jigs, this is for the implementation inside any single function, this is for the API if you have to build a class or a module or any collection of different entry points, however they are presented, that are supposed to present a model, start simple. Um anything you publish, and your source code control system is a perfect example of this. Anything you publish, you can't go backwards from. Um but you can easily go forwards, so start small, and then only when you know it get bigger. Um we're gonna talk about libraries and where to look for things and logging and all of the things about writing code um later in some other episode in the future. Um but uh I do want to say something very, very important that has to do with everything you create. Names, functions, behavior, programs, files, user interfaces, build scripts, tasks, everything. No surprises. It should have a name that says what it does. Once you've given it a name, it should do that thing. It should if your name is has edges, has edges is gonna return true or false. If has edges returns true, false, or none, that's a surprise. You've made a mistake.

Jim: 38:13

Or if it returns the edges.

Wolf: 38:16

Right. Uh so start simple. Um all right. Number three. You ready for number three? I'm ready. Let's do it. Measure. Measure everything. Measure starting right now. Don't wait until you know you're too slow. Start measuring now. You don't want to get to Cleveland and say, look, my gas mileage was 23 miles to the Oh, I should have been in Pittsburgh. I've made a mistake. Measure. Here's my elevator pitch. Everything is about money. You absolutely have to know where you are spending it. Um maybe it turns out you did need that KD tree, but you're not gonna know unless you measure it. How much of the time did they spend accessing those points? How much of the time did a real human being waste? Um, if you could have made it faster, you won't know until you measure. So, measure everything. Um, you absolutely must not optimize anything you haven't measured because you don't know what's right. And I promise you that your guess as to what is slow and what is fast, I don't care how old you are. I don't care if you've been programming for 40 years, your guess about what's slow and 40 years of programming, it's gonna be a better guess than it was when you started. But it's absolutely Absolutely not guaranteed to be right. You're not gonna actually know the truth of what I just said until you do start measuring and you find out, oh shit. It's startup time. Just reading the config file takes ten minutes. Do I have to fix that?

Jim: 40:21

What is that? A sendmail config file?

Wolf: 40:26

So measurement is absolutely a continuum. You start right away, right at the beginning. And your first measurements can be simple. And as you see which things are slow, dive down into those things. And once you understand what parts of them are slow and why, then maybe you're ready to develop. Sometimes it's not going to be about optimizing. Sometimes you're going to say, did I actually need to do that at all? You know, the fastest code you can have is the code you don't actually execute. And how long something takes, that might not be the only money you're spending. If you're running this in the cloud, maybe you care about how much storage space you're using, how much memory you're occupying, how many GPUs you're using. If it's something you're spending money on, you need to measure it. Once you actually have something in production, there's more kinds of measurement that might be helpful to you. There's questions about whether it's acceptable, depending on how much you uh learn about end users. But a thing that we care about is called telemetry. Um unless you bring users in-house and videotape them or something. It's not even videotape anymore, whatever it is, but record them. Um do they bring up the map? Do they actually click and put pins in locations? Do they parse this string? Do they ever fill out this form wrong? Do they put their names in the right slots? To know the answers to those questions, you need a special kind of test that we call telemetry, where you get feedback. Whenever you do these things, you want to be as non-invasive as possible. You don't want to know things about the users that you shouldn't know. You don't want to store information about them. You want to be a good human being. But telemetry is going to be important to you understanding if you're doing the right thing and solving the right problem, and if the way you've solved it makes the customer use it the way um you all together think it ought to be used. Um that's about measurement. Um I'm ready to talk about the fourth thing. Are you ready, Jim, or are you gonna fall asleep?

Jim: 43:11

Uh I'm not falling asleep. This is fascinating. I'm ready.

Wolf: 43:15

I'm anxious. All right. This is a thing nobody thinks about, and that is errors and a thing they kind of think about, which is validation. Um, whenever you are writing a program, things can go wrong. And part of your job as a programmer is to figure out the places where something can go wrong and to catch it, to make sure that you uh don't let it go wrong and ruin someone's day. Let me tell you a different kind different some different kinds of things that can go wrong. For instance, i in a traditional language with pointers, a thing that you can do is you can have a pointer that is null. It doesn't point to anything. Uh but you assumed that it did. It was supposed to. And you don't even look, you just dereference it and try to get that thing and do something with it. Um or you get a list. Maybe it's a list of suppliers. Who knows? Um, but instead of having some suppliers in the list, you get a list, but it's empty. Um or maybe the user entered a six-digit zip code. Not a nine-digit zip code, not a five-digit zip code, a zip code that in this country is wrong. Um so all different levels of things can go wrong. Some of them are your fault. A null pointer? That's you. You did it. Um that should never get through uh to a production build. No customer should ever encounter the place where that pointer was null. If that pointer was null, it is acceptable to stop the program. If the supplier list is zero length, that might be real. Maybe you're looking for all the people in Columbus who can build you a hydroelectric dam rotor. And there aren't any. You know what? That's not an error. That's true. You can't get one in Columbus, that's all there is. Should you stop the program? No. Um, so that's an error that you have to handle differently than a null pointer. What happens when an uh a user enters a six-digit zip code? Is that worth ending the program for? No, you don't even accept a six-digit zip code. When they type in a six-digit zip code, that field turns red and the submit button dims out and becomes uh unavailable. You don't let them put in a six-digit zip code. There are all that's validation, by the way. There are all kinds of different answers. So every time you, and you're always looking for them, come upon a situation where something can go wrong. You need to understand, is this something, whose fault is it? Who can fix it? Can I go on beyond this thing? Is it possible to keep running the program? Um, do I need, if this is in production, to actually report back to the programmer to say, hey, guess what? This is something that made it to through to production and shouldn't have. You need to fix this. Um that's merging with telemetry. So always be thinking about it. Uh and I tried not to dive down into the details of my outline, so I think that covers error handling, and I feel like that puts us onto the very last uh top-level item. How do you feel about that, Jim?

Jim: 47:14

Uh I I think you're moving at a great pace. Uh we're gonna finish this one on time. I'm I'm impressed.

Wolf: 47:22

All right, here's the last thing, and you knew I had to talk about this. It's testing. Um testing is absolutely fundamental to development um for so many reasons. Because uh you can't know that you're right unless you test. You can't know that you're done unless you test. You can't know that it's safe to refactor, and believe me, when you start simple and evolve, refactor as you learn more, there's going to be refactoring. And you want that refactoring to be easy and safe. The smaller you make your APIs, the smaller you have written your code, the more tests you have, the easier refactoring is going to be. If your tests all pass, and then you move things all around, and now your tests all pass, oh, except for that one, well, find out why that one doesn't pass, fix it. Guess what? Your refactor is good. Um and that's a thing you're going to be doing a lot. Um and the combination of starting small, writing tests, and running those tests, and your performance checks are gonna be in those tests too. When I worked on Mozilla, one of the things that we did was um we had several different operations, and when I say several, I mean, you know, uh less than a hundred but more than twenty uh different operations timed. And if any of those operations got slower, that was the same as submitting code that actually didn't build. The tree turned red, that means we had a web page that showed um the build with the currently committed source um on uh one column for each OS that we were building on, and it was green when everything was good and you could actually release it, it was yellow if there were warnings, and it was red if the code didn't compile, or if the performance measurements or tests failed. And when it was red, you weren't allowed to commit code, and job one for every single engineer was making it be green again. Um not implementing your goddamn feature, not uh it was fixing the test or making it go back the speed that it was before. So testing is absolutely fundamental to every part of your job and the combination of writing the code and the tests, but doing it small and running them before you commit, and always having something that functions instead of writing it too big and not testing it, and fixing more bugs than you thought you were gonna have to fix, and not being able to build, and not being able to release. The one with tests sounds like it's more work, but it's faster. It's faster and it's easier, and you're going to hate it on day one, and you're going to love it on year two. Um People have been telling you this forever. Those people sound pretentious? They're not. They just know. So, item number five, the elevator pitch. Testing enables elevation. The elevator pitch is how do you know your code works? How do you know you're done? How do you know if it's okay to make the big change? Um, and how? It's by the tests. Um I think those are the big points. So let me give you the takeaways. Um, how do you how do you feel about that, Jim? Is it time for the takeaways?

Jim: 51:41

Yeah, that's some excellent information there, and I'm looking forward to the takeaways.

Wolf: 51:46

Alright. The takeaways are short, um, and they will be in the show notes, which since you're listening to this in your podcast player or on the web or wherever, they ought to be right there where you can see them. Here are the takeaways. There's five, one preach top-level topic. First, the problem. The problem comes first. What comes first for you is asking questions and more questions and more questions until until you actually understand the problem. That's number one. Number two, start with the simplest thing that could reasonably work. Um it's quicker to write, it's quicker to test, it's gonna do the thing you want, it solves the problem you have, it's the best use of time and money. Why aren't you already doing that? Uh number three, measure first before you optimize. But don't be stupid. Um if it's only membership, use a set. Um lots of times you probably want a dictionary, or sometimes known as a hash. Uh that may be the answer to most of the problems in computer science. You better know what it is, because it's gonna be important. And using a hash when you're or a dictionary when you're supposed to, that's not premature optimization, that's good programming. Um, understand your errors. Which ones are worth quitting over? Which ones are worth uh uh stopping the user from what they're doing, which ones can be fixed, whose fault is it? Is it really an error? Understand. And number five, write tests. Tests so you can evolve, tests so you don't waste time, tests so you don't waste money, and tests so you don't waste effort. Um I tried not to go down into the weeds. I tried to tell you the five most valuable things I could tell you that you didn't already know. Um to the best of my ability, I think I've done that. What do you think, Jim?

Jim: 54:12

I I think you covered some excellent things. Um that's the knowledge and process side. How to think about problems, how to approach solutions. We talked about understanding the problem first, starting simple, measuring blah blah blah. Wolf just mentioned all those things, right? Um, in an upcoming episode, we're gonna uh dive into the tools side of it, the editors, code, uh, source control systems, um, all that kind of stuff, languages. Uh, we're gonna get deep into that stuff. Um I I'm looking forward to that episode right now because I think it's gonna be like this. Uh you and I are gonna have words over it, and and uh and and you're gonna make a long outline and I'm gonna ask you to cut it down. Uh you did a great job on this one, so I appreciate it. Um as always, uh, we love to hear from you. So please send us your thoughts, questions, uh your own experiences. Um we'd just love to hear about it.

Wolf: 55:10

Uh and you know and especially especially because I did uh not dive into the weeds. If there was something you wanted to know more about, tell us.

Jim: 55:22

Yeah, yeah. You know, the neat thing about not diving too deep on each one of these subjects is it can become a whole episode on its own. Uh and and and that's good. So if you want to hear about it, send us the feedback. Uh feedback is at uh uh runtime arguments uh at feedback at I'm sorry. Feedback at runtime arguments.fm. I don't know why I have such a hard time with that. Uh anyway, send us email, please. Uh we'd love to hear for uh hear about uh uh what you want to know. Um man, thanks for listening, everybody. Uh and we'll talk to you next time. Thanks, everybody.