Coding Blocks - The Pragmatic Programmer – How to Build Pragmatic Teams

Episode Date: September 3, 2019

We learn how to apply the concepts of The Pragmatic Programmer to teams while Michael uses his advertisement voice, Joe has a list, and Allen doesn't want anyone up in his Wheaties.

You're listening to Coding Blocks, episode 114. Subscribe to us and leave us a review on iTunes, Spotify, Stitcher, and more using your favorite podcast app. And send your feedback, questions, and rants to comments at codingblocks.net. Wait, how are you going to skip that? Visit us at codingblocks.net where you can find our show notes, examples, discussions, and more. And follow us on Twitter at codingblocks or head to www.codingblocks.net.

Find all our social links there at the top of the page. That's Joe Zack, who decided to flip the script today. I'm Alan Underwood. And I'm Michael Outlaw. And Joe, you want to say your voice so people know who you are? No, he doesn't. All right, cool. Hi, I'm Joe Zack.

I'm Joe Zack. Yep, you got it. All right, cool. Hi, I'm Joe Zack. I'm Joe Zack. Yep, you got it. Nailed it. This episode is sponsored by Datadog, the monitoring platform for cloud-scale infrastructure and applications. And the O'Reilly Velocity Conference. Get expert insight on building and maintaining your cloud native systems. And educative.io.

Level up your coding skills quickly and efficiently, whether you're just starting, preparing for an interview, or just looking to grow your skill set. All right. And in this episode, we're going to wrap up this series on the pragmatic programmer. And this time we are going to be talking about pragmatic teams. So with that, as we like to do, let's go ahead and jump into the podcast news. And Joe,

I think you've got some stuff to share with us. Yeah. Um, so let's start off by saying big thanks to the iTunes reviews. Thank you very much. Simply manual. Eric shins is strong. Let me repeat that. Eric shin is strong. Let me repeat that.

Eric Shin is strong and dub, dub HG 10. I wonder if that means he expects you to kick him whenever you, when you meet. Oh no, I hope not. I'm more of a kid kind of guy. All right.

And we have on Stitcher. Awesome with Lawson. Uh, Glenn Moyes, Simply Manuel. Yes. Let's see. Is that misspelled? Codes for Coffee, but that doesn't look like you spelled it correctly. Red Peril, T. Gibson, and Letrous Cthulhu. Wow, you said it right this time. It's awesome.

Thanks for the, thanks for doing this again. Letras. Oh, that's amazing. Yeah. Yeah. We met him at, uh,

Alan's, uh, talk, uh, Kafka talk. Yeah, that's right. And for the record,

it's Kafka. What did I say? Kafka. Sorry. Dang it. Proper nouns. You got all the names right here, but that's good. And so coming up, speaking of my Kafka slash Kafka talk,

Atlantic Code Camp 2019, Joe and myself will be doing some presentations there, and Mike is going to be doing some meet and greet. That is, is it September 14th, man? I really should have checked that before I did this. Oh yeah. That's a,

I don't know. Right. I think it's, you know, I just come on down to Atlanta and we'll figure it out. Yep. September 14th. So show up.

Um, we'll probably do another drawing. So if you sign up with us at the booth, we'll probably have another drawing last time. What we gave away a $100 Amazon gift card. So come by and see us. Yeah. Yeah, and what are you talking about, Alan?

What do you mean? Oh, I'll be talking about Kafka and Kafka Streams. Yes, Kafka Streams. Very nice. Yes, so some KSQL. And I might even throw in some Java or maybe Kotlin version of a Streams app just to show how they differ.

I'm pretty sure it's pronounced Kafka out in Long Island. So I was pronouncing it correctly. It just depends on where you're from. Fair enough. Regional. Regional pronunciations. And I'm going to be talking about Jamstack. And this is probably going to be your last chance to hear me talk about Jamstack because

I've done this one a few times and I am pretty sick of it. Kind of over it. You know, I mean, you should still go if you're in Atlanta region. It's going to be awesome. Yeah, definitely. Man, I swear, I almost put in a talk for Kubernetes as well, but it was like, man, that means I'm going to be forced to have to make something work

before then. So, yeah, I didn't. Yeah. And speaking of front-end type stuff i wouldn't mention that i was on the back-end bear podcast but i kind of flipped the script on him it's a great show you should go check it out especially if you like back-end type stuff and uh the guy marco is awesome but i kind of flipped the script on him and i talked to him a lot about kind of front-end envy and kind of just talking a little bit about how front end and backend technologies have kind of been,

um, evolving and what that means for front end and backend work. And so I thought it came out really gross. Great. It was a great show. So you should go check it out at backend bear.com. Hey, uh,

I don't know. Were we going to do a book giveaway on this one? Cause I guess, Oh, I guess we're now we are out of do it. Cause I just mentioned it. Yeah. I guess that's done.

So, you know, you're welcome, guys. And you can leave a comment on this episode. You'll be able to find it at www.codingblocks.net slash episode 114. And you can

leave a comment there for your chance to win. And from our last episode, Jordan wrote in, and I guess I'm never aware of this. I don't know if you guys have ever noticed, but he says I have an advertisement voice. You do. And he wants to hear me do the entire episode in my advertisement voice. So I guess it would go something like this.

I hope everybody's ready for this. Now that we're done with our itunes reviews i feel like i'm trying to do like a if like what was his name walter uh cronkite cronkite it sounds like it's it almost sounds like i'm trying to like trying to do the regular show in a quote an advertisement voice i want to say announcer voice but an advertisement voice almost makes it sound like i'm trying to do a Walter Conkright impersonation. Yep. That's all good.

If you want to try and do it the entire show, it will be somewhat entertaining, somewhat irritating, entertaining and somewhat irritating, you know, whatever. Hey, also I want to point out,

like we always say, you can go to coding blocks.net slash episode one 13, but in your podcast player as well, it's worth mentioning. If you swipe over to codingblocks.net slash episode 113. But in your podcast player as well, it's worth mentioning if you swipe over to the show notes, we have a link to the episode directly from the show notes so you don't have to remember what to type in or anything. So definitely check that out in your podcast player as well. And just to be super clear, because you said swipe over,

so if you're on iOS, it's swipe up. Oh, okay. Interesting. Yeah, if you're on Pocket Cast, know it's it used to be swiped to the right um but yeah at any rate in most of these pod catcher apps you will be able to see you'll be able to see the full show notes on the page but if you want to go up there and do the survey or anything just click the link it'll take you up there and you can do it so just swipe some direction until you figure it out yes how's that swipe all over the place all right now that we've got that out of the way, I just thought we never mentioned it. And, you know, the show notes, you know, you do a ton of work getting these together.

We put a lot of effort into making sure that these are pretty. So, you know, anyways. Yes, we do. And now with that, we will head into the next portion of our show as we start to wrap up our, or actually, no, we'd be finishing our wrap-up of the Pragmatic Programmer as we talk about pragmatic teams. Part one. Oh my god.

I'm not going to be able to pull that off the entire episode. Alright, so I thought that I, you know, we each picked a chapter right and we did the the chapters that you guys picked in the last episode uh and this was the one that i picked and i thought that this would be a pretty good summary you know summation of the entire series here so far so basically we're going to take a lot of the the wisdom that we've already gained from this book and we're going to distill it to see like can we apply this to a team, right? So, working on a pragmatic team has its advantages, and the advantages of practicing the methods of the book are going to be multiplied many times over when you take it to a

team. So, it's great for an individual, but if you're just one person on the team that's trying to, you know, do the right thing, right. And other people, maybe they don't know. I'm not saying that it's like malice or anything like that, but you know, there's only so much you as an individual can do, but combined, right. Like the, the, what's that saying? Like the strength in numbers. Well, that's one, but there's many, there's many things like that one, but yeah, that, that one will fit the... Strength in numbers? Well, that's one. But there's many sayings like that one. But yeah, that one will fit the purpose just fine. So yeah, so these are just a starting point, though. The authors make a point of mentioning that this is just a starting point.

And that pragmatic teams, they need to take some of these lessons and evolve them and adapt them and refine them to the practices that are going to best fit their environment. And so we'll start with the no broken windows. So a lot of these are going to be like revisiting things that we've already discussed, but applying it to the team, right? So in the no broken windows section, if you recall, that was where you're not going to let, you as an individual, you aren't going to let something go, right? You see that something needs to be refactored or corrected or, oh, there's a bug there. And rather than saying like, well, it's not my job, right? Rather than taking that kind of approach, you're going to do something about it, right?

Well, on a pragmatic team, everyone needs to take that same approach, right? Like you can't be the only one that's going, like we've mentioned the Boy Scout principle from the past, right? You know, like it really becomes a matter of everyone needs to take that type of approach to where if they see that something needs to be refactored or fixed or whatever, that they care about the quality of it and they take a moment to go ahead and fix that. And as a whole, pragmatic teams will not and cannot accept broken windows. Okay. So I'm going to ask probably the obvious question here is how do you,

how do you make that happen? It's, it's easy to take that upon yourself, right? Like I have, I have my answer. I think that I know. Okay. Okay. And it's going to sound super cliche, but you lead by example okay so if you do it and you just talk to people and like and they hey why did you even touch that piece of code i didn't think that's what you're working on like i found a bug right like i said i found something that needed to be corrected or you know hey why did you refactor that because it needed to be done okay what about you joe uh my answer is automation and stopping that stuff early. So if you can get like a linter

or some sort of test or something that getting the ball rolling on those guys makes it really hard to break those patterns later. But I've been breaking a lot of windows lately, so you shouldn't be asking me. Well, the reason I ask is, I mean,

we all know, if you're listening to this podcast or, you know, the three of us, we care about what we do a lot, right? That's the reason why we listen to podcasts, why we read books, why we watch videos, why we're constantly trying to better ourselves, right? Like we want to do a good job on what we do. There are some people that it's a job, right? It's an eight to five. It's a nine to five. They come in, they do this stuff. They want to get paid. They want to go home. Those people don't care about it, right? Like, Hey, uh, you know, I'm fixing this. Hey, don't touch that. It's not my, I don't care about that. It's not mine. Right. Or, or they're doing something in their side and they don't care about patterns

because they're just trying to get the job done. How do you – or do you? Like how do you get that culture and get that ball rolling in a way that everybody gets on board? Or is it something to where if they're not on board, then you figure out ways to fix it, right? Like I don't know. I'm curious so basically you're describing like a situation where you want to reward good behavior so the people that are doing that you know but if somebody honestly just doesn't care about that reward you're not going to be able to reward them in any way enough to where they're going to care so then what do you do it's kind of what i think you're getting

yeah you have somebody that just does not care to be, um, no broken windows, right? Like they don't mind putting in code this garbage because it, and take, when I say garbage, I mean,

they're not caring about the maintainability or anything like that of the code, right? It's just, Hey, I got this ticket. I closed the ticket. Done.

We'll put another way. Maybe it's that they aren't, they don't care. I hate to even say care closed the ticket. Done. Well, put another way. Maybe it's that they don't care. I hate to even say care. Different priorities. Yeah, they're not as mindful about the implications of what they're doing. They closed the ticket. They got that problem solved. Doesn't matter that it's going to be a pain to refactor later when they have to solve that same problem in eight other places, right?

There's very little thought put into it. It's just, hey, I got this thing done. That's my job. I had to close the ticket. It's closed. You know what I mean? And let's be completely honest. We've all worked with people like that.

Just about anywhere you've ever been. There are plenty of people that, Hey, it's my job to get stuff done. I don't really care how I do it. How I do it. I don't want you to question me about how I do it. This is what I'm going to do. Well, that's where I come in. I wasn't kidding when I said I've been breaking some windows lately, but it's because I've got different priorities. So what I was doing is basically doing some translation and it effectively ends up being kind of a lot

almost like data entry type work. And so I've written some scripts and some various things around it, but they're tricky. They're really not meant to be shared or reused because they're just kind of helping me through a task because I don't care so much about the maintainability about this right now because I just need to get some stuff translated over and then I don't have to worry about those tools I use to translate hopefully ever again. And so it doesn't matter to me if you have to run the scripts in this order or else you have to start over. It doesn't, I don't care that much because right now I'm the only person running those and i still have some things kind of like logged in a wiki or kind of checked in because i want to have some history of that while i'm

