Programming Throwdown - Debugging

Episode Date: June 3, 2015

This show covers Debugging: how to fix and maintain code across any language. Book of the Show Jason & Patrick: Mindhacking http://www.mindhacki.ng/ ★ Support this podcast on Patreon ★

Hosting provided by Host Tornado. They offer website hosting packages, dedicated servers, and VPS solutions. HostT.net. Programming Throwdown, Episode 43, Debugging. Take it away, Patrick. I want to start off with a rant. I very ranty person so this is easy for me this one is every time are you a ranty person yes that's true i rant a lot i need to see these

long emails that you send your co-workers no i don't i do it verbally because emails can be reproduced and like held against you versus like someone just recollecting what you said. And then you go, I didn't say that. I didn't say that. The worst is don't put an email. I don't want to talk about this in email. Sounds like proof you were doing something bad. Yeah.

Don't ever write an email saying like the lawyers will have a field day with this. Like, don't do that, please. Yeah. saying like the lawyers will have a field day with this like don't do that please um yeah so my thing is every time someone at work or on the internet whatever says i have a really easy programming problem that i think every programmer should be able to solve um and my rant is that uh so i work at a company that does technical interviews so if you do an interview for my company, then you have to actually like program as part of the interview. And I try to be very sensitive to the fact that programming during an interview is a very, very tough thing to do. And not everyone does. But I try to be very sensitive that fact, because a lot of times when other people who do interviews tell me their

interview problems, I think, well, I don't know how to solve that um and the truth is if i sat in the room and like tried like had to do it i probably could work through it um but i think my problem and i think a lot of other people have this problem is that there can be edge cases which even the person asking the problem either is being nefarious in having there or hasn't even thought of themselves yeah i had this situation where someone asked me to solve some interview question and then at some point during the interview they realized that they had just created a very bad question and didn't know it and it's it's not hard to do it's super easy to to make this mistake because like it's like anything right you don't

see like all the possible nuances that could happen so the classic one i remember is that i was in association for computing machinery programming competition in college and we went to one of the competitions with other schools and there was a question about they gave you a layout of supposedly an unfolded cube. So if you took a cube and you kind of like if it was made of paper and you unfolded it at the various faces laying on the table and it forms a pattern. Right. And there's various different patterns that form cubes. The easiest one being four squares in a row and then two wings kind of on opposite sides of the line. So if you have four squares in a row, one over, one under. But there are actually other valid patterns which form squares. And so when we looked at this problem,

they give you a pattern and you had to say whether or not it formed a complete cube. I actually remember solving exactly that problem. It was like the Southeast Regional Qualifier, right? It might have been. We may have. You and I didn't know each other then, but we may have both been there at this time. Oh, interesting. So this was a problem presented.

And one of the teams from our school afterwards talked about, oh, yeah, we saw this is really easy. You just look for four in a row horizontally or four vertically and then the two wings. And then you'll know, is it Cuban? If it's not, it's not. And they actually got it right submitting that solution. And then we pointed out, yeah, but there's edge cases where it's much more difficult to solve. You actually have to think about it in a more nuanced manner so our team didn't even end up attempting it uh to solve the problem because you know we thought like oh it'd be take a long time to figure out how to actually do all these edge cases um and it was probably solvable but it

turned out you didn't need to because the uh set the test set they used only had the most easy case in it this you know four in a row in two weeks it was super i happen to remember i mean not to go on like a rant on a rant but but that specific year that year i did particularly bad in the competition like our team did particularly bad and uh i remember a lot of the problems like i remember there being problems with the competition like that was one of them like that one i think we solved but it took a long time and other people solved it immediately and we couldn't figure out why yeah this is why yeah there was some other one where um just there was some there was an error in the test set and and no team got it right but it was kind of bs like oh man yeah i hated that year yeah i did yeah i did bad that year um but

okay so the reason that this rant is spawned is because i was reading i don't remember hacker news or reddit and um this this thing came across a website we'll have it linked in the show notes um the oh this is a weird name the blog is svpino.com yeah i think it's his name okay i don't know how to say that and i don't know what the blog i never read any other articles el valderrama okay so i can't recommend if anything else on the website it's good but this particular post that he got that you know became pretty popular was five programming problems every software engineer should be able to solve in less than an hour uh so i'm not sure if he means hour total or hour each um but he basically talks about you know people this is the if you ever hear the fizz buzz, oh, every programmer should be able to solve this fizz buzz problem.

You can look it up. Anyways, that, you know, people apply for programming jobs and they can't actually write just a for loop. You know, I want a for loop. This is like, this is actually a real problem. You think about it, like you can get somebody who no matter what they have on paper, like it's always possible. And it's even sometimes like probable that you will get someone who applies, who like literally does not know how to program. I mean, you can go through an entire computer science degree.

Like it's actually harder in the U S but especially more in like Europe and Asia, you can get like a PhD in computer science and never have written a single program it's entirely possible it is true i do give likely interview questions sometimes and the way to start off is you know kind of starts with like essentially write a for loop that goes through an array and looks for a specific number right no tricks no anything and yeah a lot of people can't get who have computer science degrees can't get that question and again i'm sensitive to the fact that in interviews it's very hard but okay so he gives a couple uh you know he gives up five

problems and the first uh two are really straightforward the third one uh is pretty easy calculate fibonacci numbers okay that that's actually i mean you can't use the brute force recursion way for only the first hundred so you actually can um uh yeah two to the hundredth that's like pretty huge still right no no but on a modern computer i think i think you're fine for the first hundred fair enough um also i think you he wants you to do it it looks like he's trying to say iteratively so you actually can just go through the whole list so you can just wait two to the hundredth no two still pretty, it's not 2 to the 100. No, that's the complexity.

Yeah, if you want the first 100 Fibonacci numbers, then like each, it's a split, right? Well, yes, if you calculate the 100th number recursively, naively. Yeah, right. That's true. But if you're doing it iteratively, you just have to keep an array and add the previous two numbers. No, no, I get that.

But I'm saying like, yeah, yeah, yeah. But what i'm saying is he's not asking for the nth number he's actually saying print the first 100 in a row oh which leads you to like doing it iteratively okay fair enough fair so i don't actually know to 100 may or may not i don't know okay but but okay that's why i'm saying that one maybe maybe not not. Okay. Right. Then the problem four, which I won't describe, you can go read. But basically, he gives you an array of numbers, 52, 1, 9, different numbers. And he's saying arrange them in any way possible to form the largest number if you kind of concatenate the digits together. Oh, okay. And he's saying this is like, oh, this is really easy. He presents, you know, he at some point presented a solution

that turned out not to even be correct. Yeah, this seems like extremely freaking hard. That's what I thought too. And I was like, oh, I feel really bad because random person on the internet says this is an easy question and I don't know that I could get it. I think this is, yeah, I mean, obviously like the numbers won't have that many digits, but I'm pretty sure this is uh yeah i mean i mean obviously like the numbers won't have that many

digits but i'm pretty sure this is like np complete where n is like the number of digits so like this could get hard right yes and depends like he doesn't give a bound here that like could the numbers each be are the numbers in the array there'd be a hundred numbers in the array like yeah right uh i don't know uh and then the last one is he gives you a list of numbers and you're supposed to uh put pluses or minus between them arbitrarily so that their sum is 100 again this is not straight like to me that's an incomplete problem this is not easy actually you might be able to use dynamic programming but yeah you're right like there's no they're not but these are not nobody i know can do all of these in an hour first time get it people won't be able to do

number five in an hour yes so my rant is simply that a lot of people say oh you know you should be able to do this in an hour this is easy for interviewing just be careful and don't like feel bad about yourself because like some random guy on the internet says you should be able to like oh this is easy and it turns out he may not even be right. And like Jason was pointing out, I also have seen people who said, this is an easy problem, told me what their interview problem was, told me what they think the solution is. And then I point out ways their solution is broken. And then like, oh, I forgot about those ways, you know, or something. So people sometimes like to say things are easy when they're really not.

Yeah, yeah, definitely. That's actually a good point. It's very hard in general, to figure out how difficult something is. And I mean, which true for interview coming up with interview questions, but also kind of as a metaphor for just being an engineer, especially, you know, when you have kind of time time constraints or when you have to impose define time constraints like someone tells you like how long is this going to take that that's a super hard question to answer and the good news is like in real life a lot of these problems i would solve by like we're saying you know how big can the array be um before you know it kind of takes too long it's like the way i would code it in real life which you can't do in an interview would be oh well i'll code it the naive way and then i'll put you know the you

