Coding Blocks - The Pragmatic Programmer – Tracer Bullets and Prototyping

Episode Date: June 10, 2019

The Pragmatic Programmer teaches us how to use tracer bullets versus prototyping while Joe doesn't know who won the Game of Thrones, Allen thought he knew about road numbers, and Michael thinks 475 is four letters.

You're listening to Coding Blocks, episode 108. Subscribe to us and leave us a review on iTunes, Spotify, Stitcher, and more using your favorite podcast app. And find show notes, examples, discussion, and more at the website, codingblocks.net. Send your feedbacks, questions, and rants to comments at codingblocks.net, follow us on Twitter at codingblocks, or head to www.codingblocks.net and find all our social links there at the top of the page. And with that, I'm Alan Underwood. I'm Jay-Z.

And I'm Michael Outlaw. This episode is sponsored by Discover.Bot, the only community for bot creators, and Datadog, the monitoring platform for cloud-scale infrastructure and applications, and Clubhouse, the developer-friendly project management platform. And tonight, we're continuing on with the pragmatic program, and this time we're talking about two stories, Tracer Bullets and Prototyping. But first, we have a little bit of news here,

so I'm going to read some thank yous here from iTunes. We got Sodds, TheCrow two, two, six, nine, apex wolf, and Ashley J Walker. All right. And from stitcher, we have. Ta.

Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta.

Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta.

Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta.

Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta.

Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta.

Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta.

Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta.

Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta.

Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta. Ta. Takonathan? Takonathan? Okay. I practice this one too, a lot.

Hold on. Bear with me. I want Outlaw to read my name. Got it. Thank. And Skywalker is Null. I love that name. That one's good.

That's really good. Appreciate that. How can Skywalker be Null if there's the rise of Skywalker hold on now I don't know you see the last one oh is that where you're going with this alright yeah fine spoiler alert dang it it's not very good

but you know what is good uh program parmesan parmesan just when I thought I might go an episode without pronouncing it weird, he reminds me why I should. My dinner was not satisfying. But we're going to be doing another book giveaway, so make sure to leave a comment on the episode. And we got a particularly great comment last time.

I think this was talking about the rap. Last episode, so I'm going to delete this. If you missed the rap, you should go back and listen because I did my Jay-Z impersonation. And, I mean, everybody loved it. So many positive comments. It's just been amazing. Thank you. Including record executives have been reaching out to him.

So a big thank you to the fans. You know, my mama, everyone that helped me out. Are you going to thank us, the little people, for getting you? Yeah, Buance or whatever. Can we be part of your entourage, part of your posse now? Did you say Huance? Yep. Is that our name?

Oh, man. That's awesome. And also, just a reminder, coming up at the end of June, June 24th at the Atlanta Intelligent Devices Meetup, I will be speaking on Kafka again. So if you'd like to learn more about it, want to come out and just hang out and say hi, please do come out there. I believe it's at the Microsoft campus. So yep, June 24th. And by the way, no hate mail, please. I know who Beyonce is. She's amazing. But I don't mean I know rappers, but everybody knows Beyonce. No hate mail. Except for Joe. Yeah, except for Joe.

Kick him in the shins. Come on. He Googled that real quick. We all know that. That's right. Pronunciation guide. Beyonce. All right.

So, yeah, let's go ahead and get into it. So the first topic up here in this section of the book is tracer bullets, which anybody ever seen or know what a tracer bullet is? I remember being a kid watching like Gulf Storm. Remember that? That was the first time I ever saw it. And it was like, how did they like all the cool footage with the night stuff? I mean, terrible stuff happening, but it looks really cool. Am I the only one that thought of like Call of Duty?

Are there tracer bullets? No one else thought of like any kind of games? No. Okay. I don't remember seeing a tracer bullet. I'm going to go stand in a corner now. No, but like what Joe was talking about is like you'd see some firefights and you'd see this one that looked like a firecracker going out in the middle of it. And then you'd see exactly where the bullets were flying, right?

I remember seeing a video like that all the time. Well, even if there weren't exact tracer bullets in the Call of Duty franchise, there were lasers that acted like a tracer. Yeah, maybe. I guess so. Then you could see exactly where your opponent was. Yeah, but that's different. Oh, right. Yeah, tracer bullets when you see where it's going.

So, yeah, if you've never seen that, maybe we should find a good YouTube thing and put it up here on the link. But, yeah, a tracer bullet. It's a little dark, but it looks cool. Yeah, it's just when you can see where your bullet's going. It's a round that they mix in with their regular rounds so that while you're firing, you can adjust while you're shooting, right? And it's a whole lot better than, like, have you ever seen the sniper movies or anything where they're like five degrees over here, two degrees north? Well, I was just thinking of the movie American Sniper where he made like the

longest sniper shot. It was something insane, like a mile long shot or something crazy. But yeah, and you sit there, you watch them and they have to sit there and calculate like

what's their wind trajectory, like how far is it and the curvature of the earth. Like at that point, the gun and the scope are at completely different angles, you know, to accommodate for the,

you know, how much higher the gun has to fire in order for it to arch. Yeah. For it to arc over to whatever the, you know, far away distance target is. And that's actually what they talk about here is, you know, there's the one approach like what you're talking about where you sit there and calculate exactly how it's all going to happen. And that can be a lot of work, right? Or there's the, hey, shoot, see where it went. Shoot again.

Adjust, see where it went. Shoot again. And, you know, sometimes in the heat of battle, it makes more sense to be able to adjust on the fly instead of sit down and do another hundred calculations. I mean, sometimes you don't have that. Sometimes you have to do all the calculations up front. And sometimes you can just Leroy Jenkins it and just run right in. Guns a-blazin'. Shoot first and adapt.

That's amazing. So – Yeah, the joke they've got there is that there's two effective ways to fire a machine gun in the dark. The key word there is effective, right? You either have to know, like, everything, basically perfect knowledge of the exact situation that you're in and you have to execute perfectly or else you need to have some sort of tracer bullet so you can kind of shoot, see how it went, and then adapt. And this fits really well in terms of software development, too, because we've all at least lived in the world of waterfall development specs to where somebody plans out something for three months. And then you have a two-year project that by the time you finished writing the project is no longer legit and everything about the business has changed in that time. So there's that method.

And then there's the newer method actually since I think Joe was even saying that's emerged since this book came out, right? What they talk about here is the iterative approach to where you just keep going. That's that's the tracer bullet. Make some stuff, see what people think about it and adjust. Right. Three years before the agile manifesto. Oh, it's three years. So it was actually pretty quick. Yeah. So the point is, is like, get your code out there sooner rather than later. And just like the tracer bullet, you can get immediate feedback.

So you can start iterating on those features or on your aim as you're going along throughout it, rather than like, hey, here's an all or nothing. Do you like all of it or do you like none of it? Oh, the delivery dates tomorrow. Cool, here, check out what we have. Oh, man, that doesn't do what we want. We just spent a year on it. Well, another point that they make towards this though is that if you go back to those waterfall approaches, you think about that. Things are going to change by the time you're ready to deliver. So if you do try to do that all or nothing

waterfall approach, then you're setting yourself up for failure because something's going to change along the way and it's just going to delay you that much longer. Yeah. Software's hard. Go ahead. You know, I just thought of – so continuous delivery, it's common for companies like, say, Google or Amazon or whoever to deploy a bunch of times in one day, right? Which was unheard of in 1998. And now it's common for even more than 10 times a day. I'm sure there's companies that deploy 100 times a day. Is that even possible in a waterfall methodology? How do you plan to that granular level?

Yeah, I don't know that you could. Yeah, I don't know that you would, right? I mean, because that's the thing is you're just going against a set of checklists and you don't really care how it all looks right now. It's the end product that you're going after. Whereas this whole approach of the tracer bullets is let people see it every step of the way, right? And I guess with Waterfall, like you kind of like at least the one I worked on before, like you kind of work on one big thing and then it'd have to be done. And then you would work on the whole big, big thing. But like the whole thing didn't work together until basically the end.

Right. Big milestones for each section of the project. Right. Yeah. Yeah. So. All right. And Joe loves doing the tips.

So. Oh, yeah. Hey, tip 15. Use tracer bolts to find the target. I like that. Yep that a lot, actually. You know, you shoot the whole analogy that they put out there is you shoot, you write some code, get it in front of the customer, the end user, and they can say, oh, I like that. Or no, that's not going to work at all. You know, you got this completely wrong.

All right, cool. Well, we totally missed there. Let's go ahead and realign with what you just told us and now you can you have another short feedback loop yep so five minutes in and we already got our first tip doing pretty good that's not terrible and then we figure out there's only like 18 tips in the whole book no there's more to make that up tips i i don't have any clue you guys have read it before. I hadn't. No, there's 70.

Oh, wow. Okay. Off by a factor of a few. Yeah, it was a rounding error. You were only off by a rounding error. It's one of those floating point things we talked about previously. I think one important distinction of tracer code is what they kind of refer to as tracer code is that it's not a throwaway. It's not like you're constantly ditching this stuff.

It contains all the validation, documentation, tests, and so on that production code has. It's just designed to be feedback driven. So you're able to roll this thing out to something like production or to the stakeholders and get that feedback on and then adjust. But it's not really an intermediary stair step. It's, it's kind of done in a way, you know, it's the bullets out there.

The, the, the goal has been, the target has been shot at. And it's, it's just what you said before is it's very similar to what this whole agile movement was, right?

Put something together, figure out every sprint, whether that's every two weeks, every three weeks, whatever, what's important and go after that goal, right? Put something together, figure out every sprint, whether that's every two weeks, every three weeks, whatever, what's important and go after that goal, right? Like constantly reevaluate what you want to do next and what needs to be done next so that you're not just in the state of, oh, I'm looking, you know, a year down the road. You're constantly trying to get out there in front of what the customer needs or wants and what's the most important. Yeah. And the idea is that you're never going to be finished with your project,

right? You're always going to be improving it incrementally, you know, getting that feedback, make the next feature, you know, or the next improvement or whatever. Right. But that's also kind of a sad way to think about like your code is never finished. It does kind of hurt to hear something like that. There's never an end in sight. Because when you work on projects like that, it can become very tedious over time. But it is an honest way to think about it, though. Any project that you're working on, there's always going to be features that are, someone's always going to ask for a new feature or to make a change. You're never going to be done with it. And the only times that I can think of where you are going to be done, where you're going to walk away from it, is if you are in a services organization to where company A hires your

company, you walk in the door, write whatever it is that they want, and then you walk away and you never see them again. Yep. As an employee of a company, that's almost never the case. Right. Yeah. Yeah. If you're employee of a company, that's almost never the case. Yeah. Yeah. If you're,

