1
00:00:00,000 --> 00:00:02,200
Hey, a quick message. 
For those of you who are 

2
00:00:02,200 --> 00:00:04,300
listening to this episode on 
Spotify. 

3
00:00:04,600 --> 00:00:07,500
I have a small favor to ask 
Spotify. 

4
00:00:07,500 --> 00:00:10,100
Now allows mobile users to rate 
podcasts. 

5
00:00:10,400 --> 00:00:13,300
I would really appreciate it. 
If you can take a quick, pause 

6
00:00:13,300 --> 00:00:16,100
to go to the technique Journal 
podcast page, and leave your 

7
00:00:16,100 --> 00:00:18,800
favorite show. 
Your best rating on Spotify. 

8
00:00:19,200 --> 00:00:21,800
It will help me a lot to get 
this podcast to reach more 

9
00:00:21,800 --> 00:00:24,300
people on the platform. 
Thanks a lot. 

10
00:00:25,100 --> 00:00:28,500
The simplest way to describe 
craftsmanship is pride of 

11
00:00:28,500 --> 00:00:30,700
workmanship. 
If Or a programmer. 

12
00:00:30,900 --> 00:00:33,700
Do you go home at night every 
day? 

13
00:00:33,700 --> 00:00:36,500
And look in the mirror and say 
to yourself. 

14
00:00:36,900 --> 00:00:40,400
I did a really good job. 
I'm proud of the work. 

15
00:00:40,400 --> 00:00:44,600
I did not only did I write 
software that worked. 

16
00:00:44,600 --> 00:00:49,000
But I wrote it well, and I wrote
it in a good way. 

17
00:00:49,200 --> 00:00:52,200
The process I followed was a 
good process. 

18
00:00:52,500 --> 00:00:56,200
Do you go home and feel good 
about yourself and good about 

19
00:00:56,200 --> 00:01:00,200
your job or if you have to go 
home and take a shower and Are 

20
00:01:00,200 --> 00:01:03,200
too many programmers, have to go
home and take a shower because 

21
00:01:03,200 --> 00:01:07,500
they've gotten caught into this 
very dominant mindset. 

22
00:01:07,900 --> 00:01:13,000
That speed, overrides 
everything, you must program 

23
00:01:13,000 --> 00:01:17,900
fast and they get caught in this
trap of thinking that speed 

24
00:01:17,900 --> 00:01:25,300
comes from rushing. 
Hey everyone. 

25
00:01:25,800 --> 00:01:27,700
My name is Henry Surya with 
Robin. 

26
00:01:29,400 --> 00:01:32,300
And you're listening to the 
technology, you know, podcast 

27
00:01:32,700 --> 00:01:35,000
the show where I'll be bringing 
you the greatest technical 

28
00:01:35,000 --> 00:01:38,800
leaders practitioners and 
thought leaders in the industry 

29
00:01:39,200 --> 00:01:43,600
to discuss about their Journey 
ideas and practices that we all 

30
00:01:43,600 --> 00:01:47,200
can learn and apply to build a 
highly performing technical team

31
00:01:47,600 --> 00:01:50,000
and to make an impact in your 
personal work. 

32
00:01:50,400 --> 00:01:58,700
So let's dive into our Journal. 
Hello, to all of you, my friends

33
00:01:58,700 --> 00:02:00,800
and listen. - welcome to the 
technology. 

34
00:02:00,800 --> 00:02:03,600
Now, podcast the show where you 
can learn about technical 

35
00:02:03,600 --> 00:02:07,300
leadership and Excellence from 
my conversations, with great 

36
00:02:07,300 --> 00:02:10,900
thought, leaders out there. 
And today is our episode number 

37
00:02:10,900 --> 00:02:13,300
90. 
We are getting really closer 

38
00:02:13,400 --> 00:02:17,200
just 10 more episodes to reach 
the hundredth episode milestone.

39
00:02:17,500 --> 00:02:20,400
For those of you who have been 
following me and this podcast 

40
00:02:20,400 --> 00:02:23,700
for a while now, thank you so 
much for your continuous support

41
00:02:23,700 --> 00:02:25,400
and for listening to the 
episodes. 

42
00:02:25,700 --> 00:02:29,200
You are one of the main reasons 
that gives me the energy to Our 

43
00:02:29,200 --> 00:02:32,300
new episode week in week out, 
and I hope to be able to 

44
00:02:32,300 --> 00:02:35,800
continue doing this and deliver 
a lot of learning contents for 

45
00:02:35,800 --> 00:02:38,100
all of us. 
And for those of you who are 

46
00:02:38,100 --> 00:02:41,000
listening to technology, you 
know, for the first time, don't 

47
00:02:41,000 --> 00:02:44,600
forget to subscribe and follow 
the show on your podcast app and

48
00:02:44,600 --> 00:02:47,600
social media on LinkedIn. 
Twitter and Instagram. 

49
00:02:48,100 --> 00:02:50,700
And if anyone wants to 
contribute to the creation of 

50
00:02:50,700 --> 00:02:54,600
this podcast, support me by 
subscribing as a patron at 

51
00:02:54,600 --> 00:02:59,200
technology not deaf / Patron. 
Today, I am really, really 

52
00:02:59,200 --> 00:03:02,400
excited to share my conversation
with one of the great thought 

53
00:03:02,400 --> 00:03:05,900
leaders in the surf industry. 
When I started my professional 

54
00:03:05,900 --> 00:03:08,300
career. 
I used to read and watch a lot 

55
00:03:08,300 --> 00:03:11,800
of his great work, such as clean
coat, clean coder, and he's 

56
00:03:11,800 --> 00:03:15,100
clean code video series. 
And I grew a lot by learning 

57
00:03:15,100 --> 00:03:18,600
from those resources in my early
career and I still continue 

58
00:03:18,600 --> 00:03:20,800
reading. 
Every new clean series book 

59
00:03:20,800 --> 00:03:24,600
published in the last few years.
So, it felt quite surreal to 

60
00:03:24,600 --> 00:03:27,500
finally have a chance to talk to
him personally, for this. 

61
00:03:27,700 --> 00:03:29,700
Be sewed. 
But this is really one of the 

62
00:03:29,700 --> 00:03:33,900
most fun episodes that I've had 
in the podcast, as many of you 

63
00:03:33,900 --> 00:03:35,400
would have already known by. 
Now. 

64
00:03:35,500 --> 00:03:37,800
My guest for today's episode is 
Robert C. 

65
00:03:37,800 --> 00:03:42,100
Martin more widely known as 
Uncle, Bob he is the co-founder 

66
00:03:42,100 --> 00:03:44,800
of clean code, s.com. 
And acclaim speaker. 

67
00:03:44,800 --> 00:03:48,300
At conferences, worldwide 
prolific author of multiple, 

68
00:03:48,300 --> 00:03:51,100
best-selling books. 
And one of the authors of the 

69
00:03:51,100 --> 00:03:55,400
agile, Manifesto in this 
episode, Uncle Bob shared some 

70
00:03:55,400 --> 00:03:57,500
insights from his latest book 
clean. 

71
00:03:57,600 --> 00:04:01,100
Craftsmanship, he first started 
by sharing his view on the 

72
00:04:01,100 --> 00:04:04,100
current major challenge of the 
software development industry 

73
00:04:04,400 --> 00:04:07,300
that as a young discipline, It 
suffers from the state of 

74
00:04:07,300 --> 00:04:11,600
Perpetual inexperience amid, the
exponential acceleration of 

75
00:04:11,600 --> 00:04:15,100
demand for new programmers. 
While not having enough, highly 

76
00:04:15,100 --> 00:04:18,200
experienced programmers to 
impart valuable knowledge and 

77
00:04:18,200 --> 00:04:21,800
experience from their Journey, 
which then drove Uncle Bob 

78
00:04:21,800 --> 00:04:25,600
writing this book to help Define
the disciplines standards and 

79
00:04:25,600 --> 00:04:27,500
ethics for establishing 
software. 

80
00:04:27,700 --> 00:04:31,700
Osman ship Uncle Bob then touch 
on the five key disciplines of 

81
00:04:31,700 --> 00:04:34,500
clean craftsmanship, 
specifically focusing on two 

82
00:04:34,500 --> 00:04:37,400
main disciplines which are 
test-driven development and 

83
00:04:37,400 --> 00:04:40,600
refactoring after covering the 
disciplines Uncle. 

84
00:04:40,600 --> 00:04:44,000
Bob also described a few 
essential standards and ethics 

85
00:04:44,000 --> 00:04:47,300
of clean craftsmanship. 
Such as never ship shit. 

86
00:04:47,400 --> 00:04:50,600
Always be ready. 
Do no harm and estimate. 

87
00:04:50,600 --> 00:04:54,000
Honestly, I'm super thrilled 
having this conversation with 

88
00:04:54,000 --> 00:04:55,900
Uncle. 
Bob diving deep into clean 

89
00:04:55,900 --> 00:04:58,300
craftsmanship. 
And the tree is and Do things as

90
00:04:58,300 --> 00:05:00,900
part of that craftsmanship, 
which are the disciplines 

91
00:05:00,900 --> 00:05:03,100
standards and ethics, which I 
believe. 

92
00:05:03,100 --> 00:05:06,200
If all of us try to adhere to, 
the software industry, would 

93
00:05:06,200 --> 00:05:09,700
continue to mature towards a 
better future, especially in the

94
00:05:09,700 --> 00:05:12,100
current ERA of software, eating 
the world. 

95
00:05:12,400 --> 00:05:15,900
If you enjoyed this episode and 
find it useful, please share it 

96
00:05:15,900 --> 00:05:18,500
with your friends and colleagues
who may also benefit from 

97
00:05:18,500 --> 00:05:21,600
listening to this episode. 
Leave a rating and review on 

98
00:05:21,600 --> 00:05:25,200
your podcast app and share your 
comments or feedback about this 

99
00:05:25,200 --> 00:05:28,800
episode on social media. 
It is Ultimate mission to make 

100
00:05:28,800 --> 00:05:31,000
this podcast available to more 
people. 

101
00:05:31,300 --> 00:05:34,100
And I need your help to support 
me towards fulfilling my 

102
00:05:34,100 --> 00:05:36,100
mission. 
Before we continue the 

103
00:05:36,100 --> 00:05:38,800
conversation. 
Let's hear some words from our 

104
00:05:38,800 --> 00:05:41,200
sponsor. 
Today's episode is proudly 

105
00:05:41,200 --> 00:05:44,800
sponsored by skills matter. 
The global community and events 

106
00:05:44,800 --> 00:05:47,500
platform. 
With more than 100,000 software 

107
00:05:47,500 --> 00:05:51,100
professionals here members. 
Can organize their learning 

108
00:05:51,100 --> 00:05:53,600
experiences around the 
technology topics. 

109
00:05:53,600 --> 00:05:57,000
They care about most you get 
on-demand access to their 

110
00:05:57,000 --> 00:05:59,200
latest. 
Content thought leadership 

111
00:05:59,200 --> 00:06:02,800
insights, as well as the 
exciting schedule of tech events

112
00:06:02,900 --> 00:06:06,700
running across all time zones. 
So whether devops our data 

113
00:06:06,700 --> 00:06:10,700
science is your bus or you are 
fan of functional programming or

114
00:06:10,700 --> 00:06:13,400
all things Cloud. 
You can make real connections 

115
00:06:13,400 --> 00:06:17,500
with people who share your 
interests head on over to skills

116
00:06:17,500 --> 00:06:20,800
method or Cam to become part of 
the tech community that matters 

117
00:06:20,800 --> 00:06:23,400
most to you. 
It's free to join and you will 

118
00:06:23,400 --> 00:06:25,900
find it easy to keep up with the
latest tech. 

119
00:06:25,900 --> 00:06:29,900
Trends are you looking New cool 
swag pacolet Journal. 

120
00:06:29,900 --> 00:06:33,100
Now offers you some swags that 
you can purchase online. 

121
00:06:33,500 --> 00:06:37,300
These wax are printed on demand 
based on your preference and 

122
00:06:37,300 --> 00:06:39,900
will be delivered safely to you 
all over the world. 

123
00:06:39,900 --> 00:06:43,200
We're shipping is available. 
Check out all the cool swag is 

124
00:06:43,200 --> 00:06:45,000
available by visiting 
technology. 

125
00:06:45,000 --> 00:06:48,400
Know that death / shop and don't
forget to break yourself. 

126
00:06:48,500 --> 00:06:50,600
Once you receive any of those 
tracks. 

127
00:06:53,400 --> 00:06:55,600
Hello everyone, welcome back to 
another new episode of the 

128
00:06:55,600 --> 00:06:57,400
package, you know, podcast 
today. 

129
00:06:57,400 --> 00:07:00,400
I I am really, really excited. 
Actually, my guest today. 

130
00:07:00,400 --> 00:07:02,600
I think most of you would have 
known him. 

131
00:07:02,800 --> 00:07:05,600
He is widely known as Uncle. 
Bob Robert C. 

132
00:07:05,600 --> 00:07:08,900
Martin is in the show today. 
Before we start actually, I just

133
00:07:08,900 --> 00:07:12,100
want to say Uncle Bob, you have 
been one of my heroes in the 

134
00:07:12,100 --> 00:07:14,600
software development World. 
In my early career. 

135
00:07:14,600 --> 00:07:16,300
Actually. 
I read a lot of your books. 

136
00:07:16,400 --> 00:07:18,700
Clean code, clean coders, 
whatever blocks. 

137
00:07:18,700 --> 00:07:21,500
And even your clean coders 
series, the videos. 

138
00:07:21,700 --> 00:07:23,300
I watch her number of the 
episodes. 

139
00:07:23,500 --> 00:07:25,800
So I'm really, really pleased to
have this chance to have a 

140
00:07:25,808 --> 00:07:27,500
conversation with you today and 
learning. 

141
00:07:27,600 --> 00:07:30,900
From your story and experience. 
I know that many people would 

142
00:07:30,900 --> 00:07:33,500
have known you by now. 
But before we start, I always 

143
00:07:33,500 --> 00:07:36,500
like to ask my guests to 
actually share their story, 