know checks to make sure that the input amount i'll have is less than what i know runs in a reasonable time and then basically we'll try to catch when it goes to something more so initially like oh there's only five things in the system, but one day there may be a hundred. Well, the algorithm only works when there's 10. Well, I'm not going to write the algorithm that works for a hundred off the bat. I'll write the one that works for like 10. And then I'll just make sure the code self documents and checks that it's less than 10. And when it's greater than 10, we basically have to go rewrite it. Um, and maybe I'm a terrible person for doing that, but I don't want to get analysis paralysis uh and too often people spend the time writing the optimal for size million and they

never ends up being past size five or whatever right so so so the guy ends up writing the dynamic programming solution in his blog but i this is a perfect example of of like you know our point right yeah the point patrick's making is he solves the problem using dynamic programming and he probably feels really clever and everything but he calls his function f it's like now nobody can understand like you know what his code is but there's no documentation right yeah well and the point like he starts off with the context for it is like people who only know how to write you know css and html shouldn't be called a programmer you shouldn't be able to call yourself a programmer unless you can solve this problem and that's just really that's a bar far higher than i would put for calling yourself a programmer um now it may be that your company doesn't want to hire someone who can't do dynamic

programming sure fine whatever that's up for debate but that doesn't mean they're not a programmer or a good programmer because they can't come up with dynamic programming solutions right i mean at the end of the day computers are cheap and uh you, making something that's easy to read and making it so that if you quit, the person behind you can take your place is way more important than writing the best dynamic programming solution, right? Yeah, I can count on one, maybe two hands, the number of times in my entire career where I've needed to use, like, the algorithm I chose actually made an impactful difference. Yeah. Most of the times it doesn't matter. Architecture can matter sometimes, but like, you know, true textbook algorithms.

Anyways, so my anti-rant, if you really want to go through programming problems with data sets and that like other people have done, we have some resources. One is Topcoder, which is, even if you don't do the competitions offered by TopCoder, they have past problem sets

and the example inputs and outputs. So you can actually submit your code and see if it works or not. And they give a pretty, what I find to be pretty accurate, although it's still pretty difficult. But the ones they say are easy are typically pretty easy.

Now, hard ones could be really, really hard, but the easy ones... Well, one thing about top coders, they have the editorials. So the people who write the problems also take the best solution. And they're good about not just taking their own solution. Like, actually, at the end of the contest, they look at all the solutions and they find the most interesting one and they document it and write literally write an editorial like you with links to wikipedia and like math dot stack exchange and everything so like you could do a top coder contest and then go back and look at the editorial and and learn what you didn't know

it's very awesome the other ones are good. We'll link all three of them. But Topcoder by far is the best for this reason. Oh man, my news article's up first and it's time for the news. The first link I have, which is not really news, is NAND to Tetris. So NAND is a type of logic gate, a not and. So it's an and with a not and it is one of

the gates uh nor being the other one i think where you can build every other logic gate out of nan so knots ores and exclusive ores can be built entirely from nand gates so once you understand how a nand gate works you can combine them to form all other bits of logic and once you understand how the bits of logic work you can build circuits and then computers um and so this takes you this massively online course mooc m-o-o-c yeah massive online something course uh offered i don't know actually i'll look it up uh on coursera so i haven't taken this one but i skimmed through the accompanying textbook, and I heard some good stuff about this. Massive open online courses.

Open, open, okay. So is this free? I don't know how long it's been out, and I can't recommend whether or not the actual videos in the course that we'll link is good, but they have books. And it takes you all the way from NAND logic through building a microprocessor, writing assembly for that microprocessor. And this is my understanding through,

mostly through simulators versus actual chips. But the idea is still there about system, microcontroller architecture, assembly. And I guess supposedly at the end, you actually make a Tetris game on your processor that you've built from nand gates and i think this is something i did something of course pretty similar to this only it wasn't so awesomely named or uh we didn't make tetris at the end um but i did something similar you

go from all the way logic gates up to a microprocessor um you know you're on your own from scratch and that was really insightful into learning about how processors work and trade-offs and decisions that are made in processor design. Cool. So if you're a low level person or you want to learn more about it, I recommend it. If you're a high level person, I don't know, maybe. Do we ever, I don't think we ever explained if we haven't, if we've ever explained it, it's definitely been years ago.

So low level, that doesn't mean low on the totem pole or anything like that. Low level means that you're working closer to the metal. No, we talked about this, right? The guys doing CUDA who are getting rich. Oh, okay. It means lower, it means closer to the metal which which is a which is a metaphor uh your paraphrase or whatever you call it a metaphor for uh you know writing you know like assembly code c code things which are um things which

where the code looks very which looks more similar to machine code than, than something that's very high level, like like prologue or something. Yeah. It's also something more too, to me, like you could write C Linux applications and I wouldn't really call that low level per se, but like if you're writing Linux or you're writing Linux drivers or you're

writing stuff that runs without an operating system or controls hardware, you know, talks out to PCI bus stuff or, right? Like these kinds of things that involve hardware. And you need to, for instance, read vendor-supplied data sheets for hardware components or worry about clock cycles that stuff takes. You know, like that kind of stuff becomes low-level, yeah. Yeah, that makes sense.

So mine is creating art for engineers and so uh wait wait art to be enjoyed by engineers no this is sort of like uh uh four engineers in the sense of like like there'd be a book for dummies oh okay so this is like yeah creating art for art dummies so how and teaching engineers how to create art exactly yeah that's right and so uh i read through this i haven't gone through in great detail yet but i do think it's pretty cool it's written in a very sort of um uh it takes sort of the affirmative is that what that's called or the imperative it takes over an imperative stance or it's like kind of it's it's all written in the second person like do this don't do that don't don't forget to do that it's kind of cool um and uh yeah i thought it was pretty cool article

um you know as i said in the previous show um kind of getting more into drawing is like a hobby and things like that so this this fit well with that for me so uh yeah if you're interested in doing some drawing releasing your creative energy uh check out this article it's pretty cool how is your drawing journey going it's going pretty good actually i uh um yeah i've been i'm bringing pretty close so you know i'm drawing basically i have i have a list of photographs that i want to make drawings of like not i don't literally want to trace the photograph but i just want to do a sketch of it and so i'm kind of making my way through it and i should be done in you know maybe like a couple of months wow that's very good so you do like photorealistic drawing no they're they're meant to be abstract but the photograph's meant to be like an

inspiration for the drawing so uh yeah i'll have to show you some okay uh maybe i'll post one to the to the blog or something totally on topic yeah right so my next link is google put out a how to become a software engineer but i thought this was kind of interesting because a lot of people would like to work at Google. And so people talk about that a lot. And there's a lot of online writing about getting into Google or not. And so this is Google's recommendation on academic learnings is what they call it. And they basically go through, you know, some links to Udacity courses, Coursera courses, MIT courses for object-oriented programming,

you know, learning C++, Java, Python, other languages, how to test, test methodologies. Like a lot of the stuff we talk about in this show, how to build compilers, a lot of things that they, you know, I guess, feel is important for engineers who work there to... i'm surprised they put learn artificial intelligence as like a staple so i when i read this like read through this and tried to understand it uh well first of all using the guide checking off all items on this guide does not guarantee

a job at google i think legitimately honest checking off all these items would take a lifetime. Yeah. Right. To actually learn every single item on here. And then to be, I think what they're saying is like, these are the areas you want to at least to be high level familiar with. And,

you know, more than one or two of them, you probably should be pretty good at. Gotcha. Or do some of them are just things to do um anyways but we'll have the link in the show notes it is interesting if nothing more than it has a lot of links to good uh mooks word of the show apparently massively open online courses free that's right free courses for you to take like there's i didn't know this of course there of course on compilers cryptography uh heterogeneous parallel processing um that would be cool that would be uh gpus which we've talked

about one of the ways um anyways so check it out what does heterogeneous mean in that context it just means instead of like lots of cores which are the same you have different cores which have different uh specialties. Like GPUs are good at some things versus a CPU is good at others. So therefore, a system with both is heterogeneous. And you have to divide the work so that the best parts run on the best things. Gotcha. That makes sense. Cool, man. Very cool.

That's a great resource. So, yeah, so I checked this out recently. It's called Docker, and it's the final news story. It's pretty cool. Basically, so imagine, you know, you build some cool website, like in Java or something, and you get it running on your laptop, and you can connect to, you know, local your local host and visit your website and you have a database that's also running on your laptop and everything's pretty cool and then you you know take your code move it to the server and it totally blows up you say well what happened you find out oh the server is running a different version of Linux the server is running a different version of the database.

It's running a different version of Java, and that version doesn't support your thing, so on and so forth, right? And it's super frustrating. So Python had this pretty cool thing a while back, which still exists, but it's been around for a while, called VirtualEnv, which was basically like a Python environment in a directory. So you could have some directory that has a Python build in it and a bunch of other stuff in it, and then you could say virtualenv in the directory, and it would put you in that environment, and it would sort of freeze your version of Python. Ruby has RVM, which is very similar.