working on it but i'm hoping i'm betting that this stuff is going to disappear it's scaffolding for me well that's different sometimes it ends up yeah getting you know sticking around and sometimes you know it's going to stick around when you're doing that stuff, which is not so bueno. But there was a quote that was kind of like to your point about the automation that you mentioned, Joe. There was a quote in here that it appeared just before this section where it was like the preface to the rest of the chapter. And it says the single most important factor in making project level activities work consistently and reliability is to automate your procedures, right? Which is kind of like what you're describing. So even in your case where you're saying like, okay, fine, I'm going to have these scripts and maybe they aren't perfect, but you know, cause you have to run them in specific order. So there's like some implicit dependencies

there, but I mean like, you know, you're kind of automating what you're doing in that. So, you know, I don't know if I would count what I heard as the broken windows that we're necessarily talking about. Right. But it's definitely taking longer than I want to. Yeah. I mean, yours isn't a shared code base right now. Yours is, you know, I need to get some stuff done. I've written my own scripts.

But, yeah, I mean, I guess my point is I agree, by the way. I think leading by example is huge because if you get enough people doing it, then it almost creates like a Game of Thrones shame type moment, right? Like people don't want to be the ones making that walk of shame, you know? So I like that because it encourages everybody to start doing things better. But I think there are situations where this is kind of a tough, a tough one, right? Because not everybody has the same desire to, to be the best at what they're doing. Like regardless of what it is,

whether, you know, whether it's programming or anything else, sometimes to most people, good enough is good enough. And that's it. Well, that's going to make the rest of this section disappointing.

All right. So that's out of the the rest of this section disappointing. All right. So that's out of the way. I'll never mention it again. But I think the next part to talk about that boiled frogs and stone soup is kind of – the original sections were about addressing that kind of problem and how do you institute change with a group of people. And that's where we kind of talked a little bit about with like stone soup. It was like kind of lead by example. Like, hey, let's go ahead and get this ball rolling and everyone hop on and boiling of frogs was kind of the other approach where you're basically um you know

kind of gaslighting someone or gaslighting your team where you're kind of um tricking them by slowly integrating the things that you think are right until the next thing you know they're uh too far in to be able to back out and we talked a little bit about like you know whether those things were manipulative or good or bad but it was cool to see this addressed from more of a team perspective. Yeah. I mean, they, they call out that it's easy enough as an individual to overlook the big picture, right. And, and to get caught in the heat of that project's development and get boiled. But, um, you know, they call out that it's even easier for teams to do that, right. To, to overlook the big picture. And I'm sure we've all been in those environments where

like, you know, uh, you know, maybe you're whatever your next big feature is. Right. And that's, that's whatever that thing is. That's what everyone on the team is focused on. Not necessarily what really might matter is like, well, is this thing selling right to do the cut or the customer is really asking for this, right? Like, cause those are the kind of big picture things, but we get focused on like, can we do this? Not necessarily should we do this? Right. Yeah, I could see that. And then that's kind of management's job or,

or whoever's pushing the project's job to kind of let everybody know what the bigger picture is, right? To keep that frame of mind in the right place, I think. Okay, yeah, I would agree with that. But, I mean, we've been on several teams where that hasn't been – you have your regular meetings, and it's been more focused on can we do this? How do we do this? And little to no conversation about, you know, should we do it? Right.

Or like, how does this fit into the big picture? It doesn't matter kind of situations, right? So it is super easy for the teams to be focused on that just because we get caught up in the minutiae of just trying to get the things and the gears moving. Yep. All right, so moving on. They call out that it can also be easy for the teams to assume that somebody else is going to address a problem or a bug or a feature or whatever. So, you know, you might see something and just like, oh, okay, don't worry about it. Alan's going to cover that or Joe's going to cover that. So, or, you know, if I see a PR come in, if Joe says, hey, here's a pull request, and I look at it and I'm like, well, I don't know why

he would make that environmental change, but I'm going to assume that it was approved, right? Otherwise, why would Joe do it? Right? well, I don't know why he would make that environmental change, but I'm going to assume that it was approved, right? Otherwise, why would Joe do it? Right. Right? Yeah, I think some of this ties back to the kind of no broken windows. Like if there was only the one bug that you saw, then you would probably ask about it. But if it's like the 10th or 11th one you've seen this week or like the thing is constantly busted,

you're always having to kind of bang your thing back into shape before you work on it. And at some point you're like, ah, somebody probably is already working on it because there probably is somebody working on it because people have been doing things making a lot of changes making a lot of breaking stuff in the meantime and same with the environmental changes like if you're checking in screwy stuff all the time at some point your coworkers are going to stop asking about it and they're just going to assume that it's for

some reason and they don't want to argue about it but if you've kind of been taking care of things if everyone's been doing this scouting rule and the windows aren't broken, then when that fishy stuff starts to sneak in, it's easier to say no. Yeah, I'd also say, too, like things are probably a little bit different now versus when this book was written because you have ticketing systems like Jira or if you're using, you know, Azure DevOps for your, your code storage and all that, there's, you know, ticketing systems built into that. So it's a whole

lot easier now to sort of assign these things out instead of making assumptions. I would think like, I mean, when this book was written a few years ago, you know, those things weren't quite as easy to get ahold of, but it's still easy. It's still easy to think that like, Oh, there's probably already a ticket for that. So I don't need to create it. That's a good point. So, so it can still happen. And like even these environmental changes that we're talking about, it doesn't necessarily have to be like a hardware or a configuration type of environmental change. It could be something as simple as like you brought in a new technology, right? Like maybe you bring in some new library that, you know, might have other ramifications, right? So, you know, like, I don't know, I'm trying to think like,

what would be a good one? You have one right here. Well, yeah, I mean, okay, so I wrote down, but then I was thinking about like, this wouldn't be crazy. But like, you know, if you had an, like, this is kind of an extreme example to prove the point but like if you know if your app was an angular app uh you know and somebody were bringing you know a react portion right like oh yeah sure no it's probably okay if we use react for this portion of the application like is it or even if like technically it might work if you wanted to boil it back you might even say something like oh we're just going to use web components here. Well, not every single browser supports that. So is that

going to work out well? Yeah. There must be a time when Outlaw busted me for using a language feature of JavaScript that I shouldn't because it wasn't supported by a browser. Do you remember this? And I was like, yeah, well, we got a transpilot that takes care of that stuff. But you pointed out that

if I had just used a framework that we already had to kind of sit around, it actually had a better fallback plan and better support for the browsers. And so there was really no reason to not go with another solution than the cool new thing I was trying to do. I want to say it was related to promises. Yeah, it was related to promises. ES 2015 type feature. Yeah, and the way I wanted to do it, admittedly, was much cooler. But I think everyone agreed that it was like super cool. But unfortunately, it just wasn't as well supported.

And it just wasn't the right solution for that problem. And so it was nice to have that pair of eyeballs. And if my code wasn't so amazing all the time, I probably wouldn't have noticed when I snuck a little bit of dirt in. So I got lucky there because of all the hard work and amazing stuff I check in all the time. I'll probably wouldn't have noticed when I snuck a little bit of dirt in. So I got lucky there because of all the hard work and amazing stuff. I check in all the time. That's awesome. I like the humble brag that he like goes along with it. I think that's the first time he's not done a self deprecating thing.

So yeah, I flipped the script on you. I said the thing about the broken, breaking the windows earlier. So I was like, you know what? I'm about to make myself from the other what? I'm about to make myself. Let me try this from the other side.

Yeah, I'm going to make myself. Awesome. All right. Well, yeah. So, I mean, kind of to Joe's point, though, is that the authors say that everyone should be on the lookout for changes to the environment, right? So if you see new libraries that are coming in, like, why? Did those really need to be done? Were they necessary?

Or are there going to be other ramifications that you need to worry about? Maybe all of your application is a.NET Core app, and somebody decides to bring in a.NET Framework app, or I'm sorry, a.NET Framework library. Wait a minute. Why? Was there not a.NET Core version? And did they bring in everything that was necessary

to make sure that that's going to work in all the situations? Because that one specifically can get hairy, right? You're about to lose some time. Yeah. Yeah. I mean, it's fine that it worked on their machine, right? Sure. Well, let's assume that they compiled it and it worked on their machine.

Sometimes that's an assumption, too. Yeah. All right. That's not an assumption anybody should make, by the way. So the author suggests appointing a chief water tester to monitor scope creep, timelines, and environments. Anything that wasn't originally agreed upon, that's what this person would

watch for. That sounds like a product manager to me. Yeah, I was kind of wondering, like, what if we did, like, a buddy system? It'd be kind of nice to have a couple water testers, and even if, like, you could ask sometimes, like, hey, did I go off the rails on this one or am I heading off a cliff?

Like, just tell me yes and I'll stop right now. I don't think that, I don't agree on the product part because typically when I think of product manager, like they're not, I don't think of product managers as being into the code. But the scope creep, right? And the timelines. Yeah, but we're not talking about that though.

We're talking about like things that changes that could be to the environment too though right so so scope creep and timelines are part of that right but changes to the environment like we were talking about with the libraries like yeah they won't care about they're not gonna they're not gonna know or care yeah yeah i suppose i don't want that job yeah i kind of feel bad for anyone that does have that job because like it kind of puts them in the position of kind of slapping people with the ruler. And I guess there are some people that would probably like that. And so, you know, maybe it's okay.

I just kind of like the idea of having more of a kind of buddy or small pod system where you can kind of have those lifelines where you can kind of have somebody that you work with that you kind of trust if you work on a team. And you can kind of say like hey did i am i just doing this wrong and like i i added this thing i don't know if it's right or i saw somebody else added this thing am i the only one that thinks this is crazy and it's nice to at least have you know two crazy people or you know hoping that hopefully that at least one of these people will be able to kind of average out so two heads two heads are better than one. Yeah. I like that. I think for me, like one of the things that I've always said about development in general, that I think is exciting for most developers is the creativity, right? So it's like you said, I don't necessarily

think having somebody there with like a ruler, this could be slapping somebody on the hand every time they go past a boundary is necessarily the right thing because then it kills the the creative freedom that a developer needs in order to write something good so i don't know i i think it's a good balance i i don't disagree that there should be somebody monitoring these things but i don't i definitely don't think you should be like you spent five more minutes on that than you should have you know well I don't know that I was thinking of it going to that level. Yeah, I don't think it would be that extreme by any means. But, you know, I mean, it would be easy for somebody to take that particular job description to heart and be like, no, no, no, that's way out of scope. Don't mess with it.

Right. To me, I view this title like this chief water tester. To me, this is the lead architect role, right? Like they know, they're involved with conversations about timelines. They're involved in conversations about scope creep. And they know the environments and what's happening, right? Yeah, that's fair. That's kind of where I see that role fitting.

That's fair. But if you have a I see that role fitting. That's fair. But if you have a business card with Chief Water Tester on it, I will have to accept it. Yeah, I don't know that that's going to fly as well. Although I'm going to probably assume, like my first inclination is going to assume that you work in like a water purification type of place. But okay. I couldn't remember in Harry Potter, did they give negative points or was it always positive? They got negative also. They got negative also. They got negative points.

Okay, it's like 50 points from Slytherin. Yeah, yeah. Slytherin never lost points, though. It was always Gryffindor. It was always unjust. Yeah, like, don't be a Snape. All right, so they also say to keep metrics on new requirements. You ever done that?

I don't know what that means, like time? Yeah, what are we saying? Yeah, like if a new requirement comes in, then you're going to track, keep metrics on how much effort it took to bring that new change in and, you know, like how long did it delay your project or whatever? I think we sort of do that. Like I've always sort of done that. We have like estimates and time tracking. Right. That's, that's what I'm thinking.

Right. I don't know that unless something just went way crazy, like beyond, i don't know that i've ever really had to do any retrospectives or anything on it although there have been things that we've worked on in the past where it's like hey we think this will take a week and then a month and a half later you're like okay it kind of has if you could rate tickets after you're done like yeah how'd you like this when you're two stars but yeah i mean typically i guess this is kind of done, like you said, through estimates, right? You estimated it four hours and all of a sudden it took two weeks.