144
00:07:36,500 --> 00:07:39,400
their Journey or maybe any 
turning points or highlights in 

145
00:07:39,400 --> 00:07:46,100
their career, gee whiz. 
I got involved with computers at

146
00:07:46,100 --> 00:07:49,300
the age of 12. 
My mother bought me a little 

147
00:07:49,300 --> 00:07:51,400
plastic computer. 
I have it over here. 

148
00:07:51,700 --> 00:07:54,400
Well, there it is, little 
plastic computer and it's got a 

149
00:07:54,407 --> 00:07:56,500
little readout with ones and 
zeros on it. 

150
00:07:56,700 --> 00:07:59,400
There's three. 
B in here and they can go back 

151
00:07:59,400 --> 00:08:02,200
and forth to 1 and 0. 
It looks pristine. 

152
00:08:03,000 --> 00:08:05,100
It is the original, it is my 
original. 

153
00:08:05,100 --> 00:08:09,400
So it's 57 years old. 
It's not functioning at the 

154
00:08:09,400 --> 00:08:12,800
moment because the rubber bands 
that I have up here are old and 

155
00:08:12,800 --> 00:08:15,200
rotten. 
But otherwise, you could program

156
00:08:15,200 --> 00:08:19,500
it to count in binary or 
countdown or add to b, or 

157
00:08:19,500 --> 00:08:22,800
subtract to B solve a number of 
logic puzzles. 

158
00:08:23,100 --> 00:08:26,900
I was very fascinated by this 
machine at the age of 12. 

159
00:08:27,600 --> 00:08:31,700
So I taught myself how to 
program which required that I 

160
00:08:31,700 --> 00:08:34,799
learned Boolean, algebra and 
learn about State machines, 

161
00:08:34,799 --> 00:08:38,299
learn about logic and that set 
me on the path to becoming a 

162
00:08:38,308 --> 00:08:41,700
program. 
So I started very early the year

163
00:08:41,700 --> 00:08:47,200
was 1964, could long time ago, 
my father noticed my interest 

164
00:08:47,200 --> 00:08:52,000
and he somehow managed to get me
books on Fortran and COBOL and 

165
00:08:52,000 --> 00:08:57,200
pl1, the suite of languages that
was popular at the time and I 

166
00:08:57,200 --> 00:08:59,500
just Devoured those books. 
I've read them. 

167
00:08:59,500 --> 00:09:02,900
And tried to understand that I 
wrote lots and lots of software 

168
00:09:03,000 --> 00:09:05,900
that I could not execute, 
because they didn't have a 

169
00:09:05,908 --> 00:09:11,200
machine, but I still wrote it in
pencil on paper. 

170
00:09:11,200 --> 00:09:15,700
You know how when you're at a 
preteen or a teen Ager, you can 

171
00:09:15,700 --> 00:09:19,200
really focus on something. 
I got pretty focused on that 

172
00:09:19,200 --> 00:09:22,600
stuff. 
My father figured out a way for 

173
00:09:22,600 --> 00:09:27,100
my friends and I to visit the 
digital equipment sales office, 

174
00:09:27,100 --> 00:09:31,500
where they Had some pdp-8, sand 
pdp-10 s just sitting there on 

175
00:09:31,500 --> 00:09:35,200
the floor and the sales office. 
So those people would allow me 

176
00:09:35,200 --> 00:09:39,700
to come in on weekends and play 
with their computers, my 

177
00:09:39,700 --> 00:09:43,100
friends, and I would sit there 
and we would toggle in programs 

178
00:09:43,100 --> 00:09:46,900
into a 8 and make it executes. 
And we learned how to edit 

179
00:09:46,900 --> 00:09:50,400
programs on paper tape. 
Using a teletype. 

180
00:09:50,600 --> 00:09:53,000
There's an awful lot of that 
stuff that I was doing. 

181
00:09:53,000 --> 00:09:57,400
I got my first job as a 
programmer probably at age 16. 

182
00:09:57,500 --> 00:10:01,400
I mean that was a temporary 
summer job Road, a little bit of

183
00:10:01,400 --> 00:10:04,500
Assembly Language code for a 
Honeywell h200. 

184
00:10:04,700 --> 00:10:09,400
Got my first full-time job as a 
programmer at age 18, writing 

185
00:10:09,400 --> 00:10:11,600
some COBOL and then very 
rapidly. 

186
00:10:11,600 --> 00:10:15,500
After that Assembly Language in 
an old Mini computer called a 

187
00:10:15,508 --> 00:10:18,200
variance 620 gas. 
So you don't need to know all 

188
00:10:18,200 --> 00:10:23,300
that, but gives you a background
of where I came from very early 

189
00:10:23,300 --> 00:10:27,900
on with very low level machines.
Thanks for sharing your And 

190
00:10:27,900 --> 00:10:30,200
actually, the toy that got you 
into all this. 

191
00:10:30,400 --> 00:10:32,600
It's really fascinating. 
And you still have that toy, 

192
00:10:32,600 --> 00:10:34,600
right? 
So 50 million years ago. 

193
00:10:34,600 --> 00:10:37,200
So that is really a Monumental 
toy. 

194
00:10:37,200 --> 00:10:40,100
I believe, I always like 
devouring your content into your

195
00:10:40,100 --> 00:10:43,800
books or maybe your videos. 
You actually gave some history 

196
00:10:43,800 --> 00:10:46,700
on overview of what actually 
happened long time ago, maybe 

197
00:10:46,700 --> 00:10:50,300
before I was born even. 
So, I always appreciated those 

198
00:10:50,300 --> 00:10:52,200
stories. 
Thanks for sharing your story at

199
00:10:52,200 --> 00:10:54,000
the beginning of this episode. 
Sure. 

200
00:10:54,300 --> 00:10:56,600
So, Uncle Bob, do you have 
written a number of books? 

201
00:10:56,600 --> 00:10:59,000
But today we go. 
Gonna cover mostly from your 

202
00:10:59,000 --> 00:11:01,800
latest book, which is titled 
clean craftsmanship, the 

203
00:11:01,800 --> 00:11:03,700
disciplines standards and 
ethics. 

204
00:11:04,000 --> 00:11:07,100
I think if I'm not mistaken, you
have been writing this even long

205
00:11:07,100 --> 00:11:10,000
ago, maybe through blog posts 
and some of the webinars and 

206
00:11:10,000 --> 00:11:13,000
conferences that you did, but 
maybe if you can give us some 

207
00:11:13,100 --> 00:11:16,300
overview of what other reasons 
that now, actually, you wrote 

208
00:11:16,300 --> 00:11:21,600
this book clean craftsmanship. 
The book is a culmination of a 

209
00:11:21,600 --> 00:11:25,100
lot of topics. 
So I've started writing books in

210
00:11:25,100 --> 00:11:29,200
1995 1994. 
I wrote books about software 

211
00:11:29,200 --> 00:11:35,000
design object-oriented design. 
I wrote a book in 2002 which was

212
00:11:35,100 --> 00:11:37,500
agile software development 
principles patterns and 

213
00:11:37,500 --> 00:11:41,300
practices that really brought 
all of the design principles and

214
00:11:41,300 --> 00:11:45,100
all the practices and design 
patterns, all together in a nice

215
00:11:45,100 --> 00:11:48,100
neat little bow. 
And then I started writing 

216
00:11:48,100 --> 00:11:51,200
books, like clean code. 
And that was a difficult look 

217
00:11:51,200 --> 00:11:55,600
for me to decide to write 
because who am I to tell anybody

218
00:11:55,600 --> 00:11:58,700
what clean code is? 
I'm just a But I figured 

219
00:11:58,700 --> 00:12:03,000
somebody has to write this book.
So I wrote it with the caveat at

220
00:12:03,000 --> 00:12:06,000
the beginning that you know, 
this is my way, I do it this 

221
00:12:06,000 --> 00:12:07,400
way. 
You don't have to do it this 

222
00:12:07,400 --> 00:12:09,600
way. 
It's just, you know, after 50 

223
00:12:09,600 --> 00:12:12,200
years of programming. 
Maybe you want to listen to what

224
00:12:12,200 --> 00:12:15,800
I have to say, as I was writing 
that book, there were a whole 

225
00:12:15,800 --> 00:12:18,200
bunch of topics. 
I wanted to talk about, but they

226
00:12:18,200 --> 00:12:21,600
didn't fit into that book 
because clean code is a very 

227
00:12:21,600 --> 00:12:24,800
technical book and I wanted to 
talk about all the non-technical

228
00:12:24,800 --> 00:12:27,700
things. 
So I had a whole bunch of Of 

229
00:12:27,700 --> 00:12:30,300
topics. 
I wanted to talk about once I 

230
00:12:30,300 --> 00:12:33,500
published clean code. 
I wrote the clean color. 

231
00:12:33,500 --> 00:12:35,400
It just kind of Spilled Out, 
right? 

232
00:12:35,700 --> 00:12:38,400
All this stuff that was stuck in
my brain. 

233
00:12:38,400 --> 00:12:41,800
Just kind of Spilled Out that 
the clean coders all the none 

234
00:12:41,800 --> 00:12:44,700
technical things about being a 
programmer. 

235
00:12:44,700 --> 00:12:47,300
Like what do you do when you go 
to work? 

236
00:12:47,300 --> 00:12:50,100
You've just had a big fight with
your significant other, your 

237
00:12:50,100 --> 00:12:53,000
cannot get your brain to focus 
on code. 

238
00:12:53,100 --> 00:12:55,800
How do you deal with that? 
That's the kind of stuff that's 

239
00:12:55,800 --> 00:12:58,400
in that book. 
How do you Stimate, how do you 

240
00:12:58,400 --> 00:13:00,300
deal with managers? 
All that stuff? 

241
00:13:00,800 --> 00:13:04,400
I wrote that book and then I 
started to get this idea that we

242
00:13:04,400 --> 00:13:09,200
needed to address a giant. 
The agile Community had begun in

243
00:13:09,200 --> 00:13:14,500
like 1999 and the manifesto was 
signed in 2001 and then all the 

244
00:13:14,500 --> 00:13:18,400
Consultants jumped in and they 
kind of corrected not the right 

245
00:13:18,400 --> 00:13:21,600
word, but they got involved and 
they stretched the whole 

246
00:13:21,600 --> 00:13:25,400
discipline out and I thought 
it's time for a reboot there. 

247
00:13:25,800 --> 00:13:29,600
So I wrote the clean Edge. 
I'll Book as a way to just reset

248
00:13:29,600 --> 00:13:33,800
and describe what agile was of 
how we got there and why we got 

249
00:13:33,800 --> 00:13:35,200
there. 
And where would you go? 

250
00:13:35,600 --> 00:13:38,900
And as I was writing that book, 
I thought well, there's a whole 

251
00:13:38,900 --> 00:13:41,500
bunch of other things. 
I want to say about this, but 

252
00:13:41,500 --> 00:13:43,600
they're not really tied to 
Agile. 

253
00:13:43,600 --> 00:13:46,800
They're more about the notion of
craftsmanship. 

254
00:13:46,800 --> 00:13:50,100
I put all those topics aside and
then when I was done with clean 

255
00:13:50,100 --> 00:13:51,900
agile, I thought, okay. 
I've got to write this 

256
00:13:51,900 --> 00:13:55,200
craftsmanship book, The 
craftsmanship book was kind of 

257
00:13:55,200 --> 00:14:00,400
an odd mixture of Deeply 
technical topics, very technical

258
00:14:00,400 --> 00:14:03,200
topics, having to do a test 
driven development and 

259
00:14:03,200 --> 00:14:06,200
refactoring. 
And then also this kind of pull 

260
00:14:06,200 --> 00:14:09,600
back to say, okay, we need some 
standards and we need some 

261
00:14:09,600 --> 00:14:13,000
ethics to try and balance this 
whole thing out. 

262
00:14:13,100 --> 00:14:18,200
A programmer is a deeply 
technical person, but has to be 

263
00:14:18,200 --> 00:14:22,700
governed by non technical 
Concepts, including standards 

264
00:14:22,700 --> 00:14:25,400
and ethics. 
So that book kind of ties, all 

265
00:14:25,400 --> 00:14:29,000
of those things together into a 
A nice neat little bow. 

266
00:14:29,500 --> 00:14:32,300
If you read that book, it starts
out really technical. 

267
00:14:32,500 --> 00:14:35,000
It's probably one of the most 
technical books. 

268
00:14:35,000 --> 00:14:37,500
I have written. 
In fact, ever so much technical 

269
00:14:37,500 --> 00:14:39,100
stuff in it. 
I had to put some of it on 

270
00:14:39,100 --> 00:14:41,300
video. 
So as you're reading the book, 

271
00:14:41,300 --> 00:14:45,200
it refers you to videos that you
can watch and then as the book 

272
00:14:45,200 --> 00:14:48,700
progresses, it shifts into 
standards. 

273
00:14:48,900 --> 00:14:52,300
What are the standards we try to
uphold while we are doing all 

274
00:14:52,300 --> 00:14:55,500
this deeply, technical work and 
then once we get through the 

275
00:14:55,500 --> 00:14:58,300
standards, the book shifts 
again, It says, okay. 

276
00:14:58,300 --> 00:15:02,400
Now, what are the ethical 
situations that drive those 

277
00:15:02,400 --> 00:15:05,700
standards? 
So the book proceeds from 

278
00:15:05,800 --> 00:15:09,400
disciplines deeply technical 
disciplines then to the 

279
00:15:09,400 --> 00:15:12,300
standards that drive those 
disciplines of end of the ethics

280
00:15:12,300 --> 00:15:15,600
to drive those standards. 
And that was the way I completed

281
00:15:15,600 --> 00:15:18,300
that book. 
So if I may add, that's actually

282
00:15:18,300 --> 00:15:20,600
one book that you miss, which is
clean architecture. 

283
00:15:20,900 --> 00:15:24,900
Oh, yeah, I forgot. 
Yes, so that book is also deeply

284
00:15:24,900 --> 00:15:27,300
Technical and it talks about 
clean architecture. 

285
00:15:27,400 --> 00:15:29,400
Like ports adapters and that 
kind of stuff. 

286
00:15:29,400 --> 00:15:31,200
So I think that's also what 
dimension. 

