Coding Blocks - The Pragmatic Programmer – How to Estimate

Episode Date: June 24, 2019

Joe is distracted by all of the announcements from E3, Allen is on the run from the Feebs, and Michael counts debugging as coding. All this and more as we continue discussing The Pragmatic Programmer.

You're listening to Coding Blocks, episode 109. Subscribe to us and leave us a review on iTunes, Stitcher, and more using your favorite podcast app. And get yourself to CodingBlocks.net where you can find shows, examples, discussion, and other stuff. Send your feedback, 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.

With that, I'm Alan Underwood. I'm Joe Ziggity-Zack. And I'm Michael Outlaw. And Joe Ziggity-Zack, I gotta know, was that supposed to be like a Parks and Recreation reference about get yourself? Because it almost sounded like treat yourself.

Treat yourself, yep. I love treat yourself. I love Parks and Rec, but no, I had a nap before tonight's show. So man, I am on fire. I have not seen it. I love treat yourself. I love Parks and Rec, but no, I had a nap before tonight's show. Oh, man. I am on fire. I have not seen Parks and Recreation yet. Oh, get on it. Yeah. This episode is sponsored by Discover.Bot, the only community for bot creators, and Datadog,

the monitoring platform for cloud-scale infrastructure and applications applications and Clubhouse, the developer friendly project management platform. All right. So continuing on in this episode, we're going to be talking about the DSLs and estimates for the pragmatic programmer. But before we do that, as we always like to do, we like to first thank those that have taken the time out of their busy days to leave us some reviews. Yeah, I got some here to read from iTunes. So thank you veryologic. And on Stitcher, we have Plodgen, Dirty Matlab, Grand

Pappy, Plodgen12 and Damio Dias. And I might have said one twice. You might have. Although his was pretty funny. It took him 107 episodes, then it took him 108 episodes.

Yeah. Yeah, that was good. If I could submit gone wrong, it's awesome. Yep, and also a shout out to Javier because I think we all spent time chatting with him when we were down in Orlando at Orlando Code Camp. So thank you very much for taking the time to leave us a review.

Super appreciated to all of you who did so. Yeah, it's a big pain in the butt to delete the review so we appreciate it uh i know it's not the easiest or funnest thing to do and like you're not even you know really listening all the time on a computer with like a keyboard like you listen on your phone whatever so i know it's uh something you got to remember to do but really appreciate you taking that time out um and we appreciate so much that we're doing another book giveaway. So leave a comment on this episode at codingbox.net slash episode 109 for a chance to win. Yep. And yeah.

And the last thing is, assuming this launches the day that we think it's going to launch, get yourself out to my talk tonight. Treat yourself. Treat yourself. So I'll be talking about Kafka streams and that is at the Atlanta intelligent devices meetup at the Microsoft campus. So June 24th at, I think it's 6 PM or something. So yeah,

come on out. Well, you should know I should, I gotta be there. It's only like a week. Yeah. Yeah. I gotta be there.

So maybe donuts yeah i probably need to invest in some donuts yeah yeah be wise yes all right so let's talk about digital subscriber lines have you guys ever built uh wrote a digital subscriber line a domain specific language when you said this digital subscriber line my brain literally just turned off i was like well when you said when you said dsls i was like oh yeah dsl line oh yeah old school yeah so we've read several books now that have mentioned writing one and suggested writing one and uh reading the descriptions online and stuff some people call doing specific languages

you know like okay maybe sort of kinda but i still don't really feel like i've ever really sat down and designed like a language that was intended for someone else to to write that would map to something some code that i would run i agree with you i mean i i'm in the same boat uh i don't feel like i have either we we've referenced it in Robert L. Reed's How to Be a Programmer series. I think it was in the section of how to be an advanced programmer. That's when you start writing your own language, which I guess I'm not an advanced programmer because I've never – I don't feel like I've ever done that. We've covered it in Domain Driven Design, and now we're covering it here in the pragmatic programmer yeah yeah i'm not in love with the idea of it but i mean so here's what got me thinking

maybe i kind of have maybe sort of so elastic search has a nest library c-sharp library for interacting with its api they specifically call it a domain specific language because it has a nest library c-sharp library for interacting with its api they specifically call it a domain specific language because it has a one-to-one mapping with the kinds of things that you can generate in their json so that means that there are little functions that you can kind of string together kind of like a fluent kind of syntax so you can say like this dot query dot bool dot must dot whatever and so it doesn't really read like english but the the compiler and the intellisense guides you into writing mostly valid queries so you have to really go out of your way or just kind of get unlucky to generate something that isn't valid and they call that a

domain specific language because it does represent all the things that you can do and you can change things together and it's validated but yeah i mean if you say that then aren't you saying like any kind of api that you write for c sharp isn't that kind of a dsl then that's kind of what i was thinking right like if you wrote or contributed to like an orm or something you're kind of doing the same thing or even even the specification pattern or or even test driven type stuff like have you seen the Fluent test? I think, like, XUnit has, like, a Fluent plugin that's, like, this.must or this.like. It speaks to it, but, yeah, I don't know. Like, when I was reading this chapter in here, it felt more like talking about

the business problem and then trying to tailor a language to the business problem, right? That's what it sounded like. And they do talk about like using something, I think they specifically referenced like Perl or Python, I think was the examples they gave. Yeah. But when I think about writing a domain specific language, I never considered it as like, like for example, the example you gave Joe,

where like here you might think of like some classes that have some methods on it. Like, I don't think of those as being domain specific languages. I always thought of it as maybe that's why maybe I'm wrong. But I always thought of it like a domain specific language is something that you could just give to like a business user and say like, hey, write it. And here's like, here's the keywords, you know, that we'll agree on. Like, here's, here's our keywords you know that we'll agree on like here's here's our ubiquitous language that we agree on and you write it that way and then i can understand it and maybe i can even have like code that can generate code from it right so that's that generating the code part that is where like you know i that's where the disconnect is yeah and that's where the lines get a little blurry with this library because it's not something where every function runs out and does something. It generates an abstract syntax tree. And so you can kind of keep appending stuff with your fluent syntax so you can add more conditions, more filters, more aggregates. And at the end, when you say go run it, go search,

that's when it actually generates the request to Elasticsearch, which does represent kind of a different language. It generates a JSON object that gets sent it actually generates the request to Elasticsearch, which does represent kind of a different language. It generates a JSON object that gets sent to map to your request. So it's kind of like you mentioned there, where it does kind of build up a syntax, and then kind of all fires it off at once. So a little bit like I can kind of see that, but still, I feel a little squeamish about calling that a DSL. Yeah, I mean, I'm with you. Like, okay, so specifically here in the book, right, it says like, we always try to write code using the vocabulary of the application domain, which if you've listened to the domain series, domain-driven design series, then that should sound kind of familiar to you, right?

And they say, even in some cases, we can go to the next level and actually program using the vocabulary, the syntax, and the semantics of the domain. Yeah, it's, I don't know. I've never, maybe it's because we live in a world, because this is what, 20 years later, maybe it's because we live in a world where the languages have progressed enough to where it doesn't feel necessary to do something like that. Or maybe I'm just missing it. Maybe I'm just not, maybe I'm just not in the mindset of, I want to write my own language to, to speak to the business, you know, to, to code and be able to speak to business thing. I'd almost rather take the domain driven design approach where it's like, yo, just name your objects in a way that the business speaks to you in. And then that way you're not having to try and create something that is a one-off use to me.

And usually not as extensible, right? Yeah, I did think what you said there is really spot on. It's like, why don't I just give them some sort of JSON schema or some examples that show what they can do, or just build a UI if it's really complicated and involves some sort of chaining. But I did think of a couple of examples

where I've used DSLs, and has been like just like some little dinky music programming where you can kind of like draw the letters or the patterns of the music and it makes sense to be there to use that because like i don't want to have to try and program it be arduous to like have all that stuff dragging around on screen but if i could just kind of type like the little numbers that represent the notes and the little various flavors then that's something that kind of makes a little bit of sense to something that gets translated and it's just easy for me to type in that format but for the most part i really don't see a whole lot of this so yeah maybe you're right maybe technology's kind of advanced to the point where this just really dsls aren't super necessary anymore well i mean we see it every day so

the the canonical reference that comes to my mind when I think about domain-specific languages is like for anyone who is an Atlassian user, right? If you live or work in the Jira world, right, and you want to query anything, you can use their query syntax, JQL, to, you know, do true run searches. And I imagine in the background, you know, they're translating that JQL into something that might look more like, you know, SQL, maybe. But, you know, I don't know. But, you know, that layer of abstraction gives their, I imagine it buys them the ability to have some layer of protection in the form of like you know maybe they're protecting against sequel injection or something like that because it's not really sequel that you're writing does that make sense so you but that isn't a case that you know we see as developers we see often right that one's in our face Yeah. So what Joe said a minute ago about like

ASTs, that's basically what JQL probably does, right? It's something that builds up this syntax tree that you can do. And I will say there have been times I've thought about doing something like that because you want to communicate your intent and using something like Antler, A-N-T-L-R for those who want to go look it up. It's kind of interesting because that's how you could do it. If you want to implement your own type search, when I think about this stuff, I think like GraphQL or OData or something like that. If you created something that allowed you to say, hey, I don't want necessarily it to speak my domain language

and I kind of get it right. Like I want it to be able to provide a complex search in a way that's sort of human readable. That makes sense to me, but I've never ever considered writing a language for, for a particular business problem. You know what I mean? Or a particular business domain, I should say. It's just. It feels foreign to me. Yeah, maybe if I did it once or twice, then maybe I would start seeing places I could use it. But, yeah, I don't know. If you got a good tip on maybe an article or getting started type thing to kind of help me get along, then that would be awesome. Or if you know some other common places where you see it.

Like I mentioned the JIRA example. But, you know, if you know of another example, I'd love you see it. Like I mentioned the JIRA example, but if you know of another example, I'd love to hear it. Yeah, I mean, they even said in here, if you do this, so tip 17, actually, we should let you do this one, Joe, because I think you've done all the tips up to this point. Oh, sure.

Tip 17, program closer to the problem domain, which is, I think, great advice. It makes sense to me. It is. And what they say, and this is what kind of makes sense, is if you coded a higher level of abstraction you were free to concentrate on solving the domain problems right which is good and it helps you ignore the implementation details but that's where i sort of feel like it's it still just sort of falls apart for me because

the power you get with ac sharp or java or any of that kind of stuff is in the details right like you can do whatever you want as long as you're providing decent interfaces or abstractions in your code itself then you then you can achieve that same type of thing without creating your own language yeah it's important to call out though too though like some of, they reference like this language doesn't need to be executable, right? So we talk about it in the form of like, or at least in my mind, I think about it as like there's some kind of a compilation process that happens whenever I typically think about DSLs.

But, you know, they're saying like, hey, it doesn't have to be, right? That's a great point. It could just be a language that like maybe you and the business owner are using and you're able to like write it down and communicate out the thought right like pseudo code is kind of what we're saying yeah that's that's a super good point and i hadn't even thought about it from that perspective which then kind of takes me back i mean in a so this is where like i can't stop thinking about it being compiled because it kind of takes me back to our spec flow conversation or cucumber. But then I'm like, oh, but that gets executed.

