16: Do you have all the right tools in your toolbox?

Wolf has lots of great information about the tools you should consider using when developing software projects. Jim chimes in with his own ideas.

Takeaways

Just a few take-aways this episode and I hope by this point you have already internalized them and this is just a summary.

• I’ve presented categories: the tools you will absolutely need to get your job done. You will need an editor. You will need language. You will need a source-code control strategy. The first take-away from this episode is these categories! Do you have everything you need? Are you using it when you actually need it? Have you been using print when what you really needed was a debugger?
• I’m going to separate this next take-away into angles. These angles have the same implication: to get the right tools, you might need to do a little research.
  • Do you know what all a tool in a given category can do for you?
    If you’re a Notepad user and didn’t know that PyCharm or Helix or VS Code could rename a method and fix it across your entire project in a single command (skipping over things that were spelled the same but weren’t actual uses of that method) … then why would switching even cross your mind?
  • Do the “math”: is an alternative enough better to make you switch?
    Will you get out of it more than you put into the switch? Git was enough better, for Jim, than Subversion. But in editors, Helix is not enough better for Jim, to make him leave Vim. There’s nothing wrong with that! In every case, it’s never about which is better; it’s about which is enough better. Is the juice worth the squeeze?
• Maybe one tool is not enough! I personally do the bulk of my editing in Helix; but sometimes, PyCharm does the specific thing I need. Both are at my fingertips. You don’t have to settle for just one tool.
• And finally, as always for me, the underlying theme is: are you spending whatever it is you’re spending (time, money, effort) on the things with the biggest payback? Using a great editor, an editor that you are great at using, lets you work faster and more effectively. The right tool doing the right job at the right time helps you spend less on your way to the end goal.

Links

Here's a link to the github repo with the project for reading Meater temperature probes: https://github.com/Runtime-Arguments/meater

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:06

Welcome to another episode of Runtime Arguments, where we talk about programming and all kinds of computer technology related topics. I'm Jim McQuillen and my partner here is Wolf. Say hi, Wolf. Hey. Hey, how are you doing? I'm doing great. Sometimes we talk over each other. That's just the way it goes. Um, so today's episode is about essential tools. Now, this ties back to episode 14 we did uh a month or so ago. Uh, and and the that episode was You Are Not Google. That episode was all about uh essential knowledge, um knowing how to do things, knowing uh uh Wolf, what did we talk about? We knew how to do what.

Wolf: 0:54

What what should be in your brain? Uh how to approach a problem, forgetting everything that might be in your hands or at your fingertips. What is going through your head as you start down the path of solving a problem and stay on the path towards the answer?

Jim: 1:12

Yeah, yeah. And it kind of uh the title I think was pretty good, You Are Not Google, and that was Don't Think Like You Are Google. That's not the problems you're trying to solve. And the whole episode was about uh how you should approach uh your projects and stuff, and uh it was a lot of fun. We really enjoyed that. Anyway, this is part two to that. This is uh essential tools, um debuggers and editors and source code control, and health skills get into all that stuff. And believe me, he's got some really good, interesting things uh to talk about. Um, so how was your we week, Wolf?

Wolf: 1:50

Um well, uh some weird, weird stuff. Uh I I've I'm halfway through, you know, they don't do cataract surgery and they don't do both eyes at the same time, at least that I have heard of. Some people are like telling me, oh no, I had them both done. But yeah. Um, so that's put me in a weird place. My vision is both the best I've ever had and awful. Um, and um I I get a couple of headaches. That's that's weird. Also, um I started using the direnv tool, which works works great everywhere. Um and as you know, I use everything. Works great everywhere, except in Git Bash for Windows, where it needs help. Um so I've been working on that, and I've got it to work, not with Pixie, which is what my main project is, but it does work with a UV-based build. So I'm pretty excited about that. It's helping me. I just CD into the directory, and everything's great.

Jim: 3:01

Okay, so I I've heard you mention dir env, and it's D-I-R-E-N-V. Uh, you mentioned it a couple of times. I saw you posted on Mastodon about it, and I gotta tell you, I don't know what it is.

Wolf: 3:14

Um you never have to say the word dir env. You add it to your shell and it sticks something into your prompt. There's a thing called prompt command that runs every time your prompt happens. And what what that does is um it figures out if anything needs to happen specifically for the directory you are in or up from there. And usually you specify these needs, these requirements, in dot envrc files. So examples are, for instance, uh in a Python project, you you always are working with a virtual environment. Durand doesn't have to be used with Python, but if you are, you tell it you are, and it automatically activates your virtual environment when you're in that directory or lower, and deactivates it when you CD out of there. Um if you've got global variables you want to set, absolutely great. Um so a whole bunch of stuff that you normally would do by hand, DureInv can just do for you. There's other tools that do this. DurEv might be the most famous. Uh also famous is that the author of DurEnv does not himself have a Windows machine.

Jim: 4:38

So um So So debugging Windows issues and getting them fixed is is challenging. Correct. Yeah. Um is your when you when you change into a directory, things can happen, and you're in control of what those things are by these dot files. And when you leave a directory, some things can happen. Right?

Wolf: 5:00

Yeah. And in my case, um it happens that I'm the thing where I'm making this work right this minute is the standard structure of a writing a brand new Python package. So it's a directory with a pyproject.toml, it's got a source directory inside that, um, and then below there are the actual Python files, there's a virtual environment at the very top level. If you just tell direnv with a simple line in the.nvarc file, um that this is what you're looking at, and yet you do it with a layout command, layout x, whatever x is, um, then it does all the stuff that you want for that kind of situation. And one of those things is it activates the virtual environment. Um Okay.

Jim: 6:01

That that's sounds useful. I'm not a Python programmer, so that part doesn't appeal to me, but some of the other things sound really interesting. And and you know, maybe there's maybe there's something I can I can use there.

Wolf: 6:14

Um Yeah, it uh one of the layouts is layout pearl. Um I don't know what that does, but it's worth checking out. Might do some stuff automatically for you. Don't know.

Jim: 6:25