So you can, like, now when you send your code to the server, you also send Ruby itself. And so you're guaranteeing that the Ruby you run on the server is the same Ruby you ran on your laptop when you're testing it, right? So Docker kind of takes that idea to the extreme. So they have containers for everything. They have like a database container. They have a, you know, Ruby container, Python container, so on and so forth.

And you sort of depend on these containers when you build your application which is also a container so then when you go to the database when you go to the server to run your application you just tell it look i want exactly these versions of java and python and all that stuff and it handles it for you and so what you end up with on the server is you might have a server running, you might have a computer running like 10 different web servers on it. And so it has 10 different versions of Java, 10 different versions of Python, so on and so forth. And Docker kind of manages all of that so that they don't conflict with each other. And everyone gets exactly the environment that they had when they were developing. So it's pretty awesome.

It's picked up a lot of steam. There was kind of like things that sort of hokey things that kind of did similar as this, but they didn't work 100%. And this kind of was the first thing that really was extremely solid, and so it took off. Definitely check it out. It's pretty awesome i have not used docker before but i it's become all the buzz i hear about it all the time now yeah it's pretty sweet um i to be honest i've only done kind of the bare minimal like i'm running some simple internal stuff at work on it um i haven't used it in like a

heavy production environment but it did exactly what i wanted it to do which is which is pretty cool nice well it's time for book of the show and this week we have a special guest but first uh this won't be applicable to the special guest interview, our first ever interview. Congratulations to us. But I want to remind people that we still have our Audible 30-day free, I guess one book free trial going on. So if you want to check that out, you can go to www.audibletrial.com slash programming throwdown.

Check out some books. We typically, every show offer, at least I offer awesome science fiction and fantasy recommendations jason typically takes the high road and offers uh something to make you a better person um but yeah anyways so you can check that out audible trial.com programming throwdown um but this week we have a special interview with sir John Hargrave. That's right. As Patrick said, it's our inaugural interview. And we actually have Sir John Hargrave here to talk about his book, Mind Hacking.

And I took a look at it and it's pretty cool. It's basically, and you definitely do a better summary than I would, but from just from going through making a pass at it, it looked like it like sort of a book about how all of us can try to sort of open up our mind, be more creative, tackle projects a little bit more diligence and follow through and things like that. And so I'm excited to finish it. I'm about halfway through. Yeah, that's great great thanks for having me on i've been sitting

here in the background for the entire show waiting for my segment so it's good to be on great hors d'oeuvres back there by the way cool those crackles of energy mind hacking is all about reprogramming your mind and i'm excited to be on your show because mind hacking is really the greatest programming language you can learn because your mind is behind everything you do. So in the book, we talk a lot about debugging your mind. that hold you back, but then reprogramming those thoughts, like reprogramming a computer to really help you not only achieve your goals, but to feel great and improve your life. Cool. I know a lot of the people who are listening to the show, they're either getting into programming and these kinds of things for the first time as part of a you know a college endeavor or a late high school endeavor or they are people who you know kind of picked picked a different profession we've seen everything from chemical engineering to someone who manufactures lightsabers for a living

and they just programming started off as a hobby and they want to take it to the next level and they want to do something something more important with it or bigger with it or just learn and enhance their body of knowledge. And so I think this book is pretty cool for that. Yeah, and that's my background too. You know, I came of age just as personal computers were starting to take off. And in the beginning of the book, I talk a lot about my experiences with my first programming classes. And, you know, by the end of the semester of my first programming class, you know by the end of the semester of my my first programming

class i was teaching the teachers and i talk a lot about you know exploring things like a semi legal phone switching software but i got involved with it let you make free phone calls and just that sense of playfulness and curiosity and fun that really characterized the early personal computing revolution. So I can really relate to your audience. And I love that sense of learning something new and then also of exploration of what computers can do. And that's really that same sense of curiosity and fun that I tried to bring to this mind hacking concept, approaching our minds with that same sense of curiosity. Cool, cool. Yeah, I thought that your background definitely is worth, you know, having a discussion on. I mean, I was absolutely, I read the book first, actually,

I went through and then i went in and kind of dug in it was absolutely fascinating the sort of different things that you've been involved in it was it was really quite interesting um how you've been sort of in the entertainment field and then in the entrepreneurial field and then helping other people um you know motivating other people to to take advances and the whole thing has just been fascinating kind of walk us through sort of the path that got you to to writing this book well i was born on a small farm in tennessee uh as as you said uh you know i started out as a. So I started out as a developer early in my career. I started out with a company that's still around called ZDNet.com, one of the biggest

computing sites out there. And it really just gave me, it was a fantastic time because it was as the internet was just starting to take off. And those years were really magical. That was really just a moment in history. And it just cemented my love for technology and all things geeky and ran a humor site called Zugg.com for many years and also had this business, Media Shower. And so as the years went on, Media Shower continued to grow. And I now run that full time. We're a content marketing company.

But along the way, I really learned being an entrepreneur and also wrestling with my own demons and working toward my own goals that my biggest enemy was my mind. It was the thing that held me back most often. And I say in the book, your mind can be your greatest friend and also your worst enemy. And what we need, I am convinced as a society, is tools to learn how to manage our own minds. Think of all the effort we put into educating people about math and science and reading and writing, but we don't talk about that most basic skill of learning how to manage your own mind. So that's really become my passion is sharing with people, here are some of the hacks or the tricks that I learned to manage my own mind and get to where I am today. And I want to help them do the same.

Cool. I actually, I was one of those people early in life where I didn't really care about history or in history classes or anything like that. And i didn't i read a lot of you know sort of geeky things a lot of kind of fiction books but i didn't read a lot of self-help books or or anything like that and at some point i've i kind of realized i was learning a lot of things the hard way and uh just really starting from scratch on things. And over time, especially if you have to go and get an advanced degree and you have to publish papers and things like that, you realize that it's a lot easier to build on the shoulders of giants, so to speak, right? So that's when I started really getting into, you know, digesting a lot of information, reading a lot of information about people who are writing about their experiences, their history,

and also sort of how they can sort of what they've learned in some kind of specialty. Right. So one of my favorite books I keep going back to in the show is, is the dummies guide to negotiation and uh i read that just because i was uh um was curious what a dummies book was and i'd always been making fun of them for for you know the label they put in and everything like that but then i ended up being just one of the best books i've ever read in my whole life and um so now i'm kind of a big fan of people who have gone through very interesting, especially very eclectic experiences, sort of learning from them and building on top of that. And so I think

this is one of those books that can really help people. Thanks. Yeah, I'm a fan of the For Dummies books too. DOS For Dummies was the first, I mean, that was the first For Dummies book. That was the first one I owned. DOS was, of course, course the original pc operating system and it was confusing if you didn't have much of a technology background and what they did that was brilliant was they just pulled in humor and they made it very accessible you know they they explained it in plain english and it was funny and it had cartoons in it and lots of eye candy. And that's been basically the formula they've used for that franchising empire. And it is relevant because that's very much what we've tried to do with mind hacking is take this very kind of arcane sort of philosophical concept of your mind

and managing your mind, but put lots of humor and put lots of real life examples around it. We tell lots of stories of great, you know, great geeks throughout history, great technological innovations, and how we can use those to manage our own minds. So I'm glad you enjoyed it. Thank you for that, Jason. Yes. So what part from the point, just kind of following the history of the book, from the point where, you know, you started having this downward spiral with addiction to where the Secret Service comes knocking on your door to where you managed to beat those demons and where, you know, in your own words, you hack your mind and you're able to sort of you know get better control of yourself and your your family and your destiny

all the way up to running this company so at what point did you decide you know i'm going to write a self-help book this is always one of these things that interests me like when do programming language inventors decide you know screw it i'm not going to use C++ anymore. I'm going to invent my own language. It's a massive undertaking. And I feel like in the case of programming language inventors, a lot of them are the kind of people that they just don't settle for what's out there. They don't want to use tools that are inferior. And at some point they say, you know, this is worth the five year investment it's going to make for me to spin up this language and generate support. So at what

point for you did it sort of click and you said, okay, I'm going to write this book and invest this time? It's a great question. And I guess the best answer I can give is that I heard once someone say, you should only write a book if you can't help not writing the book. So in other words, if there is a spontaneous expression that rises up within you that says you must write this book, that's a really good reason to write a book. And I think the same is true when you're developing a programming language or you're doing any kind of great creative work that there is a drive, there's a passion that springs up from within you and you just know this is what I have to do.