287
00:15:31,400 --> 00:15:33,700
So you mentioned about 
programmer being a technical 

288
00:15:33,700 --> 00:15:35,700
person. 
They should have the technical 

289
00:15:35,700 --> 00:15:37,500
practices. 
They should have standards and 

290
00:15:37,500 --> 00:15:40,000
ethics and if you compare it 
with other profession, like 

291
00:15:40,000 --> 00:15:42,400
maybe dr. 
Pilot lawyer and all that 

292
00:15:42,400 --> 00:15:45,600
programmers seem do not have 
those kind of things, which is 

293
00:15:45,600 --> 00:15:48,500
why I think in the beginning of 
the chapters of the book you 

294
00:15:48,500 --> 00:15:51,700
wrote about this problem 
developer now is like coming 

295
00:15:51,700 --> 00:15:54,400
from different backgrounds. 
They maybe go to the boot camp. 

296
00:15:54,500 --> 00:15:57,300
They just learn how to do those 
technical staffs, but not 

297
00:15:57,500 --> 00:16:00,500
Necessarily the standards and 
all these ethics that make them 

298
00:16:00,500 --> 00:16:03,500
the real profession. 
So tell us more about these 

299
00:16:03,500 --> 00:16:06,300
problem that you see maybe from 
your Consulting point of view, 

300
00:16:06,300 --> 00:16:08,600
or maybe from recent days that 
you see the programmers. 

301
00:16:08,600 --> 00:16:10,800
These days. 
What is the current state of the

302
00:16:10,800 --> 00:16:15,500
programmers job software? 
Use a very young discipline. 

303
00:16:15,800 --> 00:16:18,100
I want to use the word 
profession, but it's not a 

304
00:16:18,108 --> 00:16:22,000
profession because there's 
nothing that we profess a 

305
00:16:22,000 --> 00:16:27,300
profession is the assemblage of 
standards and disciplines and 

306
00:16:27,400 --> 00:16:30,700
Ethics the professionals 
professed. 

307
00:16:30,700 --> 00:16:34,500
Those things we don't have that 
but it's just because we're a 

308
00:16:34,500 --> 00:16:37,600
young discipline. 
We are very the first line of 

309
00:16:37,600 --> 00:16:39,800
code that are executed on an 
electronic. 

310
00:16:39,800 --> 00:16:42,900
Computer is just a little bit 
older than I am. 

311
00:16:43,000 --> 00:16:46,500
Alan Turing, wrote a little bit 
of Assembly Language in a 

312
00:16:46,508 --> 00:16:52,800
machine in 1946 or 1945. 
Let's just let that long ago to 

313
00:16:52,800 --> 00:16:57,300
complicate that the need for 
programmers has accelerated. 

314
00:16:57,500 --> 00:17:00,800
Did exponentially as the number 
of computers has accelerated 

315
00:17:00,800 --> 00:17:03,400
exponentially. 
So has the need for programmers.

316
00:17:03,400 --> 00:17:07,300
So the number of programmers in 
the world doubles every five 

317
00:17:07,300 --> 00:17:10,700
years. 
It's pretty Stark the number of 

318
00:17:10,700 --> 00:17:14,700
programmers in the world doubles
every five years or so, which 

319
00:17:14,700 --> 00:17:18,200
means that F the programmers in 
the world have less than five 

320
00:17:18,200 --> 00:17:21,200
years experience. 
And this will remain true as 

321
00:17:21,200 --> 00:17:24,900
long as we are doubling every 
five years and that leaves our 

322
00:17:24,900 --> 00:17:27,200
industry in a state of 
Perpetual. 

323
00:17:27,400 --> 00:17:31,900
Inexperience, there is no way 
for us to accumulate the 

324
00:17:31,900 --> 00:17:36,100
standards in the ethics because 
they're not taught in school and

325
00:17:36,100 --> 00:17:39,800
they're not taught on the job. 
There is no way to accumulate 

326
00:17:39,800 --> 00:17:42,900
those things. 
The people who could accumulate 

327
00:17:42,900 --> 00:17:46,000
them, the people with a lot of 
experience 20 or 30 years 

328
00:17:46,000 --> 00:17:50,300
experience in the field. 
Barely exist as 20 or 30 years 

329
00:17:50,300 --> 00:17:51,700
ago, door, hardly any 
programmers. 

330
00:17:51,700 --> 00:17:57,100
So it's a fundamental problem of
how do we mature an industry? 

331
00:17:57,100 --> 00:18:01,300
That is Is dominated by 22 year 
olds, we're going to have to 

332
00:18:01,300 --> 00:18:05,800
solve that problem because our 
civilization is now in a state 

333
00:18:05,800 --> 00:18:08,400
where it depends on us for its 
existence. 

334
00:18:08,700 --> 00:18:12,300
If there were not programmers, 
now our civilization would 

335
00:18:12,300 --> 00:18:15,600
collapse. 
So we have to somehow get this 

336
00:18:15,600 --> 00:18:21,800
idea of standards and ethics a 
real profession into our minds 

337
00:18:21,800 --> 00:18:24,900
into our brains. 
So that was the reason I wrote 

338
00:18:24,900 --> 00:18:26,800
the book. 
I wrote the book so that I could

339
00:18:26,800 --> 00:18:29,700
start. 
That process the standards with 

340
00:18:29,700 --> 00:18:34,300
the ethics that I talk about in 
the book are just my Concepts. 

341
00:18:34,600 --> 00:18:38,900
They may not be the end result 
other people should take that 

342
00:18:39,100 --> 00:18:43,100
and massage it and change it. 
But at least I think it's a 

343
00:18:43,100 --> 00:18:45,000
seed. 
It's some place to begin. 

344
00:18:45,900 --> 00:18:47,700
Thanks for taking this 
President. 

345
00:18:47,700 --> 00:18:50,000
Thanks also for sharing this 
history to me. 

346
00:18:50,000 --> 00:18:52,400
It's an Insight. 
So, I'm still consider young. 

347
00:18:52,400 --> 00:18:54,200
I mean, my profession. 
I didn't know. 

348
00:18:54,200 --> 00:18:57,200
I actually like 75 years ago 
when the first program. 

349
00:18:57,400 --> 00:19:00,300
Is written and then up to now 
actually the number of 

350
00:19:00,300 --> 00:19:02,700
developers keep growing and 
growing exponentially. 

351
00:19:02,900 --> 00:19:05,600
Like you said the numbers of 
experienced people are not that 

352
00:19:05,600 --> 00:19:08,700
many even if there are they are 
just maybe in some parts of the 

353
00:19:08,700 --> 00:19:10,200
world. 
They are knowledge is not 

354
00:19:10,200 --> 00:19:12,300
spread. 
It's just like so many people 

355
00:19:12,300 --> 00:19:15,500
turned out from University going
to the engineering job. 

356
00:19:15,600 --> 00:19:18,200
And that's why we are in this 
state of like what you say is 

357
00:19:18,200 --> 00:19:22,300
Perpetual in experience where we
try to learn from doing, right? 

358
00:19:22,300 --> 00:19:26,100
Not necessarily from someone who
has done it before, which brings

359
00:19:26,100 --> 00:19:27,900
us to the concept of crust. 
Worship. 

360
00:19:27,900 --> 00:19:30,900
So, your title of the book is 
clean, craftsmanship, maybe in 

361
00:19:30,900 --> 00:19:33,600
the beginning if we can clarify.
What do you mean by this 

362
00:19:33,600 --> 00:19:36,500
craftsmanship? 
The simplest way to describe 

363
00:19:36,500 --> 00:19:39,400
craftsmanship is pride of 
workmanship. 

364
00:19:39,600 --> 00:19:43,900
If you're a programmer, do you 
go home at night every day and 

365
00:19:43,900 --> 00:19:46,600
look in the mirror and say to 
yourself. 

366
00:19:47,000 --> 00:19:50,400
I did a really good job. 
I'm proud of the work. 

367
00:19:50,400 --> 00:19:54,900
I did not only did I write 
software that worked, but I 

368
00:19:54,900 --> 00:19:59,500
wrote it well. 
And I wrote In a good way, the 

369
00:19:59,500 --> 00:20:02,200
process I've followed was a good
process. 

370
00:20:02,500 --> 00:20:06,400
You go home and feel good about 
yourself and good about your 

371
00:20:06,400 --> 00:20:10,500
job, or do you have to go home 
and take a shower, and far too 

372
00:20:10,500 --> 00:20:12,100
many programmers? 
Have to go home and take a 

373
00:20:12,100 --> 00:20:16,400
shower, because they've gotten 
caught into this very dominant 

374
00:20:16,400 --> 00:20:20,300
mindset. 
That speed, overrides 

375
00:20:20,300 --> 00:20:24,900
everything, you must program 
fast and they get caught in this

376
00:20:24,900 --> 00:20:29,500
trap of thinking that Speed 
comes from rushing. 

377
00:20:30,000 --> 00:20:31,600
Now. 
The opposite is actually true. 

378
00:20:31,600 --> 00:20:35,500
If you rush, you will slow down,
but you can't feel that because 

379
00:20:35,500 --> 00:20:39,100
you feel the rushing, you feel 
the tension in your body. 

380
00:20:39,100 --> 00:20:40,800
You feel the tension in your 
mud. 

381
00:20:40,800 --> 00:20:45,400
It feels like you're going fast.
You're not actually going slow 

382
00:20:45,800 --> 00:20:50,500
and the way to go fast is to 
slow down, and take your time 

383
00:20:50,600 --> 00:20:55,400
and not make dumb mistakes and 
use a nice deliberate process 

384
00:20:55,500 --> 00:20:58,900
and keep everything clean. 
That's the way you go. 

385
00:20:58,900 --> 00:21:04,100
Fast very difficult concept for 
especially young programmers to 

386
00:21:04,100 --> 00:21:06,500
internalize. 
Once you've done it for 20 

387
00:21:06,500 --> 00:21:07,600
years. 
Then you realize. 

388
00:21:07,600 --> 00:21:09,600
Oh, yeah. 
I'm going to spend eight days. 

389
00:21:09,600 --> 00:21:12,600
Debugging this mess and some 
other guy is going to spend 

390
00:21:12,700 --> 00:21:14,400
eight days. 
Debugging the mess. 

391
00:21:14,400 --> 00:21:18,700
I made if I rush like a crazy 
person right now and maybe I 

392
00:21:18,700 --> 00:21:21,600
should take my time and do this 
in a nice, orderly way, and that

393
00:21:21,600 --> 00:21:23,300
way everybody can continue to 
go. 

394
00:21:23,300 --> 00:21:27,200
Fast craftsmanship. 
Is that mindset? 

395
00:21:27,300 --> 00:21:31,800
It, it is the mindset that you 
are working on something 

396
00:21:31,800 --> 00:21:34,800
important and you are going to 
do it. 

397
00:21:34,800 --> 00:21:40,100
Well, so I just want to add this
phrase. 

398
00:21:40,200 --> 00:21:42,800
Just now you mentioned every 
programmers, when home and then 

399
00:21:42,800 --> 00:21:44,300
take a shower, right? 
For those of you who are 

400
00:21:44,308 --> 00:21:46,700
wondering, why take a shower 
because in your book, you 

401
00:21:46,708 --> 00:21:49,800
mentioned that they feel dirty 
because of the dirty job that 

402
00:21:49,800 --> 00:21:52,800
they are doing with their code. 
So, just to give a context, why?

403
00:21:52,800 --> 00:21:54,600
Every programmer went home and 
take a shower. 

404
00:21:54,600 --> 00:21:57,200
So because of that, the software
craftsmanship. 

405
00:21:57,400 --> 00:21:58,900
That you mentioned here is very 
important. 

406
00:21:58,900 --> 00:22:02,800
I think, I myself are guilty of 
doing so much of this rushing 

407
00:22:02,800 --> 00:22:06,000
and also bad code and also 
trying to meet the deadlines. 

408
00:22:06,600 --> 00:22:09,100
So you wrote a software? 
Craftsmanship, Manifesto as 

409
00:22:09,100 --> 00:22:11,000
well. 
I think this is also very 

410
00:22:11,000 --> 00:22:13,200
important for those of you 
programmers here. 

411
00:22:13,200 --> 00:22:16,200
Who listen, maybe you should 
check it out and try to instill 

412
00:22:16,200 --> 00:22:19,700
that mindset like Uncle. 
Bob mentioned here and try to do

413
00:22:19,700 --> 00:22:21,700
your job. 
Well, so that's the message 

414
00:22:21,700 --> 00:22:24,000
here. 
The software craftsmanship, 

415
00:22:24,000 --> 00:22:27,200
Manifesto. 
I was there when it was written.

416
00:22:27,300 --> 00:22:30,300
In but I did not write it. 
It was other people who 

417
00:22:30,300 --> 00:22:34,800
collaborated to put that message
together, which I remember 

418
00:22:34,800 --> 00:22:36,300
correctly. 
There's a website. 

419
00:22:36,300 --> 00:22:38,400
So a preference if that order 
something like that. 

420
00:22:38,700 --> 00:22:40,500
I can't remember. 
I was there at the time and I 

421
00:22:40,508 --> 00:22:44,300
nodded sagely as everybody talk,
but I didn't really contribute 

422
00:22:44,300 --> 00:22:46,600
much. 
Thanks for that clarification. 

423
00:22:47,100 --> 00:22:50,000
So let's go to the first thing 
from your clean craftsmanship, 

424
00:22:50,000 --> 00:22:52,800
which is the discipline. 
So you mentioned, these are the 

425
00:22:52,800 --> 00:22:55,200
technical portion of the things 
that I think it's worth to 

426
00:22:55,200 --> 00:22:57,000
mention all of the disciplines 
here. 

427
00:22:57,300 --> 00:23:00,200
Baby, can you give an overview? 
What are the disciplines that 

428
00:23:00,200 --> 00:23:04,700
you advocate in the book? 
The book begins with a very, 

429
00:23:04,700 --> 00:23:07,400
very deep discussion on 
test-driven development. 

430
00:23:07,500 --> 00:23:11,700
I focused heavily on this 
because as we have learned over 

