WEBVTT

1
00:00:00.160 --> 00:00:02.520
<v Speaker 1>So what if I told you that, over the entire

2
00:00:02.720 --> 00:00:07.400
<v Speaker 1>lifespan of a you know, multi million dollar app, the

3
00:00:07.519 --> 00:00:12.519
<v Speaker 1>average software engineer only produces about ten lines of final

4
00:00:12.560 --> 00:00:13.320
<v Speaker 1>code per day.

5
00:00:13.519 --> 00:00:14.599
<v Speaker 2>Yeah, just ten lines.

6
00:00:14.720 --> 00:00:18.079
<v Speaker 1>Ten lines. I mean, it sounds completely impossible, right, It's

7
00:00:18.399 --> 00:00:21.559
<v Speaker 1>it's like someone building a house by laying literally a

8
00:00:21.600 --> 00:00:23.359
<v Speaker 1>single brick every afternoon.

9
00:00:23.480 --> 00:00:26.000
<v Speaker 2>It really does sound absurd when you frame it like that, right.

10
00:00:26.079 --> 00:00:29.879
<v Speaker 1>But the digital infrastructure that you rely on every single minute,

11
00:00:29.879 --> 00:00:32.560
<v Speaker 1>like your banking app or the computer's keeping your car

12
00:00:32.600 --> 00:00:35.000
<v Speaker 1>on the road, you know, global financial networks, it's not

13
00:00:35.159 --> 00:00:39.759
<v Speaker 1>built like a physical house or a suspension bridge.

14
00:00:39.439 --> 00:00:41.719
<v Speaker 2>Exactly because we can't see the steel cables, we can't

15
00:00:41.759 --> 00:00:42.679
<v Speaker 2>measure the concrete.

16
00:00:42.759 --> 00:00:46.560
<v Speaker 1>Yeah, it operates by these invisible, almost bizarre rules.

17
00:00:46.600 --> 00:00:49.159
<v Speaker 2>It is the ultimate invisible infrastructure. Yeah, and I think

18
00:00:49.159 --> 00:00:51.880
<v Speaker 2>because we can't physically watch it go up piece by piece,

19
00:00:52.200 --> 00:00:54.439
<v Speaker 2>we just assume it's manufactured on some kind of you know,

20
00:00:54.520 --> 00:00:59.320
<v Speaker 2>digital assembly line. Right, But the rules governing how software

21
00:00:59.320 --> 00:01:04.239
<v Speaker 2>actually comes into existence are totally alien to traditional manufacturing.

22
00:01:03.799 --> 00:01:07.400
<v Speaker 1>Completely alien. So welcome to our deep dive today. We

23
00:01:07.439 --> 00:01:12.719
<v Speaker 1>are exploring the fascinating and honestly just wildly misunderstood world

24
00:01:12.879 --> 00:01:14.879
<v Speaker 1>of how software is actually built.

25
00:01:14.920 --> 00:01:17.040
<v Speaker 2>It's such a great topic, it is, and.

26
00:01:16.959 --> 00:01:19.920
<v Speaker 1>We're pulling our insights today from a really incredible source.

27
00:01:19.959 --> 00:01:24.319
<v Speaker 1>It's called Write Great Code, Volume three, Engineering Software, and

28
00:01:24.319 --> 00:01:25.480
<v Speaker 1>that's by Randall Hyde.

29
00:01:25.640 --> 00:01:28.120
<v Speaker 2>Yeah. Hi does just an incredible job pulling back the

30
00:01:28.159 --> 00:01:29.840
<v Speaker 2>curtain on the entire industry here.

31
00:01:29.959 --> 00:01:30.640
<v Speaker 1>He really does.

32
00:01:30.799 --> 00:01:34.760
<v Speaker 2>And what makes this exploration so valuable is that he

33
00:01:34.799 --> 00:01:39.000
<v Speaker 2>looks at the psychological and human elements of coding just

34
00:01:39.040 --> 00:01:40.599
<v Speaker 2>as much as the technical frameworks.

35
00:01:40.640 --> 00:01:44.599
<v Speaker 1>Absolutely, so, our mission today is to decode the hidden processes,

36
00:01:45.159 --> 00:01:49.799
<v Speaker 1>the crushing productivity traps, and those really radical management frameworks

37
00:01:49.840 --> 00:01:53.480
<v Speaker 1>that software engineers use to construct the digital world around.

38
00:01:53.200 --> 00:01:55.799
<v Speaker 2>You, right, giving you a shortcut to being a much

39
00:01:55.840 --> 00:01:57.519
<v Speaker 2>more well informed consumer of this.

40
00:01:57.400 --> 00:02:01.319
<v Speaker 1>Stuff exactly, or maybe even a creator of complex projects,

41
00:02:01.400 --> 00:02:04.760
<v Speaker 1>because look, you interact with software all day, but tracing

42
00:02:04.799 --> 00:02:07.239
<v Speaker 1>how it goes from just a vague idea in someone's

43
00:02:07.280 --> 00:02:10.960
<v Speaker 1>head to a perfectly functioning tool on your screen, it

44
00:02:11.000 --> 00:02:13.280
<v Speaker 1>reveals a staggering amount of human friction.

45
00:02:13.560 --> 00:02:14.879
<v Speaker 2>Oh massive amounts of friction.

46
00:02:15.000 --> 00:02:16.199
<v Speaker 1>So okay, let's unpack this.

47
00:02:16.439 --> 00:02:18.479
<v Speaker 2>To start unpacking it, I mean, we first have to

48
00:02:18.520 --> 00:02:22.120
<v Speaker 2>look at the fundamental, unique nature of software itself. Right.

49
00:02:22.280 --> 00:02:26.039
<v Speaker 2>Unlike a physical bradge or a car engine, software doesn't wear.

50
00:02:25.879 --> 00:02:27.960
<v Speaker 1>Out, right, there's no rest exactly.

51
00:02:28.280 --> 00:02:32.680
<v Speaker 2>Friction doesn't degrade code over time, and it's also highly customed.

52
00:02:33.159 --> 00:02:36.400
<v Speaker 2>We don't have the equivalent of a standard universal integrated

53
00:02:36.439 --> 00:02:38.919
<v Speaker 2>circuit that you can just snap together to instantly build

54
00:02:38.960 --> 00:02:39.680
<v Speaker 2>any app you want.

55
00:02:39.800 --> 00:02:41.120
<v Speaker 1>Yeah, it's not legos, it's not.

56
00:02:41.759 --> 00:02:45.560
<v Speaker 2>And crucially, once the design is finished, it costs literally

57
00:02:45.680 --> 00:02:49.120
<v Speaker 2>pennies to duplicate it a million times. The actual manufacturing

58
00:02:49.159 --> 00:02:50.639
<v Speaker 2>cost is practically zero.

59
00:02:50.680 --> 00:02:53.400
<v Speaker 1>Right, So the real cost is entirely in the intellectual

60
00:02:53.400 --> 00:02:56.599
<v Speaker 1>design and the implementation precisely, which means before we can

61
00:02:56.680 --> 00:02:59.759
<v Speaker 1>understand how software is built, we really have to understand

62
00:02:59.759 --> 00:03:00.680
<v Speaker 1>the peace people building it.

63
00:03:01.000 --> 00:03:03.199
<v Speaker 2>Yeah, the human element is everything here, it is.

64
00:03:03.639 --> 00:03:07.479
<v Speaker 1>And the source outlines four distinct historical metaphors for a programmer,

65
00:03:07.719 --> 00:03:10.159
<v Speaker 1>and they perfectly track how the industry has had to

66
00:03:10.199 --> 00:03:13.120
<v Speaker 1>evolve as the stakes got higher they do. So let's