It does. Right? Yeah, I make the point earlier on that the computer language has influenced how you think about a problem. And I've heard that from a lot of different people, and I definitely agree with it. Someone recently did kind of a coding challenge where he said, hey, go solve this problem. It was like a web spidering kind of problem. Solve this problem in your favorite language. And then they got a bunch of solutions for people.

And the people that didn't go used the fans, did the multi kind of concurrency cool stuff. The people in JavaScript did it async, non-blocking. But most of the people that did it in other languages did it iteratively. And I think a big part of that, and they kind of speculated a big part of that was because the techniques in Go and the techniques in JavaScript, it was common to solve problems like that.

And so while you could do stuff like that in like a C Sharp, people just tended to not really think of it that way because that wasn't like their normal kind of flow. That makes sense. So I thought it was cool. Yeah, I mean, it also makes me question too like myself as i'm reading through this because you know we talked about like um where would you implement a dsl and you know that that search kind of capability right that that makes sense and i'm like oh yeah but am I being influenced because of JIRA?

Probably. You know what I mean? But it's because of the power that it provided, right? It's because it feels right when you use it. But I mean, imagine if you were to Newegg and you wanted to do a search and Newegg had their own query language and you could just, rather than clicking on facets in the left nav, you could just, like if you really know shop there a lot maybe too much right you could say like uh you know where speed equals 3200 and type equals ddr4 and uh you know amount equals 64 gig or something you know what i'm saying like if you could if you could like type to those kind of specifics uh then it's it's really clear to you what you're

trying to get across and you would hope as a result, and the search would be too. Yeah. So they even say writing in a mini language, right? And this is, they're saying this could be a tool that interacts with the existing application as if you were a user on a system. And I've actually seen stuff like this before. I don't know if you guys ever had, but you remember the 4GL languages? There were a bunch of them out at one point.

CoolGen was one. I don't remember all of them. I think maybe even Delphi could have been one at one point. I don't know. But the whole idea was it was sort of like this drag and drop world where you didn't have a ton of control over what happened underneath the covers, but you had this functionality that could happen. Well, the problem was, is those things could only do so much. And oftentimes you couldn't code the stuff, right? It was more like you drag something over here and an action could happen. And your actions that you had available were like saved to a database or post to some other URL, but that was

it. So if you wanted to extend it, a lot of times what people would do is they would have these things that would be able to interact with those UIs and you could script that kind of stuff. And that's kind of like what this was talking about is you could have tools that could, you could act like you were a user.

It almost reminds me of, what's the testing one right now? I know you guys can think of it, the browser one. Selenium. Selenium. It's like that, right right selenium allows you to interact with a browser as if you were the user doing it but it's actually a program writing it right so i've seen stuff like that and that and that can actually be hugely beneficial in some situations yeah i think of um like audio processing programming like our buddy aztec has done some stuff with uh he's done a lot of stuff with audio programming and uh like chaining together kind of different things like filters and timbres and when you look at it like it doesn't look that

crazy because there's a couple visual things that drag together and it kind of maps there's like little lines and circles and instruments all kind of chained together so you can look that and you can imagine how people could talk about it like hey take this tone and pipe it through these filters and map it over here. But when you start thinking about it, if you're trying to code that by hand and all the math and the bit fiddling and all the stuff that kind of happens and mapping files and stuff, if you're thinking of that low level, then you can't really communicate very well at a high level. That is true. Most people can't. Sometimes it's really hard to get those two different views.

The other thing they say is these many languages could be in the form of metaprogramming. Now, I think all of us here have done that quite a bit, right? To where instead of writing the code to do exactly what you want, you write code that will read data from some metadata that you save off somewhere, and then it will go do something for you, right? So you have this very abstract way of doing things. That can be super powerful, right? It allows you to change some data in a database table, and your app just works, right? But it's also typically pretty rigid in that once you get past your your initial use cases then it's like

oh well we need it to do this yeah oh man like those first five use cases are okay but then like six and seven come with pain right yep but there is really cool stuff here though because you can have it like one of the things that they say in here. And we've also done this. You have it auto-generate your UIs for you. If, you know, if like CMSs are a super popular example of this in a nutshell, CMS, what pages do you have? Okay, here's the pages. What are the fields on those pages? Okay, here they are.

It'll generate the page for you, right? I mean, they actually do reference that, though, about like it being, you know, that lock in that you referred to in that, you know, the kind of pain that you're going to have with that. But, you know, they make the point of saying that most applications are going to exceed their expected lifetime. So you're probably better off just biting the bullet and doing it right. Which I thought that was an interesting thing like most applications exceed their expected lifetime i'm like oh yeah that's very true don't they all even your prototype i mean you know i mean windows xp might be the most famous right oh man yeah that os lasted a little bit too long yeah i like the maintenance too they mentioned here and like you know if you get your stuff out into like metadata you can imagine then like all your kind of steps your little rules like this is dependent

on that whatever is kind of specified on the file then it's really easy to see what's happening much easier than going looking at thousands of lines of interweaving code and it's also easy to kind of port stuff so you know what the rules are so it's just a lot easier to maintain if your data is separated i definitely believe in that for sure. One thing, though, is that, like, as going through this, at some point it was like, okay, well, at what point are we talking about configuration versus a language, right? And do we call configuration a language?

Because they reference, like, a CINMIL configuration as an example, right? I'm like, that's – I don't consider that a language, right? That's configuration. Totally agree. Yeah. You mentioned the JSON thing before, Joe, earlier, but even JSON could technically be configuration too. I mean, like take, for example, you know,

Visual Studio projects, like new Visual Studio projects, right? So, like, do you call that a language? Right. I mean, I, I totally liked the example that they gave here about, um, you know, a windows resource file for the UI. Like you kind of hinted on that about being able to create the UI from it. So, you know, that made sense to me as like, well, I don't think that I wouldn't count that as configuration because that gets compiled. And again, there I am with my compilation. Yeah. I mean, I don't know that compiled necessarily does it. Cause I mean, we've definitely done things where you'll say, Hey, what, what are the form fields that show up on a page and you'll save some metadata about it, right? Like you're going to have first name, last name, whatever. So that's not compiled. It's interpreted at runtime, which I'm fine with.

Which you could make a case that that is a form of compilation, right? Just in time. Maybe. Yeah. Yeah. It's, it's really, it's again, though, I think it goes back to what you said. It's sort of blurring the lines of what's a language versus what's just configuration right the the key is you wrote an application that knew how to read that particular set of data that you wanted and do something useful with it so i think where they're sort of drawing the lines of configuration is like there's the uh you know what do you want your background color to be okay that's not really doing much Okay. Let's say that we agreed on a style sheet, an XML style sheet, right? Of, of how we would describe, let's say products like, you know, uh, there's going to be a product inside the product. Yeah. I'm sorry. Yes. I said style sheet, but I didn't mean that. I meant

schema, yeah. There's going to be the product. You're going to have inside of that tag, you're going to have a description, you're going to have a price, you're going to have a UPC code, like things like that, right? That would relate. And that then that one tag might belong into a bigger one that's like, you know, you know or whatever right at what point do we say that that thing that i'm describing does that count as a dsl or is that configuration or is that just markup of some data like you see where i'm saying like all these gray lines come in because because if send mail can count if the send mail configuration can count in per their you know deciding you know they they refer to it as a data language right yeah i yeah that it's definitely blurry oh by the way i should i should you know clarify too

that um you know they say that this data language languages produce some form of data structure used by an application. And in the imperative language, which is the case of the Windows resource file for defining what the UI would look like, imperative languages will be executed. Well, going back to this, they did contradict themselves a little bit, right? Because they said that if you have these meta-driven type things, the maintenance is usually easier. But then getting back to the point of what you said is sometimes it's better to bite the bullet and just, you know, go code it yourself. They were basically saying because over time, these many languages or these metadata type things can actually be more of a pain to maintain because of probably all the bolt on stuff that you're trying to do, right?

As you try to extend it further than all of a sudden, what was simple now became super complicated because it was never intended to do that, that extra stuff in the first place. So, yeah, I mean, you can imagine trying to write your own,

like imagine, imagine if you had to implement your own SQL, right? And at first you're like, just as like a mental exercise, like imagine you wanted to abstract that away, like Jira did, for example. And you're like, okay, well, I want, I want this new, my new query language to be used for everything that goes to the database. Like if you want to talk to the database, you got to go through this first. And at first you're like, well, my selects will be pretty easy. You know, um, you know, to what, to add a predicate, that's not too hard. I think I can handle a predicate. Oh, you want to join. Okay. Well that's going to be a little bit more

like as an inner outer, a full cross, like, okay. You see what I'm saying? Like it starts to get a little bit more hairy and then you're like okay what about now there's an inner select like do i can i do i even allow that dude is that okay so you could imagine like how it could get like progressively harder uh you know depending on your situation oh there's no as soon as it goes recursive, it's like, okay, now it's time to not do it this way anymore. Turtles all the way down. We're all done here. Yeah.

I did. They had a couple of challenges. You know, I love these challenges. Uh, the first one was, um, could you,

could some of the requirements of your current project be expressed in a DSL? And could you write a translator later for it? What do you think? Totally. So for me, yes, I could definitely see there being a DSL for the stuff I'm working on. I don't know that I can write a translator in a reasonable amount of time

without researching how to do that first. Oh, there's nothing about reasonable in here. Yes, I could write the DSL. And yes, that was an important distinction that you did not preface the question to Alan with. Yeah, reasonable never came into play here. I could totally write the DSL and I could write a translator and it would probably take the rest of his life. That's right. But it would happen. Yes. What about you, Alan? I mean, what I'm currently working on

could a DSL, I don't think what I'm currently working on could a dsl i don't think what i'm currently working on it would fit in personally uh fair enough yeah yeah i don't think so either but could you write a trans are kind of a dsl right say again like would you consider things like kubernetes a dsl like it's a language that's specific to certain tasks and abstracts away the details? Totally. I've actually thought about doing DSLs or UIs for Kubernetes to make it easier for people. Hey, I just did one for Docker that adds no value. Nothing you couldn't do already.

It's fun though. Right? We got another challenge here uh can you see ways in the framework you develop for one project to be reused in others wait what yeah it's kind of a weird question can you see ways in the framework you develop for one project that can be reused in other yeah this kind of ties back into a part that we don't really talk about that they mentioned where basically if you build some sort of like little kind of land language interpreter that goes and do some tasks and like maybe you could bite the bullet on the first time and then maybe you could take that language into other tasks and just kind of modify or tweak it for other things oh the framework is the first

language that you did from the previous question. Yeah. Oh, okay. If you write some sort of like SQL translator in one project, like maybe you could use it in a second one and it'd be much easier to do. Yeah, totally. Yeah, I imagine like once you bite the bullet and you do this the first time, then the second one will be easier to do and you might be able to reuse some pieces.

Hey, you remember Fusebox in ColdFuse? Oh, yeah. Of course you don't know yeah i actually had written my own version of like a framework back then and i used it and everything so i can't man me too yeah it was awful yeah it was awful this episode is brought to you 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 in 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 this space, Discover.bot will teach you everything there is to know about 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 more and get started on your next great bot. All right. And so it's that time of the show where we, again,

say thank you to everybody who has left us a review. And if you haven't, if you remember when you get back to your computer and we made you laugh or giggle or you learned anything at all, please do take the time to go up to codingblocks.net slash review, and we'll have links there to iTunes or Stitcher so that, you know, if you've got an account on either, or if you don't even want to have to create an account, Stitcher is a great place to go because they don't require you to put one in and, you know, leave us a review,