431
00:23:11,700 --> 00:23:16,000
the last 20 years, it is a very 
rich discipline. 

432
00:23:16,000 --> 00:23:19,900
There's a lot in test-driven 
development, it began with this 

433
00:23:20,200 --> 00:23:23,300
silly idea, that you write unit 
tests first, and then you make 

434
00:23:23,300 --> 00:23:26,000
them fast, right? 
And you get caught into a nice 

435
00:23:26,000 --> 00:23:27,100
tight little Loop for you, 
right? 

436
00:23:27,300 --> 00:23:30,200
A little test and it fails and 
you write a little code and you 

437
00:23:30,200 --> 00:23:32,400
make it past and then you're a 
little more tests. 

438
00:23:32,400 --> 00:23:35,500
And then you write a little bit 
more code over the years, we 

439
00:23:35,500 --> 00:23:39,700
started to learn how to do this 
well, and it turned out to be 

440
00:23:39,700 --> 00:23:43,500
non trivial but it turned out 
that there's a lot of twisty 

441
00:23:43,500 --> 00:23:46,100
little turns and there's a lot 
of complication. 

442
00:23:46,400 --> 00:23:48,800
Once you internalize all of 
that. 

443
00:23:48,800 --> 00:23:52,900
It makes an enormous difference 
on the way you write code. 

444
00:23:53,000 --> 00:23:56,000
I mean, it's a transformative 
kind of discipline. 

445
00:23:56,500 --> 00:24:01,600
So I A lot of time on that 
discipline, especially exploring

446
00:24:01,600 --> 00:24:04,400
the advanced concepts to my 
knowledge. 

447
00:24:04,400 --> 00:24:07,600
There are no books out there 
right now that talk about these 

448
00:24:07,600 --> 00:24:10,000
Advanced ideas and test-driven 
development. 

449
00:24:10,100 --> 00:24:13,900
So, I think that book is the 
first one to really attach those

450
00:24:13,900 --> 00:24:15,900
ideas. 
These Advanced ideas and 

451
00:24:15,900 --> 00:24:19,100
test-driven development. 
I also spend a fair bit of time 

452
00:24:19,100 --> 00:24:23,200
on the notion of refactoring. 
The two are brother and sister 

453
00:24:23,200 --> 00:24:25,500
to each other. 
You cannot refactor with that 

454
00:24:25,500 --> 00:24:28,000
test-driven development and all 
The reason you're doing 

455
00:24:28,000 --> 00:24:30,600
test-driven development is so 
that you can refactor. 

456
00:24:30,800 --> 00:24:35,000
And the goal of refactoring is 
to create a better design, 

457
00:24:35,200 --> 00:24:38,300
better code, better structured 
your code, better design code, 

458
00:24:38,300 --> 00:24:41,200
better architecture. 
So these two are deeply 

459
00:24:41,200 --> 00:24:43,900
intertwined. 
I talked a fair bit about that 

460
00:24:43,900 --> 00:24:47,500
in the book and then I talk 
about simple design. 

461
00:24:47,500 --> 00:24:52,300
The basic rules for what design 
is and what should be motivating

462
00:24:52,300 --> 00:24:56,500
design at the very lowest level 
and I draw very much from the 

463
00:24:56,500 --> 00:24:58,700
work of Ken. 
Back and run Jeffries in that 

464
00:24:58,700 --> 00:25:01,200
particular discussion. 
I don't go into design 

465
00:25:01,200 --> 00:25:03,500
principles. 
That's a higher level topic. 

466
00:25:03,600 --> 00:25:06,700
This is like, what is design at 
the very lowest level? 

467
00:25:07,000 --> 00:25:10,600
What are the simplest things 
that we can say that Define the 

468
00:25:10,600 --> 00:25:13,900
qualities of good design? 
And then I talked a little bit 

469
00:25:13,900 --> 00:25:17,300
about collaborative programming,
pair programming, starting to 

470
00:25:17,308 --> 00:25:21,700
back away from technology, so 
much and starting to get into 

471
00:25:21,700 --> 00:25:24,300
the interpersonal parts of 
programming. 

472
00:25:24,800 --> 00:25:28,600
One of the things that 
programmers are very good at is 

473
00:25:28,800 --> 00:25:33,300
deep focus. 
Deep focus generally requires 

474
00:25:33,300 --> 00:25:35,700
that, you work alone. 
Because if you're working with 

475
00:25:35,700 --> 00:25:39,200
someone else, it's very hard to 
deeply Focus because that person

476
00:25:39,200 --> 00:25:41,500
is always interrupting. 
You always getting in your way. 

477
00:25:41,800 --> 00:25:45,500
There is Need for deep focus. 
It's a good thing to be able to 

478
00:25:45,500 --> 00:25:50,800
deeply Focus, but it's also a 
good thing to sit back and with 

479
00:25:50,800 --> 00:25:55,700
someone else at your side, walk 
through the code and co-author 

480
00:25:55,700 --> 00:26:00,600
the code and Share knowledge and
build code. 

481
00:26:00,700 --> 00:26:04,100
That is a collaborative effort. 
So I've talked a fair bit about 

482
00:26:04,100 --> 00:26:06,400
that as the last of the 
disciplines. 

483
00:26:06,800 --> 00:26:10,400
If you look carefully at those 
disciplines those for that. 

484
00:26:10,400 --> 00:26:12,900
I just mentioned, test-driven 
development refactoring, simple 

485
00:26:12,900 --> 00:26:15,500
design, and collaborative 
programming. 

486
00:26:15,800 --> 00:26:20,300
Those are the inner circle of 
the circle of life diagram, that

487
00:26:20,300 --> 00:26:24,700
Ron Jeffries put out 20 years 
ago, describing a giant. 

488
00:26:25,000 --> 00:26:27,100
So agile is composed of three 
circles. 

489
00:26:27,400 --> 00:26:30,600
And in the book clean agile, I 
talked about the outer two 

490
00:26:30,600 --> 00:26:33,700
circles, the business facing 
practices and the team facing 

491
00:26:33,700 --> 00:26:36,700
practices in this book clean 
craftsmanship. 

492
00:26:36,700 --> 00:26:40,400
I talk about the inner circle of
the circle of life, all of the 

493
00:26:40,400 --> 00:26:44,300
engineering practices, the 
engineering disciplines, and 

494
00:26:44,300 --> 00:26:47,300
then one more disciplined with 
his acceptance test, right? 

495
00:26:47,300 --> 00:26:50,300
So, which are the outer part of 
the Inner Circle, so maybe if 

496
00:26:50,300 --> 00:26:54,200
you can give an overview of that
as well, the acceptance test, 

497
00:26:54,200 --> 00:26:57,100
this one is actually part of the
middle circle, the team. 

498
00:26:57,300 --> 00:26:59,400
Practices. 
But it is a deeply technical 

499
00:26:59,400 --> 00:27:05,100
discipline because it involves 
the writing of tests at a 

500
00:27:05,200 --> 00:27:08,500
business level. 
And that oddly makes it 

501
00:27:08,500 --> 00:27:11,300
technical. 
But technical in the sense that 

502
00:27:11,300 --> 00:27:16,200
the business people QA people, 
and the business analysts must 

503
00:27:16,200 --> 00:27:19,600
be able to State the 
requirements of the system in 

504
00:27:19,700 --> 00:27:23,400
formal detail, and that's what 
an acceptance test is an 

505
00:27:23,400 --> 00:27:25,500
acceptance. 
Test is the statement of a 

506
00:27:25,500 --> 00:27:29,900
requirement written for Emily in
enough detail so that there's 

507
00:27:29,900 --> 00:27:32,100
nothing left to the imagination 
of the programmer. 

508
00:27:32,100 --> 00:27:35,600
As far as the behavior of the 
system is concerned. 

509
00:27:35,900 --> 00:27:40,500
You would like the business to 
specify the behavior of the 

510
00:27:40,500 --> 00:27:42,700
program. 
You'd like the programmer to 

511
00:27:42,700 --> 00:27:46,800
implement the behavior of the 
program, with a structure that 

512
00:27:46,800 --> 00:27:50,100
can tolerate change and take it 
into the future. 

513
00:27:50,400 --> 00:27:54,000
But you want the business 
specifying that behavior and one

514
00:27:54,000 --> 00:27:57,800
of the problems we have had in 
this industry for the last 50 

515
00:27:57,800 --> 00:28:03,300
years or more is that the 
business does not want to dive 

516
00:28:03,300 --> 00:28:06,900
into enough detail to specify 
the behavior of the system. 

517
00:28:07,400 --> 00:28:10,700
So they leave all the really in 
terrible, low level detail to 

518
00:28:10,700 --> 00:28:14,900
the programmers and that's where
we get into some real problems. 

519
00:28:15,900 --> 00:28:16,900
Yeah. 
I think you've been said this 

520
00:28:16,900 --> 00:28:19,200
very insightful state of the 
industry. 

521
00:28:19,200 --> 00:28:21,300
Right? 
Where is always the programmers 

522
00:28:21,300 --> 00:28:23,200
that wrote all this 
implementation of the 

523
00:28:23,200 --> 00:28:25,900
specifications, There's No 
Business rules that actually the

524
00:28:25,900 --> 00:28:27,700
VA or the product. 
Are these days? 

525
00:28:27,900 --> 00:28:31,200
There's no be a when some of the
startups, this day is a product 

526
00:28:31,200 --> 00:28:34,300
manager or the Q&A. 
They don't actually write this 

527
00:28:34,300 --> 00:28:38,200
specifications in the formal 
details, but actually just give 

528
00:28:38,200 --> 00:28:40,600
maybe a dog of just firmly 
mention it. 

529
00:28:40,800 --> 00:28:44,000
So I think this is a very good 
distinction, so that we always 

530
00:28:44,000 --> 00:28:46,600
have to get the same 
understanding of the business 

531
00:28:46,600 --> 00:28:48,000
rules and programmers. 
Also. 

532
00:28:48,000 --> 00:28:49,500
Understand. 
What is it that they're trying 

533
00:28:49,500 --> 00:28:53,400
to implement if we can go into 
TD because most part of the book

534
00:28:53,400 --> 00:28:56,400
actually covers about these TD. 
And I think this concept 

535
00:28:56,400 --> 00:28:59,200
although it has been And for 
many years, since can back wrote

536
00:28:59,200 --> 00:29:02,700
it a long time ago, but still, I
think many people may not be 

537
00:29:02,700 --> 00:29:05,400
able to practice. 
It fully including myself, 

538
00:29:05,400 --> 00:29:07,200
right? 
It is a hard discipline like, 

539
00:29:07,200 --> 00:29:08,500
what you mentioned in the 
beginning. 

540
00:29:08,800 --> 00:29:11,900
So, maybe if you can give us 
some tips or some guidance or 

541
00:29:11,900 --> 00:29:15,300
philosophy, how we should do 
this DVD including the laws that

542
00:29:15,300 --> 00:29:18,700
you have 40 d? 
So a test driven development. 

543
00:29:18,900 --> 00:29:22,100
I describe it using three laws 
or three rules. 

544
00:29:22,600 --> 00:29:25,300
The first rule is that you're 
not allowed to write any 

545
00:29:25,300 --> 00:29:28,300
production code. 
Until you have, First written a 

546
00:29:28,300 --> 00:29:32,300
test that fails and it must fail
because of the code. 

547
00:29:32,300 --> 00:29:35,400
You have not written yet. 
You write a test that fails. 

548
00:29:35,400 --> 00:29:38,500
First this the second law. 
You are not allowed to write 

549
00:29:38,500 --> 00:29:41,300
more of a test than is 
sufficient to fail. 

550
00:29:41,400 --> 00:29:43,200
As soon as it fails. 
You have to stop writing with 

551
00:29:43,200 --> 00:29:45,600
it. 
And I like to say that when it 

552
00:29:45,600 --> 00:29:48,500
fails to compile, you have to 
stop writing the test. 

553
00:29:48,700 --> 00:29:51,600
So now you're stuck, right? 
Because you have to write a 

554
00:29:51,600 --> 00:29:55,700
test, but you cannot write more 
then we'll fail to compile, and 

555
00:29:55,700 --> 00:29:58,100
they will fail the compiled 
within the Couple of lines, 

556
00:29:58,300 --> 00:30:01,300
especially if you're using a 
statically typed language, like 

557
00:30:01,300 --> 00:30:04,700
C, sharp or Java, or C++, or 
something like that. 

558
00:30:05,300 --> 00:30:08,800
The third law says, you are not 
allowed to write more 

559
00:30:08,800 --> 00:30:11,700
production, code than is 
sufficient that pass the 

560
00:30:11,700 --> 00:30:15,300
currently failing test. 
And this locks you into a cycle.

561
00:30:15,300 --> 00:30:18,600
That is 30 seconds long. 
So you write a line of pesto. 

562
00:30:18,600 --> 00:30:21,300
No, it doesn't while you write a
line in production code. 

563
00:30:21,300 --> 00:30:24,600
Oh my God, that made, well, you 
go back test, your write another

564
00:30:24,600 --> 00:30:27,000
line of Tesco doesn't compile 
it. 

565
00:30:27,100 --> 00:30:30,300
Write another line of production
code that makes a compile your 

566
00:30:30,300 --> 00:30:34,100
into the light of test, it 
compiles, but it fails and you 

567
00:30:34,108 --> 00:30:36,700
write another line of production
code that makes it past and 

568
00:30:36,700 --> 00:30:39,700
you're stuck in this really 
tight Loop. 

569
00:30:40,100 --> 00:30:44,200
This is the first thing that 
programmers rebel against if 

570
00:30:44,200 --> 00:30:46,600
they are looking at test-driven 
development if they're 

571
00:30:46,800 --> 00:30:50,600
evaluating it as a possible 
discipline, they look at that 

572
00:30:50,600 --> 00:30:53,400
really tight little Loop and 
they think, well, that's nuts. 

573
00:30:53,600 --> 00:30:56,700
That's stupid. 
I'd never be able to write an if

574
00:30:56,700 --> 00:30:58,700
statement. 
Without interrupting myself. 

575
00:30:58,700 --> 00:31:01,500
I'd ever be able to write a 
while loop without interrupting 