Then, okay, we were wrong. But I don't know that I've ever gone back and looked at any of that stuff. Yeah, I mean, I feel like we've had a similar conversation like this on the requirements. And, you know, I don't know that I have. You know, I don't know that I have, you know, I don't, yeah. Because I think it was like around the estimating conversation that we had where we were talking about like going back and keeping metrics on it and like then reviewing to see like, well, how far off were you and everything. So this is in that same kind of vein, right? Like, you know, but looking at it from a larger picture, right. And so it's not just you and like how you estimated this one thing

and whether or not you were on track or not, but what was the overall impact to the overall timeline? Yeah, I think for me, just to wrap that piece up, though, I think the reason why I never go back and look at it in terms of truly how far off were you is every situation is so different different so it's not like you can take that one thing that was blown out by two weeks and say okay well that means the next one's gonna we need to expand it by two weeks it doesn't work like that right like it could it

could have been an integration problem that you could have never foreseen you know i mean to that end though there was one portion of the book and i don't remember if this is a portion we covered or didn't cover but um they were there was one section in here that, and I don't remember if this is a portion we covered or didn't cover, but there was one section in here that I really liked where they were talking about how more often than not, when we talk about software development and we try to make analogies to the real world, I mean, even on this show, we've done it countless times where we will make an analogy to construction, right? And like building a house or a building or whatever. Right. And they call out like,

you know, it's really not, there isn't, it isn't like that because it's easy when it's, well, I should say it's easier if, if you were in the business of building houses, for example,

then, you know, you have a rough idea. Okay, this is what it takes to lay the foundation, right, of the house. You know, what steps have to happen beforehand to clear the land, to compact it, and then, you know, lay out the markings for it and then pour it and how long that's going to dry. And then you can estimate that like after you've done that the first time, you can be like, okay, it took me X number of days to do that the first time. So it's probably going to take me X number of days to do the second one. Oh, I was off by a

day. Okay. Well, why was I off by day? Well, okay. I need to account for that. Okay. Then you do another one. And pretty soon you're going to be able to refine that to where, because it's so cookie cutter, you're going to, you're going to have a pretty good idea of what that takes. Right. But they caught out of like software development is more like tending a garden. It's going to constantly be changing. Each one is going to be a little bit different because the soil is going to be different. You know, one thing is going to grow and it's not going to look right. Or maybe it didn't grow well enough because of the particular environment. You know, maybe there was too much shade. It didn't get enough water. The soil wasn't just right or whatever. So you're constantly going

to be like, okay, well, it's time to trim this and cut it out, i.e. refactor, right? And put something else in its place or, you know, whatever, right? So they made the analogy that software development is more like gardening than it is building construction. I thought that was kind of neat. It is, and it's so true, too, because you might not have even made a change to your application, but there was some sort of cumulative update to your operating system, and all of a sudden your thing is broken, right? Or it's running slower or whatever. Like it's stuff you can't control. When you're building a building, there's just certain things you do.

You have two by fours, you have nails, whatever. It goes up, right? There's a lot of knowns and not as many unknowns. So it's definitely not the same world. It's easy to talk about them similarly in terms of building blocks. Right. But in truly estimating and maintaining all that, it's not even the same ballpark. Yeah, I liked it so much that I was like, you know what?

I'm going to try to commit that to memory from now on. That's what I want to try to remind myself to talk about instead of making the building analogy. We're going to be planting strawberries next. And I'm probably going to forget that next episode, so be prepared for that fair enough you know i'll tell you like when when people do work around my house i kind of think of it like it's a commodity like you know i expect the sprinkler people to come out and they're going to do just as good as job as the other company if they come out so i shop based on price whatever but any sort of home repair project i try to do it feels like custom software development for me things are crooked the screws don't work

door doesn't open anymore i got spare parts left over i go to lowe's three times oh that that's the part about home projects is so frustrating is you know what you need you go to lowe's or home depot you get what you need you come home and you're like, I forgot one thing. And then you go back five more times because you forgot five times one more thing. I do the calculations on the mulch. I'm like, all right, I need 20 square feet of mulch. And by the time I'm done, I've bought like 80

somehow. Do you think that's how Steve Jobs' projects around the house went? Like he would be like, and one more thing. Yeah, absolutely. That's what happened. All right. So the last thing in this section was they make the point of saying that pragmatic teams should not reject new feature requests outright. Instead, you should be aware of when they occur and that they will occur and, you know,

be receptive to them because otherwise you might be the one boiling. I like that. Yep. I'm always open to feedback that makes sense, right? Like a request that makes sense. Yeah. You come out with me with something stupid now and I hold on.

Right. Now we're going to have a problem. Now we're going to, you go back to your corner. I mean, because you said that it had to make sense. It has to make sense. Let's be honest. Yeah.

All right. So here's one of the most difficult parts of any team is communication. Oh, my God. So pragmatic teams need to communicate clearly to everyone else as one voice. Okay. The team needs to communicate with one voice. You need a consistent voice. So that means you have a spokesperson.

It doesn't have to be a spokesperson. It just means that you have to use the same language. So the team as a whole uses the same language. And when talking to other groups, you don't air your dirty laundry, so to speak, right? Like you stay on message with whatever your team is trying to deliver. And you might have, you know, your disagreements, but you keep those in house, right? Like, and, you know, your disagreements, but you keep those in house, right? Like, and, and, uh, you know,

until, and like, unless the team changes their collective mind on, on something, right? Well, this is, this is almost like some of the,

uh, big company, uh, like commandments or whatever, like commit and, and go right. Like, yeah,

even if there's disagreements or whatever, you got to commit to something and everybody has to be on that same page. After reading the next bullet point, that's what this is saying. And I agree with that. What you don't want to do is say something doesn't happen in IT and next thing you know you're over and customer service is gabbing to their manager or one of their employees about something that you don't like or disagree with. That just looks bad on everybody. It just kind of stirs up drama and resentment and just it just harms everyone ultimately yeah i wanted to make this feature so much easier for

you but they wouldn't let me so right right i mean that's the type of thing that you're talking and it can happen yeah it's insidious oh yeah it's easy to happen yeah so i've never done it but you know alan you kind of hinted around at this bullet point, but the worst teams are those that are bad-tempered or difficult to get information from. Yeah, don't be belligerent. Don't be hard to work with. I mean, man, there's no reason people should be that way. Right. These are teams whose meetings have no structure and no one wants to talk.

Their documentation is awful. Any two documents that you get, they're not going to have the same format and they'll use different terminology. There's no ubiquitous language among the team members or their documentation. Great teams, on the other hand, they have a personality. You look forward to meeting with them and working with them because they're organized. Their presentations are well-prepared. Their documentation is consistent. It's current. It's accurate.

It's concise. All of the members use the same language, and they all speak as one voice. You know, one thing I'll say about this section, and I completely agree with this. I mean, we've talked about in the past the like the type of people we'd want to hire. And I'll take somebody that's just, you know, a go getter over somebody that's just, you know, got every mathematical algorithm formula in their head. Right. I'll also take somebody that is super easy to work with. You know, that combination of relentless and, you know, brings a smile with what they do.

I'll take that any day of the week because it sure does make working a bigger pleasure than having to fight with anybody. You spend too much time at work to be miserable. Yeah, seriously. I mean, you spend, what, you're awake, what, 14 hours a day, and you're at work eight to nine of it? Yeah. Yeah. 60% of your day is spent at work. It shouldn't be frustrating.

So you get 10 hours of sleep? Did I say 14? Was it 16? I did on Saturday. That was so good. That's probably it. Nice. Oh, man.

Lucky show off. All right. So, yeah, but I mean, kind of to the point earlier, though, like these are the teams that, you know, yeah, they use that ubiquitous language and speak as one voice externally, but internally they have lively debates. There's nothing wrong with the lively debates, right? You can have strong opinions and you can express those strong opinions.

But at some point, what you were saying, Alan, to your point, at some point, you just have to, you know, agree to disagree and accept what the team has decided and move on, right? Like you can't keep belaboring whatever the point was, right? And good developers are passionate developers, which is, I think, part of what you were getting at, too, with what you look for. Yeah. And by the way, look, I'll be the first to admit, this whole commit and move on, I've not always been perfect with this, right? It's hard. There are definitely some decisions where I'm like, man, that is a boneheaded decision. And I'm going to tell you about it the next 30 times we talk, and then I'm going to move on, right?

And that's – it's something that I actually had to work on internally because I know it's not productive for anybody. Right. Like that's when, when you've been told that, yes, I hear what you're saying. Sorry. I don't care. Yeah. Doesn't matter. Then by continually bringing it up, all you're doing is creating friction, right. Intention. And, and that doesn't help anybody. So, all you're doing is creating friction, right? Intention. And that doesn't help anybody. So, you know, be aware of it.

Be conscious of it. Yeah, what you're saying might be right, but you got to also know when to table it. Yeah, it is really hard because at some point, like, you don't want to be that guy. Right. And by that guy, what I mean is whatever that hot button is, whatever that subject is, people will be like, well, I know I can't go to Michael, for example, about it. Because every time I – if we go to him to talk about it, we're immediately going to go down this other tangent of why this was the wrong decision in the first place. So we're better off to just, you know, talk to somebody else. Right. And maybe that somebody else is a good person to talk to on the subject, but maybe they're not, maybe,

maybe your first choice, like maybe Michael was the better choice for that particular topic. I don't know, but you get what I'm saying though. Like you can automatically be skipped out of conversations and you might be the subject matter expert on a particular thing just because, you know, you've,

you've now created that. People don't want to deal with you. Yeah. Yeah. And they say that the simple marketing trick to communicate as one, right? We were questioning this, like how do you communicate as one voice? Is generate a brand. Now, I will tell you, I don't think I've ever been on a team where, well, maybe that's not true.

Where I'm thinking, like, have I ever been on a team where this is true? Like, you have a team name and a team logo. Now, that's the part that's crazy. And then when communicating with others, you use that name or that logo. And then that builds an identity for your team to build on, as well as something memorable for others to associate your work with i kind of like that so we're gonna have a logo as at first like as i started that statement i was like i've never done that but then like immediately some some uh teams within like at ibm for example came to mind and i'm like oh no wait a minute like depending on how small or large you're talking about this team that was definitely done you would definitely have logos for it

and and names for it and you know people knew like oh that's you know that's the thing right that's fun yeah i remember a semantic at teams i don't remember what the team mascot was anymore but they kind of stuff like that would spin up and they would do a little either friendly competition or would do shirts or something around and just kind of try and bolster that identity which i think is really cool one thing i think to watch out the war is i've i've worked at places that have been part of or been excluded from like kind of little cliques that sometimes develop where maybe you have some developers that will just like get along really well into like buddies uh and then whenever they come around it's like oh it's the three musketeers and then whenever someone you know as else or it's kind of mixing

then it could be a little awkward because you know these other three have like such a strong kind of team identity together but they're only a smaller part of the team or maybe not even on the same team so it could be a little weird and that's what we always had to watch out for with being on the the podcast together is we have to be careful not to always have the team identity when we're working together. We need to be able to stick to the bigger team and larger goals and not

click up. That's why I purposely disagree with you every time. Yeah, that's good. We worked somewhere that there was a couple people, 20 people on the team, four or five, like mountain biking or road biking. And that meant they were hanging out on weekends doing stuff together and kind of having these conversations about work and kind of getting on the same page about things that the other people who weren't into bicycling weren't a part of. And that caused some friction sometimes.

It was a little bit awkward. Like overall, I think it was probably good and like, you know, overall a good thing. It's not like you shouldn't be able to hang out with your coworkers, but just something you have to be careful of when those kinds of tighter bonds start forming that it's not exclusive. It's not exclusionary to the other people on the team. And then you still have that team identity. I think, I think what you just said is the most important part. As long as what you're doing isn't excluding other people, right, then it's probably okay. Because like what you guys are both saying is it sort of creates factions, right? Like my team is against your team because, you know, and that's what you're not trying to do.