if you're in a consulting capacity, that's definitely. And, and for anybody out there that's never done consulting, that's actually a lot of fun. It can be frustrating, but it can be a lot of fun because you get exposed to a lot. But on the flip side,

you never really get to see how everything comes to fruition over time. So there's an upside and a downside. Yeah. But you, you never really get to see how everything comes to fruition over time. So there's an upside and a downside. Yeah. But, you know, you can also guarantee that you're always working on something new. And usually the latest and greatest. Yeah. Latest and greatest, Greenfield. Now I want to go back to consulting.

Okay, that's it. Hey, can we wrap up early? We're done. You know, this book was published 12 years before the notion, at least where I think the notion of the MVP was first kind of talked about, at least in tech circles. The book Continuous – wait, no, that's not the title. I forget the name of the book. The Lean Startup came out in 2011. That was the first time I heard that.

I don't know if someone else had coined that earlier. But still, it's way ahead of its time in terms of this thing. When they were talking about tracer bullets, that was like they didn't have the word agile. That was their best way of kind of describing what they were thinking. And they hit the nail on the head. I mean, what they're describing here ended up being like a huge game changer over the next 20 years. That's been awesome.

Now, I think stakeholders that I work with get really squirrely if they're not seeing results in a couple of weeks. That's not how it used to be at all. Yeah. No, it's so true. It really is true. And, and they even called out the alternative to this whole,

you know, tracer bullets last agile approach is, is what we said with the waterfall thing where everybody sort of works on separate modules in vacuums. Right. And then at the very end, they want to bring it all together and show that it works. Now, this is where we've had previous talks, and I wanted to bring this up because this is sort of counter to some of the other things that we've talked about in the past.

Because it's almost like what they're going for here, and they even gave examples in the books, and we obviously don't go over every single example they talk about is, you know, until tonight, until tonight is when you have a multi-tier application, right? You can have a front end, a middle tier and a back end. You know, they're typically talking about this whole, this tracer bullet approach is you're working on all three at the same time, right? Because you're iterating on this thing and you're coming up with something to go show your end user. And so it very much favors a full stack type approach to this thing, right? And this is almost counter to like what we've talked about with things like clean architecture, where it's like divide your things up into modular components, right? Like they're almost saying here, you shouldn't necessarily do that. Now, I know that they're talking more about in a vacuum, like people just going off and working on solo and they never really put their head up for air or to talk to anybody.

But it does feel more like you're talking about a tightly coupled type thing, right? Because you're trying to make this work. And it's kind of hard to do that if you're constantly iterating on things and you've got to have some database things in sync with some middle tier with the UI. But even in the case of the clean architecture, though, as it related to teams, they did talk about agreeing on a contract between the teams. And then you could just mock that contract for your side so that you could do the development on your half, on your side of the line, right? And it worked fine. That's true too. Yeah.

So if that line is between like, okay, if we broke up the teams by tech stack, which is what these authors preferred back at the time of the writing, right? Then that line might be among, you know, your, your database developers versus the C sharp developers, for example. And so in that case, the data developers might be like, okay, we're going to have an orders table. And these are the, you know, eight columns that are going to be in it. All right. And you would say eight, why so many? And then someone else is going to say eight, why so few? But it's got the eight columns.

But then that way you could like mock it out against that, right? That's true. That's true. But it would definitely imply that you're going to be communicating a lot more with all your layers, right? Because if you're trying to do these tracer bullet approaches, everything has to be in harmony as you're showing these things, right? It requires a lot more communication.

A lot more communication and coordination amongst those tiers. This is where full stack people are super good at getting this stuff together because they touch all three, right? Like, hey, I need this. Okay, well, let me go modify the database, modify the middle tier and then modify the UI. But that also can lend to messier code over time too. So, I mean, we've talked about this too. Like the, the more people, the more lines of, the more people that get involved, right. The more exponential those communication lines become, right. That doesn't scale well. Yeah. Like it becomes, it becomes increasingly difficult.

So if you're working in this vacuum world, waterfall world, if for some reason you're still in the 90s using 90s workflows, right? I don't know. There might be shops out there. I'm sure there are. So, yeah, you have to keep all of those teams in sync, communicating with what those needs are. If that's a large team or a large company, man, I don't even want to think about

what that looks like. Those team meetings have to be ridiculous. I would swear that the waterfall approach had teams by parts of the tech stack. What would happen with these long iterative kind of cycles, like a two-year product release cycle,

is the work was never distributed evenly for a release. So there were teams that would spend two years under the gun. And there are other teams that kind of would get done a little bit early. And so they kind of like, you know, what happens when there are free hands when there's still work to be done is you basically get thrown somewhere random. So the people on the teams that kind of had their part already finished and buttoned down, all of a sudden they're free agents and they're getting stuck with like the worst bugs, the crappiest stuff. Don't know teams they know nothing about. And of course, they think everything's crap that everything's working on because they're not used to it.

And it probably is crap too. But it's just a bad place to be in no matter what and ultimately they get to kind of say like well this bug's here because these guys are idiots and then it just makes the people who have been under the gun even more angry and upset and it's a bad situation it can last for a long time too imagine being on a small team like you're part

of the project done three months in and then you got all these jokers on these other teams that are delaying your release you know like why can't they get their stuff done. So it's a bad situation. It's not easy. This episode is sponsored by Discover.Bot. Discover.Bot is an online community for bot creators designed to serve as a platform agnostic digital space for bot developers and enthusiasts of all skill levels to learn from one another, share their

stories, and move the conversation forward together. Built by Amazon, Registry Services Inc., Discover.bot is an informational place for novices and experts in the bot development space. Discover.bot regularly publishes how-to guides and the latest bot building resources such as how to design a bot personality, how to set up payments through your bot, or how to stop shopping cart abandonment. Discover.bot also shares expert advice and provides insights on all things bot-like, what KPIs are worth measuring, why emojis may be breaking your bot,

or how to write an engaging chatbot dialogue. For newcomers in the space, discover.bot will teach you everything there is to know about these bots with articles such as the Beginner's Guide to Bots. Already have a bot of your own? Discover.bot can help you choose a framework that's aligned with your business goals and needs. Head to discover.bot slash coding blocks. That's discover.bot slash coding blocks to learn about how to get started on your next great bot. All right, so

let's talk about the advantages of tracer code. So first and foremost, we've kind of already hit on this, but one of the main advantages of tracer code is that your users get to see things working earlier. They get to see the fruits of your labor sooner rather than later, and you get that feedback. And this is nice because you can get them disappointed early, and then you can kind of forget about it as you kind of move on with the project. And so there's not like this big pin-up release of disappointment at the end of the project somehow i feel like he got the wrong takeaway yeah wait i misread the notes i think he might have paraphrased a little you know whatever the idea is that we're reducing the risk of disappointment because people get to see what they're getting and so we're setting the expectations appropriately and even if they are a little misaligned uh you know from week to week

or from from the beginning then they eventually kind of fall in line as the process continues because everyone's involved and the stakeholders involved. And so at the end of this process, no one can say like, this doesn't work like I said it should because, hey, like, hey, you were in all the same meetings I was. You saw this thing 8,000 times before we published it. So you're stuck with this too. Hey, so what's the right level of people to get involved? Have you ever worked on a project where you worked with maybe a manager and maybe they didn't understand the system as well as the people that were working under them, but the manager wanted to make the decisions versus the, you know,

like how do you hit that right balance? Oh, man, that's such a tough question. I hate big meetings and there's like 17 people and only two are talking. At the same time I really hate it when the end users or the people doing the work aren't talking and it's like kind of the managers making decisions. I guess things could get lost in translation so

it's not necessarily a nefarious manager but it's just really hard to kind of represent that. So like if you're doing the work, you may feel like your voice isn't being represented or your argument wasn't made the way you wanted to make it. And then you lost your way. And then it's something that's frustrating. So, I don't know what the answer is.

I think if you just keep things small, make really small tools and never work with anybody or only one, two, three, four other people, then that's the way to go. I definitely think the people closer to how things work is helpful. But, I mean, like a word of caution there, too. A lot of times, even when you're working with the people that work with the existing tools, they're so conditioned by the way the existing tools work that they don't think about the end workflow. Right. They think about the workflow that they're used to. And no, you have to do this, this, this and this. And it's like, well, wait a second.

If we if we simplify this a little bit, we can make your life a lot easier, improve the system overall. But it's, you know, and that's where it's up to you as a professional developer to be able to assess the situation, you know, figure out what's really happening, you know, find out the details from the people involved, find out all the steps they have to do, but then also reel it back in and say, okay, what are we trying to accomplish here, right? Like we're trying to make a better product for the end user. What does that mean? Yeah, I mean, you can't take away their red swing line stapler from them,

expect them to be able to focus. Yeah. This bullet point right here, I swear, even when I read it in the book, I still don't even really understand what they're getting at here okay thank you thank you we've talked about this before about the highlights this is the one where I was like

I can't even get behind I don't know what we're talking about here I don't see anything worth highlighting in it everybody that's listening is like what are you going to tell us here so Joee's maybe you're the only one who understands this are we talking about the piece of paper yeah yeah oh my gosh i totally agree with this i am okay so the book says the most daunting piece of paper wait wait wait wait wait no no no back up

the first bullet point there hold on hold on i just got to point this out i just got to point this out oh no no we're not this out. Oh, no, no. We're not at yes, yes, no. We're at yes, no, no. Sorry. Never mind. Nothing to see here. Go ahead.

Hashtag nailed it. So, hold on. The title of this section is Developers Build a Structure to Work In. All right. Take it away, Joe. Okay. So, they say the most daunting piece of paper is the one with nothing written on it. And I totally am a big believer in this. i'm a believer that the constraints set you free i know it's like if you've got like

colored pencils and a blank piece of paper chances are you're not going to do anything because it's like it's too free you could do whatever you want so chances do nothing but like you give me a picture picture like nicholas cage and some colored pencils and a blank piece of paper. I'm going to make something cool. You know, that's like, it looks like Nicholas Cage, but, but hold on,

hold on my, my, okay. This is where I'm confused. I totally get what you're saying with a blank piece of paper can be daunting. You got some project needs to be done. Where do you start? Okay.

That's all fine. Because it's like, because then you get into analysis paralysis or decision paralysis where you can't decide what to do, right? The blank canvas is difficult. That's what we're saying. Yes, I totally get that.