67
00:03:13.120 --> 00:03:16.120
<v Speaker 1>start with the first one, which is the programmer as artist.

68
00:03:16.400 --> 00:03:18.719
<v Speaker 2>Right. So the artist dates back to the very early

69
00:03:18.800 --> 00:03:22.960
<v Speaker 2>days of computing, where coding was viewed as this mysterious,

70
00:03:23.400 --> 00:03:24.680
<v Speaker 2>almost god given.

71
00:03:24.520 --> 00:03:26.319
<v Speaker 1>Talent, you know, like magic.

72
00:03:26.479 --> 00:03:30.680
<v Speaker 2>Yeah, like magic. The artist bends the rules, relies on

73
00:03:30.840 --> 00:03:35.240
<v Speaker 2>pure natural aptitude, and often does their absolute best work

74
00:03:35.560 --> 00:03:38.759
<v Speaker 2>when they are completely unconstrained by corporate oversight.

75
00:03:38.639 --> 00:03:40.840
<v Speaker 1>Just left alone in abasement somewhere exactly.

76
00:03:41.000 --> 00:03:46.120
<v Speaker 2>They're fantastic for solo, highly creative, intensely focused projects.

77
00:03:46.280 --> 00:03:49.639
<v Speaker 1>See. I always picture the artist like a solo musician

78
00:03:49.680 --> 00:03:51.240
<v Speaker 1>recording a track in their bedroom.

79
00:03:51.400 --> 00:03:53.360
<v Speaker 2>Oh, that's a great way to look at it, right, Like, they.

80
00:03:53.199 --> 00:03:55.599
<v Speaker 1>Play all the instruments, they mix it themselves, they don't

81
00:03:55.639 --> 00:03:59.560
<v Speaker 1>care about standard time signatures. The final product is pure

82
00:03:59.639 --> 00:04:03.120
<v Speaker 1>personal expression and it can be totally brilliant. But a

83
00:04:03.120 --> 00:04:07.199
<v Speaker 1>solo artist in a bedroom can't build a global banking system.

84
00:04:07.400 --> 00:04:08.400
<v Speaker 2>No, definitely not.

85
00:04:08.520 --> 00:04:12.719
<v Speaker 1>The stakes are just too high. When software started impacting

86
00:04:12.800 --> 00:04:16.560
<v Speaker 1>human safety and you know, managing billions of dollars, the

87
00:04:16.720 --> 00:04:19.920
<v Speaker 1>industry had to evolve. Someone needed to see the big.

88
00:04:19.720 --> 00:04:24.279
<v Speaker 2>Picture exactly, and that necessity birth the second metaphor, which

89
00:04:24.360 --> 00:04:25.560
<v Speaker 2>is the programmer as.

90
00:04:25.680 --> 00:04:26.800
<v Speaker 1>Architect the architecture.

91
00:04:27.000 --> 00:04:30.319
<v Speaker 2>So if the artist is the bedroom musician, the architect

92
00:04:30.360 --> 00:04:34.560
<v Speaker 2>is the composer writing complex sheet music for an entire

93
00:04:34.600 --> 00:04:38.720
<v Speaker 2>symphony orchestra. Oh I like that right. The architect exercises

94
00:04:38.839 --> 00:04:42.879
<v Speaker 2>large scale creative control. But they leave the actual building,

95
00:04:42.959 --> 00:04:46.279
<v Speaker 2>the you know, coding of individual components to other people.

96
00:04:46.399 --> 00:04:46.759
<v Speaker 1>Got it.

97
00:04:47.120 --> 00:04:50.600
<v Speaker 2>They're focused entirely on the structural integrity of the big picture,

98
00:04:51.040 --> 00:04:53.639
<v Speaker 2>because a badly designed building falls down and hurts people,

99
00:04:54.040 --> 00:04:57.480
<v Speaker 2>and a badly designed software architecture can crash a hospital's

100
00:04:57.480 --> 00:04:58.319
<v Speaker 2>life support.

101
00:04:58.040 --> 00:05:01.240
<v Speaker 1>System, which is terrifying. But the industry couldn't stop at

102
00:05:01.279 --> 00:05:04.240
<v Speaker 1>architects either, because the demand for software just exploited. It

103
00:05:04.279 --> 00:05:07.040
<v Speaker 1>really did, which leads us to the third metaphor, the

104
00:05:07.120 --> 00:05:11.040
<v Speaker 1>programmer as engineer, And this one has a very specific,

105
00:05:11.160 --> 00:05:14.680
<v Speaker 1>almost panicked origin story from the late nineteen sixties.

106
00:05:14.360 --> 00:05:18.199
<v Speaker 2>Right, Yes, the nineteen sixty eight NATO conference. Right at

107
00:05:18.199 --> 00:05:21.360
<v Speaker 2>the time, the world was facing what they literally called

108
00:05:21.439 --> 00:05:22.600
<v Speaker 2>the software crisis.

109
00:05:22.839 --> 00:05:24.360
<v Speaker 1>The software crisis.

110
00:05:24.600 --> 00:05:28.879
<v Speaker 2>Yeah, the demand for complex software was vastly outpacing the

111
00:05:29.000 --> 00:05:33.040
<v Speaker 2>number of naturally talented artist programmers available. Yeah, I mean,

112
00:05:33.480 --> 00:05:36.800
<v Speaker 2>budgets were spiraling, projects were failing left and right.

113
00:05:36.720 --> 00:05:38.839
<v Speaker 1>So they needed a reliable system exactly.

114
00:05:38.959 --> 00:05:42.439
<v Speaker 2>So NATO sponsored a conference and officially coined the term

115
00:05:42.680 --> 00:05:47.000
<v Speaker 2>software engineering. The explicit goal was to take the predictable,

116
00:05:47.120 --> 00:05:51.439
<v Speaker 2>standard building block approach of civil or mechanical engineering and

117
00:05:51.519 --> 00:05:53.240
<v Speaker 2>just force us onto software development.

118
00:05:53.480 --> 00:05:56.000
<v Speaker 1>Okay, so, keeping with our music analogy, then if the

119
00:05:56.079 --> 00:05:59.000
<v Speaker 1>engineer steps in, they are like the studio executive trying

120
00:05:59.000 --> 00:06:00.160
<v Speaker 1>to mass produce pop hit.

121
00:06:00.399 --> 00:06:01.439
<v Speaker 2>Yes, exactly right.

122
00:06:01.519 --> 00:06:04.480
<v Speaker 1>Like they use standardized coord progressions and heavily enforced production

123
00:06:04.560 --> 00:06:08.079
<v Speaker 1>schedules to just guarantee a baseline of financial return regardless

124
00:06:08.079 --> 00:06:09.959
<v Speaker 1>of who is actually in the recording booth.

125
00:06:10.000 --> 00:06:11.480
<v Speaker 2>That is a perfect way to describe it.

126
00:06:11.600 --> 00:06:14.720
<v Speaker 1>But wait, if we treat programmers entirely like engineers on

127
00:06:14.759 --> 00:06:19.680
<v Speaker 1>an assembly line, strictly following predetermined procedures, don't we completely

128
00:06:19.759 --> 00:06:21.759
<v Speaker 1>kill the creative greatness of the code.

129
00:06:22.079 --> 00:06:24.920
<v Speaker 2>Well, what's fascinating here is that this is the exact

130
00:06:25.000 --> 00:06:30.079
<v Speaker 2>historical tension highlights in the book. Oh really Yeah, software

131
00:06:30.079 --> 00:06:35.879
<v Speaker 2>engineering was invented specifically to make less talented programmers reliable. Okay,

132
00:06:36.199 --> 00:06:39.560
<v Speaker 2>it raises the floor of quality, ensuring a baseline of

