Is Uncle Bob Right? Reading Code vs. Architecting the Future

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.

0:29 My name is Scott Porad,

0:30 and this is my trusty co-host,

0:33 Brad: Brad Hefta-Gaub.

0:35 Scott: Brad,

0:36 I heard through the grapevine.

0:39 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.

0:45 But you texted me about Uncle Bob this morning and I didn't totally know what you were talking about. So I said.

0:55 Let's talk about that on the podcast.

0:57 Brad: Well,

0:57 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,

1:05 well,

1:05 that's a famous old timey computer guy.

1:08 And I don't really know a lot more about Uncle Bob than that.

1:11 So why don't you fill me in and fill the rest of that.

1:14 40 other people who are listening today on

1:16 Brad: this Yeah,

1:16 Scott: thing.

1:17 Brad: well,

1:18 Uncle Bob is a famous computer guy,

1:22 old timey computer guy. I think you got that right.

1:25 He's most famous for a bunch of books that he wrote.

1:30 Clean Code is probably like his most famous book from like 2009.

1:36 He was one of the signers of the Agile Manifesto. He was kind of one of the

1:40 One of the early – so he's written books on agile principles.

1:43 He was a big C++ object-oriented guru back in the day. So back in the 90s, he wrote designing object-oriented C++ applications.

1:58 So basically has been writing books since the mid-90s. Before that,

2:04 he spent –

2:05 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.

2:37 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,

2:45 right?

2:46 Scott: Oh, wow.

2:47 That's cool.

2:47 Brad: So you're right. He's an old timey computer guy.

2:52 That's for sure. That's for sure accurate.

2:56 Scott: Bob Martin,

2:57 right?

2:57 Brad: Bob Martin, Robert Martin. Yeah.

2:58 Scott: Yeah.

2:58 Brad: Oh,

2:59 yeah.

2:59 Goes by Uncle Bob.

3:00 I sent it to you because he's blowing up on the Internet today because,

3:07 well, first of all, he was basically in some podcast.

3:10 And honestly,

3:11 we probably get him on the How Many CTOs podcast. He may be a fun guest to talk to.

3:15 Scott: Yeah,

3:15 it would be.

3:16 Brad: He was on some podcast and basically the podcaster was talking about agentic programming and said, hey.

3:22 But hey,

3:22 tell me what you think about agentic programming,

3:24 especially this guy that's like supposedly,

3:26 you know, hey,

3:27 it's all about code. It's all about clean

3:28 Scott: Hmm

3:28 Brad: code.

3:29 And he basically said in the podcast interview, he's no longer reading the source code from his agents.

3:36 That's the headline.

3:37 That's the that's the thing that got pulled into the Internet zeitgeist.

3:43 And if you watch the podcast,

3:45 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,

3:55 which is, you know, the the 3000 line thought experiment,

4:00 right?

4:00 Like you have a developer who shows up, he didn't use this,

4:02 this is my thought experiment, right?

4:04 But he basically describes like,

4:05 hey.

4:07 These things write code really fast.

4:09 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.

4:17 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?

4:23 Automated unit test,

4:24 Scott: Yeah.

4:24 Brad: right?

4:26 Automated end-to-end tests.

4:28 Um,

4:29 other sort of like,

4:31 you know, uh,

4:32 you know, acceptance criteria around architecture,

4:36 right?

4:36 Like you can, you can have static analysis of architecture,

4:40 right?

4:40 Um,

4:41 all kinds of stuff like that, you know? So he listed all of these different things, which basically just,

4:46 in my opinion, just boiled down to like,

4:48 Hey,

4:49 that's what I mean when I talk about.

4:51 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

5:18 Well,

5:19 if you've got lots of control systems in place,

5:23 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.

5:35 But he's blowing up the internet right now because some people are like,

5:38 oh my god.

5:41 The author of clean code is no longer reading the code.

5:44 Right.

5:45 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,

5:55 follow this.

5:56 Brad: Exactly. Right?

5:58 Exactly.

5:59 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,

6:13 well,

6:13 certainly like.

6:14 Clean code is definable. It's written down in many books.

6:19 Good architectural patterns are written down and have had plenty of debate about them, and there's consensus.

6:28 So that's all verifiable.

6:31 Scott: I'll tell you where my mind first went to,

6:34 and maybe we're just going down paths that are well-worn.

6:38 If I know that I need really good quality controls,

6:42 I think it is easier to get those in place when I'm building something Greenfield.

6:48 And if I have a pre-existing system.

6:53 Without those things,