This is the next thing that I've really got to be involved with. How did you guys decide to do this podcast? You know, there was something in you that said, we've got to do this podcast. There was something in you that said, we've got to do this podcast. And you do it and you put your heart and your passion into it. And eventually it starts to click with people. And that's how we move these things forward. So I think that's the quick answer to your question. There's a passion. There's's an energy there's an excitement that should drive us to do these these great things and when we feel it we got to act on it gotcha so along those lines and i haven't read the entire book yet so i feel like this might be in one of those areas of the

book that i haven't read near the end but how do you where does the sustainability come from i mean i feel like i have a million different side projects and of that you know programming down throw down is among the few that where the sustainability is there and where it's really kind of gotten off the chopping block and it's become kind of a real thing that we have going here but so many projects, kind of they just the momentum dies out, the idea fizzles out. And just there's there's plenty of people out there can relate to this, where they have this great idea, they have that energy. And then after a few weeks, it's gone, or after the fun part is done, it's gone, and they can't kind of execute. So how does mind hacking help with that part of it?

Yeah, so in the end of the book, which you'll get to as soon as we finish this podcast tonight, we talk about the ability to act. In other words, once you kind of debug your mind, you clarify your thinking, you plan, you kind of reprogram your mind with these new values and these new goals. Well, then how do you make that happen? How do you bring it out into the world? And what you're asking is, how do you persist? So how do you continue to do it? And there's a whole chapter on this where we talk about breaking up your goals into sub goals. We have an acronym called LASER, which talks about the best kinds of goals and how to make those repeatable and something that you can do day after day to really start to make progress toward those

goals. But what generally happens is people have negative loops that kind of go on in their mind that sort of drain their mental energy. And because that's happening, they lose momentum in continuing to push on those projects. So for example, you might be very excited about this new programming project on day one. And then day three, other concerns and worries start seeping in.

We call these your negative thought loops or your negative habits. And then that starts to drain the energy that you want to put into this main project. cut off those sort of energy leaks from your thinking and reprogram those negative loops, you'll have more energy to keep putting into these projects that you're passionate about and make some real progress. Gotcha. Yeah. I feel like a lot of it, and this is just looking back empirically at the things that I've done, and Patrick, maybe you can chime in one way or the other, whether you agree with this, is a lot of it for me has been about the philosophy. Like, the reason why programming throwdown is really interesting to me is that I've always wanted to teach, and I was torn between becoming a professor and going into industry, and I feel

like this was a way to sort of get the best of both worlds to kind of teach myself and teach other people about programming and then also to kind of have have an industry job and uh i think that because there's sort of a philosophy philosophical reason behind it that's what sort of keeps it going when you're in i guess as you say one of these negative loops where you have to spend you know four hours putting together the show and then at the end the notes uh you know your your computer crashes and you lose all your notes you have to spend another four hours redoing it when those things happen it's this sort of philosophy that sort of is that positive light that keeps shining,

that keeps you going through the parts that aren't very fun. Yeah, you're helping people, right? And that's, I think, what you're saying is that you're providing a real value, a service with this podcast. And in the book, we talk about collaboration and we talk about, you know, that's another great way of staying focused on these goals is collaborating or thinking about what can I give back and how can I help people and how can I work with people to do something that's greater than myself. Yeah, or even if it is more self-centered, like your goal is to make an awesome to-do list website. That's often one thing that we tell people when they ask uh well you know what's the first thing i can build um even if that is your goal it's uh it's

good to sort of stay focused on that like instead of instead of saying i'm going to make the the fastest uh you know game engine i can and then you end up with you know a small piece of a game engine if the goal is sort of like very abstract and kind of philosophical, you can try to then you're fine sort of maybe cutting corners here and there or doing the not so pretty solution or things like that. Because because the goal is something that's that's kind of much more high level. Yeah. In the book, there's there's a whole section about just barely good enough, right? JBGE. So the object is to get code or to get projects that are just barely good enough. It's the same concept as kind of agile development.

We want to just get something out. So many of us suffer from perfectionism. We suffer from wanting everything to be perfect before we can feel like it's worthy of being released. But if we can adopt an attitude of I just want to move the ball forward, I want to take a small step today toward this goal. I want to just get something produced and get it live and get it out there. And then I can iterate. Right. I can continue to improve based on feedback that I receive. And that's why I would say to anybody listening to this podcast, it's a lot of work to produce content. And what Jason

and Patrick do is it takes a lot of time for, you know, this hour that you're listening to it here, many hours are going on behind the scenes. So the best thing you can do for any of your favorite content producers is thank them, is just give them positive feedback. When you do that, it really is incredibly motivating. And in many ways, it's like the only reward that you're really getting. You're not getting paid for it. Read all those iTunes reviews, at least the positive ones anyways. Yeah, definitely.

Cool. Patrick, do you have any questions? I was just going to comment. The minimally viable product, Lean Startup, is the other idea that goes along with what we're talking about. And, The Lean Startup. But yeah, that's a fantastic book. It's one that a lot of people keep going back to. And at least here, it always seems like everyone's kind of read that book. So that's always a good sign. The Lean Startup is one of the foundational books behind our company, Media Shower. We talk about it in employee training whenever we bring on new folks. And I think it's a fantastic book that really does drive home that point of it's much better to get something live than to get it perfect. Just get it done.

Don't get it perfect. But also constantly improve, constantly iterate on it, and just keep chipping away and making your product better and better. Yeah, I feel like there's this misconception that the minimally viable product means you're not working hard enough. But it's really that you're working so hard and so fast that you can change directions quickly. And it's more that you're still running, but not in a straight line. You're constantly pivoting as you learn more and as you iterate. And that's just supremely important. Yeah, the misnomer about, I say in the book, in just barely good enough is that, as you said, it's pretty low quality.

It's just barely good enough. It's not very good, but the truth is, it's actually the best possible because you get the most accomplished with the minimum amount of effort. So from an efficiency standpoint or from an elegant standpoint, it is the most efficient, best solution. And it's self-recognizing that no strategy survives first contact with the enemy, right? So you're trying to make something for someone else, and when you finally put something out there, it won't be right.

Yeah, that's right. At the first time anyway. Yeah, that's a great point. You need to get that feedback. Yeah, thanks a lot for coming on the show. The book is fascinating. I'm going to read the other half right now. Actually, by the time you guys listen to this, I would have to read the other half right now actually by the time

you guys listen to this i would have already read the other half and you haven't even started yet so uh you guys out there have to have to catch up cool um excellent sir john hargrave it was great having you on the show on our book of this show and our also first interview ever on Programming Throwdown. So thank you for bearing with us while we had our inaugural interview and got everything going here. It was my pleasure. And I'm going to go back off to the green room now. It's off to the right, down the hall to the right.

Yeah, that's right. The long hallway just past the mansion, the stables and the helicopter pad. All right. Thanks, guys. All right. Thanks a lot. Have a good one. hallway just uh past the mansion the stables and the helicopter pad all right thanks guys all right thanks a lot have a good one yeah time for tool of the show to to the tool of the show so um i don't think we talked about this one in our unix commands um show but even if we probably did but it's awesome enough to use again that's right if you If you're using Baboon, which you should be after our last show on Windows, or you are running Mac or Linux, you have access to this amazing utility. And if you're ever using CP, you probably should be using RS, which you alias to rsync.

So rsync is basically cp on steroids so you know first of all any command cp can do rs can do just naturally um it's faster um it also well in certain cases it's faster it's not always faster but uh um also it has some pretty awesome capabilities. So if you do rsync-raz, then what it will do is it will look at the destination and look at the source and only copy what's changed. So that's pretty cool if you're copying to a server and maybe you're doing it every day or something like that. Definitely use rsync, right? You don't want to waste all that bandwidth.

It has a number of other really cool features. It can do one-way synchronization. It can do clobbering or no clobbering, which means if you delete something on the source, it will delete it on the destination, so on and so forth. Basically, it has a ton of functionality like this you know you can do it across computers like you can actually rsync to an ssh endpoint you don't have to rsync just from one directory to the other um i think some versions can even rsync to ftp servers like it's kind of crazy but i know it can do ssh um and uh yeah i use it all the time I think it's pretty great rsync yeah all one word rsnyc yeah my tool of the show is not a software tool

it is a multimeter multimeter depending on I was wondering if like you're gonna say oh this is an android app or ios app nope this is a good old-fashioned lives in your toolbox electrical measuring device nice i have one behind me but i won't get it out do you oh well it won't come we won't be able to see it in the audio version anyways so um so the reason why this is my tool of the show is because although we're software engineers uh it is very useful sometimes. Wow, that was a lot of caveats. I find it to be useful to have and know how to use a multimeter.

I'm going to look it up. No, I looked it up. It's actually both, which is why I'm saying both. I asked Google, define multimeter. I switch back and forth on how I say it. A multimeter, if i switch back and forth on how i say it so um anyways a multimeter it you know allows you it's a if you don't know it's a physical object which has two wires coming out of it and one's red one's black typically and allows you to measure voltage uh resistance sometimes um other it's called you know a multimeter because it multiple different things and you're able to