put a smile on our face and, you know, it helps other people know that, you know, you're enjoying the show and all that. And if you haven't already tell a friend, you know, hopefully, hopefully they'll, you know, latch on and learn something and get a laugh out of it too. All right. And with that, we're onto my favorite portion of the show. Survey says, all right. So in episode one zero six, we asked, Hey, why don't you go to conferences? And your choices were too expensive. Got to think about that ROI. Or too far.

I could finish an entire Coding Blocks podcast just getting there. Notice that we might be upset if you picked that one. What about both of the above? that's this option or but i don't go to conferences why can't i participate in the survey no i do go to conferences oh but i i'm sorry but i do go to conferences why can't i participate in the survey and i misread that all right so i I think Joe went first last time. So, Alan. I'm going to say a lot of people are going to say, what about both of the above? Oh, that's this option. I'll go with 33%.

All right. Joe. Sorry, I was looking at E3 right. Joe? Sorry, I was looking at E3 announcements. What? Right. I was kidding. No, I think, oh, geez. I'm going to say both of the above.

It's too expensive and too far. What's your percentage? 33%. Wait. I think you just tied me on both. No, no, no. You can't pick the same. Alright, Alan, what do you change it to? I'll go 34. Wait. Oh. I win. Well, that backfired. It did. Alright, whatever.

All right, so Alan picks... Which one did he pick? What about both? What about both of the above? Oh, that's this option at 33. No, wait, 34%. And Joe picks also, what about both for 33%? And Alan wins. Sweet. Oh, what about both for 33%? Alan wins.

Sweet! Oh, man. Hey, you brought it on yourself, Joe. It was probably like 60%, wasn't it? It was 52%. Okay. And then the next one was too expensive, yes. And if you think about it, it really was the safe option. It was. Because

chances are like you're probably already thinking like even if it was only like 10 miles down the road you're like that's too far right yeah so so all it had to do was just be really expensive and then it automatically was like well if it's not in my house it's too far that's right like if i don't have to drive by it on my way home from work it's too far uh we gotta do a twitch conference is what i'm hearing yeah so yeah and close i'm sorry free and close all right so the second one was uh too expensive but it was uh at 27 yeah it's not surprising yep even a couple hundred bucks for for training like it's just awkward to kind of bring it up. A lot of companies don't really seem interested in paying for training nowadays, and you definitely don't want to pay for that sort of stuff. It's not like it's fun.

Yeah, out of pocket. It's usually like a long day, right? Or two. Yeah. It's fun, but it's not like whitewater rafting fun. Exactly. If you've got two Benjamins to drop which would you rather do it on a tech conference or whitewater rafting e3 announcements yeah pre-orders yep all right so which would you prefer to hear the next survey or take time for a joke. Joke. Always a joke. All right. So first off, I love this name. So you've heard this name before. This is from a Stitcher review, PB and Jamstacks Stitcher review.

Why did the angry function exceed the call stack size? Angry function. It got into an argument with itself. Oh. That's pretty good. That's really good. Alright, so for today's survey we ask, hey,

how much data do you use per month for your home ISP? And your choices are less than 250 gig or less than 500 gigabytes or less than one terabyte or

no idea. Unlimited plan, bro. He's my neighbor. Oh, wow. Oh, man, I should use that. That's a great one. That's all there. You'll have to ask my neighbors. Oh, wow. Oh, man, I should use that. That's a great one. That's all there. You'll have to ask my neighbor.

Gotta ask my neighbor. I'm not doing this stuff on my own account. Are you kidding me? Oh, that's amazing. And I apologize. I got this from somebody in our Slack channel, which, by the way, if you're not a part of our Slack, you're missing out because there really are amazing people in there. So I fully apologize when I wrote this down, I totally forgot to say who did it. So thank you, whoever it was, feel free to reach back out and

be like, yo, give me a shout out on the next show. So there's our write-in option there. You'd have to ask my neighbor. That's hilarious. I love that one. And you better start locking down your home routers. Yeah, which really, I mean, if you wanted to be a good neighbor, you would tell them, like, hey, by the way. But that's after you logged in with their default admin and password. No, no, no.

You wait until you're moving. Oh, good point. Good point. Wait until you're moving and then be No, no, no. You wait until you're moving. Oh, good point. Wait until you're moving and then be like, hey, by the way. But if you wanted to be a good neighbor while you're stealing your neighbor's internet, you should at least use some sort of VPN service. So when the Pheebs come knocking on their door...

Is that what we call them now, the Pheebs? It's the Pheebs, man. That's what they say in some shows. Oh, okay. 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. Like Alan mentioned, Clubhouse is designed to be developer first, the UI is simple and intuitive enough for all teams to

enjoy using. Like Alan mentioned, Clubhouse is designed to be developer first. It's designed for developers by developers. And you can tell because of all the little details they sprinkled in like get tips throughout the UI. And they make it a big point to highlight open source projects that integrate with them. And they're always adding new features, like they just recently added the ability to reorganize the buttons in your navigation bar to suit your needs, or their latest feature iterations that help you streamline the sprint planning and management process. Clubhouse recently launched the Clubhouse community, where you can connect with other software engineers and project managers using Clubhouse. 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. 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 to get your free two months and see why companies like Elastic and Full Story and LaunchDarkly love Clubhouse. All right, well, let's get back into it with estimating. You were excited about this one, right, Outlaw?

Well, yes, because this one was weird there was some good stuff in here but there was also some like weirdness it was like oh i'd never ever thought about it like that but then i went and reread parts of it and i was like you know what i've actually done this like a billion times we all have and. And when we get to it, I'm going to call it out. I bet I know the section you're talking about. We'll find out shortly. We will find out. So estimating. We all do it.

We all hate it. It's the worst part of our job. Yeah, I didn't even want to read about it, honestly. I was at a doctor's office. I was like, I'd rather just stare at the wall. You'd rather the doctor be poking you and prodding you than actually doing this? I say that though, and yeah, we all chuckle and everything, but it's really true. And I really meant it when I say it, because the reason why we all hate it is because everyone is going to

hold you to it. So there's little room for error. If it's your boss, your boss is going to hold you to it. So there's little room for error. If it's your boss, your boss is going to hold you to it. And then if you don't make it, they're going to want to know why. If it's a customer, like if you're consulting, for example, and you don't make it, there's never a happy path if you don't make that estimate. So it's like, it's really an important skill to, to be better, to get good at. Well, you know, the flip side of that, that's frustrating too, is let's say that you give an estimate and you, you padded it a little bit so that you would come in in time and then you, you just destroy the estimate, right? Like it was going to be a week, you finished it in three hours. Oh, well, I can't believe the next thing you're going to be a week you finished it in three hours oh

well i can't believe the next thing you're going to give me because you sandbagged on it and it's like man that's not how this works or or where i thought you were going to go was that uh you give an estimate you do pad it you know so like you're like okay hey maybe i think this is going to take uh a week but maybe give myself like a 15% buffer or something. So you add on a day or two or whatever, you know, and then whoever you're giving that estimate to is just like, well, that's not going to do right. That's worse. Whoa, whoa, whoa.

Now it's got to be faster than that. Surely two days. Surely you can do better than that. So it's like you can't win. No. Yeah. I get such like just anxiety just thinking about estimates every time i have to do it i hate it and i hate it so much that i like i almost like

i have to fight myself to actually try and do a good job of it because my my instinct is just to like kind of like throw anything up there running high because it's just such a hard problem i'm gonna feel bad no matter what so but i do like that when i uh when i really try to do a good job of it it does make me kind of think through the problem and the best success i have with estimating is when i start thinking like okay if i were to do this right now where would i start typing what things would i look let me get a little bulleted list of things that need to happen and when i do that a lot of times i'll notice like oh i thought this was one day but really i think i could just do this with the email like this doesn't even need to be a ticket or another handlebook.

Oh, I don't think I could do that at all this week, actually, because I don't have the things that are important. So I do like thinking through the problem, but not enough to want to do it. So what you just said is spot on what they said in the book with it forces you to know more about the program, which is so true. And the part that you just said about bulleting out the things, it also helps you understand what might need optimizing versus what, like you said, you may not even need to touch it, right? Like there's no clue going through that exercise will definitely force you down that path. Like there's, there is the best way to put it is, all right, I got to do an estimate. Well, I can't do the estimate if I don't know the pieces.

So I guess I need to know the pieces and, and it can be beneficial, super beneficial. And that leads us into the next tip. Tip number 18, estimate to avoid surprises. Man, this part frustrates me. But isn't it a surprise when you don't make the estimate? So how do you do that? Surprise, not for me, not for my manager. So this is the part right here that is really the kicker is how accurate is accurate enough.

I loved this section. Yeah, it was good. It's so true. You have to know the context. This is, this is where it gets good. So you want to jump into the next one? Yeah. I mean, basically there was a example here where they're talking about like, depending on the, the measurements that you use to give your estimate is going to be, is going to dictate kind of like how accurate you're being, right? And based off of whatever that accuracy is, is going to influence the person receiving this estimate as to like what their expectations are going to be. So, for example, let's say that

you have an estimate and you want to say it's like, you know what, I think that's going to be about 21 days, right? Well, you put it into a smaller unit of time there by saying days, where maybe you should have instead said, I think it's going to take about three weeks. Because if you say 21 days, then the person receiving that estimate is going to expect it in terms of like, okay, well, you know, I might get it in 20 days, I might get in 22 days, but you know, it's gonna be around there. Whereas if you said, hey, you'll get it in three weeks, then they might be willing to accept like, okay, it might be two and a half weeks to three and a half weeks before I get it. So automatically, you just gave yourself, you know, you know, another day and a half potentially, uh, by, by saying it in terms of weeks. Right. And there are several examples

that they give like that. Yeah. And that is true. That's absolutely true. I've seen it happen. One thing I didn't really mention too, but depending on your audience, like if you're a third party and dealing with somebody and you tell like, let's say like you say tell your boss like two weeks your boss might know he means uh you know 80 hours if you tell a third party two weeks they think oh next friday which could be totally different things you know based on whatever because they're kind of thinking about when a dime is going to get delivered not the amount of work that's going to be done so that's something like could, I definitely get myself in trouble. Like when can you guys get this time?

Like I was only going to take me an hour and they're like, oh, okay, great. I'm like, but I can't do it till next month. Like, oh, right, right. Okay. The other thing here too, was also knowing whether there needed to be high accuracy or if it could be ballpark, right? Like if you got, if you got an open heart surgeon laying on the table right now and their chest is open and they say, how quick can we get that heart in here? You know,

saying about an hour is probably not going to cut it, right? We can have it in here in 13 minutes is probably more what they're going to need in that, in that situation. So you actually have to know, you know, how important is this estimate in terms of what needs to be done? Yeah, they gave the example of pi. Like, you know, how much precision do you need to know pi to? And, you know, depending on who you are, like the state of Indiana, apparently three is good enough, right? That was funny. But yeah, apparently there's an indefinite law on the, you know, indefinitely tabled potential bill there for Indiana to just, you know, represent it as three.

But if you're at NASA, you know, you might want it down to 12 digits. You might want it more. Yep. You know, who knows? When you're trying not to miss a planet, that's probably a thing. It might matter. Right. So one of the recommendations from the book on this

