Pragmatic 34: My Code's Nicer Than Your Code

Welcome to Pragmatic. Pragmatic is a weekly discussion show contemplating the practical application of technology. Exploring the real-world trade-offs, we look at how great ideas are transformed into products and services that can change our lives. Nothing is as simple as it seems. This episode is sponsored by Aqualia and specifically their great product Solver. Solver is an amazing calculation app that works the way your mind does. When you're working out a maths problem on paper, the more powerful than a calculator but simpler and quicker than a spreadsheet, Solver can help you solve your math problem. Please visit the URL in the show notes for more information. This episode is also sponsored by Space Nation and specifically their app, Hue Party. If you have LIFX or Philips Hue bulbs, Hue Party can control them and add some neat effects to it. It's a free app for up to two bulbs, so you can check it out at, with no commitment, at hueparty.com/pragmatic for more information. I'm John Chidjie and today I'm joined by my guest host Guy English. How you doing, Guy? Great, happy to be here. Cool. Thanks for agreeing to come back on. Before we get stuck into the topic today, Which oddly given you know, you're my guest host is related to software I just wanted to quickly cover off a few things. So firstly a quick Thank you, too. And I love the name the username. Yo crystal ball In the US for the lovely review in iTunes. Thank you very much But more poignant as of today, I'm going to be live-streaming each show of pragmatic So we I used to do this with Mixler on episodes 10 to 14 But then episode 15, we started having some technical problems with it, decided it was best to stop. That was back when I was at Fiat Lux. And it's been a while between drinks, so it's been exactly 20 episodes since the last one that was live, but now we're going live again. So this time, however, I'm doing it the more, I'd say traditional, but how about the more current way, which is there is an IRC chat room on freeno.net. The chat room is #pragmaticshow, all one word. If you go to the URL techdistortion.com/live, you can listen to the stream, you can access the stream there, or you can use the embedded IRC chat box in that window to join in during when the show is live. Of course, if you have an IRC client, like I use Colloquy, is that how you pronounce that guy? Colloquy? - Colloquy, yeah. - Yeah, I'm more-- - Close enough. - Yeah, I-- - That's what I use too. - Yeah, cool. It's not bad. So I never know how to pronounce it, but anyway. So feel free to join in and what we're going to be doing right now, first of all, is I don't have the ShowBot up and running yet, working on it. It will eventually, probably in the next week or two, I don't want to set a deadline because that's crazy talk. So yeah, at some point I'll get ShowBot running. I'm actually going to take Casey List's ShowBot for a whirl. I had a look at the 5x5, I know. I know. That'll work out well. Oh, come on. It's not too bad. I'm kidding. that. So I want to give that a shot anyway. So, hopefully we'll see the results of that in the next few weeks. In the meantime, I'll just go back over the stream. So if you have title suggestions, feel free to make them. Any contributions, obviously chime in at any time. But because it's a very focused show, I tend not to go off on too many tangents, or I try not to anyway. So, you know, there'll be a balance. But what I want to do differently is if you have a question, specific question, either for me or my guest hosts, then please ask it in the chat room, but prefix it with an apostrophe Q or apostrophe QA. The idea is that after the show's wrapped, that I wanna have a question and answer session for people. So what I wanna try and do is separate the actual questions and any interruption of the show, and we'll have it as a separate Q&A session at the end, which is hardly a new idea, but it's just something I wanna try. We'll see how it goes. Okay, now just one more quick word about sponsors. I've been really fortunate to have some great sponsors in the last few months and honestly if you would like to sponsor the show just go to techdistortion.com/sponsored again and touch. This is the first and only time I'm going to spruik sponsoring the show on itself. I think it's a bit strange but I haven't done it before so this is the first but I won't do it again anyway. Basically the rates I've have got a very aggressive, they're targeted at indie developers. I think that we're about one third of the cost of relative to total downloads of some of the other podcasts out there. So I'm trying to be as good value as possible. And just to give you an idea, it's sort of, it's absolutely blown my mind, but our most popular episode just recently cracked 20,000 downloads. So I'm over the moon and stoked at the same time. And a big thank you to everyone who's given the show a chance and especially those that are still listening. of course, and even more special thank you to those who are in the chat room right now. So hello chat room. Right, that's my pre-show preamble blurb and now we can get stuck in. Okay. So I have always wanted to go into this one in a little bit more depth, which is my code's nicer than your code. Everyone likes to think, you know, that they know the best way to write their software, the best way to structure it, the best way to name things, the best way to put it together, essentially. And honestly, I guess back in the early days, I say the early days, when programming was first a thing, there really wasn't much choice. I mean, you had machine language, assembly language, and there really wasn't much latitude. It was like, you know, move this there, you know, op codes and so on. There was no artistic license 'cause there was no art. There was just, that was just it. So I guess you could structure your program slightly differently, but you know, it wasn't object oriented. It wasn't, yeah, it was just, you had to deal with it. You had to speak in machine speak in order to actually do anything. So when there is no choice, there is no problem, right? But as soon as you start having a choice, you start having a problem. So as we evolved and we added abstractions and sort of increased that distance between the programmer and the machine level of code, so we had the opportunity to make the code potentially more readable and potentially more maintainable. And the biggest leap I think is the idea of object-oriented programming. And that makes the software potentially easier to separate and improve independent components of it and distribute amongst larger teams. But I say potentially, when I say potentially, I mean, a lot is about how you go about that implementation. So just 'cause you have the opportunity to make it more readable, more maintainable and so on, doesn't mean you actually will just by virtue of the fact that you can, if that makes sense. But anyway, so yeah, and when it comes to writing better code, before we dive in, just get this clear right now, it's not all about other people. People will say, "Okay, I'm gonna write this code "to be more maintainable for the next program "that comes along to look at it." Okay, great, that's nice, but seriously, you're gonna come back to it in six months time and you're gonna look at this code and you're going to be a total stranger. It'll be, I don't get it. And I often, I get the same kind of BS from younger programmers all the time that I'm working with. It's like, I'm always going to be maintaining my own code so I can do whatever the heck I want. You know, structure doesn't matter. Comments are optional. Yeah, I'm going to call my loop variables, count one, count 1,970, counting the count count if I want, 'cause I can, right? Then they give you a look. they pout and they go all sullen and fold their arms and sulk, you know. Have you ever witnessed that phenomenon? Yes, it's been a long time because I've been a professional programmer for, I don't know, about 20 years now, I guess. Slightly longer than I've been doing engineering or thereabouts. So, yeah, it's- Yeah, long enough. So, you know, when you've been working with professionals for long enough, that kind of stuff drops away. But certainly when you're starting out, I think especially if you're-- so when you're starting out and you're learning the way to do things, I think individually you get to a level where you feel really accomplished. And you are. You can probably do all kinds of really fancy stuff. And you understand the way the computer works and your code works. But translating that into professional space is totally different. Because once you start with working with other people, everything changes. Like you're no longer the smartest person in the room. Hopefully, with any luck. At least you shouldn't be. Yeah, I have-- And so yeah, you need to learn to be able to work with each other. And that sort of necessitates a common culture, or culture of the code. like a common way of doing things or a common way of writing up variable names or function formatting, whether it be camel case or, you know, the underscore hyphen one, whatever they call it. Snake, snake style, whatever the various different styles are. How about we just agree on indentation of your code? Yeah, well, that's an extra horrible one. It's the answer is spaces, by the way. No, what? No, it is. I'll tell you. Well, I'll tell you one in bit. Okay. All right. All right. Cool. Cool. Good. But yeah, you need to be able to agree with all of this kind of stuff. In order to become like an actual professional programmer. Because you're no longer just dealing with the machine, you're dealing with the machine and a bunch of fuzzy humans. Absolutely. Hopefully not too fuzzy. No, but well, I mean, everybody's got their own different perspective on stuff, right? So exactly. It's like, It's an extra order of magnitude in terms of trying to get stuff straight. So if you can keep in mind the way your program works, if it's all hacked up and crazy with go-to statements and jumping around, then that's fine. But you need to be able to stand that not everybody's going to be able to have the same subset of knowledge of the code base as you are. And so you're just increasing the order of difficulty if you don't properly organize and document your code. - Yeah, exactly. It's sort of, you start out and you'll create something and it looks really awesome to your eyes. And it's like, oh, this is the most, this is really cool. And then with time, as time passes and you start working with other people and you start showing it to them, and if it's not standardized code, they no longer see it as, oh, that's great. They see it as that's horrible. And you start to appreciate when other people actually follow all of those, you know, all of those little details and all of the rules and making sure that the code is consistent, suddenly that becomes your measure of, gee, that's great code. Because you know, you're doing what everyone else is doing. And you're actually working together as opposed to on your own. Yeah, I should say that I'm not a style guide Nazi. Well, some people are right. Some people that if you put like, let's say you're writing C, and you put the you put an if statement, and you put the opening curly brace on the same line as the if statement, you can either put it on the same line or the next line indented the same level as the if, right? Can you picture what I'm saying? - Yes, I can, yes. - Okay, so you can do one or the other of those. Some people would insist on one or the other happening. You know, in code that I, certainly that I'm responsible for, I'm okay with minor stuff like that. - Right. That's a minor style thing. It's more when you you know, if you start naming your Objective C method names with like underscores in them, that gets you know, This underscore is underscore a underscore method. Right? Yeah, that's that's important. Don't don't do that. Yeah. Fingernails on the chalkboard. Yeah, exactly. So you know, like minor stuff. Spacing. I prefer a lot of blank space. I don't like dense code. Yeah. It makes Some people do. Yeah, you're right. Denser code is more difficult to read. I try and space out logical blocks. So, if there's a section of code that has a particular function, then I'll try and separate it with a line above, before and after it. Yeah. And in fact, sometimes when I do that, especially back in the day, C didn't let you declare variables that weren't within a pair of curly braces. Okay. Because if curly braces would define a scope. Okay. But you could put curly braces in the middle of a function. So somewhere in the middle of the function I might put a curly brace, write a bit of code, like declare which new variables I need, write a bit of code and then close a curly brace. So those variables were only visible within that small scope and I could put a comment just on top of that sort of section, that scope, describing exactly what it did. And now what I've done is I've encapsulated exactly what this little section is going to do. And if the overall function starts getting too big, well, I've already got my sections kind of mapped out so I can know which ones to pull out to make their own little functions with. - Yeah, I understand. - I'm discovering as we try to chat about this, how hard it is to describe visual code stuff over the radio. But yeah, yeah, it is. It is. It is. And sometimes when I'm on this show, I'd give anything for a whiteboard. But yeah, it's just not going to work. So anyhow. All right. Cool. And we've made a we've made a bit of a start, but I guess there's a few things I just wanted to quickly sort of I feel like a starting at the basics is really with with comments. But before we get to that, actually, there's an essay that I found when I, I don't know how long ago it was months ago. And it's called "How to Write Unmaintainable Code" and by a guy called Rody Green. There's a link to it in the show notes. It's a joke, right? It's a joke essay, but I mean, geez, it's long, but it is so funny. And the funny thing is if you've got time to read it, it's actually got some really great advice in there. I mean, it's framed as a joke, right? Here's, do this if you want to make yourself indispensable because no one else will be able to understand your code. And you read through it, and there's just so much really good advice. It's like, well, and every now and then, I would now and then and now I'd cringe. And I'm like, oh, I used to do that. - Yeah, of course. - No, anyway, so I recommend reading that one. It's really quite funny. And you can learn some lessons about what not to do. And by, you know, obviously through inversion, what therefore you should do. And the other thing that if you do any kind of research on this specific topic is the internet is absolutely swimming with advice on how to write good code. Jeez, it was just similar to the whole coffee thing. You know, everyone thinks they know the best way, but anyway, there's lots of tips and tricks, but you know, let's face it. The problem with that is that the internet was put together by programmers for the most part. So, you know, obviously that's why there's so much of it out there, but anyway. So we'll just focus on our opinion and frame it that way, I guess. Okay, yeah. So code commenting, code commenting. So, code comments for me are meant to augment the code such that they improve its overall readability by mentioning details that you can't really capture in the code itself. What do you think of that kind of definition? I agree. I have to see an example. So, I mean, there's two types of comments. There's comments that point out something particularly tricky that's going to go on. And then there's comments that I use to sort of tell a story. Right. And so when I say tell a story I say let's say a function, I don't know what it does, it collects something, it sorts them, it spits out a like a fixed up list. So in the first half, the first third of the function, I'll put a comment saying now we're going to collect all of the objects that match blah you know and then we'll do the for loop and I know modern languages have much better ways of doing this, but stick with, bear with me. We'll do the for loop and we'll collect all of the objects that match a certain predicate into the new array. And so the first comment will say, "Okay, we're going to collect all the items and it'll end with an ellipsis, like dot dot dot." Then after we've done that, when we get to the next section of code, I'll put a new comment and I'll start it with an ellipsis and say, "After having done that, we will now sort them all, dot dot dot," and then I do the code for sorting them all. And then in the final thing, it'll be like, and now we repackage them into X format. Like, so it would end with, it would start with dot, dot, dot, and then repackage all the objects into format Y period. So you could read, like, if you, if you look at the function, you could read the comments with the ellipses joining them together. And it tells you the story of what's going to happen. Um, and from there, hopefully the blocks of code that you're describing are atomic enough and basic enough that once you've been given the rough description, you can see how they work. And the reason I like that kind of story, kind of commenting, is that even if you change the particulars of the way any block of code is going to work, the top level comment will still be valid. You're still going to be collecting them. Whether you do it with a for in loop or you iterate with an enumerator or do something else, the purpose of what you're trying to accomplish is at least labeled at the top. Now obviously I don't do that for every method or function because basically most methods should just be that in the first place but if you do have like a complicated series of operations that are going to happen in one method that's generally the approach I take. Cool. No I absolutely agree and I try and do something relatively similar to that and I guess I suppose just to extend that, the things that I don't like seeing in comments are things such as a code comment. I don't think a code comment should be the English version of the code verbatim. No, that's horrible. I know. Yeah, it's the worst. And I've seen this. I've seen this. You know, programmers will say, "I've got..." It's always the younger ones. Well, actually, not always. I've I've had a couple of older ones that do it anyway. So count plus plus. And then the comment after it is in English, variable count is incremented by one. And I'm like, oh, thank you. That's so helpful. And I can't put more sarcasm into that. I mean, that's worthless on pretty much every level because the audience you're writing for in programmers. Yeah. By the end of CompSci 101 or CompSci, whatever, whatever language course, the first one you do it, If you can't recognize like a counter being incremented, you've got problems. Yeah. You've got major problems. Yeah. So. No, tell it, tell the story. You know, for me, it comes in very handy. Um, when doing graphics processing, like I'll take an image, I'll invert the image, I'll translate it, uh, and then remap it with a different color and then transform it into something else, like scale it up or something. Now, if you just write that out with pure graphics code, it's kind of inscrutable. Because graphics code is like very terse, right? It's you have like, GL bitmap do this or flip a coordinate or affine transform this. So if you don't have a story, like a basic premise of what the code is supposed to do, it becomes hard to understand it. Yes. Yeah, it's it's a it's very analogous to the PLC code that I write sometimes if you've got so if I create a block that's a queuing function, for example, then I'll write that most likely in structured text STL. And when you're doing that, obviously, well, not obviously, but yeah, you'll have, you know, load address, load address register one, load address two, you know, TAC, I'm talking in Siemens talk at the moment, but you know, you have a whole list of commands and unless you've got in your head exactly what data's in what register going where and multiplying, dividing by what, you'll lose complete track of what the hell you're doing. And that comment, that story is absolutely crucial. Otherwise you'll look at that code in six months time and think, what the heck is that there for? - Yeah. - So cool. So yeah, and so from my point of view, I find the comments to be most useful at the beginning just to lay out the basic function and that's it. And the obvious ones are, I also am a great believer in embedding author and revision history in the header. I know that that's a contentious one. actually. What are your thoughts on that? In the header? Yeah. So personally, I like headers. I know a lot of languages don't use them. People say that they're anachronism and modern languages shouldn't have them. I find headers to be compiler-checked documentation, as far as I'm concerned. Yeah, I think the author and the date at the top is fine. I mean, it gets put there automatically, but it pretty much all the tools, so that's fine. It used to be invaluable. These days with Git stuff, I think people can say it's not a big deal. Yeah, but you hit it exactly with my problem though, is that if you've got an external tool that's managing this, that's fine so long as you're using that external tool. Exactly. As soon as you stop using that tool, you've lost all of that revision data, you've lost all of that information. So then what? It's kind of analogous to I want to use rich text and markdown versus I'm going to use Microsoft Word. You know what I mean? Because once you... Yeah. Yeah. Well, I mean, if you lose your Git repository, if you, for whatever reason, you have to check everything, you move from Git to Super Git, like it, then it's not compatible somehow, whatever the next thing is, you know, so you have to import your repository. and for whatever reason it can't import all of the code changes. You've just lost all of that data, right? Like you have no idea who initially wrote the file or when or even under what circumstances, you know? Yeah, exactly. So, and for exactly that reason, that's why I will embed author and revision history. You know, when you cut a revision and what comments you make is another discussion, but you know, well, is it? No, I don't know. Maybe it is. Do you keep it rolling as a log in the top of the header? They used to be pretty common practice. I, okay. I tend to keep it rolling between major revisions. So if I've got something that's released, it's 1.0 and I'm doing iteration on that, you know, in the simulator, then I'll, I'll, I'll, I'll keep one, 1.1.0.1.0.2.1.1.1.2.1.3 and all that revision history. But as soon as I got a 2.0, it's a clean slate. That's what I can do. Because otherwise, you know, 'cause sometimes I'll be iterating on these things, you know, a dozen times just. - True. - So, and if I did that for every revision, then I'd have an enormous lot of comments. And yeah, it is also backed up. So what I'll do at the end of every day is I'll zip and back it up, but that's a manual thing. And you know, one of the things that I hate about PLC software is that it's not, it doesn't support version control tools like Git or Subversion very much, if at all. it's all like a continuous block. It's like you're working on a Word document. You know, you can't just save a paragraph or a sentence, which, you know, really sucks. And it makes working on larger scale projects difficult. - Okay, well, that's a great reason to do what you're doing. - Yeah. - Which is keep a log in the header. - But I mean, even in the, even in OO code that I've written, I still do it. Maybe it's just force of habit, but I still think it's the right thing to do. - But one can't hurt, right? - Yeah, exactly. it could be useful someday. Like, well, what did I change in between this and this? And it's like, okay, go straight to that point in the code and you figured out, okay, right. I screwed that up. It's usually why you go back. That's usually why I go back. Anyway. So, there is something though, I hear that the expression, and I actually sort of expounded this there for a few years, is the concept that well-written code doesn't need any comments or hardly any comments. It's like code should be self documenting. I believe that to a certain extent. I think yeah, I thought I said, I think it's an idealistic viewpoint, you know? Yes, yes. Like, that can be the goal. But it's okay, if you don't get there, it's okay to still have some comments in there. Of course. Yeah. I mean, that's why that's why I like the COCO frameworks and Objective-C. Yeah, it is very expressive. Like it reads like a sentence. You have, you know, the target of the action, the method, the message and any parameters that are coming. Okay, it's like an English sentence. Yeah. So and so do this with that. We've got we'll talk about it. Yeah, I actually quite like it too. When I first when I first got it, I got into my brain into the Apple way of thinking. With all their frameworks. You don't even after a while, you don't even look up the the name, you just start typing away what you think it's going to be. And nine times out of 10, it just pops up in autocomplete. And you're like, yep, I knew it'd be something like, you know, yeah, half the time, you can just guess it anywhere. Yeah, that's it. And that's, that's beautiful. It's beautifully consistent. It's Yeah, anyway, right. I'm gonna stop gushing about it just for the moment. So I mean, I mean, that, that doesn't obviate the need for comments, of course. But it does mean that I think you get to do more of the storytelling comments than the low level particular comments, right? Absolutely. Especially with, especially with named parameters in Objective-C, and now I guess Swift and Ruby and other stuff does it, but you know, named parameters helps a lot in terms of helping to document your code because you don't have to go look them up all the time. No, exactly right. So, okay. Um, I also had this other thing years ago, when I was working in the reliability group at Nortel, when we were looking at software reliability, and one of the metrics that was thrown around for a while, and I think it still is in some circles, which depresses me, but still, is comments per KLOCK. I knew you were going to say KLOCK in there. Am I showing my age? But I don't know. Anyway, look, the thing is that I just, from my point of view, adding comments does absolutely nothing to make your code run better. You know, that's it. Bad code is bad code. I mean, how many comments you have? So I mean, because we did the we should we're so K lock is 1000s of lines of code. Yes. By the way, if anybody doesn't pick that up. Yeah. Okay. LOC. Yeah. Because for a while there, when they started throwing it around in meetings, you haven't been in that situation where you got a bunch of people in the room that have been an organization for a while they're throwing around every acronym under the sun and you're like, what did what did you just say? I just had a I just had a client that is in a big retail operation. Yeah. Holy moly, do they have a lot of act there? Oh, yeah, Nortel was so bad that they had the little book of acronyms. I kid you not, it was literally this little thing. And it was these guys have like an internal wiki to look up all the acronyms. And that's of course, yeah. And honestly, yeah, that's, that's the modern equivalent back then. There's no wiki but anyway. Oh, dear. Anyway, all right, cool. So Two more things about code comments, and I think we've probably done that to death, and that is the other problem I have with too many code comments that are specific, the specific code comments, is that you tend to get a divergence. And you sort of alluded to this earlier on, is that it doesn't matter how you choose to iterate, you were talking about enumeration versus loops and blah blah blah. That point there is that, well, if I'm going to be really specific about what this code does, and I'm going to replicate some of that in my comments, then as you develop the code, what tends to happen is you'll be told, there's a bug in this object, go fix it. And you're like, right, looking at the clock, it's like five minutes to five in the afternoon. Now, this is if you've got a job, right? You know, but let's say that at five o'clock, you've got to go and watch your daughter playing hockey or whatever, right? I don't know. I'm trying to come up with a home working equivalent. But the point is, you're deadline. So you get in there, you check out, you go through and you fix the code. yeah, yeah, yeah, good, great, check back in, go. Did you remember to update your comments? No. And this is what happens, right? So then you get this divergence of what's in the code and what's in the comments. And then the poor bugger that's reading the code is then you've just doubled the difficulty because they'll read the comment thinking that's going to help them understand it, but it's not. It's just confusing. Yeah, to lie. Yeah. It's like, well, it's just, you just totally misled. Yeah. Thanks. Thanks for leaving me that inaccurate comment. Really. Anyway, so those small kind of comments are really good for when you do something insane. Yeah, like in the Doom or the Quake engines there's a lot of weird math tricks that have to do with the way integers work on the computer and you can divide by a certain magic number and then shift by one and it'll do some it'll figure out the square root or something like there's always some weird trick. Explaining what you're going to do with that? Very good. Because that's completely non-obvious. But explaining what you're doing in the Munitia when the implementation can change drastically is... I think not only is it a waste of time, I think it's not just a waste of your time to write it, it's a waste of everybody else's time who comes and reads it and it's just let down the garden path. Yeah, exactly right. Exactly. So the last thing about commenting that I want to talk about is dead code. And yeah, yeah, you know what I mean? When I'm talking about dead code, right? Yeah, I'm bad for this. But yeah, oh, so am I. So okay, so when I'm iterating my code, what I tend to do is I will take a block of code that sort of does what I want it to do. And then I'll copy paste comment out. And that's my way of sort of like, I'll just park that to one side. And then I'll iterate, iterate and now it's working. That's great. And then I'll delete out that dead code that I commented out. At least that's what I try to do. Often when I'm going to, when I'm done, like I'm totally done with something, I'm happy as I'll go through and I'll do a cleansing or purification, purify my code and just go through and strip out anything that's the dead code because the dead code sort of creates that confusion for programmers, and even for yourself going back over it, was this commented out for, why was that left in there? Was that part of an experiment or is it a branch that you kind of were chiseling away at and you're gonna come back to or what, why the hell is it there? So. - So if I comment, well, if I comment a blocker code out, often it's for testing something. Like I'm like, okay, I wanna get rid of this chunk and see what happens. But I'm getting much better at this, but it used to be pretty bad because, you know, versioning systems weren't what they are today. So I'd comment out a chunk of code that I may want to come back to. Like I may have a totally different implementation of a function or two sections of a function. Generally what I try to do when I do that is put a comment on top of the commented out code saying exactly why it's commented out. so that when I can come back to it in the future, I'd know what's going on. And then every now and then I try to do a cleanse. - Yeah, that's it. - These days I'm relying a lot more on source control and just being able to go back in time and find. - The tools are great. - 'Cause I don't wanna, yeah, yeah, exactly. I mean, what happens is I don't have something that's working now and then I'm like, oh, I can try this different approach that's gonna be faster or whatever, more efficient, whatever thing I'm particularly trying to optimize. And then ditch a bunch of old code and then find out that the new one is kind of broken in some way and have to reintroduce something from the old one and not have it to hand. Do you know what I mean? Yeah. And without version control or proper version control, that is a huge pain in the ass. And that's why you just ended up with a bunch of dead code. These days, it's easier to go back and see what revisions were made and just pull the right stuff forward again. Yeah, that's true. As I was saying, yeah, the tools have come a long way. And I guess some of the way that I program is force of habit. And that's and I'm not moving with the times and using some of the tools that are available. So I acknowledge that. But even with those tools, dead code is something that I still come across. And, you know, I mean, the other form of dead code, which is far more subtle, is the objects with a bunch of methods that are never called. and you're forever wondering, you know, do I need, is this part of the framework or isn't it? What will, you know, because you're, I remember there was two similarly named objects that I was working on and I even got confused, this is, you know, years ago and I even got confused. I'm like, okay, so which one was the one I was working on and which is the one that I left for dead? Right, so before we go on any further, I think we might just take a quick break to talk about our first sponsor which is Solver and that's a calculation app by Aqualia for both the Mac and iOS. It's great by the way, I use it every day. Yeah it's fantastic isn't it? Once you start using it, it's like how did I not, I mean I've just given up, there are a whole bunch of things I used to do through Google search and I just do them through Solver because it's just so much quicker. No it's one of those apps I'm jealous of because I'm like oh man I wish I'd thought of this. Yeah I know. So okay all right so I'm careful to call Solver a calculation app because it's more than than a calculator and it's quicker and easier to use in a spreadsheet. You just start typing away and in real time the answers will show up in the right-hand pane. So let's say you want to add two numbers but one's in hexadecimal and one's in decimal. Well you know type 0xFF + 10 and there's your answer and you can have it in whichever you like. So yeah it's just that easy. Converting currencies. Okay so I got 10 euros plus 10 US dollars in AUD for Australian dollars. Boom! You get the answer in Australian dollars. It does all the currency conversion, gets the rates and so on. It's just magic. So crazy things. If you want to do crazy things you can. Yeah like if you want to know how many minutes you've been alive. Okay that's a crazy one. Try 38 years to two weeks as minutes and it turns out that I've been alive 20 million six thousand two hundred and twenty nine minutes or so. Something like that. Anyway yay. Sometimes Sometimes what something I use it for for pragmatic is the conversions between Celsius and Fahrenheit So if you type in 120 F in C, it'll give you that in Celsius. Boom done It's just it's just that easy and that's just a handful of examples, you know But you type them in as you would think them and you get an instant result You can link different results together easily to create more complicated calculations You can share you're working in your results list goes on and on it is awesome So anyway, if you're not convinced, then why don't you go to the URL in the show notes and check out the Mac version. It has a 10 day smart trial, meaning you only pay for the days that you actively use it for. So that's 10 days of total usage time. So for me, I used the trial for three days and I loved it so much I just bought it. It was just that good. So Solver is available through the Mac App Store and the iOS App Store, and there are links to the apps from Aqualia's website. If you use the URL in the show notes, it'll help out the show. So please use that URL in the show notes to learn more about this helpful little app. So thank you to Aqualia with their great app solver for sponsoring Pragmatic. Highly recommended. And they're not paying their dime. No, it's a great app. It really is a great app. Yeah. It's like I said before, it's one of those ones that once you start using it, you're like, how did I not, how did I not use this for forever? Cause it's just that good anyway. Okay, so it's related to commenting, but it's not commenting, it's variable naming. So, we got to talk about this. And in my parlance, for example, in PLC land, they're referred to as symbols or symbolics. But you know, same diff kind of thing, right? So, I think that the overarching rule with naming is verbosity is good within reason. I think that if your variables end up being 150 plus characters long, you're really writing a sentence, you probably need to work on that and shorten it a bit. But yeah, yeah. It's got to fit in a tweet. That's the new, that's the new measuring stick, is it? Yeah. It used to be that they had to be less than like, what, eight characters. Now it's like, yeah, variable names go over a tweet length. That variable names, method names may go a bit longer. Maybe an objective C, even that's really pushing it. Yeah, well, I think it's Yeah, well, put them in the same bucket. Why not methods, variables? You know, why not? I mean, it's just 140 minutes is a good guideline, right? Yeah, yeah. But well, if only because a variable name is going to be describing one thing, while a method name is going to be describing a process and a process is by its nature more complicated than one thing. Okay, yeah. Okay. So let's say you got a method that's add number, you know, with number, from number, you know, whatever. Yeah, okay, that's true. Well, you know, it's like connect to network X using radio Y, on frequency Z, like, you can get like, pretty long. Yeah, I suppose that's fair enough. So definitely watch the verbosity, but it's okay to be verbose because that's what the tools are there for. There's no prize for having a short variable name. And one of the things that I've been frustrated with for years is knowing how good the development tools are, for example, with Xcode and then going into PLC land and dealing with the fact that you're still restricted to stupid things like 24, 32 characters for symbol name. And it's what century is this really guys? And this is the thing that really annoys me is that you know the state of the art of software development in PLC land is abysmal. So compared to what else is out there. So I live and hope that someday they will step up and realize that yeah it would be handy to have more than 24 characters. Is there a reason for that? Like they just don't invest in the compile technology or it's just there's no pressure to I honestly don't know I know I can speak to one product because I know the answer for one product and one product is called SciTech and or as it's more affectionately known SciTech it's anyway it's built on DB4 and every time you change the column width in DB4 you have to change the way it's compiled because everything is all based on fixed width columns and it's just ridiculously old. No, there's no link list, there's none of that stuff. So, when they change and add more characters, then it increases the size of the database file for the variable list and that then causes a backwards compatibility problem. So, every so many years, like every four or five years, they've said, "Okay, well, we've extended it now to 32 characters, thumbs up." And I'm Really? Only 32? Yeah Goodness me Well I guess if they just, if they went to 128 then everything would balloon right? You've got very limited RAM so Yeah well But the problem is the symbolics for example in a Siemens PLC aren't stored in the PLC's memory And yeah it's stored in an offline file so you just download the raw code And what you see on the front end is that it overlays the symbolics over the top so that it's human readable So in that case, there's no advantage, disadvantage. And with SciTech, that's SCADA, again, yeah, it's sitting on the computer and I've got a five-- - Oh, that's weird. - Terabyte hard drive. Yeah, it's BS. - So these symbolics never get onto the device. - No, well, not all PLCs are like that. Some PLCs, they do. They actually download the entire project to the memory and some PLCs will have it segregated. So you'll have like a program memory and you'll have data memory. So you download, you're literally doing a split download. you're downloading compiled code to the run to the to the actual live program memory. And you're downloading a copy of the project for archival purposes and retrieve a later that has everything in it. So depends on the PLC. But still, wait, that's cool. So you could you could pull out the entire source code for the for the programmable bit. Yeah. Oh, yeah. Yes, that's cool. Well, because it goes along with like the physical object, right? Like, you can that's right. One of the things that sucks, though, it's cool. That's a good - It is a good idea. - Yeah, not all PLCs do it, but you know, for example, some PLCs, I think the Quantum's or the Premium's, I think the Schneider's, I'm trying to remember, it's been a while, but if you don't have to have a memory card for some of these, it's optional. And if you don't have the memory card, then you don't download the entire project to it. And then you just download the compiled raw code. At which point then, if you ever want to upload it, you'll upload it, but you'll just get raw memory addresses and raw function calls, and you'll have like, what the heck is FB165 doing with M7.3? Oh, good. - Right. - Yeah, it's, and believe me, that's the worst kind of call out to get. You get a call out at, and I haven't done this for years, but I used to get these sorts of call outs where the machine stopped working, it's two in the morning, you know, they're losing thousands of dollars an hour, and they're like, right, fix it. And you're looking at this machine, you've never seen it before. You log in on your laptop, and there's no backup of the code. You upload it, and you're looking at this thing, and it's like, right, I'm staring at raw machine code. Now I have to figure out why. - The machine isn't running. - Oh, that's where daddy drinks. - Yeah, damn right. (both laughing) So yeah, I'm out of that game at the moment, but I'll tell you what, it was a certain buzz doing that, I will admit. But anyway, that was a while ago. Okay, I digress, I digress. So I need to do another, I need to do an episode just about PLC programming and all that stuff. I'll get to it someday, but anyway. Okay, so I think embedding the variable type into the variable name is sort of a pseudo common practice, would you say? Yeah, like B for brilliant. Well, Hungarian notation, right? Not familiar with that terminology. I have to put my hand up. I'm sorry. Okay, so I forget to name it a guy, but he was a dude at Microsoft back in the 80s or early 90s. And he popularized this way of naming variables which included type information at the beginning. So if you had like a window handle, it would be H, like underscore not underscore, lowercase H W N D and then a capital which would start off your window name. So you'd have Hwind main window. Do you get what I I mean? Yeah, I think I do. Yeah. Or like, so maybe more familiar would be like, if you have like an unsigned int, it might be understood, like, lowercase u, i, and then a count of indexes or something. Yeah, count of people. Yeah, that's it. Yeah. That's that is exactly what yes, it's exactly what I'm talking about. So there you go. I learned something new for the day. There you go. Cool. They didn't know that I actually had a name. I think he created it, which is but like, whatever could be something else. One of those things that his name has been attached to it ever since sort of thing. Yeah. Cool. Well, The thing is, I was looking at this recently on a project that I'm currently working on, and I was reviewing someone else's code. And one of the problems that they've had is the coding standards available. You know, read from that comment what you will. But anyhow, what they did is if you're going to do that, do not mix your naming schemes, please. So what they did is they said, OK, well, we're going to have B for Boolean, I for integer. OK, so far, so good, shrug, whatever. And then they're going to say, we're going to have S for set point and P for process value. But they're going to put it in the same character position as in the first character. So I'm like, OK, so if I've got a set point that's an integer, which way around is it? Is it IS or is it SI? And they're like, well, because not every variable is going to be a set point, not every variable is going to be a process variable, process value. So, what they'd done is they essentially blended the two naming schemes together. So, it should be consistent, like the first character. If you're going to do this kind of abbreviation thing, which I guess is okay up to a point, then, you know- Well, you need an order of precedence, right? Yeah, exactly. And they hadn't defined it. And I'm just, you know, so, yeah, think it through is, I guess, my advice if you're going to do that sort of thing. Because I think that there's a diminishing return up to a certain point. Because some languages that are, what's the expression? Heavily typed or the, so a language like, in a lot of instances, you can read the variable in context and figure out what it is. And honestly, I find sometimes the abbreviation concept to be a little bit redundant. And I try not to do it myself. I have done it to be consistent usually with other people's code, but it's not really, I wouldn't necessarily recommend it. But I know why people do it. But anyway, so. - I hate it. I don't want to do it. - Yeah. - I think it's a bad idea. - Yeah. - I think in some languages, maybe it makes sense. Maybe more for your stuff. - Potentially, yeah. But that's better. - In higher level languages, no, I don't think it makes sense. I think a variable name should describe what the variable represents. Whether that is in a float or a double, that may change over the course of the development. Oh yeah, sure, absolutely. - Like let's say you've got a, I don't know, location in world, in a float, and then you discover that floats don't kind of accurately represent the size maps that you want, so you move up to doubles. - Yeah. - You really don't want to go and have to rename every single variable everywhere. - No. - 'Cause that would be really annoying. - And search and replace is the blunt hammer that will wipe out otherwise working code. - Yeah, so then I get what you do in C or something It would be like you type def something to be, I don't know, like CG coordinate float. But then what do you prefix in front of all of your variables? Like you put coordinate, so you've got C, O, R, D. It just gets silly fast. And it's just a bunch of line noise, and it gets annoying. And again, the tool should be doing this for you anyway. They should be helping you out with this kind of stuff. I feel the same way with a lot of programmers, and this is even inherent in Objective-C now, but a lot of programmers in C++ at least, would put M in front of the member variables of their classes. - Yeah, yeah. - So that when they were being interop, when they were being operated upon inside methods, you could tell if a member variable was being messed with or something defined locally, like a parameter or something being defined locally. Objective-C has this kind of built in now where if you don't specifically synthesize a property, you automatically get underscore property name, which is how you know that you're messing with something directly. I'm not a fan of that. I really don't like the M prefixing stuff. Underscore a little less so because I usually just do self dot, so it's less of a big deal. But the M stuff just reads like line noise And I honestly feel that what we're kind of using code readability. Yeah. Yeah, because if you because the tools aren't good enough, right? Like, the tool should be color highlighting and all of that or telling you exactly what you're doing wrong or pointing out mistakes, right? Yeah, well, exactly. So I guess from what I'm, what bugs me about the practice is that if people do it, they'll use like M for method, like I say, I for integer, B for Boolean, blah, blah, blah. And it's sort of that implicit, then they'll have the rest of the variable name or method name in fully described in text. So what is it exactly about the type that needs to be abbreviated that makes that different and special and OK? you know if you're gonna write boolean write boolean you know it's a high level yeah which yeah if you're really gonna go down that road why do it I mean in 6 to 12 months time let's say you've come up with a naming convention and that naming convention is you know whatever it is and that naming convention is Q short for qubit I don't know whatever are you really gonna remember in 12 months time what the heck the Q stood for because I'm gonna bet you're not unless it's something that you it's all your code and you know again you're not working in a team you're in isolation and you come up with your own naming thing just because you can and that's just anyway cool yeah so I mean again if I operate in anybody else's code base I respect their their their style yeah just for my own and as a sort of philosophical point, like I don't like mixing up type information with the name of the variable. And like you're saying, well, like I was saying before with the coordinate thing, I would rather put a unit coordinate than C-O-R-D unit. - Yes. - You know, like the-- - Absolutely. - Just write it out. - Yeah, and another thing-- - If you have to. - Absolutely, another thing about writing it out too is the separation of names. So yeah, please, we said before, do not use underscores. That just looks so horribly horrible. But-- - Well, okay, I have a different opinion on that. - All right. - Oh, wait, so in Objective-C methods, yeah, don't do that, for sure. - Yeah, okay, but what about in variable names? So you're happy with them, so if I wanna have variable names, this underscore is underscore my underscore count. - Well, okay, so here's one thing I did years ago, and I think it worked pretty well. One of my-- the first game engine I was lead on, actually. Anything that you shouldn't be calling, unless you knew exactly what the hell you were doing, would be written in sort of old school underscore style. Like all lower caps, all lower case, underscores. Structs would be so and so. Like it would be like, I don't know, vec3_t, that kind of stuff. And on top of that would be something that looked a lot more like what's it called? Oh, Core Graphics. Wow, Core Foundation. Like a very Core Foundation looking API on top of that. And the Core Foundation API could call into this lower level stuff as needed to get stuff done. But if you were just a general programmer, you would only be operating at the core foundation level. And the reason I did this, and the reason I think it worked out really well, is that it was basically impossible to visually, like you had a very visual cue that you were dropping down to a low level. And if you knew, if you were messing with one at some other level, you knew you were screwing up. Certainly if you were in one of these, if you're writing a function, 'cause there's all functions back then. if you're writing a function that called anything that was all caps, like, or that did, that looked like a core foundation function, you were screwing up, because you were visibly going up the stack in terms of abstraction. Yeah. Do you know what I mean? Like, so the underscore one was like a visible way of being like, this is the lowest level of abstraction. If you're calling this from on top, Okay, maybe you've got a good reason, but if you're calling the other way, you're around your your script like don't yeah Definitely don't do that So as long as they're consistent like and these were functions keep in mind I would never do that with objective C code no Because that is you've read objective C code properly like it's it's got its own culture and language So so that's that's and that's fair enough use of an underscore that that's cool But I guess what I was one of the things that I was sort of getting at is that it's okay to For the for the one with a better way of saying it's sentenceifying and that's actually I don't pretty sure that's actually not a word But anyway, when you're when you're making your variable name into a sentence of sorts be to help describe it Yeah Just using capital letters to didn't to break apart the words Because there's nothing more frustrating to me than looking for a jumble of letters as a variable name Yeah, irrespective whether this is underscore at the beginning or not to denote its level in the code, but I guess more so about- Oh wait, wait, wait. No, I'm sorry. I think we misunderstand each other. Oh, sorry. When I was saying underscore, in camel case you use the capital letter to break apart the words. Right. In the case I was talking about, I would use an underscore. Like everything would be lowercase and I would use an underscore to break apart the words. Okay, I'm apologizing. Okay. No, no, don't apologize. No, it's just because it's hard for me to communicate, right? Yeah, you're right. This is actually tougher than I thought it would be to talk about. But yeah, honestly, can I just put my head up and say I still wouldn't write like that, but that's okay. Maybe that's personal preference. No, so I wouldn't, I don't either. That's why it was visibly, it's like the most Unix-y, level-y kind of stuff. Yeah, exactly. It's got a very Fortran sort of feel to it. But anyway, I, yeah, so I guess what I'm railing against is all lower cased or run together. Like for me, that's the worst. Please, God, don't do that. It's illegible. Yeah. And I know this is tangentially related, and it's the wrong in chauffeur that, but still, when you're doing a hashtag on Twitter, try and do it there, too. Take your learnings from programming and breaking it up by using capitalization and apply this to your, your hashtagging exercises in your spare time. Because there's nothing worse than reading a hashtag and you're trying to break out, okay, is that supposed to be an a, like an a or is that on or if? - Yeah, that's the worst. So, wave Michael Johnson, Pixar guy had a good one the other day. It was co-designing and co-designing. - It's the same, it's spelled the same way. - Oh yeah, hey cool. - It's the exact same word, they mean two totally different things. - Oh, that's brilliant, I love that. - One's kind of fun and the other one is definitely, definitely not fun. - No, no, no, that's right. Okay, cool, well, before we go on, I'd just like to take a quick moment to talk about our second sponsor for this episode, and that is Space Nation. And they make a neat Mac and iOS app for the iPhone and iPad called Hue Party, that's H-U-E, Party. and Hue Party can control your LIFX or your Philips Hue bulbs. I thought it'd be an interesting fit for the show, seeing as how LIFX have been a previous sponsor of the show. And still follow up as well for this month. So it's free to try. It has many of the same features that you get out of the standard LIFX app, such as candle flicker strobing, color change, based on the music playing through your device's microphone. But in addition, there's two interesting little twists this app has, is if you tap and hold the Hue Party icon and shake your device, it turns the lights off. Also, if you tap and hold the icon and turn your device in the air, using the gyroscope and accelerometer, it changes the brightness setting of the bulb. I could only really test it on a LIFX bulb since I don't have any of the Philips Hue bulbs, but Hue Party found my LIFX within five seconds and the rest was pretty straightforward. The best part is it's a free app to try on both of the app stores, the Mac App Store and the iOS App Store. So try it out and if it works well for you or if you have more than two light bulbs you wanna control, then the $3.99 US in-app purchase will unlock the unlimited lights to control in your network. So please visit this URL, hueparty, all one word, .com/pragmatic on your Mac and iOS device and follow the links to the App Store from there to help out the show. You can search for the app in the store, but if you use that URL in your browser of choice, then that'll help the show out. So thank you to Space Nation's Hue Party app sponsoring Pragmatic. Okay, I want to talk about something that Joel Spolsky wrote about, and he's written so much good stuff. That's a rather generic comment. It's just hard to know where to start with this. But yeah, and this one was actually an article was written back in 2000. But the thing is, kind of like the mythical man month, it's timeless. So, I kind of, yeah, anyway, I love his stuff. Anyhow, he doesn't write so much anymore though. - Oh yeah, he's doing great. Very smart guy. - Yeah, oh yeah. So, okay, it comes back to, and this is now getting more into coding practice, but it's still important. And that is perfecting functions or objects. At least that's, I guess, the title of what I'll sort of lead into this, because when you write an object or a block, I'm a firm believer that you should spend as much time on it as you can and then leave it alone. So perfect it as much as you can, then leave it alone. Try not to extend it too much. Don't refactor it too much because you get buried with it. If you've been buried in code for weeks or months, or hopefully not months, your brain is so connected with that code, it'll make sense. But if you take a break and then you come back again, I've found that you can never really quite get back to the state that your brain was in when you wrote it. Have you ever found that? Yes, very much so. I think that's one of my major problems with C++ actually. Yeah. Is that I think, well, there's so many tools available to it that I think some programmers begin to fetishize the writing of the code. And how, not abstract, but how not even clever, but just how concise and, I guess, smart it feels to have written that code. I fear the same may be true of Swift, because Swift does some of the same things. But no, I totally agree. I mean, the purpose is to build a product, right? Yes. And I think you have to keep that in mind. So you write your object to do what you need it to do, and then move on, and then write the next object. And if you have to come back to add some new functionality, then perfect. I think what happens when you're starting out is that when you write that object the first time, it's not good enough. It's screwed up in some way. But with more experience, you get to write these things one off. And they will have a design sensibility that will last throughout the lifetime of the project, you won't have to go back and change up a bunch of stuff. Yeah, exactly. And it's one of the it's this, there's this two effects that I see is the whole, I'll just do enough to get it working. And then I'll move on because I've got to get this thing out. And yeah, then there's the effect of well, the block, the function object, it almost does what I need, but I I just need to do a little bit more. So I'm just going to go inside and mess with it again, six months later or something. And that's when I go, please don't do that. Because if you've put in all this effort and you've done all your test cases and it's as solid as you can make it, you move on and then you just leave it alone. Because I find that that's where things really start. That's when you start to get crazy bugs is when you go in six months later and you just extend it just a little bit. I mean, and obviously, okay, this is not, And I don't mean this to sound, geez, what's the word? I was on either or choice. I'm not saying that you can't extend it. I'm just saying that there's other ways of getting around it. Like you could either, you could potentially clone the block, you could put a wrapper around it, you could pluck out certain features. I don't know. There's other ways of dealing with it. But, you know, and honestly, I'm just a great believer that once code has been written and dealt with, then it's best to leave it. And one of the pull quotes, just from the article I've linked in the show notes by Joel Spolsky from 2000 was, "It's harder to read code than it is to write it." It doesn't matter who you are, that's a reality. So once it's written, yeah, anyway. So. - No, so I totally agree with that. I think that is one of the arguments in favor of test-driven development though, is that it gives you a bit of latitude in order to go back and make sure you're not screwing anything up. True. So in theory, I'm a big proponent of test driven, driven development in practice. Not many of my projects really lead themselves to it. Or at least I haven't been able to figure out how so. Yeah. Yeah, it's it's one of those. Yeah. Sometimes I catch myself talking to the junior engineers and saying, Yeah, you need to test your code, you need to test your code. And then I'll quickly run in and write some code. And I'm like, I really need to test that. And you think, well, that the automated testing, right? Yeah, yeah, yeah, yeah. Where you can, I mean, obviously, in my case, there's some tests I simply can't do automatically, because of the nature of the SCADA and the PLC software that I use is that they're not lending themselves to that. But, you know, if you have decent development tools. Sorry, that's kind of the bane of my profession really is the state of the software just depresses me daily. But anyhow, okay, so once you once your code is out there, there's this this terminology I like to use called soak time. And I don't know if it's an engineering term. It actually comes I think more from electrical engineering, isn't it? Well, yeah, the idea is it's if you've got a product, like a but we see this at Nortel. So when we're making the MetraCell BTS or any of our electronics products is you put them into an oven and you run them at a high temperature. And they call that a heat soak. And it's designed to accelerate any failure rates that you might have. If you're really, really so inclined, you would get a temperature cycling oven such that it would ramp the temperature at a temperature profile. And that would simulate the effect of the devices being in the field. because there was for quite some time, and even still now, there are lots of places where you don't have temperature and humidity controlled environments. So you're putting these cars into a base station and it's out in the sticks during the winter time, it's quite cold during the summertime, it's quite hot. - Yeah, if you put something out here in Canada, like we range from like minus 30 in the winter Celsius to like plus 30 in the summer. - Oh yeah, man, I felt it. I was in Calgary, man. - Yeah, yeah. - Pretty big range of temperatures. - Yeah, massive, massive variation. But I mean, the daily one is just as bad and I'm sort of treading on reliability engineering here. But the idea is that you get temperature cycling and what we are different. Temperature cycling, you get differential expansion rates and that introduces fractures and blah, blah, blah, blah. Point is that heat soak is, and soak time is a concept that I sort of ripped off from that. But I have heard it used in the context of software as well. And it's sort of used interchangeably with field time or real world use. Or what term would you use? It's out there, it's in use. What terminology would you typically use to describe that? Well, automated unit testing. No, I mean, your code is out there in the field. It's been live in use by customers for 12 months. What would you refer to that time as? Oh, point release. Yeah, okay. This is why I had to rip it off. for 12 months. There's no, I don't think there's, I don't have a ready term for that. - Okay. - So sometimes great for me. - Okay, cool. So we're gonna run with soak time. There you go. I've just dragged that in 'cause it works for me. And the idea is that it's out there. It's been soaked in real world use, but not physically wet. Anyhow, so once the code is out there in the world, it's been heavily used and exercised. And I guess that's the caveat, exercised. Okay. - Yeah. I love it when people say, oh, we've had 5,000 downloads of our app. Oh, but no one's used it. - Yeah, it doesn't mean anything. - No, no one's used it. It's like, well, they've used it for five seconds and then it's crashed and they stopped using it. And it's been out there for six months. So it must be solid. No, no. I mean, actually exercising and using your code. So hopefully at that point, the more bugs have been fixed because you'll be getting those reports back and it's like, okay, so it's crashing a lot less now. And yeah, it's solid and stable. My code base is nice and robust. So the longer the soak time, the longer the stress testing, the better your product is inevitably gonna be, the better your code is inevitably gonna be. And the longer that goes, the more it has to reinforce in your mind, don't mess with the code. 'Cause it's, you know, the temptation is, oh, but it could be done so much better if, well, no, no, no, don't do that. And another great pull quote from Joel's article is, "When you start from scratch, there's absolutely no reason to believe that you're gonna do a better job than you did the first time." And there seems to be this- - I'm like 99% of the way there with them. - Yeah. - In fact, that's right. In reality, I probably totally agree with them. In theory, it's like if you wrote something five years ago and you come back to it, you could be like, "Yeah, that's, it probably could do better." I still don't think you should fix it, quote unquote, fix it. I mean, if it ain't broke, don't fix it, right? - Oh, yeah, sure. But- - Kind of just sums it up, so. - Yeah, exactly. I just, I find that the idea of people just say, "Oh, well, we're gonna tweak this and make it better." And I'm thinking, A, is it broken? No. Okay. So there is no B. Well, so that's, I think that's a matter of what you're focusing on. I think the correct thing is to be focusing on the product or the the usefulness towards the customer. Primarily. Yeah, fair enough. But I think some people see code and they're like, Oh, I could do it better if I rejiggered this algorithm. That's like, well, does that solve what problem? What real world problem is that solving for anybody? Because if the answer is none, then don't do it. If it's working now, all you're doing is potentially introducing bugs. That's it. You're not actually solving a problem with anybody. You're potentially creating them. And all of that time that you spent being fancy and then fixing being fancy, it's time that you haven't spent fixing other real problems that real people are facing. So I think it's a net loss, except for maybe your ego that you made something fancier. Yeah. And the problem is that that's that's that whole, the last bit of what you just said is, there's a belief that you're going to do it better or fancier the second time around. And inevitably, I don't think that's necessarily true. Not all the time, most of the time, it isn't. So it's just that thing. Even if you do, who cares? I mean, you haven't fixed any more problems. Does it matter if it's fancier or not? Yeah. Someone once said, I wish I had the exact, the person that said this, but refactoring is a loss leading exercise or something like that. So, you know, I don't know. To be clear, I'm not against refactoring when it's needed. Oh, sure, sure. You just have to identify the need rather than the desire. Yeah, I mean, if you find those two big differences. Yeah, exactly. I mean, if you fundamentally messed up the structure of your object, and you need to add a bunch of functionality, and there's simply no way to do it any other way than to rewrite it and refactor it to include that functionality, you know, okay, fine. That's fine. But honestly, that doesn't happen as often as you might as well, once you've got code that's out there, I find it doesn't, that doesn't happen so much. So anyway, yeah. Okay, so I've got a few more points. Small ones. So grouping data into structures, and this may be, you know, if we're talking about object oriented code, I keep saying object oriented, because, you know, Just sounds cool, I guess, whatever. Grouping your data into structures is something that is a choice in a lot of, you know, PLC platforms. But it just for me, it makes finding data you're looking for much quicker and a lot more sensible rather than just having, you know, and there's how many people have written articles about, you know, global variables versus, you know, and global is evil. I think global is OK up to a point, but you should do everything you can to minimize global and pass around what you need and group it, because otherwise it's really hard to find what the hell you're looking for. And I realized that I've just crossed about three or four different programming styles in the last five sentences. So if that's kind of risky, but yeah, thoughts, comments? I think that's almost unarguable. Structures are in terms of globals. I mean, that should be exceedingly rare. Yeah. Uh, you know, in objective C, all of the classes are effectively globals. Okay. That's one thing. Sure. Uh, the application is a global because, you know, guess what? You have to tell me one process running. So that just makes sense. Grouping data into structures is a no-brainer, as far as I'm concerned. I mean, I've been doing that since Pascal, for as long as you possibly can. Even before I could wrap my head around what an object was, I thought structures were the most obvious way to go around getting things done. Is that really even up for debate anymore? Do people argue about that? No, I don't think it is. And I guess this is one of the other problems I had when I put this in the notes to talk about is that, at what point is this just given and understood and we've been doing this for long enough now that we just accept it? And maybe that's just one of those and we should just move on. So let's just- So, well, one book that I wanted to bring up while we're chatting about this is an old book called Code Complete, which if you haven't read is brilliant. I think I've got like three of them around the house somewhere. Okay. It is a book by oh my god, I'm going to blank on his name. It's not Charles Petzold. Hang on. I got to Google this now. I can't believe this. Steve McConnell. Steve McConnell. I'm going to guess I haven't got there yet. Yes, Steve McConnell, brilliant guy, Microsoft Press, 1993. This book is terrific. It's written in 1993, mind you, so I mean, keep in mind that, you know, it may be a little bit outdated. The second edition is 2004, so, you know, maybe that's a little bit more modern. But it is a terrific book that lays out all of this kind of stuff. In fact, I'm pretty sure there's a chapter about exactly what you just talked about. I highly recommend it to anybody. I gotta put my hand up to say I haven't read it and I am now going to read it. You really should. It's still worth your time. I mean just skim through the... so if you go to the Wikipedia page, right on the bottom, there's an external link called "Code Complete Checklists". If you just scan through that, it's literally asking most of the questions you're asking now. Cool. All right. could you could look up structure and be like and so and so for the checklist format is basically it's like you're writing a structure have you thought about this this this this and this and if you can check off all of those boxes when having made that decision that set of decisions you can feel confident that you've got a pretty decent design yep and you don't have to check all of the boxes he's it's just more of like a mental like you know it's a mental model of looking at things. And if you don't, if you can't check a box, it doesn't mean you're wrong. It just means that you've considered why you can't check that box. So it's a good way of thinking about stuff. And that covers inheritance and structures and globals and all kinds of stuff like that. It even covers commenting, which we talked about before. Cool. Yeah, and I mean, I will I will put this out there. This is this this whole episode talking about, you know, all the different things that we think go into making better code and do's and don'ts and so on. This is not new, this has been a well covered topic and so on but I hadn't covered it specifically on the show and I thought it's definitely worth exploring from the show's point of view. I'm going to add that to my reading list and I will get to that and I'll let you know what I think. It's actually a compellingly quick read. You'll probably just tear through it. It's well written. cool. Okay, so a few more points that I had and then I'll leave it open for any others that you wanted to quickly mention and that is that breaking the code down. So break it down. That was terrible. Okay, so when you're about to write and this is the thing when you're about to write your program, your code, whatever, just take a little bit of time up front to map out roughly the objects or blocks, structures, functions that you're going to use. It doesn't have to be to the nth level of detail necessarily, but as the project gets bigger and you've got more and more people on it, for goodness sake you absolutely have to do this. But it's still a very useful exercise if you're a one-person show. And on bigger projects as well, just write an interface spec so that people know what the hell to expect from your objects, from your from your functions and so on. Because if you're going to work on this object, they're going to work on that one. Yeah. You've got to know how the hell the messaging is going between them. You've got to define that. You just have to. To me, that's the value of a header file. Oh yeah, sure. Absolutely. Because you get to put exactly what's public and you get to comment on it. Yeah, absolutely. And I'm not saying the format in which you need to document it. I mean, in my industry, we typically do it, unfortunately, in a Word document, but hey, whatever. I can't, I can't stop them from using that. But this is not a word versus pages comment. This is a, I'm a great believer in, well, why don't we just put it in the code and distribute the framework and say, right, here's our framework of the code and you go and figure it out from that. But nevermind, that's fine. One day I'm gonna win that argument, but nevermind. So yeah, so yeah, definitely break it down. Like MC Hammer, God. - It's okay. - Bring it up again, you know, why not? second time around the joke is funnier. Anything else to add to that one guy? I love MC Hammer. I know, I think that's good advice. So, for me, I think if I mean, I don't want to say do the snaps all the time, because that's far from the truth. But once you've had a lot of experience, you don't necessarily need to putting that much time up ahead because you know the general structure that you're gonna do. Yeah. Do you know what I mean? It's like, oh this kind of problem, okay here's what I'm gonna do. And it's a common approach that's not just for me, but it's what I've learned from working on other projects that are similar to it. So you don't necessarily need to write out like an object graph specifically. Certainly you do when you document it for other people, that's great, but if you're using common patterns and common approaches then and you're not doing anything fancy pants, then you know you don't necessarily need to spend that much time up front. That said, you know, measure twice, cut once, never hurt anybody. Yeah, absolutely. So definitely give it some thought. Especially if you're unsure of how to approach a problem, don't just go in gun blazing. It will not work. If it's a problem you've seen before and you've seen three or four different solutions and you've seen one of them or two of them be particularly successful while other two had failings, well now you're better. You can cull a bunch of possibilities right off the beginning, right? Yeah, exactly. Yeah, that comes more better with time. But if you don't know how you're going to approach something, don't just start. Yeah, exactly. And well, if you do, do the thing where you build one to throw it away, because guess what? It's not going to be any good. You may get it working, but you must have heard that expression, right? Like you build the first one, and then you throw it away because it's garbage, and then you go do it the right way. Oh, yeah. Well, that's the way of doing the first path where you're just trying to figure everything out. but it's the nitty gritty way of doing it, right? Like you build your doghouse and it's all screwed up and then you're like, okay, well, this kind of sucks. So you got to take it apart and build up a new one using everything that you've learned the first time. - Yeah, exactly right. And something else that occurs to me when we're talking about this is that just because you do set out a path early on doesn't mean you're stuck with it. And if you- - No, no, no. - Yeah, if you- - That's the worst. - Yeah, oh yeah. And so do not make a rod for your own back in that sense. I mean, okay, that came out wrong. It's okay to make the rod for your back, but you can modify that rod as you go if necessary. And the longer you wait to tweak it, the more a pain you will feel. So if you get in a few weeks into your development, let's say, and it's gonna take you, you're working for three months on a bit of code on a project, and it comes out after a few weeks, you realize you need to extend this, this, and or create or change this object slightly or modify this and so on, for goodness sake, do it sooner rather than later. Otherwise, you know, it's just so much more work and pain, the longer you let it go. So because I've noticed that there's a in larger companies, there's this momentum effect whereby it's in the interface spec. So that's what you're going to get. And if you want to add things, the longer it goes, the harder it gets. And it's like, oh, geez, I wish someone had spoken up sooner. And you speak to the developer, and they're like, Oh, well, I realized this weeks ago. Why didn't you say something? And I oh, well, because yeah. political reasons or whatever. Yeah. What's that? What's that expression? Yeah. Politics. What's that expression? Uh, a foolish and reading. So it's a hobgoblin of a small mind. That's cool. Something like that. Yeah. It basically just means like, if you're just, if you're just being obediently, foolishly, like just. If you're just being obedient in this case to the, to the plan, yeah, uh, you're ultimately just being kind of a dummy. Like you need to continuously adapt the plan to what you've been learning. It doesn't mean you throw everything out. But if you're not being responsive, and I don't mean that in like, technical terms, but I mean, if you're not responding as an organization to what you've learned as you're building the project, you're not helping yourself in any way. That's right. And a lot of that pressure comes from, you know, project managers that'll look at, well, I only care that you ship something on this date and anything that requires going back sounds like a bad thing up front. But the funny thing is with software is that sometimes it can actually be a good thing. If you iterate early, it can save you time in the long run. And trying to explain that to someone in project management that doesn't understand software, that thinks linearly is an exercise in endless frustration. So, you know. I've actually had a few good experiences with project managers that have been trying to warn ahead of time that we need to make changes. Sure. And then the top person is vettisant to do it. Wow. So I don't want to just bash on any one. Like this kind of stuff can-- and I think that's worth pointing out, is that this kind of-- what's the quote? I found the quote here. "A foolish consistency is the hobgoblin of little minds." Love it. Cool. But this kind of foolish consistency can come from any part of the organization. Anybody can stick their feet in the mud and refuse to change or refuse to realize that things will need to change. Yeah, exactly. So it's not-- often it's project managers because they're less close to the stuff, but it doesn't have to be. It could be a programmer who's got a particular being that's bonded about taking a particular approach that's currently not working or a designer that is like, he won't bend, or she won't bend because it's like, they're so enamored with the design that when it becomes impossible to actually implement, they just won't. They won't give it up, you know. Yeah, so it's a fair point. And I honestly, I rag on project managers all the time. Because usually, they're the bane of my existence. But they do have it coming. Yeah, they yeah, damn right. But the thing is that I say that, And then in the next breath, I got to put my hand up and say, I've done plenty of project management myself. And I mean, and on a couple of occasions, I was accused of, you know, not fully comprehending, you know, what I was adjudicating on. And the problem is the level at which you're managing. So if you're project managing at a code level, and you're just looking at code, that's one thing. but if you're their project, you take a step up. And when I was in terms of level of what you're overarching in your project plan, for example, when I worked at MPI Engineering, we built switchboards, we did the physical installation, we wrote the code, all of that, but they're all very different things. They're very, very different animals. And whilst I had a lot of experience writing the code, I had less experience building the switchboards, although that changed the longer I worked there and same with the site installation. So I had very little installation experience And then I accumulated that as years went by. But when I was doing the project management, I would often get into strife, particularly with the workshop that we're building the switchboards because they would say, well, you've given us however long to fit, blah, blah, blah to the switchboard. We need double that amount of time. And it's like, well, okay, fine. So I mean, I acknowledge the fact that, yes, I've been a project manager. Yes, I have messed it up as well sometimes. But I'm also a great believer that that's an unfair position to put me in. and the way that, yeah, 'cause I was put in that position, right? I was told, look, you've got to do the project management on the whole thing. And on larger projects, we can justify the cost codes and say, well, okay, we're gonna have a representative from the workshop manage their schedule. We're gonna have a representative from the install team do their schedule, and we're gonna have you do the software schedule, John. And I'm like, great, that would work perfectly. And on the really big projects, like the $10 million projects, that worked because we had enough cost to, enough cost codes to go around, enough money in the budget to do that. However, when it was just me and the budget was tight, they're like, "Well, we've got enough money for you one person to project manage it. So it's all your problem." I'm like, "Ha, yay." - Yeah, but you don't have the expertise in the various fields. - No, it's not. At that point in my career, this is going back six or seven years ago before I'd maybe even eight years ago. Time flies and you're having fun. But yeah, I was still getting that experience. I mean, I'm a lot better now. If I look at the switchboard, I can say, yeah, 14 to 16 weeks for that one. 'Cause it's, you know, like 10 meters long and whatever. - Well, you know why? It's 'cause you got thrown in the deep end. - Yeah, oh, sure. Yeah, absolutely. So to all the project managers out there, I don't hate you, okay? I really, I don't. (laughs) I love you really. But just note that sometimes there is frustration. Okay, anyway, all right. Enough aside on that. The last thing that I have to talk about quickly is testing. And the one point I wanna make about testing that irritates me is that so many people test to make and they don't test to break. And I love that expression because it rhymes. Test to make, test to break. So in other words, if you don't know what I mean by that, it means, I mean, test the functionality such that it functions the way the specification has described or the way that you have functionally intended it to work. So I'm going to send this message and I'm going to get this response, or I'm going to act on this and I'm going to get that blah, blah, blah. All that is testing to make in other words, make it work the way it's intended. What about sending a gibberish? Send it something that's out of bounds, send something that's illegal, invalid. Are you testing that test to break it, try and break this thing. And it doesn't just work on a on a code level, it go up to a user interface level, if there is a user interface, you know, click on stuff out of sequence, do stuff that that, you know, get someone that's never seen it before to try and break it. Because, yeah, you just think, no matter how long you've been doing this, you think, this code is ready to ship or almost ready to ship. I'm not going to name names, but someone recently that we both are acquainted with, made this comment recently, perhaps on one of your shows, regarding stuff that they wrote, where, yep, it's, it's a few weeks away from being shipped. Anyway, and then it went out for testing. And it's like, oh, crap. So the point is that getting other people involved to try and break it, you know, absolutely invaluable. And when you test it, you should test both angles that that's, I guess that's what I'm trying to say. And as for whether you should test it or not, I think that's self explanatory, please, God, yes, test it. Yeah. So I think I'm kind of guilty of that myself. Like, I'll implement a feature, and then I'll go and test it out. And oh, yeah, look, the feature works. You know, eventually, after a couple of iterations, you compare and contrast that to somebody like Daniel Jelka. You can give him a piece of software and he will break it within minutes, doesn't matter what it is. He's really, really good at breaking stuff. And it really is. I mean, it's frustrating. It's good, I know, I know, I know. It's just depressing to get the bug reports back. But a good... so one of the things that I I learned early on in my video game career is that a good tester is worth their weight in gold. Oh yeah. And especially in video games. They're often young kids. They pay them like crap because these kids come in thinking that like, "Oh my god, I get to play video games all day?" And it's like, "Yeah, have you tried playing broken video games all day? It's not as fun." And you know, they have weird incentives like the number of bugs logged and all of that. So it's kind of garbage in terms of repro cases. But a good tester with a good repo case who will sit with you and exactly figure it out is oh my god that's like a blessing from god right there. And because a lot of like the good ones do exactly what you say, they test to break and that's wonderful. I don't have that in me because I'm my loop is I get a like an endorphin rush from the creative process right? Well I say creative but you know from making something work. Yeah, like I'm a kid. I've got nothing. I've read a bunch of code. I run it. It doesn't work. Iterate, iterate, iterate. Oh, that works. Oh, that's amazing. Yeah, you're right. It's a rush. Yeah. Yeah, and then some, often along the way, I'll notice that something else screwed up and I'll be like, "Ah, okay." So then I'll have to go and fix that. But I very seldomly, just during my regular, I mean, I do, just during my regular day-to-day, I don't often go and try to break the app that I'm working on. For my own app, for my own company. I've got like two partners. We do spend some time trying to beat on it. It's not a day to day thing for me. I think one of the things that occurs to me is that we ourselves, the developers of the code specifically that we've developed, are perhaps not the best people to be trying trying to break that which we created. You almost... - Well, you really don't want it, you don't even want to see it break. - Yeah, well, that's it. It's part of our pride, I think, maybe, to an extent. - Oh, I've seen things in games where once they got pointed out to me, I'm like, you know what? I've been coddling that. Like, I knew kind of maybe in the back of my head that that was not gonna work. - Yeah. - So I just didn't do it. And games have this weird dynamic system. So, you know, you can avoid weird edge cases that you even subconsciously, you know? And once they've been pointed out, I'm like, oh yeah, I kinda, in the back of my mind, I kinda knew that was probably gonna screw up in some way. - Yeah, that's it. - Which is depressing, but good. I mean, ultimately you can't get good software without somebody having beaten on it, so. - Yeah, absolutely. So I guess that advice by extension is that if you're working on your own, having a beater is absolutely essential. if you are working in a team, having other people in the team try and break your code is essential as far as I'm concerned. And when it comes to adding functionality, it's important to go back over the tests and regression tests, those things that you already do to try and exercise and try and break the code again, because every time you modify the code, is it's potential for you to mess up what previously used to work. And that's another thing that irritates me is that people add functionality to a function or an object and they'll say, oh, I only have to test the bit that I put in that the new bit works. And I'm like, well, what about all your regression testing on all of the other things to break the code? And they're like, oh, but I only changed this one line. Yeah. With code that's running, you know, equipment, like in my particular case, specifically in the moment in oil and gas, if you get it wrong, I mean, there are some pretty massive consequences. So, you got to do that. If it's, you know, and another thing, even if you're just putting stuff into the app store and you put something out there, "Oh, I just fixed this bug, push it out. Time and review, time is money. Let's get it out there. I've got angry customers." Well, guess what? You fix one problem, you just create two new problems, let's say by accident. And then suddenly you're like, "Oh, no, oh, no." Yeah, take that time, try and break it. Make sure that it's solid before you send it out. that's that's anyway, so I'm not sure how many other ways I can say that if I thought about it, maybe two or three more, but we might just leave that. No, I completely agree. Yeah, good testing is invaluable. Absolutely. So that's the end of my list. Did you have anything else that you wanted to talk about that you see as being critical or useful in terms of going into good code? I think we covered most everything that I wanted to cover. Mostly because I got to bring up CodeComplete, which despite being 20 years old, I still think has some tremendous insights and is invaluable to programmers, especially new programmers. It's a remarkable piece of work that hasn't just lasted 20 years. It'll probably last another 20. That's how good it is. Yeah, cool. All right. Well, we might wrap it up there. And we've had a few questions come up during the show in the chat room. So please stick around after the show and we're going to do a Q&A. And that will appear after the outro music. So keep listening. But if you'd like to talk more about this, you can reach me on Twitter @johnchidjie and check out my writing at techdistortion.com. If you'd like to send any feedback, please use the feedback form on the website, and that's where you'll also find show notes for the episode under podcasts pragmatic. You can also follow Pragmatic Show on Twitter to see show announcements like when we're going live and other related stuff. I'd also like to thank my guest host, Guy English, and what's the best way for people to get in touch with you, Guy? - I'm @GTE on Twitter, and I write very occasionally at kickingbear.com, and I have a show called "Debug." - Fantastic, definitely listen to Debug, it's great. If you're into programming, it's awesome. - Thanks. - Yeah, the latest one also, the Revolution 61 was really good too. - Oh yeah, those guys are great. We got one coming out soon with, it's a conversation with Don Melton and Neaton Ganatra. - Ooh, okay. - Neaton ran the apps group for iOS and Don did a lot of the, he was in charge of the internet stuff. - Yeah. - That's right, yeah. - So that was fun. - And thank you for introducing me to Don Melton. And when I say introduced, I don't mean like personally, but I had no idea who he was when I heard him on debug and he's a great guy. So lots of- - He is great. - Yeah, so- - He's great in person too. - Cool, I'm excited about that now ahead of time. So cool, awesome. Alrighty, I'd also like to thank two sponsors for this episode. So thank you to Solver by Aqualia for sponsoring Pragmatic. You've tried a calculator and a spreadsheet, but if you haven't tried Solver, you're missing out on a great app that fits perfectly with the way your brain actually thinks about doing a calculation. Solver's available through the app stores, but there are links from Aqualia's website. But if you use the URL in the show notes, it'll help out Pragmatic. So please use that URL in the show notes to learn more about this helpful little app. And also I'd like to thank Space Nation and their Mac app, Hue Party, for sponsoring the show. If you have LIFX or Philips Hue bulbs, or both even, Hue Party can control them and add some neat effects. It's a free app for up to two bulbs, So check it out at hughparty, or one word, dot com slash pragmatic for more. And for our live listeners, please stick around. We'll be doing a Q and A after the show and to everyone else, thanks for listening and thank you, Guy. - Thank you. (upbeat music) [Music] (upbeat music) (upbeat music) [MUSIC] (music) (upbeat music) (upbeat music) (upbeat music) [MUSIC] [MUSIC] YUX Huang. I'm sorry if I'm mispronouncing that, mate. Okay. Don't really want to open that big can of worms, but what about fighting political battles when trying to get a technical direction? I guess my- - That's a whole show by itself, by the way. - I agree with you. It is. - Well, it's really hard to give a single answer to a political battle, right? Because it's the nature of human interaction that that's always going to be different. I think one thing that you need to be aware of is that the best technical decisions aren't necessarily the best decisions for the product. Yes. Not only that, I don't think that in all cases that the best decisions for the product are the best decisions in in line with what the company wants. Do you know what I mean? - Yeah, absolutely. Oh yeah. - You could have a product that, I don't know, pushes some other aspect of the company. I mean, let's take, I'm trying to come up with an example that I haven't worked on so I can actually talk about, but let's take the Twitter, native Twitter client. - Yep. - Clearly they make some decisions in there that are not the best for the product, obviously. like the Dick bar being the big one and sponsored ads and a bunch of other stuff. But they are best in line with the goals of the company. So they make the product worse, but with the hope of making the company better. And so in terms of the technical design, you need to understand that you're on at least a three axis matrix here. trying to figure out the best solution for all of these various goals. And they may be weighted differently depending on what stage of the development or the financial straits of the company you're at. So in terms of dealing with the politics, I think you really need to try to understand everybody else's perspective and why they're trying to do what they're trying to do. Because while a lot of it sounds really stupid, most people have a good reason. Yeah, I think that's the one of the- At least from their perspective, right? So, could be wrong, but. Yeah, I agree. I think the biggest problem that you face in a larger organization when you're developing software is that, well, honestly, doing any kind of design, to be honest, is that when you're getting political push, people tend to simplify it and they tend to vilify the people that are pushing that down. And it's like, oh, well, I don't really understand the technical problems. So then I really know this is really the wrong decision and so on and so forth. And I think everyone's sort of guilty of that at some point being the programmer or the engineer that's trying to do the implementation. And our initial reaction is all politics is stupid and they just don't understand and so on and so forth. But the funny thing that I found is that Once you start getting into higher up in the business and you get to those business level decisions, they start to make a little bit more sense. I mean, don't get me wrong, don't get me wrong. There's always going to be an idiot that says, I want it pink because it's because pink's my color and whatever. And it'll be some kind of nonsense that makes no difference to anything, adds no value. And you're just trying to get a technical direction. What color do you want this thing to be? And, you know, whereas the far more useful approach would be, well, you know, we know that blue is a nice color because it relaxes people or whatever the heck. Was it Microsoft that looked into what shade of blue was the most relaxing for their background at some point? I forget, but. - I wouldn't be surprised. I mean, I know Google A/B tested a bunch of colors at one point too. - Yeah, so yeah, but I mean, as ridiculous, almost ridiculous as that sounds, funnily enough. - Well, there's a reason that so much stuff is blue, right? - Oh, sure. - Just put it that way. - Yeah, exactly. Yeah, we need everything to look like the sky blue. But anyway, I guess what I mean is that once you get talking to the people who are making the political decisions and understand where they're coming from, you might just be surprised that there really isn't a political will necessarily, it's more about a, you need to understand the bigger picture. And it's so easy to get stuck into the, you know, get stuck into the weeds of the development that you just, you vilify the the politics and you start getting all worked up and angry about it, when in the reality is, you know, chill out, man. Just it's okay. I think a big one for me coming up was game design versus marketing. Oh, yeah. Where game design is like, basically, screw you, we're the artsy-fartsy guys, we're going to do what we want. Marketing is like, we just can't sell this game. And you're like, oh, sure you can, you can convince them. and it's that's seeing marketing's job is to convince them that your artsy-fartsy vision is the correct one and everybody should buy it is not appreciating what they actually do for a job. Yeah like they it's it's a two-way street and I'm not saying that marketing should dictate all of your decisions but I'm saying that pretending that they don't have any kind of input or insight into to the outside world is pure folly. Sure. And you should be working together in order to kind of come to a solution that, that, that hits as many of the, of the, um, uh, the goals of the various points of the organization as, as possible, which isn't to say like design anything by a committee, but it is at least be respectful of what other people in the company are trying to achieve. Because nine times out of 10, they're going home just as frustrated. Like when a project is going poorly, they're also going home being frustrated that the project is going poorly. So either you can just all get mad at each other, or you can kind of try to work it out. And I guarantee you, if you go into a meeting with that perspective, you will come out with a better result for yourself. Yeah, absolutely. It's all about frame of mind. Yeah, which isn't, which isn't to mean that this is a selfish thing, but it, you will get better results by understanding other people's position, because you will know you, you can learn to understand where they can can negotiate and where they really can't. And through that understanding, you can better figure out how to fit your plans and your objectives into that framework. Okay, cool. No, I do. I totally agree. And on the marketing side. Yeah, it's tough because marketing has this stigma, almost, I would say. Yeah, exactly. Associated with it. You kind of want to hate them. Yeah, it's the episode of Dilbert where Dilbert comes in and says to the marketing department of the Nirvana company and he sits down to the marketing department and he says, "You know, I can't believe you have a company without a marketing department." So, they create a marketing department for me sits down and the marketing guy across the table says about his underwater barbecue, he says, Okay, just a couple of thoughts. This is the marketing guy. One, does it have to be underwater? And two, does it have to be a barbecue? It's like, okay. So, you know, and that's the perception is that marketing somehow don't know what they're doing. But the reality is, marketing know a lot more about marketing, you know a lot more about programming. That's why you're doing each of your respective jobs. The two of you working together, we'll get a better end result. Well, okay, so here's the other thing. In the framework of that cartoon, the person who developed the underwater barbecue wasn't able to communicate to the marketing team why that was a good thing. Yeah, I mean, like, there's two there's two reactions to that. Marketing can be like, I don't understand underwater barbecue. And that's because the development team needs a little bit of a pitch guy. Like you need to be able to pitch in a certain way to be like no no this is cool because look at this look at that. You need to have a little bit of internal marketing from your own thing. You need to be able to sell your own perspective and to do that you need to understand what they're want to buy in terms of it and then this is confusing all kinds of terms because I'm talking internally and externally right. But if you can't pitch your own marketing people on something they can't pitch it out to the outside world. You need them to buy into your project. And there's two that you can either be like, "Screw those marketing guys, those idiots." Or you can go in with the attitude of like, "No, I'm totally going to convince you it's awesome, because it really is awesome." Yeah, and the longer I've been doing this sort of thing, pitching the idea, as you say, it's not just important to the marketing. But here's the thing, pitch it to yourself first. If you can't pitch it to yourself and convince yourself that it's a good idea, why are you bothering pitching it to anybody else? If you can do that and start with that and then pitch it to marketing or the high level management or whoever is who has the final say for a feature for your product, whatever, you know, then you've got to start there. And absolutely, it's all about you. It has to be something useful other than just it would be cool if, insert feature here, right? Because that's not enough. just isn't. Time is money. So and I know that sounds ruthless, but honestly, that's business. And that's just reality. If you're not thinking like that, you're not going to be in business for long, I think. Yeah, that's it's a business thing. I mean, I love art games as much as anybody, or even really opinionated software, but opinionated software that's not useful, doesn't deserve to succeed in the marketplace. It doesn't. You still need to earn that, right? Like you don't just get it because you've got something cool up your sleeve. Yeah, exactly. So you should buy this because it's cool under the hood. But you can't see it. And there's no useful features. But it's cool under the hood, man. So it's Yeah, exactly. How do you? All right, cool. Now, I also have another question. The last one. Last one. Behavior driven development. Behavior driven. So the question just for the listeners from Mac Birdie in the chat room. Thanks for this one. Any tips or ideas on applying behavior driven development to apps that are mostly UI experience focused. Okay, so MacBirdies provide a bit more. More generally, he says provide or he or she says they say, providing a kind of contract, how the app should work instead of creating tests for the apps algorithms. So okay, oh, so taking that testing, it'd be like working from the from what's that development process? The agile stories? Yeah, something like that. And then you'd say define some stories and then you keep developing your app until you fit a story. Yeah, essentially, your testability or your judgment for the success of your testability is done at a higher level at the UI experience level rather than testing the raw algorithms. At least that's the way I'm reading the question. I think, no, you know what, I think that's a natural way to develop. If I'm understanding it correctly, I think that's a natural way of developing software. I mean, you figure out how you want your software to be used, and then you keep iterating on it until it fits that use case. I see it as layers. You start out at the lowest level, and you can just confirm that it's something like Stories, yes. So, from that agile development sort of angle then. Okay. So yeah, I think that I-- well, certainly, coming from the game world, yeah, I mean, you develop a level with a certain number of scenarios in it, or like little cool things you want to have happen, and you write the game in the engine, and then you develop all the assets in order to make that happen, and until that happens, you're not done. And it's certainly in games, you don't really get to do a lot of unit testing, just because, like I said earlier, It's a vast dynamic system. And testing any one unit is cute, but it doesn't really help the-- it's a dynamic system. So there's so much state flying around that it's really hard to figure out what anything means in isolation, which is what unit testing is about. You take something in isolation and you test it. In a giant system, that doesn't really help because the magic comes out of the system rather than the isolation. But yeah, no I certainly when I develop my software I aim to, I don't, we don't do an agile thing per se but we have a use case that we want to achieve and we do that and we just keep iterating until we get that. Any obstacles we hit we try to resolve them. If I'm understanding this BDD specifically correctly is that It's unit testing plus the end of the story stuff. Whereas in the games and the stuff I do, I often end up skipping the unit testing stuff. Do you know what I mean? I'm mostly testing the top layer of what the user is actually going to be interacting with rather than the entire stack, which is what I think BDD is trying to achieve. Okay, so when I'm doing testing on my code, what I'll do is I will start and I will get the code at a low level as solid as possible and make sure that it's test to make, test to break and those will be very very thorough testing. But once you start assembling the blocks together I pretty well stop doing that unless there's a big issue of course but and I go back to read to go back over that but the low level testing but when you get to the the top end the end-to-end functional testing perhaps is the best way I'd describe it whereby you've got a certain functionality that calls on a bunch of different functions to do what it's going to do and then you get a certain result whatever that might be and I'll have a list of tests and I'll ensure that those tests that they pass but I will seldom go back to that low level after that unless there's a big problem. Or I'm doing massive modifications and I'm going to go back and regression test a lot of it but you know hopefully that doesn't happen too often because that really sucks but anyhow. So I'm not sure if I'm not sure if that answered the question, but thank you for the questions, guys. This is a, again, it's a new thing I'm trying, so I really do appreciate the questions. Hopefully I'll have the show bot up and running in the next few weeks, and it'll be a little bit more automated. And as the show goes out and people become aware that it is being streamed live, then hopefully we'll also get some more people. But a special thank you to everyone who's listening live in the chat room right now. You're the best. Thanks for coming along and joining in. I really appreciate it. - Thanks a lot, man. Thanks for having me. - Yeah, no worries. [8-bit music]