for instance if you have like around the house I have them just to measure like is this battery dead or not and you can buy those specific battery testers or you can just measure the voltage with your multimeter also I use it for like doing conductivity testing like um if i have like a wire like a you know be really careful i shouldn't recommend what i do with it because if you're doing electrical stuff around your house be really safe and make sure the power is off yeah i mean but like your fuse box know what your fuse box is yes but but yes i use it a lot around the house um but also at work i do low level uh programming so often i have hardware and it's important for me to be able to tell, like, various voltages on my development boards that we have.

And so I need to be able to tell, is, you know, something on or off? What's the power draw in a given region of the board? These kinds of things. And so I find this tool indispensable. And it really makes people you work with who are in other disciplines, you know, appreciate that you know more than just your niche. So a lot of people think, you know, software engineers just know software. And then when you kind of know how to use tools properly, then they, you know, kind of gives you a little bit more respect.

Yeah, you definitely get some street cred. Yeah. All the cool kids are using them. Yeah, all the cool kids are using multimeters. Ah cool kids using multimeters ah yes so cool that's my tool of the week probably useless do you have any do you have any so actually i was wondering to ask you this a little bit of side note but if i was to get any of these sort of starter kits like a beagle board or raspberry pi uh nerd kit uh like like which of these should I get? As somebody who knows virtually nothing about this stuff.

Raspberry Pi and BeagleBone are kind of the same thing, in my opinion. They are different, but they're at the same level, which is they're small Linux computers. And so if you want to do both powerful Linux internet-y things and also be able to control

hardware, they're really good. Do they have the I2C connector and all that stuff? Yeah, I think they have it brought out to a GPIO header, like a set of pins, so you can talk I2C to other devices. And then there's lots of libraries for doing that. Of course, personally, I find doing I2C in Linux to just be overcomplicated. People do do it, and there's libraries to help you do it.

And if you were gonna develop something that you wanted to also have like displayed on your computer, for instance, or be a web server, that's the way to go. But if you're looking to just learn about hardware, because personally I like doing in my spare time what I don't do in my work time. Right.

And so like, if you do kind of that programming a lot, it may be lean more towards like something that's Arduino based because an Arduino isn't going to have an operating system. It's going to be much more just about the hardware. The programs are going to tend to be simpler. They won't be able to do as much per se, but they're going to be better at timing and controlling hardware because they're simpler things.

And they'll also be cheaper typically. Gotcha. So that's the approach. Okay, so Arduino isduino is what you that's that's the approach i would take if you really are wanting to learn about like i2c devices spi devices um blinking leds that kind of stuff i feel like it's more straightforward to get there on an arduino than a raspberry pi okay cool good to know does arduino have like a wi-fi chip can you can you they do have one but it is pretty expensive okay got it but yeah like but then if i was going to do wi-fi something i'd probably i might go with like a raspberry pi because like wi-fi is complicated um ah okay right but like you could always start on an arduino talk to like if you're going to talk

to sensors and stuff like if you want to read a temperature and send you an email when the temperature gets over 75 degrees yeah exactly like you could start on an arduino for instance and like learn how to talk to the sensors read it and you can hook it up to your computer right so you can like plug in the usb cord to your computer and it'll show up as a serial port then you can just write a simple program to read the temperature off the serial port send the email and then once that's working like you have all the pieces that if you wanted to do it, like on a Raspberry Pi, you would just strip out one little part in the middle and kind of put the other two pieces on the Raspberry Pi and do the same thing. Got it. But yeah, people forget you on your Arduino. It plugs into your computer.

It can. it can yeah me I wanted to Write something that you does world domination, but I figure like getting the temperature of your house is pretty much the same thing, okay? And then and then stream it over cereal Yes, so then yeah, I mean it would be fine All right cool time for our debugging discussion. Debugging. Debugging. Debugging.

Debug, like defense. Debugging. Debugging. Well, first, Jason, tell us about the kinds of things you would need to debug. Yeah, so what are the kind of problems you have as a coder? So the most obvious is a crasher, right? So you have, I'm writing my temperature sensor that also takes over the world, and I divide

by the current temperature. And all of a sudden, strangely enough, when it's 0 degrees Celsius, my program crashes, because there's a divide by 0. that's why you shouldn't use celsius tons of hate mail now yeah i mean that's also why you shouldn't use metric stop stop stop no no this is not our real belief yeah these are not our real opinions okay so uh second is hang or slowness right so a hang is where you know it just all of a sudden they also call it a freeze you know it's where it's just you've entered some bad state and just nothing yeah it's gonna be like an infinite loop for

instance like it's just stuck yeah exactly or infinite recursion yeah it's continuing continuing just so incredibly slowly that it feels like it's frozen. Wrong answer where you expected the answer, the meaning of life, and you got 43 and a half. And it's like, whoops. Memory or thread leak. So if your program, over time, the memory usage goes up, up, up, up up up up but eventually your computer runs out of memory and dies or if you know every few seconds you're creating a thread and you're not deleting any threads you know after like 30 40 000 of that you'll your computer will run out of threads and blow up um these are all uh these are all real things that can happen

and uh so that's i figure that covers the majority of the bugs. Yeah, there's other ones. You could get the common ones on a computer with an operating system, like a page fault. Like if you have an errant pointer, you try to null dereference. So most of these, I guess, would apply. That would apply to a C or C++. If you had null and you tried to dereference it,

typically that will get caught by the operating system and you'll you'll get some sort of crash so i guess that's a crasher but um caused by a different oh yeah yeah yeah actually no you you're right we should have like a buffer overrun oh buffer overruns are another one yeah yeah so buffer overrun is very simply you know you uh uh you have an array of size four, and you try and get the 27th element of that array. You're actually, you know, in C or a low-level language, you will get something, but it definitely won't be what you want.

Or you might get a crash, depending. Oh, I guess that's, yeah, that's true. Like, if you have the protected access or protected memory space or, yeah. So in the good case, it crashes. Like if you have the protected access or protected memory space. Yeah. So in the good case, it crashes. In the bad case, you just get a number that is probably close to, it could very well be a sensible number, but not what you want. Yeah.

Makes sense. So then the techniques for debugging. So I was telling Jason before the show, I actually consider myself to be pretty good at debugging, mostly because I tend to be able to track down where the problem is and isolate it very quickly, if not fix it. Not all the time, right? I'm not saying I'm the world's best, but I just find this I call divide and conquer, which is basically about finding out where the problem is not. So if you know there's a problem in the code, the more of the code you can say it's not a problem, then the faster you can find what is the problem. So a lot of people I find try to consider everything in the system that influences a given answer. So you get 43 and a half. Well, what are all the inputs that influences a given answer right so you get 43

and a half well what are all the inputs that lead to give me 43 and a half um and that can you know if you just sit there and think about it conceptually it can take a long time versus dividing and conquering would be like going and saying okay here's a bunch of computation and then i add to it this other bunch of computation and i know what the results of you know the left half should be and what the results of, you know, the left half should be and what the results of the right half should be. And you look for which half has the wrong answer. And then you keep tracing back and you keep dividing, right?

And you're eliminating whole portions of the system. Yeah, I do exactly the same thing. I just kind of thought everyone did that. No, no. Really? Yeah. Oh, all right. Like a lot of people I'm saying is like,

they try to look like audit the code or like think conceptually for like long periods of time and say where could be the problem. Versus me, I'm much more likely to just start going in and start like using techniques we're about to talk about, like just start hacking up the code and like look for what gets the right or wrong answer and where does it go wrong.

Yeah, I'm exactly the same way. But that is not common. Wow. Or at least it may be, I haven't, i don't observe that to be the case and i'm not saying that way it's always faster because if you sit there and think about it meditatively it's log n time yeah but if you think about it meditatively you could get it like right away right a login login algorithm isn't always the an n squared algorithm could be faster if N is super, super, super small. Yeah, or I guess it's order one if you just look at the file

and know the answer. Well, it's the whole coefficient thing, right? So mine might be order N-squared, but with a big coefficient... Or order a login algorithm, but with a big coefficient. And then you may have an N-squared algorithm with a tiny coefficient.

Yeah, yeah. Anyways, blah, blah, blah, that was nerdy. And so yeah, so I mean, that works for some people, but for me, I find it very useful, even conceptually, just to think about like what systems are in or out of play in trying to find the problem. Yeah, that makes sense. So another technique is logging.

Obviously, the simplest is print statements. So if the function takes in two ints and is supposed to return their sum, and it's returning something completely bogus, then you want to put a print statement in that function where you print the two ints and what you think the sum is before you return. And then from that, you can kind of figure out, oops, you know, my Arduino is too hot