576
00:31:01,500 --> 00:31:03,000
myself. 
I'm not going to do that. 

577
00:31:05,100 --> 00:31:08,600
That it's a difficult first step
to get across. 

578
00:31:09,200 --> 00:31:11,700
I first saw this in the year 
2000. 

579
00:31:12,100 --> 00:31:14,100
I had gone to visit. 
Kent Beck. 

580
00:31:14,300 --> 00:31:17,400
I really enjoyed the extreme 
programming stuff that he was 

581
00:31:17,400 --> 00:31:19,900
doing. 
I went out to visit him and talk

582
00:31:19,900 --> 00:31:23,400
to him about it, but I didn't 
care for this old test first 

583
00:31:23,400 --> 00:31:24,800
thing. 
I thought that was stupid. 

584
00:31:25,100 --> 00:31:29,200
And then he and I sat down and 
we wrote a little Java applet. 

585
00:31:29,400 --> 00:31:33,300
Took us about two hours, just a 
dumb little Java applet that 

586
00:31:33,300 --> 00:31:36,900
simulated the fairy. 
Mother's magic one with little 

587
00:31:36,900 --> 00:31:39,900
sparkles coming off. 
It was a pair programming, 

588
00:31:39,900 --> 00:31:41,900
exercise. 
He and I sat together writing 

589
00:31:41,900 --> 00:31:46,300
this in Java, and he showed me 
this discipline and I've never 

590
00:31:46,300 --> 00:31:49,100
seen anything like this. 
I'd already been programming for

591
00:31:49,100 --> 00:31:51,800
like, 30 years. 
I did not think someone was 

592
00:31:51,800 --> 00:31:54,700
going to show me something 
radically different, but here, 

593
00:31:54,700 --> 00:31:58,100
it was right before my eyes. 
This was different. 

594
00:31:58,500 --> 00:32:01,900
And it was different in a way 
that it had a huge effect. 

595
00:32:01,900 --> 00:32:06,800
Because for two hours, we wrote 
that That coat we never debugged

596
00:32:06,800 --> 00:32:09,600
anything. 
There was no debugging, we never

597
00:32:09,600 --> 00:32:12,100
went into a debugger. 
You never put print statements 

598
00:32:12,100 --> 00:32:15,400
in, we never did anything. 
We just went from tiny little 

599
00:32:15,400 --> 00:32:18,000
test to tiny little test. 
The tiny little dust until the 

600
00:32:18,008 --> 00:32:19,400
whole thing worked on the 
screen. 

601
00:32:19,800 --> 00:32:23,300
I walked away from that 
experience with a very different

602
00:32:23,300 --> 00:32:26,400
mindset. 
I thought, okay, this needs to 

603
00:32:26,400 --> 00:32:28,900
be looked at. 
I need to get good at this so 

604
00:32:28,900 --> 00:32:32,700
that I can properly evaluate. 
Well, okay, it took me 20 years 

605
00:32:32,700 --> 00:32:36,400
to get good at but turns out to 
put A lot more complicated than 

606
00:32:36,400 --> 00:32:39,400
I thought. 
Now, we have enough information 

607
00:32:39,400 --> 00:32:42,800
and enough knowledge so that 
other people can get started 

608
00:32:42,800 --> 00:32:45,400
faster and they don't have to 
make the mistakes that I made 

609
00:32:45,400 --> 00:32:47,900
and that can't made and that 
everybody made in the early 

610
00:32:47,900 --> 00:32:50,200
days. 
We made a ton of mistakes in the

611
00:32:50,200 --> 00:32:54,900
early days, my advice for people
who want to get started with 

612
00:32:54,900 --> 00:32:57,900
test-driven development is not 
to do it at work. 

613
00:32:58,000 --> 00:33:00,200
Don't do it at work because 
there's too much at stake. 

614
00:33:00,700 --> 00:33:03,600
Do it at home because everybody 
writes coded home of your 

615
00:33:03,600 --> 00:33:05,600
programmer. 
You've Got your own little pet 

616
00:33:05,600 --> 00:33:09,100
projects that you do at home. 
Everybody does do it at home. 

617
00:33:09,100 --> 00:33:10,600
Do it at a hackathon. 
Don't know. 

618
00:33:10,600 --> 00:33:13,100
A hackathon on a Saturday. 
Do it there. 

619
00:33:13,100 --> 00:33:17,400
Do it at lunchtime. 
Do it in some scenario where 

620
00:33:17,400 --> 00:33:20,300
there's nothing at stake. 
Your nothing big at stake and 

621
00:33:20,300 --> 00:33:22,500
get good at it. 
Getting good at it is going to 

622
00:33:22,500 --> 00:33:26,000
take you. 
I'm months, but once you're good

623
00:33:26,000 --> 00:33:29,800
at it, then you can bring it to 
work and it will pay on it is 

624
00:33:29,800 --> 00:33:33,300
the way I write code nowadays. 
Now, do I do customer 

625
00:33:33,300 --> 00:33:36,100
development for every The line 
of code I write. 

626
00:33:36,300 --> 00:33:37,500
Nope. 
I do not. 

627
00:33:37,600 --> 00:33:41,200
There's whole bunches of code 
that simply do not do well with 

628
00:33:41,200 --> 00:33:45,500
test-driven development, very 
specifically, gooey code code at

629
00:33:45,500 --> 00:33:48,700
the graphical user interface. 
All you can do there is kind of 

630
00:33:48,700 --> 00:33:50,900
get it on the screen and look at
it and get more of it on the 

631
00:33:50,900 --> 00:33:52,500
screen and look at it and 
fiddled with it. 

632
00:33:52,500 --> 00:33:56,200
You're still in the same loop. 
It's still a real fast loop, 

633
00:33:56,300 --> 00:33:58,200
right? 
But now you're not writing test.

634
00:33:58,200 --> 00:34:01,400
Now, you're looking at your eyes
using your eyes to judge it. 

635
00:34:01,700 --> 00:34:06,800
You worked very hard to pull all
the Agents out of the gooey so 

636
00:34:06,800 --> 00:34:09,600
that you can write the 
intelligent code with tests. 

637
00:34:09,900 --> 00:34:13,199
And then the last little bit all
that horrible CSS stuff from all

638
00:34:13,199 --> 00:34:15,800
the formatting and go. 
You have to do that by. 

639
00:34:16,300 --> 00:34:19,100
That's the way I approach 
test-driven development. 

640
00:34:19,800 --> 00:34:21,000
Wow. 
Thanks for sharing that 

641
00:34:21,000 --> 00:34:23,000
insightful story. 
So I didn't know that you 

642
00:34:23,000 --> 00:34:25,500
actually paired with Ken back 
and figure out about this 

643
00:34:25,500 --> 00:34:27,900
technique tdd. 
And that's what we learn from 

644
00:34:27,900 --> 00:34:30,500
you as well in the clean code in
CODIS videos. 

645
00:34:30,699 --> 00:34:32,000
So thanks for sharing that 
story. 

646
00:34:32,300 --> 00:34:35,100
So you mentioned about these 
three laws, which I think People

647
00:34:35,100 --> 00:34:37,500
associate a lot with this red 
green thing, right? 

648
00:34:37,600 --> 00:34:41,000
You add the test per seat fail 
and you add the production code 

649
00:34:41,000 --> 00:34:43,100
make it run. 
But then there's this third 

650
00:34:43,100 --> 00:34:46,800
piece, which is refactor and you
ensure that tdd always work 

651
00:34:46,800 --> 00:34:49,000
hand-in-hand with your Factor. 
They're like brothers and 

652
00:34:49,000 --> 00:34:51,500
sisters, their work really well 
together. 

653
00:34:51,600 --> 00:34:54,600
Maybe he can tell us more about 
refactoring, why we should do 

654
00:34:54,600 --> 00:34:56,699
it. 
What are some of the advice from

655
00:34:56,699 --> 00:34:58,300
you as well? 
How to do refactoring. 

656
00:34:58,300 --> 00:35:03,100
Well, so refactoring is the 
practice of changing the 

657
00:35:03,100 --> 00:35:06,000
structure of code without 
changing its Behavior. 

658
00:35:06,400 --> 00:35:08,400
You cannot refactor in a new 
feature. 

659
00:35:08,400 --> 00:35:12,200
You cannot we factor out a bug, 
the behavior of the system 

660
00:35:12,200 --> 00:35:14,500
remains constant. 
While you are adjusting the 

661
00:35:14,500 --> 00:35:18,000
structure Kickback, said 
something a very long time ago. 

662
00:35:18,000 --> 00:35:23,600
He said, first, make it work, 
then make it right, many many 

663
00:35:23,600 --> 00:35:27,300
programmers, take the first bit 
of that advice and ignore the 

664
00:35:27,300 --> 00:35:30,600
second part of that advice. 
So they get it to work the way 

665
00:35:30,600 --> 00:35:33,100
programmers behave, you know, 
programmers will work hard. 

666
00:35:33,100 --> 00:35:34,600
They'll try to get something to 
work. 

667
00:35:34,800 --> 00:35:37,400
Fiddle with it's not working. 
Try something else. 

668
00:35:37,400 --> 00:35:40,000
It's like working for. 
Oh my god, it worked. 

669
00:35:40,100 --> 00:35:43,100
Oh, okay. 
Nobody breathe, kept it in, 

670
00:35:43,400 --> 00:35:45,800
check it in. 
That's the wrong approach. 

671
00:35:46,100 --> 00:35:49,500
What you want to do is once 
you've gotten something to work,

672
00:35:49,800 --> 00:35:53,800
you've made a mess in there. 
Human brains are not that good. 

673
00:35:53,900 --> 00:35:57,400
We cannot make something work 
and make it clean 

674
00:35:57,400 --> 00:36:00,800
simultaneously. 
Too Many Factors going on so we 

675
00:36:00,800 --> 00:36:04,600
can make it work, but then you 
have to change stop and think, 

676
00:36:04,600 --> 00:36:07,700
oh, Okay. 
Now I need to make it right and 

677
00:36:07,700 --> 00:36:10,600
the making of it right? 
Is this idea of refactoring 

678
00:36:10,700 --> 00:36:14,700
going to keep the behavior while
you change the structure. 

679
00:36:15,400 --> 00:36:19,400
We talk about this as a cycle. 
We talk about the name of the 

680
00:36:19,400 --> 00:36:22,100
cycle. 
Is the Red Green refactor Cycle,

681
00:36:22,200 --> 00:36:26,100
which tries to take refactoring 
and mix it in with test-driven 

682
00:36:26,100 --> 00:36:28,300
development. 
So, test-driven development has 

683
00:36:28,300 --> 00:36:30,700
this very tiny little psycho. 
Write a test. 

684
00:36:30,700 --> 00:36:32,400
Make it pass, write a test. 
Make it fast, right? 

685
00:36:32,400 --> 00:36:34,600
It says they could pass and then
we try. 

686
00:36:34,800 --> 00:36:38,000
Tossing the refactoring on top 
of that by saying, okay, write a

687
00:36:38,008 --> 00:36:41,500
test, make it past, clean it up.
Write a test, make it as clean 

688
00:36:41,500 --> 00:36:44,100
it up. 
Good advice, doesn't always 

689
00:36:44,100 --> 00:36:44,800
work. 
That way. 

690
00:36:45,500 --> 00:36:48,100
What happens to me? 
Anyway, is that I'll go around 

691
00:36:48,100 --> 00:36:53,100
the test driven development 
cycle. 50 60, 70 times around 

692
00:36:53,100 --> 00:36:55,700
that cycle, test, test, test, 
test test test as best. 

693
00:36:55,900 --> 00:36:59,400
I will get something relatively 
significant working. 

694
00:36:59,400 --> 00:37:03,200
And by that, I mean 50 lines of 
got 50, 60 lines of code, 

695
00:37:03,200 --> 00:37:05,100
something like that. 
And that's That's what I 

696
00:37:05,100 --> 00:37:06,300
stopped. 
And I go. 

697
00:37:06,300 --> 00:37:09,500
Okay. 
This is a mess and it is, it's 

698
00:37:09,500 --> 00:37:11,600
almost always a mess. 
I've done it wrong. 

699
00:37:11,600 --> 00:37:14,700
I put the wrong names in. 
I've put the code in the wrong 

700
00:37:14,700 --> 00:37:16,700
place. 
I've got a set of functions, 

701
00:37:16,700 --> 00:37:20,100
I've written, but the functions 
don't partition things. 

702
00:37:20,100 --> 00:37:23,700
Well, and then I stop, and I 
say, okay, I need to move this 

703
00:37:23,700 --> 00:37:25,400
over here and move that over 
there. 

704
00:37:25,400 --> 00:37:28,500
This name has to change. 
Oh my goodness, this functions, 

705
00:37:28,500 --> 00:37:31,200
too big. 
I need to split it in half and I

706
00:37:31,200 --> 00:37:34,400
spend a relatively significant 
amount of time. 

707
00:37:34,800 --> 00:37:39,100
Structuring the code while 
keeping the behavior stable. 

708
00:37:39,400 --> 00:37:43,600
How do I know that the behavior 
is kept stable, the tests 

709
00:37:43,600 --> 00:37:46,300
continue to pass without those 
tests. 

710
00:37:46,600 --> 00:37:50,600
I would be lost because every 
time I change the structure, I 

711
00:37:50,600 --> 00:37:54,900
would be fearful that I had 
changed the behavior because I 

712
00:37:54,908 --> 00:37:57,000
have the tests. 
I know the behavior hasn't 

713
00:37:57,000 --> 00:38:00,000
changed and I can safely improve
the structure. 

714
00:38:00,700 --> 00:38:02,100
Wow. 
Thanks for sharing again, your 

715
00:38:02,100 --> 00:38:04,600
insides, how you normally do 
this that he D PSI. 

716
00:38:04,700 --> 00:38:07,900
Cycle Plus refactoring. 
So for people who listen to 

717
00:38:07,900 --> 00:38:10,300
Uncle Bob, maybe you can also 
follow his style. 

718
00:38:10,700 --> 00:38:13,000
One thing that you mentioned 
about programmers these days, 

719
00:38:13,000 --> 00:38:15,100
right? 
They just make it work and a 