133
00:06:39.560 --> 00:06:44.319
<v Speaker 2>safety and function across a massive team. But by enforcing

134
00:06:44.399 --> 00:06:48.279
<v Speaker 2>rigid bureaucratic rules, it inevitably lowers the ceiling.

135
00:06:48.439 --> 00:06:51.040
<v Speaker 1>Oh I see, it brings the top down exactly.

136
00:06:51.360 --> 00:06:54.560
<v Speaker 2>It restricts the truly great programmers from doing their best work.

137
00:06:54.920 --> 00:06:58.879
<v Speaker 2>It actively discourages divergent thinking because in an engineering pipeline,

138
00:06:58.959 --> 00:07:01.360
<v Speaker 2>divergent thinking is view as a schedule risk.

139
00:07:01.240 --> 00:07:04.279
<v Speaker 1>Which makes sense from a management perspective, but it's terrible

140
00:07:04.279 --> 00:07:07.160
<v Speaker 1>for innovation, which brings us to the ultimate ideal. Right,

141
00:07:07.319 --> 00:07:08.720
<v Speaker 1>the programmers.

142
00:07:08.120 --> 00:07:09.360
<v Speaker 2>Craftsmen, Yes, the craftsman.

143
00:07:09.480 --> 00:07:11.720
<v Speaker 1>This is someone who operates in that sweet spot between

144
00:07:11.759 --> 00:07:13.079
<v Speaker 1>the artist and the engineer.

145
00:07:13.360 --> 00:07:17.519
<v Speaker 2>Precisely, if we finish the musical analogy, the craftsman is

146
00:07:17.600 --> 00:07:21.079
<v Speaker 2>the master luthier building a custom strata areas violin.

147
00:07:21.240 --> 00:07:22.120
<v Speaker 1>Oh wow.

148
00:07:22.360 --> 00:07:25.399
<v Speaker 2>They intimately understand the strict physics and engineering of the

149
00:07:25.399 --> 00:07:29.439
<v Speaker 2>wood and the acoustics. But they use that rigid knowledge

150
00:07:29.720 --> 00:07:32.720
<v Speaker 2>to create something of profound artistic beauty.

151
00:07:32.800 --> 00:07:34.480
<v Speaker 1>That's a beautiful way to think about.

152
00:07:34.199 --> 00:07:37.519
<v Speaker 2>It, and their lifelong learners. They start as an apprentice,

153
00:07:37.680 --> 00:07:40.879
<v Speaker 2>move to a journeyman, and eventually become a master craftsman

154
00:07:41.199 --> 00:07:43.519
<v Speaker 2>by creating a masterpiece that proves their skills.

155
00:07:43.600 --> 00:07:45.720
<v Speaker 1>So they know all the rules basically exactly.

156
00:07:45.800 --> 00:07:47.959
<v Speaker 2>They know all the rules of the engineer, but they

157
00:07:47.959 --> 00:07:51.040
<v Speaker 2>have the earned wisdom to know exactly when to bend

158
00:07:51.040 --> 00:07:51.920
<v Speaker 2>them like an artist.

159
00:07:52.199 --> 00:07:55.519
<v Speaker 1>You know, think about your own workplace right now. Understanding

160
00:07:55.600 --> 00:07:59.079
<v Speaker 1>these identities helps you recognize the different types of problem solvers,

161
00:07:59.120 --> 00:08:01.959
<v Speaker 1>you're actually collaborate reading with Polly. If you are managing

162
00:08:02.000 --> 00:08:04.439
<v Speaker 1>a team and you treat a highly creative artist like

163
00:08:04.480 --> 00:08:07.240
<v Speaker 1>a factory line engineer, they are going to fail or

164
00:08:07.360 --> 00:08:08.199
<v Speaker 1>they're just going to quit.

165
00:08:08.279 --> 00:08:09.480
<v Speaker 2>Oh, they'll quit in a heartbeat.

166
00:08:09.800 --> 00:08:14.399
<v Speaker 1>Right. Recognizing whether a specific task requires an artist's flare,

167
00:08:15.040 --> 00:08:18.160
<v Speaker 1>an architect's vision, or an engineer's discipline is really the

168
00:08:18.240 --> 00:08:21.160
<v Speaker 1>secret to unlocking any collaborative project, and.

169
00:08:21.160 --> 00:08:24.040
<v Speaker 2>That actually leads directly into the most dangerous trap in

170
00:08:24.040 --> 00:08:25.000
<v Speaker 2>the entire industry.

171
00:08:25.120 --> 00:08:25.639
<v Speaker 1>Let's hear it.

172
00:08:25.959 --> 00:08:29.319
<v Speaker 2>If we increasingly view coding through this engineering lens, where

173
00:08:29.319 --> 00:08:33.200
<v Speaker 2>we need to manage large teams, management naturally wants to

174
00:08:33.240 --> 00:08:34.360
<v Speaker 2>measure their productivity.

175
00:08:34.519 --> 00:08:37.279
<v Speaker 1>Oh right, and this is where the industry's attempts to

176
00:08:37.320 --> 00:08:41.320
<v Speaker 1>measure human output become almost comical, truly comical. First of all,

177
00:08:41.320 --> 00:08:44.720
<v Speaker 1>the baseline skill gap is just mind boggling. The book

178
00:08:44.759 --> 00:08:47.480
<v Speaker 1>points out there is a staggering ten to twenty times

179
00:08:47.480 --> 00:08:52.000
<v Speaker 1>difference in productivity between average programmers and grand master programmers.

180
00:08:52.200 --> 00:08:54.840
<v Speaker 2>Yeah, just think about the mechanics of that. In literally

181
00:08:54.879 --> 00:08:57.320
<v Speaker 2>any other field, you don't usually find a plumber who

182
00:08:57.360 --> 00:08:59.480
<v Speaker 2>can pipe a house twenty times faster than the plumber

183
00:08:59.480 --> 00:09:00.440
<v Speaker 2>and the next nameborhood.

184
00:09:00.559 --> 00:09:02.200
<v Speaker 1>Right, physical limits exist.

185
00:09:02.159 --> 00:09:06.879
<v Speaker 2>Exactly, but software is pure intellectual leverage. A grand master

186
00:09:06.960 --> 00:09:10.360
<v Speaker 2>can look at a problem, synthesize the logic, and solve

187
00:09:10.360 --> 00:09:13.039
<v Speaker 2>it in one elegant line of code, while an average

188
00:09:13.080 --> 00:09:15.679
<v Speaker 2>programmer might take three weeks and five hundred lines of

189
00:09:15.720 --> 00:09:18.639
<v Speaker 2>code to clumsily force the computer to do the exact

190
00:09:18.679 --> 00:09:19.120
<v Speaker 2>same thing.

191
00:09:19.279 --> 00:09:22.159
<v Speaker 1>So how on earth do managers measure output when the

192
00:09:22.279 --> 00:09:23.480
<v Speaker 1>gap is that wide?

193
00:09:24.320 --> 00:09:26.000
<v Speaker 2>Well, it's right, right.

194
00:09:26.080 --> 00:09:29.440
<v Speaker 1>For decades, the most popular metric has been lines of code,

195
00:09:29.519 --> 00:09:34.159
<v Speaker 1>or LOC, and it is a wildly dangerously flawed metric.

196
00:09:34.399 --> 00:09:37.320
<v Speaker 2>It is, and it became popular solely because it's.

197
00:09:37.200 --> 00:09:39.440
<v Speaker 1>Easy to count, because it's just a number.

198
00:09:39.639 --> 00:09:41.960
<v Speaker 2>Right. You literally just run a script that counts the

199
00:09:42.000 --> 00:09:45.399
<v Speaker 2>lines of text in a file. But measuring productivity by