You're trying to build your team up, but not at the expense of everybody else. Well, I think what I'm hearing is that great pragmatic teams mountain bike together. That's, that's the takeaway from this. So I'm going to go get a Huffy now, but yeah, I mean like,

I mean you're, you were kind of talking about like smaller teams, but like, um, you know, when I was thinking back to the, like the IBM example, right?

Like, uh, you know, for anyone who's in the Atlanta area, you might even recall this one too, Alan, the arts cafe. Does that, does that ring any bells?

Like, you know, that was a team where, like, that's what it was known as, right? Like, you know, if you needed anything related to, you know, any kind of art you needed, it was the Arts Cafe. And it wasn't like it was, like, officially the thing, the name, but, like, there was a logo. It was on the door. Like that's where, that's what it was, you know?

And, and, you know, it was, it was a pretty decent sized team, but you know, as an example, right? So I thought it was a cool name too. Yeah. This episode is sponsored by Datadog, a monitoring platform for cloud scale infrastructure and applications. Datadog provides dashboarding, alerting, application performance monitoring, and log management a monitoring platform for cloud-scale infrastructure and applications. Datadog provides dashboarding, alerting, application performance monitoring,

and log management in one tightly integrated platform so you can get 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, visit www.datadog.com slash coding blocks to sign up today. All right. So continuing on here, let's get to don't repeat yourself.

And since we've already talked about this before, we'll skip it. What did you say? What was that? Don't repeat yourself. Do it again. Okay. So they call out that duplication is wasted effort and that this duplicated effort can create maintenance headaches. Right. I think we've all seen that before.

Like we've talked about examples where, you know, you have like a bunch of code. You're like, oh, well, I don't feel like rewriting this to where I could use it again in some other place. I'm going to like just copy and paste it. And now something needs to change, or maybe it had a bug and you don't know that you need to fix it, right? But that's at the individual level. But now we need to talk about this at the team level, right? And so how do you avoid that type of duplication? I mean, because it's a similar type of duplication that we're talking about. But at a team level where like maybe an entire other team doesn't know that your team has created this amazing, like, for example, this amazing logging framework, and you should

use that framework. Or maybe, you know, there's something related to like, you know, how do you ensure that you're protected against cross-site scripting, right? And your team has solved some kind of problem, right? And you need to let other teams know like, hey, this is the way you should do these and don't go and reinvent your own will, right? Then this is where they were saying like going back to a previous section that good communication among these teams can help to reduce this duplication. Okay.

So I've got to ask some more questions here because this is probably the one part of development that I feel like scales the worst. Oh, God, yes. Is communication. Like, even if you don't have a ton of developers, but you just have a few teams, like, how do you effectively communicate between teams? And here's the reason I bring it up. Okay. Everybody wants to have more meetings, right? So let's have a meeting and get everybody together and tell them what was done. And let's hope that people aren't doing other things like looking at their cell phones or working on

something because they're like, oh my God, there's another meeting. I need to do some work, you know, whatever. So that's probably not the most effective way. Sending an email. If somebody gets an email that has a page of information on it, that's not directly related to what you're working on at the moment, chances are you're going to forget that email was ever sent, right? Okay, well, let's do something even better. Let's create a wiki page. Let's create a wiki page because, man, that's a searchable index.

I could put some great information in here. And anytime anybody needs any information regarding this subject, they'll just go to the wiki and search for it, right? Because those thousand other links in there, you know, they'll go right by those. So here's my problem with this entire thing is how do you communicate effectively amongst many people on many teams when chances are whatever you're talking about is not relevant to those people at that given point in time and therefore is crammed to the furthest reaches of their mind never to be dug up again because what will happen is a month later when they actually care about whatever it is they're going to send an email out to everybody

and be like hey why is this thing like this you'd be like you're lucky right if you're lucky if they don't just go duplicate the effort because they didn't know about it in the first place. So I guess my question to you guys is how do you effectively communicate things out to reduce duplication or, or any number of other problems? and some spoken delegates because once you get more and more people, you can't have everybody talking to everybody. Especially if you've got a 200-person team, you can't have each person talking to 199 other people and trying to keep in touch. You've got to have a hierarchical structure at that point. And so I think as things get above, you know, is it two pizzas, like 10 people or something? Or in my case, like two people.

I like that. Two pizzas, that's a good approach, right? Well, okay. But you should probably define that i don't know two medium pizzas will feed what 10 people medium okay too large to yeah however many people you can feed with the table i think i forget where that was it's like two slices per person yeah however many people you can feed with the two pizzas that's the maximum number of people that you can have in the meeting.

In a meeting. Alright, so keep going. Sorry. Yeah, and even actually I've heard that for team sizes too. Any more than that and it just gets kind of unruly. So if you can keep your team sizes to basically two pizzas, give or take a bit or preferably take a bit, then you just limit some of the

extraneous communication that needs to happen. But it does mean you need to have good communicators in those lead roles, and they need to be able to understand what's going on at least at a high level, high enough to know, oh, hey, I heard there's something that you want to do. You want to create a new authentication form. But I know that somebody else on another team over here did something similar recently. So let me reach out to them and find out. So they don't necessarily have to know, no, don't do that.

Someone did that or someone is doing that. But they have to kind of know enough to say, that's kind of tickling my funny bone. Let me go find out a little bit more about that and see. Because I can't imagine like, you know, if you're working in a company with like 100 people and you've got a couple of people, you know, being redundant or doing things kind of in a, you know, re-implementing solutions, you know, that stinks. But if you're a super large company and you've got like whole subsidiaries duplicating functionality of other subsidiaries, like, that's terrible.

It's crazy when you think like, hmm, this company has 50 people that are implementing the new Kubernetes framework and like this company's over here. They've got 60 people implementing Kubernetes on their frameworks. So it's crazy. I mean, here's my thoughts on it is that, you know, they mentioned having a project librarian, which we've talked about before.

They can coordinate the documentation, the repository so that others can go to this librarian when they're looking for something. And the librarian can be responsible for spotting duplication when they get something new. But, you know, I mean, even in the examples that I gave, right, related to, you know, hey, we've created this awesome logging framework, don't do it again. I think at some point, and especially like as the organization grows, it's okay to allow for some duplication because kind of to, you know, your point earlier, Alan, it will allow you, it'll allow you to experiment and try new things. Like you might have created the greatest logging framework ever. It doesn't mean that there might not be a better way,

right? So you should still be allowed to, you know, there should still be some flexibility to be able to like, you know, whether you know that that other one exists or not, like you should be able to, you know, create some, some things that are repeated though. So part of this, I kind of take issue with like at the team level about like not allowing, like to, to 100% say that there's no duplication ever, then I can't get 100% on board with that, right? I mean, I understand the intent. If we go back to clean architecture too, right,

there's accidental duplication and then there's intentional, right? Just because you have similar code doesn't mean that you're actually doing something wrong. They might have two different purposes and they should change for different reasons. Right. So, you know, I don't know the librarian thing I kind of get, but I mean, even large pull requests, like, it's not like you can just look at a pull request and know what's going on. You've got to pull down the code, look at it in the context. Like you're talking about a pretty grueling job of being that librarian. You know what I mean? Yeah. I mean, especially like if you picture, you know, I picture if it's you're talking about a pretty grueling job of being that librarian. You know what I mean? Yeah.

I mean, especially like if you picture, you know, I picture if it's a team where like you only have maybe 10 people or 20 people, for example, like those kinds of teams. Okay, fine. Maybe you want the one library that you're going to use for like, hey, this is how we're going to handle logging, for example, or this is how we're going to handle authentication. You know, maybe that's okay. But if you're the size of Facebook, you know, you might want to allow other experiments because like, yeah, sure, you solved it. You solved authentication, you know, 10 years ago.

Okay. Are you really not going to let anything else come along, right? Right. As new authentication methods come out, right? So I kind of envision is like, okay, yeah, we have this other version of authentication, but I want to try new things. And then you create that new version and maybe it starts to gain popularity. And now it becomes the newer standard across an organization the size of someone like a facebook for example right so in some regards like that

that's why i say like i understand the intent behind there did you not repeat yourself but you can't be like 100 never repeat yourself it's going to there's going to be some variation there especially depending on the size of the teams. You know, sometimes stuff is just a little bit different. Like Auth is a good example where you can imagine where like the mothership Facebook has something for authentication, I'm sure. And it probably supports SAML and LDAP

and Kerberos and OAuth and all this other crazy stuff. And you can imagine like you're on a small team trying to create a little website for your, you know, for your company's softball team. And you need to be able to log in and say, okay, well, I'm going to use the company authentication system. And then you got to go set up some, you know, Kerberos servers and do all this stuff because it's a big heavyweight tool that's designed for millions of people and not for your softball

team. And so you're going to have a much harder time implementing that stuff because it just wasn't designed for you. So a lot of these technologies and logging frameworks and a lot of other things may not be adequate to your needs. And so sometimes it's okay to say, you know what? I think that our needs are going to differ enough that it's not worth trying to make it generic to suit both of them.

And I mean, part of your problem there too, in that particular example is, I mean, we've already decided that great teams mountain bike together, not play softball. So I mean, like right away, you're like, what am I doing? It's a failure. So those balls are not very soft, by the way. Yeah. So they also call out that, you know, if the project is too big for one librarian, you know, this is kind of the point

that you're making now is like, you might want to have more than one person, you know, you might want to have a few people as the primary contacts for different functional areas of the overall project. And they also call out like, did not forget the value of online user groups and mailing us and forums and wikis and things like that. um you know to be able to like archive questions and answers and discussions stack overflow well i mean i was thinking about like uh the you know the mvp mailing list for example right like you know things like that you know there can be there can be really good resources huge value all right and then there's everyone's favorite, orthogonality. I love that word. Yeah. It just puts a smile on your face to say it, right? So they say that traditional teams

are organized such that individuals are assigned roles based on their job function. So the rational unified process and an introduction, this is the book title, the Rational Unified Process and Introduction, this is the book title, the Rational Unified Process and Introduction identifies 27 different roles within a project. 27 different roles. That's a few. That was crazy. I mean, I'm sure we could rattle off, you know off easily a half dozen or a dozen, but wow, 27. So roles have an implicit hierarchy.

And I thought this was an interesting point that they make here, is that the closer the role is to the user, the more senior the role. I don't think I'd ever thought about that, but it sounds about right. Right? Exactly. That's what I loved about that statement. I was like, oh, yeah, that's a really great observation that I've never embarrassingly have noticed before. Yes, we're talking specifically about the project, not about the software, right? I mean, yeah, I think so.

It could be either, right? Why couldn't it be either? I've seen lots of businesses that would kind of buy a design and then kind of have, you know, more of this stuff going on in the background. But the design is what the user kind of interacts with. But I guess I don't know. I don't know how to approach that. But I do see it. And when it comes to project management, like the person who's paying the bill, like they need to be the happiest, right?

Yeah. I mean, generally speaking, I would agree with that statement. I mean, not too happy. I'm ripping you off. well i mean actually i mean i know you say that jokingly but there's a a chapter later in the book where they described that like um i forget exactly how they worded it but it was something about like going a little bit above and beyond with your you know for your customer because you would gain some goodwill from that yeah and uh you know so yeah you know you do want to like put that extra smile on their face so like it was basically basically what they said was something to the effect of don't just do what they asked right yeah over deliver yeah that one of my one of my old vps he used to say you have to give it the extra lanyard which is is an old New Orleans type saying where it's that little bit extra.

Like if you went to the butcher or whatever and you ordered some ham, right, they give you a little extra. And it was called lanyap. Land? Lanyap. Lanyap. L-A-G-N-I-A-P-P-E. Lanyap.

And it's actually the definition is something given as a bonus or an extra gift. So it was fantastic. Like he was probably one of the best leaders I've ever had the pleasure of working with. But he just had that ability to make people want to work harder. And his thing was, hey, when you deliver something, give them a little something extra, right? Make them happy about the fact that they came to you for whatever the project was or whatever the solution was. All right. Well, this weekend Webster's dictionary,

