0:00 Brad How much value are you really getting from your human reading your code anyway?
0:23 Scott Welcome to the latest and greatest episode of the How Many CTOs Does It Take podcast. My name is Scott Porad, and this is my trusty co-host,
0:33 Brad Brad Hefta-Gaub.
0:35 Scott Brad, I heard through the grapevine. Of our chit chatting and text messages where our listeners don't probably know is we're always just kind of sending text messages back to each other. But you texted me about Uncle Bob this morning and I didn't totally know what you were talking about. So I said. Let's talk about that on the podcast.
0:57 Brad Well, yeah.
0:58 Scott And so teach us about Uncle Bob.
1:00 Brad Well...
1:00 Scott I know Uncle Bob only in the furthest distance, which is when I hear the name Uncle Bob, I think to myself, well, that's a famous old timey computer guy. And I don't really know a lot more about Uncle Bob than that. So why don't you fill me in and fill the rest of that. 40 other people who are listening today on
1:16 Brad this Yeah,
1:16 Scott thing.
1:17 Brad well, Uncle Bob is a famous computer guy, old timey computer guy. I think you got that right. He's most famous for a bunch of books that he wrote. Clean Code is probably like his most famous book from like 2009. He was one of the signers of the Agile Manifesto. He was kind of one of the One of the early – so he's written books on agile principles. He was a big C++ object-oriented guru back in the day. So back in the 90s, he wrote designing object-oriented C++ applications. So basically has been writing books since the mid-90s. Before that,
2:04 Brad he spent – 20 or 30 years in as a you know hands-on developer for a bunch of different companies i'm sure he's he's also constantly writing code you know he's not
2:15 Scott just Mm
2:15 Brad a not just an author he worked for teledyne i guess he's big in the he was big in the early late in the in the 70s and 80s and the 90s he worked in telecom and writing like low-level systems code for telecom companies
2:31 Scott Oh, so he lived through the personal computer revolution from the 70s to the 80s to the 90s.
2:36 Brad Yeah, exactly. Yeah,
2:37 Scott That's
2:38 Brad I think he cool. described his own backstory of like got his first computer at 15 years old in 1967, right?
2:46 Scott Oh, wow. That's cool.
2:47 Brad So you're right. He's an old timey computer guy. That's for sure. That's for sure accurate.
2:56 Scott Bob Martin, right?
2:57 Brad Bob Martin, Robert Martin. Yeah.
2:58 Scott Yeah.
2:58 Brad Oh, yeah. Goes by Uncle Bob. I sent it to you because he's blowing up on the Internet today because, well, first of all, he was basically in some podcast. And honestly, we probably get him on the How Many CTOs podcast. He may be a fun guest to talk to.
3:15 Scott Yeah, it would be.
3:16 Brad He was on some podcast and basically the podcaster was talking about agentic programming and said, hey. But hey, tell me what you think about agentic programming, especially this guy that's like supposedly, you know, hey, it's all about code. It's all about clean
3:28 Scott Hmm
3:28 Brad code. And he basically said in the podcast interview, he's no longer reading the source code from his agents. That's the headline. That's the that's the thing that got pulled into the Internet zeitgeist. And if you watch the podcast, he actually goes deeper into it. And he basically and part of why I sent you the link to the podcast is because he basically said in the podcast what I have been saying all along, which is, you know, the the 3000 line thought experiment, right? Like you have a developer who shows up, he didn't use this, this is my thought experiment, right? But he basically describes like, hey. These things write code really fast. You need to have systems around it, control systems around it that
4:15 Scott Mm
4:15 Brad ensure
4:15 Scott -hmm.
4:15 Brad the quality of the code. And so what do you think the things that he lists that are the control systems around it to ensure the quality of the code? Automated unit test,
4:24 Scott Yeah.
4:24 Brad right? Automated end-to-end tests. Um, other sort of like, you know, uh, you know, acceptance criteria around architecture, right? Like you can, you can have static analysis of architecture, right? Um, all kinds of stuff like that, you know? So he listed all of these different things, which basically just, in my opinion, just boiled down to like, Hey, that's what I mean when I talk about. quality sdlc engineering
4:54 Scott Mm-hmm.
4:54 Brad practices and
4:56 Scott Mm-hmm.
4:56 Brad i mean i i i feel like it's not that shocking of a thing for a very senior engineering leader who's been writing code and working with engineers on writing code for 60 years to basically say Well, if you've got lots of control systems in place, not, you know, the decider, the approver doesn't have to read every single line of code.
5:33 Scott Mm
5:33 Brad That
5:33 Scott -hmm.
5:33 Brad doesn't sound shocking to me. But he's blowing up the internet right now because some people are like, oh my god. The author of clean code is no longer reading the code. Right. And you can get lots of people debating the pros and cons of that.
5:48 Scott Well, what's interesting is the author of Clean Code can probably feed a PDF of Clean Code to the agent and say, follow this.
5:56 Brad Exactly. Right? Exactly. Exactly.
5:59 Scott Yeah.
6:00 Brad I mean, that's kind of what you and I talked about recently where we were just kind of like we were talking about taste. What is good taste? And I think you asked, you know, as it relates to coding and you asked the question, like, is it definable? And I'm like, well, certainly like. Clean code is definable. It's written down in many books. Good architectural patterns are written down and have had plenty of debate about them, and there's consensus. So that's all verifiable.
6:31 Scott I'll tell you where my mind first went to, and maybe we're just going down paths that are well-worn. If I know that I need really good quality controls, I think it is easier to get those in place when I'm building something Greenfield. And if I have a pre-existing system. Without those things, it's harder to add those things after.
6:57 Brad Are you going to try to get me to argue with you on that?
6:59 Scott I am not going to try and get you to argue with me with that. What I'm trying to say is where my mind, yes, argue with me on that. Where my mind goes is, okay, I need to solve the how do I add these quality controls to my existing lines of code. Like my new services that
7:22 Brad Okay,
7:23 Scott engineers
7:23 Brad sure.
7:23 Scott are creating can have amazing quality controls, but the thing I need to fix, not fix, but address is the existing stuff where it didn't have that. what is an effective and efficient way to do that? So there's an effective way to do that. It's pure brute force. And I'm sure that if you set a smart engineer down for a long time, they could go figure out how to get a bunch of coverage on there. And I'm certainly sure if you told an agent to go write a bunch of unit tests, as you go up the ladder of tests from like unit tests to integration tests to end-to-end tests, somewhere in there is acceptance tests. I'm not really sure how they're different. different than end-to-end tests really but as you work your way up the stack it gets a little harder for the agent to what's the word I'm looking for when you look at the code and you reflect to you know to deduce what the test should be from the codes I just where I went to is like okay most CTOs out there have the I have a bunch of existing code without quality around it
8:32 Scott problem. And it's great that Uncle Bob is not looking at his code, but is that the case true when he's like going into a system that, let's say, is like Microsoft Word and it's been around for many, many years and had many, many people work on it and so on and so forth. Although I bet Microsoft Word probably has amazing test coverage. That's probably moot. You get my point, I hope. So I'm not being skeptical of Bob. I'm actually just thinking my mind goes, for most of the CTOs out there, how do they solve this problem,
9:04 Brad How do they...
9:05 Scott right?
9:06 Brad yeah how do they use the advice like hey you can you can pay less attention to reading the code if you have great you know controls already in place and if
9:16 Scott How
9:16 Brad you're the kind
9:17 Scott do I
9:17 Brad do i
9:17 Scott that? How do I get really good controls in place?
9:19 Brad have controls in place then what do i do right
9:20 Scott Then what?
9:21 Brad okay so so first of all i love that train of thought and i think that you're right like this is our well well trod path right this is like untangling the ball of mud this is This is the,
9:32 Scott Right.
9:32 Brad you know, how do you deal with like older systems and how do you modernize older systems, right? Okay, so let me just say like, I agree there's that that's the thread that we might want to pull on. I'm going to. there's another thread we could also pull on let's say so you know i always i like it you know when you when you read a wikipedia article about like a a war in history or something like that you know on the right hand column they always have the list of belligerents right
10:00 Scott I love that.
10:01 Brad right so okay so in the war over uncle bob's no longer reading code what are what are the belligerents who are the belligerents and what are their positions right Right. And one of the list of the belligerents would be probably people saying, oh, my God, I can't trust code unless I've read every line of it.
10:24 Scott Mm-hmm.
10:24 Brad You know, other belligerents are probably saying like, well, you're probably kidding yourself if you think you reading the code is actually doing that much quality control. And that's why we need these other systems in place instead. So I think one of the threads worth pulling on. is how much value are you really getting from your human reading your code anyway?
10:45 Scott Well, okay, so I'm thinking of a human code review, and I'm thinking there are two or three things that are probably the primary categories of exposure. In there. One is bugs. Hey, this isn't written properly. And I actually bet that's kind of the minority of things. Another category is what I'll just broadly call architecture, which is like, hey, you didn't design this very well, right? This is going to be brittle. and then I would say that actually blends itself into a I guess there's sort of two variations on architecture one is you didn't do it very well but then the other is like hey if you did this just a little differently like
11:31 Brad It would be better bet
11:32 Scott it would just be a lot more flexible and whatever better
11:35 Brad or better somehow.
11:36 Scott better somehow right so that's kind of like the second but it has two flavors of it and then the third is the well I see you're using this library here but did you know that like Like these other guys use this library over there and maybe we should only use one HTTP library around here kind of thing. And I suspect, I don't think, I think it's probably the first bucket is 10%. The second two buckets are 25% and the last bucket is 15%.
12:07 Brad Oh, that doesn't add up to 100%.
12:08 Scott You're right, it only adds up to 75%. But we're operating in base 75.
12:15 Brad Okay, so I love it. So I love that that's where you got to when I asked the question, what does reading the code actually do? Because Uncle Bob has an answer to those second two categories. And he says that's what he's instead spending his time on. So he basically says, look, I have the agents justify their implementation to me and I have the agents. Agents build me a visualization tool so I can see how did they architect the code? Did they follow the practices of clean code, good architectural design, the stuff that exists, his definition of what clean code is, his definition of what good. So in other words, if he was already looking, if he was going to read the code,
13:02 Brad he would be looking for those second. second two categories, and those categories are actually able to be discerned and in fact could be discerned better without necessarily just reading the code.
13:15 Scott And then this gets to another thought. It's a little bit of a variation. So like we have talked at TaskRabbit, we have a code review agent does code review for us. And we've talked about building two other types of agents to be in our pipeline. One is an architecture agent. Does this comply with what we refer to as our target state architecture, what we're trying to build towards?
13:40 Brad Yeah, you should
13:41 Scott And
13:41 Brad absolutely do
13:42 Scott the other is a security
13:43 Brad that.
13:43 Scott agent. which
13:46 Brad Yeah.
13:46 Scott is, you know, that looks to see if it's secure. And we've actually talked about those could be targeted at two different points in the pipeline. Obviously, one could be they could be they would be different agents, but there could be one targeted post code just like the code review after it's been written. Does this meet whatever architecture and security standards we have? But also further upstream, could you give it some sort of design doc, either human generated or
14:10 Brad Absolutely.
14:10 Scott Asian generated to look at that also? And where my thought goes there is, okay, we are trying to build a service oriented event based architecture, right? We are building it. For a variety of reasons and a combination of Ruby and TypeScript, and I know that sounds unusual, but we don't need to go into that part of it right here. I got some people who want to write an architecture agent and they want to write a security agent. can't I just buy that like why why are we going to write the type script event-based architecture agent it just seems like that should be seems like the guy like uncle bob should write the book and say this is how you do it and then all of us can just follow the best practices
14:53 Brad Yeah, I mean, I hope that whoever says they're going to write this agent for you really just means they're going to collect all the markdown files that list the rules that matter. matter right like that's all that really should be
15:05 Scott But
15:05 Brad it's
15:05 Scott who made the
15:06 Brad yeah
15:06 Scott rules the rules that matter could be standard they could be a github library or github github repo just standardized across
15:12 Brad but your architecture like you guys have a target architecture so describing the target architecture that you believe is correct is not going to be out of some book from you know
15:22 Scott There are layers there's a first layer of like kind of technical principles and then there's the actual design of like like have
15:29 Brad Yeah.
15:29 Scott this service and have that service that's right that part i'm talking about that first layer
15:33 Brad Let me just say I 100% agree. One of the things I'm now starting to see with the teams I work with that is, I think, really paying off is. we all like they're all running multiple different agents looking at code and they're and so like one developer says i want my agent to go do a code review of this and the way that that developer has configured their agent to like he's really focused on security and correctness so he has told his agent this is what i want you to really focus on you know You know, and,
16:08 Scott Mm-hmm.
16:09 Brad you know, others have others have said other things to their agents. And the result is you get, you know, the more times you run through the probability machine, you get slightly different answers every time you run through the probability machine. And the more slightly different answers you get allows you to get a higher quality answer, right? Like you get if you combine multiple different versions, you get a higher. a higher quality answer right
16:34 Scott Mm
16:35 Brad and
16:35 Scott -hmm.
16:35 Brad i think i've said this to you before like i i actually think that's why isn't it the case before ai existed didn't weren't there some modules in our code bases where we'd go like this is a very sensitive module it requires two reviewers to approve right don't we have modules in our code where that
16:51 Scott Yep.
16:52 Brad we're like this one's this one needs two reviewers right well that's what is that if it's not Two different runs through the probability machine. They happen to be the meat sack version of the probability machine instead of the silicon version. But it's two humans that are reading through the code and they each see different things and they comment on different things and the combined answer is the better answer.
17:17 Scott meat sack agent I feel like that needs to be like a a cartoon agent meat sack jesus there's always a moment in every episode where we get totally off the rails and this agent meat sack is it there's
17:34 Brad agent meat sack well anyway agent
17:37 Scott the title for the episode right there agent meat
17:40 Brad meat sack
17:40 Scott sack
17:40 Brad there you go i guess the thing i'd say is like i don't think it's that controversial To sit like again like you like I challenge you as a CTO like you're not doing code reviews, but you're accountable that the code is is high quality How are you solving that problem?
17:58 Scott A series of checks and balances and processes that start all the way with our recruiting and hiring pipelines, right? You know, I mean, step number one is you just get the smart people in the room who've got good skills and talent and taste and ambition. care enough about doing a good job and a lot of it takes care of itself but it's interesting what you yeah so that's that's the answer the answer is we've got a bunch of processes and checks and balance in place and that's how code can ship all day long and I don't have to worry about it although from time to time there
18:39 Brad It breaks.
18:40 Scott is something I
18:41 Brad It gets through.
18:42 Scott wasn't going to say it breaks from time to time there are things where I'm like I want to take a look at that And I might not even want to take a look at the code. I'll tell you very specifically what's coming up. We are moving our production infrastructure to a different AWS region. I don't remember. I always get them mixed up. I can't remember what region we're in, but it's like one of the regions that's like low on their total polls. So like we get all the updates last in whatever region we're in.
19:07 Brad Right.
19:07 Scott And it also only has two availability zones and we want to have another one. So we're moving. I can't. We're moving to Oregon, I think. It doesn't matter. Those details don't matter. But this is one place where I said to our head of infrastructure, I was like, okay. I would like to see your rollout plan. And the two things I'm specifically interested in that plan are I want to see action item level detail, like who is doing every single task. And I want to see the rollback scenarios.
19:39 Brad Yeah. Which ones are there any one-way doors?
19:42 Scott Great. Are there any one-way doors in this? And just because my experience is when doing a risky maneuver like that where you're trying to move your entire infrastructure without actually taking your system offline, if you have implicit...
19:59 Brad things that people are going to do that is risk oh that's right we were supposed to have so-and-so turn
20:07 Scott Right.
20:07 Brad off the flux capacitor before Right. we did that you
20:10 Scott Rats.
20:11 Brad know um and yeah the one-way door thing so there are times and there there Few and far between, but this is a very high risk time because you could imagine you could end up in a state where you're offline
20:25 Scott Right.
20:25 Brad and you can't
20:26 Scott And get right.
20:26 Brad back online.
20:27 Scott And so I chuckled because there's been two times in my career when I had some very. high risk maneuvers to transfer data centers and the one that flashed in my mind this was not that high risk but when real networks moved from our first office down in Pioneer Square to our second office in the in kind of downtown core our our kind of head of IT slash you know graybeard who was in charge of all the things he had one computer that he definitely did not want Want the clock to reset on and so he had he had it hooked up to a you know a UPS battery that was like you know he had it had that on the battery as he rolled it down the second avenue to go between the two buildings he's like I
21:16 Brad Wow,
21:17 Scott am not going to let this I'm not going to let the runtime on this computer get reset and it was
21:21 Brad just I
21:22 Scott it
21:22 Brad wonder what was running on that thing.
21:23 Scott was nothing important it was nothing important it was just the it was the matter of pride that he wanted the the uptime to you Maintain.
21:31 Brad Oh, I see. He wanted the uptime. I thought you meant he didn't want the clock on the machine to get messed up.
21:38 Scott No,
21:38 Brad He
21:38 Scott it was
21:38 Brad just wanted
21:39 Scott just the he
21:39 Brad runtime.
21:39 Scott just
21:40 Brad That's
21:40 Scott wanted the funny. uptime. He just wanted the uptime.
21:41 Brad That's funny. Yeah, those were the days. I do remember if we can just share war stories for a second. We moved data centers when I was at drugstore.com. It was an eight hour outage overnight and it consisted of going with a truck to one place and putting computers in it. and driving it to the other place and getting them all plugged in before morning so
22:00 Scott Yeah.
22:01 Brad anyway so the point is uh yeah there are checks and balances and but even sometimes i do want to check because i would hate for our company to get in a really extremely compromised position.
22:15 Scott Well, and the point that I'm making about that is that even in your answer, you you had a system for what you were going to validate. Like, I doubt that you are going to say, show me, let me read the code of every script that you're going to run during this. Instead, you you kind of zoomed the camera out to the next level and said, and you interrogated the operators to say, like, what is your plan? Give me a very detailed. detailed plan here and
22:41 Brad Yeah,
22:41 Scott i and
22:41 Brad that's
22:42 Scott what i'm
22:42 Brad right.
22:42 Scott saying is that the point i'm trying to make is that there's way more that i believe that there's way more value in the review that whatever review you're doing that review is much more about a conversation with the people that are doing the work or did the work about did they consider all the things and
23:08 Brad Right, right.
23:09 Scott and even if i'm talking about code did you consider all the things you know that is the conversation that matters and having me like read individual lines of code i mean i can i i can do it i enjoy doing it there's value in it i love the the poetry of looking at code like there's there's something artistic about it i like
23:34 Brad Yeah.
23:34 Scott it but i've never just read the code anyway i'm always going to be like reading the code and asking the developer who wrote it like tell me more about why did you do this what was this that you were doing anyway like what was this about right
23:50 Brad Yeah, yeah.
23:50 Scott Because that's going to reveal so much more. Like the only thing you're going to get out of reading the code is did they put the braces in the place? Well, you should be using a linter and a pretty printer to get the braces in all the right places. Like I shouldn't be wasting either of our time on that.
24:11 Brad Yeah, I think there's also two other lessons here for CTOs and aspiring CTOs that are worth mentioning. The first is when you have to go to your boss or your boss's boss and present something, it forces you, well, in theory, it should force you to get your ducks in a row. I sometimes have to go to the CTO and the senior leadership team or to our board of directors and present things. And there's just as much value in the fact that I need to make sure what I'm presenting is right than that they actually. I shouldn't say they don't care, but like they're actually presenting to them, right? I
24:53 Scott Yeah.
24:53 Brad find that especially with the whole board presentation thing is it's really a very effective forcing function to be like, oh, here's a whole thing that we don't have. We need to get we don't have this thought through and we need to get this thought through because that is definitely a question they will ask and they're only going to ask out of a place of ignorance and stupidity because they don't know anything that's going on in our world, but they're just going to say what happens. Why does it work that way?
25:16 Scott And right, and you better have an answer.
25:18 Brad And you better have an answer. And so as a CTO, like I don't, some people I think wield that tool punitively, like they want their team to fear them and maybe they don't even want their team to fear them, but their team does fear them. And so I don't do it that way, but it is an effective tool sometimes to just say, look, I'm, you know, the person who's leading this is, her name is Megan, just say that and it's like,
25:41 Scott oh.
25:41 Brad nope she has to go actually like get her ducks in a row then the other piece that i think is important for ctos again in aspiring ctos as the cto i am the face and the voice of the organization now as my team knows i try hard to put them in front of the company as much as possible i don't try to hog the spotlight in fact that's i've been given that criticism which is scott you're not out in front enough i'm like okay well that's not my style i want to be here but at the end of the day when push comes to shut shove and there's a giant outage or whatever you know they're going to come talk to me and
26:13 Scott Yeah.
26:13 Brad in advance of this i want to be able to tell the story to our company we have a community an outward communication plan in advance to tell the story to people of what we're doing and i want to know about it enough to be able to tell that story and i also want to know about it enough so if it does go wrong i can speak authoritatively to what was happening and
26:35 Scott Yeah.
26:36 Brad so I think the point there is an important part of our jobs is to be the representative and the voice in the face of that engineering team to the rest of the company and I guess I feel like it's important to do that job well it builds trust with our team it builds trust in our team if we can represent our teams well and it isn't just about the engineering it isn't just about But it isn't just about the scripts and are the really braces in the right place. It's all about the whole story of why are we moving these regions? Why are we doing it in September and not December? Why is this going to save us money? What you know, it's so and so forth. And what's your how do you know it's not going to screw up and all these things?
27:15 Scott Right. And I feel like just if we circle back just to kind of, you know, kind of attach these two threads together, right? Like, you know. The Internet's up in arms because Uncle Bob says he's not reading code anymore and he's the author of clean code. What the heck? Right. And then you're giving an example of and I and I agree with everything you've said, by the way, you're giving an example about how as CTOs do we do a good job of really representing our technical teams and representing the technology like what is the right level of of detail that we need to be paying attention to? And what I'm saying is I absolutely agree that you need to basically both build systems for quality and you need to spot check, you need to set a break point in the debugger every once in a while and double check like.
28:06 Scott what what what is the current state of the stack and what is the current state of the variables like what are people doing yes we have this program that we're all following but like in this case are they following it correctly are they getting the right results right and um so i definitely agree if if you know advice i would give to aspiring ctos or spying engineering leaders is i would say it is really important that you be be strong technically and be able to. have those technical conversations with your team members to make sure that you don't have to review every line of code they write. You don't have to review every decision they make, but you need to spot check it and you need to make sure that they trust that your judgment is good technical judgment.
28:56 Scott And
28:57 Brad Mm
28:57 Scott the best
28:57 Brad -hmm.
28:57 Scott way for them to trust your technical judgment is for you to, when appropriate, You know, be in the mix with them and really have a conversation with them about the choices that they're making.
29:10 Brad That's interesting. Here is where we might have a little bit of a point of disagreement.
29:14 Scott OK, good.
29:14 Brad I do want to get back to Uncle Bob because I have an observation about what he's doing that I didn't get a chance to make. But as I've gone on in my career, I've been much more about the getting in with the team. I get in with them a lot less, but I'm actually getting in more like specific points, right?
29:35 Scott Yeah.
29:36 Brad And there's just a few of them and I can articulate what they are, okay? There's certainly one-way doors, like are we creating a one-way door for ourselves here? They are high-risk operations, like this data center move we're talking about. They are sometimes, although slightly less so, data model designing. And I want to give a little bit of an example of that one, and I find it a humorous one.
30:03 Scott Okay, sure.
30:05 Brad Back when I was at Rover. We were doing dog walking and we were in our mobile app. We were making it so that like the dog walker could send like a report card to the owner, like here's how the walk went and track the GPS of the walk. And then if the dog. uh peter put on the walk or a few different other Yeah. things you know that the walker could push the button i remember talking to the engineer who was working on this that was like super cool and i was like hey are you saving the lat long of where those p's and poos are happening he's like no that's not in the requirements and i was like you should save those I don't know why we're going to need that data, but my gut just tells me that someday that data is going to be important.
30:51 Brad I don't know why. Now, that's a really silly example because I'm sure that data has never been important, although Rover now is probably sitting on a decade worth of where dogs have peed and pooed all around the world. I did, when I worked at Rover, I bought the domain names pmap and poomap.com. Rover still owns those. So if anybody is working at Rover, you can build those maps. but my point is i think sometimes as the cto you have an intuition of like okay this wasn't in the requirements but we should probably do this they're
31:22 Scott Yeah, 100%.
31:23 Brad saying this doesn't need to scale but yeah yeah
31:26 Scott This one's gonna,
31:27 Brad or
31:27 Scott yeah.
31:27 Brad even actually there was an example today what was it today we were talking about oh bundling Okay, we have a customer, a partner who they're a storage unit facility and they want to do and we their partnership with us is people need to have stuff delivered in and out of a storage facility. and they want to actually do a partnership, deepen the partnership whereby you can actually buy the storage and the delivery together, right? And so we have to sort of build this bundling thing into the system.
32:02 Scott Yeah, totally.
32:02 Brad And I was just saying, I was like, I know it's not a requirement here, but I just might, we need, we would be really short-sighted and really unwise to not build sort of a generic reusable. bundling capability for third-party services because we
32:17 Scott Yeah.
32:17 Brad don't sell the storage and like i don't know if we'll ever have another partner that needs this but if we do have another partner that wants this like sure
32:25 Scott Shipping.
32:25 Brad who knows what i have no idea like it's just not on the radar but it's just just in my experience i think that's an important thing as a cto
32:31 Scott Yeah,
32:32 Brad is to
32:32 Scott I agree with that. I agree with that.
32:33 Brad those are those are four places right one-way doors high consequences sort of some intuition about What a requirement shouldn't be. I think there was a fourth one I listed that I'm forgetting. I've narrowed it down. And the other places I think it's a good team, they'll figure it out.
32:51 Scott Yeah, I love that. I love that. And I agree with you. And all I'm saying is that the fact that you say, hey, these are a handful of important things that I would like you to, you know, like loop me in on when you when you hit one of these, because, well, and I think that that's that's what I mean by setting the breakpoint in the debugger. You know, I don't and you know, it might be the case that like. Another case, another example I can think of that would be another place where as a CTO with, you know, hundreds of engineers or something like that working under you, you might, I know I've set the breakpoint in debugger at points is when a team, when one team is struggling. And, you know, and if you can find a way to basically be like, hey, let's, you know, maybe it's a skip level one on one or something like that where like talk to the EM and just be like,
33:39 Scott hey, tell me tell me more about what's going on here, you know, and
33:42 Brad Yeah.
33:42 Scott how is, you know, what are your teams struggling with? And. You know, especially if there's, you know, if you can open up the GitHub and you can open up the, you know, the Kanban board, whether that's Jira or whatever, and look at the real-time dashboard that might inform you, be like, oh, like there's actually something going on here. This team is struggling in the following way.
34:08 Brad That leads into another example. When a project has an estimate that is substantially different than what your gut would tell you.
34:16 Scott Yeah, that's another good one.
34:19 Brad And I always approach those from a point of curiosity of
34:22 Scott Yeah, totally.
34:23 Brad thinking, I have an example I use that's from a time at Rover. There was a time at Rover when you could only book an appointment like 30 days, a sitting like 30 days in advance or something. And someone was like, well, we have to make this, you know. further out in advance and i assumed yeah
34:37 Scott There'd be a place
34:37 Brad we
34:37 Scott like one place in the code where it says 30
34:39 Brad 30
34:40 Scott days.
34:40 Brad yeah and they could change it to 365 and then we get this big estimate back and i go to the engineer his name was john and i was like could you um actually his name was john and uh but that's john in a language that i'm not sure it's language uh maybe russian perhaps that's ivan i don't know anyway uh i was like what's what's with this estimate he's like well actually let me just show you all the places in the code that need to respect first of all there is no variable like you're thinking so i can put that in but then let me show you all the places of the system
35:13 Scott I'm going to have to go change.
35:15 Brad that actually have to respect this and it was just stuff like the date picker when you're booking your thing and this place and there were 21 places that had to if you put this new thing in that had to respect this and then there was also things and the web app and the mobile app right so they had to get data from the back end and stuff like that i was like oh okay so i think those are opportunities also to learn about maybe complexity of the system that i don't really understand And sometimes that leads to frustration where you're like, oh man, who coded it this way? This was terrible. Now we're
35:49 Scott Right.
35:49 Brad having to clean it up. But lots of times it just helps understand the details of the system better.
35:53 Scott And I love that story. I love that approach. And I think that, you know, approaching these things with curiosity, that's exactly the right tenor to take. Right. Like, you know, and just be like, hey, tell me more about this. Help me understand what, you know, tell me more about this.
36:08 Brad We go back to Bob for a second.
36:09 Scott Let's go back to Uncle. Don't
36:10 Brad The
36:10 Scott go by
36:10 Brad Uncle Bob and then we'll wrap it up. Okay. I was a little surprised actually when you told me, so Bob said he didn't review the code and I thought you were going to say, but he did review, he did like look at the architecture and, but then you actually said he had agents looking at the architecture and
36:25 Scott Well, just
36:26 Brad that, and
36:27 Scott to be clear,
36:27 Brad like writing him some reports about it.
36:29 Scott yeah, and to be clear, I don't know exactly what his system is. So I don't feel like I can comfortably like he didn't show on the screen like. Like, you know, his, you know, whatever these reports are, I would assume that he. like the parts of the code that he has to look at to verify that the architecture that the modules are the modules that the the APIs are the APIs like I assume that that's what he means when he says give me a report that shows this architecture right
37:01 Brad The
37:01 Scott like
37:01 Brad notion of a report is interesting because often I think about an architecture agent which is just saying yes or no. versus an architecture agent which is saying i've looked at it and here's what i see which is like almost like an x-ray vision that's
37:20 Scott Yeah, that's what I understood him to be describing as his product.
37:24 Brad pretty cool that's pretty pretty cool uh i don't know uncle bob do you know uncle bob
37:29 Scott I mean, in person, no.
37:30 Brad I wonder how many degrees of separation we are and if we could get Uncle Bob on this podcast.
37:36 Scott We'll definitely reach out to him like he's on Twitter. You know, I'm sure he'd be willing to come and defend himself.
37:43 Brad I wonder if we get Kent Beck on this podcast.
37:47 Scott That's good. You said you're working on that.
37:50 Brad I wasn't working on it, but I actually think I will work on it. I'm a little, honestly, I'm a little afraid to have Kempak on this podcast.
37:58 Scott Because he's so famous.
38:00 Brad He's very famous. I think he's very smart. So I'm a little intimidated by that. He has a perception of maybe being a little curmudgeonly. So
38:12 Scott That is
38:12 Brad I wonder if that place
38:13 Scott Uncle
38:13 Brad is still.
38:13 Scott Bob, by the way.
38:14 Brad Oh, is it right?
38:16 Scott Yeah.
38:17 Brad So, you know, I'm a little nervous of maybe getting sliced up with my bad ideas getting sliced up. I don't know. But it'd be fun. I once it
38:25 Scott was You ask
38:25 Brad at a conference.
38:25 Scott him how to untangle the ball of mud and he'll be like, don't ever create a ball of mud. That's how the answer is.
38:32 Brad Yeah. I was at a conference called Agile Open Northwest about 2008. 2007 2008 2009 somewhere in there and there was a session called agile from the old timers and it was three individuals one of them was ward cunningham i think the another one was named rob name starts with an s i think anyway three individuals who were they they were they they were people who had signed the agile manifesto
39:04 Scott Yeah.
39:05 Brad and it
39:07 Scott I
39:07 Brad was
39:07 Scott bet you it might have been Uncle Bob, dude.
39:09 Brad it could have been i don't remember most he
39:12 Scott Robert C. Martin, you know?
39:13 Brad could have been there i don't really recall but uh i remember ward mostly and um they were just telling the story of like how it came about and you know what their experience was and it was i really treasure that that memory because it was so It was just so neat to hear the origin story from the. mouths of the origin.
39:36 Scott Right.
39:36 Brad It was really, really cool.
39:38 Scott Yeah. Well, that's by the way, that's a great note to end on. And I will say that the only other thing I'm going to say about the Internet blowing up about Uncle Bob is there's another sort of skirmish happening, which is the he's right and he's wrong. But the other skirmish that's happening is who the F cares? Why do we care anything about what Uncle Bob has to say?
39:59 Brad ever done and Hmm. and
40:02 Scott That's interesting.
40:03 Brad i i think that's a i'm i was intrigued by that answer because or that that stance because it's like i mean he's like he's like kent beck he's like a pretty influential thought you know thinker about quality code
40:19 Scott I mean, it's really interesting. This gets like a fundamental sociological question. Why do we care at all what? Deep thinkers think.
40:27 Brad maybe that's maybe that's what it all comes down to yeah
40:31 Scott Why do we care what professors say and all those types of folks? maybe Maybe we shouldn't.
40:36 Brad we shouldn't well i my response is it's not an appeal to authority but like yeah if someone's got a lot of experience and they offer an opinion then i I want to like consider that opinion and think about it and interrogate it. And it happens to be, you know, I've got confirmation bias going on here. It happens to be that I also agree with the stance that he's taking, which is that it like I think people fool themselves when they think they're catching bugs by reading code like they're not.
41:07 Scott Yeah.
41:07 Brad And so do the other stuff because the other stuff is going to get you so much further.
41:13 Scott Here's the answer. Over his career, Uncle Bob has said things, had theories, advocated for things that came to be true. I don't know what those things were, but he advocated for engineering practices that turned out to be good practices that helped engineers do better engineering, do better work, enjoy their jobs more.
41:35 Brad over
41:35 Scott And so he's earned the right. To
41:38 Brad to
41:38 Scott say
41:38 Brad have something some exactly
41:39 Scott and have people say it's meaningful.
41:40 Brad that's right and then to have them interrogate it and look at it and try to take it apart and understand it i think that's i'm all for people like debating it yeah
41:50 Scott And I'm sure he is too.
41:51 Brad i'm
41:51 Scott Well, I don't know. maybe he's not. But that's why sociologically it matters what he says is because the proof is in the pudding. He has shown us that what he says is meaningful.
42:03 Brad Exactly. Awesome. Well, there you go. That's the summary. What do we say?
42:08 Scott Smash, rate, and review.
42:11 Brad Smash rate and review.
42:12 Scott Tell all your friends. Tell your mom. Have your mom tell everybody else when she's out playing Mahjong or knitting or at the tennis club or whatever your mom does, and then we'll hopefully get 45 people listening to this podcast.
42:25 Brad There you go. All right. It's All good talking to
42:28 Scott right, until you, next
42:28 Brad Scott.
42:28 Scott week, Brad.
42:29 Brad See you next week. Bye.
42:30 Scott Bye.
42:31 Brad This episode of the How Many CTOs Does It Take podcast was produced and edited by Saffron Hepdegout. Our theme song was AI Generated by Brad.
42:40 Scott Please follow us on all the social media platforms at How Many CTOs Pod. You can find us on YouTube, LinkedIn, Instagram, Facebook, Threads, X, TikTok, and Patreon, or at our website at HowManyCTOsPod.com. And remember to rate, review, and subscribe on the podcast platform of your choice. Thanks for listening.