Yeah, yeah. That sounds great. Um okay, so Matt, I I you know, we say how is your week, but it's really two weeks because it's two weeks in between every episode, right? And I've got a lot of stuff going on in the last two weeks. Um you know, I I I went to uh uh Maine. Um we go, you know, I I used to work on a project called LTSB, the Linux Terminal Server Project, and that was Thin Clients on Linux. Um and in 2000, well, in the year 2000, we started going to Maine for a developers conference, and we still go, even though I haven't touched that project in like almost 15 years. Uh but we still go every year, and there's a bunch of us that go. And this year, six of us went. Uh, Wolf has been several times, but he wasn't able to make it this time. But it's just a bunch of smart people, and we we go and we we spend a week in Maine and we eat well and talk tech and just have a great old time. And uh and this year uh I say we eat well, and basically we stay in a uh kind of an apartment type thing with a full kitchen, and the guys that go, some of them are really, really good cooks. You know, I can boil water, but these guys they know how to really, really do it up. And I'm talking specifically about uh Scotty and Ron, and they're both listeners of of this podcast, and I think they'll get a kick out of me talking about this. Anyway, one of the things on the menu was uh pork shoulder. And uh Ron is big into like smoking things, and uh and when I say smoking, I mean smoking meat. Um it he it's a whole project for him, and it's really fun to watch because he's so passionate about it. Anyway, they were up at like five o'clock in the morning preparing this thing, getting the grill ready, charcoals lit, all that kind of stuff. And then once the meat starts cooking, uh Ron is a data guy, he likes to keep track of the temperatures of of all the meat and what's going on inside the the barbecue grill, and and for some reason he likes to track the temperatures every 15 minutes. So he writes these things down as a notebook, and it's it is fun, fun to watch this. Everything he does, he goes out and makes a uh uh a measurement. Um he's got these thermometers. Uh I I think I turned him on to these. They're they're uh it's something called meter, it's M-E-A-T-E-R. It's meat thermometers. And uh, you know, we don't get any any uh sponsorship from these guys, but they make great uh thermometers for meat, and there's an app for your phone. And so Ron is using these and he he's got a set of four of them and he plugs them into various parts of the the pork shoulder and it's cooking, and every 15 minutes he's checking his app to see what the temperatures are, and he writes them down in his notebook. And Scotty, uh, he's a great cook too. And uh he kind of watched that and he kind of thought, you know, that's kind of silly. Every 15 minutes writing this down. And he thought, I I never would have thought of this, but he thought, I wonder if there's an API for those meat thermometers. So he Googled a little bit and he found out, yes, there's a public API for these things. So he whipped up a little Python program to attach to this public API for these thermometers. And you have to pass it like a, I guess it's like a um a MAC address for each of the thermometers, some kind of an ID for each one that makes them unique. And you got to pass them some credentials uh to the API. So now he's able to fetch the the temperatures of these four meat probes as often as he wants. Uh so he sets up this program to fetch them. I I don't know, I think he did them every five minutes or something. I'm not sure what the interval was. Uh so he started collecting this data. And, you know, of course, Ron was astounded. I was just completely surprised and happy to see this thing happening. So now Ron's not writing these things down in his notebook, he's got a database of these times and these temperatures. And then Scotty took it a level further and he used GNU plot to plot these temperatures over time. And now the two of them, and this is like a 12-hour cook, and the two of them are just sort of giddy about what they're doing, and they got these plots and and graphs, and it's just it's hilarious. Anyway, he gave me that code that he wrote. I put it into a GitHub repository, so it is on our runtime arguments uh GitHub account. Uh and I'll put the link in the show notes. Um, so if anybody here wants to wants to download that and give it a try, uh, I I just thought, you know, I I I've always believed surround yourself with the smartest people you can find. And it eventually rubs off. And I'm telling you, these guys, uh, they're they're brilliant, and it's so much fun to be around them. All the guys that were in Maine this year. Uh it was just so much fun. Uh and of course we missed Wolf, but uh I still get to hang around with him, and he's like he's like at the top of that list of smartest people I know.

Wolf: 11:40

I you know, I have a direct I have a direct comment on the thing you just said. I I've said it to you in different words multiple times, but I want to say it uh for everybody who's listening, and that is that um passion and expertise are absolutely enchanting to witness. Oh when somebody knows how to do it and wants to do it, it is a treat to be one of the people who gets to watch.

Jim: 12:14

Oh, it's it's it's it's like nothing. Like nothing else I've ever seen. It's uh it's so much fun to be uh just uh an observer of of what was going on in Maine. And and I just love I love these guys and it's so much fun to watch them. So hey, shout out to uh Scotty and Ron. Uh and and uh that was an awful lot of fun. Uh so uh I'm talking a lot and I've got more exciting things to talk about. And uh I I promise you eventually we're gonna get to uh the part where Wolf talks about essential tools. Uh I I've got one more thing. Today I unlocked a superpower. And you you know what that was? Um, what uh back, I don't know what it was, our second episode, we talked about uh moving to the cloud. I moved uh my system uh that I host for my customers from our data center uh up to the cloud using Azure. And one of the things I put in the cloud is our internal wiki. We have a wiki for my company, and that's where we keep all our important stuff. And I don't want other people to have access to that wiki, I just want people from my company to be able to get at it. So the way I set it up, I use HAProxy to decide uh you know how to get to the various internal servers. And I had a thing set up in there where you have to be on the VPN in order to access the wiki. Um, but that caused a problem because I use Let's Encrypt for SSL certificates. Um that caused a problem with Let's Encrypt renewing that certificate because Let's Encrypt wasn't able to get at that internal website. Uh so you know, every two months, you you got to renew it every two months, right? Because uh the certificates are good for 90 days, and at 60 days it tries to renew and it would fail. And I'd go in and I'd change the I'd change the config so that for that couple of minutes Let's Encrypt could hit my internal site, and it was ridiculous uh and and not a good idea, but every every two months I had to do that. So today was the day that I needed to do that, and I thought there's gotta be a better way. Um, and normally the way Let's Encrypt works is uh you run this cron job and it goes out and and it runs uh the acme.sh uh script that reaches out to Let's Encrypt and requests a new certificate, and they validate that you are who you say you are by hit hitting your web server and fetching some magic key. And if they can't get to your web server because it's internal to your network and not publicly available, it's gonna fail. Um so there's a way around that. Let's encrypt and acme.sh, they support DNS for doing this. Um and uh my DNS is hosted by Google DNS, Google Cloud DNS. Uh, and they support that. In fact, they support like 175 different DNS providers for doing this. Uh anyway, I got it all working. I am now able to uh renew my certificate for my internal wiki completely automatically, um and it just happens, and it's I just love it. And the more and more I use uh less encrypt, the more I love it. And it's just great. So, like I said, I unlocked a superpower. I now know how to use less encrypt my internal hosts, and I think that's pretty cool. Um anyway, there's a podcast I discovered um when when we drive to Maine. It's a long drive, it's like a thousand miles from my house here near Detroit to the place we go in Southwest Harbor, Maine. It's a long way, and with a bunch of guys in the car, uh I like to take technical podcasts with us. And one of the podcasts I I've loved for years is co-recursive from uh Adam Gordon Bell. He does a great job interviewing people, and it's a really cool podcast. So if you get a chance to listen to that, but I got turned on from his podcast, I got turned on another one. Uh, there's a guy named Matt Godbolt and uh Ben Rady. They do a podcast called Two's Compliment, and it it's kind of funny because it really reminds me of the podcast Wolf and I do, runtime arguments. Uh anyway, these guys are doing a super job at podcasting. They've got about 65 episodes, and we listen to a whole bunch of those on our road trip. And you know, if you get a chance, check those guys out because they do a great job. It's two's compliment. Uh search for that, you know, wherever you find your podcasts. And uh they do a great job. Um, okay, so let's get on to feedback. Uh and like I said, I promise we will get to Wolf's uh uh talking about essential tools soon. Um uh for for uh uh feedback though, um we um we did a pod uh we did an episode uh a couple of weeks ago on POSIX. Uh and I talked about how how POSIX um is is um uh interesting and maybe not quite as relevant as it or as necessary as it used to be. Uh and I talked about how uh Apple's uh Mac OS is POSIX compliant, but there were a few goofy things about it. And I mentioned that uh the Z shell used by Mac OS is not POSIX compliant, but uh Oliver Kittle uh poked his head in and and mentioned that um ZSH actually does have a POSIX compatible mode uh that you can enable. And if you invoke it as slash BNSH, it it will be in POSIX mode. And that's very much like Bash uh uh does. Uh it's the same thing. Bash really isn't POSIX compliant, but it has a compatible mode if you invoke it as uh BNSH. So uh Z Shell and Bash are are quite similar that way. Um I mentioned we we did the essential nudge uh episode. Um and I pointed out uh that I think uh understanding or uh having an understanding of the C programming language uh is important. I believe it's important for software developers to have a good understanding of that. Um a lot of people disagree with me, but I I still reserve that uh the right to have that opinion. And Wolf turned me on to a new book uh from Paul J. Lucas, uh, and the name of the book is Why Learn C? And he makes the same argument I tried to make about how it's it's important to understand fundamentals. Uh so I've been reading the book and I haven't really gotten to the part where he thoroughly explains why it's important to understand C, but so far the book is doing a great job of teaching C. So if anybody out there really wants to jump in and learn C, I know the KR book is like the uh de facto standard on on learning C, but it's uh it's a reference book. Uh this guy's book, uh uh Paul's book, uh really does a nice job of teaching you C. So if you want to learn C, uh it's a great place to start. So check that out. Um we we uh talked also during that episode, the essential uh knowledge episode, about um you know the things I said, the the languages and stuff. Um and w Wolf and I had a conversation last week, uh, like we do every Saturday, we go to lunch at a sushi place in Ann Arbor. And uh we talked about uh what it means to be a well rounded software developer. Um and I kind of made a point. That you can be a great Python programmer, you can be a great Java programmer. Um, I I I like to think I'm a pretty good Perl programmer, uh, but I think the real goal is to be an all-around software developer who understands languages and tools and all kinds of stuff stuff. And um I I'm I'm kind of hoping that you get that out of this this episode. Uh you really, you know, anybody can handle a problem when uh can handle programming when they've got a uh a specific task to do. And knowing these tools and stuff is great, but when things go wrong, there's a whole nother set of tools that that uh you should have in your toolbox. Um anyway, I've been rambling far too long. I think uh I think y'all are getting uh uh tired of listening to me. So uh let's uh let's turn it over to Wolf. Wolf, you want to jump in and tell us uh a little bit about tools?