But how do tracer code or tracer bullet solve any of this? I don't understand the context of this with tracer code the advantage of tracer code is you have developers build a structure but what yeah so the way i kind of interpret it is it's like if you sit me down and tell me like the the plan for a business that's going to launch three years from now and you like describe uber really basically say, hey, we're going to kind of democratize and meritocratize driving people around.

And people need to be able to find drivers and take them places. And we need to launch this thing in three years. Go. Like, what language do I pick? What database do I pick? I've got three years to decide this. I shouldn't just pick the tools that I'm comfortable with. I should really make some decisions here. I should look at other companies that are doing stuff. I should

do all this analysis paralysis type stuff because I've got three years to work. I need to make the right decisions now so that I don't waste my time and waste that. But if I know, hey, we're going to try and build a company that's going to take people around, you got one week until our next meeting and you get to show me what you got. Then that's going to change how I behave. It's going to get feedback sooner. And I'm probably going to start with no JS. So you're saying that by taking the tracer bullet approach and just saying that you need to get something in front of somebody quick, then that's no longer a blank sheet of paper. Don't give them a piece of paper.

Just pull the trigger. Okay. I still don't get this section. I mean, I get the whole point of having something together, but I don't understand how tracer code turns a white piece of paper into a piece of paper with stuff on it, right? Like you still got to make that. You still have to make that jump or don't jump decision, right? Like, oh, crap, we're going with go.

It's Nicolas Cage, man. Apparently Nicolas Cage is the answer to all these problems. You need to spark this fire anywhere. He did raise Arizona. That's right. We talked about Nicolas Cage. We've talked about him a few times. I don't know.

Have we? Beyonce. Beyonce. You just need to. Have we? Beyonce. Beyonce. You just need to be careful in this structure. If we go back to the last episode and some of the things we said there, though, that the decisions that you're making there to make them reversible, right? So that you don't – what you don't want to do is build yourself in a structure to where you're stuck in Node.js. Yeah. Right.

If you later decide, oh, well we want it to be in Go or whatever, you know, you know, language du jour you, you choose, right.

That, because like one of the things that was said last time, which almost seems like this kind of fly, like these two things are almost feel opposite is that, uh, last episode we talked about that, um, as you make these critical decisions, they, they aren't easily reversible. Right. And so now we're saying like, okay, well, uh, to solve the blank canvas problem, we're just going to go ahead and like create some small things, you know? So, Hey, how are we going to deliver this feature? Oh, we're going to do it as a web app. Okay, cool.

So we know that we're not writing, you know, a, hey, how are we going to deliver this feature? Oh, we're going to do it as a web app. Okay, cool. So we know that we're not writing, you know, a Windows application or an iOS application. Okay, cool. So that narrows some of the scope down to languages that might be involved there or frameworks that might be involved there, right? Like each one of those decisions, you know, it's now it's like it. That's where the challenge comes in is to keep it reversible. And that's not the easiest of tasks, but I guess the whole point here is, is,

is if you get something started, then people can work within it, right? They, they start moving forward in that. And that totally makes sense, right? We've even talked about it in the past with,

if you create good code patterns, people don't want to break them because you don't want to be that dude with your signature or, or do debt with your signature on the code saying, you know, you broke protocol here and dirtied up the code. So I get it. It just feels like it was weird in this section. Yeah.

If someone gives you a machine gun in the dark, you just start shooting. That's what you do. You don't look for a piece of paper. Try to point it away from yourself. That's a good tip. That should be the tip of the week. All right. Better than most of mine.

So, okay. So then moving on to one that we can get behind and support is that by doing this, you're creating an integration platform. So that every day you'll be integrating in the features from various developers and teams so that your debugging and testing are happening faster and more accurately and more often. Yep. And they even say, as opposed to developers working in silos and then hoping everything works together, we've all worked in environments where everybody's working on stuff and then at the end of the week you had your build.

And then it was like, oh, God, it's Friday, right? It goes my entire day. Oh, and if we're lucky, it won't bleed into Saturday, right? So anybody that does development and they're doing it the old school ways without these continuous integration things, man, there's so many good tools out there nowadays that really didn't exist probably even that well five, six, seven, eight years ago. Man, you need to take a break and go look because it can really ease your life. I'm really curious to see what the modern update of the book has to say about all this stuff now. We've got things like velocity charts and Scrum. There's a whole industry that's sprung up around Agile.

So I'll be curious to see what they have to say about that. I'm curious to see what things in the book they talk about now are going to be things that we're talking about 20 years from now as being important. Yeah, totally. They really did foresee some future here though, didn't they? Man, they really did hit some stuff. Talk about sightseeing, future sightseeing. They nailed it. Yeah. They may not have used the same words, but I guess it's kind of hard to sell a bunch of courses around tracer bullet methodology versus agile.

You want to be a scrum master or you want to be a shooting master? Once you have a downer, it's a bummy. Yeah, exactly. But, yeah, they also talk about the continuous integration and delivery, which is, again, just something. If you can push that button, you know, 100 times a day, you have 100 commits come in and it automatically kicks off 100 builds, you know you're good. Like that's beautiful. Yeah, I do wonder though. I mean, kind of to the point that you guys were saying something similar to what you were saying though. Like I think a lot of this has just been like an evolution as to like not just the methodology that we as developers do, but also just the speed of the equipment around us that we're using.

You know, because it's gotten so ridiculously fast now that we can't afford to spend CPU cycles doing some of these things. We're like, you know what? I don't care if that machine builds a thousand times a day. What else is it going to do? Versus, you know, there was a time where, okay, you want to do one build? All right, you better really mean it because that's going to be an all-day affair, right? Like, you know, and it's sad to think like that. But, you know, mean that's that's

not an untrue statement well i mean you just have to schedule time with computers and then take your punch cards to the library right good lord that's insane but i mean like the tools have seriously gotten so good that like we've said it before if if you're new to programming or even if you're experienced in programming it's worth going out and getting involved in like some Git projects or something because the tools are built in and they're free. Like you can go up there and do builds. You can have continuous builds or continuous integration type stuff in GitHub. You have the same thing on Azure DevOps now to where you can go up there. You can set up these pipelines, these builds.

It's free, and that's crazy. So if you've never done it, if you've never looked at it, you should totally, totally go look at it this weekend and just get an idea for what all this stuff means, right? Like having your – Kind of like a Travis CI kind of thing? Yeah, yeah. So like there was Jenkins, there was TeamCity, there was Travis CI, all that kind of stuff, but now it's built in, right? Like you, you get that stuff for free. Yeah. You could spin up a site and like five minutes on Netlify Gatsby starter five minutes, and then you just iterate from there. It's pretty

amazing. It's insane what you can do nowadays. Well, I mean, not to take away from Netlify, though, but I mean, the point that Alan was, I think, making, though, is it just like alongside the source control itself. You know, like if you have a GitLab, you can have build pipelines right there in your GitLab. So as soon as the code is checked in, it can run tests and do builds and sanity checks. It can check for, you know, like you might be, uh, like maybe you want your, your code formatted consistently,

right? So it can do those kinds of format checks. Yeah. And even, even something like Azure DevOps, it's not just their source control. You can tell it, Hey,

I want you to hook into a GitHub repo. I want you to hook into, you know, uh, Git labs or whatever they have. You get hooks into all these things. So you could actually get their build pipelines using external source control for free, which is, again, like all this stuff that we're talking about here actually matters a lot because if you have been

a part of a team that did a build once a week or once every two weeks, then you understand and you know the pains. Whereas if every time you have a pull request, it gets approved into master or a particular branch, it builds, you get notified immediately. Hey, this thing blew up. Go fix it. You know? And it can take away that old works on my machine. Oh my God.

Argument. Yeah. Yeah. The tools have gotten better, but people just keep wanting more and more out of us. They really do. Yeah. We shouldn't have, should have kept a little quiet. We should have sandbagged a little bit.

Oh, man. I'd be able to pick all day. It keeps you more in touch with the progress, which is really good. It leads to setting those appropriate expectations and lets you know when you're about to drive off a cliff, which is really nice. Yep. One big point, Amy, too, is tracer bullets don't always hit the target and that's okay it's designed to show you what you're hitting and it's okay if you miss as long as you can adjust so we talked about reversible decisions and things like that in the last show and uh it's just more kind of tying into that so if you can't adjust then the tracer bullets don't do you any

good right but you see him shooting over the target, and you just keep shooting. Yeah, like, what am I going to do? We got a deadline in two weeks, and that happens all the time, by the way. Yeah. It's like, we're agile, but we got a deadline in two weeks,

and we know it's wrong, but, you know. This is the path we're committed on. Oh, that's hilarious. Yeah. I just picture, like, you're holding a gun in your hand, and it's like it the rate of fire and and the force at which it's firing like you can't control it so like you keep squeezing the trigger but you know it's just that's exactly what it sounds like that's what happens when you don't pause while you're shooting. Yeah. That's how I feel.

Picture every comedic scene where the frail person is holding the machine gun, right? That's what it's like. Yeah, a kid with a fire hose. That's real development, too. So I

did like this one comment that they had in there, and I quoted this one because it's true. A small body of code has low inertia. Do you highlight that one too? Why do you always get the same things as me, man? That one was so good because it's so true. If you don't have a massive, huge pile of code, then it's a whole lot easier to change, right? Like it's a whole lot easier to change, right? Like it's a whole lot easier to

make these changes that you need. And that's why keeping assemblies smaller and focused is super helpful. Or even methods, man. Let's go back to Uncle Bob, right? And you just have a three-line method. Yep. What's easier to read and understand? A three-line method or a 3,000 line method? Now, which one of those is going to be easier to change or to refactor understand a three line method or a 3000 line method. Now, which one of those is going to be easier to change or to refactor when a new feature or a bug comes in? Right. What about 10,000 three line?

Okay. Well, you got me. Well, I picked that one. So that is actually, I was going to say that is something that is arguably sort of frustrating, right?

Like, so yeah, you have your three line method, but then you F12 into one of the methods there. And then that goes into another one. You have 12 from there. Like there's no doubt that you end up hopping around a bunch of methods, but at least they're small and isolated,

right? Yeah. Yeah. Hopefully it's really important. So if you make a change here, you know, it's not breaking things out of the places. Right.

And it's testable and it's testable. Yes. So this small body of code, this small tracer bullet, is testable. Yep. You ever work somewhere where you're working on the project and a question comes up like, hey, what happens if the user tries to do this?

And someone says, well, what does the spec say? Or what did the plan say? And they kind of go dig out the email that explains how things are supposed to work. And they use that as if it's like the plan say? And they kind of go dig out the email that explains how things are supposed to work and they use that as if it's like the plan that will rule the universe. The one authoritative source and ultimately there's mistakes and stuff in there