200
00:09:45.440 --> 00:09:48.919
<v Speaker 2>lines of code assumes every single line requires the exact

201
00:09:48.919 --> 00:09:52.600
<v Speaker 2>same amount of intellectual effort, which is fundamentally false.

202
00:09:52.679 --> 00:09:53.720
<v Speaker 1>It's totally absurd.

203
00:09:53.840 --> 00:09:57.879
<v Speaker 2>A programmer might spend three agonizing days conceptualizing a really

204
00:09:57.919 --> 00:10:01.639
<v Speaker 2>complex cryptography algorithm, but the final result is just two

205
00:10:01.639 --> 00:10:04.879
<v Speaker 2>lines of code. Meanwhile, someone else could write four hundred

206
00:10:04.960 --> 00:10:08.200
<v Speaker 2>lines of simple, repetitive formatting text in a single hour.

207
00:10:08.840 --> 00:10:11.240
<v Speaker 1>So using lines of code to measure a programmer is

208
00:10:11.279 --> 00:10:13.559
<v Speaker 1>like judging the quality of a book strictly by its

209
00:10:13.600 --> 00:10:18.000
<v Speaker 1>page count. Imagine a brilliant editor spending an entire day

210
00:10:18.120 --> 00:10:23.440
<v Speaker 1>meticulously cutting a ten page rambling draft down to one single,

211
00:10:23.919 --> 00:10:28.320
<v Speaker 1>devastatingly perfect paragraph. If you judge them by line count,

212
00:10:28.679 --> 00:10:31.879
<v Speaker 1>that editor had a heavily negative productivity day.

213
00:10:32.080 --> 00:10:35.480
<v Speaker 2>It completely punishes elegance. I mean, in software, often the

214
00:10:35.519 --> 00:10:39.159
<v Speaker 2>most productive, valuable thing a programmer can do is actually delete.

215
00:10:38.799 --> 00:10:40.679
<v Speaker 1>Code, making the system lighter and faster.

216
00:10:40.759 --> 00:10:43.919
<v Speaker 2>Precisely so, to get around the sheer absurdity of loc

217
00:10:44.399 --> 00:10:49.360
<v Speaker 2>computer scientists develop more sophisticated metrics like cyclomatic complexity.

218
00:10:49.440 --> 00:10:52.039
<v Speaker 1>Okay, explain the mechanics of that, because this dives right

219
00:10:52.080 --> 00:10:53.360
<v Speaker 1>into the psychology of coding.

220
00:10:53.480 --> 00:10:57.639
<v Speaker 2>Yeah, so, cyclomatic complexity abandons bulk size entirely. Instead, it

221
00:10:57.679 --> 00:11:01.320
<v Speaker 2>measures the number of distinct logical paths through the code. Okay,

222
00:11:01.399 --> 00:11:03.720
<v Speaker 2>it counts the decisions. You know that if this happens,

223
00:11:03.759 --> 00:11:04.759
<v Speaker 2>then do that otherwise?

224
00:11:04.799 --> 00:11:06.919
<v Speaker 1>Do this branches right the actual logic?

225
00:11:07.159 --> 00:11:09.360
<v Speaker 2>Yes, And the reason this works is that it measures

226
00:11:09.399 --> 00:11:12.279
<v Speaker 2>cognitive load. Yeah, the human brain can only hold so

227
00:11:12.360 --> 00:11:15.440
<v Speaker 2>many competing threads in its working memory before it drops

228
00:11:15.440 --> 00:11:18.480
<v Speaker 2>one and makes a mistake. Makes sense. So cyclomatic complexity

229
00:11:18.600 --> 00:11:21.559
<v Speaker 2>measures how hard the human brain had to work to

230
00:11:21.679 --> 00:11:23.840
<v Speaker 2>map out that specific piece of logic.

231
00:11:24.120 --> 00:11:26.799
<v Speaker 1>That makes so much more sense than just counting lines.

232
00:11:27.480 --> 00:11:31.000
<v Speaker 1>But even utilizing better metrics, we have to circle back

233
00:11:31.080 --> 00:11:33.679
<v Speaker 1>to that shocking reality check we started with.

234
00:11:33.519 --> 00:11:34.480
<v Speaker 2>The ten lines a day.

235
00:11:34.639 --> 00:11:38.559
<v Speaker 1>Yes, over the lifetime of a major software project, if

236
00:11:38.559 --> 00:11:42.399
<v Speaker 1>you average out the total output, a typical programmer produces

237
00:11:42.440 --> 00:11:46.320
<v Speaker 1>only ten lines of debugged, documented code per day.

238
00:11:46.559 --> 00:11:47.320
<v Speaker 2>It's wild.

239
00:11:47.639 --> 00:11:49.320
<v Speaker 1>I really want you to walk me through the math

240
00:11:49.360 --> 00:11:51.200
<v Speaker 1>on that, because when I first read it, my brain

241
00:11:51.279 --> 00:11:54.840
<v Speaker 1>just rejected it. How is ten lines a day mathematically possible?

242
00:11:54.919 --> 00:11:57.960
<v Speaker 2>Well, it sounds absurd until you map out the actual

243
00:11:58.000 --> 00:12:01.600
<v Speaker 2>life cycle of a multi year project. On day one,

244
00:12:01.679 --> 00:12:04.000
<v Speaker 2>a programmer might sit down and hammer out one thousand

245
00:12:04.000 --> 00:12:07.480
<v Speaker 2>lines of code. It feels incredibly productive, right, they're in

246
00:12:07.519 --> 00:12:10.240
<v Speaker 2>the zone. But that code doesn't exist in a vacuum.

247
00:12:10.720 --> 00:12:12.600
<v Speaker 2>On day two, they have to write tests for it.

248
00:12:12.720 --> 00:12:14.919
<v Speaker 2>On day three, they find bugs and have to untangle

249
00:12:14.960 --> 00:12:15.679
<v Speaker 2>their own logic.

250
00:12:15.799 --> 00:12:16.480
<v Speaker 1>Oh okay.

251
00:12:16.559 --> 00:12:18.879
<v Speaker 2>On day four, they sit in six hours of meetings

252
00:12:18.919 --> 00:12:22.279
<v Speaker 2>to discuss how their code interfaces with a database. Someone

253
00:12:22.320 --> 00:12:25.360
<v Speaker 2>else is building always the meetings, and then on day

254
00:12:25.399 --> 00:12:28.480
<v Speaker 2>thirty the client changes the requirements, so they have to

255
00:12:28.480 --> 00:12:30.639
<v Speaker 2>throw out half of what they wrote and start over.

256
00:12:30.919 --> 00:12:34.039
<v Speaker 1>Right, the code is constantly rotting and needing maintenance.

257
00:12:33.679 --> 00:12:37.679
<v Speaker 2>Exactly, and eventually they have to rigorously document every function

258
00:12:38.200 --> 00:12:40.840
<v Speaker 2>so the next person hired can actually understand it.

259
00:12:41.000 --> 00:12:41.519
<v Speaker 1>Wow.

260
00:12:41.840 --> 00:12:44.679
<v Speaker 2>So by the time that product is officially retired, maybe

261
00:12:44.720 --> 00:12:50.720
<v Speaker 2>five or ten years later, the sheer crushing overhead of coordination, meetings, rewriting,

262
00:12:50.960 --> 00:12:55.240
<v Speaker 2>and fixing mistakes dilutes that initial thousand line burst down

263
00:12:55.279 --> 00:12:58.360
<v Speaker 2>to an average of about ten finalized lines a day.

264
00:12:58.600 --> 00:13:01.600
<v Speaker 1>That is just incredible. So the realization here is that

265
00:13:01.919 --> 00:13:04.679
<v Speaker 1>the real way to speed up a project isn't typing faster.