Wolf: 20:57

I really do. Uh because as you know, I love tools. I'm so enthusiastic about the particular ones that I like the best and why and understanding them really well. Um before I actually jump in to the categories, um, I want to say a couple of things. Um First of all, this is about categories. Every single tool that I'm going to talk about, there's a zillion choices for why, excuse me, why you might want one for yourself and why that one might be different than the one I like for myself. Um and it's not about my opinion. It's about what fits your use case, what fits the problems. That's one thing I want to make sure I say up front. Um the second thing is um I I I I guess I'm a little um uh uh you know uh very focused on certain kinds of things, compulsions and whatnot. Or I stack things, I arrange them by high. I can't help myself. OCD, maybe you know, I I don't want to compare myself to someone who really is OCD because they are facing a whole set of challenges that I'm not, but I feel um those things. I want things to be right for me. So when I get a shelf at IKEA, the first thing I do every time is I open the instructions to the page that is a picture of all of the tools and parts that you need. And I take all of the tools and parts that I actually have for this task and I lay them out in distinct, easy-to-get-to piles. Maybe it doesn't look like the picture, but I prove to myself that I'm ready to go, that I have everything. And as sort of a side thing, I already know that for such and such a tool, I know how to use that tool. Um I'm gonna jump back into the end of this uh little anecdote at the end of the conversations. Let's start talking about categories, and I'm gonna start um at the most important part, and that is source code control. Um we have something that other um disciplines don't have. Uh, we have source code control. And it doesn't matter whether the one that you choose for yourself is Git or Subversion or um uh Mercurial or uh Jujutsu. Uh there there are a ton, and there's all different reasons why you might choose one. Um there is one called Visual Source Safe, that's sort of historical. That is not actually a source code control system, and if anyone ever tries to tell you that it is, punch them in the face. Um you absolutely need source code control. You need it before you need anything else. You need it because uh it's going to take care of you, it's gonna keep everything you produce uh in a place where you can get to it. Yes, uh it enables sharing and teamwork and collaboration, but you need it even if this is the very first thing you've ever done. Even if you're just learning a brand new language. Um, source code control gives you infinite undo. All you have to do is save at the right places. Um, it gives you the ability to experiment, to try a whole brand new thing, completely and catastrophically fail, and go right back to a place that worked perfectly. It gives you the ability to release something to your end users that works, even while you're in the middle of construction and all kinds of weird crap is going on. I know you think you don't need source control when you're working alone, but you do. Um now I've got my favorite, it's git. Um, depending on how you feel about the command line or whatever tool uh that gives you a graphical interface to uh your uh your tools. Maybe Git is right for you, maybe it's not. Um Git is certainly the most common and best supported. Um so let me just tell you the misconceptions you might be starting with, and then we'll move on to the next category. Um programmers think source code control is only for teams. I'm alone, obviously, I don't need it. Uh that's backwards. You need it, especially when you're alone. Uh the reason you need it, especially when you're alone, is nobody else has a copy of the source. There's no rest of your team. There's no backup. And because you're not sharing, you probably didn't push it to a server. So, source code control is gonna help you there. Um the solo benefits, and uh let me tell you, one of the absolute best things that's in Git, other source code control systems give you this. But in a good situation, if you've arranged your um, I'm gonna use the word commits, but checkpoints essentially is what we're saying, correctly. That means that each new time that you added to your repository, it was one whole thing that worked by itself. Then if a problem shows up, but you can't remember where the problem was, um there's a couple things. One is you can go back to any previous version and see does it work without that problem? But many of these source code control systems provide a mechanism by which you can um actually search for the single commit that introduced the problem. In Git it's called Git Bisect. Um yeah, you need to do things the right way for it to be as helpful as possible, but it's one of the most powerful features. Learning how to use whatever source code control system is right for you is a project. They are complicated. Git might be the most complicated. There are easy ones, there are hard ones, but it's not gonna be something you pick up in a day.

Jim: 28:27

Um You know, I um I I started using source code control like in the mid-80s. Uh i yeah, I've been programming for a long time. Uh I used SCCS. Did you ever get a chance to use that?

Wolf: 28:40

I actually used RCS and then SCCS.

Jim: 28:45

Yeah. Uh so I did, I kind of made the progression from SCCS to CVS, and CVS was a huge, huge uh uh improvement over SCCS. Uh and then I moved up to subversion, which again was a huge improvement over CVS. And then Wolf convinced me to to start Git. And I don't know how long ago that was. Seven years ago, eight years ago. Uh I've been using Git for a long time now, and it is it is amazing, and it's uh uh it saved my butt several times. So yeah, it it's it's a it's a good one.

Wolf: 29:22

Yeah. Um alright. I'm gonna jump into the next category. Are you ready, Jim?

Jim: 29:29

I sure am.

Wolf: 29:30