we will teach you all the new words. Yes. I will. Is there a way to link to this? All right. So they also mentioned that some development environments are going to have strict divisions of responsibilities. So we've seen these kind of environments before, but they call out like, you might not be able to talk to testers or the chief architect, for example, or to make matters worse, some organizations might have different sub teams that report to different management chains. Right.

Have you, have you been in those kinds of environments? Do you know the type of environments I'm talking about? Yes. Oh yeah. Don't like those. Yeah. I mean,

it's, it's, they're really, uh, counterproductive, I guess. Like it's more about rank, right? Yeah.

I would say like, it sometimes kind of makes sense. You want things to go to the proper channels. I'm sure you've been on teams where they say, hey, don't let whatever team come directly to you because we need to kind of track this stuff and manage it and make sure that they just aren't always going to the dev team or whatever. Right. It makes sense. I get it.

But it is frustrating. I definitely think if you can be closer to the customer and you work closer with the kind of end users, then ultimately everyone's going to be happier because you're not playing the telephone game. But as things get big, you just can't keep up with that. Well, so here's my thing with that, right? Like if that's truly what it was, was making sure that you were shielding teams and all that, then fine. A lot of times it feels way more political than that. You know, like, Hey, I don't want you getting goodwill with somebody because I'm trying to move up the corporate ladder or whatever. Like, as long as there's not some sort of, you know, garbage going

on behind the scenes is maybe I get a little bit more, but the political games are the worst. Yeah. I can't, I can't tolerate that stuff, but it's to me, the thing is when you break a developer, especially when that communicates well, like you don't want somebody that doesn't communicate well, trying to communicate with the end users, because that usually doesn't end up well. But if you have trusted developers that communicate well, typically you can get to a better solution if they have more direct interaction with whoever you're building the product for, right? I don't know. Yeah.

I mean, they also make – Look, Joe. No, I'm just remembering. Pleasant memories. Pleasant. They also make a point of saying that don't fall victim to thinking that the various tasks for a project can happen in isolation because they can't. True. Right?

Like the team, teams are going to need to work together, period. Right? To get to that end goal. Uh, you know, analysis, design, coding, testing, these are all perspectives of the same problem. And in fact, there's a different portion of the book where they actually refer to these as different views. Like they kind of, if you kind of think about it in the model view controller or, you know, that type of model view, view model kind of thing, like it almost sounds like that's where they're coming from, right? It's like it's just different views of the same problem, right?

All pieces of the puzzle, yeah. So, yeah. And developers that are two or three levels removed from the user will likely not be aware of how their code is used and therefore not be able to make informed decisions while developing it. Yeah, I feel that way too. Again, I don't know that you can always involve every developer at every level. But worst, I mean, worst case scenario, if they can't talk to the user for whatever reason, then at least within the team, there should be some sort of communication going on to let people know like, hey, the reason we're doing this is X, Y, and Z, right? You know, I don't know.

Communication is definitely super important with this. And sometimes it's difficult too, though, because like it's easy. Okay. So let's say that you're working on like a line of business application, right? And so the users of it are just down the hall, right? Those are situations where it's a lot easier to talk to the user of your software, right? But, you know, if your user is some random person, because, you know, like, for example, you're building a.com, right? Then it can be a lot more difficult to get that kind of feedback and engagement with the user. Yep, true. All right, Joe,

you take all the tips. What's this one? All right, number 60, organize around functionality, not job functions. Yes. And the authors prefer to split teams by functionality. I'm just kind of still thinking about what that means. They basically say each small team should be responsible for a small aspect of the overall system, which I think makes sense to me. They're kind of advocating, I guess, for more of a vertical approach here is what we're talking about. Then, you know, I don't know. I think it would be more of a vertical approach here is what we're talking about, then, you know, I don't know.

I think it would be more vertical, more horizontal. Right? Because you're saying, like, instead of saying, like, okay, like, I remember back in the old days, you know, where, like, at IBM, for example, there was like, oh, hey, here's all of our C developers and C++ developers. And here's another group that these are all the Java developers. And then here's all of our HTML developers. And these were each different, different groups, different management chains and whatever.

And it was like, you know, that's what they're saying. Shouldn't exist. Right. Yeah. And instead you would have a team that like this team collectively as a whole,

this is, they create the authentication. You're building this feature. We need a database person, a C person and a front end person. Yeah. Right. So're building this feature. We need a database person, a C person, and a front-end person. Yeah. Right. So, yeah, and then commitments change with each project, and so should the people per the team.

So this part reminded me, I think we've mentioned this before, but it reminded me of a Spotify blog article that's old, back from 2014, but around how Spotify structures their teams. And I think, I think I remembered hearing that they don't do this anymore. I think I've heard the same, but it's still, if you've never read this article and I think there's a corresponding video that goes along with it too.

I'll have links for it in the show notes, but it's a two part article. Great, really great read though. Super interesting. But yeah, this is what it reminded me of was how Spotify used to work with their teams. So splitting up the teams by functionality doesn't necessarily need to translate to use case though.

So in my authentication example, they're saying like, don't listen to HL. So, right. And in fact, the database team can count as a team, right? The help subsystem could count as a team. Like departments do like the accounting team, like these people specialize in the accounting software. That makes sense to me. Um, I guess it's kind of weird because, um, if you've got a team that's more busy than another, then that doesn't really seem very fair. But I guess you kind of shave things off. I guess if you're working with a smaller structure and you've got a customer service team and they have a front end, a back end, a database person. But then there's a lot of work happening on accounting a lot more than customer service.

And maybe you could borrow some people. I guess there's the idea that these teams have to be flexible as need. Yeah, if I remember right, that was part of the Spotify thing was like literally they were just very fluid teams. And that was part of the thing that was really cool and interesting about it was like, hey, you know, you get who you need, you work. It's kind of a flat hierarchy, right? Like it was just more about accomplishing goals and milestones so yeah i think i heard about some of those guys uh back when they kind of split their uh their pages up and they're like you get this little spot and you get this square

and you get this square right i know they ended up going away from that but i don't know about their uh like the culture and team organization if that was part of that change. Yeah. I think, I think I remember it being like what you just described where it's like, Oh, we are the banner ad rotation team. So like any banner ads that you would see, regardless of which version of the application, you know, how,

you know, be it a desktop app or a mobile app or a, a web browser. Yeah. And that, that would be that team. Um, of course, everyone inify is like we didn't

do it like that you got it wrong right all 1200 of them watch out they'll beat you up is it that many now uh it was in this 2014 article wow well they can leave their comments on uh codingblocks.net slash episode 114 and tell us how we got it wrong they might want a book uh yeah that's right all right so uh they said to look for largely self-contained groups of people uh when you're trying to like build these groups right and so like how would you define like you know how do you decide you got you've got 20 30 developers right how do you decide what the teams are, right? So you're going to largely look for the self-contained groups of people.

And this is similar to how we would break code up into modules, right? So we're going to use the same techniques that we would use there, such as by contract or decoupling and orthogonality. And by doing so, we can help isolate the entire team from the changes outside of it. I love this way of thinking about this. Now, in practice, though, I'm like, okay, that sounds amazing. But in that example of like a 20, 30 person overall developer team, like that's your total developer team, right? And in practice, it's still like, well,

I mean, do you, are there self-contained groups? Like so hard. You have to have well-defined chunked up projects to make stuff like that work. Right. Yeah. Yeah. It's,

I think, I think if you're going to do something like that, you've got to have people that have truly sat down with whatever the roadmap is for whatever product you're working on and saying, these are the separate individual pieces of functionality we're trying to add or whatever before you can even do that. If you're kind of more of a fluid organization, that's almost like everything's agile where it's like, well, I think we want this feature. It makes this way harder because nothing's defined up front for you, right? I think where I have personal struggles with this, though,

trying to wrap my head around it, is trying to separate the management chain of a team from the project team of a team, right? Because those don't have to be the same thing. And that's, you know, they, there's, they're making this kind of point with, and that's why they were saying like earlier, right? Like as the commitments change with a project, you know, the people on that team can change, right?

They're not talking about like hiring and firing people all the time, right? They're just talking about like shuffling people around, you know, as the need, as the needs of the overall project will change. And so then it's like, okay, in that 20, 30 person team example, okay, fine. So, you know, now I have this task and here's a group of people I can go give that task to, to get that feature done. And this, you know, this group of people can do that feature, et cetera, et cetera. That makes sense to me. But then how do you structure management chains in that kind of example? Because 30 people for one person to manage would be a lot. So how do you deal with that?

And how do you divvy those teams up into meaningful ways or do you? Well, in my mind, the way that works is it's almost on a project by project basis, right? Like there'd be a team lead for that particular project manager. Wait, okay, go ahead. So, so I see in that case, like, so let's say that there's a management hierarchy, right? You have employees and the manager's responsible for, you know, reviews, time off, all that kind of stuff. They still continue to do that job and they'll communicate with whatever the project lead is. And the project lead will tell them, hey, you know, so-and-so is doing awesome or they're not doing awesome, whatever.

But I think at that point, you just treat it as what it is, right? Like those little separate project teams, they're self-managed, right? The manager's job in the role of HR now is truly just HR functions, right? Sick leave, time off, you know, any kind of requests, like any kind of problems. Difficult conversations. Say what? Difficult conversations. Difficult conversations, right?

Anything like that. But seriously, the manager's then just taking on the role of HR manager type stuff. And then the project teams, those things are self-contained and they're run by whoever is leading that particular effort. So that's what I'm asking though. Is it like do you break up the team from a management point of view into something meaningful or not? And it kind of sounds like what we're saying is, who cares? Don't bother, right? So going back to that IBM example, fine, sure.

Here's all my C and C++ developers, and here's all my Java developers. And that's fine that they're in separate management chains, because when it comes time to put a project together and you're like, okay, I'm going to need X number of HTML developers or JavaScript or Java or C++ or whatever developers, right? You can just mix and match and pull from those various pools. I kind of like that, honestly. And that actually works better. Like I said, a lot of development, and I'm curious what you think about this too, Joe, is a lot of companies have now gone to this agile development, right?

Which is amazing for giving customers or whomever what they want in a quicker, you know, hey, we found out that this is actually more important than what we thought two months ago. So let's switch to this. It's amazing for that, but it does make managing or structuring teams a lot harder. Yeah, for sure. I think about some of the companies that I kind of keep in touch with, like with their roadmaps. Like Elastic searches. I love Elastic.

I love everything Elastic. They've got their roadmap published for like two years in advance because they're telling you about things that are breaking, that are going away, where the product is overall going. But they still sneak stuff in there. Like every once in a while, if something makes sense, like something changes in landscape, they might sneak something into a release that wasn't planned prior.

So they're kind of mixing that longer-term roadmap with dates, with some agility there. But that's also a lot of the stuff that people complain about. I complain about a lot, too, where you kind of mix Agile with dates, and those things don't really jive together well. And it's a sort of source of a lot of friction and frustration for everybody involved. But ultimately it's, it's kind of, uh, you know, maybe necessary for a lot of businesses to be able to do that, especially as they get bigger or have a lot of customers. Yep. I mean, I, I guess to, to your point outlaw, I think that in that regard, if you're going to have setups like that where you have fluid teams working on projects, just kind of turning a little task force type things, then I say at that point, the manager's role is to be the HR manager, right?

Like that's how it should be set up. And then each individual project that gets set up should have their own leads. And then that way, you know, you divide the two, right? should be set up and then each individual project that gets set up should have their own leads. And then that way, you know, you divide the two, right? Like there's somebody that's responsible for the project and there's somebody that's responsible for making sure their employees are getting what they need and doing what they're supposed to do. And that's basically it. Yeah, I can get on board with that, you know, because then it'll allow you to, you know, let's say, let's say you had a team where the management structure was such that like, you know, hey, this is all the JavaScript developers report to this guy, right? Well, then

they can agree that like, hey, on your various projects, we want to start implementing these new features of, you know, whatever the next version of JavaScript is, or whatever the next version of the framework that, you know, you happen to be using across your company or whatever, like you can kind of like advocate for these changes across the various teams. And then they can sprinkle that out based on the individual projects they are, they're on. So that then as a whole,

all of these different, uh, you know, silos can start, you know, taking advantage of it. Right. I like that.