266
00:13:05.240 --> 00:13:09.039
<v Speaker 1>Typing speed is completely irrelevant, totally irrelevant. The bottleneck is

267
00:13:09.039 --> 00:13:12.279
<v Speaker 1>the mistakes in the communication overhead. But when a project

268
00:13:12.320 --> 00:13:17.320
<v Speaker 1>starts running late, management usually panics. Right always, they fall

269
00:13:17.360 --> 00:13:19.879
<v Speaker 1>into the trap of confusing man hours with real time,

270
00:13:20.360 --> 00:13:22.600
<v Speaker 1>which leads to something called Brooks's law.

271
00:13:22.840 --> 00:13:26.159
<v Speaker 2>Yes, Brooks's law is a fatal flaw in project management

272
00:13:26.399 --> 00:13:27.159
<v Speaker 2>across the board.

273
00:13:27.200 --> 00:13:27.600
<v Speaker 1>What is it?

274
00:13:27.759 --> 00:13:30.879
<v Speaker 2>The assumption is physical? You know, if one person can

275
00:13:30.919 --> 00:13:33.080
<v Speaker 2>dig a hole in sixty minutes. Two people can dig

276
00:13:33.080 --> 00:13:36.919
<v Speaker 2>it in thirty minutes. Right, But software is intellectual, highly

277
00:13:36.960 --> 00:13:40.320
<v Speaker 2>intertwined work. If you have a project that is running late,

278
00:13:41.080 --> 00:13:43.279
<v Speaker 2>doubling the staff on that project does not have the

279
00:13:43.320 --> 00:13:44.480
<v Speaker 2>time it takes to finish.

280
00:13:44.759 --> 00:13:45.279
<v Speaker 1>It doesn't.

281
00:13:45.440 --> 00:13:47.480
<v Speaker 2>No, it almost always makes it take longer.

282
00:13:47.279 --> 00:13:52.039
<v Speaker 1>Because every new person adds an exponential number of communication nodes. Exactly,

283
00:13:52.080 --> 00:13:55.000
<v Speaker 1>the original programmers, who are already behind schedule have to

284
00:13:55.000 --> 00:13:59.039
<v Speaker 1>literally stop working to explain this complex, invisible architecture to

285
00:13:59.080 --> 00:14:04.159
<v Speaker 1>the new folks. The communication overhead absolutely skyrockets, dragging everything

286
00:14:04.200 --> 00:14:05.639
<v Speaker 1>to a complete halt.

287
00:14:05.639 --> 00:14:09.960
<v Speaker 2>And when throwing bodies at the problem fails, managers predictably

288
00:14:10.000 --> 00:14:13.480
<v Speaker 2>trigger what we call crisis mode. Oh no, they demand

289
00:14:13.600 --> 00:14:16.799
<v Speaker 2>sixty to seventy hour work weeks. They order everyone to

290
00:14:16.799 --> 00:14:18.120
<v Speaker 2>work through the weekend.

291
00:14:17.799 --> 00:14:21.720
<v Speaker 1>Which sounds productive on paper, right, But cognitive data proves

292
00:14:21.759 --> 00:14:23.519
<v Speaker 1>this is mathematically counterproductive.

293
00:14:24.200 --> 00:14:28.200
<v Speaker 2>You aren't just getting diminishing returns, you are creating negative work.

294
00:14:28.279 --> 00:14:30.360
<v Speaker 1>Because of the cognitive load we talked about earlier.

295
00:14:30.639 --> 00:14:35.559
<v Speaker 2>Precisely, a tired brain cannot hold complex logic paths in

296
00:14:35.639 --> 00:14:39.000
<v Speaker 2>its working memory. No way, a programmer operating on four

297
00:14:39.039 --> 00:14:41.360
<v Speaker 2>hours of sleep on a Friday night at eleven pm

298
00:14:41.679 --> 00:14:44.600
<v Speaker 2>is going to write a bug guaranteed, And because the

299
00:14:44.639 --> 00:14:49.080
<v Speaker 2>logic is so intersigned, that single bug might cascade, taking

300
00:14:49.120 --> 00:14:52.279
<v Speaker 2>three senior engineers four entire days to track down and

301
00:14:52.320 --> 00:14:53.440
<v Speaker 2>fix the following week.

302
00:14:53.720 --> 00:14:55.679
<v Speaker 1>So they actually went backwards.

303
00:14:55.799 --> 00:14:59.919
<v Speaker 2>Yes, that friday night coding session literally destroyed a week

304
00:15:00.080 --> 00:15:01.080
<v Speaker 2>future productivity.

305
00:15:01.159 --> 00:15:04.000
<v Speaker 1>This is such a critical takeaway for you listening right now.

306
00:15:04.080 --> 00:15:06.759
<v Speaker 1>No matter what industry you operate in, if you are

307
00:15:06.759 --> 00:15:10.360
<v Speaker 1>doing collaborative knowledge work, throwing more bodies at a late

308
00:15:10.440 --> 00:15:13.080
<v Speaker 1>project just makes it later every time, and grinding your

309
00:15:13.080 --> 00:15:16.000
<v Speaker 1>team for seventy hours a week destroys their net output.

310
00:15:16.039 --> 00:15:19.279
<v Speaker 1>It is a complete illusion of progress. So if individual

311
00:15:19.279 --> 00:15:23.039
<v Speaker 1>metrics are this flawed and adding people backfires, how do

312
00:15:23.240 --> 00:15:27.639
<v Speaker 1>massive organizations ever manage to organize armies of developers to

313
00:15:27.759 --> 00:15:30.480
<v Speaker 1>ship global products without the whole thing collapsing?

314
00:15:30.600 --> 00:15:33.600
<v Speaker 2>Well, they survive by relying on structural models. They map

315
00:15:33.639 --> 00:15:37.919
<v Speaker 2>out what's called the Software development life cycle THELC SDLC. Right,

316
00:15:38.000 --> 00:15:47.279
<v Speaker 2>this is a framework broken down into phases conceptualization, gathering, requirements, design, coding, testing, deployment, maintenance,

317
00:15:47.600 --> 00:15:49.120
<v Speaker 2>and eventually retirement.

318
00:15:49.480 --> 00:15:52.000
<v Speaker 1>That's a lot of phases, it is, and.

319
00:15:52.039 --> 00:15:54.799
<v Speaker 2>How a company forces its team to move through those

320
00:15:54.840 --> 00:15:58.559
<v Speaker 2>phases dictates their entire working culture.

321
00:15:58.399 --> 00:16:01.879
<v Speaker 1>Which brings us to the models. The most primitive approach

322
00:16:02.000 --> 00:16:04.720
<v Speaker 1>is the informal model, which is basically just hacking.

323
00:16:04.840 --> 00:16:05.840
<v Speaker 2>Yeah, just winging it.

324
00:16:05.919 --> 00:16:07.919
<v Speaker 1>You get an idea, you sit down and you just

325
00:16:07.919 --> 00:16:11.279
<v Speaker 1>start banging out code. You skip the design phase completely. Now,

326
00:16:11.320 --> 00:16:15.639
<v Speaker 1>it is incredibly fun and it's perfect for tiny, throwaway prototypes,

327
00:16:16.039 --> 00:16:17.960
<v Speaker 1>but if you try to build a commercial banking app

328
00:16:17.960 --> 00:16:20.960
<v Speaker 1>this way, it is an unmintainable disaster that will just

329
00:16:21.039 --> 00:16:22.519
<v Speaker 1>collapse under its own weight.

330
00:16:22.399 --> 00:16:25.879
<v Speaker 2>Oh totally. And to avoid that disaster, the industry created

331
00:16:25.879 --> 00:16:29.879
<v Speaker 2>a granddaddy of all formal structures, the waterfall model.