Alright. The next category, um I know the first thing that an ordinary person thinks about when they talk about this category. This category is choosing the right language um for your situation. And normally what goes through your brain is, oh, I'm a Python programmer, I'm gonna write it in Python. That has nothing to do with the problem wrong. Um it turns out that languages are good at certain kinds of problems. Um maybe Python is the right language for your problem. Maybe Rust is, maybe Perl is, maybe Java is, uh, maybe C is. Uh but you don't get to pick the language just because it's the one you're good at. Being good at it is absolutely a factor. And if you're in a team, and that's the language the whole team is good at, it's a huge factor. But the thing you were hired to do is to solve a problem. And if some other language makes solving that problem easier to do, cheaper, run faster at the end, and give you a better answer, then it's part of your job to figure out if you can afford to try that other language. Um learning a new language is a project, same as source code control. And there are factors that are gonna drive um what language you choose. Uh number one is the problem domain. If you are writing a web app, um web apps generally have a front end and a back end. The front end is almost always written in JavaScript. Um you're gonna have a very strong uh influence to write in JavaScript for the front end. The back end can be almost anything. The second is the ecosystem. Um, what libraries in the language that you're looking at for this this instant, what libraries does that language have that are uh uh specifically about your problem? Um it turns out that um for instance if you're doing mathematical work, um there are libraries, um pandas and numpy and polars and uh interesting things like that, uh those all work in Python and they're super important to solving a certain class of problems, they might um actually uh be the straw that breaks the back that makes Python be the right language for your problem. I think NumPy actually runs in multiple um environments, it's underlying written in C, so it's certain that uh you can use NumPy in other places. And like I said before, your team and the context uh of your uh work, that's a huge influence. If and I gotta admit right up front, um as an engineer, as an individual contributor, maybe even as an architect, this is often a l a choice you don't get to make. Sometimes it's the head of engineering or the VP or the CEO of your company that says, um, yeah, I've heard Haskell, it's great, let's use Haskell. Um and the truth is uh they're they might be great guys. They might or or women or whatever, they might um understand the problem domain really well, they might be terrific with customers, but almost always they are not qualified to make the decision I just said, and yet you're gonna have to live with it. Um so what your team does know, if you happen to be a Java shop, well, there's some heavy weight on the Java side of the scale. How is your um end result going to be deployed? Is it gonna be embedded? Um maybe that means it's an Arduino and you have to write it not just in C, but in a special version of C that runs on Arduinos. Is it gonna be a web app that requires servers? Is it gonna be something that goes inside of um I I who knows? But the deployment context makes a big difference. Um there's not a best language. Um I have some favorites, but if you ask me what language should I use, you didn't tell me enough for me to answer that question. I need the whole rest of that sentence. What language should I use to, and then you tell me what problem you're solving, and then we can talk. If you just say something in general, uh, well, there's a lot of general choices. Um so if the language that you have found is a significantly better fit for the problem you're getting paid to to solve, that's worth knowing. If the ecosystem around that language um makes you more productive, that matters. If your whole team or your company is all about such and such a language, that matters. Um if you're just trying to teach yourself a new language, and that's the project, well then your choice is made. Uh at no point did I ever say anything about z some new language being trendy or flashy or new or best. Those words, if somebody says, hey, let's use blah, because it's great, let's use zig because it's the the new hotness, you know there might be reasons for using zig, but zig being the new hotness is absolutely not one of them. Uh so think back to episode uh one, the you are not Google. It's really episode 14, but uh the problem comes first. Um that's true for your language choice as well. And remember, use what exists. Language ecosystems are huge collections of existing solutions. Um and believe it or not, they're better than you could write yourself if you had to write all of them. If you only have to write one, yeah, maybe, and you only have to consider one particular situation, okay, sure. You can write something better than that general purpose solution that comes with your language. Um, but I guarantee you didn't cover all the edge cases. And remember, you are not Google. Don't choose languages for problems you don't actually have. Uh and that's what I have to say about languages. How do you feel about that, Jim?

Jim: 37:15

Um, great stuff. You know, I've got a quote that I want to read to you. Uh and I uh I I I've probably said this to you to you before. You sort of talk about uh you shouldn't write your own stuff. Um Alan Kay is is like the uh how do you describe him? He's like the AI guy. Well, he's the father of small talk. The father of small talk, okay. He he had this uh uh this quote, uh, this quote is from him uh from The Power of the Context. Uh I think that was a book uh that he either wrote or or was in. Anyway, it here it is. In programming, there's a widespread first-order theory that one shouldn't build one's own tools, languages, and especially operating systems. This is true. An incredible amount of time has gone and energy has gone down these rat holes. On the second hand, if you can build your own tools, languages, and operating systems, then you absolutely should, because the leverage that can be obtained and often the time not wasted in trying to fix other people's not quite right tools can be incredible. I'm not sure that that quote holds up because there's awesome tools that people have spent an awesome amount of time, an awful lot of time, uh uh writing for us. Um so maybe it's not true anymore that you should write your own tools. And maybe I like the first half of that tool better.

Wolf: 38:37

Apply uh my personal opinion to that comment. Um I believe both sides of that equation, and like absolutely everything else that I have talked about in every previous episode, that I'm going to talk about in this episode, and that I'm going to harp on in the future, that is this. Yeah, both those are true. Um you shouldn't write it yourself. Uh or you should write it yourself because you can do a better job for your specific case, and you should know the difference. Yeah. Because neither one of those is true all the time, and the only way to know the difference is to know how much better your version could be, how much it would cost for you to write it, and how much you would save if you had it. If you knew those things, you'd be able to pick.

Jim: 39:37

Yeah. Okay.

Wolf: 39:39

You ready to move on to category three? Let's move on. All right. Category three is a lot like languages in that you probably already have one. This is your editor. Um editors, I I'm sort of reminded of Blade Runner. Um at the Beginning of Blade Runner, um he's in the Tyrell Corporation talking to some Tyrell people, um, and they're asking him about uh what he does and how he relates to replicants, and he says, a replicant is like any other machine, it's either a benefit or a hazard. If it's a benefit, it's not my problem. Editors are like any other piece of software. Um either they are going to help you or they are not. You really liking one, you probably like it because it does help you, but you ought to know the different things that editors can do for you so that you know if your editor is doing everything it could. Um the most popular editor in the world, as far as I understand it, is maybe VS Code. Um that's not the editor for me. Uh uh I can I don't have any problem with people using VS Code, and VS Code does do a lot of the really important things I'm gonna talk about. But what you need to know about editors is first of all, it absolutely doesn't matter what anybody else thinks. Um if you want to use VS Code and VS Code does everything you need, use it. If you want to use Notepad and Notepad does everything you need, use that. I will fight with you because I don't think Notepad does do everything you need, but maybe it does. Um just don't don't listen to, you know, Vim versus Emacs guys. Um that doesn't matter. Um that's so that's important. Second thing is, does it run where you need it to run? Um if you're writing on Windows, does it run on Windows? If you're doing most of your editing across an SSH connection, does it work on files across SSH? Either by being able to run locally and open them remotely, or by running remotely where the file is and showing you everything you need across the connection, does it do that? Um if you're working on a single file, almost anything will do. If you're working on a project, can it do all the magical project things like you're looking at a word? Take me to the place where this word is defined, even if it's in a different file? Does it know the language that you're working on? Does it uh even if, for instance, a particular function name um appears a thousand times in your source project, a hundred files, um, in only twenty of those, maybe, is it a specific function that you mean? Can you in a single command rename just that one and leave all the other uses of that collection of letters untouched? My editor can do that. Vim can do it with the right plugin. Um you need a thing called an LSP, a language server protocol plugin, uh, for whatever editor you're using. VS Code can use them, Vim can use them, Emacs can use them, Helix can use them. Um so an editor is where you are going to spend a lot of your time. You should be good at it. It's worth practicing. You should know your editor at least as well as you know your language. You should be able to do all the important editing things that it does. Some editors are even bigger than um a little tiny uh program that knows about files. Some editors integrate tons of tools together. Like they know how to run your tests and how to debug the application, run your debugger, and they know how to publish. Uh, for instance, the JetBrains IDEs do this. Usually an editor that knows how to do these things is called an IDE, an integrated development environment. Um, I am gonna describe briefly my setup, not to tell you what to do, but just to give you an example. Um I I have been a Vim user for decades, but I have switched over the course of maybe the last 10 months to Helix. I use Helix for almost all editing. Um and it is fast, it's keyboard driven, it's modal. That makes it super easy for me to use. So that's all at ease of use. It supports the language server protocol directly, so all those language things I talked about, it does out of the box. Um it works on every platform that I work on. Uh so GitBash for Windows, uh WSL where I run Ubuntu, um, an actual Ubuntu machine, it works on uh my Macintosh, uh, so I can use it everywhere, and it's lightweight, it stays out of the way. It runs in my terminal, and everything that I use to influence terminal apps just impact it. Sometimes I need a little more uh in terms of an IDE. Like uh PyCharm has an integrated debugger that is graphical. Uh I am gonna talk about debuggers a little later. Um sometimes I'll switch over to PyCharm. Um it's a rare occurrence, but it's there when I need it. And the important thing uh to talk about with respect to that is I'm talking about categories of tools. This is not a multiple choice problem. It is checkboxes. One editor might not be enough for you, one language might not be enough for you. In a super fast program that I'm writing that uses Python, we use the numpy library that's C underneath. I switch between multiple editors. Sometimes you need more than one. Um so how much does the editor matter? Uh well, it matters a lot. Because like I said, um that's where you're gonna be spending uh all your time. But does it matter as much as I don't want to say Vim salesman or VS Code aficionado or Helix Lover? Um these these people want you to try Helix or VS Code or Vim or whatever, and they're really gonna make it sound like the editor is super important. But the actual answer is the editor is only as important as the job. Does it do the thing it's supposed to do and then get out of your way? If it does that, I don't care what you use. Use what makes you feel good, just make sure it does the job. Um I think that's about all I have to say about editors. Um I know you have strong opinions on editors, Jim, uh, and especially configuration. Um anything you want to say to that?