6:54 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.

7:04 What I'm trying to say is where my mind, yes,

7:08 argue with me on that. Where my mind goes is,

7:11 okay, I need to solve the how do I add these quality controls to my existing lines of code.

7:20 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,

7:28 but the thing I need to fix, not fix, but address is the existing stuff where it didn't have that.

7:40 what is an effective and efficient way to do that?

7:43 So there's an effective way to do that. It's pure brute force.

7:46 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.

7:54 And I'm certainly sure if you told an agent to go write a bunch of unit tests,

7:58 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.

8:06 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 problem.

8:33 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,

8:48 many years and had many,

8:49 many people work on it and so on and so forth. Although I bet Microsoft Word probably has amazing test coverage.

8:54 That's probably moot.

8:56 You get my point,

8:57 I hope.

8:58 So I'm not being skeptical of Bob.

8:59 I'm actually just thinking my mind goes, for most of the CTOs out there,

9:03 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

9:32 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,

9:38 right?

9:38 Okay,

9:38 so let me just say like, I agree there's that that's the thread that we might want to pull on.

9:45 I'm going to.

9:46 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

10:13 Right.

10:13 And one of the list of the belligerents would be probably people saying,

10:17 oh, my God,

10:19 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,

10:27 well,

10:27 you're probably kidding yourself if you think you reading the code is actually doing that much quality control.

10:33 And that's why we need these other systems in place instead. So I think one of the threads worth pulling on.

10:40 is how much value are you really getting from your human reading your code anyway?

10:45 Scott: Well,

10:47 okay,

10:48 so I'm thinking of a human code review,

10:50 and I'm thinking there are two or three things that are probably the primary categories of exposure.

10:58 In there.

11:00 One is bugs.

11:03 Hey,

11:03 this isn't written properly.

11:06 And I actually bet that's kind of the minority of things.

11:09 Another category is what I'll just broadly call architecture,

11:14 which is like,

11:15 hey,

11:16 you didn't design this very well, right?

11:18 This is going to be brittle.

11:20 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

11:46 Like these other guys use this library over there and maybe we should only use one HTTP library around here kind of thing.

11:54 And I suspect,

11:55 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%.

12:13 But we're operating in base 75.

12:15 Brad: Okay, so I love it.

12:17 So I love that that's where you got to when I asked the question,

12:22 what does reading the code actually do?

12:24 Because Uncle Bob has an answer to those second two categories.

12:27 And he says that's what he's instead spending his time on.

12:31 So he basically says,

12:33 look,

12:34 I have the agents justify their implementation to me and I have the agents.

12:39 Agents build me a visualization tool so I can see how did they architect the code?

12:46 Did they follow the practices of clean code,

12:52 good architectural design,

12:53 the stuff that exists,

12:55 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 he would be looking for those second.

13:04 second two categories,

13:05 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.

13:18 It's a little bit of a variation.

13:20 So like we have talked at TaskRabbit, we have a code review agent does code review for us.

13:28 And we've talked about building two other types of agents to be in our pipeline.

13:34 One is an architecture agent.

13:36 Does this comply with what we refer to as our target state architecture,

13:39 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.

13:46 which

13:46 Brad: Yeah.

13:46 Scott: is, you know, that looks to see if it's secure.

13:48 And we've actually talked about those could be targeted at two different points in the pipeline.

13:53 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?

14:05 But also further upstream,

14:07 could you give it some sort of design doc,

14:09 either human generated or

14:10 Brad: Absolutely.

14:10 Scott: Asian generated to look at that also?

14:13 And where my thought goes there is,

14:15 okay, we are trying to build a service oriented event based architecture,

14:22 right?

14:24 We are building it.

14:26 For a variety of reasons and a combination of Ruby and TypeScript, and I know that sounds unusual,

14:31 but we don't need to go into that part of it right here.

14:33 I got some people who want to write an architecture agent and they want to write a security agent.

14:38 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.

15:03 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

15:29 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.

15:35 One of the things I'm now starting to see with the teams I work with that is, I think, really paying off is.

15:43 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

16:08 You know, and,

16:08 Scott: Mm-hmm.

16:09 Brad: you know, others have others have said other things to their agents.

16:13 And the result is you get, you know, the more times you run through the probability machine,

16:18 you get slightly different answers every time you run through the probability machine.

16:23 And the more slightly different answers you get allows you to get a higher quality answer,

16:29 right? Like you get if you combine multiple different versions,

16:32 you get a higher.

16:33 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

16:58 Two different runs through the probability machine.