I hadn't even thought about it. And I also think that that also, that gives people a chance to shine too. Right. Like if you're breaking things up into little project teams, as they come along, then, you know, uh, today Joe gets to step up and be the leader of this team tomorrow. Outlaw gets to step up and be the leader of this team. Right. It gives people a chance to step into those roles and see what they like, see what they excel at and that kind of stuff too. So, you know,

now I'm really selling myself on this too, because like as a, as, by doing that, if you were to like organize your, your, your management teams to where it was like biotechnology, for example, rather than by use case, then let's imagine the inverse for a moment and say that your management chain was such that, okay, your team is responsible for whatever this feature is. Let's say it was authentication as an example. And maybe that's going to require, okay, we need somebody to do some front-end work. So there's going to be at

least one JavaScript guy on that team or gal. There's going to be a database person on the team. You know, there's going to be a middle where, you know, so somebody is going to be doing Java or C plus C sharp or something like that. Right. And so maybe you have like four or five people on that team and, and that's the management chain as well as the use case, right? And so now let's say that that database person, they run into issues. In that scenario, they don't really have anyone else to talk to, right? But if their project of authentication is separate from their management chain

and they still have like regular management meetings, then they can be like, hey, have you guys run problems too like because you know we're on this other project for authentication there's this use case like it kind of gives it it opens up your lines of communication so yeah i'm kind of talking myself into that i like it yeah it's really good too for if you do have a large team for people to be able to kind of meet other people without having to talk to 200 you know i give the example 200 before you'd have to talk to 199 people. You talk with like these six people on your Monday weekly meeting about that project and these seven people on your Wednesday and then six months from now

you may be on three teams or whatever. It can kind of rotate and give you different perspective, interact with different people and to keep ideas fresh and help things kind of propagate. Yep. Yeah. So they say that when this is done properly, this can reduce interactions, which is your point, Joe, and it can reduce timescales and increase quality and reduce bugs. And as a result, the developers are going to be more committed, right?

Because they're going to feel like they have, you know, whatever the project, because now they're in the project part of it, they're going to have a little bit more commitment to it. And the teams are going to feel more ownership because they know that they alone are responsible for their part. But this approach will only work with responsible developers and strong project management. So I kind of disagree with that. Weak developers? So I kind of disagree with that. I think at least with developers. Well, so what I was going to say is I think the approach that we were just talking about where you have a management chain that's kind of HRE and then you have, you know, a project chain that allows people to start bouncing around to different teams.

And maybe it helps the people that are a little bit weaker grow into those roles a little bit better. Right. Because you start like I doubt you're going to create a project team that has a bunch of weak players on it, right? Chances are, just like any sports game, you know, if you're talking about a pickup basketball game or something, right? Like you start out with some strong ones and you kind of, you pick your team as you go down, right? And if you're doing that, then maybe you build these better habits because you have some of the weaker players in there with the stronger players and they see what it takes to be that way. At least that's the hope. Unless you're a fantasy football draft, you just did an auto draft on everything, in which case you might end up with all the worst players.

You shouldn't even be in the auto draft. Man, I've got a fantasy football draft tomorrow night. I'm so excited. This episode is sponsored by the O'Reilly Velocity Conference. To get ahead today, your organization needs to be cloud native. The 2019 Velocity Program in Berlin this November 4th through the 7th will cover everything from Kubernetes and site reliability engineering to observability and performance to give you a comprehensive understanding of applications

and services and stay on top of the rapidly changing cloud landscape. Learn new skills, approaches, and technologies for building and managing large-scale cloud-native systems and connect with peers to share insights and ideas. Join a community focused on sharing new strategies to manage, secure, and scale the fast and reliable systems your organization depends on. Get expert insights and essential training on critical topics like chaos engineering, cloud-native systems, emerging tech, serverless, production engineering, and Kubernetes, including an on-site CKAD prep and certification.

Velocity will be co-located with the Software Architecture Conference this year, which presents an excellent opportunity to increase your software architecture expertise. Get access to all of software architecture's keynotes and sessions on Wednesday and Thursday, in addition to your Velocity Pass access for just €445. Listeners to Coding Blocks can get 20% off of most passes to Velocity when you use the code BLOCKS during registration. Again, that's the code BLOCKS. Well, as we've said before, if you haven't already,

we would greatly appreciate it if you'd leave us a review. You can find some helpful links at www.codingblocks.net slash review and know that we do read those. It puts a smile on our face and we really do appreciate you taking the time out of your day. And with that, we will head into my favorite portion of the show. Survey says. Oh, no yeah this is backwards and we're missing stuff this is the wrong one here oh no no it's it's right it's just um yeah i got things in the wrong order though but i just realized when i i wrote this survey i did not write it with the typical funny voice that Outlaw normally writes these surveys in.

By the way, Outlaw does like everything on the show. I don't know if I've ever mentioned this before. But yeah, Outlaw is beast mode for sure. And yeah, and I let him down. Now I'm going to like totally blush. What has to happen here, unfortunately, is that when you do the survey for this week, you're going to have

to make them funny on the fly. Okay. So, creativity is going to come into play. No pressure. Right.

And that's on top of me getting things in the wrong order. Okay. As if we haven't done this 113 times before. Right. Right.

Gotcha. All right. Well, thanks for that, that pressure and uh yes it's on you now all right let me then i will fix that and here we go so uh back in episode 111 we asked what is your favorite shell of choice and your choices were bash k shell ash dash z shell fish command prompt or power shell all right uh joe since since you you uh put me on the spot here i'm gonna make you go first powershell all the way power 38 38 power show that that's commitment yep no i'm just kidding all right uh powershell 38 alan what say you man, you know, I think because our show title says.NET,

there's probably a lot of people that lean towards PowerShell, but I'm going to be hopeful, and I'm going to say Bash. Okay. And I'm going to go with 35%. 35%. So I have PowerShell at 38%, Bash at 35%. Correct? Yes.

And the survey says you're both wrong. Really? Command prompt. No, actually this one was super impressive to me because it took me by surprise to Z shell.

Wait, how many people actually voted on this three? Cool. I've never heard of this. No, no, there were, there were quite a number. Uh, it was 37% of the vote. I don't even know what Z shell is. And bash was second. Okay.

All right. What, what was the percentage? Uh, just under 31% of the vote. Okay. So I was What was the percentage? Just under 31% of the vote. Okay. So I was... Rounding out the top three, PowerShell was there. But I mean, I've already counted over almost 68% of the vote, right? So everything else is really small, right? So PowerShell was third place with less than 15%.

Man, I'm about to have to change my shell, apparently. I don't even know what this is. Well, I mean, it probably just goes to show how many of our listeners actually are not on a Windows platform, was kind of my takeaway from it. Yeah, that's why I was going to lean towards PowerShell. I think you're getting sawed on Windows. I know I've heard from people who use Macs a lot.

That's the only reason. I've never used it, though, but I've heard, and I've seen you can change some icons and some cool stuff with it what it looks like yeah i mean i guess i'm gonna have to give it a shot you know i mean we had uh uh just recently we learned a lot about vi and vim so i guess now i'm gonna have to learn a lot from uh you know somebody on the on the slack community is going to have to give us a talk on z shell and why we should care about it because you bash has been forever my go-to on any kind of unix environment and now apparently it's not enough that's so you know i gotta mention uh even though we're still doing survey zach uh i'm sorry

about your last name zach and breck and brexton I'm sorry that I can't pronounce your last name, did an amazing presentation on Vim this weekend that Adela and I were in and a few other people. And I have doubled my command of Vim and I know a little bit about the history and why it makes so much more sense just knowing where things came from. And I learned a couple of just life-changing, just little commands that have made things a lot better for me already. So thank you, Zach. That rocked. Yeah, it was a really great talk. I know for me, the one that I never knew before. And when he talked about it during the talk, I was like, that is a game changer for life, was the command chaining in VI. I never thought about it during the talk, I was like, that is a game changer for life, was the command chaining in VI. I never thought about it, never knew about it. It never dawned on me. I would have never Googled it to find out that it was even possible. And then he talked about how you could chain commands together. So if you wanted to select and change a word all and then, you know, insert it at the same time,

like how you could do that. And I was like, oh, wow, that's like, I would have just said like, okay, let me find the word, delete it. And now I'll insert and here's the new word. And like my way of doing it was so noob compared to how he showed us to do it. Like those types of things as an example right and like that is just such a minor example compared to some of the things that he showed us related to like finding in and block selection in it too in vi to like or in them it was it was awesome did we happen to record this or was it on twitch he did he did he was he recorded it and uh he was going to uh share it in multiple places um once he has it ready so yeah okay so hopefully that'll be in our show notes i don't know if it'll be ready i don't know when he's going to have it ready so i can't commit to that okay but it will eventually be

yeah check back we we will once he once he gives us the link then we will definitely uh you share that awesome my favorite was the end so you like if uh because a lot of times i'm doing like config We will, once he gives us the link, then we will definitely share that. My favorite was the N. So, like, if, because a lot of times I'm doing, like, config editing in Vim. So, you do the, like, the C-I and, like, W, like, change in word or change in, you can do, like, quotes and it would change the value. So, you can just start typing. You don't have to, like, normally I would kind of, like, go back and forth in order to select or delete XXX. Now, it's just like two little letters.

Yeah. Doggone it. Yeah, it was really good. All right. So, with that, we will head to today's survey. And I will read it in my announcer voice or announcement voice. What is your favorite type of swag? I really can't do that. No, you can't do that.

All right. So what is your favorite type of swag? Stickers because they make my laptop go faster. Obviously, if you've ever seen my laptop, it runs a billion uh clock cycles per some time frame it's trying to get away from the stickers yeah wait what no although maybe that's part of the reason uh shirts because i wear them pretty often and they make me look pretty uh water bottles because nothing says conference better than something that's going to keep me hydrated so that I can run to the bathroom in between talks. Coffee cups because my code requires caffeine.

Hats because I got to keep that heat in or is it just that I got a bad hair day and I got to hide it? I'm going to go with bad hair day. I'd take a bad hair day. Yeah, it's probably a bad hair day. Socks because, I mean, come on. Everybody loves super cute, funny socks. They have to be totally unique and different. You can't have just plain single-colored socks.

Although that's all I'll ever wear. So don't make fun of me. All right. You wear socks? I mean, sometimes. Where are you going, fancy pants? When I wear shoes. We're talking to Florida boy here.

Florida man. Yeah, right. Florida man doesn't wear shoes. All right. Bags, because they cost the most. Or pens and notebooks in case I need to write down something super quick. All right. So this one will be interesting.

It might determine what kind of swag we buy next. You think? Maybe. Maybe. Maybe. I mean, based on our hair, it's going to be probably the... I've seen our hair style, so it's probably going to be the hat. Or lack thereof. You've seen some of my hairs. This episode is sponsored by Educative.io.

Every developer knows that being a developer means constantly learning new things, new frameworks, languages, patterns, and practices. But there's so many resources out there. Where should you go? Meet Educative.io. Educative.io is a browser-based learning environment allowing you to jump right in and learn as quickly as possible without needing to set up and configure your local environment.

The courses are full of interactive exercises and playgrounds that are not only super visual, but more importantly, engaging. And the text-based courses allow you to easily skim the course back and forth just like a book. No need to scrub through hours of video to get to the parts you care about. Amazingly, all courses have free trials and a 30-day return policy, so there's no risk. Try an awesome course like Grokking the Coding Interview, a really good course to prepare you for your next interview. I ended up experimenting with a couple of courses this weekend, and I ended up buying one for Big O Notation.

And it was really nice to be able to flip around and be able to read text and skim and go back and forth a little bit just to see what the course was like after I purchased it. And the problems I actually thought were pretty hard. So it was really nice to be able to kind of have that kind of confirmation on the stuff that I was learning and to be able to go back and revisit them easily too. Yeah. I took it from a different approach. I asked my son, who isn't a software developer, you know, like, hey, can you take a look at this from like someone who is new to programming and any of the concepts about it, right? I wanted to get his approach on it. So he went through the Learn Python from scratch, right? And I asked him, I was like, okay, like, you know, get through