but for some reason like somebody on the team or the team is just kind of orchestrated to like kind of believe in that binder. I've worked at places where people would have like a binder that would show up and everyone would see the binder and the whole developers were just staring at the binder like, I wish you'd just lose that thing.

Not talking about anyone in particular. A binder, man. What are you talking about? I've been in places where you had a person who that was their role. To be able to tell you. They knew. Hey, what's supposed to happen when you click on this? Oh, I can tell you yours.

When you click on that, you go over to this and they would be able to show you. Yeah. Here's the diagram of what that's supposed to look like. Here's what that interaction looks like. That's no fun. Yeah. Move fast, break things. Well, nowadays.

So yeah, the next thing they said too, is the business will feel more comfortable with the change, too, when they see how easily things can change. And that is super true. Sometimes they don't get it, though. Maybe they don't get it, but it's like they'll say, hey, can you change that checkbox? You're like, yeah, two seconds. And the next time they see a checkbox, they're like, hey, can you add a checkbox? You're like, that's a whole other can of beans. Right.

I don't get it. But last time you changed it. Yeah, that checkbox. Last time it was a radio button and you asked for a checkbox. Yeah, that checkbox is not that checkbox. Yeah. This checkbox touches every single line of code in our code base. Yeah.

So, tracer code versus prototyping. I actually like this because I was kind of curious what they were going to say about it. So, prototypes are designed to explore a single aspect of something. And they're designed to be throwaway. And that's really the key. More or less than anything else here, prototypes are trash from the beginning. They're there to explore something quickly and then toss it away. Yeah, and we're going to be talking about prototypes more in depth here, but yeah, it was just kind of the big distinction there. Tracer code is meant to adjust and prototype is meant to throw away.

Well, also too, did you say that the tracer code is lean, but it's complete? We did not say that. Right, so, I mean, that's another thing. Testing and all that. The prototype might just be like, hey, what do you think if it looked like this, right? But it doesn't really do anything. There's nothing functional about it, right? Whereas the tracer code, it might not have all the bits there, but everything works that is there. And is being done in an appropriate way.

So I kind of envision that as like some of the tools that designers could use to mock uis right so they could easily prototype out a design to where like everything in the drop down box is hard coded right like if you click on something you're absolutely going to go to the next page no matter what you know like that's the smoke and mirrors presentation right that's the prototype it it it's just to get the idea across like hey do you like this the this? The way I'm visualizing this, like that kind of idea. If not throw it away and do another one. But there's, yeah, exactly. There's no real code behind it. You know, it's, it's not, it's not production use. Yep. So it's that time of the show where we do like to ask you, if you haven't already, please do leave us a review.

Head up to codingblocks.net slash review. And, you know, we thank everybody at the beginning of the show for taking the time to do it. And we read them all and seriously, super appreciate it. We love seeing that we're helping people out, helping people achieve goals, right? Like you just got something today or yesterday, Joe, where, you know, somebody's starting an Uber job, you know, and, and they said a lot of it was because of what they were going to their first day at the Uber job in an Uber. I loved that part. They're taking an Uber to go to Uber. Well, that's like inception there. And, and it was, it was seriously awesome to hear

that, that we've helped, helped that person along their way. Right. And, and we're not going to say their name cause you know, maybe they didn't want to share that or whatever, but it is really incredible for us to be able to help people out. And, and so, you know, please do if, if you would like to give back to us, you know, go leave us a line, say hi, thank you and whatever. And we super appreciate super appreciate it and and as outlaw always says you know if you haven't share it with a friend you'd be surprised how many people don't even know what a podcast is right so you know maybe you grab their uh android or iphone from them and say hey let me show you how to get this done so so yeah all, with that, we head into my favorite portion of the show.

Survey says. All right. So a few episodes back, we asked, did you improve on the things you wanted to for 2018? Which is very topical of us to discuss now that it's mid-2019. So you see how on top of a good idea at the time. You see how on top of it we are. We do not procrastinate around here. That's right. Alright, so your choices were, I did

as well as improving on additional things. Or, I was able to focus on my 2018 goals and improve on them. Or, I crushed some and failed at others or no, dang it. Or lastly,

wait, I was supposed to set some goals. All right. I think Alan went first. So Joe, you go first. Which one do you think was the top choice? And by what percentage?

I'm going to say no dang it at 34%. No dang it, 34%. So I also think that's probably going to be the top answer, but I'm going to go more optimistic here. I'm going to say I crushed some and I failed at others. And just to be fair, I will also go 34%. Oh, I thought you were going to go the no dang it. No, no, no, no.

I want to be positive. All right. Oh, I see what you're saying. You were saying you really think that no dang it is going to win, but you wanted to pick something that was more optimistic than that. Okay. If you were to pick no dang it, what would it have been?

Would you have stayed at the 34? No, I'd have gone, uh, 40. Really? Okay. So Joe says no dang it at 34%.

Uh, Alan says I crushed some, failed at others at 34%. Yes. And Alan wins it. Nice. Good. I crushed some,

failed at others. 51%. Nice! Oh, wow. That's really good. Congrats! Yeah. So congratulations

to our listeners who are out there busting it. That is amazing. So what was the second one? No Dang It? No. Like, you guys,

I was really hoping you were both going to go with the No Dang It because that was like last, dead last. Wow. Awesome. Good job. No. no like you guys i was i was really hoping you were both going to go with it no dang it because that was like last that last wow awesome good job no uh the other one was wait i was supposed to set some goals yeah so you either you're either like in one of the two camps either you were crushing it or you didn't know you were supposed to be crushing it and one of these years i want to have like a whiteboard in my office and be like, these are the,

these are my goals for the year and I can change them, but I just want to see him. Like, I, I don't mean to sound so pessimistic. Like there's definitely things that, uh, that I did really well at last year that I was proud of that.

I had no plans of in January. I didn't even know we're coming, you know? Right. It's tough, but yeah, it's hard. I mean, you spoke at like 20,000 different conferences or meetups.

Yeah, 21,000 meetups. 21,000 in three. In three. Yeah, rather three. Yes. So, I mean, yeah, I'm sure that wasn't necessarily something that you had totally planned out. I don't think you had thought about talking about Jamstack 100 times. So, I mean, yeah, it's crazy how this stuff sneaks up on you.

But that's exciting that our audience is like, you know, getting after it. Yeah. Yeah. That's really awesome. I want to know, like, don't forget to,

if you leave a comment and let us know what you crushed or what you want to crush this year. Oh, I might win a book. Yeah, that's a good one. That's a, yeah.

So what is this? Um, Cody blocks.net slash episode one Oh eight. Yeah. Tell us, tell us what your goals were that you crushed. Yeah, that's awesome. You can tell us about the ones that you didn't crush too, if you really wanted to, but

we're trying to keep things, you know, upbeat, lively. No bumbies. This episode is sponsored by Datadog, a monitoring platform for cloud scale infrastructure and applications. Datadog provides dashboarding, alerting, application performance monitoring, and log management in one tightly integrated platform so you can get end-to-end visibility quickly. Visualize key metrics, set alerts to identify anomalies, and collaborate with your team to troubleshoot and fix issues fast. Try it yourself today by starting a free 14-day trial and also receive a free Datadog t-shirt when you create your first dashboard. Head to www.datadog.com slash codingblocks to see how Datadog can provide real-time visibility into your application. Again, that was www.datadog.com slash codingblocks to sign up today. All right. And so for today's survey, we ask,

do you discuss podcasts with your friends or coworkers? And your choices are, are you kidding? That's all we talk about. Or absolutely. They need all the help they can get. Or absolutely. They need all the help they can get. Or absolutely. I need all the help I can get. Or lastly,

no, it's my secret superpower. They can't know where all my tips come from. I look forward to this one. All right. On to the next section, prototypes and post-it notes. We kind of alluded to it before. Prototypes are the throwaway projects that are designed to test out an idea.

And they kind of hint at there being a single idea. I don't think there's a specific rule about that, but I think it's kind of um common maybe or at least implied uh and the kind of idea here is just to have a proof of concept if you've heard that term before and uh they have an example i really liked um where they were talking about kind of cars like if you're a car manufacturer and you are you know thinking about coming out with a new line then you might do some wind tunnel tests with like a mock car like you don't need to build a whole car with the engine and the power lock brakes or whatever i don't know much about cars uh i mean you might be just fine with like a small wood model right or a small clay model

or something that you can compare to other ones it's gonna be a lot cheaper and a lot faster to make yeah and so i thought that made a lot of sense. Yeah, and one of the cool things that they say here, and this is really the important part of it, is it provides the ability to correct at a reduced price because you're correcting early in the process. And you were here on the notion of the lean company, whatever, the lean startup book I mentioned earlier. They'll tell you to really hit hardly. Hit hardly. They'll tell you to basically go try and sell something before you even make it. So go, if you need

to be doing stuff in the background and manually typing, doing whatever, just make sure that your idea has wings before you invest any time in it. So I think this is another case where they were really much ahead of the game. So I guess that's where you see the people that the risk takers out there, they'll go and sell the idea of the game so i guess that's where you see like the people that you know the risk takers out

there that'll like go and sell you know the compute the idea of the computer before they've even built the computer and they're like okay we got an order for 20 000 we got to make this happen right yep you remember those things i look in back magazines these to talk about like you'd flip the back and be like hey it's in 25 cents and we'll send you a balloon with your name on it or you know something stupid. A lot of times I read later that those companies, they would basically refund the money if they didn't get enough. So it's kind of like early day Kickstarter. So I'd say like, hey, get the Golden Kazoo, whatever.

If they got 100 orders, then they'll go ahead and place the order to China or manufacturer or whatever. Get that stuff that's in it. And if they don't, if only two people end up trying to order that thing in a magazine, then, oh, well, sorry, here's your money back. And so nothing was really lost by doing that other than maybe some hurt feelings about their golden kazoos or balloons with names on it or whatever. But ultimately, the business owner didn't have to put anything out front and they were able to sell the idea as early as possible. And this is the same kind of idea here. You can prove that something is going to work. You can prototype something and see that people are happy with it. Then you can potentially save a lot of time if they're not. It doesn't work.

You nailed it, though, with the one example that you really glossed over super fast, which was that I didn't even think about while reading this, which was the Kickstarter idea. Oh, yeah. Yeah, sell it first. Yep. Although there's been lots of times I would see something in – you know websites do that thing where they're like, here's a little teaser. Enter your email address and I'll send you the free ePub or whatever on the thing. I hate those. But there's been plenty of times where I put in my email address and they're like, oh, yeah, this is super exciting. I love this.