17:01 They happen to be the meat sack version of the probability machine instead of the silicon version.

17:06 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

17:21 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

17:46 To sit like again like you like I challenge you as a CTO like you're not doing code reviews,

17:52 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,

18:09 right?

18:12 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.

18:21 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

18:46 And I might not even want to take a look at the code.

18:48 I'll tell you very specifically what's coming up.

18:50 We are moving our production infrastructure to a different AWS region.

18:57 I don't remember.

18:58 I always get them mixed up. I can't remember what region we're in,

19:00 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.

19:11 So we're moving.

19:13 I can't. We're moving to Oregon,

19:15 I think. It doesn't matter.

19:16 Those details don't matter. But this is one place where I said to our head of infrastructure, I was like, okay.

19:21 I would like to see your rollout plan.

19:24 And the two things I'm specifically interested in that plan are I want to see action item level detail,

19:32 like who is doing every single task.

19:35 And I want to see the rollback scenarios.

19:39 Brad: Yeah.

19:39 Which ones are there any one-way doors?

19:42 Scott: Great. Are there any one-way doors in this?

19:44 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,

19:56 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

20:19 Few and far between,

20:20 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.

20:36 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

21:01 Want the clock to reset on and so he had

21:05 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

21:30 Maintain.

21:31 Brad: Oh,

21:31 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.

21:41 He just wanted the uptime.

21:41 Brad: That's funny.

21:43 Yeah, those were the days. I do remember if we can just share war stories for a second.

21:47 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.

21:57 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

22:14 extremely compromised position.

22:15 Scott: Well, and the point that I'm making about that is that even in your answer,

22:19 you you had a system for what you were going to validate.

22:22 Like, I doubt that you are going to say,

22:25 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?

22:38 Give me a very detailed.

22:39 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

23:02 people that are doing the work or did the work about did they consider all the things and

23:08 Brad: Right,

23:09 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

23:28 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.

23:52 Like the only thing you're going to get out of reading the code is did they put the braces in the place?

23:59 Well,

23:59 you should be using a linter and a pretty printer to get the braces in all the right places.

24:06 Like I shouldn't be wasting either of our time on that.

24:11 Brad: Yeah,

24:11 I think there's also two other lessons here for CTOs and aspiring CTOs that are worth mentioning.

24:19 The first is when you have to go to your boss or your boss's boss and present something,

24:25 it forces you, well,

24:28 in theory,

24:28 it should force you to get your ducks in a row.

24:32 I sometimes have to go to the CTO and the senior leadership team or to our board of directors and present things.

24:39 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.

24:49 I shouldn't say they don't care, but like they're actually presenting to them, right?

24:52 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,

24:59 oh,

24:59 here's a whole thing that we don't have.

25:01 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.

25:15 Why does it work that way?

25:16 Scott: And right,

25:17 and you better have an answer.

25:18 Brad: And you better have an answer.

25:19 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.

25:32 And so I don't do it that way, but it is an effective tool sometimes to just say, look,

25:37 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

26:08 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

26:32 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

26:59 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?

27:05 Why are we doing it in September and not December?

27:08 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.

27:15 And I feel like just if we circle back just to kind of, you know, kind of attach these two threads together,

27:21 right?

27:21 Like, you know.

27:23 The Internet's up in arms because Uncle Bob says he's not reading code anymore and he's the author of clean code.

27:27 What the heck? Right.

27:28 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?

27:48 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 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

28:33 be strong technically and be able to.

28:38 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 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,

29:03 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.

29:11 Here is where we might have a little bit of a point of disagreement.

29:14 Scott: OK,

29:14 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.

29:21 But as I've gone on in my career,

29:23 I've been much more about the getting in with the team.

29:28 I get in with them a lot less, but I'm actually getting in more like specific points,

29:34 right?

29:35 Scott: Yeah.

29:36 Brad: And there's just a few of them and I can articulate what they are,

29:40 okay?

29:40 There's certainly one-way doors, like are we creating a one-way door for ourselves here?

29:45 They are high-risk operations,

29:47 like this data center move we're talking about.

29:51 They are sometimes,

29:53 although slightly less so,

29:55 data model designing.

29:58 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.

30:07 We were doing dog walking and we were in our mobile app.

30:11 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.

30:20 And then if the dog.

30:22 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

30:41 and i was like you should save those

30:44 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 I don't know why. Now, that's a really silly example because I'm sure that data has never been important,

30:55 although Rover now is probably sitting on a decade worth of where dogs have peed and pooed all around the world.