and my sum function is not working. So or you can find out that you're like that guy on the blog and you used a minus instead of a plus sign. Another thing you can have is rolling files. So I mean, obviously, if you keep putting print state, you have to do one of two things, you either have to put them in the print statement, and then fix the problem and then take the print statement out. But then if you do that, as your program gets bigger and bigger and bigger, you'll eventually discover a problem that happened six months ago.

And now you have no more print statements anywhere in your code, and you have to go back and put them all in. So a lot of people just leave the prints in, but now your program becomes really slow, because printing to the screen halts the processor and things like that. So you can log to a file and then you can say, okay, I'm going to take all these print statements and dump it into a file where it can be printed really quickly because it doesn't have to go straight to my eye. And then every day I'll

delete the file and start over. So that's pretty common is to have a lot of debug logging and to dump it to a file or even have a level of logging that gets thrown away. And you only use that level of logging when you know something's wrong. Right. Or like the function actually no ops in the case where your system logging level is set higher than the log message you're trying to output. Right. So I see a lot. And depending on the language you're using, there's different ways of doing that. But logging can still be problematic

because they're, like as Jason pointed out, but even just printing to a file still can, depending on your application, be hugely expensive relative to what you're trying to do. So if you're trying to process a million, you know, items of data and you're printing 10 things for each one, this isn't going to work.

Also, it's going to be very hard to track through if only a couple of them are having problems, track through all that massive amount of data you've generated looking for problems. Yeah, so sometimes you need to take a certain function and just really dive in and you're willing to just take an extreme amount of time to find some bug that's very nuanced and that's where things like debuggers can really help um so for c and c plus plus there's gdb or if you're using llvm if you're using the clang compiler there's lldb um. For JavaScript, there's Firebug, which is pretty cool. Chrome has a debugger, too. It might just be called the Chrome debugger. For Python, there's PDB.

And for Java, there's JDB or JDWP, which is not something you would use directly, but you would use through an IDE. So if you ever are coding Java in Eclipse, and you're writing some web server, and some function is just really hokey, and you could try to test that function in isolation, you could run some simple Eclipse program in debug mode. And that's actually using this JDWP to start your program up in debug mode,

and then to talk to it through this protocol. So Java has sort of API for debugging, which is pretty cool. And so that's how these IDs work. Another thing is that, you know, it may not be obvious that something wrong is happening, but just that your program runs slower than you expect it to. You didn't implement the dynamic programming solution, and instead you implemented the N-squared solution. But you still think you can get there with N-squared, but you need to understand functions are taking too long. And then you need to do what's called profiling.

That's right. That's right. So actually, interestingly enough, Morton Nielsen posted on the Google Plus page and asked us to do a show on profiling. And so this show on debugging was a good opportunity to talk about this. So yeah, if we could talk about profiling in a nutshell. Yeah, basically profiling is where you run your program, hopefully in as normal an environment as possible. Obviously, you know, the act of adding profiling taints the program, but you try to keep that as low as possible. And a lot of these tools are optimized for that and then you finish your program hopefully doing some task that's that's nominal for that program and at the end you get this cool dump this this graph which shows what functions you spent the most time in and you know

what lines of code were the hot spots and things like that and so there are a couple different ways of of doing that so um there we'll talk about some tools in. And so there are a couple of different ways of doing that. So we'll talk about some tools in a second, but there's all kind of two ways I know of doing it. One is where you essentially for every function call, you add a little bit of, you generate a little bit of metadata. So in the prelude and postlude to a function.

So this is like in your programming language, when you go from one function to another the compiler inserts a little bit of code in between them or you do a little bit of code in between those two calls to say that you're calling a new function and what the current time is and then you're returning from this function and what the you know current time is and if you do that for all the functions you'll get not the correct time, but relatively the correct times for how long each function takes. And then for functions which are called over and over and over again, of course, they'll

have lots of entries. And if you sum up all their time, even though each individual time may be very tiny, if you sum up all the times, it could be a huge portion of your program. So think like a very tight inner loop calls some function for graphics processing could end up taking a long time in aggregate. And you'll be able to catch that by essentially looking at all these every time the function call started and every time it ended. Now, the problem, as Jason pointed out, depending on what other systems you interact with, like

let's say you're also talking to an sql database while doing this you know code there could be timeouts associated with the database and so if your code runs really really slow because of all this extra data is generating then your sql you know query times out your connection times out and you have to start it over and it just changes fundamentally the way your program interacts with other processes um and so it's not always desirable to do that although if you can do it that kind of way is the best because it gives you the complete answer um but the other alternative which statistically in the long run ends up being the same as random sample profiling, which means that at a random time, you wake up via an interrupt or whatever, you stop your program, and you ask it what current line of code it's running at. So in embedded, we often have to do this in a custom way,

where you have an interrupt that fires, and you look at what the program counter that was pushed onto the stack was, which is where you'll return when your interrupt finishes and you you know essentially put that return location somewhere and then at the you know end of some interval you go look at all those return locations and then statistically in aggregate you know what functions you're spending time in by randomly when you woke up and asked the processor what it was doing where was it at then you build up a picture of where you're spending time but you could miss certain functions like if a function is only called once in a while and for a very brief period of time you may not catch it randomly but then you may you wouldn't care about it because it doesn't take

very long to run yeah that makes sense yeah it's like, you know, we talked about the acceptance-rejection sampling like a few shows ago and how you could like estimate the volume of a surface and all that stuff. This is basically that. I mean, this is just pure acceptance sampling.

But yeah, I mean, to Patrick's point, right, if you take enough samples, then yeah, it's like a Monte Carlo approximation of the actual time. And it's much easier to implement. Yeah, but it does have a flaw where with random sample profiling that if, for instance, like you do a lot of math operations, like you take a lot of sines or cosines and you are spending a lot of time in that code but it's called from many many different parts of the system it will only tell you that you spent a lot of time computing cosines but not for what purpose like what was the one level above function you typically don't get why can't you unwind the whole it depends so yes it adds the only if it unwinds the stack as well

so only if it records their current call stack as well so only if it records okay their current call stack yeah right which will get to a horror story why like a lot of times in low level embedded you can't actually get the whole call stack oh okay cool um so yeah so the uh oh man i was totally gonna say something i forgot. I'm sure it was important. Oh, yeah, yeah, I remember. Okay, so Boost has this pretty cool thing called Scoped Timer, which is meant for the thing Patrick talked about earlier where you want to time every function.

And I thought it was kind of clever. It's a timer object, and in the constructor of the object, it gets the time, and in the destructor of the object, it gets the time and takes a difference and prints it and so the idea is like you know as long as you create the scoped timer on the stack um you know you don't use new scope timer no one would ever do that so as long as you create on the stack then you don't have to create the end version like it just naturally happens when you return from the function. And you could even have, like, within a function,

you could put little curly braces and put a scope timer such that, you know, you know it's going to go out of scope. I still find the, like, non, like, the curly braces without, and C or C++ you're talking about, but, like, the curly braces for creating local scope without something at the opening curly brace, still find that disturbing really like i've seen it so many times that i still find it jarring like as such a weird notation as long as you're creating the variable right afterwards i'm okay with it but if you just have one kind of floating then yeah i

kind of think why did this why is this here there are lots of reasons for doing it. It's just always, like, it never jived with me. It always just... Okay. So some random tools for this. So C or C++, you're probably going to be using Gprof. For JavaScript, the Firefox and Chrome both have a pretty good profiler built in. One interesting thing is they'll give very different results

um i guess it's not that interesting because you know they're completely different browsers right but um um but like there are some things that firefox i think adds like counts in the profile that chrome doesn't and things like that um python has profile or c profile i thought this kind of interesting like python has a lot of these libraries where they have like a C version, like they have pickle and C pickle, they have profile and C profile, and I always kind of thought, why would you ever use profile when the C profile is just better in every way, the only thing I can imagine is you might not exist on every architecture or something like that.

Um, so I put both in just in case, but you're almost certainly going to want to use C profile if you're doing Python. The, so, sorry for memory leaks. A tool I've used before is Valgrind, which is extremely interesting because you don't actually run your program

on the processor when you run it through Valgrind, but Valgrind instead looks at your code and basically hijacks it so when it sees you using memory, it tags it so that it knows when you free it and when you don't. And this has, again, a problem we talked about before where it does change the timing of your code,

but for memory allocation, deallocation is very useful because because it tags all every time you allocate memory it says when you created it when you freed it um and i don't remember i think it even maybe gives you line numbers where you um did it i can't remember now it's been too long since i used it yeah it does it gives you it gives you line numbers yeah so it a really, really powerful tool for Linux-based systems. I don't know if there's something equivalent in Windows and when you're not using an operating system, there's no dice. Yeah, so for Mac, there's also,