332
00:16:29.960 --> 00:16:30.759
<v Speaker 1>The waterfall model.

333
00:16:30.879 --> 00:16:34.080
<v Speaker 2>Yes, it is rigid, it is highly sequential, and it

334
00:16:34.120 --> 00:16:37.039
<v Speaker 2>is heavily documented. First you spend months figuring out exactly

335
00:16:37.120 --> 00:16:39.679
<v Speaker 2>what the requirements are. Okay, Then you spend months designing

336
00:16:39.720 --> 00:16:42.440
<v Speaker 2>the architecture. Then you hand it to the coders, then

337
00:16:42.480 --> 00:16:43.120
<v Speaker 2>you test.

338
00:16:42.919 --> 00:16:44.960
<v Speaker 1>It so step by step exactly, you.

339
00:16:44.919 --> 00:16:48.120
<v Speaker 2>Flow down the steps like a waterfall, and gravity dictates

340
00:16:48.159 --> 00:16:49.600
<v Speaker 2>you never ever go backward.

341
00:16:49.879 --> 00:16:53.039
<v Speaker 1>It's exactly like building a skyscraper. You dig the foundation,

342
00:16:53.159 --> 00:16:56.559
<v Speaker 1>you pour the concrete, you weld the steel, frame. You

343
00:16:56.679 --> 00:16:59.559
<v Speaker 1>absolutely cannot get to the fifteenth floor and suddenly say,

344
00:16:59.600 --> 00:17:01.879
<v Speaker 1>you know what, but we should really move the elevator

345
00:17:01.919 --> 00:17:03.679
<v Speaker 1>shaft to the outside of the building.

346
00:17:03.919 --> 00:17:05.400
<v Speaker 2>Right, it's physically too late.

347
00:17:05.519 --> 00:17:10.359
<v Speaker 1>But software isn't concrete, it's totally malleable. Applying physical engineering

348
00:17:10.359 --> 00:17:15.240
<v Speaker 1>constraints to a digital medium seems I don't know, fundamentally arrogant.

349
00:17:15.400 --> 00:17:17.279
<v Speaker 1>It as soons you can perfectly know what you are

350
00:17:17.279 --> 00:17:18.680
<v Speaker 1>building before you pick up a tool.

351
00:17:19.079 --> 00:17:21.680
<v Speaker 2>And if we connect this to the bigger picture, that

352
00:17:21.920 --> 00:17:24.480
<v Speaker 2>arrogance is Waterfall's fatal flaw.

353
00:17:24.720 --> 00:17:24.920
<v Speaker 1>Right.

354
00:17:25.240 --> 00:17:28.119
<v Speaker 2>It assumes you know exactly what the end user wants

355
00:17:28.519 --> 00:17:31.880
<v Speaker 2>before they have ever seen, touched, or interacted with the.

356
00:17:31.839 --> 00:17:33.559
<v Speaker 1>Product, which never happens never.

357
00:17:33.920 --> 00:17:37.039
<v Speaker 2>So to solve this, the industry invented the iterative and

358
00:17:37.119 --> 00:17:41.279
<v Speaker 2>spiral models. Instead of pouring concrete, it's more like sketching

359
00:17:41.279 --> 00:17:42.759
<v Speaker 2>with a pencil before applying ink.

360
00:17:42.920 --> 00:17:43.759
<v Speaker 1>Okay, I like that.

361
00:17:44.079 --> 00:17:48.119
<v Speaker 2>You build a minimum viable product and MVP, you give

362
00:17:48.119 --> 00:17:50.839
<v Speaker 2>it to the users, immediately, watch how they actually use it,

363
00:17:51.039 --> 00:17:54.039
<v Speaker 2>and then loop back to redesign based on their real

364
00:17:54.079 --> 00:17:54.880
<v Speaker 2>world feedback.

365
00:17:54.920 --> 00:17:56.960
<v Speaker 1>Now I understand the logic, but I have to push

366
00:17:57.000 --> 00:18:00.039
<v Speaker 1>back here, isn't it terrifying to start building something and

367
00:18:00.079 --> 00:18:02.119
<v Speaker 1>when you don't even know what the final product will

368
00:18:02.119 --> 00:18:04.759
<v Speaker 1>look like. Doesn't that just invite chaos into the budget

369
00:18:04.799 --> 00:18:05.880
<v Speaker 1>and the timeline.

370
00:18:06.200 --> 00:18:09.759
<v Speaker 2>Well, it feels terrifying to traditional management because it requires

371
00:18:09.799 --> 00:18:13.400
<v Speaker 2>a radical mental shift. How so you have to accept

372
00:18:13.480 --> 00:18:17.960
<v Speaker 2>that you aren't building a finished, static product, You're cultivating

373
00:18:18.039 --> 00:18:22.640
<v Speaker 2>an evolving system. You're managing uncertainty rather than trying to

374
00:18:22.680 --> 00:18:26.960
<v Speaker 2>pretend uncertainty doesn't exist. I see, iterative models are entirely

375
00:18:26.960 --> 00:18:29.480
<v Speaker 2>about risk mitigation. You don't spend two years and ten

376
00:18:29.519 --> 00:18:31.960
<v Speaker 2>million dollars building the wrong thing. You spend two months

377
00:18:31.960 --> 00:18:34.279
<v Speaker 2>building a piece of it, check if it's actually solving

378
00:18:34.319 --> 00:18:35.880
<v Speaker 2>the problem, and a just course.

379
00:18:36.279 --> 00:18:39.920
<v Speaker 1>Okay, that makes sense. And this intense desire to manage

380
00:18:40.000 --> 00:18:44.680
<v Speaker 1>uncertainty to finally ditch those rigid waterfall factories sparked a

381
00:18:44.759 --> 00:18:48.119
<v Speaker 1>huge revolution in the industry, the Agile revolution.

382
00:18:47.920 --> 00:18:49.400
<v Speaker 2>The famous agile. Right.

383
00:18:49.480 --> 00:18:51.799
<v Speaker 1>We hear agile used as a corporate buzzword all the

384
00:18:51.839 --> 00:18:55.000
<v Speaker 1>time now, But at its core, agile is about straight

385
00:18:55.039 --> 00:18:59.240
<v Speaker 1>sprints of work. It values functional working software over sick

386
00:18:59.279 --> 00:19:03.119
<v Speaker 1>binders of theoretical documentation, and it demands constant face to

387
00:19:03.119 --> 00:19:08.160
<v Speaker 1>face communication. But Inside the Agile framework, there's a fascinating,

388
00:19:08.160 --> 00:19:13.960
<v Speaker 1>almost extreme offshoot. It's literally called extreme programming or XP.

389
00:19:14.279 --> 00:19:18.359
<v Speaker 2>Extreme programming takes the best, most effective practices of software

390
00:19:18.359 --> 00:19:20.440
<v Speaker 2>development and dials them up to eleven.

391
00:19:20.599 --> 00:19:21.200
<v Speaker 1>It really does.

392
00:19:21.319 --> 00:19:24.160
<v Speaker 2>It relies on a set of strict rules that actively

393
00:19:24.240 --> 00:19:26.720
<v Speaker 2>challenge almost everything traditional management stands for.

394
00:19:26.920 --> 00:19:29.480
<v Speaker 1>Okay, let's run through some of the wildest ones, starting

395
00:19:29.480 --> 00:19:32.200
<v Speaker 1>with the concept of JBGE just barely good enough.

396
00:19:32.279 --> 00:19:33.400
<v Speaker 2>Oh, this is a great one.

397
00:19:33.599 --> 00:19:38.319
<v Speaker 1>In XP, heavyweight documentation is explicitly banned. You only write