whole you know using units was like they took the time thing and they said hey if you're going to do anything up to 15 days then probably using the days unit is good enough if you're going to do anything past that and up to eight weeks then then probably the weeks unit is enough, right? Like two weeks, three weeks, four weeks, whatever. If you're going to go up past 30 weeks, then you probably need to be talking about months, right? And so five months, right? Or actually the way they phrase it was just think hard about giving an estimate. Yeah. If you go over that, that they were like you really shouldn't even be estimating now because really right you're gonna give an estimate of more than six months out all right right but i mean like that's real world though it is honestly i mean if you were talking about like building a

building right i mean you know that might be like a a multi-year thing, right? That's not uncommon. And that's kind of stepping into what we're going to talk about in a little bit. But those estimates can typically be given because it's something that's been repeated a lot, right? Like, say that you're somebody that puts up a Gold's Gym, right? It's almost like a cookie cutter thing. They know that it took them three months to do it here. It's going to take three months there, you know, give or take a couple weeks. So that's pretty easy to reproduce.

Right. So you've already put down a thousand miles of train track. You know what it would take to put down 10 more miles. Exactly. And that's key. And we'll get into what that means here in a minute. I want to call out to you that my train track example is super current with the times. Absolutely. Hey, look, I think I may be incorrect here, but I believe that it's still

one of the most used modes of transportation for moving freight around. I believe it is. Here in the South it is. I feel like I get stuck by a train every time I get in my car. I was like saying, if I knew how to do something, then I would have automated it already. So kind of by definition, every ticket I have is stuff I don't know how to deal with. It's true.

It is true. I will say Joe more than most people I've ever worked with, if he has to do something more than two or three times, he's writing a script to do it. I love me some scripts. Yeah, he's done it many, many times. Script sandwiches. Script sandwiches.

Skip on toast. So the next thing was you have to really understand what's being asked. And this is, this is critical. I venture to say there's lots of people that don't really truly take the time to do this. And so estimating is nearly impossible. Yeah.

I mean, it was in the same kind of thing where they were talking about the, you know, the units that you describe are going to make a difference in the interpretation of the results. And so you need to choose the units of your answer to reflect the accuracy you intend to convey. Yeah, that's a good way of putting it. So understanding what's being asked, the scope of the domain, which is big. And one of the things that I thought was really cool was they said, hey, part of your answer can be, hey, assuming that we keep this the way it is, then this feature will take X number of days. It's like putting sort of like a quid pro quo in there.

Like, hey, we're going to make the assumption here. You change that. And all of a sudden this, this whole estimates bunk, right? So that, that helps lead in and set the mindset for the other people receiving that estimate that, Hey, you know, you have control to either make this succeed or to potentially blow it completely out of the water. And that helps too with your case down the road. Yeah. If it doesn't rain for the next week, we can lay the foundation of the house in this many days. Definitely. As opposed to, hey, it'll take us three days to get that foundation laid. Oh, well, it just rained three days. Sorry. Or worse, you'll have it in three days. You'll have it in three. Right. Perfect example. Hey, it rains we're assuming it doesn't rain then we can

do this so it at least puts it i don't want to say doubt i think that's the wrong word but it at least lets them know that there are other factors that can impact the estimate other than just your ability to do something yeah build bare bones model makes sense to me. And just kind of said, like thinking through the problem building

that bare bones model can help reveal things, exposing answers. Yeah, I don't know. There's something about me that just really doesn't want to do that. But I don't know what it is.

So the funny thing is what you just said is what you had led off with is this building the bare bones model and and actually you know kind of bulleting out the things that need to be done and and i know that joe's done this a lot of times outlaws done it too i've done it is hey you know i know you guys are asking for this, but I think that we could achieve most of what you want without doing this other thing that's going to make it three times as long to do it, right? So is that okay? Yeah, like I know you wanted X,

but if I give you Y, not only can I do it faster, but you might not get all of the features that you really originally wanted, but you get it faster. Is that acceptable? Right. And a lot of that's understanding the business need, the domain problem that's being asked. If you fully grok that thing, then you can come up with these solutions that help both you and them.

Yeah. Like you want a custom e-commerce site? Awesome. Uh, you want it custom made specific to your business. Well, that's going to take, you know, a couple months, maybe, I don't know if you want it, if you are willing to base it off of something like a Shopify, well then, you know, you could scale that back down to days, but now it might not be tailored to your specific business. Is that acceptable? Can you work in those confines?

Yep. Yeah, that's really important. It's like you want to start making money tomorrow, make sure this thing works, or do you want to put down a massive down payment? Right. Yeah. Looking at the model,

maybe it's just the planning that is kind of rough. A lot of times I just want to get in there and start typing code, and I feel like I'm being inefficient any time that my hands aren't on the keyboard but uh it's really important you ever do the thing like you really spend a lot of time estimating like the beginning of a sprint so you're like you'd spend hours really researching and figuring out good estimates that just feels so wrong to me i so who cares i am, God, I'm so with you on that. And it's so frustrating because I see both sides of it, right?

I see from a developer standpoint, like, man, I'm spending hours just trying to figure out how long it's going to take me to do this. And so you're like, man, let me just code, right? Like the sooner I get in here, the sooner you'll have some results. But I also get it from a project planning perspective from the people up above that need to say, hey, when do we think we'll have this feature done? Right? Yep. So I get it. It's frustrating.

I wish it was something that just automatically did stuff. Like it could figure out based off your past stuff and be like, oh, this looks like this would be about that. My favorite way to think about this, and I'm pretty sure we've talked about this before, but our friend John, who was on episode 100 and 101, he had like, in my mind, the best possible way that you could think about this. Rather than you estimating how long you think it's going to take to do something, you instead let the business owner say, this is how much time I'm willing to spend on you developing something. And if it can't be done in that amount of time, then I don't want it. I like that. But also what do you do when, when they say, okay, well, we want,

we'll give you two months on this and you're in it. And then two months comes up and you're like, I actually need another three weeks, right? Like that's the only flaw in that thinking is... Well, if you miss the estimate, I mean, you have that... If you miss the estimate, that's either way. It doesn't matter if you created the estimate or if they said this is the amount of time I'm going to give you. Like either way, you missed the estimate and then, you know... And sometimes there might be factors that come in out of your control, right? This is where it's like, hey, as long as it doesn't rain, this is what it'll take, right? So, you know, I mean, you could work with the business owner in that regard, but I still love that way of thinking about estimates.

Rather than you estimating the amount of time you think it would take to develop it, the business owners say like, hey, if you can do this in an hour, I want it. If it's going to take you three months, I don't. Right. Yeah. Right. Yeah, I do think as much as I complain about it like my estimates aren't usually terrible and that's because i've been doing it for years and so the tasks that i do like kind of week to week aren't usually that different from the week before so i know if i just blew it last week i had a little bit more

this week and things just kind of work out it's just i get anxiety about it and so i had something about the planning phase that drives me nuts and And I hate the idea that I could spend four hours planning for my day and still not come out that accurate. Right. Well, I mean, we had something that we were working on together last week and you know, you're like, I'll have this hooked up in half a day. Right. And then three days later, you're like, man, I'm still working on this. It's just those things that you can't plan for because you don't know. And that's just really hard. But one of the things that they point out here, and I think this is super important, even as much as we all sort of hate having to do this estimating game, is they say that building that model, the mental model or the one that you write out on paper,

it can also identify inaccuracies in the estimation, right? Like as you start building that model out a little bit further, you can look and be like, oh yeah, we totally didn't account for this. So it's going to take an extra day or maybe we overlooked this and it's going to take two or three more days. You know, that does help. Yeah, that's good. And let's, just by having estimates, it lets the business kind of have a say in that. Like, you know, we, that does help. Yeah, that's good. And let's, uh, just by having estimates, it lets the business kind of have a say in that. Like we, you know, we mentioned kind of going back to them and saying, we can do this in shorter time, but you don't get all you want. If they see something in your estimates that they don't like, and they can say, you know what,

this can wait until after these other things. Now that I know these other things are only going to take two hours, like, yeah, push them to the front of the list. So I get it. It's important. Well, I'm not happy about it. And it does take a lot of time to even build out those models yeah the the next one that i thought was also pretty good was this whole you know you can keep refining that model you can keep going back and being like well i gotta change you know maybe it's well we gotta touch 10 pages to do this and then if you keep going further well they're on that there's there's a thousand lines per page and then you get into it you're like well there's 300 methods per page well there's also you could keep digging in and keep finding more and more and there's a point of diminishing returns

right like maybe maybe pages was enough we got to go touch 10 pages that are all kind of gnarly maybe that was enough and going in and saying hey there was a thousand lines per page and you know And you know, this is what's happening on each line. You didn't add that much value. You didn't change what your estimate was going to be by going in and spending that much more time or finance. So you, you learn this over time as you figure out how to estimate. So now we're starting to get into the part where I was like, oh, this part's really weird. Now we're starting to get into the weird part where they're talking about like breaking the model into components. Yeah.

And then... I think... Okay, go ahead. I'm sorry, you go ahead. Well, no, I'm curious to see where you're going to go first before I do. Yeah, I had the same part there. I think they were talking about much bigger estimates that I'm used to giving.

Yeah. Because then they get into talking about like, okay, once you break these apart, then start identifying the parameters to these components and assign values to them. And so they go through this whole, as they're describing this section, they're talking about like, you know, using a spreadsheet and creating a math formula around these components and these parameters. And, you know, they're pointing out like, hey, the ones that are going to be multiplied or divided, you know, those are the ones that you're going to care about more than the ones that are just additive, right? Because if something is going to be like two times, well, then that's a bigger deal than something that's just going to add like five milliseconds of time to your overall project, right? Like you're not going to notice that five milliseconds, but if something else is going to be like double the time, right? You might notice that. Yeah, for sure. And I,

you know, I was thinking like, i'm thinking sprint planning as i'm reading this section and i think they're thinking like waterfall six month releases yes for so many of my tickets it doesn't make sense for me to do this kind of level of breaking up because i do this level of planning so rarely this is like the kind of planning that like maybe comes along with the big project like once every couple years once a year maybe this is that is exactly where like in the beginning i was thinking about this and i'm like man no one like i've never broken out a spreadsheet to write out like requirements or like not requirements but like to visualize all the components and like how thing long things we're going to take and then be able to see like, this is the impact of that one on that one and all of that kind of stuff. But then as I got to thinking about it, I'm like,

oh, well, let's go back and consider when this book was written. I know where you're going with this. Can I say the three letters? Okay. Is it UML? No. That's not what you're thinking? No. Okay.

Microsoft Project. Oh, okay. Microsoft Project. Because then if you think about this was written back in the waterfall days, right? And they're definitely using Microsoft Project to like identify, okay, we're going to have this page. This page is going to need all these components. It's going to take me this long for that component, this long for that component. Overall, that page is going to take this long. I need X number of these pages. This page is going to be a little bit more complicated because there's a search and I need to, there's this fasted navigation engine that I need to, you know, so you see what I'm saying? Like, you know, the about us page might be like super fast, but, but the search results page might be a little bit longer. And so you would like create this like waterfall of your project

and then have the estimate, like, there it is. You've calculated out the estimate, but never as a spreadsheet as they described here. Wait, did they, the project actually have that built in though, to where you could layer that stuff like that? I can't remember. Oh, yeah. It's been so long. Wow, okay. Yeah, man, I've been through some, like you could set dependencies on different components. Because that was the thing that kind of got me was when they were talking about