Jim: 48:17

I don't know. You know, I'm a Vim user. I I haven't moved up to anything more fancy than that. Uh and it it I don't use a lot of plugins in my editor because I have to edit on all kinds of different machines and just dragging all those plugins around, something I'm not really willing to do. Um and it and it just works for me. So I'm I'm quite happy. I also do a lot of um uh iOS development, and for that, really the only platform to use for developing iOS programs is Xcode. Uh and that's really the first IDE that I've ever really used. Um it's nice. Xcode is horrible. Um I I I Okay, some people might think it's horrible. I I really like it, it really works well for me. Um you know, being the only IDE that I've ever used, I can't compare it to others. But uh it it works. You know, I can do the refactoring. I can uh if I'm looking at a function call, I can uh click uh something and and get uh the definition of that function. And that's that I'm not doing that in Vim. Uh and I really like that in Xcode. Uh so that's kind of and it just works. Um uh anyway, that's kind of my environment, Vim uh on Linux or Vim on Mac OS uh Xcode.

Wolf: 49:34

At lunch, when we were discussing this, um you asked me, and I don't think we actually said the words aside from knowing the language, um, you asked me uh what's the feature of my editor that I couldn't live without. Yeah. Um and it's the thing, uh, and I told you this, that I made you install as a plugin. It's the thing that made you use plugins in Vim. Like you didn't use any plugins before I gave you this plugin.

Jim: 50:08

Right.

Wolf: 50:08

And I can't live without um the thing that in Vim is called surround.

Jim: 50:16

Yeah. That's a pretty nice that that's that's a nice enough thing that I did install the plugin. Uh and I really like that. Uh tell tell us what Surround does for those people who don't use it.

Wolf: 50:27

So however it is in your editor that you choose some text to operate on, surround um gives you some powers over that range. Uh the easiest is it can stick stuff around it, like parentheses. So you've got an expression, you suddenly realize things are happening in the wrong order, you pick just the sub expression that you need, and you put parentheses around it. Um in Vim you could actually make that be a function call. That's one of the things the surround plugin does. Instead of surrounding with parentheses, you can surround with a function, which automatically puts the parentheses, all you have to do is type the name. Um in uh helix, once you've done the surround, you still have a selection and you are um in uh normal mode with a selection. If you just type I, you'll be in insert mode at the beginning of that selection. So you don't even need a special function thing to put function in. Um but surround does a lot of things. It can uh add and remove any character that you want. Some of them are matches, like open square bracket and close square bracket. Some of them are just the same character twice. Um it can remove existing ones, it can change. Oh, I didn't want parentheses, I wanted square brackets. No problem. You can just do it. Um that's what surround does.

Jim: 52:04

I use a little bit you know, I I use that. Um when I'm editing HTML, I really like attributes, uh attribute values to be surrounded in quotes. And our system has a lot of HTML. And I'll go through if I'm editing a file and I see that uh you know it's uh class equals something, and the thing it equals doesn't have quotes around it. Uh I think the keystroker YSIW quote. And the YSIW will surround that word with quotes. So I type that once, and then as I'm moving through the file, I just hit dot, because in Vim you get to repeat the last command with dot. So I just get to move down the list, dot, dot, dot, dot, and it just surrounds all those words with quotes. I love it. Saves me a lot of time and it and it solves a uh uh a pet peeve of mine of values not being in quotes.

SPEAKER_01: 52:59

Yeah.

Jim: 53:01

Uh one more thing before you jump into the next thing. If uh if while you're listening to this, you think you hear a dog barking in the background, uh, you do. Uh I'm not hearing it right now, but earlier we heard a dog barking in the background. I believe that's Oscar, uh, one of Wolf's dogs.

Wolf: 53:17

I have many dogs. And if there's a barker, it's probably Snick.

Jim: 53:23

Um, but Okay. If you hear it, yes, you're hearing a dog bark. It's no big deal because we all we all love dogs. And and that's fine. But yeah, you're not going crazy, you're hearing a dog. Okay.

Wolf: 53:40

I am going to talk about uh two things in a row. Jim and I disagreed a little bit about these things. Um he says they're really one thing, and I say they're two, but it doesn't matter. Uh when programming started and we invented fire, um there was only one way to debug. Well, this is once you could actually have stuff uh on your printer or on your screen or something. And that way was print. You can print some value. Um printing is absolutely the easiest, ready to go, fastest to use, well, unless you're using a really slow compiled language. Some languages are both compiled and not dependency aware and slow, um, and so you have to end up compiling the whole thing. If that's your world, print kind of sucks for you, sorry. Um but if you're if you're in a world where you only have to compile that one file or it's interpreted or any of those things, maybe print's a lot better. So printing and its big brother logging, um, which gives you often a lot more control, um, those are things that can give you a snapshot. Um remember uh we talked about measurement and understanding uh what what your code is doing, what what uh things cost. Printing is the very first look into the runtime state of your code. What's the value of X? Print X. Um so it's immediate, it's simple, it's universal, it's persistent, it's low barrier. Um, it's absolutely everything that you want. Um logging gives you a lot more power. Usually you'll get to logging through some additional library that you use, but it uh lets you control where the output goes, filters it, makes it so that it doesn't even happen at different levels, like is this an info message or a warning or is it critical? Things like that. Um logging's the more sophisticated answer. Uh but remember, when you are approaching something that is a piece of your problem, start with the simplest thing that can reasonably work. And a lot of times that's print. Um so printing is uh pretty easy. What's what's your thinking on that, Jim?

Jim: 56:45