And then it just never – you never hear from it again. Everyone would say, Impostor Handbook Season 2. Whatever happened with that? They kind of said, hey, if enough people show interest in it, we're going to do it. And it's been no good while. Has it not? I thought it launched. Did it not?

I don't know. It's busy. To the Googles. The Impostors. I really want it, so I hope so. All right. Well, while you're looking for that, the prototype is going to act as a model, something that you can use to analyze and expose your risk and validate your ideas cheap. So let's go back to this clay model car idea, right?

You didn't have to build a whole car to see how it's going to function in a wind tunnel, right? And you could even build that clay model down. It doesn't have to be a full-size scale, right? So you could build a smaller scale version of it just to see like, okay me validate like how does the how's the wind going to flow over this right and if you take those into water tanks there's some cool things that they could do there too you know it's smaller at smaller scales right have you ever seen what i'm talking about i have not where like you could put like different colors of water in it to see like how it flows over the, over the vehicle. Yep. Right.

So, you know, that's the idea here with the prototype. Yep. So, uh, I Googled imposter handbook season two and actually did come out. I don't know how I missed that. Like that.

I thought I'd be keeping an eye on it. We talked about it not too long ago. And so I don't know if I missed that email or what. I don't think I got the email either, but they were definitely supposed to send it out. I remember them sending out a bunch of emails before it launched. Yeah. But, yeah, interesting.

That's really cool. Do you want to know what the chapters are like? You save it for a future episode when we talk about it? Yeah, I'll save it for a future episode. All right. Go check out the website. Yeah. Monster's Handbook Season 2.

Check it out and tell them to come and watch it. That's right. So, yeah, the next thing was is the prototype acts as the model for something we can analyze and expose risk to validate the ideas for cheap, right? So the risk part was really the super interesting thing is what do you prototype? You prototype things that are risky because those are the things that you want to figure out earlier whether or not you want to continue forward with it or or scrap it and go with something else this is a great case for jam stack if you have an idea it's really lightweight you throw something the other the gasp doesn't have to be your company colors doesn't have to be your theme you can just grab like a starter that like looks all that looks alright. Throw some forms together.

I mean, that's silly. If we're talking about truly a prototype, a lot of times you can just use a UI tool like Balsamiq or UXPen or something to do the work. Why spit up a whole website for it? I think I'm more comfortable with messing with stuff and doing stuff

with HTML than I am with tools. I guess if i spent more time with them then probably be probably be better what's this jam stack you speak of let me tell you all right there's a talk 20 000 21 004 and four that's right yeah so the the other thing they said i've actually seen this done and it works rather well, is use post-it notes to depict a workflow, right? You get a board and you put some post-it notes up there. Why you got to do some digital drawings?

Just get some paper. Don't open a window on a breezy day. Yeah, yeah. It'll all go away. I've never done this with notes. I actually worked on a project where we used a, it was surprisingly effective to where we had swim lanes and there were, there were things that needed to be done. And it was just nice to be able to see it on a board when you walk by it.

Right. So you put the post-it notes in the different swim lanes to say, yeah, this has moved along and this hasn't, whatever. I mean, it's fine to see that stuff in jira and all that but every time you walk by it and see it there it's it's sort of like a a bit of a reminder like oh man i really need to get this thing moved over so yeah i mean yeah i've worked in environments where like that was how we you know you got your ticket from that it it reminded me like watching uh silicon valley yeah because they did the same thing, right? Rigby. Yeah. You know, now everybody's going to be like, wait, Rigby? What's Rigby? Yeah.

Richard is great, but yeah. You know, you would pull your ticket down off the board and that's what you would work on, right? And so it is like in your face, like what you were saying, right? It's nice. And so then the other thing that they described here too was just using a whiteboard to draw out storyboards, right? This is, you know, you're on this screen, then you click something, and this is what the next screen is going to look like, right? You can just sort of sketch it out. You wireframe it with real whiteboards and markers and stuff instead of, you know, going to some, going to some PowerPoint or whatever. I love the office environments where the walls are painted with the whiteboard paint. Yeah.

And you can just draw on every part of the wall. Up until you find that one area of the wall that wasn't painted and now is permanent. Oops. Yeah. Have you ever worked with someone that drew too much? Oh, yeah. It's like they would stop by the office, stop by your cube or whatever and they would like start talking

and they would reach for the pen and be like, let me show you. And you're like, no, because like every little box they're drawing, like whatever thing you were thinking on before you got interrupted, steps one step out of your head. And so I'd die in there and finish drawing. And you're like, well, great. Now I got this loaded up and it's going to take me 20 minutes to get back to work.

That's what I thought too, man. I thought he was going to talk about something inappropriate that was drawn or something. It wasn't like, hey man, you've got to erase that. Don't leave that on my board. It's like someone starts drawing and be like, hey, this is 20 minutes now this week you spent drawing already. You starts trying to be like, hey, this is 20 minutes now this week.

You spent drawing already. You're going to be out by Wednesday at this rate. You only get one hour per week. No, it drives me nuts. I don't know. Maybe I'm just a bum. I don't like getting interrupted. I don't think anyone does.

But there's something about getting interrupted and it being a long interruption, that makes it so much worse. So it's like when it's like full of details and full of stuff, it's just I feel it pushing everything else on my head out. And then you have to relearn what you were trying to do in the first place. Yeah. Yeah, it happens. Anyway. Cool. Don't be that person.

So you have some pro tips here. Yeah. Oh, this't be that person. So you have some pro tips here. Yeah. Oh, this is what I like. The more prototypical that your project looks, basically the worse it looks, the less likely it is to get shoved to production. This is something I learned a long time ago with working at a boutique website is if we would show the customer something that was closer to done, they expected it to be done like really fast. Even if it was just like photoshop stuff and they they saw the design the pictures they were like okay you know they just their expectations would get increased and so they would expect stuff to look exactly like the photoshop exactly

done tomorrow and it was also you know harder to change like hey can we move this thing over here and make it green it's like well yeah i guess like i cheated and it's not a layer and you know it's just took hard work so what we decided to do there was just do white screens for initial discovery. So it's really easy if you want to change something. You just move it over here and nobody's worried about what shade of green it is. Because we'd have meetings with clients. We'd have them in the office for three hours and one hour was just talking about shades of green. And it's just not productive.

That's something that can be done in an email or whatever. Yeah, that's a good point. Do you now have a favorite shade of green? I mean, let's get to the hard-hitting questions that matter. Hashtag 339999. Wait a minute. Yeah, 33 and then quad 9

is I think what he said. Yep. It's the cutting block screen from our logo. From one of our logos. What? No. That's like coding box screen from our logo, from one of our logos. What? No. That's like some teal color. Yeah, it's teal.

I don't know. I grabbed it once with the eyedropper and I memorized it. Oh, okay. I think I know which part you're talking about. I think it's like the coding box person's pants. Yeah, yeah, yeah. That's hilarious. Yeah. So if you can't give crazy details on the project and you can't get down to that level, then it's probably a prototype.

Maybe it's not a prototype you mean. Oh, if you can't give up on the details. If you're trying to be too detailed, then yes. Then it's probably not a prototype. And you shouldn't spend that much time on a prototype. It might be that you need to use the tracer bullets right that's yeah totally read that wrong and you got to recognize when things start going off the rails and start turning into production and and it's just you just got to recognize that they had a nice list of things to prototype so anything that carries risk.

So I like that, especially things that are going to take a long time. Architecture. Now, wait, what's not going to carry risk? Well, the bigger the risk, the more likely you should be to prototype it. So maybe if you're thinking about switching to a new JavaScript library, like that's a big decision. Maybe you should try prototyping one in this framework and one in that framework, just to kind of see like what's going to gel for your team better.

But if it's like, what font should we use on a website? Something that's easy to change, like we need to prototype that. That's the one you definitely want to prototype. I mean, I'll give, I'll give a,

a decent example is, you know, we had worked on a project where it was, you know, taking queries from a database versus something like a search index, right? What's the performance of it? And the thing is to really put stuff into like a search index from your relational database, there's all kinds of things you have to consider. But if you just want to test the performance, really what you need to do is just find a way to cram that data in there and set it up as close to apples to apples in terms of the data that's there and then run your performance test, right?

Just so that you can show that, hey, the performance over here was this and the performance over here was this. Without going and building all the tooling and all the setup to sync the data over and do all that crap right it just get it in there that's a good example of a prototype hey is this thing even worth exploring is it going to give us the benefits that we think it will yeah big difference between a one-time data dump and data syncing everything that needs to be synced forevermore and updating your application. Right. You know, and I asked the question, though, about what carries risk, though, but that's really going to depend on who the audience is

that's hearing that question being asked, right? Because you brought up fonts. Like, okay, nobody's going to be able to write a font, right? And I wasn't thinking of design-type things when I brought that up, but if you were to bring that up to like a marketing person or design specialist, like huge, that's absolutely going to be something like they might consider that a

risk because, you know, depending on the font, the size, you know, like your brand, the, the weight of the font,

right? Like, yeah. So, so, you know, and then that's where like, you know,

they have, might have tools where they could like a b something to see like well how well did it perform you know that that might be how how their prototype works but i was thinking more like you know the technical weeds of something yeah i was thinking uh it's easy to reverse because it's you know something i can easily change but if you're getting print materials made or potentially roll out the new font everybody hates it rebels and you know like the Olive Garden logo. Remember that?

Remember they changed the logo and everybody hated it? What? I didn't know about this. Oh, yeah. I don't know if they kept it or what. But, yeah, there's a big thing. Like, whatever company changes its logos now, there's like 80,000 people that hate it.

And Twitter is like raging for a day and they forget about it. Man, I'm not going to go read all this while while we're doing this because yeah so originally the olive garden logo it looks pretty crusty like it looks like it was you know it was just kind of ancient and they changed it but people were like oh it looks like it was done with crayons it looks terrible i remember now they've changed it again so it's kind of a hybrid yeah i remember the original i guess i don't remember either because i'm like well i can't tell which one of these is the new one and which one of these is the old one. All that really matters is that they still have their breadsticks and that they have their.

Oh, wait a minute. Here we go. I found. Yeah, I found. I found a link that has them organized by year. So, yeah, from 82 to 99, they all looked about the same. But then the one they show, I guess I'm assuming that they

changed it in 2014. So maybe it was from 82 to 2013, they were pretty much the same. Yeah, 2013's about, no. 2014's when they went really different. Yeah. Drastically different. Yeah, and that's the one that people hate everything