breaking out the things into components, I was like, okay, yeah, so maybe you have your about us page and maybe you have your listing page or whatever. I was like, okay, I get that. But when they started talking about going down to the method level and plugging in parameters and all that, I was like, wait a second, who's doing that garbage?

Because first off, if you're talking about an existing code base, that's a little bit easier, but tedious. If you're talking about something doesn't exist, right? Like how are you planning that out? Like talk about putting the cart before the horse. Like, that almost goes completely contrary to what they were talking about prior to which is don't write in the language. Tracer bullets. Yeah, don't do that.

You should be looking at both the tracer bullets and the domain-specific language. Like you, you've completely gone off the rails now because you're writing methods or planning out methods for things that you don't even know how they're going to interact that, but this whole section just kind of was like, uh, think of the search results, right? Like, I mean, you could just call search your method in that case, right? Like you're going to do, you know, some type of a commerce type site, right? And, and you're in, let's think back to, you know, when this book was written, there weren't, you know, some type of a commerce type site, right? And let's think back to, you know, when this book was written, there weren't, you know, a lot of search engines. Well, no, no, no. I was going to say like, you know, commerce frameworks out there for you to use. I mean, there were some, but, you know, let's say you wanted to roll your own for whatever your reason

was, right? And so a product search results page, you know, for custom search, that might be one of the things. So you know that there's going to be some kind of a search method. You don't know what it is. And so you could say like, okay, well, the page is going to be one thing and just stubbing out like the thing of that. But then the actual search results functionality itself could be its own estimate, right? Its own component that just happens to belong to that results page. yeah so so once i started thinking about this chapter in that kind of or this portion in that type of context right then it was like what everything that they were saying made a lot more sense to me like i

was able to relate to where they were coming from especially given the time frame of when the book was written right that makes sense and like you guys both said, it's more waterfall-y than agile approach. Yeah, and I was doing some e-commerce sites back in like, not 20 years ago, but like 15 years ago. And there was a lot of stuff that was, we were doing custom and there weren't a lot of things that were kind of, there was no Shopify. Things weren't kind of standard back then. And I remember finding Solar the first time and being like, oh my gosh, this is really amazing. My point there is we had to make those kinds of estimates all the time so we had to tell customers

how much we were going to charge them to build a website. It was so hard because not only did you have to figure out how much time it was going to take you and you wanted to be realistic and figure it out with balancing with the other customers, but you also had to know how much they were willing to spend. You kind of had to gauge

is this a $15,000 customer or is this a $60,000 customer? And if I think the customer has 60,000, I'm not going to try and rake them over the coals, but I'm going to not take some shortcuts that I would with the $15,000 client. And I want both of them. So it kind of added this new dynamic where it's like you wanted to kind of figure out a number that you thought they were in for and then try to kind of come up with an estimate to meet that for this kind of stuff you could do and sometimes one of those could be wildly off right get awkward well the worst part is when you underbid and then you still had to do all the work because you didn't want to oh yeah yeah and that's typically what happened anyways back in the day.

Yeah. Yeah. I mean, going back to like the MS Project days, that was definitely, you know, where some frustration would come in because you would take the time to put together that estimate, right? And you would be able to show like, this is everything that has to happen, laid out, right? And what I think it's going to take.

And then somebody would be like, yeah, but you see where that delivery date is not where i want it so you got to back it up to this date and now you got to reverse engineer like what the what what should the estimates be to make that delivery date you're like well okay yeah then why did i just waste my time to project management it's a slider right like Never mind all the details under it. It's like, wait, wait, wait. You have that thing three months out. Just go ahead and drag that thing back to two. Let's make that happen.

It's like, wait a second. What did you just chop off? We're getting more resources? No, no, no, no, no. We're getting more money? No, none of that. I just know that we can do this. Okay.

15 years ago, they'd be like, I saw you playing foosball yesterday. Right? But never mind that I was here until midnight when you went home. Right? Yeah. It's rough. I would love to read more stuff on project management. I've never really seen a lot of books.

Like, every once in a while, I'll kind of Google for, like, Audible or whatever. And, like, I just don't really see a lot of information written about that like you do for, like, developers. You know what's so funny is with Udemy, we all do it. So Joe Zach treats Udemy kind of like Steam. He buys all the things

and he has a collection. And I think that I'm sort of falling into that sort of category too because i'm like it's 10 bucks like i'll buy that i mean i want to know this for 10 bucks yeah right now i don't have the 30 hours to actually learn it but i'll buy it for 10 so yeah but god i don't even remember where i was going with this. How did you start this? Estimation, project management. Oh, project management.

That's one of the things. Every time, and I don't know if it's because of the estimation thing or because I just hate project management type stuff. I'll look at a course and I'm like, I should probably learn more about Agile or I should probably learn more about, you know, how to do timelines and I look at them and I'm like, there's no way I'll sit through and listen to this. There's no way I'll sit through and watch it. I want to know it, but I really don't want to invest the time to learn this stuff. Yeah. There's no way I'm going to listen to a eight hour audio book about agile.

No. Well, if you really want to go after your project management certificate, you know you could get like a pmp yeah right yeah georgia tech has a project management certificate program how much does it cost uh how much does it cost does it do they say course load determines the cost and how much so calculate your total by identifying the courses needed and tallying up to individual course fees. So, in other words, it could vary. Man, I don't think I'm there. Whenever I Google, I always come across P&P and I look at the kind of stuff they're talking about. I'm like, uh-uh.

It's funny. Like, we've talked about this before. Like, soft skills are important to me, but anytime I read something about, you know, how to conquer your, your fears or, or improve your motivation, I'm like, no, I don't want to read that. I don't want to hear it. I don't care. I know what I need to do. It's just doing it right. Like I just got to go chop the wood. And I hate it that I'm that way. But anytime I see a title like that, I'm like, yeah, I'll never read it.

For me, it's just finding the time sometimes. That's where it feels like, man, where do I get the time? Well, and I have ADD. So, you know, squirrel. Yeah. I'm gone. I go through phases. I'll do the whole getting things done or seven habits are highly effective or whatever.

I've read all those, quote unquote, read all those fancy business books. I like them, but sometimes I just get sick of them. I'm like, that's it. I'm going back to tech podcast. I do the same thing in tech podcast. I'll listen to a bunch of tech podcasts for a month and I'm like, that's it. I'm going back to tech podcast. I do the same thing in tech podcast. I'll listen to a bunch of tech podcasts for like a month and I'm like, that's it. Doing a break. I'm only listening to, I don't know, music and game podcasts for the next

week to recover. I'm the same way. I definitely go through phases. I'm halfway through a Kubernetes certification thing and I was super gung-ho on it for like a week and then one night my brain just melted. We're done.

Yep. Yep. I'll come back to this later. I'm about 50% of the way through. Remember Inside Out? Have you ever seen that movie? Do you remember that? Oh, yeah. The cartoon one? Where like each of the little emotions were a different character. Like the little red guy, anger. He was just like, we're out of here. That's Louis Black. Yes. i totally feel his his uh inner inner frustrations so answer me this then so then the next section they were talking about like tracking the you know your your estimating

prowess right have you ever ever in your life i'm not trying to like influence you here, but have you ever really ever tracked how well your estimates you're estimating is every day? Oh, really? Yeah, I would say yeah. I think you keep you keep track of how well your last estimate was. You can see it in Jira. That's what I was gonna say. It's only because of the tools we use. Okay, well, I guess I wasn only because of the tools we use. Okay.

Well, I guess I wasn't thinking of it in those regards. Yeah. Before then, when I did the, those boutique websites in commerce, I did the same thing. Cause I,

I read a thing about, uh, from Joel Swilski. Basically it was tracer bullets for estimates. It's like, here's how you estimate you estimate, you get it wrong and then you adjust. And so for a while there,

I was doing it with like a spreadsheet and, uh, it just got really depressing for me. For instance, like, man, uh, everything is way scary. I don't feel comfortable giving people estimates that are accurate. Yeah, I will say. In in larger scope, I've definitely not been as good about it, right? Like there's there's no question.

Like if somebody asked me, you know, how long you think this project is going to take? And it's usually over six months. I'm like, over six months. And then I don't think I've ever looked at it that close afterwards. But part of it, too, I think this is just trying to be fair to myself. A lot of times the scope changes so much on whatever I'm doing. On anything that's more than like a two-week type thing. Oh, I don't even care.

That's, that's sort of what I was getting at is, okay, if you give me something that's six months, I guarantee you, I've never worked on something that was a six month project that was the same as what it's supposed to start as, right? Like it's just, it's just never been that way. So tracking an estimate didn't make any sense because every time that someone, oh, I love that. Can we add this? Sure.

Right. But did you take it to the point where you would, okay, you, you get your estimate wrong and then you go back and reevaluate like, Oh, why did I get my estimate wrong? No.

Oh, it's not all bad. If I totally flop on something, there's lots of times I go back and look and like try to figure out what went wrong. Really? Yeah. Yeah. I'm from'm for like i you know i take notes and stuff a lot of times on like kind of on what i'm doing so i like i like to go back and sometimes be like what like what understanding like what did how did i get this so wrong like what mindset did i have or what did i miss what

was ignoring what made this so wrong and a lot of times I could figure it out. And it's so many times I just, there's some things that I continuously underestimate on. And so it's kind of nice to know, like what emails one, whenever someone asks me an email, I'm like, oh, two seconds. And it's because I'm thinking about sending a stupid email. I'm not thinking about tying into the business processes and the triggers and the business requirements I know nothing about because I just know about sending an email. When you say sending an email,

you're talking about in a program. Yeah, sending an email. Sorry. Someone's like, hey, you've done a lot of notifications before. We need to send a spreadsheet. Oh, no problem. I know how to send attachments. Easy. I got code for that. Then I get in there and I'm like, oh, wait. I need to send a spreadsheet like oh no problem i know how to send attachments easy i got code for that and then i get in there i'm like oh wait i i need to get the data and then like i can't just query it and everything's time sensitive and nothing

makes sense i have never like if it is if it's something big then it usually stands out there where i don't have to think about it right like there it isn't you know something worth thinking about but like if i if you ask me something i'm like yeah i think i'll take three days and it takes me four i don't go back and reevaluate man why did it take me a fourth day like right i don't send any brain cells on it like other than maybe like oh well i got distracted on one day because of a conference call or something like that. Like that, that's if it even happened to come across my mind, which it probably isn't going to, I'm probably not going to care about it. So I guess I should just go to Jay-Z for my estimates from now on. No, it's not, it's a curse. Every time I go to log time in a ticket, I'm like, oh man, I can't believe I had this thing for eight. I know I spent more time on that. And

like a lot of times, like if I have something that blows out like bad, like there's like a – you know, you almost kind of lose motivation sometimes. And you get kind of lost in the woods. And so, you're like, well, I said four. I spent ten. But two of that was just kind of like lost in the woods, like not really sure and really wasn't productive time. Do I log that or do i you know whatever or what ends up happening a lot of times like if i get stuck like that i'll end up like trying to make up the time or something later because i just don't feel productive that's a trap too because then you end up spending way

more time working and a lot of times that kind of lost time is valid work time it's because you didn't understand you had to talk to people but just it feels gross when you're like kind of in that weird spot where you're like oh i'm not at least for me like where i'm not typing so i feel like i shouldn't be counting that time but hold on let's let's tangent on that real quick because as as professional level developers i guess is a good way to put it how much time do you think that you actually, percentage of your day, how much time are you actually coding, typing on your keyboard? How much? 5%. 5%.