398
00:19:38.440 --> 00:19:41.279
<v Speaker 1>exactly enough documentation so the next person can pick up

399
00:19:41.279 --> 00:19:43.519
<v Speaker 1>the code and understand it. No more five hundred page

400
00:19:43.559 --> 00:19:48.480
<v Speaker 1>specification binders. But wait, if Agile bans heavy documentation, how

401
00:19:48.519 --> 00:19:51.000
<v Speaker 1>on earth does a new employee know what they're supposed

402
00:19:51.000 --> 00:19:54.240
<v Speaker 1>to be doing. Doesn't institutional knowledge just vanish?

403
00:19:54.319 --> 00:19:57.200
<v Speaker 2>Well, it forces the code itself to be the documentation.

404
00:19:57.599 --> 00:19:58.920
<v Speaker 2>What do you mean if you have to write a

405
00:19:58.960 --> 00:20:01.599
<v Speaker 2>ten page manual to explain what a single piece of

406
00:20:01.640 --> 00:20:07.200
<v Speaker 2>code does? That code is too complex. JBGE forces programmers

407
00:20:07.400 --> 00:20:10.240
<v Speaker 2>to write simple, elegant, readable logic.

408
00:20:10.400 --> 00:20:12.160
<v Speaker 1>Oh, so the code is so clean you don't need

409
00:20:12.200 --> 00:20:15.720
<v Speaker 1>a manual exactly. That makes total sense, which brings us

410
00:20:15.759 --> 00:20:19.759
<v Speaker 1>to TDD. Test driven development. Now, this is the one

411
00:20:19.759 --> 00:20:21.079
<v Speaker 1>that completely broke my brain.

412
00:20:21.160 --> 00:20:22.480
<v Speaker 2>It's so counterintuitive.

413
00:20:22.599 --> 00:20:25.720
<v Speaker 1>It is. In traditional coding, you write the software and

414
00:20:25.759 --> 00:20:28.000
<v Speaker 1>then you write a test to make sure the software works.

415
00:20:28.400 --> 00:20:30.640
<v Speaker 1>In TDD, you literally write the test first.

416
00:20:30.759 --> 00:20:34.000
<v Speaker 2>Yes, it completely flips the psychology of coding. You write

417
00:20:34.000 --> 00:20:36.359
<v Speaker 2>a strict test for a feature that doesn't exist.

418
00:20:36.079 --> 00:20:37.720
<v Speaker 1>Yet, which means the test fails.

419
00:20:38.079 --> 00:20:40.680
<v Speaker 2>Naturally the test fails, then your only job is to

420
00:20:40.680 --> 00:20:43.640
<v Speaker 2>write the exact minimum amount of code required to make

421
00:20:43.680 --> 00:20:46.920
<v Speaker 2>that specific test pass. Wow, not a single line. More.

422
00:20:47.720 --> 00:20:50.240
<v Speaker 2>It ensures that every single piece of logic in your

423
00:20:50.279 --> 00:20:52.920
<v Speaker 2>system is constantly automatically verifiable.

424
00:20:53.000 --> 00:20:55.519
<v Speaker 1>That is brilliant, and that leads right into the rule

425
00:20:55.559 --> 00:20:58.920
<v Speaker 1>of simple design, which has just the greatest acronym. Ever,

426
00:20:59.240 --> 00:21:02.799
<v Speaker 1>ya aga, you aren't gonna need it. The rule is

427
00:21:03.039 --> 00:21:06.240
<v Speaker 1>you never ever write code for a feature you anticipate

428
00:21:06.319 --> 00:21:09.920
<v Speaker 1>needing in the future. You only solve today's immediate problem,

429
00:21:10.000 --> 00:21:13.119
<v Speaker 1>right like, don't build a complex data portal just because

430
00:21:13.160 --> 00:21:15.720
<v Speaker 1>the marketing team might want to track analytics next year.

431
00:21:16.039 --> 00:21:16.880
<v Speaker 1>Yag and I.

432
00:21:17.039 --> 00:21:19.759
<v Speaker 2>It aggressively stop speculative coding, which is honestly one of

433
00:21:19.799 --> 00:21:22.119
<v Speaker 2>the biggest time wasterers in the industry, I bet. But

434
00:21:22.319 --> 00:21:25.960
<v Speaker 2>the most controversial rule in extreme programming, without a doubt

435
00:21:26.240 --> 00:21:27.279
<v Speaker 2>is pair programming.

436
00:21:27.400 --> 00:21:30.200
<v Speaker 1>Okay, I have to stop us dead right here. Pair programming.

437
00:21:30.839 --> 00:21:34.880
<v Speaker 1>The rule states, you have two programmers sitting at one

438
00:21:35.279 --> 00:21:36.279
<v Speaker 1>single keyboard.

439
00:21:36.319 --> 00:21:36.880
<v Speaker 2>One keyboard.

440
00:21:36.920 --> 00:21:39.960
<v Speaker 1>Yeah. One is the driver who physically types, and the

441
00:21:40.000 --> 00:21:43.359
<v Speaker 1>other is the navigator, who reviews every single line in

442
00:21:43.400 --> 00:21:44.960
<v Speaker 1>real time as it appears on the screen.

443
00:21:45.119 --> 00:21:45.599
<v Speaker 2>That's the rule.

444
00:21:45.720 --> 00:21:50.160
<v Speaker 1>Wait, hold on, you are paying two highly expensive six

445
00:21:50.200 --> 00:21:53.799
<v Speaker 1>figure engineers to sit at one computer and do one job.

446
00:21:54.440 --> 00:21:57.279
<v Speaker 1>How on earth does a manager justify that labor cost

447
00:21:57.319 --> 00:21:58.279
<v Speaker 1>to the finance department.

448
00:21:58.480 --> 00:22:01.119
<v Speaker 2>Well, on a traditional spreadsheet, it looks absolutely insane.

449
00:22:01.119 --> 00:22:01.720
<v Speaker 1>It really does.

450
00:22:01.880 --> 00:22:05.920
<v Speaker 2>But the math is incredibly counterintuitive, and it goes right

451
00:22:05.960 --> 00:22:09.880
<v Speaker 2>back to our discussion on the crushing cognitive load of debugging. Okay,

452
00:22:10.000 --> 00:22:13.240
<v Speaker 2>finding and fixing a bug is exponentially more expensive than

453
00:22:13.279 --> 00:22:15.680
<v Speaker 2>writing the code in the first place. When you use

454
00:22:15.720 --> 00:22:19.200
<v Speaker 2>pair programming, it takes about fifteen percent more total man

455
00:22:19.200 --> 00:22:23.079
<v Speaker 2>hours to write a feature, but it produces fifteen percent

456
00:22:23.119 --> 00:22:24.599
<v Speaker 2>fewer defects.

457
00:22:24.440 --> 00:22:28.319
<v Speaker 1>So it's essentially buying an insurance policy against crippling bugs.

458
00:22:28.519 --> 00:22:32.160
<v Speaker 2>Exactly the navigator catches typos before the file is even saved.

459
00:22:32.599 --> 00:22:35.279
<v Speaker 2>They suggest better, cleaner design patterns on.

460
00:22:35.200 --> 00:22:37.519
<v Speaker 1>The fly because they aren't bogged down on the typing.

461
00:22:37.720 --> 00:22:40.279
<v Speaker 2>Right, a solar programmer might get stuck for two days

462
00:22:40.359 --> 00:22:43.519
<v Speaker 2>chasing a cascading logic error. In pair programming, that never

463
00:22:43.559 --> 00:22:46.240
<v Speaker 2>happens because you have a second set of eyes constantly

464
00:22:46.279 --> 00:22:47.240
<v Speaker 2>auditing the logic.

465
00:22:47.359 --> 00:22:48.039
<v Speaker 1>That's huge.