else looks like i guess another way to say this is like the older ones all look handwritten and this one definitely looks like a font that you would see on like the oprah channel or something and we need to have this in the show notes because i want to look at it yeah because it definitely looks like it definitely looks like the like the o reminds me of like an Oprah kind of thing. Yes. You must put that in the show notes. All right. Because like the internet rebelled and I think they changed it.

That's hilarious. I didn't know about this. All right. So back to what is a prototype. So we also said architecture. Or did we say architecture? We did, right? So you might want a prototype like we were talking about, a search engine.

That might be one that, hey, does this work? Does it not? A graph database. Like a lot of the newer technology type things, like, I mean, there were a lot of people that just left relational database world and went to document database worlds, right? Maybe that's something you want to prototype. You want to find out, is this going to do what we thought it was going to do? And does it answer my problems? Does it introduce more problems?

That's kind of a good way to get to it. New functionality. I don't know. Maybe you want to take on a new payment type or something, right? Like finding out how painful is this thing going to be. PayPal can be painful. I think it's going to depend on like how big is that functionality though. Totally.

You know, I mean, if it's bringing on a new payment processor like a paypal or something like that i don't even know then you know all gardens are rolling out those things for that the tablets on the table you could pay and it's like blinking in your face oh yeah yeah they probably should have prototyped that in one store before they rolled it out to all of them because i hate that yeah i'm not a big fan of those and i've always got to tell my kids to get their hands off of it because that's that's basically what happens everybody wants to reach over and start playing games and i'm like no man but i think the ziosk yeah paper games those things yeah i always look at them and i'm like man why didn't i think of that yeah ruth's chris did it for a while too

they got rid of them like a even a couple months after we first saw him. I have a lot of feelings about Olive Garden. I think he goes to fancy eating more often than I do. I think so, too. You said Ruth's Chris. I'm like, what? No. I like eating.

That I do as well. So structure or contents of external data. That's like mocking sort of, right? But that can totally be a prototype. I think you even said faking data earlier. Yep. Third party tools or components. Yeah, for sure.

But again, we're like prototyping things that carry risk or that haven't tried before. Like a structure or contents We're prototyping things that carry risk or that haven't tried before. A structure or contents of external data, I would mock. I could see maybe – but I guess that was a term that they didn't have, that wasn't used for this kind of thing back then. So maybe I'll give them a pass then.

Maybe the revision calls that something different. Possibly. Yeah. I think this is more just hey, we don't want to spend a bunch of time trying to get something from Amazon's API. Let's just create some fake data so that we can get it in there. That'd be my guess is what they're getting at. So yeah, very much mocking data. But the example you just gave is the prototyping of the third-party tools and components. So it's like where – you see what I'm saying? What does it mean to prototype the structure or contents of external data where you are not prototyping third-party tools or components? Well, I think they're two separate things, right?

I mean one is you know what that external data looks like, right? Like, like, if you were to go look up the API endpoint for Amazon, like, and I just went through this recently. So I know how painful it can sort of be. But you know what the data looks like, because they have samples of data out there. So you can just mock up a bunch of that stuff and say, hey, this is what it's going to look like when I get it. So I can code around it. Right. So that's easy enough to do, but that's different from saying, okay, now I want to try Amazon versus Walmart. Right. So, so now you've got two components you want to try out. You're not going to write any production ready code, but you are going to try and get something in place, just see what they are. So I think there is a difference between, yeah, I want to use third-party components because I want to have the shopping experience on my site versus I know what the data looks like in what I'm going to use. I just want to mock that in place. So I think it's two separate use cases. They could go hand in hand a lot, I think, but.

You know, I think third-party tools or components, I think about like point of sale devices or hand scanners or components is like Kendo UI or, you know, some clock widget or something. Yeah, totally could be react or bootstrap versus material, you know, anything like that. You know, you're not going to try and do it out perfect, but you just want to see how it looks. So I don't know. Let's see. Performance issues. This one was kind of interesting, right? I mean, this goes back to your search example that you just gave.

Search was one. They had also said if you're trying to do something language-wise, like one of the things that they had mentioned in the book that I thought was pretty interesting is, you know, a lot of times you might use a more scripty language, something that's a little bit more high level if you're trying to throw together a prototype, because it's faster for you to just glue things together. Like JavaScript is one of those, right? Like I think one of the reasons it's so popular is it's so easy to just do stuff in. But they said, if you're actually trying to prototype for performance, then you probably need to use the language that you're more looking at using for that purpose, right?

Because how are you going to prototype performance if you're not using something closer to what the end goal is going to be? So I thought that was pretty interesting, and it makes sense. And then the last one was user interface, user experience. So that's the, I think the kind of the most obvious case of prototyping to me. Yep. That's the easiest one to at least put in my mind because there's so many tools for it out there.

Ooh, Hey, we're at another tip, tip 16 prototype to learn. And that's just kind of the whole gist of this was basically we're using prototypes to figure out the answer to one or more questions. And so that's the point. When do you prototype when you need to figure something out? Prototype to learn. This episode is sponsored by Clubhouse. Clubhouse is the first project management platform for software development that brings everyone together so that teams can focus on what matters, creating products their customers love. While designed to be developer-first,

the UI is simple and intuitive enough for all teams to enjoy using. Clubhouse is truly built for developers by developers. And you can tell because they've sprinkled Git tips throughout the UI, and they even made a point to highlight open-source projects that integrate with them. In fact, today I even noticed a Ghostbuster reference on one of the forms. And they're constantly adding new features. For example, they just recently added search operator auto-completion. So no more memorizing the spelling or format of operators in Clubhouse. In as little as one keystroke, auto-populated operators make surfacing work by other users or performing date-related searches

or more much faster and easier. With a simple API and robust set of integrations, Clubhouse also seamlessly integrates with the tools you already use every day like Slack or GitHub. For example, getting out of your way so you can focus on delivering quality software on time. Sign up for two free months of Clubhouse by visiting clubhouse.io slash codingblocks. Again, that was clubhouse.io slash codingblocks, and you'll get two free months and see why companies like Elastic, Full Story,

and LaunchDarkly love Clubhouse. All right, so another section I really liked was what can you ignore? So the first one they've got listed is correctness, which I appreciate. I recommend using dummy data. And I even like having like really dummy data, like lorem ipsum type stuff, like make it really obvious that this is not correct. And I've noticed sometimes like if data looks a little too real, people will get confused. I'm like, hey, why is that a five?

It should be a four because if you add, you're like, oh, it's fake. Just fake. It's just fake. I've sat in so many meetings like that where people start nitpicking numbers and it's like, whoa, whoa, whoa. We said at the top, this is not real. Hey, but that's got to match this over here.

Yes. Completeness too. I've worked at places that we did a, we did a lot of prototyping back then. We would do things like leave the things that weren't done, the gray scale. Just so they were still there. They still have the shape.

They also let people know that you can't click on that. So the users weren't thinking something was broken because it was obviously not meant to be working yet. And I mentioned thinking or disabled components. So there's robustness, like leaving out the validation. I love that. Yeah. I even put a note here on the side of this.

So this reminds me of something that we did a while back. It's been a few years ago where we had been working on a feature, and this was totally not a prototype, but it was meant to be production code, but it wasn't ready. Right? Like we had totally prototype the beginning of it and it was going into a demo because why wouldn't you demo the thing that's not done? And, and it was said, do not do this. If you do this, it will break.

And that's one of the things about prototypes is you, you totally set it up for go down the happy path, right? Like what we're trying to show you is what's going to happen when you go from A to Z this way. So if you click on something that's not in that A to Z path, it's totally going to break, right? And that's on you. We told you.

We warned you. Yeah, I like that. Yeah, like make sure to only check out with Visa 4111111. Exactly. Yeah, like, oh, you didn't type enough ones the whole thing crashed yeah start over style so slacking on documentation and comments and what I thought was interesting

when they said style you can ignore style they were talking specifically about coding style not like you know UI style I was surprised to hear that I mean when you're talking about like documentation like yeah of course I don't expect documentation for a prototype. Comments, you know, okay, fine.

We're not too crazy about comments anyway. But, like, the coding style, like, uh-uh, no. That needs to still be formatted to me. Like, it still needs to be good code, but I guess you don't have to worry about dependency injection and all that stuff. Yeah, patterns. I think it's really patterns and good practices that you just kind of throw out the window, right? Yeah, just the word style threw me off. It was like style, like TAS versus Spaces?

No. You can never let that go. You let that demon in and it's never going back out. So they also mentioned the higher level tool you use, the better. It saves you time. So if you can use something like a prototyping tool that's great what was funny is the book mentions for their high level tools for prototyping tools like tcl or tk for ui visual basic power builder delphi like those are not considered high level tools anymore no they are not what is tcl tk though i don't think i'd heard of that tickle tk

isn't it the like the linux ui library oh i don't know that was the only one i I'd heard of that. Tickle2k? Isn't it like the Linux UI library? Oh, I don't know. That was the only one I hadn't heard of. It is ironic, though, that they called out Delphi because I think all three of us were kind of like Delphi. And then we did that YouTube video with the guy who walked us through it. We were like, that's amazing what you just showed us. Yeah, RAD Studio was really cool. And Tickle is nothing like I thought it was. I don't know anything about Tickle2K.

Okay, cool. So none of us know. Awesome. Yeah. Before our time. But I was curious, though, what do you think about tools that we can use now? Like if you had to do a prototype today, what would be the thing that you reach for? Well, you're stealing my tip of the week, Thunder.

I don't know that I want to talk about this. Okay, well, Thunder. I don't want to talk about this. Okay. Well, crap. Okay. Well, we have recommendations, but we're not going to tell you, so move along. Well, we can talk about the ones you have right there because I didn't do any of those. Okay. UXPen definitely is just a site where you can do some nice mockups,

and you can do linking between things. You can kind of click, and it'll take you to that. You can do that outside of HTML. You just do it in their UI, which is really nice. They have a lot of cool widgets and stuff that are built in. So you can kind of get things that look a lot like your site just with the built-in stuff. And then you can add images and stuff too. So it's just really nice.

Docker Compose is one that I specifically wanted to mention. Because Docker Compose isn't always – I saw that. I'm removing stuff from my notes. Docker Compose isn't always appropriate for production because it kind of is only really designed to work for like one single server. And that's not always applicable in the real world, but it's great for developers because I can spin up like say Elastic Stack, which will spin up like four or five services all run locally. And so it's something I can use to quickly prototype.