You outlaw? I mean, probably not 5%, at least here lately. Okay. Yeah. It generally is typical. I've been in a pretty, I've been pretty fortunate just like, you know, banging on the keyboard kind of mode here. Scratch the last two weeks uh yeah i mean yeah well even no because even then i was still banging on the keyboard it was just a different thing yeah i don't know i would say no more than 50 historically

for me like the thought of having a four-hour block of just coding like that's rare when you got meetings and other not a continuous block oh is that what you mean no i'm talking in a day so let's let's assume i know this is low for all of us but let's say an eight hour day right so if you said a 10 of an eight hour day um there's what 60 times eight is what's i'm definitely higher than 10 in that day there's Yeah. For me, like 5% was like just lately, the stuff I've been doing is like, I feel like I'm crafting magic spells and like all my time is just researching. And then at the end I come with three lines.

10% is just under an hour is basically what I'm getting at. So 10% of a day is an hour typing on a keyboard. I would say that I'm maybe, maybe, and this is way past an eight hour day, right? Because most of us find ourselves looking at the clock and going, oh my God, I need to walk away from this computer. I'm probably somewhere in a ballpark of an hour to an hour and a half a day. Yeah. But I mean, that's different though. I mean,

I could see that in your role where like you're, you spend a lot of time on calls. So a lot lot that's different, but even, even when I'm not on calls, like, you know, I'm deep in the Kafka world right now. A lot of the times I'm just spending time, you know, I'll, I'll spend five minutes writing some code and I'll spend the next 30 minutes just running it to see what happened there and there and there. I'm not actually writing any useful code. I, okay. Now now hold on now, because now you're talking about the execution of the code you wrote and you're not counting that as part of your coding. Like execution of the code that you wrote.

I mean, it sucks that yours happens to take 30 minutes in that scenario that you just described, but that counts as part of your time on keyboard, in my opinion. That's debugging at that point. I wasn't counting that. Yeah, I'm not counting that. I was counting like type typing. Typing, that's what I'm saying.

I could find myself, and I'm not even kidding, I can find myself committing my code at the end of the day and looking at it and going, I only changed 50 lines of code today? Well, now we're talking about like how fast you type, number one. Because like if I bang out like thousands of lines of code and I do it in like 10 minutes, then you're like, oh, but you only did it for 10 minutes. No, but I guess that's what I'm saying is like writing code and maybe typing is the wrong thing,

but how much code do you actually produce in a day? And that's where I'm saying like, I spend a lot of my time either on calls or understanding the business problem or how did that work? How did that work? I have to just change the same five lines 500 times throughout the day. Let me rephrase this then.

Okay, because at least in the way I'm thinking about this, because programming in my mind is not necessarily something that you can just quantify as like the number of lines of code you wrote in a day right there have definitely been days where i've spent two days programming and only changed five characters yeah because of some like obscure bug that you go hunting for you're like what in the world is going on and the thing that actually gets committed in the very end was the you know that very that very simple one line.

That one line. Now you might've written, you know, some, some debug statements here and there beforehand or whatever, uh, you know, or, or log statements or whatever, you know, or using like your console tools to, to insert, uh, uh, break points on the fly as you go. Right. To me, that still is all part of the programming package, man. I agree. The reason I called this out is because we have a lot of people that listen to the podcast

and they're people that want to be programmers or people that are getting into the game or whatever, right? And we've laughed about this and talked about it before. When you watch a movie, there's somebody hacking, right? They're on the computer just banging out code. You're like, man, that is a freaking lie. First off, they never even checked for errors. I guarantee you they forgot a semicolon or some sort of spacing, right?

But I guess that's what I'm getting at is I'm not saying that it's necessarily unproductive, but there are definitely times where at the end of the day, you're looking like I committed one line of code. I fixed this nasty, gnarly thing that should have never been a problem, but it took me 50 iterations and two whole days to get there. And it was for one thing that somebody missed. Right. That's kind of what I'm getting at is a lot of what you do is just understanding the problems and finding that one little bit of a solution to that problem. And a lot of it is not banging out code. A lot of it is, what does this do? Let me see how this flowed through the system or whatever.

Yeah. That's what I was thinking too. I'm definitely not going to beat myself up about that too, because even in like, you know, how we're kind of like banging out code, a lot of that code, like, do you really count it? Because a lot of that's just boilerplate stuff. Like, I don't care what your language or framework is, right? There's just a lot of like boilerplate stuff that you're going to do over and over that then by your standards here is like, well, should that count? Dude, honestly, boilerplate code, I hate with a passion.

I would rather spend a day writing the code that would generate that code than actually write that code. Oh, I didn't even mean it in that kind of regard. But I meant like, yeah, most of it's not that hard. You know, be it like a be it react or be it C sharp. Like, I don't care what it is. There's going to be parts of that that are going to be like repetitive from like one class to the next kind of scenario.

Totally. Yeah. And I will say you spend at least two hours a day thinking of what you're going to name your code. So, I mean, well, I mean,

that's the hardest part of our job. There's that. And if you're doing experimental type stuff, you can do a lot of retreading too. You like try something for it in the internet that doesn't work in your environment. Cause you got to do this. Then you got to go look up how to do that. And next thing you know, it's like three hours gone by and you're still looking at that same function yeah this episode is sponsored by

data dog a monitoring platform for cloud scale infrastructure and applications data dog 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 coding blocks to see how Datadog can provide real-time visibility into your application. Again, that was www.datadog.com slash coding blocks to sign up today. All right, so let's talk about estimating project schedules. So I guess this is kind of in line more

like you could think of your MS, the MS project example that I gave to like, you know, definitely at the larger project level, although I have used it at like the more micro level, it's spite its name. They didn't want to rename it to ms micro project though when i asked him um but yeah estimating large development projects is is even harder than estimating your own tickets that you get so this would definitely give jay-z some stress amen brother estimating projects stinks yeah even like side work freelancing stuff i stopped doing that a long time ago just because it stressed me out. Like the amount of anxiety I feel about it proportioned to the income just wasn't worth it for me. I know a lot of people do really well with it, but no thank you. I'm with you there.

It's funny, though. One of the things they call out here that I really agree with and I wish that it was this way more and more people accepted it is the best way to get a good estimate is to keep iterating on the project and keep revising that estimate. Right? Like this actually was something that we all had that we worked on at, at a previous engagement where, you know, we were asked for, do you guys remember this?

We were asked for estimates on this one security thing that we were doing and we get up and draw on boards and, and nine months would be thrown out there, and eight months, and seven months. And we'd do this every day for weeks, it felt like. And then finally, everybody was like, we're kind of tired of talking about this. We'll just start working on it,

and then we can come back with some better answers. Because trying to come up with that stuff out of thin air was like, we don't even know what we don't know yet. And as we got into the code, and as we got in and we started seeing the patterns that it could develop, it was like, hey, I think we can do this part in a couple months or in a few weeks or whatever. It does get tricky, though, because at some point there is a chicken and egg kind of problem here, right? Like you can't tell me how long it's going to take, but yet you want to start it, you know, to be able to tell me how long it's going to take so that you can refine your estimate as you go. And, you know, you might end up, it might end up, you keep going that process, right?

And every, every week that we meet, you're like, well, I think it's going to be, uh, you know, like in the beginning, you might be like, oh, it's going to be a year. And you're like, I don't want to hear a year. And you're like, well, you know what? I'll tell you what, let me get started and we'll see where we're going to go. Right. And then, you know, the next time we meet, you're like, ah, it's probably gonna be more like nine months, nine months. Really? And you're like, oh, I'll tell you what, like, give me a little bit more time. We'll see how we're going to go. Right. And then there might be some slippages in there. And then by the time you get to it, like maybe you were close to a year. And had you known that in the beginning, you might've been like, no, there's another way. Right. So it is, it is, it is weird to think

about it in that regard, but at the same time, like you don't know what you don't know. So how do you estimate it until you start on something? And a whole lot changes in the scope of a big project, a whole lot changes over that time span right that's that's the part to me that is the most frustrating i think back when this stuff was written back in that day i don't think that systems were moving as fast as they are now today you know you know what regard do you mean like i mean that clearly not bandwidth and cpu because obviously they're faster now. Well, every time you turn around, there's new frameworks, there's new software, there's new things to integrate with, there's new cloud services, there's new whatever, right?

Yeah, that was the same true back then. But it didn't feel like it was as fast. Oh, dude, it was really fast back then. You don't remember? Really? Seriously, honestly? Like what? you don't remember really you seriously honestly like what i mean i'm just remembering like every it seemed like back in the late 90s there was constantly something new coming out man so i'm thinking like aws and azure and stuff like they've got all these commoditized services now you can

browse anything you want to do you can find like three different cloud providers that do it software as a service that you can just integrate and like even like payment providers back in the 90s like if you were integrating like a payment processor like three weeks hold the phone you were reading every page of documentation now it's like stripe like oh here's your token here's your bank account now you take credit cards great so i think that the the pace of things has just kind of moved faster in in that side of the house and so things have totally changed in that way, but you're just expected to do more and more with it. Yeah. And I guess to that effect, like, like some of the other things that come into play nowadays too, are things that you didn't

necessarily think about as much back then. Not, not because it was, you know, okay that you didn't, but like security, right? Like, like nowadays security is a huge thing. Like, man, I was talking with somebody on, on Slack the other day, just about, you know, I've joked about, I start side projects all the time and I never get anywhere with them because inevitably I'll be like, well, I want to plug in some authentication. All right. Well, where do I store the keys? Well, okay. I get it. I could put it in Azure key vault. Well, where do I store the key to that thing? Well, um, you could use the developer tool that will allow you to put that in a config outside of it. But how do I, how do I secure that thing? Oh, you can't really, well, wait a second.

Like, and that's kind of what I'm getting at is, is there's just so many different pieces and things are moving so fast nowadays that it's kind of hard to keep up with it all. And, and, and to that point, when you have a six month long project, you know, you start off with Angular 2 and they're on Angular 4 now. And you're like, well, do we, do we bite the bullet and upgrade that? I mean, we've done it with the XDJS, right? Like we're in the middle of a release and it's like, oh, well, they just released it and it's got new features and it's also faster. I think that's just part of like. Today.

Maybe it's just more like web development, especially. Maybe. In my opinion, has always been fast moving, fast changing. Right. That might be true. And that goes with everything that goes into that world, right? We chose the hardest one, basically. It could be JavaScript frameworks that are constantly being introduced or changing,

or services that you can access over the internet that are constantly changing and new ones are popping up here and there. Yeah. Yeah. I mean mean it might be that and i actually didn't mean any disrespect people are doing stuff like c++ programming right it's just programming for the web is frustrating because there is so many moving pieces to it that are always changing the browsers that are locking down features you guys remember the poor man ajax request back in the day where you basically had a hidden iframe on a page and you'd throw posts to that thing and it would return something like you couldn't even do that today. A browser would block it. Like, so your app that you wrote 15 years ago, 10 years ago,

wouldn't even work. Right. So there's just constantly new stuff to learn. So I guess, I guess that's what I was getting at is, is it's hard to estimate a long-term project because not only are your requirements going to change as customers see it, which is good, you know, the tracer bullets, but so are the things that you're working with. Right. They're changing out from underneath you, and that is frustrating. Yeah. I mean, there was one point in here that we forgot to call out, or at least if we