720
00:38:15,100 --> 00:38:17,400
stop after that. 
So I think there's one thing 

721
00:38:17,400 --> 00:38:18,800
that you mentioned in the book, 
right? 

722
00:38:18,800 --> 00:38:21,800
So you should not actually ask 
permission to refactor because 

723
00:38:22,000 --> 00:38:25,200
most of the times we make it 
work and then we stopped and 

724
00:38:25,200 --> 00:38:27,600
then maybe one week later, or 
maybe one month later. 

725
00:38:27,600 --> 00:38:29,200
You tell the business 
stakeholders. 

726
00:38:29,300 --> 00:38:31,500
We need some time to actually 
refactor the code. 

727
00:38:31,500 --> 00:38:34,600
So that is actually a wrong 
thing to do and that is probably

728
00:38:34,800 --> 00:38:37,300
Not part of the craftsmanship 
that you advocate here. 

729
00:38:37,800 --> 00:38:38,700
But us. 
Correct. 

730
00:38:38,800 --> 00:38:41,500
You do not want refactoring to 
be on the schedule. 

731
00:38:41,600 --> 00:38:44,900
You don't want to have a bar on 
the schedule seeing this is when

732
00:38:44,900 --> 00:38:48,100
we will refactor and you never 
want to go to managers and say, 

733
00:38:48,100 --> 00:38:49,200
is it? 
Okay, sir? 

734
00:38:49,200 --> 00:38:52,800
If we refactor now, that's kind 
of like going to the bathroom 

735
00:38:52,800 --> 00:38:55,400
and then sticking your head out 
and asking the manager of it's 

736
00:38:55,400 --> 00:38:57,000
okay. 
If you wash your hands, don't 

737
00:38:57,000 --> 00:39:00,000
have time to watch my hands, or 
should I just go back and cook 

738
00:39:00,000 --> 00:39:03,900
them? 
So, one thing that is always 

739
00:39:03,900 --> 00:39:07,200
associated with tdd or unit test
is about code coverage. 

740
00:39:07,400 --> 00:39:10,200
So maybe if you can give some 
advice here, what will be the 

741
00:39:10,200 --> 00:39:13,000
good code coverage that we 
should aim for so that people 

742
00:39:13,000 --> 00:39:15,800
are not misled. 
There are a number of very good 

743
00:39:15,800 --> 00:39:20,100
tools that will measure code 
coverage code coverage is the 

744
00:39:20,100 --> 00:39:24,900
measurement of the lines of code
and the branches of code that 

745
00:39:24,900 --> 00:39:28,900
are executed in the context of a
suite of tests. 

746
00:39:29,300 --> 00:39:33,400
So you run your Suite of tests. 
And the tool will show you every

747
00:39:33,400 --> 00:39:37,200
line of code that was executed 
and every branch that that code 

748
00:39:37,200 --> 00:39:41,000
took and that's very useful. 
And if you are writing tests and

749
00:39:41,000 --> 00:39:44,700
you're writing code to go along 
with it is good to know how much

750
00:39:44,700 --> 00:39:47,800
of your code is actually being 
executed by those tests. 

751
00:39:47,800 --> 00:39:51,900
So that's what code coverage is.
You could break it up into line 

752
00:39:51,900 --> 00:39:55,900
coverage and decision coverage. 
There's another kind of coverage

753
00:39:55,900 --> 00:39:58,600
which is path coverage, but 
that's when you explode out 

754
00:39:58,600 --> 00:40:01,600
every possible path, and it's 
not very Be practical. 

755
00:40:01,900 --> 00:40:06,000
So I usually just do the first 
two wind coverage and decision. 

756
00:40:07,000 --> 00:40:09,400
How much of the code should be 
covered. 

757
00:40:09,900 --> 00:40:13,000
Is there some number? 
And most of the tools will give 

758
00:40:13,000 --> 00:40:16,100
you a number, they will 0 92 
percent of your coming was 

759
00:40:16,100 --> 00:40:18,600
executed when you ran the test. 
Okay. 

760
00:40:18,600 --> 00:40:21,400
So what should that number be? 
And a lot of people will say, 

761
00:40:21,400 --> 00:40:25,200
well, it should be at least 80 
percent and reject that I think 

762
00:40:25,200 --> 00:40:27,100
will know. 
I mean, the number should be 

763
00:40:27,100 --> 00:40:30,800
100%, or is close to 100% as you
can get it. 

764
00:40:30,900 --> 00:40:34,200
Maybe you can't get all the way 
to 100% because there's some 

765
00:40:34,200 --> 00:40:36,600
lines of code. 
You can't cover for some reason 

766
00:40:37,000 --> 00:40:40,700
but the number should be very 
high in the high 90s and you 

767
00:40:40,700 --> 00:40:43,100
should take every opportunity to
push it. 

768
00:40:43,200 --> 00:40:48,100
Even higher code. 
Coverage is a technical thing. 

769
00:40:48,300 --> 00:40:52,400
It is not a management metric. 
It is not something you want to 

770
00:40:52,408 --> 00:40:57,000
put on the wall to show your 
customers, or you are managers 

771
00:40:57,000 --> 00:41:00,700
because they don't understand 
what it is code. 

772
00:41:00,900 --> 00:41:05,200
Coverage does not mean that the 
code Works, code coverage means 

773
00:41:05,200 --> 00:41:09,500
that the code was executed. 
That's all if you had a bunch of

774
00:41:09,500 --> 00:41:13,300
tests and you took all the 
assertions out of the tests. 

775
00:41:13,600 --> 00:41:16,200
It would still show you the same
code coverage. 

776
00:41:16,600 --> 00:41:19,800
So one of the problems that 
we've had with code coverage is 

777
00:41:19,800 --> 00:41:24,100
that managers learn about non 
technical managers for managers 

778
00:41:24,100 --> 00:41:27,500
who used to be programmers, but 
then became managers and lost 

779
00:41:27,500 --> 00:41:30,000
all their technical skills 
because that's instantly what 

780
00:41:30,000 --> 00:41:33,400
happens as soon as you Manager, 
so when happen is that those 

781
00:41:33,400 --> 00:41:37,700
managers will say, well, we 
should measure this and we 

782
00:41:37,700 --> 00:41:43,600
should fail the bill if you 
don't achieve 80% So all of a 

783
00:41:43,607 --> 00:41:46,000
sudden you've got this 
artificial metric in there, 

784
00:41:46,200 --> 00:41:48,100
you've got to achieve 80% code 
covers. 

785
00:41:48,100 --> 00:41:50,800
Otherwise the build fails. 
Well, you can't have them. 

786
00:41:50,800 --> 00:41:54,300
Build fail for god sakes. 
You can't ship, you can't deploy

787
00:41:54,300 --> 00:41:57,700
of the build fails. 
Therefore the build must pass 

788
00:41:58,000 --> 00:41:59,500
and the way you make the bill 
passes. 

789
00:41:59,500 --> 00:42:01,600
You take all the assertions out 
of your tests. 

790
00:42:02,100 --> 00:42:03,300
Yeah. 
I've been there. 

791
00:42:03,400 --> 00:42:07,200
I've seen that happen. 
It is a bad idea to make the 

792
00:42:07,200 --> 00:42:10,100
code coverage number a 
management metric. 

793
00:42:10,300 --> 00:42:12,500
It is a very useful tool for 
program. 

794
00:42:12,900 --> 00:42:15,500
It's programmers, can look at it
and understand what it means. 

795
00:42:16,200 --> 00:42:19,200
Very bad idea to export that 
outside of the programmer 

796
00:42:19,200 --> 00:42:22,600
Community into the management. 
So for those of you who listen, 

797
00:42:22,700 --> 00:42:26,900
try to aim as high as possible, 
100%, I know it's really 

798
00:42:26,900 --> 00:42:29,900
difficult sometimes to achieve 
100% But at least you try your 

799
00:42:29,900 --> 00:42:32,800
best. 
Aim at the higher 90, the three 

800
00:42:32,800 --> 00:42:35,300
other disciplines, I think 
people should refer to the book.

801
00:42:35,700 --> 00:42:38,400
So let's move to the two other 
things, which is the first one 

802
00:42:38,400 --> 00:42:40,700
is standards, right? 
So this is where we go to the 

803
00:42:40,700 --> 00:42:43,600
non-technical staff. 
We will probably cover some of 

804
00:42:43,600 --> 00:42:46,600
them which I find interesting. 
And the first one that stood out

805
00:42:46,700 --> 00:42:49,600
actually, is this phrase called 
we will never ship shit. 

806
00:42:50,000 --> 00:42:53,200
Maybe if you can tell us a 
little bit more about why you 

807
00:42:53,200 --> 00:42:57,600
have this in the chapter, the 
idea behind these standards came

808
00:42:57,600 --> 00:43:03,000
about because I was looking for 
a way for managers to encourage,

809
00:43:03,000 --> 00:43:05,800
programmers to use good 
disciplines. 

810
00:43:06,300 --> 00:43:08,500
One of the things you cannot do 
as a manager. 

811
00:43:08,500 --> 00:43:12,300
You cannot tell programmers, you
will parent program, you will 

812
00:43:12,300 --> 00:43:13,600
do. 
Test-driven development. 

813
00:43:13,600 --> 00:43:15,500
You will RE Factor that doesn't 
work. 

814
00:43:15,700 --> 00:43:18,500
You can't have this stuff being 
shoved down on you from the top 

815
00:43:18,600 --> 00:43:20,300
because the programmers are 
going to rebel. 

816
00:43:20,600 --> 00:43:22,600
I don't have to do Castro 
development. 

817
00:43:22,600 --> 00:43:24,700
Screw. 
You having been there? 

818
00:43:24,800 --> 00:43:27,500
That's exactly. 
What'll happen managers need 

819
00:43:27,500 --> 00:43:30,000
some way to encourage those 
discipline. 

820
00:43:30,300 --> 00:43:33,600
And what occurred to me one day.
Is that what would the captain 

821
00:43:33,600 --> 00:43:38,000
of a ship? 
Now here you got a guy who the 

822
00:43:38,000 --> 00:43:41,900
wives of the croup depend on the
crew behaving. 

823
00:43:41,900 --> 00:43:45,800
Well, but the crew are just a 
bunch of guys. 

824
00:43:46,000 --> 00:43:48,800
And if the captain is walking 
around saying you are not 

825
00:43:48,800 --> 00:43:52,100
swabbing the deck properly. 
I want you to use the 

826
00:43:52,100 --> 00:43:55,100
three-stroke method for swabbing
the deck Muppet to swim. 

827
00:43:55,400 --> 00:43:58,500
That's not going to work. 
Captain can't be at that level 

828
00:43:58,500 --> 00:44:05,200
of detail, but the captain can 
say I expect the deck to doesn't

829
00:44:05,200 --> 00:44:07,000
it. 
Say how you say? 

830
00:44:07,000 --> 00:44:12,400
I expect the deck to be clean. 
So I started listing standards 

831
00:44:12,400 --> 00:44:16,600
that could be expectations, that
managers communicate to 

832
00:44:16,600 --> 00:44:19,100
programmers. 
And the first one is we will 

833
00:44:19,100 --> 00:44:22,300
lock ship shit. 
The deck will be clean. 

834
00:44:22,600 --> 00:44:25,100
We will not ship shit. 
Now. 

835
00:44:25,600 --> 00:44:29,600
This is something that most 
managers do not say to the 

836
00:44:29,600 --> 00:44:32,100
programmers. 
The message coming from 

837
00:44:32,100 --> 00:44:36,400
management. 
Most often is we We'll go fast 

838
00:44:36,600 --> 00:44:41,300
and I don't care if it's shit. 
The implication is that they 

839
00:44:41,300 --> 00:44:43,400
don't care if it's shit now, 
they do care. 

840
00:44:43,400 --> 00:44:47,000
All managers care. 
Everybody cares, that the 

841
00:44:47,000 --> 00:44:50,700
software be would manage. 
MERS may not understand what 

842
00:44:50,700 --> 00:44:53,400
good software is, but they still
want it to be good. 

843
00:44:53,900 --> 00:44:56,700
All managers have the 
expectation that the software 

844
00:44:56,700 --> 00:45:00,300
will behave properly and that it
can be modified properly and it 

845
00:45:00,300 --> 00:45:04,100
can be maintained Diesel and it 
can change its requirements. 

846
00:45:04,100 --> 00:45:08,300
Kiesel those Unscented 
expectations that need to be 

847
00:45:08,300 --> 00:45:11,100
set. 
So that's the reason I started 

848
00:45:11,100 --> 00:45:15,300
the standards part of the book 
with that particular standard 

849
00:45:15,900 --> 00:45:20,600
bad code is below standard. 
We are not going to tolerate 

850
00:45:20,600 --> 00:45:27,300
bad, couple what a concept 
that's one thing also that the 

851
00:45:27,300 --> 00:45:31,100
business stakeholders always ask
when will we be able to release 

852
00:45:31,100 --> 00:45:33,100
it? 
So that goes hand-in-hand with 

853
00:45:33,100 --> 00:45:35,100
go fast as well, but they never 
said. 

854
00:45:35,300 --> 00:45:37,900
Don't take shortcuts. 
Don't do bad job, but they 

855
00:45:37,900 --> 00:45:40,400
always emphasize. 
When are we going to realize it 

856
00:45:40,400 --> 00:45:43,600
or do it as soon as possible? 
So thanks for reminding the 

857
00:45:43,600 --> 00:45:46,000
standard. 
There's something that happens 

858
00:45:46,000 --> 00:45:49,200
in that communication managers 
have to go fast. 

859
00:45:49,400 --> 00:45:51,600
There's got to be speed because 
it's month. 

860
00:45:52,100 --> 00:45:55,300
So the managers are going to 
focus on speed and that's what 

861
00:45:55,300 --> 00:45:57,700
you should expect. 
All programmers, should expect 

862
00:45:57,700 --> 00:45:59,400
that. 
What happens? 

863
00:45:59,400 --> 00:46:00,000
Then? 
Is that? 

864
00:46:00,000 --> 00:46:01,800
There's a funny communication 
that goes on. 