Printing is great. Uh when I'm you know, I do a lot of Perl programming, and by far the easiest way to debug that is uh with the print statements in the right places. Uh I've I've cranked up the uh the Perl debugger occasionally, but I have to look up uh how to use it every time I do. And most of the time I just need to know what's going on in the program. Um logging, I do a lot of logging in our system. For the past couple of years, we've been putting logging through our throughout our system. Um, and really what that does for us is uh we we we push all of our logging messages to the database. And I'll give you an example. We uh the system that I run for my customers is a it's for in the medical uh industry, and uh it might be um there's a process that the the user goes through that might generate a high risk letter for the patient if they're at risk for getting cancer. And what used to happen all the time is I'd get a I'd get a uh an email or a or a chat message or something saying, Jim, um this patient didn't get a high risk letter. Can you can you figure out why? So I started putting logging in everywhere, and I give users access to the logs, certain users, uh access to view the logs. And I've got a really nice log viewer that they can filter on various things, and and uh so now it'll tell them. I I I put log messages in, like within my code, there's logic that says uh if for instance, if the patient qualifies for a high risk letter, then we're gonna print a high risk high risk letter. And what I've started doing is on the else of that, I'll also put a log message to say why I didn't generate a high risk letter for that patient. So now they don't call me anymore, they just look in the log and say, ah, the patient uh didn't get a uh high risk letter because uh their risk score was was only 12 out of 100. So they they're not technically high risk. It shows them right there. They don't have to ask me, I don't have to go digging through code and try to figure out what's going on. It's all in the log. Very, very useful. So yeah.

Wolf: 58:57

Uh you should probably point out that you log into the database. Your logs are saved in a place where they are going to be safe.

Jim: 59:08

Yeah, I got tired of searching through the Apache log file for all these messages. So everything we log goes into the database, and uh the user has an as a uh a UI uh so that they can view that. Um and it's uh and it's good. And also, because it's in the database and we log pretty much everything we do, it can generate an awful lot of stuff. Uh I've got a cron job that runs weekly and it goes through looking one of the things it looks at is the log file, and we will prune entries out of the log file. I I think we keep log entries for like 90 days. Um, if somebody needs to know why something happened, 90 days is plenty uh for that kind of thing. So yeah, watch out if you are logging, don't run out of disk, right?

Wolf: 59:53

You know a nice thing about logging is it's usually more it it happens that I I work with data that is big. Uh you know, huge geometries, point clouds, uh giant data frames from pandas. Um it is often, not always, but often uh better, more controllable, more useful to log huge things like that than it is to print them.

Jim: 1:00:23

Yeah. Yeah, yeah. I I I think it's a great way to do it. So yeah. So let's move on to the next thing after logging. All right. And print statements.

Wolf: 1:00:35

The next thing is a debugger, an actual debugger. Um this is kind of the nuclear option. Um I'm gonna be completely candid with you. When there's something wrong with my program, I actually don't even start with print. I start by putting the entire uh you know, function or whatever thing is on my screen, and I look. I just look at it, and I think to myself, what what did I do? Why is this how could this watch this? How could this be somehow doing something that is not what I meant for it to do? And 80% of the time that's enough. Uh and then sometimes I have to print. And every once in a while you have to start a debugger. Now there's all different levels of debuggers and debugging. Um and Jim, when we discussed this, uh his argument at that moment was that printing uh is the lowest level of the debugger. Um and I uh said my personal belief is there is a difference between a debugger and printing, and that is that when you print, the program you are in is the one you're writing that's going to be the customer's answer. And when you're debugging, the program you are in is the debugger. And it knows about your program, but your program is stopped, and the debugger can tell you all kinds of things about it. Up and down stack frames and stuff like that. I feel like that's a difference. Maybe it is, maybe it's not.

Jim: 1:02:30

Sure it is. It tells you a lot, the debugger will tell you a lot about the program, like you said. It absolutely will. Yes, stacks and stuff. Yeah.

Wolf: 1:02:40

Um so let me give you a little hierarchy of uh debuggers. We already talked about print. The next level up is a REPL-like debugger. REPL stands for uh read uh evaluate print loop. Um so for example, GDB, uh which is for any language that you compiled with one of the GNU compilers. GCC stands for the GNU compiler collection. Or uh PDB is the uh built-in Python uh debugger. There's an enhanced version of that called IPDB. The step from print to one of these REPL debuggers is huge because um these things let you put breakpoints in your code uh and stop there. Automatically enter the debugger. Those breakpoints can be conditional. Only stop here if such and such is true, and you can do it on demand. Um like I didn't know, oh, I want to stop here when the ID of the uh segment is 5 when I was writing the program. But I know now, and so now, before it ever gets to that, I'm gonna add the breakpoint while the program is running. Um some of these things you can do in source code. Uh Python has a uh breakpoint uh keyword, um, which you can put inside an if or you know anything like that.

Jim: 1:04:26

Keyword in JavaScript.

Wolf: 1:04:28

Right.

SPEAKER_03: 1:04:28

Yeah.

Wolf: 1:04:29

Um so uh a thing that you can do in a debugger is you can execute arbitrary code. If you have a function that looks at your data and calculates the maximum, you can ask that question. You can make it happen right there. Um you if you wanted to do that, you'd have to know in advance when you were running the code. Uh w before you ran the code, if you were gonna do that without a debugger. Um debuggers um can let you change um the answer. If you're looking at some piece of data, you can strip away. Throw like your d your data is five-dimensional. Throw away four dimensions. You can do that in the debugger because you have access to that object. Um your debugger can let you move the execution point. It's about to evaluate an if. You don't want to do the if. You want to do the else instead. The debugger will let you do that. And debuggers do this amazing thing called watch points. Um in a regular pro um print statement or an ordinary, you're gonna put a break somewhere, a break point or a debugger statement, you can say, when you get to here, stop. Or when you get to here and segment ID is stop is five, stop. A watch point is not where, it's what. So for instance, um you have some piece of data and you want to stop when that data changes. Not at some particular place, the data gets changed all over. And maybe you even want to do something complicated, like calculate the max, like we just said before, and if the max is greater than a hundred, then stop. A watch point gives that to you. Um so that's the next level up, a REPL debugger. A GUI debugger, like you get from um uh PyCharm or whatever, it's a not a huge leap from a REPL debugger, but you don't ever have to say list, because it's always showing you where you are, it's visual. But there is a step up even from there, and that is um if you have an environment that's not about your program and running your program, but is about importing and executing anything in the language of your program, and your program's all built out of packages and stuff. For example, um iPython or Jupyter Notebooks is a go-to for me if I ever get to this stage. I can import a broken library from from my program and say, hey, how long is this segment? Um and the segment is actually a raw geometry object from post-JIS or whatever, base geometry, and I can calculate length, that's a JIS function, or or I can use um shapely or or whatever. I can test those things, not even in my program, just importing all the things my program imports. Do you ever get to this level? Probably, if you're listening, you never even thought about this level. But it's there. And some problems warrant it, and it is a possibility. Um Debuggers shine when you are facing a really complicated state problem. When you're at this particular place with this particular kind of data, and when you evaluate this function, you get back this weird thing. Yeah, you could write a print statement that could catch that. It's just easier in the debugger. And one of the great things about debuggers is to print, you sorta have to already know where to look. In the debugger, you can be at a bad place, figure out, oh, the value of Z is wrong. Well, Z got passed in. How did Z get to B wrong? And there's uh uh ordered list of stacks, stack uh entries, frames. You can step up and down that list and look at how did Z get that value. You can go through the five things that called it without ever adding a print statement. That's magical. Um that is a reason why people use debuggers. Um remember, back in the first part of this uh pair of episodes, we talked about uh errors in validation. Debuggers are gonna let you look inside and see why. Remember testing, um, a good test framework, and hopefully you're using one, will do something nice for you like uh automatically take you into the debugger right at the point where the test fails. That's how mine works, um, and I use it all the time. Remember how I said measure everything? Some debuggers include profiling features. Um remember how I said you're still learning about the problem? Debuggers are part of that learning. Um I think that covers everything I wanted to say about debuggers, Jim. Uh what what do you have on your mind?