you can build Valgrind for Mac. For Windows, I believe you can build Valgrind, but the catch is your binary must have also been built with GCC or Clang. So if you build your binary using Visual Studio, then there's no hope. No hope with Valgrind, but there are other, like Intel has a tool you can pay for. If you're already paying for Visual Studio, they probably figure paying is something you're used to. You like paying. Yeah, you like paying. Yeah, another one is address sanitizer. It's very similar to Valgrind. It's not as heavy.

In fact, many people run address sanitizer all the time because it's only like, I think, a 30% or 40% hit. And most people say, oh, I'd rather buy 40% more computers than have an address out-of-bounds error. And so many companies run with address sanitized run all the time. It's much more lightweight than Valgrind, but it only catches a subset of the errors. For automated testing, you know, you can write,

we had a show about unit tests. That's great. Integration tests. There's also a great kind of testing called fuzz testing, which is essentially throwing randomly generated data at your program. So this is really good, for instance, if you think about a program which accepts packets over the internet, for instance, and you say, I'm checking for malformed TCP packets. Well, that's great, except you have some sort of internal finite state machine that's

looking for certain bit patterns. And if I keep throwing enough random stuff at you, eventually I'll get something that looks an awful lot like a real packet, but is flawed in some way that if you were crafting inputs, you would never think about. And you can cause all sorts of crazy crashes and end up getting found. Every story

I've ever heard about, and maybe it's confirmation bias, but every story I've ever read about someone who decided to try doing fuzz testing has always found whole classes of errors they weren't catching in other ways. Yeah, definitely. I mean, I've used the gremlins.js, which is a visual version of fuzz testing.

Basically, you load gremlins.js into your browser while you're looking at a website and you can even do this on websites that aren't yours which is kind of cool like you can do this on new york times or whatever but you can uh you can load gremlins.js and then you can say i think it's like gremlins.spawn and it will just randomly and very quickly start clicking all over the screen and typing into all the input boxes and hitting enter and clicking all over the screen and typing into all the input boxes and hitting enter and clicking on all the buttons. Did you just recommend people to try hacking the New York Times, Jason?

I think I just DDoSed the New York Times, like thousands of people. So you could do this on your own website. And the short story here is, I have this internal website that I use Docker for, which we can go back to that. But I ran this Gremlins on it, and it completely blew up. Like, even the server died.

Everything died. And, you know, I went through several iterations. I basically got to the point where i just like it was too hard like i just the gremlins beat me and uh i still have to do a lot more work to to overcome it so if you know where jason lives you can uh run gremlins on his website and crash all his computers yeah that's right but you will be absolutely amazed especially with javascript where or you know with web design where you might have a lot going on on a website but you don't really expect all of it to be engaged at the same time um you will be amazed at how broken

um you know like gremlins will actually click buttons that aren't visible because i mean technically someone can just make them visible in the browser and click them. Like, it's possible, you know? And so if you're not handling that on the server side, your thing just explodes. So, yeah, check that out. You guys, your web programming and invisible buttons. I don't even know what's going on.

All right. Also, tools for iOS and Android to do similar things. Randomly click your app looking for problems. We didn't even talk about fuzz testing for, like, sanitation of inputs for, like, SQL injection and stuff like that, which is also very important. Oh, yeah. Because it turns out there's, like, all sorts of Unicode characters that also do equivalent things and escaping and escaping escaping and oh yep all sorts of weirdness that you can do uh and then of course all of it's very important for when you're running services in production or uh on you know user devices that you have reporting crash reporting

aggregate reporting reporting some dashboard where you can go to and say did my newest release cause more crashes than normal or what crashes are there why are why is it crashing unexpected that's a good point like when you release things to you know millions or maybe billions of people it's going to crash for a lot of them you know i mean so it's not like you know you're going to release something and and uh after doing all the debugging we just talked about it's just 100 right the reality is if you're really selling to a billion people you're going to get thousands of crash reports yeah i i don't think i mean i can't say for certain but i mean there's all sorts of reasons that aren't even your fault that it could crash for right like misconfigured whatever like you're you're expecting

some job to complete and someone pulled the power plug on their computer um like i mean or like ram you know like you store an eight and you will get an eight back 99.6 nines percent but i mean again you have a billion people so you will have that epsilon percent you will see that epsilon percent chance realized in your crash log or just like it's somebody's running on corrupted RAM or something

yeah right yeah I mean there's all sorts of reasons why crashes can happen that aren't your fault but if you kind of have looked at them and you understand and it depends a lot on the circumstances, but at least you can know that it stays at a constant level, right? Like if it goes up after you've pushed a change, like that's bad. You should understand why.

Yep. So. Cool. So that's sort of debugging, you know, in a nutshell. The rest we have are some interesting stories, kind of. We have for us are some interesting stories. We have some crazy stories, worse stories. Debugging is a lot about

sitting around the fire pit. Yeah, sitting around the fire pit and sharing these incredible stories about either the heroic or the terrifying stories of debugging. Some terrible things have happened to me are bugs that only happen in release builds. So you can't use, as soon as you run Valgrind

or Address Sanitizer or GDB, any of these tools, the bug goes away. It's only there when you, even if you add a print statement, the bug goes away. It's like only there when you're not looking for it. Timing. That's terrible. Yes.

They're impossible to drag down. Yeah. Not impossible. Basically, you have to just start deleting parts of your code until it stops crashing. Bugs that only happen once per day or once for some very long time. We had an issue where we were had some bug so patrick and i used to work uh at a company over on the east coast and we had a bug where to solve it um somebody finally just sat in a hot room with some machinery for eight hours straight and never got the bug and they were literally just sitting there and then after eight hours they finally got

the got the bug and then fortunately we were able to collect enough data that time but it had been for months it had been crashing but only you know once or twice per day and so we were never collecting the right information to fix it. Yeah, so the bugs only happen in release builds. We had a bug recently in a team I was working on where the system that we were working in, the power would essentially fluctuate depending on what you were doing. And so it would crash, but you could let... And we thought, like like someone said oh i think

it's this they added the change and it fixed it uh and then they you know tried to send the change out for review and get it approved or whatever and i brought up to them like well hey can you prove that like taking it back out or like changing something else doesn't also fix it and they just looked at me funny went back to their desk they They, they tried it, came back. Okay. What do you know that you're not telling me? And I said, well, I was just being pessimistic. And it turned out that basically changing any line of code would fix the problem. Almost any line of code. So what it turned out is like, like I was saying, the power was fluctuating because an operation we were doing, like we were doing two back-to-back operations that took a lot of power, for instance.

And that, you know, after the first one, the power was kind of like sagged and then you did the second one and it would fail. But if you altered the order or added anything in between them, the power could recover enough and would work fine. Oh my God.

But that like, it turned out not to be a software problem, but actually like physically the machine we were running on was having difficulty doing what we were asking it to. And so almost any change would fix the problem. That was really hard to try. Oh, my God. Yeah, the big thing, another big problem that I had, so this is kind of bad coding on my part

this is like when I was very young but I built this video game and there was some crasher that happened but it was near the end of the game and being extremely naive the only way I could debug it is to play through the whole game now it wasn't that long of a game it was only like 30 minutes

but like yeah I would play 30 minutes and then i would see the crash and then i would like mess around in visual studio and and make a little bit of progress but not enough to like totally fix it and then i would repeat it was just like in hindsight it was like yeah unit test would have been great there but uh um but uh but yeah that's another one that potentially that could bite you even if you wrote unit test I could regale you with all sorts of hardware stories like address bits that were stuck so you think you're talking to one address of RAM but you're really talking it to a different one because one of the bits occasionally gets stuck

and so when you ask for address 8 of the array you're actually getting address six, right? That wouldn't be, Oh God. Yeah. Yeah. So like the four bit, the yeah, four bit is the eight and six don't make sense, but Oh yeah. If you're asking for eight and it's giving me nine because the one bit is stuck and it's just like sometimes occasionally it gets stuck. And so when you're like indexing an array, it gets mirrored upon itself in some way. Very hard to track down. Oh man, that's intense.

And then I was talking earlier about stack unwinding. And so one of the things that turns out when you're on like, depending on how you run your GCC or whatever, is that when you're running in, like we said, like these bare metal kind of low level programs, is that GCC can become very, very efficient at stripping out a lot of stuff. And so one of the things that it starts to do is when you push, so every time you go into a

function, it pushes in C or C++. Wow, that's all our debugging stories. Java must be great, because I've written a lot of Java code and I have almost no interesting debugging stories about it. Well, there's been interesting things, but the problem is they're had by the VM. Like the guys who write the VM have all the fun. Oh, maybe.