And I don't have to worry about Java versions or running things or Kubernetes or how to scale, how to do rolling upgrades or how to maintain and upgrade my product, all that stuff. I can just do a quick like Docker close up and start working, prove the concept, move on. Balsamic is the last one that I've got written here. It's just a wireframing tool that I used like eons ago.

You know what? The Docker compose one, that's really good. I've got written here. It's just a wireframing tool I used eons ago. You know what? The Docker Compose one, that's really good. I hadn't thought about it. But that is a perfect prototyping one. Oh, you want Postgres running? Docker run Postgres, right? You can't do anything much easier than that. Yeah, it's silly.

It's like, I don't know how well Mongo would work. Like, I just spin it up. I don't know. But the real, but the real benefit though, that he's talking about isn't necessarily like a single service. It's the whole stack, a whole stack of services. And you're like, I don't care how many different things you're going to install this on later. Right.

For right now, you hear like, let's pretend that these all exist on different services or if you wanted them to exist on different services, or you want to scale them out to, you know, 20 per, I don't care. Right. For right now, here's what this looks like.

I want this running. Yeah. So I actually, I'd say Docker and Docker compose both of those just amazing prototyping tools, just killer stuff. Prototyping architecture. I don't know that I've ever done this.

We mentioned the post-it notes so you can kind of move stuff around without having to change any code. Do you have any experience with prototyping architecture? Kind of like what we talked about. Things like Elastic. Things like, you know, tried some Kafka stuff and all that. The hard thing is, I think the only reason I could even call it a prototype is because some of the code that you write against is complete trash, right? Like it's literally just to set up the thing to see, Hey, does this do what I thought it was going to do? And then you just completely

trash all that. And you're like, Hey, it did cool. Let's do it right. Or no, it totally didn't either. We're terrible with this tool or, or we just don't know what we're doing. And they called out a couple of questions to keep in mind when you're doing this specifically for architecture, like asking yourself whether the responsibilities are well-defined and appropriate. So that was cool.

It's like, does this go in this service or does this go in that service? I think that's good. Are the collaborations well-defined, how things talk to each other? I still have a hard time imagining that with Post-it notes, but I guess you draw the lines between them.

Let's finish through this, and I got something I think I can summarize this. Is coupling minimized? That's pretty cool. We can see that pretty well. Can you identify sources of duplication? I guess so.

You could say like this, something's happening over here and it's got to happen over here too. That's the smell. Last one is our, no, two more. Are interface definitions and constraints acceptable? Yeah.

All right. And does every module have an access path that it needs? When it needs it. Yeah. All right. And does every module have an access path that it needs when it needs it? Yeah. I mean, those are all good questions, I is how I thought of this, was that let's say, for example, let's go back to our consulting, put your consulting hat back on, and pretend you work for a company where, I don't know if you've ever worked in a company where this particular role existed, but you are a solution architect. Have you ever heard of that title? Okay. So you don't necessarily have to write any code. Okay. But the point is, is that the customer comes to you and they're like, hey, these are all the features that I want in my thing to do.

Right. And then you go and scour like all the different vendors that might provide some of those pieces of functionality. And then you start puzzling them, you know, piecing those puzzles together or putting those pieces together to create like the final puzzle is like, okay, to solve all your requirements, here's what I pieced together. Right. And I mean, you could, you could even think of this in a more scale down version. Like, let's just talk about like, if you were building a new computer, well, what, how do you want to use that computer? Right. And then you can be like, okay, well, based off of how you're going to use

that computer, then let me research this, but I think this particular video card is going to serve your needs the best. Then this motherboard based on what you said. You know what I'm saying? You didn't write any code, but you're just kind of whiteboarding it out. Okay, this is going to go with that. That's going to plug in here. Solution architect. I think that makes perfect sense. but you're just kind of like whiteboarding it out. Like, okay, this is going to go with that. That's going to plug in here, right? Solution architect. I think that makes perfect sense. And heck, even Joe, you and I did this recently with the Elastic and the Kafka things, right?

Like, you know, with Elasticsearch, you have hot nodes, you have cold nodes, you have things like that, and they all have different requirements, right? So, you know, my thing that needs to have search readily available, those need to be running on SSDs that are attached to the hardware. So that's a big deal. Um, my, my archive data, that's not getting access that much that can be on spinning this, right? Like that's cheaper storage. So that's, that's kind

of a way where you could do it, right? Like here's my well-defined things. These are what it needs. And this is what I need to put it together. Right. So I can totally see how, how this could all sort of come into play when you're going through and post-it notes would happen, right? Like you could, you could do it in Excel or you could do it with post-it notes or whatever, but sometimes it is, believe it or not, easier and faster to write something on a piece of paper and stick it somewhere than it is to redesign it in a PowerPoint or a Visio or something. It is. But I know that we've all done this where we've created like a checklist in Excel

where you have like multiple columns. You're like, okay, here's all the things. And does it do this? And does it do that one? Like here's five columns of things that I need to have solved. And here's 10 possibilities know, 10 possibilities, which one of these 10 is giving me the best fit across the metrics. Right. Yep.

Yeah, I can see that with that cloud stuff. It's officially like you take the AWS FF and you plug in the AWS C2 and you take the AWS EE and you like put those all together and you put them in front of the AWS LB2 and then the FF4 or whatever. Don't make me break out the

AWS icon. The initials aren't much better either. No, they're not. Is EB elastic beanstalk or is it elastic block storage or whatever? That's EBS. Oh,

my bad. Yes. So you knew it was elastic. Yes. Yeah. So next up is how not to prototype. So communicate the intentions of your project. You don't want your prototype turning into release code.

This has happened to everybody. If you've programmed for more than a year or two, this has happened to you. Oh, yeah. You did something and they're like, oh, yeah, make it so. That's done, right? You're delivering tomorrow. It goes exactly to Joe's point there before about like how pretty it is. Make it up.

Like the prettier it is, then they're going to be like,, Oh, well that thing's already pretty close to being done. Let's just release it like it is. Well, hold on. It's really not. And they're like, no, it'll be fine.

We don't even know what, how many users we're going to have yet. No, just go ahead and release it like it is. Trust me. It's going to be fine, man. This is so hard to like,

I've actually done projects in the past or even things that I was trying to do on the side to help a project along to where I wouldn't show anybody the, how it could be like, for instance, the elastic search type thing, right? Like a search index being that much faster because I didn't want it to be to where, oh man, that's awesome. Plug it in and be like, no, no, no, dude. No, no. I totally just hacked this into that thing, right? Like I have nothing that we can ship right now. And so I totally wouldn't even show anything to anybody because I didn't want that to become a we're releasing that in two weeks type thing. Yeah.

Then there's also the other side, though, where you show it too soon and they're like, oh, well, never mind then. I'm not interested. Right. Oh, that's not cool. Yeah. Yeah. Either way, you're playing games. You're either boiling frogs or making stone soup.

Oh, that's awesome. That's going back a couple chapters. I thought you were going to say something about it being a Game of Thrones, but okay. Now, who won anyway? Stop. Sorry, that's my joke. People will stop listening to the podcast if we drop information like that. I would.

Thanos won. Thanos won. So, yeah, the next one is if you do think that you're going to end up in a situation to where somebody's going to look at it and be like hey this is ready then maybe you need to advocate for that that agile approach or the tracer bullet approach to where you're actually truly writing good code yeah and the analogy they gave here it's like uh they're going back to the kind of the car model we talked about a little bit earlier i was like would you take a balsa wood and glue car that you made out into traffic? I love that. I absolutely loved it when they wrote that.

What if your answer is yes? You crazy? Those people, I'm sure. You crazy. You never made a soapbox derby car? Not that you're going to take out into traffic. Yeah. I mean, what are we calling traffic here?

The neighborhood street? Does that count as traffic? 275, 275 intersection. Oh, come on. Yeah. The danger zone. The danger zone. All right, Kenny.

Hey, by the way, there is no 275. There is a 275, but that's not an intersection. Wait, what? Do you not know the rules of roads? Oh, man. Do you guys not? I know like east and west and north and south. Okay.

So, yeah, there's that. But if it's a three-number digit and it's an interstate, if the first number is even, it's a loop. If the first digit is odd, it's a road that goes straight to a city, a destination. It doesn't loop back around. So, like 175, I think, goes to Columbus. 575? Yeah, 575 loops around. Yeah, it goes up to I don't know where.

Yeah, it truly goes nowhere. But yeah, no. So anything with the odd number is a destination. Even numbers a loop. What about 400 there? That's not an interstate. That's just a highway. That's a destination. Even numbers, a loop or about 400 there. That's not an interstate. That's, that's just a highway.

That's a highway. So I'm looking at 75 and two 75 here and two 75. It's a loop. It goes straight down through Tampa and then hooks back up with 75 in Rubonia. No, no, no, no.

Two 75 is a loop around Tampa, right? Uh, I mean, you mean like a one side loop? It's a loop. It's like two 85 is a loop around Atlanta, right? Well,, it's a one-sided loop. It's a loop. It's like 285 is a loop around Atlanta, right?

Well, there's a difference between a loop and a bypass. Like 475 is a bypass. Wow, we are way off topic. 475 is a bypass. It is. That's four letters with an even. It is. Yeah, and this is 235.

I'm sorry. And then 675 is also just a bypass. So maybe it's something that goes around, but it doesn't end in a destination is basically what it boils down to. Oh, that's Rubonia. Like I think 175 ends in Columbus. God, we're off the rails here. Anyway. Where are we ever going? Now I've got to find that because it's been a long time since I took those.

Well, while you're finding that, let's continue talking about how to not use our prototypes. They can save a lot of property. They can properly save you a lot of money and time by identifying problems early in the process.

When used properly. I want to make that first part clear. Also property. Maybe. See, you keep saying that. I'm getting goofy. This is not a challenge. It's been up too late.

It's 10 o'clock at night. Time to go to bed. Time warp. So this section had a challenge. Tracer bullets did not have a challenge. It was basically start firing and figure it out. This one does. It says marketing wants to brainstorm a few web designs, and they include a clickable image map, which is already like ha, ha, ha.

You have 15 minutes. What tool would you use to whip together a prototype? God, an image map. Are those even used at all anymore? I know. Yeah. It's definitely not accessibility safe. Was it fireworks used to be the one back when this was there?

Yeah. They would make it for you so you could just draw rather than having to pick out the points yourself. That was huge. Yeah. Fireworks would have been the one back when this was when this was written so that's a fun one yeah so i mean what is your go-to is that is still cheating or like do you have a go-to visual tool i have one in my tips all right well paint you try to force this on me man i do like photoshop. It's my go-to. I only use like 2% of its capabilities. So basically just the layers by use all the time for stuff like this.