Jim: 1:11:04

There's there's one place you shouldn't use a debugger, right?

Wolf: 1:11:07

There is. There is definitely, at least for me, a place that I specifically complained to you about. Um, and that is this. I have found that when I'm trying to debug stuff that's not on the main thread, I probably would have preferred print. Printing or logging just works better in threaded situations than at least the debuggers I've been using.

Jim: 1:11:39

Yeah, and it's funny because threaded code is where you always have goofy bugs that you really could use a debugger for. Yeah, it just gets tricky. It's not unbelievable. But yeah. Anyway. So yeah, uh, I I find the the debugger in JavaScript, I I I I use Google Chrome a lot, and the debugger there is fantastic. And it's really pretty much the same debugger as you get in uh Safari. Um and it's great. And the debugger in in uh Firefox is fantastic as well. Uh those tools are are so powerful. Uh so I use those debuggers all the time when I'm when I'm debugging JavaScript code. Uh I just don't use it so much when I'm in like the Perl code or personal.

Wolf: 1:12:25

My problem with the browser JavaScript debuggers is that the bad guys have your code and those debuggers.

Jim: 1:12:36

Oh yeah. Yeah, they could yeah, that's the thing about JavaScript, right? The the code is there.

Wolf: 1:12:42

But you ready for um the very last thing? Yeah. Alright. The last thing is less about um specific tools. I am gonna name some tools. It is one of the things I hit in uh You Are Not Google, and that is you you gotta be about the measurement. You have to be looking. Are you solving the right problem? Is your ladder leaned up against the right wall? Is it tall enough to take you over the wall? These are things you're only gonna know by profiling your code, by measuring it. Some of these are tools you're gonna write yourself. Some of these are tools like the one of the most common is a tool called perf. Um your language uh andor uh some of the frameworks or libraries that you use, they're gonna come with tools that help you do do this. Uming you're going to the right place and that you're applying your effort to the right pieces of your solution. I I want to tell you, uh, when I was a young man, I don't know, 14, 15, um I had a saxophone. I was trying to be a saxophone player. Um, in my whole life, I never became good enough to call myself a musician. I became okay, um, better than my peers. But at that time I r I I was not good. And I had weekly lessons with um my uh departed but excellent saxophone teacher Bob Cole. Um boy, that guy was fantastic, and I learned a lot of things from him, not just about um saxophones, and one of those things, maybe one of the most important things I ever learned from him, I'm gonna say right now, um, the jazz band, and I was in the jazz band, um, we were trying to learn a song pretty complicated called Sweet Georgia Brown. Everybody knows it. It's a hard song, lots of notes, and we sucked. Um, it was it was terrible. Um, and I'm kind of compulsive, like we've talked about before. I had done practicing, so I walked in and sat down, my horn was out, and he said, Alright, play it. And so I played it. I I didn't play all of it. I played the part I was good at. Of course. And he stopped me almost immediately, and I don't remember his exact words, but they came down to this. And he said it doesn't help you to practice the part you're already good at. You gotta practice the parts you suck at. Um It doesn't help you to improve the parts of your program that are already good enough. You gotta improve the parts that suck. That suck enough to make a difference. And there's only one way you're gonna know which parts those are, and that's by measurement. So I harp on measurement every time. Um it's important, you're not going to get to where you want to be without doing it. Do it. Um telemetry, we've talked about, it's part of that. It's measurement when it's actually in the hands of your end users. Um there are some expensive tools that help you do that, but mostly you're gonna write stuff yourself. Um figure out what matters. That's the first thing you care about. And then once you do know what matters, figure out if you're doing it good enough. Um And that's my feeling about the categories. Now it the thing that I that has been exposed in my many, many lunches with Jim is that Jim and I have different thoughts on almost everything. These are the categories I think are the most important and valuable tools, and you ought to have an answer to every one of those categories, whether it's one tool or two tools or whatever. But Jim, I know you've got opinions. Yeah, you don't know that.

Jim: 1:17:21

I agree 100% with everything you've said so far. Uh to me, though, I think you're missing a couple of things. And here's one that I thought we should have mentioned uh in part one of this, and I forgot about it. And and uh uh that is Docker. Uh Docker is a huge tool. Um knowledge of Docker, and and it probably belongs in the other other episode, but knowing how to use Docker, knowing how to construct a Docker Docker file if you want to create your own Docker images. Um huge tool that is in in this day and age, really, really important because that lets you create environments uh to run your app in that don't infect your host, right? Uh-huh. Uh and you can play with versions and all kinds of stuff. So I I've been using Docker for a few years now, and it's really, really important. So that's in my in my toolbox. Uh, and I I suggest that it should be in everybody's toolbox. Uh, but then you get into some tools, you know. You talked a lot about how to make programs that are great, but when things go wrong, uh obviously a debugger is helpful. Uh profiling is really valuable. But there's a couple of tools I've used. I'm sorry.

Wolf: 1:18:33

Just taking notes. Yeah. What did you see? What did you write? Write that stuff down. Anyway, start to interrupt.

Jim: 1:18:40

Okay. So here's a couple of tools. I I I used to use them all the time, and that is uh S-trace. Have you ever had to use S-trace to track a program?

Wolf: 1:18:48

Um I I don't directly work on Linux a lot. Okay. So I don't use S-trace very often. Um but I have used it, and by the way, I have used Docker. And both of those tools were helpful when I needed them. Yeah.

Jim: 1:19:04

So I absolutely support you. Uh so S-trace and L trace, I think, are really important tools to know how to use and how to read the output. Because uh like S-trace can spit out an awful lot of output. What that is, is it's tracing system calls. So you run your program under S-trace and it'll show you all the system calls it's making with all the arguments that it's passing. And if you can't figure out why your program is crashing, uh maybe you're getting a seg fault or something. Uh S Trace uh will kind of show you the system calls it's making, and oftentimes it's because it it dies because it tried to open a file that it couldn't find. Uh, and it didn't tell you that in the output. The thing just croaked. Um, and you can use S trace and it'll show you the files it's trying to open. And and um uh a lot of times that helps. You know, it might be a config file it's looking for or something. Uh S Trace is really available there. Uh L trace is for library calls, it's a similar kind of thing. Um, and then there's a bunch of Network tools that are invaluable to me. I use them quite often. TCP dump. If you ever want to know what's going across the wire when you're doing network programming, TCP dump is really, really important. Wireshark, if you want the graphical version of TCP dump, uh, a lot of times what I'll do is use TCP dump to actually capture the packets into a pcap file, and then I'll load uh uh uh download those to my desktop where I run Wireshark and I can analyze that file. Really, really important. And then simple tools uh Netstat, IFconfig, uh, on Linux the IP command. Uh, and then one last tool that I use occasionally for uh when I'm doing like API stuff, curl. Curl is a really important tool to me. Um learn those tools.

Wolf: 1:20:45

If you if you know what you're doing, curl is just as good as Postman.

Jim: 1:20:52