466
00:22:48.359 --> 00:22:51.920
<v Speaker 2>Plus, the institutional knowledge is instantly shared. If one of

467
00:22:51.920 --> 00:22:54.920
<v Speaker 2>those programmers leaves the company, the other knows exactly how

468
00:22:54.920 --> 00:22:56.640
<v Speaker 2>that entire section of code works.

469
00:22:56.920 --> 00:23:00.839
<v Speaker 1>So no single point of failure exactly. But XP isn't perfect, right,

470
00:23:01.279 --> 00:23:02.759
<v Speaker 1>It has a fatal Achilles heel.

471
00:23:02.920 --> 00:23:06.200
<v Speaker 2>It does. XP requires an on site customer, oh right,

472
00:23:06.400 --> 00:23:10.119
<v Speaker 2>Because you aren't writing five hundred page requirement documents. Someone

473
00:23:10.160 --> 00:23:12.960
<v Speaker 2>officially representing the end user has to be sitting in

474
00:23:12.960 --> 00:23:15.759
<v Speaker 2>the room with the development team available at all times

475
00:23:16.000 --> 00:23:17.880
<v Speaker 2>to answer questions and steer the ship.

476
00:23:18.079 --> 00:23:19.000
<v Speaker 1>And that's the problem.

477
00:23:19.119 --> 00:23:21.880
<v Speaker 2>Yeah, in reality, clients have their own day jobs. Getting

478
00:23:21.880 --> 00:23:24.200
<v Speaker 2>a customer to ship with an engineering team forty hours

479
00:23:24.200 --> 00:23:25.680
<v Speaker 2>a week almost never happens.

480
00:23:25.880 --> 00:23:28.559
<v Speaker 1>Yeah, that seems like a massive roadblock. But you know,

481
00:23:28.640 --> 00:23:31.240
<v Speaker 1>even if you never write a single line of code.

482
00:23:31.759 --> 00:23:34.200
<v Speaker 1>Taking these concepts out of the software world for a

483
00:23:34.240 --> 00:23:37.200
<v Speaker 1>second provide some really brilliant life acts.

484
00:23:37.400 --> 00:23:38.599
<v Speaker 2>Oh absolutely, think.

485
00:23:38.480 --> 00:23:41.480
<v Speaker 1>About how you operate in your own daily tasks. Yah,

486
00:23:41.519 --> 00:23:43.599
<v Speaker 1>G and I you aren't going to need it. Stop

487
00:23:43.640 --> 00:23:46.240
<v Speaker 1>over complicating the future and just solve the problem right

488
00:23:46.279 --> 00:23:50.400
<v Speaker 1>in front of you. Yes, and jbge just barely good enough.

489
00:23:50.640 --> 00:23:54.559
<v Speaker 1>How often do you overplan, overdocument, and overthink a project

490
00:23:54.599 --> 00:23:57.160
<v Speaker 1>instead of just doing the work. You can use these

491
00:23:57.200 --> 00:24:00.839
<v Speaker 1>exact frameworks right now to start procrastinating and start executing.

492
00:24:01.079 --> 00:24:05.799
<v Speaker 2>It really is a methodology entirely built around confronting reality

493
00:24:05.960 --> 00:24:08.759
<v Speaker 2>exactly as it is, rather than how you planned it

494
00:24:08.799 --> 00:24:09.880
<v Speaker 2>to be on a whiteboard.

495
00:24:10.000 --> 00:24:13.720
<v Speaker 1>Well said, We've covered a tremendous amount of ground today,

496
00:24:14.240 --> 00:24:17.039
<v Speaker 1>from the solo artist hacking code in their bedroom to

497
00:24:17.119 --> 00:24:20.880
<v Speaker 1>the rigid, factory like waterfall models, all the way to

498
00:24:20.960 --> 00:24:24.720
<v Speaker 1>the nimble, paired up, test driven world of extreme programming.

499
00:24:24.839 --> 00:24:25.759
<v Speaker 2>It's been a journey.

500
00:24:26.079 --> 00:24:29.920
<v Speaker 1>It reveals the staggering human effort, the philosophical battles, and

501
00:24:30.000 --> 00:24:34.400
<v Speaker 1>the psychological friction behind the digital tools we blindly take

502
00:24:34.440 --> 00:24:36.400
<v Speaker 1>for granted every time we swipe the screen.

503
00:24:37.079 --> 00:24:39.440
<v Speaker 2>It serves as a great reminder that software isn't just

504
00:24:39.519 --> 00:24:44.839
<v Speaker 2>cold math and logic. It is deeply human. It is organized, messy,

505
00:24:45.200 --> 00:24:47.000
<v Speaker 2>brilliant human collaboration.

506
00:24:47.279 --> 00:24:50.119
<v Speaker 1>It really is, which leads me with one final kind

507
00:24:50.160 --> 00:24:51.640
<v Speaker 1>of provocative thought for you to chew on.

508
00:24:51.839 --> 00:24:52.279
<v Speaker 2>Let's hear it.

509
00:24:52.359 --> 00:24:55.359
<v Speaker 1>We've talked extensively about how measuring a programmer's worth by

510
00:24:55.440 --> 00:24:58.480
<v Speaker 1>lines of code is a terrible, outdated metric. Well, right now,

511
00:24:58.559 --> 00:25:02.079
<v Speaker 1>artificial intelligence is getting in incredibly proficient at churning out

512
00:25:02.440 --> 00:25:04.119
<v Speaker 1>bulk lines of boilerplate code.

513
00:25:04.160 --> 00:25:04.759
<v Speaker 2>It really is.

514
00:25:05.119 --> 00:25:07.519
<v Speaker 1>So if AI eventually takes over the manual labor of

515
00:25:07.559 --> 00:25:10.599
<v Speaker 1>actually typing out all those lines, what happens to the

516
00:25:10.680 --> 00:25:13.319
<v Speaker 1>human software engineer? Do we revert all the way back

517
00:25:13.319 --> 00:25:14.799
<v Speaker 1>to the beginning of our metaphor list?

518
00:25:14.920 --> 00:25:15.079
<v Speaker 2>Oh?

519
00:25:15.119 --> 00:25:18.920
<v Speaker 1>Interesting, well, human programmers go back to being pure architects

520
00:25:19.000 --> 00:25:21.680
<v Speaker 1>or artists, where we just dream up the concepts and

521
00:25:21.839 --> 00:25:25.799
<v Speaker 1>structural safety and the machine acts as our master craftsman

522
00:25:25.880 --> 00:25:26.559
<v Speaker 1>doing the building.

523
00:25:26.759 --> 00:25:29.680
<v Speaker 2>That is the exact frontier we are standing on right now.

524
00:25:30.279 --> 00:25:34.039
<v Speaker 2>The tools are shifting rapidly, but the need for human vision,

525
00:25:34.559 --> 00:25:38.279
<v Speaker 2>risk mitigation, and system level thinking is only getting more critical.

526
00:25:38.640 --> 00:25:40.680
<v Speaker 1>It's gonna be fascinating to watch. Thank you so much

527
00:25:40.680 --> 00:25:42.839
<v Speaker 1>for joining us on this deep dive. Next time you

528
00:25:42.839 --> 00:25:44.559
<v Speaker 1>look at the apps on your phone or check your

529
00:25:44.599 --> 00:25:46.960
<v Speaker 1>bank balance online, we hope you have a whole new

530
00:25:47.039 --> 00:25:49.880
<v Speaker 1>level of respect for the invisible suspension bridges holding it

531
00:25:49.920 --> 00:25:52.960
<v Speaker 1>all together. Keep questioning the structures around you, and we'll

532
00:25:52.960 --> 00:25:53.720
<v Speaker 1>see you next time.