Yeah. I remember a lot of people back in the day would do it because it had the slice feature and all that stuff in it to where you could set them up back in the day, man. We're talking about still, do they still have the slice feature? I don't,

I, I don't ever look for that. I mean, it's not a feature that i use but i mean so i can't answer you yes or no on that but i would have to assume that they wouldn't have gotten rid of a feature yeah maybe like photoshop was one of those dumping grounds of features it was yeah but it feels like and maybe it's just my use case nowadays it feels like it's geared way more towards photographers and designers than it was for web design type stuff. I think, yeah, I don't know.

Well, I mean, we are talking about a tool that was made for movies. Photoshop was? Yeah. Do I know this? I didn't know that. Did you know this, Joe? No. Okay.

So here's your little bit of historical trivia then. Photoshop, it was originally made to make the movie Abyss. The Abyss. Do you remember that movie? I do. The Abyss. It was a good movie. Do you remember the scene where the water monster starts snaking its way through the hallways,

and then they close the door on it, and it splashes down? I do remember that, yeah. Photoshop exists because of that scene. Really? I think it was like two brothers they were making the movie and they started it that's amazing wow that's cool i had no idea how photoshop changes the way we work that's amazing stuff all right but you know i was thinking as far as this challenge goes like nowadays depending on your tooling if you know

if you've got a a mature marketing department and they can just be like, well, why don't we just AB test it? So that was kind of cool to think like, that's how different things have gone now. Like, you know, what,

like what picture you want to put on your website? Like that's a two second change, you know, it's not something, but back then, 1998, like that would be something you have a meeting about because it would be expensive change.

It would take a deploy and somebody to copy that thing up via FTP. And so if people didn't like the image or it was too big or it didn't convert, there would be a long lag time on that. So it was difficult to tell. Is it just me, though? Because I saw this. I don't know. I had a difference of opinion when I got to this example because I'm like, well, I can't even tell you the last time something like that was presented to me. Like, it's just because the tools are so much easier, I guess now, maybe there's just so much more of them that somebody else, some other designer has already like tried that already.

And they're like, hey, this is what we've decided on. And this is what we want. Right. Yeah. It's like, let's just Google what our competitor does. That's probably more accurate yeah done and done that's amazing every designer it's like yes that's that's true yeah all right so all right well with that uh in the resources we like section we're definitely going to have a link to this book, of course. And with that, we head into Alan's favorite portion of the show.

And maybe he will finally tell us his tools for mocking these UIs. It's the tip of the week. Yeah, come on. All right. Your turn, Joe. Hang on. I'm photoshopping this picture of 275 and 75 in tampa man i actually found a wikipedia there's a route number there's a wikipedia page that is super long dedicated to this so it's way more nuanced than what i had said

so tell that you can't talk about you can't talk about nuance to florida man oh that's amazing oh i'm gonna put this in the resources we like all right awesome because that's really what i was doing instead of uh podcasting sorry uh so actually um are you familiar with are you guys familiar with the notion of Zen mode? Yes. Websites and IDEs now have Zen mode. I didn't know websites did. Yeah, dev too.

If you hit zero on your keyboard, it will hide the navigation. It'll hide some other features. And it just gives you the stuff that you're reading, like the main story. Everything else goes away. I did not know that was a website thing. That's really cool. Yep, so I'm seeing that more and more on websites. This is the first website that I saw that on.

It was pretty cool. So if you go into, like, one of the stories and hit zero, the header goes by, all the likes, just basically boils it down to text, which I think is really nice. It's nice to get rid of that stuff. And it's nice to have the option. But did you know Visual Studio has the same – visual studio code has the same feature if you do control shift p that brings up your little command window there if you're on a mac i think it's like the the funky circle thing p it's command shift p yeah okay yeah no you're good uh if you do that and then just press command on our windows control

i do control your question there because he was talking about command yeah i'm all confused it's 10 10 o'clock night hey visual studio code has zen mode and so if you do that it like hides all the other windows and just gives you like the one main pane there kind of showing up it's kind of neat so it's kind of nice Like I could see doing that for like a presentation or something like in the future, if I'm presenting on my computer, I'm doing some live coding. Like I don't have to go close all those little windows and terminals and all

that stuff. I can just do control shift P start typing Zen and boom, hide all that stuff. And now you're just focused on my crappy code. Yeah. I will say in visual studio code, it's more of a thing, right?

Like when you do that, stuff goes away. And you kind of fill in the screen. On dev.to, it just gets rid of the top. Like it doesn't make anything bigger. Well, if you go into the stories. Oh, really? Yeah, go to an article. Dev.to.

Okay, so on the main page, it didn't really do much. Let me go into an article. I'm concerned with the move that FreeCodeCamp just pulled by leaving medium. Let's see what this does. Yeah, that was a good read. Juicy. Oh, but it doesn't make the article any bigger. It just gets rid of all the stuff around it.

Yeah. Okay. Now, you said Control-Command-P. Command-Shift-P. Oh, Command-Shift-P. Yeah. That brings up the, what do they call that? The command palette, I think.

Yeah. And just toggle. There can be all sorts of cool stuff in there. Toggles then. Yeah. Oh, so it goes full screen. Yeah. Okay.

Yeah, it does more. It does more than Dev.2. Yeah, it's actually really useful on an IDE. Not that the Dev.2 wasn't useful. It just didn't do as much for me. Maybe on a mobile it would probably feel better. I don't know, man. I could see that. I could see it on dev.to

becoming super... Do you ever find yourself... You'll read one article and then you'll see another one and you're like, oh, I kind of can't wait to read that one now. Then you're like, you know what? I think I've already got the gist of this one.

Let me go ahead and see this other article. Oh, yeah. I could see being focused in. You're basically putting blinders on it, right? That's really what you're doing. Yeah, you're getting rid of all the stuff around it. All right. The only thing I don't like about on Dev 2 is if you do Control-Plus and Control-Minus a lot, which I do,

I'm used to hitting Control- control zero to get it back. Well, they capture the zero now and it doesn't do that anymore. That kind of stinks. Yeah. Yeah. All right. So the one that you've tried to force me into the entire show is this is a design prototyping product and it's kind of interesting. It's called XD and it's free of interesting it's called xd and it's free which

most things from adobe are not so that in and of itself is already interesting and the cool part about this one is you've got things where you have um responsive resizing panels grids repeating animations all that kind of stuff the kind of things that you would expect in a prototyping thing. But the part that I thought that was even cooler was that it's interactive. So it's collaborative. You can, you know, whether your team needs to pitch an idea or whatever, then you can get on there and you can collaborate with people on designs. And that's pretty neat to me. Anyways, I think that's, that's pretty useful. So that one was cool. And then one of our old sponsors, they had Indigo.

You remember which one this was? Yeah, I was actually just looking at Indigo. I used it a little bit. It was actually really nice because you could share easily. Yeah, so I'll have a link to that one as well. So that was from Infragistics. That might have been our first sponsor. I think it was, honestly. So, yeah, those are the two tools that I was going to call out that kind of go along with the show.

Well, now you've got me curious. So I'm going back here and digging up. Which was our first sponsor. I believe it was Infragistics. It's been a minute. We're at episode 108. So. In the meantime, I'm going to be looking up some highways here.

And you are right. It was. Infragistics. All right. Very cool. All right. So Infragistics. It was. Very cool. So, Outlaw, what's yours? Okay, so I couldn't remember if this

one, I was pretty certain Joe already mentioned this one in a past episode, but I couldn't find it in there, so I thought, well, okay, fine. It deserves a mention even a second time, even if we already did say it once. But I couldn't find where we had mentioned it before.

But if you are building a new PC, PCPartPicker.com is your friend. One of the cool things about this thing is as you're building it, right, it will shop all of the sites for you to find, hey, here's the cheapest place where you can buy this. So you're like, okay, I want to get a new machine. I'm going to build a new rig. I want to build a core i9 rig, right? You pick which one you want. Boom, it'll say like, oh, hey, Amazon has it the cheapest or Newegg has it the cheapest

or whatever, right? You can go through all your parts. Plus you get a link that you can share to be like, Hey, look here, you know, if you needed to share that with anyone, like here it is. Plus it, it, it's stateful. So like, if you leave it and go away, it'll come when you, next time you come back to it, it still has your list there and it'll estimate your wattage as you come back to it it still has your list there and it'll estimate your wattage as you're adding things along so that you can you know see if you're properly sizing your power supply to match what you're getting in there and you can see builds that other people have done to see like oh well do i want that particular case? What does it look like? What if I do get that case, but I want a water cool?

How does that, is there enough room for everything, for the radiator and all that? Like, I don't know, right? Like, you can see it's great. I'm telling you, like, the next time you need to build a computer, if you haven't already used it before, PCPartPicker.com. And it shows you the part price history as well at the bottom oh right yes yes yeah i totally forgot to mention that part too but yeah you

can actually see like are you on a downward swing for like what the for that particular part you know that you you want to get right um like that core i9 that I mentioned, right? Like, are you buying it, you know, is this a bad time to buy it? Right. It's, you know, abnormally high. Okay. And then since I think Joe earlier mentioned the Lorem Ipsum text so to go along with this a while back from our slack miguel shared with us lorem pixum so pixum.photos is the url and there it's like lorem ipsum but for photos that's so cool so you can just find like you know good photos of whatever size you need right there.

I've never heard of this. That's amazing. Right? Isn't it awesome? Is it as cool as I think it is? Yeah, man. It totally is. Of course it is. Do you doubt Miguel? I just assumed it would be

cropping stuff weird, but it's actually really nice images that you just go get. Yeah. You can do grayscale or blur. Yeah. Yeah. Wow. Yeah.

That's really nice, Miguel. Yep. So that's it for this episode, talking about the Pragmatic Programmer, Tracer Bullets, and Prototyping. And for anyone keeping up, then I should have really called it the programmatic programmer. Your tips, use tracer bullets to find the target. And the 16th tip, prototype to learn. All right. With that, subscribe to us on iTunes, Spotify, Stitcher, and more using your favorite

podcast app. And also, as Alan mentioned earlier, be sure to leave us a review. You can find some helpful links there by visiting www.codingblocks.net slash review. Yeah, and while you're up there, also make sure you check out our show notes, examples, discussions, and more. Oh, and hey, send your feedback, questions questions and rants to slack because i just found out that their soft cap on membership has been upped uh as of a while ago so we're no longer afraid of busting the limit so you should come join the the coders best environment and best slack channel for coding nice and you can also follow us on twitter if you want at coding box way to sell twitter if you want way to sell it

if you want