it. Tell me, I want to hear like some of your feedback on it because I'm kind of curious to see like, you know, what you thought about it. And he came back, he was like, he really liked the course because he said, you know, it really holds your hand to teach you the new topics and it does a good job of explaining things. So like, you know, something that like you and I might take for granted, like functions, for example, but for him, he was like, well, it really explained it well to him. Right. And there were little quizzes and, or there were quizzes and little projects that, you know, they would give you at the end of each section and you, you had to pass them. And, you know, it really made sure that you were paying attention in order to get through it. Right. And, and he thought that the examples were easy to follow

and had, uh, you know, really good visuals to help explain what was going on. And he really liked too, that there would be like code samples that, uh, you know, to describe something, but then you could actually, those were live. You could edit them in an experiment, uh, you know, to see like, well, what if I change this? Like, how might that work? Right. So it's pretty neat getting like the point of view of like someone who isn't already in this world, the software development world, like what they thought about in going through

the, you know, the beginner port, beginner courses that they offer. Yeah. Visualizations were really cool too. And just to be able to like quickly skim up and down has been really nice because I would kind of fast forward to the stuff that I thought I had a good grip on. And then I was able to kind of, you know, scroll up a little bit in order to read back through what I realized I didn't quite have as great of a grip as I wanted to have. Start learning today by going to educative.io slash coding blocks. That's E-D-U-C-A-T-I-V-E dot I-O

slash codingblocks and get 20% off any course. All right, next up is a cool section that we've titled Two Heads. And that's because each project has two heads, basically one technical and one other they call administrative here. The technical head is basically responsible for the development style, assigning responsibilities, and arbitrating discussions. And then the administrative head is more of like the project manager. I thought it was interesting they called it the administrative head, though, because I tend to think of administrative as those things like those HR duties and whatnot. And I tend to think of project managers having more of a kind of domain experience than they're

kind of stressing here, although they do kind of also talk about scheduling resources and also talking to stakeholders and acting sometimes as a PR representative. So they kind of represent the requirements and some aspects there. But I just thought it's interesting that they kind of titled it that way. It is funny that they put the technical lead as the lead architect. I mean, in a small group with a lot of projects going on, like this doesn't seem like that would scale that well, that well with, you know, everybody being an architect. I don't know.

They need lots of architects. Yeah. It seems like, you know, having a project lead that's you know, a technical person that's got some good technical chops should be good enough in most cases. And then if there's any consultation that needs to happen with an architect, then sure. Right? I don't know. That feels a little bit more natural.

Yeah, I don't really know, but I thought it was kind of funny that they called it two heads. It kind of implies that there's some sort of friction or maybe some translation there that needs to happen between those two heads, but kind of pulling things in two different ways. Not that that's a bad thing, you know, sometimes it's kind of nice to have that balance. And so, yeah, I just thought it was kind of interesting. I also mentioned additional resources for larger teams. We talked about the librarian.

They also mentioned the water tester. So we got some notes here. I definitely feel like I've seen the librarian roll around. Really? Really? Yeah. So my first thought was, so we've referred to Arlene in the Slack as being a sort of librarian because she has her finger on the pulse of everything. So anytime something interesting or a question comes up, she just knows how to put her fingers on it instantly.

She just knows a lot of stuff and can point to it really quickly. So I've kind of thought of her as kind of having a librarian-type role in some aspects. Oh, that's i can see like you know if you kind of like when you work in an organization you just don't know where to go to talk to somebody there's usually someone around who's been there for a while they can go to and say like who worked on this piece or who can get me closer to this and they can usually get you either to the person or closer well i mean basically the way you the way you're describing, at least the way I'm envisioning what you're describing, though, is the person, like the project elder, right? Whoever has, like, through attrition is the last, you know, the person who still remains on the project, right? They know whatever history there was was so they are that person right but it's not like an official kind of role like they haven't been appointed as the librarian

or historian i don't want to necessarily conflate it with elder because it i don't think necessarily i think the history is a big part of that like obviously you know there's a historian too but i think there's a lot to be said for just knowing what new is happening. So a lot of times on a team, like if something breaks, like you might go to a manager or an architect and say like, hey, something's not behaving correctly. Who is making changes in this area? And they've just got their finger on the pulse of everything. They've got their finger in every pie, so to speak. So a lot of times there's certain people that just seem to know more about what's going on, whether it's because they work wide or maybe they're in, you know, lots more exciting meetings or for whatever reason. They just seem to have a broader picture of what's happening.

I like that. That makes sense. And yeah, I've actually seen Arlene on some of our Git projects, like, you know, answering questions and updating things here and there and yeah that makes sense i kind of see it yeah yeah excuse me i just want to ask something about um was it um dealing with errors or something someone asked something in slack uh the day we had an episode about it and we didn't um but she was instantly like oh here's two podcasts that were about reporting bugs here's two podcasts that did talk about it, and here's a couple of good links. It's like, holy crap.

I looked at it. I was like, I'm adding some bookmarks here. This is good stuff. That's awesome. Yeah, I don't know that I've ever been on a project, though, where we had that librarian. And specifically, as the book calls it out, it's like someone who's going to index and store code and documentation.

And I'm like, wait a minute. Isn't that just software? Isn't that what wikis or version control systems are for? Yeah. Like. Yeah. Yeah, I don't like having an official rule for it. It's like, oh, you've got to be the note taker because you did it once.

Yeah, and nobody wants that. Yeah. Yeah, and then they also called out like, you know, a tool builder, someone that provides the tools environments and support this open i want to do that one well hold on this opens up outlaws annoyance with the term devops no no no this isn't this isn't or at least the way i took it this wasn't it because like they're they're this would be more than that and because that support portion of this in my mind is bigger than that like this is

you know in the book they were talking about it building like you know this might be the person that would be like per building here's the system you're going to dev on this is the environment you're going to dev on right and provide support so it's more than just like automating the build i got you or something like that right yeah i don't know. Like they're providing the tools. So here's, here's the tools you're going to build with. Here's the environment you're going to build with. That's interesting because at least from my perspective, this is usually everybody, right?

Like Joe was talking about earlier that he's got his own scripts that are doing things, you know, I'm sure you have your own things that you build. Heck you have your own bin directory and windows. Um, you know, but I mean, we've all been in environments. We're in an environment now where it's like, you know, somewhat like, hey, here's your dev laptop, right? Yeah, that's true. But even in our current environment, though, like, you know, I've said, like, okay, here's a script to help everyone, like, you know, build their environment up, right? Like, where it's all automated, right?

But that's what I'm saying. Everybody sort of takes part in this, right? To a certain degree. I mean, it's almost like calling out the librarian. I feel like having just a person that's a librarian or a person that's your tool builder feels kind of wrong, at least in a lot of the stuff that I've done over the years. In a lot of ways, this role felt to me like your IT team, right? Not the dev team, but the IT team, at least in the way they described it. Although now with building environments and stuff, that's Kubernetes or that's VMs or

that's almost stuff that I spin up in the cloud or whatever. I think a lot of these roles are changing as time moves on too. Well, definitely since the book. So like, for example, Vagrant is an example where you could build out VMs in an AWS environment where you could like, hey, here's the predefined tools that are already going to be installed on it for you. And you don't have to think about it. Right.

Yeah. Right. So automation then, since we're kind of already on this topic, you know, this is, they, similarly to the quote that I said at the beginning, they had a similar quote here later in the book. The best way to ensure consistency and accuracy is to automate everything that can be automated, right? So, you know, going back to like how to make pragmatic teams, right? You can't have everybody just doing their own, you know, one-offs here and there, right? Script it so it's repeatable so that everybody can use it, right? Even if it's just building your environment, right?

Bash scripts, make file, et cetera. You know, it isn't going to change itself typically, right? And, and. Yeah, which means if you want it to be good enough for other people to use, I need a ticket. Well, and it can be versioned too though, right? So you can see like, you can track those changes to it, right? So automation is an essential element of any pragmatic team.

Now, this is where the last point about the tool builder and automation kind of, like, merge, and now we can prepare for the fun. So it says appoint one or more people as the tool builders to build and deploy tools that automate the project's boring parts. Yeah. Okay. That makes sense. So this is the nowadays DevOps people, folks. Except do you appoint them, which kind of sounds like now that's their full-time job or do you just say like hey everybody's everybody's contributing to this thing right i think it depends on the environment i mean we didn't jump

into this deep last time but if you've got something that is super duper heavy on something like kubernetes or if you have big puppet scripts and that kind of stuff then yeah maybe you do have somebody dedicated to it because that's a deep pool to be in, right? If it's something where you've got smaller teams that just have things that need to happen here, yeah, everybody should pitch it. And I think everybody should pitch in anyways and everybody should at least be cursorily aware of what's going on.

But I definitely think that in some situations, these absolutely could be full-time gigs for one or a team of people. I think it's going to – let's say it would vary by team, like by organization, right? That can be a huge factor. Yeah, totally. If you're in a company the size of an IBM or a Facebook or a Microsoft, then the larger the organization, the more capable people are of specializing in something that's super specific like that. You could make a career out of just Postgres development and nothing else, right? But, you know, when you're in a smaller company and there's like 10 developers, right? Then every developer is wearing many hats. And even in those bigger companies, though, you're still going to know, like there might be an

infrastructure specialist that's going to be ultimately responsible for the thing that's going to go to production. But that doesn't mean that for the development part of it, that you might not have to do some types of things that would still fall in like an infrastructure type of role, right? It just might not be the version that makes its way to production, right? But you might still, you know, build, configure an environment that you're going to do your development on, right? Yeah. Yeah. build configure an environment that you're going to do your development on right yeah yeah so i think everybody still has to have some you know parts of that i can just get devos person i know when to stop adding paint i knew he was going to do it i was like waiting for him

like when's he going to troll me on this what's going to happen when we need to have an episode on it next. We should talk about that. I'll add it to the schedule. Stay tuned. Alright, so know when to stop adding the paint, as Joe said.

Pragmatic teams will give each member an opportunity to shine. And they provide the team members with enough structure to support them and ensure that the project delivers against those requirements. But then they resist the urge to add more paint. So this role is the, uh,

no one to stop adding paint role. So you need to have at least four, four people on your team. You need the tool maker, no one to stop adding painter, the librarian. I forgot the toolmaker, no one to stop adding painter. The librarian. I forgot the other. We need the librarian and the water.

The chief water tester. The water taster. And we're going to change it. Oh, yeah, and the technical lead and the administrative lead. You actually need 20 people per team. That was 27. 27 roles per team. Yeah, that's right.

Yeah. Yeah, I think it makes sense. We've talked about gold playing in the past, but usually that's not the problem. So I don't know too many teams that keep making stuff better along the path that's worth it. But I think as it relates here, though, when they say knowing when to stop adding the paint,

as it relates to the teams and giving the team members enough structure to support them, I think what they're saying is like, as an example, maybe it's like not, um, okay. So going back to your example earlier, Alan, not putting too much rigor or too many, uh, boundaries on what the developer can do. So you give them enough freedom to be able to explore their creative side or whatever, and come up with their creative solution without overly dictating how they do what they do or whatever. That would be adding too much paint if you're putting those kind of restrictions on how they can do it. Okay. Yeah. It's one of my pet peeves with writing up any kind of tickets for people to do a task.

I cannot stand it when somebody writes out every single step. It's like, wait a second, man. If you, if you're going to take the time to sit there and say, okay, you're going to use an eye dictionary here and then you need to put this in this and you're going to do that. I've seen, I've seen people write things up like that. And I'm like, uh, why don't you just write the code? Like, please don't waste anybody's time. Don't dictate implementation details, right?

And put it up at the top. I don't like to scroll so much. I thought you were going to describe like the give and win then syntax, like that that was what you hated. I'm fine with that. I'm actually fine with that because as long as you're defining the intent and what you want the outcome to – I'm a big fan of the give and win then. Yeah. I'm fine with that.

Joe, you're over there huffing and puffing. No. I was just thinking good things again. So, Kotlin, my love, where have you been all my life? This is kind of unrelated. This should maybe be a tip. Yeah. I'll say this.