So write your code in Java because apparently you end up with no interesting debugging stories. Yeah. So I had GCC, when you call into a function, pushes some bits of data onto the stack. And so in Linux, for instance, I think I'm not super familiar with it, but I

think it more pushes kind of like a set format, a frame, into the stack. So you have these stacked frames. And so when you crash and you get a stack dump, you can actually look through it and look for the stack. So you have these stack frames. And so when you crash and you get a stack dump, you can actually look through it and look for the frames. But it turns out not every function needs to push something onto the frame. If you are just going into a function,

writing some value in memory, and then going to another function, for instance, that middle function doesn't need anything pushed into the stack. And so GCC will actually just make it so that it calls through that function. Yeah, that's right. So this can happen. And depending on, like I said, the level of optimization,

it becomes worse and worse. And so GCC is incredibly, well, GDB is incredibly good at using GCC and examining the code and the memory and being able to unwind. But automated tools can have difficulty doing that. And so there are several cases where I end up looking at a memory dump of the stack and looking for addresses that were in the code space that were essentially function pointers or like, you know, return addresses by hand to unwind the stack. Oh, God. To try to find problems.

So do you do the GCC-E where it gives you the function pointers for all the functions? Oh, well, there's lots of techniques. But no, I mean, typically you can have the binary and you can do like the object dump, is it? Or the disassembly, basically. So I do a lot with assembly. So I can just disassemble the code, look at the disassembly basically so i do a lot with assembly so i can just disassemble the code look at the disassembly look at the address and you know kind of tell what it was doing um but like very very by hand and i said there's probably some way to script it but it ended up being just faster to do it by hand and like scan through the stack where

we were and like look for things which i knew to be in code space and then almost universally those ended up being the return addresses cool yeah i have a friend whose dad uh uh was in russia working in the commerce space and he was designing ATM machines and for some reason the ATM machine You know the display like hadn't even arrived yet But they were under like incredible time pressure and they were trying to do all the logic and things like that And all they had was the you know, you know that beeping the ATM makes when you put your password in and things like that So he could alter the tone of that, but that was it.

Like, that was the only sort of interface between this computer and the real world. And so in desperation, he actually had it play different notes based on, you know, different issues. Like, he was basically putting in print statements but in audio form and so it would say you know and you'd have to like think about what those frequencies like what those pitches were and then say okay you know i mean he probably couldn't get it down to like the single number i couldn't distinguish a seven from an eight but he'd like look at that and say okay all right we got into this part of the function and then he'd like go back i was just like oh my god so i've never done it but i've almost done it and had someone told me that they have done it before where print statement ultimately the print handler right like

twiddles bits on a ur or sends it an assist call or whatever right so you can put your own code there and um a person told me that they had done debugging with an led blinking so actually the print statement you could send you know via on and off led pulses and then have another computer basically like detect the light and look for on off on off on off and basically retrieve the binary. So an LED-based UART, basically. That's amazing. Like LED read by a camera. It's like LED Morse code.

Yeah, doing Morse code that was invented like 300 years ago or something, right? You could do it. Oh, man. So, yeah, your friend could have actually just had a modem, right? Like it's like... You could have done stack had a modem right like it's like you could have like done stack dumps and everything not what he was complaining about

oh my gosh oh man um so we have a few questions from the from the twitch stream before we wrap it up. So someone asked, why is print debugging the best form of debugging? Andrew asks. So I still use a lot of print debugging. For me, it's the fastest. I don't know if I would call it the best form of debugging because I am definitely not a good debugger like Patrick is. What?

But I tend to almost always use prints. And it's just because I usually get what I need faster than stepping through with the debugger. So yeah, what's your opinion on it? I mean, it's a balance, right? Like I typically try one thing and then give up and try another way and go back and forth and back and forth. But I too also typically end up opting for print statements when possible.

Yeah. I mean, it depends on a lot of it depends on sort of like the dynamics of your program. Like if your program has to hit a database and do all these other things and the program itself isn't too complex, maybe like a debugger would it would be better every time but uh but yeah patrick's right there's really no silver bullet it just depends on the circumstance but i think that's part of what being like i feel like it's an old school crime detective right like you have to have your hunch and when you work yeah right when you work

in software i don't know i feel like i developed some sort of hunch like you know the bits of the code you don't trust and those are the first ones i go after first yeah and i think part of being good at it is just having a more intuitive feel of where to go first makes you get there that much faster but picking the wrong one can just cost you tons and tons of time right because you're just barking up the wrong tree. Yeah, like if you, this is one thing that I've learned over the years. If you have a bug in some code, it's extremely likely you have more than one bug

in the same code. Because what happens is that bug starts setting up sort of a false assumptions for the rest of your code in that same block. And it's like, it seems like, I don't know if it's just like a self-fulfilling prophecy or whatever But I mean we had it a month ago where we had a bug and then sure enough a week later We had another bug in the same function and it just always seems to be that way So whenever I see a bug I become like just really Like I just start scouring that part of the code base because uh there's

almost always more work to do um someone asks should we use lldb instead of gdb um it says to be more advanced than gdb so i can answer this one um if you're on mac you have to use lldb you can actually build gdb um but you probably don't want to. The short answer is LLDB is for LLVM. So if you're using Clang, Clang++, or any of the LLVM, Objective-C, any of the LLVM-based compilers, then you want to be using LLDB. Now, I think, you know, you can use LLDB for GCC compiled code, I believe. And I think you can go, you can actually, both of them work both ways.

But there's no reason to do that. Like LLDB is going to be the best for LLVM code and GDB for GCC code. So that's a, and Jiggygy asked that so thanks for your question jiggy i i never used lltb but i don't use that much either so yeah i probably osx is the reason why most people i think end up on clang recently yeah yeah clang is uh is is pretty awesome. It is really annoying because we have some bits of our code that I work in that are compiled, like the same code compiled both with GCC and Clang for different reasons.

And the set of flags is not compatible between them. So there are... Oh, right. So many are, but not all. And so we occasionally end up modifying the GCC portion for some reason and then finding out we up modifying like the gcc portion for some reason and then finding out like we have problems in the clang portion yeah i was a late adopter to clang for one reason and it was that clang didn't have support for address sanitizer like it had it but

it wasn't built in and it was super goofy um but they have that recently so i actually just uh homebrew installed clang and i'm using that for almost everything and it's amazing big fan so someone was also criticizing my uh use of multimeter but i did look it up on google and the little pronunciation key assuming i read it right actually said both are valid multimeter or multimeter. Really? Like how does a pronunciation key do both? So if you just type define multimeter into Google, it gives you the pronunciation. I'm doing it right now for the stream. Yeah, do it, do it, do it.

This is so fascinating for all of the listeners. It has like the comma and the other one. You're right. Yeah, it has both, multimeter and multimeter. And I only know that the one on the right is multimeter because the one on the left has the E with the line over it, which I know has a long E. I remember my high school English classes, but I'm surprised you can't click on it and get a speech vocal. Oh yeah. This is fascinating podcasting.

Well, I think that's a wrap for me for today. Yeah. Um, so thanks everybody. Oh, uh, so we should uh so we should we should definitely say that uh we're close to 10 000 subscribers which is amazing um thank you guys almost there tell your mom tell your friends yeah like so we've never pleaded for subscribers before i think we are pleading for subscribers i think we've pleaded before no we haven't i have more pride than i'm just kidding no we have no pride we're pleading for subscribers uh get us a 10 000 we're at 97 something so uh we're very or just download it multiple times uh yeah actually how does feed burner just define a subscriber it's arbitrary statistic it's interesting because what i'm going to assume is most people download it and email it to 10 of their friends or like put it up on dropbox or

something i don't know what all the cool kids do these days and yeah like everyone do an email chain or a pyramid scheme or something whatever they're putting on floppy disks and like leaving it on their friends desks and then like their friends are listening to it too so we actually have like 10x the distribution and i'm not going to pretend that some person has it like downloading on every one of their devices and so it's like copied on 10 devices so uh uh we yeah so we need uh exactly 225 more subscribers to hit 10k which would be totally awesome so if you're listening to this and you haven't downloaded the podcast go download it right now yeah i mean i'm pretty sure it does a good job de-duping so i don't think you'll be another subscriber but do it anyways you never

know oh dear oh man okay now we're kidding but seriously uh thank you guys for subscribing um you guys for subscribing. You guys have been signing up for Audible through our link. We really appreciate that. And Amazon. Do our Amazon stuff. And the Amazon, the book of the show. That helps pay our ridiculous network costs to serve it to everyone. But thank you guys, and we will catch you guys in a month or so.

The intro music is Axo by Binar Pilot. Programming Throwdown is distributed under a Creative Commons Attribution Sharealike 2.0 license. You're free to share, copy, distribute, transmit the work, to remix, adapt the work, but you must provide attribution to Patrick and I and sharealike in kind.