did call it out, I apologize. But, you know, they're saying like the number one way to create estimates is to ask someone who's already done it before. Yeah. So, I mean, that applies even for like the large scale project, right? Like we were talking earlier about, you know, constructing a building, right? Well, if you've never constructed a building, then the first time I ask you, you might be like, well, man, it's probably gonna take me like five years to figure out how to do that. Right. Like, you don't know. Right. Right. But you know, if you talk to somebody, you know, who has done it before, he's like, oh, no, that, you know, depending on the size of that building, well, you know, three months, we'll have that thing done. Right. Yeah. I was gonna say, you you know back in back in the day like 15 20

i wasn't like 15 plus years ago i feel like um i did a lot more coding and i got a lot less done because there weren't like prescribed solutions to everything so when it came to like how are we going to store credit cards database how are we going to store users in the base there weren't like thousands of articles on like getting started how to store users how to do this what like here's how these services do it so it used to be like all right well i'm going to create a credit card table and i'm going to put them in there and i'm going to have a user table i'm going to put it in there so it was uh it was nice because you got to kind of experiment and try stuff out but it's bad in the sense that all that stuff was like garbage and terrible not secure and led to all sorts of problems so i definitely like how

things are better now but i do miss the days of just being able to go in and like what's the problem okay let me start typing here are my tables here's my whatever and so there's a lot more typing and yeah just a lot less done i think i agree with that i will also say though there is the double-edged sword of that now which is there are tons of articles out there and you'll land on one that looks great and it'll be wrong and you'll do it right. Like, oh, this is how you save a password. It's like, whoa, whoa, dude, that is wrong. And hopefully there's comments enabled on the page and everybody on the internet says, don't do this. But you know, it is sort of a double-edged sword, but you're right. There's a lot more plug and play type solutions nowadays.

And so many of those articles are kind of misleading too because uh the tutorials are well they'll take shortcuts they'll show you like the simplest thing like here's how you count letters and then you're like okay this is great this is simple i could do this and you go in there and you're like oh but i need to do this and that and the other and when you realize like that the tutorial doesn't cover that and the docs are kind of light on the area and yeah i mean sure you could probably do it but that's you know you're uncharted territory so it's right stinks they always show you the happy path even in demos on stage believe them a little and not tonight not tonight at my at my talk tonight right that that's totally believable different why i do it that's right uh they mentioned checking requirements uh i think that's a good idea that's definitely something i think uh the closer you can be to

the users the better the better relationship the more you can understand your domain the more that stuff is just going to flow easier totally otherwise telephone game uh analyzing the risk i definitely think about this too like the the times when I spend more time on my estimates and when I actually try to do a good job, I try to think of what could go wrong. What are the things I'm most scared of? What's most likely to go wrong in this project? And that turns out to work out for me. I just don't like thinking about it that way.

We got the designing, implementing, and integration time. I guess I don't really think about designing time i think a lot of times i'm like looking at the estimate for a smaller ticket you know not a six month kind of project but like if i'm trying to think like something's going to take like one to two days i kind of think of like my estimation process as part of the design phase where i'm going to kind of figure out like high level what i'm going to do and maybe drop a couple bullet points in the ticket. Yeah, I think I'd do the same. Well,

what version is... In what regards does design count here? Is this like UI design or is this like artistic design? Or is this just architecture? System design, I'd say. Yeah, like architecture. architecture yeah i've definitely

written down tickets that were like hey research how to do this or design but i always feel bad about this too because it seems like such a wishy-washy thing and you could always just kind of cut it off like all right well it's been one day and that's what i had on the estimate so i guess i'm done then they've got uh validating with the users. That's, again, just going back and making sure that what you've come up with makes sense to them. That's probably halfway important. I like that a lot. Yeah. Honestly, that saves more time than just about anything else.

I mean, it may sometimes be frustrating as you go back and forth and they keep changing what they're saying. But ultimately, it'll save a lot of problems in the long run. I'm constantly amazed at how often I'll say, let me repeat this to make sure I got it, and I'm totally sure that I've got it, and I say it, and they're like, no, this, that, the other change, this, that, we're going to be in that day where I had some boxes down, and I'm like, we're going to draw the lines between these boxes together just to make sure that I've got it, and I start drawing.

Oh, my God, an hour later, it totally doesn't look anything like i decided i was like okay well i'm glad we did that i guess sorry about that and then i lost the diagram oh did you really yeah dude i took a screenshot of it though because the because the app crashed. Oh, it was Gliffy, right? Yeah. It's always fun. This one, God, I love this one. Having to nail down a perfect estimation at the beginning before doing any iteration is a mistake. 100% agree. Just like what Outlaw said a little while ago. How do you know what you don't know?

You can't. So trying to be nailed down to an estimate by management or even another team member or anybody, right? Like, let's say that you're working with another team of people and they're waiting on an API that you're working on. Like, how can you tell them exactly when you're going to have it done if you haven't gotten in there and found out what you need to do yet? I've definitely had situations where I've had to explain to a project manager before. Like, you know how Joe said that, like, everything that you work on, you have something you haven't done. Yeah. Right. I've definitely had conversations with project manager where

they're like, well, how long is this going to take? And like, look, I've never done that. I don't know. I'm going to need a minute. You know, like, I don't know right now. I honestly don't know. But give me honestly don't know but give me 10 minutes i'll be back yeah you know one thing we didn't mention is uh t-shirt sizes i love t-shirt size oh that's my favorite way to estimate oh my gosh it's the best and so we basically you go in and you say it's like oh this is tiny or small or medium large extra large extra extra large oh takes out so much of the guesswork. It's really just the units, I guess, that really hung me up, hang me up.

I feel like I can look at a ticket with a high level of accuracy, tell you whether it's extra large or large. You know what? I treat the time like that. I basically just compartmentalized them, right? Like an extra small is four hours, a small is a day. That's how I got around that problem in my head for estimation is, compartmentalized them, right? Like an extra small is four hours, a small is a day. Like I, that's how I got around that problem in my head for estimation is, you know what, if it's worth working on, I'm going to put four hours on it because by the time I contact switch and change

all the code and put it to get and everything, I'll be in it at least two hours, right? So I don't mind doing that. And I think if you you can if you can make that fit in your mental model then you can basically do the same type thing right like a small three days large week extra large two weeks anything greater than that you guys are crazy you need to break it down a little bit further yeah you ever do that and then you look at your your co-workers tickets and they're like two hours two hours one hour two hours you're like oh crap no not at all i don't care at all we had a co-worker that that tended to do short estimates and they would knock stuff out they were awesome they would do stuff really quickly whenever i see their estimates i was like let me go take mine down

10 no no i don't feel that way i just don't look at other people's estimates. I just assume I work on harder problems. Yeah. I seen how you solve them problems. So I was about right. Oh, and, and the thing about nailing it down, why is it a problem?

Because it'd be a mistake. There's no way you're going to be able to nail down the right estimate on, on something that you haven't messed with at all. Well, specifically it'd be a guess. I think it'd be a mistake. There's no way you're going to be able to nail down the right estimate on, on something that you haven't messed with at all. Well, specifically it'd be a guess. It'd be a guess. Oh yeah. What did I say?

You said mistake. Oh, mistake. Yeah. It'd be a guess. Yeah. But that's why they're called guesstimates. Guestimates.

Exactly. You ever put a comment like super wild guess on this one? Oh, I'm sure I have. I think all of my estimates are super wild. Yeah. Well, most of mine are terrible,

but like ill-researched and wild guesses. But like there's sometimes when like I just I'll have a bunch of tickets to estimate. I really don't know. It's all going to be like, I don't know. All these are getting three days and I'm going to put a comment on each one saying wild guess. There's ballpark in here. Yeah, like you said, you said estimate these tickets by end of day and it's 4 o'clock right now. So... I just changed my username

to Michael Wildguess Outlaw. There you go. That way they know. So this next part's funny to me as they say, as you finish an iteration, you can use that to refine your project estimates and then you continue to do this and gain confidence with the estimates over time. Do you guys... You can't change estimates?

I was going to say, do you guys ever go and revise your estimates on tickets or anything? No. It's a commitment. Exactly. I said it'd take four days. It took me one. That's it. Done. But I think they're talking about future estimates. Not like, you wouldn't go back and

revise the estimate on something you've already worked on. I'd never gone back and looked at the future ones. Even it's just like, no, man, when I get it, I get it. Right. Like, um, Well, definitely future ones. I can definitely think of times where it's like, oh, you know, I thought that, I thought that that was going to be harder, but now that I already did this other section, I see that that was actually a lot, that one's going to be a lot easier. If they were bundled together in the same type Epic, then I might do that. But if it's just random tickets that are thrown in there that it might have had a similar context, I can't think of very many times I've ever gone back in and been like, you know what?

I think I can change that. Well, again, go back to the waterfall. Step back a year or two. Put yourself back in the mind frame set of this book, right? And you could definitely see there were times where in a waterfall kind of predicament where you might think, oh, that future thing that I have to do in a week or two is going to be a big task. But then as you start to knock out some of the things ahead of it, you're like, oh, it's actually going to be easier. Or, oh, it's actually going to be worse than we thought. So you would revise it in that case right again going back to that waterfall i've always revised up i don't think i've ever

revised down like yeah i never rise down do you yeah yeah i shouldn't one of these things i'll learn yeah there's there's times like well i'll also we're like i'll do some stuff i'll do some stuff i realized the way i broke these tickets out you know maybe i broke something up into five tasks like i've done most of the work for desk three or sorry four and five by the time i finished the first three and so they're like basically trivial by the time i get there yeah now i don't mind closing them like as soon as soon as i get to them like even if i knock it out and when i was working on something else i'll be like oh man i man, I actually fixed that thing. I'll close them. But I've never actually said, hey, let me go revise those things down because I always just kind of expect that something else is going to happen, right? It is cheating. It is cheating,

but that's fine. Yeah. Wait, how's it cheating? Not revising down. Oh, not revising down is cheating? Changing estimates, like commit estimates or commitment and the decisions are made upon. So if you start going and changing those estimates after the fact, unless those people are going through and readjusting those, you know, sprints or whatever, then things can get wacky. And I know that what I'm saying is ridiculous because that happens all the

time. They constantly refining and grooming and things are moving all the time and getting moved around. But that's just how I feel about it. Like, uh, I can't change it because someone made a decision based on this. Oh,

I don't think about it like that. I just, I just have to be wrong and surprise them. I don't know, man. Like, like I said earlier, I keep,

now that I have my head in the waterfall, as I, as I read this section, then absolutely you would revise estimates and it would not be cheating to revise them for future work. Not for work you've already done, but for future work. Based off of the things that you've learned, you could revise them up or down. Yeah, I always revise up, never down.

I would say it's absolutely the right thing to do and I don't think there's a valid argument for not revising your estimates. I also think it's absolutely the right thing to do. And I don't think there's a valid argument for not revising your estimates. I also think it's cheating. I don't get the cheating part. It's not cheating. It's totally not cheating. You're supposed to be right the first time. Yeah, but you might get better information, though.

