Transcript: 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 Scott My name is Scott Porad,
0:30 Scott and this is my trusty co-host,
0:33 Brad Brad Hefta-Gaub.
0:35 Scott Brad,
0:36 Scott I heard through the grapevine.
0:39 Scott 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 Scott 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 Scott Let's talk about that on the podcast.
0:57 Brad Well,
0:57 Brad 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 Scott well,
1:05 Scott that's a famous old timey computer guy.
1:08 Scott And I don't really know a lot more about Uncle Bob than that.
1:11 Scott So why don't you fill me in and fill the rest of that.
1:14 Scott 40 other people who are listening today on
1:16 Brad this Yeah,
1:16 Scott thing.
1:17 Brad well,
1:18 Brad Uncle Bob is a famous computer guy,
1:22 Brad old timey computer guy. I think you got that right.
1:25 Brad He's most famous for a bunch of books that he wrote.
1:30 Brad Clean Code is probably like his most famous book from like 2009.
1:36 Brad He was one of the signers of the Agile Manifesto. He was kind of one of the
1:40 Brad One of the early – so he's written books on agile principles.
1:43 Brad 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 Brad So basically has been writing books since the mid-90s. Before that,
2:04 Brad he spent –
2:05 Brad 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 Brad 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 Brad right?
2:46 Scott Oh, wow.
2:47 Scott That's cool.
2:47 Brad So you're right. He's an old timey computer guy.
2:52 Brad That's for sure. That's for sure accurate.
2:56 Scott Bob Martin,
2:57 Scott right?
2:57 Brad Bob Martin, Robert Martin. Yeah.
2:58 Scott Yeah.
2:58 Brad Oh,
2:59 Brad yeah.
2:59 Brad Goes by Uncle Bob.
3:00 Brad I sent it to you because he's blowing up on the Internet today because,
3:07 Brad well, first of all, he was basically in some podcast.
3:10 Brad And honestly,
3:11 Brad 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 Scott 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 Brad But hey,
3:22 Brad tell me what you think about agentic programming,
3:24 Brad especially this guy that's like supposedly,
3:26 Brad you know, hey,
3:27 Brad it's all about code. It's all about clean
3:28 Scott Hmm
3:28 Brad code.
3:29 Brad And he basically said in the podcast interview, he's no longer reading the source code from his agents.
3:36 Brad That's the headline.
3:37 Brad That's the that's the thing that got pulled into the Internet zeitgeist.
3:43 Brad And if you watch the podcast,
3:45 Brad 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 Brad which is, you know, the the 3000 line thought experiment,
4:00 Brad right?
4:00 Brad Like you have a developer who shows up, he didn't use this,
4:02 Brad this is my thought experiment, right?
4:04 Brad But he basically describes like,
4:05 Brad hey.
4:07 Brad These things write code really fast.
4:09 Brad 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 Brad 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 Brad Automated unit test,
4:24 Scott Yeah.
4:24 Brad right?
4:26 Brad Automated end-to-end tests.
4:28 Brad Um,
4:29 Brad other sort of like,
4:31 Brad you know, uh,
4:32 Brad you know, acceptance criteria around architecture,
4:36 Brad right?
4:36 Brad Like you can, you can have static analysis of architecture,
4:40 Brad right?
4:40 Brad Um,
4:41 Brad all kinds of stuff like that, you know? So he listed all of these different things, which basically just,
4:46 Brad in my opinion, just boiled down to like,
4:48 Brad Hey,
4:49 Brad that's what I mean when I talk about.
4:51 Brad 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 Brad Well,
5:19 Brad if you've got lots of control systems in place,
5:23 Brad 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 Brad But he's blowing up the internet right now because some people are like,
5:38 Brad oh my god.
5:41 Brad The author of clean code is no longer reading the code.
5:44 Brad Right.
5:45 Brad 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 Scott follow this.
5:56 Brad Exactly. Right?
5:58 Brad Exactly.
5:59 Brad 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 Brad well,
6:13 Brad certainly like.
6:14 Brad Clean code is definable. It's written down in many books.
6:19 Brad Good architectural patterns are written down and have had plenty of debate about them, and there's consensus.
6:28 Brad So that's all verifiable.
6:31 Scott I'll tell you where my mind first went to,
6:34 Scott and maybe we're just going down paths that are well-worn.
6:38 Scott If I know that I need really good quality controls,
6:42 Scott I think it is easier to get those in place when I'm building something Greenfield.
6:48 Scott And if I have a pre-existing system.
6:53 Scott Without those things,
6:54 Scott 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 Scott What I'm trying to say is where my mind, yes,
7:08 Scott argue with me on that. Where my mind goes is,
7:11 Scott okay, I need to solve the how do I add these quality controls to my existing lines of code.
7:20 Scott 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 Scott but the thing I need to fix, not fix, but address is the existing stuff where it didn't have that.
7:40 Scott what is an effective and efficient way to do that?
7:43 Scott So there's an effective way to do that. It's pure brute force.
7:46 Scott 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 Scott And I'm certainly sure if you told an agent to go write a bunch of unit tests,
7:58 Scott 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 Scott 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.
8:33 Scott 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 Scott many years and had many,
8:49 Scott many people work on it and so on and so forth. Although I bet Microsoft Word probably has amazing test coverage.
8:54 Scott That's probably moot.
8:56 Scott You get my point,
8:57 Scott I hope.
8:58 Scott So I'm not being skeptical of Bob.
8:59 Scott I'm actually just thinking my mind goes, for most of the CTOs out there,
9:03 Scott 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 Brad 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 Brad right?
9:38 Brad Okay,
9:38 Brad so let me just say like, I agree there's that that's the thread that we might want to pull on.
9:45 Brad I'm going to.
9:46 Brad 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 Brad Right.
10:13 Brad And one of the list of the belligerents would be probably people saying,
10:17 Brad oh, my God,
10:19 Brad 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 Brad well,
10:27 Brad you're probably kidding yourself if you think you reading the code is actually doing that much quality control.
10:33 Brad And that's why we need these other systems in place instead. So I think one of the threads worth pulling on.
10:40 Brad is how much value are you really getting from your human reading your code anyway?
10:45 Scott Well,
10:47 Scott okay,
10:48 Scott so I'm thinking of a human code review,
10:50 Scott and I'm thinking there are two or three things that are probably the primary categories of exposure.
10:58 Scott In there.
11:00 Scott One is bugs.
11:03 Scott Hey,
11:03 Scott this isn't written properly.
11:06 Scott And I actually bet that's kind of the minority of things.
11:09 Scott Another category is what I'll just broadly call architecture,
11:14 Scott which is like,
11:15 Scott hey,
11:16 Scott you didn't design this very well, right?
11:18 Scott This is going to be brittle.
11:20 Scott 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 Scott 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 Scott And I suspect,
11:55 Scott 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 Scott But we're operating in base 75.
12:15 Brad Okay, so I love it.
12:17 Brad So I love that that's where you got to when I asked the question,
12:22 Brad what does reading the code actually do?
12:24 Brad Because Uncle Bob has an answer to those second two categories.
12:27 Brad And he says that's what he's instead spending his time on.
12:31 Brad So he basically says,
12:33 Brad look,
12:34 Brad I have the agents justify their implementation to me and I have the agents.
12:39 Brad Agents build me a visualization tool so I can see how did they architect the code?
12:46 Brad Did they follow the practices of clean code,
12:52 Brad good architectural design,
12:53 Brad the stuff that exists,
12:55 Brad 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.
13:04 Brad second two categories,
13:05 Brad 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 Scott It's a little bit of a variation.
13:20 Scott So like we have talked at TaskRabbit, we have a code review agent does code review for us.
13:28 Scott And we've talked about building two other types of agents to be in our pipeline.
13:34 Scott One is an architecture agent.
13:36 Scott Does this comply with what we refer to as our target state architecture,
13:39 Scott 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 Scott which
13:46 Brad Yeah.
13:46 Scott is, you know, that looks to see if it's secure.
13:48 Scott And we've actually talked about those could be targeted at two different points in the pipeline.
13:53 Scott 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 Scott But also further upstream,
14:07 Scott could you give it some sort of design doc,
14:09 Scott either human generated or
14:10 Brad Absolutely.
14:10 Scott Asian generated to look at that also?
14:13 Scott And where my thought goes there is,
14:15 Scott okay, we are trying to build a service oriented event based architecture,
14:22 Scott right?
14:24 Scott We are building it.
14:26 Scott For a variety of reasons and a combination of Ruby and TypeScript, and I know that sounds unusual,
14:31 Scott but we don't need to go into that part of it right here.
14:33 Scott I got some people who want to write an architecture agent and they want to write a security agent.
14:38 Scott 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 Brad 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 Scott 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 Brad 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 Brad 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 Brad 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 Brad And the result is you get, you know, the more times you run through the probability machine,
16:18 Brad you get slightly different answers every time you run through the probability machine.
16:23 Brad And the more slightly different answers you get allows you to get a higher quality answer,
16:29 Brad right? Like you get if you combine multiple different versions,
16:32 Brad you get a higher.
16:33 Brad 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 Brad Two different runs through the probability machine.
17:01 Brad They happen to be the meat sack version of the probability machine instead of the silicon version.
17:06 Brad 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 Scott 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 Brad To sit like again like you like I challenge you as a CTO like you're not doing code reviews,
17:52 Brad 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 Scott right?
18:12 Scott 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 Scott 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 Scott And I might not even want to take a look at the code.
18:48 Scott I'll tell you very specifically what's coming up.
18:50 Scott We are moving our production infrastructure to a different AWS region.
18:57 Scott I don't remember.
18:58 Scott I always get them mixed up. I can't remember what region we're in,
19:00 Scott 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 Scott So we're moving.
19:13 Scott I can't. We're moving to Oregon,
19:15 Scott I think. It doesn't matter.
19:16 Scott Those details don't matter. But this is one place where I said to our head of infrastructure, I was like, okay.
19:21 Scott I would like to see your rollout plan.
19:24 Scott And the two things I'm specifically interested in that plan are I want to see action item level detail,
19:32 Scott like who is doing every single task.
19:35 Scott And I want to see the rollback scenarios.
19:39 Brad Yeah.
19:39 Brad Which ones are there any one-way doors?
19:42 Scott Great. Are there any one-way doors in this?
19:44 Scott 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 Scott 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 Brad Few and far between,
20:20 Brad 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 Scott 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 Scott Want the clock to reset on and so he had
21:05 Scott 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 Scott Maintain.
21:31 Brad Oh,
21:31 Brad 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 Scott He just wanted the uptime.
21:41 Brad That's funny.
21:43 Brad Yeah, those were the days. I do remember if we can just share war stories for a second.
21:47 Brad 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 Brad 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 Brad extremely compromised position.
22:15 Scott Well, and the point that I'm making about that is that even in your answer,
22:19 Scott you you had a system for what you were going to validate.
22:22 Scott Like, I doubt that you are going to say,
22:25 Scott 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 Scott Give me a very detailed.
22:39 Scott 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 Scott people that are doing the work or did the work about did they consider all the things and
23:08 Brad Right,
23:09 Brad 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 Scott 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 Scott 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 Scott Well,
23:59 Scott you should be using a linter and a pretty printer to get the braces in all the right places.
24:06 Scott Like I shouldn't be wasting either of our time on that.
24:11 Brad Yeah,
24:11 Brad I think there's also two other lessons here for CTOs and aspiring CTOs that are worth mentioning.
24:19 Brad The first is when you have to go to your boss or your boss's boss and present something,
24:25 Brad it forces you, well,
24:28 Brad in theory,
24:28 Brad it should force you to get your ducks in a row.
24:32 Brad I sometimes have to go to the CTO and the senior leadership team or to our board of directors and present things.
24:39 Brad 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 Brad I shouldn't say they don't care, but like they're actually presenting to them, right?
24:52 Brad 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 Brad oh,
24:59 Brad here's a whole thing that we don't have.
25:01 Brad 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 Brad Why does it work that way?
25:16 Scott And right,
25:17 Scott and you better have an answer.
25:18 Brad And you better have an answer.
25:19 Brad 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 Brad And so I don't do it that way, but it is an effective tool sometimes to just say, look,
25:37 Brad 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 Brad 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 Brad 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 Brad 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 Brad Why are we doing it in September and not December?
27:08 Brad 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 Scott And I feel like just if we circle back just to kind of, you know, kind of attach these two threads together,
27:21 Scott right?
27:21 Scott Like, you know.
27:23 Scott 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 Scott What the heck? Right.
27:28 Scott 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 Scott 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
28:33 Scott be strong technically and be able to.
28:38 Scott 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,
29:03 Scott 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 Brad Here is where we might have a little bit of a point of disagreement.
29:14 Scott OK,
29:14 Scott 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 Brad But as I've gone on in my career,
29:23 Brad I've been much more about the getting in with the team.
29:28 Brad I get in with them a lot less, but I'm actually getting in more like specific points,
29:34 Brad 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 Brad okay?
29:40 Brad There's certainly one-way doors, like are we creating a one-way door for ourselves here?
29:45 Brad They are high-risk operations,
29:47 Brad like this data center move we're talking about.
29:51 Brad They are sometimes,
29:53 Brad although slightly less so,
29:55 Brad data model designing.
29:58 Brad 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 Brad We were doing dog walking and we were in our mobile app.
30:11 Brad 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 Brad And then if the dog.
30:22 Brad 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 Brad and i was like you should save those
30:44 Brad 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,
30:55 Brad although Rover now is probably sitting on a decade worth of where dogs have peed and pooed all around the world.
31:00 Brad I did, when I worked at Rover,
31:02 Brad I bought the domain names pmap and poomap.com. Rover still owns those.
31:07 Brad So if anybody is working at Rover,
31:08 Brad you can build those maps.
31:10 Brad 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 Brad Okay, we have a customer,
31:38 Brad 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 Brad and they want to actually do a partnership, deepen the partnership whereby you can actually buy the storage and the delivery together,
31:57 Brad right?
31:58 Brad 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 Brad I know it's not a requirement here,
32:06 Brad 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 Brad 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 Brad What a requirement shouldn't be.
32:43 Brad I think there was a fourth one I listed that I'm forgetting.
32:45 Brad I've narrowed it down.
32:49 Brad 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 Scott 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 Scott 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 Scott 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 Scott I know I've set the breakpoint in debugger at points is when a team, when one team is struggling.
33:29 Scott And, you know, and if you can find a way to basically be like,
33:33 Scott 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,
33:41 Scott you know, and
33:42 Brad Yeah.
33:42 Scott how is, you know, what are your teams struggling with? And.
33:47 Scott 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 Scott whether that's Jira or whatever,
33:55 Scott and look at the real-time dashboard that might inform you, be like,
34:00 Scott oh, like there's actually something going on here.
34:04 Scott This team is struggling in the following way.
34:08 Brad That leads into another example.
34:10 Brad 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 Brad I have an example I use that's from a time at Rover.
34:26 Brad 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 Brad And someone was like, well, we have to make this, you know.
34:35 Brad 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 Brad 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 Brad 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 Brad And sometimes that leads to frustration where you're like, oh man,
35:47 Brad who coded it this way? This was terrible.
35:49 Brad Now we're
35:49 Scott Right.
35:49 Brad having to clean it up.
35:49 Brad 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 Scott hey, tell me more about this. Help me understand what,
36:06 Scott 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 Scott 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 Brad Okay.
36:13 Brad 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 Brad 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 Scott and to be clear, I don't know exactly what his system is.
36:33 Scott So I don't feel like I can comfortably like he didn't show on the screen like.
36:39 Scott Like, you know, his,
36:39 Scott you know, whatever these reports are, I would assume that he.
36:46 Scott 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 Brad 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 Scott 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 Scott 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 Scott 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 Brad 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 Brad I think he's very smart.
38:04 Brad So I'm a little intimidated by that.
38:07 Brad He has a perception of maybe being a little curmudgeonly.
38:12 Brad 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 Brad I was at a conference called Agile Open Northwest about 2008.
38:37 Brad 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 Scott dude.
39:09 Brad it could have been i don't remember most he
39:12 Scott Robert C.
39:12 Scott Martin,
39:13 Scott 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 Brad and you know what their experience was and it was i really treasure that that memory because it was so
39:30 Brad It was just so neat to hear the origin story from the.
39:34 Brad mouths of the origin.
39:36 Scott Right.
39:36 Brad It was really,
39:37 Brad really cool.
39:38 Scott Yeah.
39:38 Scott Well,
39:39 Scott 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 Scott which is the he's right and he's wrong.
39:52 Scott But the other skirmish that's happening is who the F cares?
39:56 Scott 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 Brad 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 Scott 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 Scott 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 Brad 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 Brad It happens to be that I also agree with the stance that he's taking,
41:01 Brad 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 Scott Over his career,
41:16 Scott Uncle Bob has said things,
41:18 Scott had theories,
41:19 Scott advocated for things that came to be true.
41:23 Scott I don't know what those things were,
41:24 Scott but he advocated for engineering practices that turned out to be good practices that helped engineers do better engineering,
41:32 Scott do better work, enjoy their jobs more.
41:35 Brad over
41:35 Scott And so he's earned the right.
41:38 Scott 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 Scott I don't know. maybe he's not.
41:52 Scott 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 Brad Awesome.
42:05 Brad Well,
42:06 Brad there you go.
42:06 Brad That's the summary.
42:07 Brad What do we say?
42:08 Scott Smash,
42:09 Scott rate,
42:10 Scott and review.
42:11 Brad Smash rate and review.
42:12 Scott Tell all your friends.
42:13 Scott Tell your mom.
42:15 Scott 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 Brad All right.
42:27 Brad 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 Brad 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 Scott You can find us on YouTube,
42:47 Scott LinkedIn,
42:48 Scott Instagram,
42:48 Scott Facebook,
42:49 Scott Threads, X,
42:50 Scott TikTok,
42:50 Scott and Patreon, or at our website at HowManyCTOsPod.com. And remember to rate, review,
42:57 Scott and subscribe on the podcast platform of your choice.
43:00 Scott Thanks for listening.