865
00:46:02,300 --> 00:46:04,500
There's in the programmers. 
They feel like they've got to go

866
00:46:04,500 --> 00:46:07,300
faster. 
And so they start asking 

867
00:46:07,300 --> 00:46:09,600
questions of the manager. 
Well, is it okay? 

868
00:46:09,600 --> 00:46:12,900
If I refactor because I could 
probably go faster if I don't 

869
00:46:12,900 --> 00:46:15,500
refactor, is it okay? 
If I don't write tests? 

870
00:46:15,500 --> 00:46:18,800
Because with probably go faster,
if we didn't write test. 

871
00:46:19,000 --> 00:46:22,000
These are not valid questions to
ask. 

872
00:46:22,400 --> 00:46:25,300
This is like the doctor asking. 
The patient. 

873
00:46:25,400 --> 00:46:28,700
Should I now cut, you should I 
shoot you this? 

874
00:46:29,100 --> 00:46:31,600
Should I now take out this blood
clot? 

875
00:46:31,900 --> 00:46:35,200
The doctor does not ask the 
patient in a step by step way. 

876
00:46:35,200 --> 00:46:38,200
What? 
To do programmers, should have 

877
00:46:38,200 --> 00:46:40,800
in their minds, what they are 
going to do. 

878
00:46:41,300 --> 00:46:44,100
Yes, managers are going to say 
we need this by April. 

879
00:46:44,300 --> 00:46:48,700
We need this by April, and then 
a negotiation of what will be 

880
00:46:48,700 --> 00:46:52,400
delivered by April. 
Not how it will be delivered by 

881
00:46:52,400 --> 00:46:55,100
April. 
How is something that's the 

882
00:46:55,100 --> 00:46:57,600
programmers job, not the 
manager's job. 

883
00:46:58,200 --> 00:47:01,500
What can be a negotiation? 
How many features will be 

884
00:47:01,500 --> 00:47:05,200
available by a? 
I wish all the programmers who 

885
00:47:05,600 --> 00:47:08,000
Into this by tomorrow, you 
should not be asking your 

886
00:47:08,000 --> 00:47:11,700
managers or your stakeholders. 
Shall I do refactoring or shall 

887
00:47:11,700 --> 00:47:13,600
I write tests? 
So it should be part of your 

888
00:47:13,600 --> 00:47:14,900
standard actually. 
Yes. 

889
00:47:14,900 --> 00:47:17,100
Absolutely. 
The second standard that you 

890
00:47:17,100 --> 00:47:19,600
mentioned, I think, which is 
worth to discuss about as well. 

891
00:47:19,600 --> 00:47:22,300
Is this thing called? 
We will always be ready. 

892
00:47:22,700 --> 00:47:24,600
So maybe can give some lights 
on. 

893
00:47:24,607 --> 00:47:26,600
Why do you think this is a good 
standard to have? 

894
00:47:26,600 --> 00:47:32,500
So the discipline behind this is
the agile discipline, the 

895
00:47:32,500 --> 00:47:36,300
overall edge of discipline, 
which says that, You're going to

896
00:47:36,300 --> 00:47:39,500
be ready every week, or every 
two weeks, whatever your 

897
00:47:39,500 --> 00:47:44,000
iteration size, it the in most 
agile, methods, nowadays. 

898
00:47:44,000 --> 00:47:47,600
The iteration size is 26. 
I prefer one week. 

899
00:47:47,600 --> 00:47:50,200
I think it would be better if we
did it one week cycle. 

900
00:47:50,500 --> 00:47:54,500
But okay, fine. 
Every two weeks, say we are 

901
00:47:54,500 --> 00:47:56,000
ready. 
And what are we ready to do? 

902
00:47:56,100 --> 00:47:59,600
We are ready to deploy from a 
technical point of view. 

903
00:47:59,700 --> 00:48:03,100
We are ready to deploy the 
business may not be ready to 

904
00:48:03,100 --> 00:48:04,900
deploy. 
There may not be enough 

905
00:48:04,900 --> 00:48:07,200
features. 
Or maybe we've got log out 

906
00:48:07,200 --> 00:48:09,200
working, but we haven't got 
login one. 

907
00:48:09,200 --> 00:48:12,900
But from the point of view of 
the programmers, if the business

908
00:48:12,900 --> 00:48:16,200
wants to ship it with just log 
out, we're perfectly happy to do

909
00:48:16,200 --> 00:48:19,700
that because we know it works. 
It's tested it's documented. 

910
00:48:19,700 --> 00:48:25,500
It's ready to deploy every time 
around the agile Loop. 

911
00:48:25,500 --> 00:48:27,800
Whatever that loop size is two 
weeks. 

912
00:48:27,800 --> 00:48:28,900
One week, whatever. 
It is. 

913
00:48:28,900 --> 00:48:30,900
Every time around that agile 
Loop. 

914
00:48:30,900 --> 00:48:35,200
We are ready to deploy. 
I worked with a group and this 

915
00:48:35,200 --> 00:48:40,400
was in the Your 2000 these guys,
created a word processor for the

916
00:48:40,500 --> 00:48:43,500
legal Community, lawyers need 
their own kind of weird process.

917
00:48:43,800 --> 00:48:46,100
They can't use Microsoft Word. 
They've got to have their own 

918
00:48:46,100 --> 00:48:49,300
kind of word processor. 
So this company made the legal 

919
00:48:49,300 --> 00:48:51,700
word processor and we taught 
them. 

920
00:48:51,700 --> 00:48:52,900
The company. 
I was heading. 

921
00:48:52,900 --> 00:48:56,100
At the time, we went out there 
and we taught them agile. 

922
00:48:56,100 --> 00:48:59,900
We taught them how to do this. 
Well, they got to the point 

923
00:48:59,900 --> 00:49:04,200
where every week, the developers
would burn a CD, back in the 

924
00:49:04,200 --> 00:49:06,800
days when we had CDs. 
They would burn a CD and they 

925
00:49:06,808 --> 00:49:12,100
would put that CD on the top of 
a shelf and a stack of CDs every

926
00:49:12,100 --> 00:49:13,900
week. 
Just that bigger and bigger. 

927
00:49:14,200 --> 00:49:17,700
The sales people would go out 
and do demonstrations for 

928
00:49:17,700 --> 00:49:21,000
customers. 
Their policy became, they would 

929
00:49:21,000 --> 00:49:23,800
go to the developers room. 
They would take the top CD off 

930
00:49:23,800 --> 00:49:26,700
the shelf and they would go out 
and they would give demos that 

931
00:49:26,700 --> 00:49:31,400
was the level of trust that the 
salespeople and the programmers 

932
00:49:31,600 --> 00:49:34,300
had developed. 
The programmers were always 

933
00:49:34,300 --> 00:49:36,500
ready on a week. 
Weak bases. 

934
00:49:37,200 --> 00:49:39,700
So if people are familiar with 
these days, we also call it 

935
00:49:39,700 --> 00:49:43,000
continuous delivery, practice 
The age-old Continuous delivery,

936
00:49:43,000 --> 00:49:44,900
devops. 
All, these are interrelated. 

937
00:49:45,000 --> 00:49:48,100
So I think it's very good 
standard to have in that Asia 

938
00:49:48,100 --> 00:49:50,700
Loop cycle. 
You always ready to deploy 

939
00:49:50,800 --> 00:49:53,300
technically ready, but the 
business may be able to say, 

940
00:49:53,300 --> 00:49:55,100
okay. 
This is not the time to release 

941
00:49:55,200 --> 00:49:57,800
from the business point of view.
Maybe we can take some time 

942
00:49:57,800 --> 00:50:00,600
before we can turn it on for 
business users to use it. 

943
00:50:01,000 --> 00:50:04,000
So, we have one last point to 
discuss, which is about ethics, 

944
00:50:04,000 --> 00:50:05,400
right? 
So, we have discussed about the 

945
00:50:05,500 --> 00:50:07,400
Disciplines, we have discussed 
about standards. 

946
00:50:07,400 --> 00:50:10,300
The last point is about ethics. 
This is actually very 

947
00:50:10,300 --> 00:50:12,600
interesting. 
Why programmers should think 

948
00:50:12,600 --> 00:50:18,300
about ethics remodeled this part
after the Hippocratic Oath long,

949
00:50:18,300 --> 00:50:21,600
long, long ago, right? 
The Greek Epocrates came up with

950
00:50:21,600 --> 00:50:24,300
an oath for doctors from 
medical. 

951
00:50:24,600 --> 00:50:27,700
It's a long involved though. 
That Hippocrates wrote, I 

952
00:50:27,700 --> 00:50:29,700
thought. 
Well, maybe there should be a 

953
00:50:29,700 --> 00:50:34,400
similar kind of of for software 
people and this gets to the 

954
00:50:34,400 --> 00:50:37,800
ethics. 
Sex drive the standards but the 

955
00:50:37,800 --> 00:50:40,400
ethics are the core. 
You may come up with a different

956
00:50:40,400 --> 00:50:43,000
set of Standards from the same 
set of Ethics. 

957
00:50:43,200 --> 00:50:46,200
You may come up with a different
set of disciplines from the same

958
00:50:46,200 --> 00:50:51,100
set of Standards, but the ethics
remain and so I think there's 

959
00:50:51,100 --> 00:50:53,200
nine or ten points that I put in
there. 

960
00:50:53,700 --> 00:50:56,000
That's a suggestion to the 
industry at large. 

961
00:50:56,300 --> 00:50:58,900
These are the things that I 
think are ethically important. 

962
00:50:59,100 --> 00:51:02,800
The first one of course is Do no
harm that was Epocrates. 

963
00:51:02,800 --> 00:51:06,100
First statement Do no harm The 
code. 

964
00:51:06,100 --> 00:51:08,800
You write should do know her. 
You Do no harm to your 

965
00:51:08,800 --> 00:51:10,600
customers. 
It should do no harm to your 

966
00:51:10,600 --> 00:51:12,400
managers. 
It should do no harm to your 

967
00:51:12,400 --> 00:51:15,000
business. 
It should do no harm to Society 

968
00:51:15,000 --> 00:51:17,400
at large. 
It should do no harm to your 

969
00:51:17,400 --> 00:51:20,500
fellow programmers. 
It should do no harm to Future. 

970
00:51:20,500 --> 00:51:24,100
Programmers the code you write 
should behave properly. 

971
00:51:24,300 --> 00:51:28,300
It should be well structured. 
It should not be harmful. 

972
00:51:28,900 --> 00:51:31,400
Now a lot of people will look at
that and say well that would 

973
00:51:31,400 --> 00:51:35,000
mean I should never write any 
code for a weapon system and I 

974
00:51:35,000 --> 00:51:38,500
will leave It up to you, your 
own particular ethical mindset, 

975
00:51:38,500 --> 00:51:42,000
whether or not weapon systems 
are harmful or beneficial to 

976
00:51:42,000 --> 00:51:44,500
Human Society. 
You can make the argument both 

977
00:51:44,500 --> 00:51:46,900
ways. 
You might also say, means I 

978
00:51:46,900 --> 00:51:50,300
should never write software in a
gambling application. 

979
00:51:50,300 --> 00:51:52,800
And then, once again, I will 
leave that up to you as to 

980
00:51:52,800 --> 00:51:56,300
whether gambling is beneficial 
or harmful to society. 

981
00:51:56,300 --> 00:52:00,100
Those are personal decisions, 
but the fundamental ethical 

982
00:52:00,100 --> 00:52:05,200
structure below that is where 
I'm trying to push Do no harm. 

983
00:52:05,700 --> 00:52:10,300
Now consider the programmers. 
At Volkswagen who wrote code 

984
00:52:10,300 --> 00:52:13,700
intentional, you cheat. 
The Environmental Protection, 

985
00:52:13,700 --> 00:52:17,100
Agency in California. 
They literally wrote code that 

986
00:52:17,100 --> 00:52:20,900
could detect if they were 
running environmental tests and,

987
00:52:21,100 --> 00:52:24,400
and they would adjust the 
behavior of the engine to lower 

988
00:52:24,400 --> 00:52:27,400
the emissions. 
And then once you are off the 

989
00:52:27,400 --> 00:52:30,400
test, and they would have just 
the behavior of the ends again, 

990
00:52:30,400 --> 00:52:33,000
to emit more because they could 
generate more power. 

991
00:52:33,700 --> 00:52:36,900
That was harmful. 
That was harmful coat 

992
00:52:36,900 --> 00:52:39,800
intentional art. 
Some of those programmers are in

993
00:52:39,800 --> 00:52:41,500
jail. 
Now, just keep that in mind. 

994
00:52:41,500 --> 00:52:44,900
Programmers can go to jail. 
If they pry Farmville code. 

995
00:52:45,200 --> 00:52:48,100
Here's another one. 
Consider the programmers at 

996
00:52:48,100 --> 00:52:53,100
Toyota, who wrote a very complex
engine management system, which 

997
00:52:53,100 --> 00:52:57,000
did not properly calculate the 
size of stacks. 

998
00:52:57,600 --> 00:53:00,900
And so they made their Stacks in
an assembly language program. 

999
00:53:01,300 --> 00:53:05,000
They made their Stacks just a 
little too small every once in a

1000
00:53:05,100 --> 00:53:07,900
A very great while one of those 
Stacks will get blown. 

1001
00:53:07,900 --> 00:53:10,600
It would corrupt a process that 
was running in the engine 

1002
00:53:10,600 --> 00:53:14,200
management system and the engine
became unresponsive to the 

1003
00:53:14,200 --> 00:53:17,100
accelerator. 
The engine just started to 

1004
00:53:17,100 --> 00:53:20,400
accelerate out of control. 
The brakes, wouldn't function 

1005
00:53:20,700 --> 00:53:22,500
and a number of people lost 
their lives. 

1006
00:53:23,100 --> 00:53:26,700
That was harmful coat. 
It wasn't intentionally harmful,

1007
00:53:26,800 --> 00:53:31,200
but it was careless the software
developers who later on went in 

1008
00:53:31,200 --> 00:53:36,200
to testify in court about that 
code said, Almost like their 

1009
00:53:36,200 --> 00:53:39,800
work, hundreds and hundreds of 
global variables. 