Like, you might have thought that some effort was going to take, like, a week. And then you realize, like, oh, you know what? It's only going to take a couple days. And now you can relay that information to your customer, whoever that might be, Some effort was going to take like a week and then you realize like, oh, you know what? It's only going to take a couple of days. And now you can relay that information to your customer, whoever that might be, be it an internal customer like your boss or a paying external client, you know, and they're going to be all the happier, right? To get that information. Oh, yeah, you're totally right. But it's cheating.

But it's not. All right. So what do we got for tip 19? Breaking the law. Tip 19 is it's cheating but it's not all right so what we got for tip 19 breaking the law tip 19 is it's not cheating uh iterate the schedule with the code c yep i agree that's what you should do i forgot about that tip you should be in in constant communication and letting people know, hey, found this. This is good. We're on target. We're not on target. We might be ahead of plan, whatever.

Yeah, and communicating, depending on the situation with a third party especially, like if you're providing work with someone, you can absolutely over-communicate. And things can get weird if you're constantly like, oh, no, we ran into a problem. It's all going to die. Oh, actually, it're constantly like oh no we ran into a problem it's all gonna die oh actually it's fine oh we ran into another problem it could be you you want to smooth that stuff out a lot of times and it's bad because sometimes you can feel like you're not letting them know something important and sometimes it's good because things end up working out okay and things like some pm will save the day like kind of framing something in a certain way well put another way you don't want the only communications to be the peaks and valleys right yeah it's it's like dollar cost averaging on on investments right it will smooth out over time don't bring

up every little thing that happens right it's part of development um usually a lot of times over communicating is a good thing like you want to have that stuff you're kind of got your butt covered i think when you're dealing with third parties, sometimes it can be a problem. If you've ever worked with someone that kind of rang the bell a little too early or kind of got kind of overreacted sometimes in certain situations, then it can be really awkward to kind of walk that back if things turn out okay. That's totally true. So, what is the most important thing that you should say? What is the answer that you should say? What is the answer that you should say when asked for an estimate? It depends. I'll get back to you. There you go.

Yeah. That's the real answer. I'll get back to you. That is honestly the best one. It should be almost all the time because if you give some sort of answer up front, then you probably haven't thought about it that much. Yeah. There's lots of times where I think I know the answer and then it's just like sleep on it. Always take a little bit longer to write it up because you might feel differently when you kind of get back and like get out of the moment. Any estimate that you just shoot from the hip and give, like if you haven't thought through that problem, that estimate is going to come back to bite you. It's going to haunt you. No question.

Yep. Were there challenges for this section? I don't know. I didn't put the challenges in. There was. So here, there was one challenge and it was to start keeping a log of your estimates for each, track how accurate you turned out to be. And if your error is greater than 50%, try to find where your estimate went wrong. It sounds like Joe already does this. That is a challenge. I can't do that. Yeah. Yeah. I vlog myself at the end of every day. All right. Well, with that, we have now reached the end of that section of the book. Uh, how far are we? I don't know. Chapter two. Yeah. We have now reached the end of that section of the book.

How far are we? I don't know. Chapter two. Yeah. We're about a third of the way through it right now. Finished chapter two. Yeah. We'll have some resources we like, which will clearly be the pragmatic programmer.

And with that, we head into Alan's favorite portion of the show. It's the tip of the week. Yeah, baby. And I'm going first. I got two tips courtesy of the mad fucking God. The first one, I think, I think Allah,

you saw this. I don't know if Alan did. I didn't know. Oh, I did. Okay. So Alan, if you got a computer near you, try doing this in the command line.

Curl parrot.live. you got a computer near you try doing this in the command line curl parrot dot live now it'll work better in bash but you can do it oh that's amazing i'm in terminal i'm in terminal on a mac yep okay yeah so yeah curl parrot dot live how do they do that uh i don't know i don't know either but i like it yeah you must do this cool dos is a little weird it kind of gets stuck but it's still cool it's gonna be i don't know how to do it it's all open source and you can do it i just thought it was neat so i had to share that that's really i just imagine it's just uh scrolling lines right is it no uh oh yeah yeah very much scroll up in your terminal and you'll see it you'll see that you'll see the thumb move it's just like a page i've seen stuff like with the end cursors where you can kind of like rewrite and do stuff

even with a windows uh command you can like do carriage return to go back to the beginning of the line do weird stuff like yeah but i don't really mess around too much this is delivering like a page of text that's whatever the size of your console is at a time yep so like you're streaming that whole thing at a time that's really cool that's ridiculous that's awesome so that's really cool and the other is the octolinker so if you go to octolinker.now.sh this is a chrome plugin that you can use that will make uh it kind of recognizes patterns and common like files it will make them linkable so if you go to like a node.js page in our node.js file in github then you'll be able to click on those imports and it will take you to that encode and so we'll say okay you can kind of link from this

file to that file rather than you having to kind of browse around and navigate in that repository. Oh, you know what? Will Madison had given us some sort of thing like this back in the day for GitHub. Yeah, it added a tree to the left-hand side. That was from Critner. Yep. I have that too, actually. I forget what that was called, though. Yeah, I can't remember it either. That's really cool. I have that too actually I forgot what that was called though Yeah I can't remember it either That's really cool I have a lot of plugins

I'm sure if I were to search GitHub On Codingbox I might find like Only you know one or two Links for it so It'll probably come up real quick So very nice tips there MadVikingGod aka JoeZak Very nice tips there, Mad Viking God, a.k.a. Joe Zach.

Very nice. That's Aaron. Yes, that's Aaron. Does that mean that nobody can bash Joe for his tips this week then? Is that pun? That's right. Nobody can bash Joe for his tips? Oh, yeah. That's pretty good.

Two tips, that's right. That's right. Hey, I got more. So, the first one is I came across this the other day. Don't even remember what I was looking for. But Microsoft just released a new extension for Visual Studio that's really cool. Now, I'm going to preface it with I tried it today. Didn't get it to work completely the way I thought it was going to work,

but I think it's supposed to. So now who's giving out the crappy tips. Yeah. Yeah. So here's your tip that doesn't work. Yeah. Yeah. So, but here's what it is. It's called the visual studio pull request extension. So here's, what's really cool about it. If it works exactly the way it is, I actually need to go back and watch the video to find out exactly how to do it. But you can open up a pull request in Visual Studio. So one of my biggest problems I've always had is somebody sends me a pull request. They're like, hey, look at this. I'm like, okay, that's great. I have no idea what the context is because I can't navigate any of this code, right? Like I'm just seeing these lines you changed here and I have no idea what they mean. So you can open up the pull request in visual studio. It'll pull up the diffs in visual studio. And apparently there's a way to do code navigation. Now, this is what I couldn't get to

work today, but also admittedly, I was just trying to hit F12 on something and that's all, and it wouldn't go to it. So they show that it can do it. I just need to take the time to do it. So at any rate, I think this is really cool. If it integrates super well, this could be just a massive productivity boost and actually allow you to do a pull request properly by seeing the context of how things changed. Now, you should call out that this is specific to Visual Studio 2019. 2019, yes. You should be on that anyways.

Oh, yeah. So the next thing is I have a link also. And on this page, it's more about it. But they have a YouTube video where they actually show all the functionality. And that's when I first found out about this thing. So I highly recommend going in there and taking a look at that because it will show you how the thing works and it's really cool. And then the next ones are both, I I've, I've mentioned con emulator before. Conomoo is, is what it's called, but it's the

console emulator from windows that I use and command. I actually dog on it. It's not condom. It's commander that I use CMD ER. Um, they have a really cool feature that I've started using a lot to where you can split the windows very much like, you know, in, in windows, you can do like a windows in the arrow key to the left or the right to, to split your window to half of the right side of the screen or half to the left or whatever. You can do something similar to that in Commander. And what's really cool is you can just keep splitting windows and I'll have like four or five command consoles stacked on top of each other and maybe even a couple over to the left and you can just keep doing this, right? That's awesome. If you're doing like, I've been doing a lot of Kafka stream stuff and I want to

see as things hit the different areas of my pipeline. And so I can have a thing that's just watching particular topics and I can see as they pop into each of these. Really awesome. Well, the other thing that Commander has is you can right click on a tab or the settings for a console. You go to edit and you say reset terminal and it'll clear it. So it's like doing a control L if you're in like a bash type thing or a CLS if you're in windows. But let's say that you're tailing a log or something and you just want it to clear so that you'll just be able to focus on the next thing that comes in from the log. Well, that can be frustrating because you can't control L, you can't CLS because the thing's

running an active tail command. So you could right click and say, edit and reset, or you can go and set a hotkey, which is what I ended up doing. And you can click on that one thing, do your hotkey and it'll reset the terminal, clear it so that you can be back to a clean slate. So just really nice, useful things that you can do if you're using Commander and Windows. All right. So how about some more Visual Studio tips? I didn't realize that they were going to be so popular tonight, or I wouldn't have picked it. All right. So I think we've talked about this one before, but I thought, well, I'll call it out at the same time with it. So if you're in Visual Studio, you could type control plus the semicolon key, and that'll take you up to your Solution Explorer's search capability. And so you can start typing in there to search for a file or a method, right? And the one caveat to the way that search works is that if you

include any uppercase letter, then the search will assume that everything else is case sensitive too, right? But if you leave everything lowercase, then it'll assume a case insensitive search and it'll search everything. So it's a really cool way. Like if you know that like, Hey, I think there's this method or, you know, this file or whatever, so you can find it. You can do this search in your solution explorer, which is really helpful in large projects, but there's also the ability to navigate straight to a file. So I've always found it like a little bit more, uh, like, I guess like convoluted, like the, the way to get to it in, in visual studio versus visual studio code, like visual studio code just feels a little bit more natural, but, uh, or even like even web storm, for example,

was better, but in visual studio, if you want to like navigate straight to a file, you can press control plus shift plus T and it'll take you to the file. And I think the reason why I always hated that is because I'm like, why T? Right. Why not F? Yeah. That seems like it would be the natural pick, right? Or, or maybe like N for navigating, which man, it's been so long since I've used WebStorm. I want to say it was something like a Control-N in WebStorm to navigate to the file. And I think if I remember right in Visual Studio, it's like Command-P or Control-P to navigate to a file, which is also a little bit weird. But T. Yeah.

Where did the T come from? Oh, my. Yeah. So, at any rate. So, control shift T. There you go. Very nice. You know, I've been coding some C Sharp and VS Code lately on Windows.

And I got to say, I'm getting used to it. It's still, you know, I've got years of muscle memory and kind of habits built in. So, sometimes I kind of feel a little frustrated. But it's been really nice. I can't really complain about it, but you're doing a.net core then. Yeah. Okay. Yeah. Cause a.net wouldn't work so well in there. Would it work? Oh yeah. Well, I mean, give it a year. Good point. Cool. All right. Well, in this particular episode we we hit a couple of tips here program closer to the problem domain and estimate to avoid surprises so that was most of the show yep and so with that we say uh hey subscribe to us on itunes spotify stitcher and more using your

favorite podcast app and if you haven't already, like Alan mentioned earlier, we do greatly appreciate it. So you can find some helpful links to leave us a review at www.codingbox.net slash review. Yep. And while you're up there, go ahead and check out our show notes, copious show notes, examples, discussions, and more. And check out the best dev programming slack in all of existence by going to codingbox.net slash slack and join in with all

of the awesome people that are there and are much smarter and more interesting than I am. Not that I feel, you know, threatened or anything. Awkward. We're on Twitter at Codingbox.