I'll say this for my tip. Okay. I'm going to change my tip. All right. Okay. That's interesting. Well, I can't wait to get to that. So, you know what?

We're done. Let's just skip ahead. There we go. And we will, you know, obviously there's going to be some resources we like. We'll have several links in there. We mentioned the Spotify one. Of course, we're going to have links to the Pragmatic Programmer in that section. And with that, we will head into Alan's favorite portion of the show.

It's the tip of the week. All right. So I don't remember who brought up this conversation in Slack, but somebody threw down the gauntlet and said that they hadn't heard a tip of the week from me that required me rattling off a long git command. And so I immediately said, challenge accepted, and knew exactly of a couple that I would share. So one that I find sometimes handy, and I was surprised that I'd never mentioned this one before, was you ever find yourself in a situation where you need to undo your last commit? Yep. So I'll include a Stack Overflow link for this one because I'm always, just to be doubly sure that I'm executing this command right, I always go back and just, I know exactly the Stack Overflow answer,

so I just go back and check it. Like, yep, that's the way. I always double check it before I hit the enter key, but I'll go ahead and type the command and the command would be get space, reset space, head tilde. Wait, wait, wait. I think we need to mention that this might be the most upvoted answer i've ever seen on stack overflow 21,000 21 and a half yeah 595 upvotes i don't think i've ever seen that anywhere on stack overflow that Okay. Yeah. He got some serious credit for this answer. I'm going to go ahead and click up on it. Oh, I'm not logged in. Nevermind. It's too much work. Yeah. Like I said, that, that one it's game changer. So I'm, I'm including it in there, but, uh, I'm definitely going to give this link in there because, you know, I always go back to it, even though I know the command, I still go back and check it because I'm always, I

always have that fear of like, wait, what if I, what if I'm about to like undo some history that I didn't mean to undo? I just want to be sure. I just need another voice of reason that saying, yep, that's the right command. So, uh, there it is. And just as a bonus, uh, have you ever found yourself where like maybe you go down some rabbit hole of like you you start making some changes and everything then you're like you know what i actually want to scrap all this i i don't i don't want to commit any of this

right and you know you could go through the hassle of like doing a get checkout minus minus on one or two files or you know know, each individual files. But that can be a pain, especially if there's a lot of files. Right. So get space, reset space, minus minus hard minus head. No, no, not minus. I said minus minus hard minus said, oh, sorry. Ah, geez. I'm messing up my. Minus head. Oh, sorry. Ah, geez.

I'm messing up my own tip. Okay, let me get reset head tilde that last statement that I made and restate this one again. Get space reset space minus minus hard space head. Yes. And that one will undo all of your current changes and just reset the environment back. I'm surprised you did that in your additional command that you typically run right after this. Well, I'm going to say it because in case if you have, if there are untracked changes

that are included with that, that get reset hardhead will not remove those because they're untracked. So if you wanted to get rid of those, then the bonus command there would be get space, clean space minus F and that would remove those files as well. So when he says untracked changes for anybody that's like, what? That's like files that weren't already in your get commit history or anything like that. So you added new files or something like that,

that's how you would kill those off your system as well. I always do git reset dash dash hard by never to the head. Well, I mean, yeah, it's optional. I always specify where I want to put it. What you're doing technically is you're saying what commit you want to go back to. So I always just specify head to go back to the head yep okay good to know and it's funny with that when i do my get reset head tilde i usually do one i always thought you had to do the number there because you can do more than one if you want to specify so it's funny that i get more explicit on that one and not any other

right yeah we're opposites all right so now and now joe will share with us his greatness this tip of the week that came to us on spur of the moment yep yep this is a good one and i like it because it's gonna uh annoy outlaw so this is everybody isn't a devops guy here's why you need a dev op specialist on your team so this is uh from my long list of reasons why you should consider using kotlin for all of your programming and this is actually reason 147 thanks for reminding me did you know in kotlin you can uh put back ticks around your function names in order to enter arbitrary text. So things that would normally not be allowed in function names like spaces. And what this means is you can have a function and then an English-like looking sentence. Now you might be thinking

this sounds horrible for regular coding. You don't want to be doing that sort of stuff. You don't want to be calling functions with sentences for names. However, it works out really well for testing because they actually encourage and actually in the style guide, they say you should only use these back ticks for testing. It just reads really nice in your editor. And chances are, if you're doing Kotlin, I think you're pretty much using IntelliJ. You'd be kind of crazy not to. I'm sure it's not your only option, but it works really great. And it just shows up really well. And so, you know, we've kind of talked about some other kind of naming strategies and ways of kind of wrapping classes.

But it's kind of nice by like kind of having most people using one tool for one language. It's already kind of set up really nicely to show up nicely. You can see all the information you need. It already kind of breaks it down by class. And so you can see everything that you can see with other naming strategies. And it just reads like plain English. You can type exactly what you're testing in something that's really readable to a human. And it's really sharp and it's a great feature.

And it's reason number 147 why you should be using Kotlin for everything. What were the first 146? Oh, I don't know. There's no time for that. I think we're already probably over the hour mark here. Go getting pretty close to it. The hour mark. Although we should comment that even like from the JetBrains team, they're like, I don't know if this is a

good idea to abuse back ticks in this way. I have not tried emojis yet, but I'll let you know tomorrow. All right. team, they're like, I don't know if this is a good idea to abuse back ticks in this way. I have not tried emojis yet, but I'll let you know tomorrow. Alright. It is fair to say that everybody that has now been introduced to Kotlin that I'm close to has sung its

praises to the level of C Sharp and beyond in some cases. I've bagged on Java quite a bit and i want to say that i'm sorry because i i didn't know any better now i've seen the light okay okay so asking a total noob question here does it have features like link it does ah really yeah it does and the way nice features jay-z's like windowing. Nice. So it's better.

Yeah. Well, one thing that I particularly like about their link type features is that the functions have a default variable name, it, I-T. So like, you know, in link and C sharp, you have to do like X arrow function name. And it's annoying sometimes when you're just doing like little things like method groups or just small calls but it's just nice to be able to do curly brackets not not parentheses uh it dot whatever and another thing that's nice about having your link your lambda expressions in curly brackets is that you still have optional parentheses for arguments one thing that's always been kind of awkward and c-sharp and length if you've got multiple arguments say like if you're doing a i've already called it whether it's an inject

or reduce or whatever the name is um it's a group in c-sharp uh you do the lambdas like the first argument and then you pass the initial value in the second it's just awkward to kind of have that comma and there's multiple lambdas and that's something that uh colin's gotten around with curly brackets because that was oh sorry let me write that down that was uh picking it up uh reason 136 so so you're referring to like an example in c sharp where like you might do a dot aggregate and you would have to you would have to first do the initializer so like if you're doing a string building you might say like uh you know in your dot aggregate open up your parentheses new string builder and then in your next set of parentheses you would have like

uh you know the list and then whatever the string builder variable is that you're going to pass in to the next one and then fat arrow and then curly brace and then go on right yep yeah and you actually know reason number 17 why i like hotline is because it uses standard names like fold and map and reduce and things that you know from other languages and it weren't just made up specifically for c sharp aggregate and select hold up hold up let's be fair it's not that you knew them from other languages other javascript is what we're talking about here. That's what they are in Python, I believe, right? Doesn't Python have like map and stuff like that?

The names that they used? I don't know. Yeah. I mean, not that I know. I just know from JavaScript. Exactly. From other languages. I just like that you've actually taken the time to write down this list and number

them and you can quickly go back and find things in this list. I should publish a book. You should. The 149 Reasons I Love Kotlin. Oh, there's way more than that. I'm still adding to it too. That's amazing.

Mine's actually, I've got to admit, I stole this from the MS Dev Show. They had an episode where they weren't even talking about this, and he threw it out there like it was just this nonchalant thing. And I was like, in authentication world, right? Like, oh, my Lord, how many different ways and how many different lines of code do I have to write to authenticate something? Man, Microsoft has built what's called the Microsoft authentication library. And the beauty behind this thing is it's got includes for.NET, for JavaScript, for Android, for iOS. And it's also got this for Java that's currently in preview. But basically what it boils down to is if you're using like Azure, Azure Active Directory, this will do it for you. You put it in your code and it will set up your authentication, all the redirects and tokens and logging in and everything else. It does it for you.

So when I heard this, I sort of almost wrecked my car. Like, man, this really makes me mad. I've never heard this before. And like I said, it was just like this random little comment. Oh yeah. Like the Microsoft authentication library. I was like, huh? What? So, uh, got a link in the show notes here. Go check it out. There is one important thing to call out here is there's a difference between a dial, which I'd never heard of the Azure directory authentication library and the MSAL, which is the Microsoft authentication library. So apparently one uses the old version for Azure AD where this new one uses version two with the Microsoft identity platform. So apparently there's two of these things that existed that I never knew about. So you're welcome. Go play with this. This might be really cool to just plug in and play with. But okay. I mean, it sounds great, but I'm curious.

Don't butt me. No, no, no. Sorry. But I'm trying to understand, though, like, is this an authentication library for just their own thing? Because they mentioned, like, there's no need to directly use OAuth libraries. Right. So does that mean that you can use this to authenticate, like, a Facebook OAuth implementation or Google? I think so. Because they don't mention like any other services that are provided. So I'm like, oh, well, and maybe they don't need to because if it's just a protocol, then,

you know, it should just adhere to the protocol. So why would you need to? But that's what I'm trying to understand. Yeah. So they've even got a thing on here for OAuth 2 in the implicit flow. So here, I'll read it. Our goal is that the library abstracts enough of the protocol away so that you can get plug-and-play authentication. But it is important to know and understand the implicit flow from the security perspective.

So that is the goal, right? Like you can truly plug this thing in and i would imagine if you had something like facebook or google authentication or whatever as long as you have those um connectors set up for it then it should work i'm trying to look down here and see if they've got anything for it man well now you might be able to finish that next uh cloud app those support of a billion users because you'll have authentication solved right it's it's pretty crazy. When I heard this, I was like, really? I just loved where you started because I immediately thought back to those jokes about the a billion users and trying to solve authentication first.

Yeah, yeah. I mean, I'm going to scale to the planet. Yeah. But first, I got to authenticate somebody. So, yeah. Definitely check it out. Pretty cool stuff. It's one thing that I thought about so many times.

Like, man, I should just write this because it's way too hard. But apparently somebody already did. They beat you to it. They did. I'm fine with that. All right. Well, with that, Joe, you want to summarize this tip again? Oh, yeah.

I like to throw out those tips again. This was number 60, which is to organize around functionality, not job functions. How do we all feel about that one? I kind of like that one. I'm down with it. Yeah, I think we got to a good place on that one where we could all agree. All right. Yep.

So with that, subscribe to us on iTunes, Spotify, Stitcher, and more using your favorite podcast app. And like I asked earlier, be sure to leave us a review if you haven't already. We would greatly appreciate it. You can find some helpful links at www.codingblocks.net slash review. And while you're at codingblocks.net, I've got a show notes, examples, discussion, and more. I knew he was going to be all up in my Wheaties. So is that going to be the thing from now on? We're going to all try to do that?

That hurt my brain. I can't take it. I was trying to listen to it. It was like, wait, who's saying what? I knew he was doing it too. So yeah, if you haven't, check us out on Twitter at CodyBlogs. Head over to CodyBlogs.net and you'll find all our social links there at the top of the page. With that script flipped.

And don't forget to send your feedback questions and rants to Joe on the Slack channel. Yeah, totally. It's Jay-Z something crazy now. It changes from week to week. It's always something crazy, but yeah. Can I say what it is? Yeah, please. It is Jay-Z, the Quetzalcoatl.

You guys familiar with Quetzalcoatl? No. Oh, Alan, I didn't expect it from you, but come on, Outlaw Quetzalcoatl? No. You need to play more video games. I don't even know how you spell it. It's the dragon of either Aztec or Mayan. I forget.

Mayan. Maybe. Crap. I don't know. I know what you're talking about. That don't know that's bunk anyway that's how I feel about Kotlin though I'm eating the world and I require human

sacrifices laughter laughter laughter music music