1010
00:53:40,000 --> 00:53:43,600
And there was a massive amount 
of spaghetti code. 

1011
00:53:43,600 --> 00:53:47,600
I won't go into the details of 
it, but it's a very fascinating 

1012
00:53:47,600 --> 00:53:51,900
study of unintentionally, but 
very harmful code. 

1013
00:53:52,500 --> 00:53:56,600
We will do know her. 
The first of the ethics, which 

1014
00:53:56,600 --> 00:53:59,900
ties to the second point in the 
oath, which is we always do our 

1015
00:53:59,900 --> 00:54:02,300
best work. 
So even though the management 

1016
00:54:02,300 --> 00:54:05,800
pushes and all that we should 
strive to always As do our best 

1017
00:54:05,800 --> 00:54:08,600
work, that's one point that I 
also want to ask your opinion, 

1018
00:54:08,600 --> 00:54:12,000
which I think every programmers 
here should here, which is one 

1019
00:54:12,000 --> 00:54:13,900
point in the oath. 
You mentioned about estimate 

1020
00:54:14,000 --> 00:54:17,900
honestly and fairly. 
This is always the contention 

1021
00:54:17,900 --> 00:54:20,900
point between programmers. 
They call this product managers 

1022
00:54:20,900 --> 00:54:23,600
and all that, and I want you to 
give some advice for us 

1023
00:54:23,600 --> 00:54:26,300
programmers here. 
How should we do a summation 

1024
00:54:26,400 --> 00:54:29,100
properly? 
So, here's the scenario. 

1025
00:54:29,300 --> 00:54:33,000
Let's say that you've got some 
shoes on and maybe their tennis 

1026
00:54:33,000 --> 00:54:36,500
shoes that you can tie or untie.
How long does it take you to tie

1027
00:54:36,500 --> 00:54:38,800
your shoes? 
Probably you can tie your shoes 

1028
00:54:38,800 --> 00:54:40,600
in 10 seconds. 
Now. 

1029
00:54:40,600 --> 00:54:44,300
I want you to estimate how long 
it will take you to write down 

1030
00:54:44,300 --> 00:54:47,200
the instructions. 
So that a person who has never 

1031
00:54:47,200 --> 00:54:50,300
died of shoe before can tie your
shoes without being 

1032
00:54:50,300 --> 00:54:52,200
demonstrated, just the 
instructions. 

1033
00:54:52,700 --> 00:54:54,100
It's going to take you to write 
that. 

1034
00:54:54,400 --> 00:54:57,300
Well, that's the fundamental 
problem with software. 

1035
00:54:57,500 --> 00:55:02,300
We are communicating with more 
on these computers are morons. 

1036
00:55:02,500 --> 00:55:04,900
We have to write down the 
instructions inside. 

1037
00:55:05,100 --> 00:55:08,400
Such detail human beings have 
never had to deal with this kind

1038
00:55:08,400 --> 00:55:11,600
of detail in the history of 
humanity before, but we are 

1039
00:55:11,600 --> 00:55:15,800
literally, now, dealing with 
details at the one, big level 

1040
00:55:16,300 --> 00:55:19,700
human beings programmers at the 
estimate that it's hard to 

1041
00:55:19,700 --> 00:55:23,600
estimate that. 
So when a manager comes to you 

1042
00:55:23,600 --> 00:55:27,100
and says, I need this by 
Tuesday, you're stuck with a 

1043
00:55:27,100 --> 00:55:29,900
real problem because you don't 
know if you can get this done by

1044
00:55:29,900 --> 00:55:32,700
Tuesday. 
You have no idea now, maybe 

1045
00:55:32,700 --> 00:55:35,000
you've done things like it. 
Maybe you got it. 

1046
00:55:35,200 --> 00:55:38,500
In two or three days, maybe it's
like it, but you still don't 

1047
00:55:38,500 --> 00:55:40,900
know. 
So when you are asked to 

1048
00:55:40,900 --> 00:55:46,100
estimate something, you must not
give a specific time because 

1049
00:55:46,100 --> 00:55:48,600
that's a lie. 
You don't know that you're going

1050
00:55:48,600 --> 00:55:50,300
to get it done by a specific 
time. 

1051
00:55:50,500 --> 00:55:52,800
If you do give a specific time 
you damn. 

1052
00:55:52,800 --> 00:55:54,300
Well better. 
Get it done because you're 

1053
00:55:54,300 --> 00:55:56,600
making a promise. 
Do you better get it done by 

1054
00:55:56,600 --> 00:55:58,700
then? 
There's no excuse what you 

1055
00:55:58,700 --> 00:56:01,500
should do. 
When asked for an estimate. 

1056
00:56:01,600 --> 00:56:06,100
It's give a range and the range 
should be Pretty generous 

1057
00:56:06,100 --> 00:56:09,500
because you don't know how long 
it's going to take. 

1058
00:56:09,700 --> 00:56:15,400
So the responsibility is on you 
to Define for the manager, the 

1059
00:56:15,400 --> 00:56:20,000
shape of your uncertain. 
And you do that by maybe giving 

1060
00:56:20,000 --> 00:56:23,400
three estimates the best case, 
the nominal cased in the worst 

1061
00:56:23,400 --> 00:56:27,100
case and the best case should 
have a 5% chance of success. 

1062
00:56:27,300 --> 00:56:31,600
And the worst case you have a 
95% chance of success, and the 

1063
00:56:31,600 --> 00:56:35,000
nominal case should have a 50% 
chance of success hand. 

1064
00:56:35,100 --> 00:56:38,100
Those three numbers to the 
manager and say that's the best 

1065
00:56:38,100 --> 00:56:40,400
I can do. 
And manager, might say, well, I 

1066
00:56:40,408 --> 00:56:43,400
need a number. 
I can't give you cannot give you

1067
00:56:43,400 --> 00:56:46,000
a number. 
I do not know hold to that as 

1068
00:56:46,000 --> 00:56:49,200
much as you can and then watch 
out for the little trick. 

1069
00:56:49,500 --> 00:56:51,800
Here's a little trick. 
I need it by Tuesday. 

1070
00:56:51,800 --> 00:56:55,100
I can't tell you if it's going 
to be by Tuesday, might take me 

1071
00:56:55,100 --> 00:56:58,500
seven binney's and then the 
manager will say well, will you 

1072
00:56:58,500 --> 00:57:01,500
at least try to get it done by 
Tuesday? 

1073
00:57:01,800 --> 00:57:08,100
The answer to that is no. 
Because I'm already trying, it's

1074
00:57:08,100 --> 00:57:10,000
not like, I'm not trying 
already. 

1075
00:57:10,300 --> 00:57:12,600
And in your brain, little 
fireworks should be going off 

1076
00:57:12,600 --> 00:57:15,000
saying, how dare you accuse me 
of not trying, but you probably 

1077
00:57:15,000 --> 00:57:17,400
shouldn't have those words come 
out of your mouth, but you 

1078
00:57:17,400 --> 00:57:19,700
should be saying we are already 
trying. 

1079
00:57:19,700 --> 00:57:22,400
We are already doing our best. 
I cannot give you a better 

1080
00:57:22,400 --> 00:57:25,500
number. 
I cannot promise anything and we

1081
00:57:25,500 --> 00:57:30,200
are already trying. 
If you say yes to that little 

1082
00:57:30,200 --> 00:57:33,000
trick, if you say yes. 
We'll try the manager will go 

1083
00:57:33,000 --> 00:57:34,900
away thinking that you just made
a commitment. 

1084
00:57:35,500 --> 00:57:37,600
Thanks for sharing this watch 
out words. 

1085
00:57:37,700 --> 00:57:40,800
Will you at least try? 
So I think people will hear this

1086
00:57:40,800 --> 00:57:43,700
episode by tomorrow. 
If their manager asking, try 

1087
00:57:43,700 --> 00:57:47,400
your best not to, you know, give
a false commitment even though 

1088
00:57:47,400 --> 00:57:50,200
you think it's not possible. 
So that's always the danger. 

1089
00:57:50,700 --> 00:57:53,200
So Uncle, Bob is been a pleasant
conversation. 

1090
00:57:53,400 --> 00:57:55,300
Thanks again for sharing all 
these insights. 

1091
00:57:55,400 --> 00:57:57,100
It's also fun at the same time, 
right? 

1092
00:57:57,100 --> 00:58:00,000
So I'm really laughing, as you 
mentioned and describe some of 

1093
00:58:00,000 --> 00:58:02,100
these things. 
Unfortunately, due to the time 

1094
00:58:02,300 --> 00:58:05,000
we have to end this 
conversation, but before I let 

1095
00:58:05,000 --> 00:58:08,200
you Normally, I have this one 
last question that I always ask 

1096
00:58:08,200 --> 00:58:11,200
for all my guests, which is to 
share your vision of three 

1097
00:58:11,200 --> 00:58:13,800
technical leadership wisdom for 
us to learn from you. 

1098
00:58:14,000 --> 00:58:16,000
What will be your three 
technical leadership, wisdom and

1099
00:58:16,000 --> 00:58:19,900
Kebab. 
First one programmers are not 

1100
00:58:19,900 --> 00:58:21,500
good at communicating with 
humans. 

1101
00:58:21,600 --> 00:58:23,800
Generally speaking. 
We didn't get into this business

1102
00:58:23,800 --> 00:58:26,900
because we like people so 
learning to communicate with 

1103
00:58:26,900 --> 00:58:32,500
people learn how to confront 
managers learn how not to back 

1104
00:58:32,500 --> 00:58:34,800
away. 
Learn how to communicate, well, 

1105
00:58:35,100 --> 00:58:39,400
Learn how to write, learn how to
write arguments, learn how to 

1106
00:58:39,400 --> 00:58:44,000
write articles and documents. 
Learn how to make your case in a

1107
00:58:44,000 --> 00:58:46,700
written form. 
That's very important. 

1108
00:58:46,700 --> 00:58:51,500
Learn how to speak, learn how to
make your case known verbally. 

1109
00:58:51,700 --> 00:58:55,300
So all of those things are very 
important and maybe the most 

1110
00:58:55,300 --> 00:58:58,400
important of all of them, read 
like crazy read as much as you 

1111
00:58:58,400 --> 00:59:03,200
can't read old stuff, get old 
stuff, old software books, read 

1112
00:59:03,200 --> 00:59:07,600
them get new software books. 
Read them read like crazy, poor 

1113
00:59:07,600 --> 00:59:11,600
information into your brain and 
then let the good stuff. 

1114
00:59:11,600 --> 00:59:14,300
Come back out. 
Thanks for sharing that. 

1115
00:59:14,400 --> 00:59:17,600
I'm sure all your books actually
contains all the historical 

1116
00:59:17,600 --> 00:59:19,900
point of view as well. 
So sometimes you actually 

1117
00:59:19,900 --> 00:59:22,500
started a chapter by giving us. 
I don't know, it's random. 

1118
00:59:22,500 --> 00:59:26,200
Sometimes writes like room 
physics from history, from the 

1119
00:59:26,200 --> 00:59:27,600
history of computers and all 
that. 

1120
00:59:27,600 --> 00:59:30,000
So, thanks for sharing that I 
think that's also partly how we 

1121
00:59:30,000 --> 00:59:32,800
read all stops as well. 
So Uncle Bob for people who 

1122
00:59:32,800 --> 00:59:35,700
would like to reach out for you 
and maybe learn Some of your 

1123
00:59:35,700 --> 00:59:37,800
cool stuffs where they can find 
you online. 

1124
00:59:38,700 --> 00:59:40,800
Oh heavens. 
You can find me at the clean 

1125
00:59:40,800 --> 00:59:43,100
coder.com. 
That's my website. 

1126
00:59:43,300 --> 00:59:45,900
All one word. 
All lowercase clean coder. 

1127
00:59:46,400 --> 00:59:50,400
My videos are at clean 
coders.com, which is the same 

1128
00:59:50,400 --> 00:59:53,600
except for the Tessa p.m. 
Think ogres.com. 

1129
00:59:54,000 --> 00:59:57,800
My Twitter handle is Uncle Bob 
Martin, and that's probably 

1130
00:59:57,800 --> 00:59:59,700
enough. 
You'll probably see plenty of me

1131
00:59:59,707 --> 01:00:02,000
that way. 
Thanks again, Uncle Bob for your

1132
01:00:02,000 --> 01:00:03,500
time. 
So, thanks again for sharing all

1133
01:00:03,500 --> 01:00:05,000
your insights. 
My pleasure. 

1134
01:00:05,200 --> 01:00:10,300
It's been a lot of fun. 
Thank you for listening to this 

1135
01:00:10,300 --> 01:00:13,800
episode and for staying, right 
until the end if you highly 

1136
01:00:13,800 --> 01:00:16,500
enjoyed it, I would appreciate 
if you share it with your 

1137
01:00:16,500 --> 01:00:19,500
friends and colleagues who you 
think would also benefit from 

1138
01:00:19,500 --> 01:00:22,000
listening to this episode. 
And if you are new to the 

1139
01:00:22,000 --> 01:00:25,100
podcast, make sure to subscribe 
and leave me your valuable 

1140
01:00:25,100 --> 01:00:28,100
review and feedback. 
It helps me a lot in order to 

1141
01:00:28,100 --> 01:00:31,300
grow this podcast better. 
You can also find the full show 

1142
01:00:31,300 --> 01:00:34,500
notes of this conversation on 
the episode page, at Tech, 

1143
01:00:34,500 --> 01:00:37,800
Legion of death website, 
including the full transcript 

1144
01:00:37,900 --> 01:00:39,900
interesting. 
Quartz and links to the 

1145
01:00:39,900 --> 01:00:42,300
resources mention from the 
conversation. 

1146
01:00:42,700 --> 01:00:45,700
And lastly, make sure to 
subscribe to the shows mailing 

1147
01:00:45,700 --> 01:00:49,100
list on pack leader. 
No dot f to get notified for any

1148
01:00:49,100 --> 01:00:51,800
future episodes. 
Stay tuned for the next 

1149
01:00:51,800 --> 01:00:53,100
technology. 
No episode. 

1150
01:00:53,400 --> 01:00:55,100
And until then. 
Goodbye.