Yeah, and you know, I I I've dabbled with Postman a little bit, but curl is like the Swiss army knife of of uh uh uh fetching things from the web, especially if you want to do HTTP. Um curl is really, really important to me. So, you know, I I talked early at the beginning of this episode about being a well-rounded software developer, not just a Python programmer, not just a JavaScript developer, but a really well-rounded developer that knows all these tools. These things will really come in handy. Um so I I I suggest uh all of everything that Wolf talked about, and then this small handful of tools that I mentioned. Uh, if you learn those, you can be really valuable to your team.

Wolf: 1:21:35

Um so I have responses, of course. Um number one is the tools that you named, every one of those has been helpful to me. Knowing those tools, um, or knowing where you can find out more about them when the time comes and when they're just knowing they exist. Just knowing they exist. Um, that's a step up for almost everybody. Um that's one thing. Uh and another thing is in the knowledge and processes episode, I talked about building jigs, that there's lots of little things that aren't on the critical path, but having them make your world better. Um and I feel like some of the things that you said are kind of part of that. Uh I'm gonna use my own examples, like for instance, um, I use a tool called UV. I use um grep is important to me. I use the rip grep version, um, awk is important. Um you know I use tons of these tools. Uh in fact, when it comes to tools, I would say I probably have a lot more tools that I use that I keep trying to convince you to use.

Jim: 1:23:00

Well, what you have is uh like enhanced versions of the tools that I use.

SPEAKER_03: 1:23:06

Mm-hmm.

Jim: 1:23:06

And I'm perfectly happy with the versions that I use, but yeah, I get it. I know you've got some some some other tools with extra special powers.

Wolf: 1:23:15

Yeah. So yeah. Uh but absolutely uh having the the more skills the and and uh tools that you have at your fingertips, the better a job uh you might be able to do, probably can do. Uh but it's uh the and I'm gonna go back to a saxophone thing. Um I don't remember exactly the context of this. I think it was with the band director in high school. Um somebody was blaming their horn for how crappy they sounded, and um the band director said essentially this that if you're crappy, if you yourself are a bad saxophone player, a really great saxophone is gonna help you a little bit. Not a lot, but a little bit. But if you're a great saxophone player, it doesn't matter what you're playing. You could be here you know, some student horn, some piece of crap, and you would still sound astounding.

Jim: 1:24:27

You could make a kazoo sound good.

Wolf: 1:24:29

Right. Um In this outline, one of the sentences I skipped over was that um a uh great editor in the hands of a crappy programmer is not as uh powerful, as fast, um, as likely to produce a good result as a crappy editor in the hands of a great programmer. But if it's a great editor and it's the two of them together, uh that it's not even close. That's when magic happens. That is when magic happens. Um so let me um close my opening story uh and then uh tie everything together. Um I talked about putting together an IKEA shelf. In in our world, at the start of a project, um we don't know all the parts that we're gonna need. Um but we do know a lot of the tools. Um so before I start working on something, just like before I start assembling a bookcase, uh I make sure I have all the tools. And I have practiced with all my tools. Um I know how to use the things that I like. Um I like practicing with my tools. I'm enthusiastic about them. Um too enthusiastic, in fact. In fact, I I get on Jim's nerves. Um let me put together the takeaways. Oh, were you gonna say something, Jim? No, I completely agree. Sometimes you get on my nerves. Um so the takeaways aren't about specific tools. Um these are just categories. You will need an editor, you will need a language, you will need a source code control strategy. The first takeaway from this episode is the categories. Do you have the things you need? Um are you using those things when you actually need them? Have you been using print in situations where, boy, here is a place where it should have been a debugger. Um that's takeaway number one. Uh the second takeaway I'm gonna separate into a couple of different angles, but but maybe they sort of say the same thing. Um the the end result of these different angles on this one takeaway is you're gonna have to do a little research. Uh the first angle is do you know for some category everything your tool, the choice that you have made, do you know everything it could be doing for you? Did you know that your editor could fix every instance of this variable to have a different name, but only where it's actually that variable. Not where it just happens to be um the same spelling, but in a different function or something stupid like that. Because that's a thing an editor that knows your language can do. And a hundred other things. Uh there are tons of these smart editor refactorings, and Notepad can't do them. If you didn't know those things existed, why would you even bother looking at something besides Notepad? So that's the first angle. Um the second angle on this same thing is uh you gotta do the math. Once you understand there is an alternative, and that that alternative can do things that what you're using right now can't, is it enough better to switch? Um Jim used to use subversion. Um I taught him about Git. Uh Git was enough better than subversion that he did switch. Jim has been using them for decades. Is Helix enough better to make Jim switch? Um it is not. So the question is, is the juice worth the squeeze? There might be something better, but is it enough better? Um and the final angle is maybe one tool is not enough. Maybe your editor um isn't enough editor and you need two. Or maybe you need to combine your editor with said to do replacements. Uh said is not really something you would use every day out of the box as an editor. That's it's in the name, but that's not what you use.

Jim: 1:29:52

Real programmers use cat with greater than.

Wolf: 1:30:02

And finally, as always, for me, this is the last takeaway. The underlying theme is are you spending whatever it is you're spending, time, money, effort on the things with the biggest payback. Using a great editor, an editor that you are great at using, lets you work faster and more effectively. The right tool doing the right job at the right time helps you spend less on your way to the end goal. Um, so those are the takeaways, which I guess I'm gonna have to summarize in some really short form from the show notes. Um I think that's basically all I have to say today.

Jim: 1:30:48

I'm I'm gonna add one uh one takeaway, and that is it's not enough to have all these great tools. You really need to know how to use them. That to me is critical. Know the tools available to you and know how to use them.

Wolf: 1:31:04

Although sometimes the job, the problem that you're solving, is learning the tool. For sure. Learning how to use Git is a job, and you you're gonna do that job before you get to some job where Git is just one of the tools.

Jim: 1:31:23

All right, man. That's a lot of stuff to cover. Uh, this is a long episode. We covered a lot of good stuff. Uh I I had a blast uh doing this episode. Um as always, uh, thanks for listening. Um, I do have a couple of things I wanted to mention earlier. Um, I want to send a shout out to Alex in New York City. He is my sister-in-law's brother, and I looked it up. There's no relation between me and him. He's my sister-in-law's brother. Uh, he's a listener and he's loving us. So I would I just want to send him a shout-out. I think you'd get a kick out of that. Um, you know, I I've mentioned a few times in the past, uh, Wolf and I are both members of the Michigan Unix Users Group, MUG. Uh, and we're having an upcoming meeting on uh Tuesday, um December 9th, is it 6 30 p.m.? And that episode is based on uh a podcast episode we did back uh number 11, uh IPv6. We're basically going to do that live uh and this time with examples, which we can't really do in a uh in an audio only format. So yeah, if you enjoyed that episode, uh we're gonna be talking about IPv6 on uh December 9th. I will include uh a link to the website in the show notes. Um so if you're interested, come along. It's always a good time. All right. So thanks a lot. Uh if you have any feedback, please uh send it to feedback at runtimearguments.fm. Um I'm gonna include more ways to contact us in the show notes. Uh if you enjoyed this episode, uh tell your friends. We we want to get the word out. Tell everybody you know about it. And uh Wolf, uh any parting words?

Wolf: 1:33:14

Uh I gotta say, the feedback is super helpful to us. Being contacted by Oliver was great. We learned stuff from him and uh shared it with everybody. I think that was important. Please, if if we've made a mistake, if you can enhance what we've said, if you want to hear other things, if you want to say, yeah, this was good or that was bad, tell us. We want to know.

Jim: 1:33:40

Yeah, please let us know. Uh so yeah, so thanks everybody. Um looking forward to the next episode. Um goodbye. Bye, everybody.