31:00 I did, when I worked at Rover,

31:02 I bought the domain names pmap and poomap.com. Rover still owns those.

31:07 So if anybody is working at Rover,

31:08 you can build those maps.

31:10 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

31:36 Okay, we have a customer,

31:38 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.

31:49 and they want to actually do a partnership, deepen the partnership whereby you can actually buy the storage and the delivery together,

31:57 right?

31:58 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,

32:04 I know it's not a requirement here,

32:06 but I just might, we need, we would be really short-sighted and really unwise to not build sort of a generic reusable.

32:14 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

32:40 What a requirement shouldn't be.

32:43 I think there was a fourth one I listed that I'm forgetting.

32:45 I've narrowed it down.

32:49 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,

32:56 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,

33:02 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.

33:11 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,

33:22 I know I've set the breakpoint in debugger at points is when a team, when one team is struggling.

33:29 And, you know, and if you can find a way to basically be like,

33:33 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 hey, tell me tell me more about what's going on here,

33:41 you know, and

33:42 Brad: Yeah.

33:42 Scott: how is, you know, what are your teams struggling with? And.

33:47 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,

33:54 whether that's Jira or whatever,

33:55 and look at the real-time dashboard that might inform you, be like,

34:00 oh, like there's actually something going on here.

34:04 This team is struggling in the following way.

34:08 Brad: That leads into another example.

34:10 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,

34:23 I have an example I use that's from a time at Rover.

34:26 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.

34:32 And someone was like, well, we have to make this, you know.

34:35 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

34:53 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

35:19 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

35:43 And sometimes that leads to frustration where you're like, oh man,

35:47 who coded it this way? This was terrible.

35:49 Now we're

35:49 Scott: Right.

35:49 Brad: having to clean it up.

35:49 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,

36:04 hey, tell me more about this. Help me understand what,

36:06 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.

36:10 Don't

36:10 Brad: The

36:10 Scott: go by

36:10 Brad: Uncle Bob and then we'll wrap it up.

36:12 Okay.

36:13 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,

36:19 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,

36:30 and to be clear, I don't know exactly what his system is.

36:33 So I don't feel like I can comfortably like he didn't show on the screen like.

36:39 Like, you know, his,

36:39 you know, whatever these reports are, I would assume that he.

36:46 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.

37:11 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,

37:21 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,

37:30 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.

37:40 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,

37:54 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.

38:01 I think he's very smart.

38:04 So I'm a little intimidated by that.

38:07 He has a perception of maybe being a little curmudgeonly.

38:12 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.

38:33 I was at a conference called Agile Open Northwest about 2008.

38:37 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,

39:09 dude.

39:09 Brad: it could have been i don't remember most he

39:12 Scott: Robert C.

39:12 Martin,

39:13 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

39:22 and you know what their experience was and it was i really treasure that that memory because it was so

39:30 It was just so neat to hear the origin story from the.

39:34 mouths of the origin.

39:36 Scott: Right.

39:36 Brad: It was really,

39:37 really cool.

39:38 Scott: Yeah.

39:38 Well,

39:39 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,

39:50 which is the he's right and he's wrong.

39:52 But the other skirmish that's happening is who the F cares?

39:56 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

40:15 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?

40:26 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?

40:35 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

40:47 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.

40:56 It happens to be that I also agree with the stance that he's taking,

41:01 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.

41:15 Over his career,

41:16 Uncle Bob has said things,

41:18 had theories,

41:19 advocated for things that came to be true.

41:23 I don't know what those things were,

41:24 but he advocated for engineering practices that turned out to be good practices that helped engineers do better engineering,

41:32 do better work, enjoy their jobs more.

41:35 Brad: over

41:35 Scott: And so he's earned the right.

41:38 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,

41:52 I don't know. maybe he's not.

41:52 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.

42:05 Awesome.

42:05 Well,

42:06 there you go.

42:06 That's the summary.

42:07 What do we say?

42:08 Scott: Smash,

42:09 rate,

42:10 and review.

42:11 Brad: Smash rate and review.

42:12 Scott: Tell all your friends.

42:13 Tell your mom.

42:15 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.

42:26 All right.

42:27 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.

42:37 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.

42:45 You can find us on YouTube,

42:47 LinkedIn,

42:48 Instagram,

42:48 Facebook,

42:49 Threads, X,

42:50 TikTok,

42:50 and Patreon, or at our website at HowManyCTOsPod.com. And remember to rate, review,

42:57 and subscribe on the podcast platform of your choice.

43:00 Thanks for listening.