1
00:00:00,100 --> 00:00:03,000
So it seems to me. 
Good code, should be resilient 

2
00:00:03,000 --> 00:00:05,000
to Bucks. 
It should be difficult to make 

3
00:00:05,000 --> 00:00:08,100
bugs, and it should be easy to 
get started on. 

4
00:00:08,100 --> 00:00:10,400
It should lead you in the way 
that it wants to go. 

5
00:00:10,800 --> 00:00:14,700
So it's making it easier to do 
the kinds of changes that you 

6
00:00:14,700 --> 00:00:17,700
want the system to make. 
Of course, the downside of that 

7
00:00:17,700 --> 00:00:20,800
is that most refractory actually
also make it harder to make 

8
00:00:20,900 --> 00:00:23,300
other changes. 
And so if you guess the 

9
00:00:23,300 --> 00:00:26,100
direction wrong of the software,
then it can have the negative 

10
00:00:26,100 --> 00:00:32,200
effect. 
Hey everyone. 

11
00:00:32,700 --> 00:00:37,700
My name is Henry Surya be Robin.
And you're listening to the 

12
00:00:37,700 --> 00:00:40,600
tekhelet journal. 
The show will be bringing you 

13
00:00:40,600 --> 00:00:44,100
the greatest technical leaders 
practitioners and thought 

14
00:00:44,100 --> 00:00:47,400
leaders in the industry to 
discuss about their Journey 

15
00:00:47,800 --> 00:00:52,000
ideas and practices that we all 
can learn and apply to build a 

16
00:00:52,000 --> 00:00:55,700
highly performing technical team
and to make an impact in your 

17
00:00:55,700 --> 00:00:59,300
personal work. 
So let's dive into our Journal. 

18
00:01:04,599 --> 00:01:08,000
Hello again, to all of you. 
My listeners, welcome back to a 

19
00:01:08,000 --> 00:01:10,500
new episode of the tekhelet 
journal podcast. 

20
00:01:10,700 --> 00:01:13,900
Thank you for spending your time
with me today, listening to this

21
00:01:13,900 --> 00:01:16,300
episode. 
If you haven't, please follow 

22
00:01:16,300 --> 00:01:19,500
technology, you know, on your 
podcast app and social media on 

23
00:01:19,500 --> 00:01:23,100
LinkedIn, Twitter and Instagram,
you can also contribute and 

24
00:01:23,100 --> 00:01:26,400
support this podcast by 
subscribing as a patron at 

25
00:01:26,400 --> 00:01:29,600
technology. 
No, dot f / Patron, and help me 

26
00:01:29,600 --> 00:01:32,200
to continue producing, great 
content every week. 

27
00:01:33,000 --> 00:01:35,500
For today's episode. 
I am happy to share my 

28
00:01:35,500 --> 00:01:37,800
conversation with Christian 
Clausen. 

29
00:01:38,400 --> 00:01:42,400
Christian is a technical a jar 
coach specializing in teaching 

30
00:01:42,400 --> 00:01:45,300
teams on how to refactor their 
code properly. 

31
00:01:45,800 --> 00:01:50,400
He is also the author of five 
lines of code in this episode 

32
00:01:50,400 --> 00:01:55,100
Christian explain in depth about
what refactoring is when and how

33
00:01:55,100 --> 00:01:57,000
we should do refactoring to our 
code. 

34
00:01:57,200 --> 00:01:59,800
And he also described the 
components and pillars of 

35
00:01:59,800 --> 00:02:02,600
refactoring, including his 
favorite refactoring work. 

36
00:02:02,800 --> 00:02:07,100
Flo Christian also shared about 
a few important architectural 

37
00:02:07,100 --> 00:02:11,900
refactoring such as composition 
over inheritance and introducing

38
00:02:11,900 --> 00:02:14,000
changes. 
By addition instead of 

39
00:02:14,000 --> 00:02:17,300
modification. 
Finally Christian also shared a 

40
00:02:17,308 --> 00:02:21,000
few tips for writing quality 
software, such as his five lines

41
00:02:21,000 --> 00:02:23,700
of code Rule and why he thinks 5
is the magic. 

42
00:02:23,700 --> 00:02:28,800
Number cultivating, the habit of
deleting code and the advice 

43
00:02:28,800 --> 00:02:31,800
went to avoid optimization and 
generality. 

44
00:02:32,700 --> 00:02:35,900
I enjoyed my conversation with 
Christian deepening, my 

45
00:02:35,900 --> 00:02:39,200
understanding of refactoring and
some of his useful practical 

46
00:02:39,200 --> 00:02:41,300
tips. 
And I hope that you will find 

47
00:02:41,300 --> 00:02:45,100
this episode useful to consider 
helping the show by living it a 

48
00:02:45,100 --> 00:02:47,900
rating or review on your podcast
app. 

49
00:02:47,900 --> 00:02:50,400
And you can also leave some 
comments on all social media 

50
00:02:50,400 --> 00:02:53,500
channels, though. 
It may seem trivial, but those 

51
00:02:53,500 --> 00:02:56,400
reviews and comments are one of 
the best ways to help me get 

52
00:02:56,400 --> 00:03:00,100
this podcasts to reach more 
listeners and hopefully they can

53
00:03:00,100 --> 00:03:02,300
also benefit from all the 
contents in this. 

54
00:03:02,500 --> 00:03:06,000
Outcast, let's get this episode 
started right after our sponsor 

55
00:03:06,000 --> 00:03:08,400
message. 
Are you looking for a new cool 

56
00:03:08,400 --> 00:03:10,000
swag? 
Tackle, it Journal. 

57
00:03:10,000 --> 00:03:13,200
Now offers you some swags that 
you can purchase online. 

58
00:03:13,600 --> 00:03:17,500
These wax are printed on demand 
based on your preference and 

59
00:03:17,500 --> 00:03:20,300
will be delivered safely to you 
all over the world where 

60
00:03:20,300 --> 00:03:23,300
shipping is available. 
Check out all the cool swag is 

61
00:03:23,308 --> 00:03:26,200
available by visiting 
technology, you know dot, f / 

62
00:03:26,200 --> 00:03:28,600
shop and don't forget to break 
yourself. 

63
00:03:28,700 --> 00:03:30,800
Once you receive any of those 
tracks. 

64
00:03:33,400 --> 00:03:35,800
Hello everyone, welcome back to 
another new episode of the 

65
00:03:35,800 --> 00:03:37,900
package. 
You know, today I have a guest 

66
00:03:37,900 --> 00:03:39,800
with me. 
His name is Christian Clausen. 

67
00:03:40,100 --> 00:03:43,700
Christian is a technical a jar 
coach, which is different than 

68
00:03:43,700 --> 00:03:45,200
the typical age. 
Our coach. 

69
00:03:45,300 --> 00:03:48,700
He's actually specializing in 
helping people to properly 

70
00:03:48,700 --> 00:03:51,500
refactor code. 
So that's why the technical term

71
00:03:51,500 --> 00:03:54,700
is there in his title. 
So, he previously worked as a 

72
00:03:54,700 --> 00:03:58,700
software engineer and even has a
teaching experience about 

73
00:03:58,700 --> 00:04:00,700
software quality in the 
University. 

74
00:04:01,200 --> 00:04:04,100
So as you can guess, They will 
be talking a lot about software 

75
00:04:04,100 --> 00:04:06,300
quality. 
And also in particular 

76
00:04:06,300 --> 00:04:10,100
refactoring, Christian is also 
writing a book called five lines

77
00:04:10,100 --> 00:04:13,500
of code, which is currently in 
Early Access program in mining. 

78
00:04:13,900 --> 00:04:16,100
So Christian. 
Thank you for your time. 

79
00:04:16,300 --> 00:04:18,100
Looking forward to have this 
talk with you today. 

80
00:04:18,800 --> 00:04:20,899
Thank you for having me 
Christian. 

81
00:04:20,899 --> 00:04:23,900
Before we start, maybe, can you 
introduce yourself to the 

82
00:04:23,900 --> 00:04:26,000
audience here? 
Telling more about yourself, 

83
00:04:26,000 --> 00:04:28,400
your highlights, maybe or 
turning points in your career? 

84
00:04:29,000 --> 00:04:30,900
Sure. 
Now, I was at University. 

85
00:04:30,900 --> 00:04:33,700
I have always liked software. 
And coding and programming and 

86
00:04:33,700 --> 00:04:36,200
I've done a lot of that. 
I also like teaching. 

87
00:04:36,200 --> 00:04:38,700
So I've done a lot of teaching 
at the University level, when I 

88
00:04:38,700 --> 00:04:41,300
could buy with the teaching, 
assistant will stop at some 

89
00:04:41,300 --> 00:04:42,700
point. 
There wasn't any teaching 

90
00:04:42,700 --> 00:04:46,300
position for me to fill and so I
didn't have anything to do being

91
00:04:46,300 --> 00:04:49,000
a bit of a self-starter. 
I decided to just start my own 

92
00:04:49,000 --> 00:04:52,200
teaching thing where I would 
invite students to come have a 

93
00:04:52,207 --> 00:04:55,900
to our Tech talk every week and 
everyone was free to talk and to

94
00:04:55,900 --> 00:04:59,100
say whatever they had on their 
mind, but it turns out computer 

95
00:04:59,100 --> 00:05:02,700
scientists are pretty timid. 
So I had to host the first Steam

96
00:05:02,700 --> 00:05:06,400
myself to get the ball rolling 
and doing 60 weeks in a row, and

97
00:05:06,400 --> 00:05:08,700
learned a lot of different 
things and load of different 

98
00:05:08,700 --> 00:05:10,300
topics. 
And I got really good at 

99
00:05:10,308 --> 00:05:12,500
learning really. 
And then after we were done with

100
00:05:12,500 --> 00:05:16,000
University, one of my friends 
asked me if I could improvise a 

101
00:05:16,008 --> 00:05:17,700
talk having done so many of 
them. 

102
00:05:17,700 --> 00:05:19,500
Could I just do it on the fly. 
Now? 

103
00:05:19,900 --> 00:05:21,500
There's only one way to find 
out. 

104
00:05:21,500 --> 00:05:24,400
Let's try it. 
And so that's actually how I 

105
00:05:24,400 --> 00:05:27,300
came up with the idea for the 
book that conversation that 

106
00:05:27,300 --> 00:05:29,200
followed where I tried to 
illustrate. 

107
00:05:29,400 --> 00:05:31,800
I wanted to do something with 
code because that's where I feel

108
00:05:31,800 --> 00:05:32,600
most comfortable. 
Double. 

109
00:05:32,600 --> 00:05:35,500
And so I wrote up the example 
that's in part, one of the book 

110
00:05:35,700 --> 00:05:38,000
and then he was like, oh that 
was an interesting 

111
00:05:38,000 --> 00:05:39,700
demonstration. 
I don't like, we're not done. 

112
00:05:39,700 --> 00:05:42,200
We're just getting started. 
I want to teach you refactoring 

113
00:05:42,600 --> 00:05:44,400
and then he started refactoring 
this code base. 

114
00:05:44,400 --> 00:05:47,100
And I came up with these rules 
that are the basis for the book 

115
00:05:47,100 --> 00:05:48,500
that I guess, we can come back 
to. 

116
00:05:48,900 --> 00:05:50,600
But that wasn't how it all 
started. 

117
00:05:50,700 --> 00:05:53,900
Then I worked as a consultant, a
lot and I've transition from 

118
00:05:53,900 --> 00:05:57,800
being a developer to being like,
a tickly and my Fondest Memories

119
00:05:57,800 --> 00:05:59,900
of my career for my ticket 
times. 

120
00:06:00,200 --> 00:06:03,200
So the title of your show is 
really Appealing to me. 

121
00:06:03,800 --> 00:06:06,800
And then after that, I figured, 
maybe I should try to go more 

122
00:06:06,800 --> 00:06:08,700
into teaching because I was 
missing it a bit. 

123
00:06:08,900 --> 00:06:11,900
You know, I really am passionate
about teaching and about people.

124
00:06:12,000 --> 00:06:14,800
And so, I went and I actually 
taught at the University of 

125
00:06:14,800 --> 00:06:18,900
applied sciences in top software
quality, but was a good fit for 

126
00:06:18,900 --> 00:06:22,200
my current patients level. 
I think I'm too young to go and 

127
00:06:22,200 --> 00:06:25,000
be a full-time teacher. 
So, I went back and now I'm a 

128
00:06:25,000 --> 00:06:27,600
technical agile, coaches. 
You said I go and help 

129
00:06:27,600 --> 00:06:30,500
organizations, understand how to
do technical practices. 

130
00:06:30,500 --> 00:06:33,000
As you said, testing 
refactoring, all of ab stuff but

131
00:06:33,000 --> 00:06:35,400
also the cultural side, how we 
manage the people. 

132
00:06:35,400 --> 00:06:38,600
How do we organize things and 
devops and teams, apologies, and

133
00:06:38,600 --> 00:06:41,500
all that interesting stuff. 
So that's sort of everything in 

134
00:06:41,500 --> 00:06:44,500
five minutes or something. 
Thanks for sharing your story. 

135
00:06:44,500 --> 00:06:47,900
I could see you embody teaching 
code, looking at your cap and 

136
00:06:47,900 --> 00:06:50,500
also your T-shirt, right? 
Then they are like geeky 

137
00:06:50,600 --> 00:06:52,900
sentences. 
So, I'm really looking forward 

138
00:06:52,900 --> 00:06:55,600
to learn from you. 
Please treat this as a teaching 

139
00:06:55,600 --> 00:06:57,800
experience for the audience here
as well. 

140
00:06:58,300 --> 00:07:01,200
So you mentioned that, you 
specialize a lot in refactoring,

141
00:07:01,200 --> 00:07:03,900
code, Maybe. 
As a refresher for those people 

142
00:07:03,900 --> 00:07:06,800
who may not be familiar. 
Could you give us a definition 

143
00:07:06,800 --> 00:07:09,700
of what is actually refactoring?
Yeah. 

144
00:07:09,800 --> 00:07:12,500
Sure. 
So refactoring in its purest, 

145
00:07:12,500 --> 00:07:15,500
form just means changing the 
code without changing what it 

146
00:07:15,500 --> 00:07:17,000
does. 
That's the definition. 

147
00:07:17,000 --> 00:07:19,800
I always introduce two people. 
It doesn't actually have an 

148
00:07:19,800 --> 00:07:22,000
opinion on how to use that 
thing. 

149
00:07:22,000 --> 00:07:24,900
It's just saying these two 
pieces of code are the same. 

150
00:07:24,900 --> 00:07:27,700
We can go from one to the other.
In practice though. 

151
00:07:27,700 --> 00:07:30,500
We almost always have the target
of actually wanting to make the 

152
00:07:30,500 --> 00:07:33,900
code more readable more. 
Maintainable better to work with

153
00:07:33,900 --> 00:07:36,200
in something. 
So then we call it refactoring 

154
00:07:36,200 --> 00:07:39,200
and in my book and also, I 
think, in my own Palace book, he

155
00:07:39,200 --> 00:07:43,100
equates refactoring with, making
the code better in the sense of 

156
00:07:43,100 --> 00:07:46,400
maintainability and readability,
but it could also just means 

157
00:07:46,400 --> 00:07:48,700
that we're rearranging code 
without changing the 

158
00:07:48,707 --> 00:07:51,400
functionality. 
So that's the basic concept of 

159
00:07:51,400 --> 00:07:55,600
it and you relate this to what 
you call good coat. 

160
00:07:55,600 --> 00:07:57,500
So what does it mean by good 
code? 

161
00:07:57,500 --> 00:08:00,000
Is it like code that is readable
and maintainable only, or is 

162
00:08:00,000 --> 00:08:01,800
there any other property or 
attribute? 

163
00:08:02,000 --> 00:08:04,600
Well, you could have many 
attributes of your code that 

164
00:08:04,608 --> 00:08:07,000
Define what good is in your 
specific context. 

165
00:08:07,000 --> 00:08:08,700
Some people are doing embedded 
systems. 

166
00:08:08,700 --> 00:08:11,300
Where memory layout is really 
important or performance is 

167
00:08:11,300 --> 00:08:13,300
really important. 
There are certainly domains 

168
00:08:13,300 --> 00:08:16,500
where good code has different 
properties or what seems to be 

169
00:08:16,500 --> 00:08:18,900
common to most. 
If not, all of them is that we 

170
00:08:18,900 --> 00:08:21,300
want our invariance to be as 
local as possible. 

171
00:08:21,300 --> 00:08:24,400
And variance, is the stuff we 
need to keep in our heads. 

172
00:08:24,400 --> 00:08:27,100
While we're working with the 
software and the more 

173
00:08:27,100 --> 00:08:29,400
complicated they are. 
And the further away they are 

174
00:08:29,400 --> 00:08:32,000
from where we're looking. 
The more likely we're going to 

175
00:08:32,000 --> 00:08:33,700
To forget them, right? 
And then we're going to make 

176
00:08:33,700 --> 00:08:35,799
mistakes and introduce errors 
into the system. 

177
00:08:36,100 --> 00:08:39,600
So, it seems to me, good code, 
should be resilient to Bucks. 

178
00:08:39,799 --> 00:08:43,200
It should be difficult to make 
bugs, and it should be easy to 

179
00:08:43,200 --> 00:08:45,300
get started on. 
It should lead you in the way 

180
00:08:45,300 --> 00:08:49,000
that it wants to go. 
So it's making it easier to do 

181
00:08:49,000 --> 00:08:52,100
the kinds of changes that you 
want the system to make. 

182
00:08:52,400 --> 00:08:55,300
Of course, the downside of that 
is that most refractory actually

183
00:08:55,300 --> 00:08:57,700
also make it harder to make 
other changes. 

184
00:08:58,000 --> 00:09:00,700
And so if you guess the 
direction wrong of the software,

185
00:09:00,700 --> 00:09:05,200
then it can have the Perfect. 
Thanks for reminding that part 

186
00:09:05,300 --> 00:09:07,500
because sometimes a lot of 
developers are into yet. 

187
00:09:07,500 --> 00:09:09,900
Let's refactor. 
Let's refactor make it better, 

188
00:09:10,100 --> 00:09:12,700
but it turns out that the design
becomes more complex. 

189
00:09:12,700 --> 00:09:14,800
The code actually becomes less 
readable. 

190
00:09:15,200 --> 00:09:17,700
And also it's not easy to make 
further change. 

191
00:09:17,800 --> 00:09:20,300
A lot of times actually 
Engineers love to refactor. 

192
00:09:20,500 --> 00:09:22,100
They think the code will be 
better. 

193
00:09:22,300 --> 00:09:25,600
But is there any decision point 
where you think we should think 

194
00:09:25,600 --> 00:09:28,200
about doing refactoring? 
Like what's the purpose of 

195
00:09:28,200 --> 00:09:32,300
refactoring? 
It's very linked to how well 

196
00:09:32,300 --> 00:09:34,800
you're able to predict the 
future of your software. 

197
00:09:35,100 --> 00:09:38,000
I always say that if you're 
experimenting a lot, if you have

198
00:09:38,000 --> 00:09:40,000
something you're testing, you 
don't really know what's going 

199
00:09:40,000 --> 00:09:41,700
to happen to it. 
Don't worry Factory. 

200
00:09:41,700 --> 00:09:44,100
Don't make it super nice to 
spend that time because you 

201
00:09:44,100 --> 00:09:47,200
don't know yet, if it's 
malleable validate, the business

202
00:09:47,200 --> 00:09:50,200
case first, and then do the 
refactoring in the same way. 

203
00:09:50,200 --> 00:09:53,400
If you have something that's end
of life soon or some setting 

204
00:09:53,800 --> 00:09:56,400
don't spend time refactoring 
that making it nice because it's

205
00:09:56,400 --> 00:09:59,500
not going to survive for long 
enough for it to pay off all the

206
00:09:59,900 --> 00:10:03,200
Training should pay for itself 
in terms of easier, maintenance 

207
00:10:03,200 --> 00:10:06,700
and cheaper maintenance in the 
future and fewer bugs at higher 

208
00:10:06,700 --> 00:10:09,300
quality. 
Also, a lot of times we 

209
00:10:09,300 --> 00:10:11,700
associate, when we do 
refactoring, is to actually add 

210
00:10:11,700 --> 00:10:14,800
more tests, adding more 
automated test unit test, 

211
00:10:14,800 --> 00:10:19,000
whichever test that is because 
to refactor and not changing the

212
00:10:19,000 --> 00:10:21,600
actual intention of the code, 
the functionality cell, 

213
00:10:21,600 --> 00:10:24,500
Sometimes It's Tricky, right? 
And we want to have the failsafe

214
00:10:24,500 --> 00:10:27,000
mechanism to say that, okay. 
We have a test here. 

215
00:10:27,200 --> 00:10:29,700
We refactor and proves that the 
code actually still. 

216
00:10:29,800 --> 00:10:32,800
Behaves as what we intended to 
in the beginning, but in your 

217
00:10:32,800 --> 00:10:35,400
book, actually, you come up with
a different approach saying that

218
00:10:35,400 --> 00:10:38,500
you don't always have to come 
from the automated testing 

219
00:10:38,500 --> 00:10:40,600
perspective. 
You can actually do refactoring 

220
00:10:40,600 --> 00:10:43,000
without that. 
Can you tell us more about that?

221
00:10:43,500 --> 00:10:47,300
Yeah, definitely be. 
So I think since then can be 

222
00:10:47,300 --> 00:10:49,900
super useful. 
I like to start saying I'm not 

223
00:10:49,900 --> 00:10:53,000
against testing, testing 
certainly has its places when 

224
00:10:53,000 --> 00:10:55,000
I'm against this. 
It seems that some people are 

225
00:10:55,000 --> 00:10:57,900
fanatic about testing thinking 
it's the only way to check code 

226
00:10:58,100 --> 00:10:59,700
or thinking, man, if you have 
test. 

227
00:10:59,800 --> 00:11:02,500
Everything will work out. 
And neither of those are true. 

228
00:11:02,700 --> 00:11:05,200
There are other ways to 
guarantee high quality of your 

229
00:11:05,200 --> 00:11:08,100
code and also things can fail 
even if you have tests. 

230
00:11:08,400 --> 00:11:11,400
So, I'm more just an advocate of
having a more nuanced approach, 

231
00:11:11,400 --> 00:11:14,600
where you actually pick the 
quality tools, that fit the job 

232
00:11:15,000 --> 00:11:17,200
like many of the refactorings. 
I would claim. 

233
00:11:17,300 --> 00:11:19,800
Most, if not all of their 
affections in, my book are 

234
00:11:19,800 --> 00:11:23,600
breaking down to Atomic steps in
a way that make it difficult for

235
00:11:23,600 --> 00:11:25,400
you to make mistakes while doing
them. 

236
00:11:25,600 --> 00:11:27,100
Of course. 
This means that we go a little 

237
00:11:27,100 --> 00:11:30,100
bit slower while doing 
refactorings, but that To make 

238
00:11:30,100 --> 00:11:32,600
up for the fact that we don't 
have the test to catch us if we 

239
00:11:32,600 --> 00:11:35,300
Slide by the site. 
So if you follow the steps very 

240
00:11:35,300 --> 00:11:39,200
accurately and in small steps, 
you're minimizing the risk of 

241
00:11:39,208 --> 00:11:42,700
error at each point in the 
process which minimizes the 

242
00:11:42,700 --> 00:11:46,100
overall error rate a lot. 
So, I feel like there are other 

243
00:11:46,100 --> 00:11:48,700
ways to guarantee that you can 
have high quality code, 

244
00:11:48,700 --> 00:11:51,800
particularly. 
My thesis work that University 

245
00:11:51,800 --> 00:11:54,700
was about, provably correct 
software here. 

246
00:11:54,700 --> 00:11:57,700
I was actually sitting down and 
doing a proof that the computer 

247
00:11:57,700 --> 00:12:00,900
could then check and verify that
the I might written, did the 

248
00:12:00,900 --> 00:12:03,800
thing that I claimed that it 
did, which means testing was 

249
00:12:03,800 --> 00:12:05,500
trivial, you know, you don't 
need to test something. 

250
00:12:05,500 --> 00:12:07,800
If you've proven it works. 
You don't even need to run it. 

251
00:12:08,100 --> 00:12:11,100
I just knew that it worked. 
So I'm just saying there are so 

252
00:12:11,100 --> 00:12:13,300
many different levels of 
security and risk. 

253
00:12:13,300 --> 00:12:15,200
And it's all about risk 
management. 

254
00:12:15,400 --> 00:12:18,000
What is your company's strategy 
for managing risk? 

255
00:12:18,000 --> 00:12:19,900
Is it during testing? 
That's cool. 

256
00:12:20,000 --> 00:12:22,900
Isn't doing like types. 
That cannot go wrong. 

257
00:12:23,100 --> 00:12:25,900
Then that's also cool. 
It's a business decision. 

258
00:12:25,900 --> 00:12:29,100
What's your tolerance to risk 
ever since I wrote my thesis on 

259
00:12:29,100 --> 00:12:31,900
provably, Correct software. 
I hope that their automated 

260
00:12:31,900 --> 00:12:33,900
cars. 
Self-driving cast would be 

261
00:12:33,900 --> 00:12:34,800
proven. 
Correct. 

262
00:12:34,800 --> 00:12:36,400
So that we knew Lee didn't kill 
people. 

263
00:12:36,400 --> 00:12:38,300
They do need to kill. 
Unfortunately. 

264
00:12:38,300 --> 00:12:40,300
It's sort of gone. 
The other direction doing 

265
00:12:40,300 --> 00:12:42,200
machine learning where we can't 
even look at one that's 

266
00:12:42,200 --> 00:12:44,600
thinking. 
It's very interesting. 

267
00:12:44,600 --> 00:12:46,800
This is provably correct 
software. 

268
00:12:46,800 --> 00:12:49,200
I haven't heard it before. 
Could you tell us a little bit 

269
00:12:49,200 --> 00:12:51,000
more about? 
How does this thing work? 

270
00:12:51,200 --> 00:12:53,600
Is it solely relying on certain 
practices? 

271
00:12:53,600 --> 00:12:55,400
Or is it solely relying on 
tools? 

272
00:12:56,200 --> 00:12:58,600
I guess you can prove any 
program but it comes very 

273
00:12:58,600 --> 00:13:00,400
expensive to do in the general 
case. 

274
00:13:00,700 --> 00:13:03,400
The specific part. 
I work with was automatically 

275
00:13:03,400 --> 00:13:06,300
verifiable proof. 
So we use the proof assistant or

276
00:13:06,300 --> 00:13:09,100
I've dependently typed 
programming language specific 

277
00:13:09,100 --> 00:13:11,900
language, that was filled on new
camel and functional language, 

278
00:13:11,900 --> 00:13:14,800
where you could. 
Then also type in the properties

279
00:13:14,800 --> 00:13:17,600
that you wanted your program to 
have and then it has some extra 

280
00:13:17,600 --> 00:13:20,300
stuff to help you do the proof 
in that program as well. 

281
00:13:20,500 --> 00:13:22,900
And then we'll check it without 
you needing to run it. 

282
00:13:23,100 --> 00:13:24,600
There were some limitations, for
instance. 

283
00:13:24,600 --> 00:13:27,300
You can do instead nukes. 
Because you can't prove anything

284
00:13:27,300 --> 00:13:30,300
about if any of the coming that 
will be on the sound, but it 

285
00:13:30,300 --> 00:13:33,600
also has some very high learning
curve and that's in my Optics. 

286
00:13:33,600 --> 00:13:37,500
The biggest provender am using 
this widespread, but some of the

287
00:13:37,500 --> 00:13:39,500
practices. 
Some of the lessons we learned 

288
00:13:39,500 --> 00:13:42,000
from that are seeping into other
programming languages. 

289
00:13:42,300 --> 00:13:45,000
I think the appearance of 
lambdas or higher order 

290
00:13:45,000 --> 00:13:48,400
functions in most languages by 
now, or certainly helping to 

291
00:13:48,400 --> 00:13:51,700
bring down the number of Errors.
The fact that we are now talking

292
00:13:51,700 --> 00:13:55,600
in maps and filters and Loops 
that are based on the data. 

293
00:13:55,800 --> 00:13:58,500
Doctor and not on the Primitive.
Operator for instance. 

294
00:13:58,700 --> 00:14:01,400
That's certainly also helping 
we're moving in the right 

295
00:14:01,400 --> 00:14:04,500
direction and also something 
that comes very much from my 

296
00:14:04,500 --> 00:14:07,600
time working with dependent 
types, is my love of the type 

297
00:14:07,600 --> 00:14:09,900
system and the type Checker. 
And you'll see that everywhere 

298
00:14:09,900 --> 00:14:12,600
in the book. 
I relied very heavily on the 

299
00:14:12,600 --> 00:14:15,900
fact that if I've set this as a 
number, I know without checking 

300
00:14:15,900 --> 00:14:18,600
it. 
It's gonna be a number, the more

301
00:14:18,600 --> 00:14:22,300
properties you can put into that
the more you don't have to test 

302
00:14:22,300 --> 00:14:25,500
because it can never fail. 
It's actually in a lot of ways. 

303
00:14:25,700 --> 00:14:28,900
More powerful than tests. 
If you can express the same 

304
00:14:28,900 --> 00:14:32,100
properties. 
Interesting concept, so I'll 

305
00:14:32,100 --> 00:14:34,600
make sure maybe, if you have the
link to your feces, for people 

306
00:14:34,600 --> 00:14:36,200
who are interested to learn more
about this. 

307
00:14:36,200 --> 00:14:38,800
Also, you mentioned that it's 
interesting when you do 

308
00:14:38,800 --> 00:14:41,100
refactoring, that you have to 
understand the strategy of your 

309
00:14:41,100 --> 00:14:44,100
company or your business and you
mention, these are one of the 

310
00:14:44,100 --> 00:14:45,700
components for doing 
refactoring. 

311
00:14:45,700 --> 00:14:49,300
So skills is definitely one but 
they are also culture and tools.

312
00:14:49,300 --> 00:14:51,900
Can you tell us more about these
three components? 

313
00:14:52,300 --> 00:14:56,700
Yeah, the most problems that I 
encounter as a Tell coach or as 

314
00:14:56,700 --> 00:15:00,700
a sort of a demo Ops consultant 
is related to one or more of 

315
00:15:00,700 --> 00:15:02,500
these three. 
It's often a combination of 

316
00:15:02,500 --> 00:15:04,400
them. 
It's when there's something that

317
00:15:04,400 --> 00:15:06,400
you're not doing right? 
Or did you not doing it 

318
00:15:06,400 --> 00:15:08,000
effectively. 
It's almost always because you 

319
00:15:08,000 --> 00:15:10,700
missing the culture of doing it.
Like you don't have permission 

320
00:15:10,700 --> 00:15:13,500
or you don't have funding or 
something like that or you're 

321
00:15:13,500 --> 00:15:16,000
not allowed to reorganize. 
The teams could be a big one and

322
00:15:16,000 --> 00:15:18,100
develops. 
It could be the knowledge that 

323
00:15:18,100 --> 00:15:20,000
you don't have using. 
They don't know that. 

324
00:15:20,000 --> 00:15:23,500
Something is bad or how 
something works or you're doing 

325
00:15:23,500 --> 00:15:26,300
the best that you can. 
But you don't have the Tools to 

326
00:15:26,300 --> 00:15:28,500
do it. 
You don't have the correct thing

327
00:15:28,500 --> 00:15:31,300
to help you do this in an 
efficient manner, which makes it

328
00:15:31,400 --> 00:15:34,400
unfeasible and practice and 
refactoring requires. 

329
00:15:34,400 --> 00:15:36,900
Everything writer cries. 
You have time to do refactoring.

330
00:15:37,100 --> 00:15:40,000
It requires you to have some 
sort of way to do it safely, 

331
00:15:40,000 --> 00:15:43,100
some quality measure, we can't 
do it with our eyes closed. 

332
00:15:43,200 --> 00:15:46,000
Testing is one of those tools 
but it could also be types are 

333
00:15:46,000 --> 00:15:47,600
good. 
Also be Version Control or 

334
00:15:47,600 --> 00:15:50,000
manual testing or 15 other 
things. 

335
00:15:50,200 --> 00:15:52,700
And it also, of course requires 
the skills to know. 

336
00:15:52,800 --> 00:15:55,500
How do I actually do a factory? 
How do I know? 

337
00:15:55,700 --> 00:15:57,700
I'm not just making this code 
worse. 

338
00:15:57,900 --> 00:16:01,300
I've seen a lot of people 
especially young Engineers who 

339
00:16:01,300 --> 00:16:03,800
just want to make the code AS 
compact as possible. 

340
00:16:04,100 --> 00:16:06,700
They think it's really cool if 
they can do something one line. 

341
00:16:06,900 --> 00:16:09,300
And it's like it maybe, but 
that's unreadable. 

342
00:16:09,300 --> 00:16:12,000
I don't even know if it works. 
So it's definitely worse for 

343
00:16:12,000 --> 00:16:14,200
teamwork. 
So, we're factoring a sort of, a

344
00:16:14,200 --> 00:16:16,500
sophisticated Balancing Act 
between those three. 

345
00:16:17,300 --> 00:16:19,800
So you mentioned about pop 
culture of getting permission to

346
00:16:19,800 --> 00:16:22,800
do it, and all that. 
There may be a lot of software 

347
00:16:22,800 --> 00:16:25,300
Engineers would listen to this 
that are starting their careers 

348
00:16:25,300 --> 00:16:26,800
or there. 
They're kind of like Junior. 

349
00:16:27,100 --> 00:16:28,800
What will be your advice to 
them? 

350
00:16:28,800 --> 00:16:31,300
Because they want to do? 
Good job, of course, like 

351
00:16:31,300 --> 00:16:34,500
producing good coat or maybe 
working with Legacy code. 

352
00:16:34,500 --> 00:16:36,700
Where is just simply difficult 
to work with? 

353
00:16:36,900 --> 00:16:39,500
So what would be your advice to 
them to actually have the 

354
00:16:39,500 --> 00:16:43,200
courage to start refactoring? 
Well, first of all, I've 

355
00:16:43,200 --> 00:16:46,100
recommended the source books 
that I talk about a lot like 

356
00:16:46,100 --> 00:16:47,800
that. 
Modern polish original infection

357
00:16:47,800 --> 00:16:49,600
Burgers up. 
I recommended those to a lot of 

358
00:16:49,608 --> 00:16:53,100
people, what I've often found 
was that it's actually difficult

359
00:16:53,100 --> 00:16:55,400
to get started with. 
It's very difficult to sit down 

360
00:16:55,400 --> 00:16:57,900
and The book and then put it 
into practice. 

361
00:16:58,000 --> 00:17:00,400
Those are far apart. 
And then sort of why I wrote my 

362
00:17:00,400 --> 00:17:04,300
book was to make it more 
accessible and reducing the cost

363
00:17:04,300 --> 00:17:05,800
of learning refactoring and 
least. 

364
00:17:05,800 --> 00:17:09,200
That's my aim, so that you can 
actually start reading my book 

365
00:17:09,200 --> 00:17:12,700
and do some good stuff to your 
code from the next day or the 

366
00:17:12,700 --> 00:17:14,500
same day. 
As you eat something, you don't 

367
00:17:14,500 --> 00:17:17,700
have to spend days mulling it 
over or doing theoretical 

368
00:17:17,700 --> 00:17:20,200
exercises. 
You can practice in the exercise

369
00:17:20,200 --> 00:17:22,700
in the book and then you can do 
it on your own code, immediately

370
00:17:22,700 --> 00:17:25,500
afterwards. 
So already, then reducing the 

371
00:17:25,599 --> 00:17:27,800
The initial cost of learning is 
important. 

372
00:17:27,800 --> 00:17:30,300
I think that's the first step. 
I do need to get started 

373
00:17:30,300 --> 00:17:32,200
somewhere. 
Then the second step you 

374
00:17:32,200 --> 00:17:35,200
mentioned getting the funding to
do it or the time to do it. 

375
00:17:35,500 --> 00:17:37,400
I think if you have an 
organization where it's 

376
00:17:37,408 --> 00:17:40,300
difficult to get funding, I 
think the easiest way to get it 

377
00:17:40,300 --> 00:17:43,100
is probably to do refactoring 
before you start working on a 

378
00:17:43,108 --> 00:17:47,400
task so that you will be like 
well to make this change, I need

379
00:17:47,400 --> 00:17:49,800
to prepare the environment to 
receive it. 

380
00:17:49,900 --> 00:17:52,700
The need to go and make this 
code will written so that I can 

381
00:17:52,700 --> 00:17:55,500
easier make my change the 
problem with doing it. 

382
00:17:55,700 --> 00:17:57,700
Other way where we first do the 
change in. 

383
00:17:57,700 --> 00:18:01,400
Do the refactoring this set in a
lot of places, if your estimated

384
00:18:01,400 --> 00:18:05,200
that the task takes some time 
and then you spend that time 

385
00:18:05,200 --> 00:18:07,500
implementing the feature. 
Maybe you go a little bit over. 

386
00:18:08,000 --> 00:18:10,200
They're not going to give you 
the time to do the refactoring 

387
00:18:10,200 --> 00:18:13,000
as well. 
So it makes more sense to do it 

388
00:18:13,000 --> 00:18:14,900
first. 
And I love this quote that I 

389
00:18:14,908 --> 00:18:18,000
have in the book, also by Kent 
Beck where he says first, make 

390
00:18:18,000 --> 00:18:20,500
the change easy, then make the 
easy to change. 

391
00:18:21,200 --> 00:18:24,000
Wow, I love that quote as well. 
And you mentioned that it should

392
00:18:24,000 --> 00:18:26,800
be part of our daily routine as 
a software engineer. 

393
00:18:27,000 --> 00:18:28,600
So how would this routine look 
like? 

394
00:18:28,600 --> 00:18:32,000
Maybe if you can explain to us? 
Because when we pick up a task, 

395
00:18:32,000 --> 00:18:35,000
for example, we are working on 
but fixing or feature, right? 

396
00:18:35,000 --> 00:18:39,000
So, how should we make this as a
routine I present in the book. 

397
00:18:39,100 --> 00:18:42,000
I think there are six steps to 
the workflow that I recommend 

398
00:18:42,000 --> 00:18:45,000
that people use and it's sort of
built from what I've seen people

399
00:18:45,000 --> 00:18:47,500
go through. 
But it's also not accounting for

400
00:18:47,500 --> 00:18:50,200
the fact that it's probably 
easier to get funding the other 

401
00:18:50,200 --> 00:18:53,000
way around. 
This is from an optimal sort of 

402
00:18:53,100 --> 00:18:56,700
workflow would look like in a 
company that is mature enough to

403
00:18:56,700 --> 00:18:58,800
actually let developers do the 
development. 

404
00:18:58,800 --> 00:19:01,000
The way that they say, the 
reason it should be part of your

405
00:19:01,000 --> 00:19:04,300
daily work is of course that we 
know from all sorts of things, 

406
00:19:04,300 --> 00:19:07,100
lean and devops and everything 
else that smaller batches give 

407
00:19:07,100 --> 00:19:11,200
to a smaller errors and lower 
risks and easier to fix errors. 

408
00:19:11,400 --> 00:19:15,300
So, the more continuously you do
refactoring, the smaller the 

409
00:19:15,300 --> 00:19:18,100
risk that something's going to 
go wrong and you're not doing, 

410
00:19:18,100 --> 00:19:19,900
like, a full two-week 
refactoring. 

411
00:19:19,900 --> 00:19:23,200
That's just bound to go wrong in
everywhere and create merge 

412
00:19:23,200 --> 00:19:25,700
conflicts with everyone and 
everything is going to go bad. 

413
00:19:25,900 --> 00:19:28,200
So we want to do it in small 
batches and that's why the 

414
00:19:28,200 --> 00:19:31,900
workflow is you start by 
experimenting that first? 

415
00:19:32,200 --> 00:19:35,100
A lot of people just start 
coding which I've linked to be 

416
00:19:35,100 --> 00:19:38,200
counterproductive in a lot of 
cases because we don't know what

417
00:19:38,200 --> 00:19:40,300
we have to build. 
Usually the ticket that we get 

418
00:19:40,300 --> 00:19:44,200
or the task is poorly described 
it maybe even not done by a user

419
00:19:44,200 --> 00:19:46,800
or anything. 
It's just someone has an idea 

420
00:19:46,800 --> 00:19:49,600
and then they put it on paper. 
Maybe they follow sort of the 

421
00:19:49,600 --> 00:19:53,200
Mike Cohen style as Need to or 
something like that, but it's 

422
00:19:53,200 --> 00:19:55,600
still, it's very difficult to 
get a hold of. 

423
00:19:55,800 --> 00:19:58,400
So I recommend people start by 
experimenting with what we call 

424
00:19:58,400 --> 00:20:00,500
a spike where they just write 
some code. 

425
00:20:00,800 --> 00:20:03,500
It's intended to be thrown away.
It's not a production code. 

426
00:20:03,500 --> 00:20:05,700
It's just to figure out is this 
sort of thing. 

427
00:20:05,700 --> 00:20:08,500
What I want to do, we sort of 
eliminate most of the 

428
00:20:08,500 --> 00:20:11,200
uncertainty in this space. 
We maybe send it to the customer

429
00:20:11,200 --> 00:20:13,900
and say, hey, I know this isn't 
looking great, but does it 

430
00:20:13,900 --> 00:20:16,900
function the way that you expect
it to, or maybe, we're also 

431
00:20:16,900 --> 00:20:19,800
marking up some prototype for 
the design as well, just to get 

432
00:20:19,900 --> 00:20:22,000
a feeling. 
So, the First base is experiment

433
00:20:22,000 --> 00:20:25,200
with a spike. 
Then once we have that we 

434
00:20:25,200 --> 00:20:27,100
usually like to write down the 
specification. 

435
00:20:27,100 --> 00:20:30,500
It's just a list of the things 
that we've just agreed on to 

436
00:20:30,500 --> 00:20:34,000
lock something in and say this, 
I have certainty and I know 

437
00:20:34,000 --> 00:20:36,600
these things are true. 
Sometimes we do this. 

438
00:20:36,600 --> 00:20:39,000
If they weren't automated tests 
with something like a behavior 

439
00:20:39,000 --> 00:20:40,900
during development or test 
driven development. 

440
00:20:41,000 --> 00:20:42,300
You will be right down some 
tests. 

441
00:20:42,300 --> 00:20:44,900
And sometimes we just write it 
in the acceptance criteria and 

442
00:20:44,900 --> 00:20:46,700
other times. 
We do other things. 

443
00:20:47,000 --> 00:20:50,000
I don't mind how you do your 
specifications just write down 

444
00:20:50,000 --> 00:20:52,300
what you've tested. 
What your hypotheses were and 

445
00:20:52,300 --> 00:20:54,800
what you now know from the user 
or the reporter. 

446
00:20:55,300 --> 00:20:57,000
And then you start doing the 
code. 

447
00:20:57,100 --> 00:20:59,000
Now, we have the specification. 
So now you can start doing the 

448
00:20:59,000 --> 00:21:00,600
code. 
However, you want to do that. 

449
00:21:00,900 --> 00:21:02,500
Finally. 
You have to go back when the 

450
00:21:02,500 --> 00:21:05,200
thing is done and check against 
the specification, right? 

451
00:21:05,300 --> 00:21:07,700
You have a checklist of the 
things that you should be able 

452
00:21:07,700 --> 00:21:10,300
to do, or you run your test or 
however, you did the 

453
00:21:10,308 --> 00:21:12,100
specification. 
You just check against it to 

454
00:21:12,100 --> 00:21:15,000
make sure that everything is 
good and then you do refactoring

455
00:21:15,000 --> 00:21:17,400
afterwards. 
Because now you have this new 

456
00:21:17,400 --> 00:21:20,000
feature that has been in a state
of flux where you work, moving 

457
00:21:20,000 --> 00:21:22,000
things around you. 
Experimenting. 

458
00:21:22,000 --> 00:21:24,900
Nothing you sure but now that 
you're sure it's a fides, the 

459
00:21:24,900 --> 00:21:26,900
specification. 
Now you can go and say, okay. 

460
00:21:26,900 --> 00:21:30,300
I'm going to make it nice before
I shared with my team because I 

461
00:21:30,300 --> 00:21:33,200
don't want to trip up my team. 
The don't want everyone else to 

462
00:21:33,200 --> 00:21:36,400
be prevented by this thing. 
So you do the refactoring and 

463
00:21:36,400 --> 00:21:39,400
you make it nice and then you 
deliver it into production or to

464
00:21:39,400 --> 00:21:41,400
the main branch or something 
like that. 

465
00:21:41,900 --> 00:21:44,400
Thanks for sharing the workflow.
I think the few key things that 

466
00:21:44,400 --> 00:21:46,900
I pick up there to have a 
specification. 

467
00:21:47,000 --> 00:21:49,500
We have a checklist of things 
that you need to fulfill in 

468
00:21:49,500 --> 00:21:53,800
terms of, maybe the The bug 
fixing and then you test it 

469
00:21:53,800 --> 00:21:56,800
experiment, maybe ask for 
feedback, from users, or from 

470
00:21:56,900 --> 00:22:00,200
Weber that use that feature. 
After you prove that the spec 

471
00:22:00,200 --> 00:22:02,700
works, you do the refractory. 
And again, at the end, you 

472
00:22:02,700 --> 00:22:05,200
proved again that the 
specification are still met. 

473
00:22:05,500 --> 00:22:08,500
So thanks for sharing that look,
Flo the other thing that I pick 

474
00:22:08,500 --> 00:22:11,300
up and I really like this thing.
You mentioned that three maybe 

475
00:22:11,300 --> 00:22:13,600
principles or pillars of 
refactoring. 

476
00:22:13,800 --> 00:22:17,200
So maybe I'll mention it one by 
one improving readability by 

477
00:22:17,200 --> 00:22:20,100
communicating in 10. 
So, what do you mean by this 

478
00:22:20,100 --> 00:22:23,200
communicating? 
In 10, I mean, that the code 

479
00:22:23,200 --> 00:22:26,400
should lead you to a natural 
conclusion, that should be 

480
00:22:26,400 --> 00:22:28,400
accurate with what the code is 
doing. 

481
00:22:28,500 --> 00:22:31,700
It should have good method names
as an easy way to start. 

482
00:22:31,700 --> 00:22:35,200
Give us something a name that 
actually holds a poor example, I

483
00:22:35,200 --> 00:22:38,200
would say is when you have 
comments that somehow go out of 

484
00:22:38,200 --> 00:22:41,700
sync with what the code is 
doing, method names, rarely do 

485
00:22:41,700 --> 00:22:42,500
that. 
Luckily? 

486
00:22:42,500 --> 00:22:44,700
Or when you just give something 
a good variable name or 

487
00:22:44,708 --> 00:22:46,600
something like that. 
You are help me. 

488
00:22:46,700 --> 00:22:50,000
Not having to check a bunch of 
things around it because I could

489
00:22:50,000 --> 00:22:52,600
see, okay. 
This is communicating what its 

490
00:22:52,600 --> 00:22:55,500
intended to do and from my 
experience as well. 

491
00:22:55,500 --> 00:22:57,500
This is also a good reminder for
everyone. 

492
00:22:57,500 --> 00:22:59,200
Right? 
Sometimes the thing that you are

493
00:22:59,200 --> 00:23:02,400
working on is not written by you
in the first place, but it's 

494
00:23:02,400 --> 00:23:04,600
pulley communicated. 
In terms of name in terms of 

495
00:23:04,600 --> 00:23:06,400
intent. 
I think this is also a good 

496
00:23:06,400 --> 00:23:09,200
reminder for us that you should 
not be afraid of changing. 

497
00:23:09,200 --> 00:23:12,300
Even those things that you did 
not write and make it more 

498
00:23:12,300 --> 00:23:15,100
readable, communicating more in 
10, maybe changing the name 

499
00:23:15,100 --> 00:23:18,100
would be the easiest example of 
this bike could be other things,

500
00:23:18,100 --> 00:23:20,800
changing the class names data 
structure, and things like that.

501
00:23:20,900 --> 00:23:21,900
It gets. 
Yeah, exactly. 

502
00:23:21,900 --> 00:23:24,200
Data structures and interesting 
point by because if you have an 

503
00:23:24,200 --> 00:23:27,100
interface with five subclasses, 
then that's also communicating 

504
00:23:27,100 --> 00:23:28,200
to you. 
That it's likely. 

505
00:23:28,200 --> 00:23:29,700
There's going to be a six or 
seven. 

506
00:23:30,000 --> 00:23:33,000
That's also communicating sort 
of an architectural intent 

507
00:23:33,000 --> 00:23:35,100
behind this thing. 
We're expecting this to have 

508
00:23:35,100 --> 00:23:38,000
more subclasses. 
The second one you mentioned 

509
00:23:38,000 --> 00:23:40,200
about the principles of 
refactoring is actually to 

510
00:23:40,200 --> 00:23:43,700
improve maintainability by 
localizing invariance. 

511
00:23:43,800 --> 00:23:46,300
So you mentioned this in the 
beginning, maybe you can explain

512
00:23:46,300 --> 00:23:49,200
Again by localizing invariance. 
What do you mean by that? 

513
00:23:49,600 --> 00:23:52,000
Sure, your abs as I said, And 
when barium is something you 

514
00:23:52,008 --> 00:23:55,200
need to keep in our hints, that 
is true about the system, but 

515
00:23:55,200 --> 00:23:56,900
that the system doesn't know 
about. 

516
00:23:57,100 --> 00:24:00,400
So it's something in the sort of
a meat and layer of programming 

517
00:24:00,600 --> 00:24:02,700
where I know that this property 
always holds. 

518
00:24:02,700 --> 00:24:06,000
So I have to keep trying to make
sure I don't break it because 

519
00:24:06,000 --> 00:24:09,300
then somebody else's code might 
break and the fact that also 

520
00:24:09,300 --> 00:24:12,400
already suggests where it can go
wrong, right with you have two 

521
00:24:12,400 --> 00:24:15,200
different places that rely on 
the same invariant that isn't 

522
00:24:15,200 --> 00:24:18,400
checked anywhere in the code. 
Then I might very easily break 

523
00:24:18,400 --> 00:24:20,400
it in one place and then affect 
another place. 

524
00:24:20,400 --> 00:24:24,200
So we These invariants to have 
the smallest scope possible. 

525
00:24:24,200 --> 00:24:26,200
We want them to be local and 
variance. 

526
00:24:26,200 --> 00:24:29,500
So for instance, only this needs
to be true within this method. 

527
00:24:29,500 --> 00:24:32,300
It's unlikely that I'm going to 
break it because I could see the

528
00:24:32,300 --> 00:24:34,800
whole method. 
Whereas if it's some Global 

529
00:24:34,800 --> 00:24:38,800
field that I know have either a 
1 or a 0, then, you know, 

530
00:24:38,800 --> 00:24:42,000
somebody could go and put a 2 in
it from anywhere in the program 

531
00:24:42,000 --> 00:24:45,400
and I don't have the mental 
capacity to actually look at the

532
00:24:45,400 --> 00:24:48,000
whole code base and see, does 
anyone ever break this 

533
00:24:48,000 --> 00:24:50,500
invariant. 
So we want these to be localized

534
00:24:50,500 --> 00:24:53,200
to one. 
To be a small scope as possible,

535
00:24:53,900 --> 00:24:57,100
which leads us to the third 
principle, which is by doing the

536
00:24:57,100 --> 00:25:00,100
first tool, you should do it 
without affecting any code 

537
00:25:00,100 --> 00:25:03,100
outside our scope. 
So make it a smaller scope as 

538
00:25:03,100 --> 00:25:06,200
much as possible. 
It also means that if we draw a 

539
00:25:06,200 --> 00:25:10,100
line around the code that we 
have access to and we don't know

540
00:25:10,400 --> 00:25:13,300
who is outside of that line. 
That could be anyone if we're 

541
00:25:13,300 --> 00:25:16,600
doing a library than this other 
developers that we're doing the 

542
00:25:16,600 --> 00:25:20,400
front end, then it's the user. 
We cannot affect anyone who is 

543
00:25:20,400 --> 00:25:23,700
not A part of this team or we 
don't own the code. 

544
00:25:23,700 --> 00:25:26,200
That's Coley our code. 
So we can't change the public 

545
00:25:26,200 --> 00:25:28,300
interfaces. 
So it's just defining. 

546
00:25:28,300 --> 00:25:32,000
What is our boundary for change.
Where are we allowed to change 

547
00:25:32,000 --> 00:25:34,200
something? 
And it might be to say where we 

548
00:25:34,200 --> 00:25:36,000
don't have access. 
We're not controlling the 

549
00:25:36,000 --> 00:25:39,100
database so we can't change any 
of the fields in the database, 

550
00:25:39,400 --> 00:25:41,900
but we can change the layer 
right after it. 

551
00:25:41,900 --> 00:25:46,100
Enters our control our boundary.
So it's just saying that anyone 

552
00:25:46,100 --> 00:25:48,300
from outside. 
Our team should not be able to 

553
00:25:48,300 --> 00:25:50,600
see whether we've refactored our
code or not. 

554
00:25:51,600 --> 00:25:54,700
I like that as well. 
So, let's go back to the topic 

555
00:25:54,700 --> 00:25:56,700
of the book, which is five lines
of code. 

556
00:25:56,700 --> 00:25:58,600
The first thing that is 
interesting to me. 

557
00:25:58,600 --> 00:26:02,900
Y5y, not shorter, maybe three or
why not longer, maybe 10. 

558
00:26:03,200 --> 00:26:07,400
So, why particularly 5, I will 
admit that it takes a good 

559
00:26:07,400 --> 00:26:09,800
portion of luck. 
Sometimes to be a gotcher to be 

560
00:26:09,800 --> 00:26:11,600
on the Forefront of doing 
something new. 

561
00:26:11,900 --> 00:26:14,600
And I came up with five lines 
because I was looking at the 

562
00:26:14,600 --> 00:26:18,300
game, they example, the book is 
a 2-D game and so it takes 

563
00:26:18,300 --> 00:26:20,700
exactly five lines to do one 
pass through. 

564
00:26:20,800 --> 00:26:23,100
A 2d array. 
You have two moves to think 

565
00:26:23,100 --> 00:26:25,500
inside with a knife and a return
or something like that. 

566
00:26:25,700 --> 00:26:28,600
I was thinking, it does not make
sense to set. 

567
00:26:28,600 --> 00:26:31,500
The limit lower than I can do a 
pass of the data structure 

568
00:26:31,500 --> 00:26:34,700
because then I have to actually 
split up the two for loops and 

569
00:26:34,700 --> 00:26:38,100
that sort of breaks the intent a
little bit, makes it harder to 

570
00:26:38,100 --> 00:26:39,900
see that we're running through 
this array. 

571
00:26:40,300 --> 00:26:42,800
And I'm also saying in the book 
if you have an another 

572
00:26:42,800 --> 00:26:45,500
fundamental data structure, if 
you're working with 3D arrays or

573
00:26:45,500 --> 00:26:48,800
for the erase, then you should 
probably use a slightly higher 

574
00:26:48,800 --> 00:26:52,600
limit and fitted a little bit. 
But for most cases that I see in

575
00:26:52,600 --> 00:26:55,500
practice five lines seems to be 
a pretty good indicator. 

576
00:26:55,700 --> 00:26:58,800
And I've since learned that 
someone has done a study of how 

577
00:26:58,800 --> 00:27:02,600
many bugs that were in code, 
depending on how many lines, the

578
00:27:02,600 --> 00:27:04,500
method length was, the average 
method. 

579
00:27:04,700 --> 00:27:07,600
It turned out that five and six 
are the lowest number four 

580
00:27:07,600 --> 00:27:09,700
hairs. 
I mean, that's just pure luck. 

581
00:27:10,000 --> 00:27:12,900
I didn't know that when I wrote 
it, but I still think it makes 

582
00:27:12,900 --> 00:27:15,100
intuitive sense. 
And I also think that all the 

583
00:27:15,100 --> 00:27:18,700
advice I give as a coach should 
be intuitively, easy to 

584
00:27:18,700 --> 00:27:21,300
understand. 
Once you are told, and they can 

585
00:27:21,300 --> 00:27:23,600
be hard to come up with the 
idea, but it should be easy when

586
00:27:23,600 --> 00:27:26,800
you handed. 
Why do you think that shot the 

587
00:27:26,800 --> 00:27:29,300
code actually leads to a much 
better color? 

588
00:27:29,500 --> 00:27:32,600
Maybe less box, or is that even 
more readable? 

589
00:27:33,200 --> 00:27:34,700
Yeah. 
I mean, that's a good point and 

590
00:27:34,700 --> 00:27:38,200
a lot of people find that out 
that it may become less readable

591
00:27:38,200 --> 00:27:41,600
actually, by exploding up like 
this 20 line method. 

592
00:27:41,600 --> 00:27:43,300
That had a really nice flow to 
it. 

593
00:27:43,300 --> 00:27:45,600
And now we're cutting it up into
four different things and making

594
00:27:45,600 --> 00:27:48,000
the street. 
We're actually making it harder 

595
00:27:48,000 --> 00:27:50,600
to follow from the start to the 
Finish because you need to go 

596
00:27:50,600 --> 00:27:52,600
through. 
A lot more layers, and that's a 

597
00:27:52,608 --> 00:27:55,500
really accurate point. 
The thing is though, the way 

598
00:27:55,500 --> 00:27:59,100
that I use the methods in the 
book and in practice, also this 

599
00:27:59,100 --> 00:28:02,400
that I let the lines of code 
show me where the method should 

600
00:28:02,400 --> 00:28:05,500
be through blank lines or 
through other structures that I 

601
00:28:05,500 --> 00:28:08,000
described in the book. 
And then I explode that out two 

602
00:28:08,000 --> 00:28:10,000
methods. 
And then I let the methods guide

603
00:28:10,000 --> 00:28:12,900
me to where the classes should 
be through rules, like common 

604
00:28:12,900 --> 00:28:16,500
ethics, or something like that. 
Where I didn't get a much more 

605
00:28:16,500 --> 00:28:20,100
finely detailed hierarchy of 
classes that interact with each 

606
00:28:20,100 --> 00:28:22,100
other. 
That Both actually helps the 

607
00:28:22,100 --> 00:28:24,600
generality. 
Like, I can reuse more things 

608
00:28:24,800 --> 00:28:27,000
but that's not the point at all.
The point is more that I can 

609
00:28:27,000 --> 00:28:29,900
isolate things. 
Then it's an invariant to three 

610
00:28:29,900 --> 00:28:33,100
methods but not the last two, 
then I can make it Clans around 

611
00:28:33,100 --> 00:28:35,700
those three methods, where the 
invariant is isolated. 

612
00:28:35,900 --> 00:28:38,100
So again, localizing the 
invariance. 

613
00:28:38,300 --> 00:28:40,900
So I use the statements to guide
the methods and the methods to 

614
00:28:40,900 --> 00:28:43,800
guide the classes in the class 
is actually to guide the names 

615
00:28:43,800 --> 00:28:46,400
based, but we don't do names 
faces too much in the book. 

616
00:28:46,900 --> 00:28:49,400
So a lot of people actually also
like, throughout my experience 

617
00:28:49,400 --> 00:28:50,600
looking at shortcode. 
Yeah. 

618
00:28:50,600 --> 00:28:51,900
Yeah. 
It's nice neat. 

619
00:28:51,900 --> 00:28:54,300
But sometimes some people 
complain is hard to trace, 

620
00:28:54,300 --> 00:28:57,400
especially if they don't use a 
proper tool, if they don't use 

621
00:28:57,400 --> 00:28:59,600
proper ID. 
Maybe they just use text. 

622
00:28:59,600 --> 00:29:01,200
I did, of course. 
This will be cumbersome. 

623
00:29:01,200 --> 00:29:02,800
Right? 
Where you have to navigate 

624
00:29:02,800 --> 00:29:05,900
across multiple functions. 
Any advice for those people. 

625
00:29:06,700 --> 00:29:09,600
I mean, I'm just using visual 
studio code and anything that 

626
00:29:09,600 --> 00:29:12,500
hasn't F12 or something that 
jumps to the definition of a 

627
00:29:12,500 --> 00:29:14,300
something. 
We'll just it really doesn't 

628
00:29:14,300 --> 00:29:17,300
turn out to be a big problem. 
If you do have an editor, that's

629
00:29:17,300 --> 00:29:20,400
not very smart. 
Then my old advice back when I 

630
00:29:20,400 --> 00:29:23,100
was On seems like that. 
I said that every time you go 

631
00:29:23,100 --> 00:29:26,300
looking for a method, you should
swap it with the one right above

632
00:29:26,300 --> 00:29:28,900
it so that it wobbles up to the 
top of the file. 

633
00:29:29,100 --> 00:29:32,100
And then the things you're 
looking for, most often will be 

634
00:29:32,100 --> 00:29:34,900
at the top of the file and other
approach that does. 

635
00:29:34,900 --> 00:29:38,400
The same thing, is based on the 
book algorithms to live by just 

636
00:29:38,400 --> 00:29:41,100
every time you go look for 
something, put it on top sort of

637
00:29:41,100 --> 00:29:42,800
like a stack. 
You just take it out from 

638
00:29:42,800 --> 00:29:45,400
anywhere and look from the top, 
because turns out we look for 

639
00:29:45,400 --> 00:29:49,300
the same things often and some 
things we look for only ones 

640
00:29:49,300 --> 00:29:52,700
ever and they'll just go The 
bottom of the file, so it's the 

641
00:29:52,700 --> 00:29:55,900
same idea but things that you're
looking for often higher in the 

642
00:29:55,908 --> 00:29:59,900
file, but really just use an 
editor that has the pilot. 

643
00:29:59,900 --> 00:30:03,400
He's interesting approach. 
So you also mention that to 

644
00:30:03,400 --> 00:30:06,100
important architectural, 
refactoring for people. 

645
00:30:06,100 --> 00:30:08,600
I think this is quite important 
in my opinion, as well. 

646
00:30:08,900 --> 00:30:11,700
So to architectural refactoring,
whenever we want to make it 

647
00:30:11,700 --> 00:30:14,400
either like short concise or 
even better in terms of 

648
00:30:14,400 --> 00:30:16,900
maintainability, right? 
The facilities about favoring 

649
00:30:16,900 --> 00:30:20,400
composition over inheritance. 
This was also mentioned in one 

650
00:30:20,400 --> 00:30:22,100
of the books. 
Oh, I forget what is the title? 

651
00:30:22,400 --> 00:30:25,000
But can you tell us more? 
Why not inheritance? 

652
00:30:25,000 --> 00:30:28,000
Why composition? 
Yeah, so the gang of four book 

653
00:30:28,000 --> 00:30:31,600
or design patterns as it's 
called it was the first book 

654
00:30:31,600 --> 00:30:34,300
that sort of introduced design 
patterns in a large way. 

655
00:30:34,300 --> 00:30:36,100
I don't know what they may have 
existed before. 

656
00:30:36,100 --> 00:30:37,700
Then. 
I was in the programmer, but 

657
00:30:37,700 --> 00:30:40,400
they were sort of the pioneers 
of design patterns where they 

658
00:30:40,400 --> 00:30:42,200
were like we see these General 
problems. 

659
00:30:42,200 --> 00:30:45,700
Begin and again, and there is a 
right solution to solve this 

660
00:30:45,700 --> 00:30:48,500
specific thing and then they 
wrote down the constraints that 

661
00:30:48,500 --> 00:30:50,600
were necessary and then they 
wrote down the solution, which 

662
00:30:50,600 --> 00:30:53,500
is Amazing. 
It's a great way to solve a 

663
00:30:53,500 --> 00:30:56,200
bunch of problems. 
The thing is though, in my 

664
00:30:56,200 --> 00:30:59,800
opinion, or my view design 
patterns, were mostly to improve

665
00:30:59,800 --> 00:31:02,400
the architecture of a 
specification. 

666
00:31:02,500 --> 00:31:03,800
At least. 
I think that was part of the 

667
00:31:03,800 --> 00:31:05,500
idea. 
You could see these things in 

668
00:31:05,500 --> 00:31:08,200
the specifying paste, and then 
you could improve them already 

669
00:31:08,200 --> 00:31:10,600
didn't and then you wouldn't 
have the problem when it came to

670
00:31:10,600 --> 00:31:13,200
the software. 
The thing is, those things 

671
00:31:13,200 --> 00:31:15,600
change a lot. 
You can't just write up a thing.

672
00:31:15,600 --> 00:31:17,400
And then it just works the way 
you intended. 

673
00:31:17,400 --> 00:31:19,800
It changes throughout the 
lifetime of the software and 

674
00:31:19,800 --> 00:31:22,000
then refactoring. 
Alms in this is the same thick 

675
00:31:22,000 --> 00:31:25,200
introducing those patterns in a 
way that doesn't break the 

676
00:31:25,200 --> 00:31:27,100
system. 
We've already built and in a way

677
00:31:27,100 --> 00:31:29,100
where we don't need to predict 
anything in the future. 

678
00:31:29,100 --> 00:31:31,800
I don't know where their 
variability points are going to 

679
00:31:31,800 --> 00:31:35,300
be at this scope, but I can see 
it after work with a 42 years. 

680
00:31:35,500 --> 00:31:37,500
I know where I tend to do move 
changes. 

681
00:31:37,900 --> 00:31:41,000
So, the thing is with the 
inheritance, this exactly the in

682
00:31:41,000 --> 00:31:43,700
very important that I had 
before, when you have one 

683
00:31:43,700 --> 00:31:47,100
superclass and you have two 
subclasses, these two subclasses

684
00:31:47,100 --> 00:31:49,300
now. 
Share a common invariant through

685
00:31:49,300 --> 00:31:52,400
the superclass. 
You have actually created an 

686
00:31:52,400 --> 00:31:55,600
invariant that goes across two 
things that you can't possibly 

687
00:31:55,600 --> 00:31:58,700
do at the same time. 
It just makes them dependent on 

688
00:31:58,700 --> 00:32:00,500
each other and changing one 
things. 

689
00:32:00,500 --> 00:32:02,600
Interface means you have to 
change the super Glenda's 

690
00:32:02,600 --> 00:32:04,400
interface, and then you have to 
achieve other one. 

691
00:32:04,700 --> 00:32:05,800
What do you know about the other
one? 

692
00:32:05,800 --> 00:32:07,400
The other one might be another 
team, right? 

693
00:32:07,400 --> 00:32:09,900
Then is doing something slightly
different than you don't know 

694
00:32:09,900 --> 00:32:12,000
how to sort of fit that 
specification. 

695
00:32:12,000 --> 00:32:15,400
So, you're creating a coupling 
between these two subclasses and

696
00:32:15,400 --> 00:32:17,400
also between the superclass and 
both of them. 

697
00:32:17,700 --> 00:32:20,600
It's just a very bad practice 
these. 

698
00:32:20,700 --> 00:32:23,600
We extend to strangle us. 
If we don't manage them, very 

699
00:32:23,600 --> 00:32:26,900
strictly. 
There are cases, certainly for 

700
00:32:26,900 --> 00:32:29,700
inheritance, the ruled in the 
books, they never use 

701
00:32:29,700 --> 00:32:33,400
inheritance, but it's because 
it's simpler to remember that 

702
00:32:33,400 --> 00:32:35,700
way. 
It's almost never. 

703
00:32:36,600 --> 00:32:39,600
It seems counterintuitive for 
object-oriented programming 

704
00:32:39,600 --> 00:32:41,300
where the inheritance is 
actually. 

705
00:32:41,300 --> 00:32:44,000
One of the properties of why you
would want to use 

706
00:32:44,000 --> 00:32:46,500
object-oriented. 
This seems counterintuitive to 

707
00:32:46,500 --> 00:32:49,300
me, a lot of examples. 
Also in the books, during our 

708
00:32:49,300 --> 00:32:52,300
University you have shape. 
And then you have Circle and 

709
00:32:52,300 --> 00:32:55,100
triangle, and all that. 
All this seems to say that, 

710
00:32:55,100 --> 00:32:57,900
okay, you should probably use 
inheritance for things that are 

711
00:32:57,900 --> 00:32:59,800
common to each other similar to 
each other. 

712
00:32:59,800 --> 00:33:02,500
Right? 
Well, I think it's a very common

713
00:33:02,500 --> 00:33:06,200
misunderstanding that object in 
object oriented programming, has

714
00:33:06,200 --> 00:33:09,400
to do with physical objects. 
Whereas I have do remember who 

715
00:33:09,400 --> 00:33:12,400
said it but I think the north 
has reiterated, the point in 

716
00:33:12,400 --> 00:33:15,400
some ways talk stood. 
In fact, the idea of an object, 

717
00:33:15,400 --> 00:33:18,500
in an object oriented language, 
this, like a virtual machine, it

718
00:33:18,500 --> 00:33:20,600
can solve a test. 
It's a mess. 

719
00:33:20,700 --> 00:33:24,100
Each passing system where the 
methods are actually the events 

720
00:33:24,100 --> 00:33:27,400
or the messages that it passes 
to other objects that are 

721
00:33:27,400 --> 00:33:29,300
themselves little virtual 
machines. 

722
00:33:29,500 --> 00:33:33,700
So, we tend to think of objects 
much more like people, I have a 

723
00:33:33,700 --> 00:33:37,100
person who knows how to handle 
these specific things, and then 

724
00:33:37,100 --> 00:33:40,400
I can give him tasks that he 
will then solve for me and give 

725
00:33:40,400 --> 00:33:42,200
them back. 
They are much less about 

726
00:33:42,200 --> 00:33:45,000
physical objects are just 
properties of something. 

727
00:33:45,100 --> 00:33:47,600
It's a completely different 
thing in my mind and then 

728
00:33:47,600 --> 00:33:50,400
interfaces, then become 
capabilities of that person. 

729
00:33:50,400 --> 00:33:54,100
Like, Vacations really this 
optic knows how to do the method

730
00:33:54,100 --> 00:33:55,100
M. 
Ok cool. 

731
00:33:55,100 --> 00:33:56,600
He's certified em. 
Cool. 

732
00:33:56,900 --> 00:33:59,500
So it's a different manner for 
but I think it gives better 

733
00:33:59,500 --> 00:34:01,400
design to think about it like 
that. 

734
00:34:01,900 --> 00:34:03,400
Thanks for changing the 
perspective. 

735
00:34:03,400 --> 00:34:06,100
For those people who are still 
into that mindset of objects, 

736
00:34:06,100 --> 00:34:09,000
like physical objects, or maybe 
even like biology where you 

737
00:34:09,000 --> 00:34:10,699
inherit something from your 
parents. 

738
00:34:10,900 --> 00:34:13,600
So thanks for reminding that 
another counterintuitive 

739
00:34:13,699 --> 00:34:16,199
architecture refactoring. 
You mentioned that by changing 

740
00:34:16,199 --> 00:34:18,500
code, right? 
You should do it by doing 

741
00:34:18,500 --> 00:34:21,699
addition. 
Instead of Ian, this is also 

742
00:34:21,699 --> 00:34:24,500
sometimes contain intuitive but 
it's very important principle in

743
00:34:24,500 --> 00:34:26,600
my opinion. 
So can you tell us more about 

744
00:34:26,600 --> 00:34:29,600
this rule? 
When we change code, if we 

745
00:34:29,600 --> 00:34:32,699
modify it, we are again doing 
something risky. 

746
00:34:32,699 --> 00:34:35,400
There is a risk that I'm 
changing this wrong and breaking

747
00:34:35,400 --> 00:34:37,600
something. 
The different approach to that 

748
00:34:37,600 --> 00:34:40,699
entirely is to say, well before 
I go and make a change. 

749
00:34:40,699 --> 00:34:44,500
I'll just take this code and put
it within if/else block where 

750
00:34:44,500 --> 00:34:47,100
it's going to be called, and 
then I'll put my new code in the

751
00:34:47,100 --> 00:34:49,900
else block, maybe even duplicate
the original code make my 

752
00:34:49,900 --> 00:34:52,000
modifications. 
In the else block, but the 

753
00:34:52,000 --> 00:34:55,300
original code is still there. 
It's intact and I can still run 

754
00:34:55,300 --> 00:34:56,800
it through that. 
If block that. 

755
00:34:56,800 --> 00:34:59,800
I have your B just pass, a 
parameter saying with, I want to

756
00:34:59,800 --> 00:35:01,300
run the top one or the bottom 
one. 

757
00:35:01,600 --> 00:35:03,400
Then I still have both pieces of
code. 

758
00:35:03,400 --> 00:35:06,400
I can change between them very 
quickly and that also means I've

759
00:35:06,400 --> 00:35:09,500
only added things to this coat 
that never change the original 

760
00:35:09,500 --> 00:35:13,200
code, no modification of just 
added things, but I've changed 

761
00:35:13,200 --> 00:35:16,500
the functionality through the 
new parameter that I can pass to

762
00:35:16,500 --> 00:35:18,800
run the new code. 
And then when you start doing 

763
00:35:18,800 --> 00:35:22,000
that regularly, you realize that
That it's actually maybe not the

764
00:35:22,000 --> 00:35:23,600
best thing to do this with 
gifts. 

765
00:35:23,800 --> 00:35:26,600
Sometimes it is, you do feature 
toggling, then we're doing it 

766
00:35:26,600 --> 00:35:29,400
exactly like that actually, but 
if we're doing something more 

767
00:35:29,400 --> 00:35:32,600
complicated where we have two 
customers who need to separate 

768
00:35:32,700 --> 00:35:35,500
configurations of this software 
or two separate versions of the 

769
00:35:35,500 --> 00:35:38,100
software, then we'll do it 
probably through a strategy 

770
00:35:38,100 --> 00:35:41,100
pattern from exactly the book we
mentioned before the gang of 

771
00:35:41,100 --> 00:35:43,700
four book strangely pattern, 
which is also something that a 

772
00:35:43,700 --> 00:35:47,000
lot of refactoring and I would 
probably say the most important 

773
00:35:47,000 --> 00:35:50,600
refactoring in the book is about
how to introduce ready. 

774
00:35:50,700 --> 00:35:54,200
The Safeway things taking two 
pieces of code and then making 

775
00:35:54,200 --> 00:35:57,400
and biffed into an interface 
with some sub classes for each 

776
00:35:57,400 --> 00:36:01,500
of the cases and it's super 
powerful and it's very nice and 

777
00:36:01,500 --> 00:36:04,200
it means we can do change by 
modification. 

778
00:36:05,000 --> 00:36:06,800
Also, sometimes you mentioned 
right feature toggling. 

779
00:36:06,800 --> 00:36:10,300
It helps also in terms of a/b 
testing or some kind of rolling 

780
00:36:10,300 --> 00:36:13,100
deployment, where you don't want
to deploy all these changes to 

781
00:36:13,100 --> 00:36:16,200
the people exactly in one way. 
So you could probably also roll 

782
00:36:16,200 --> 00:36:19,100
it back by changing the toggle 
or maybe changing the 

783
00:36:19,100 --> 00:36:22,500
implementation of the interface.
There are so many advantages to 

784
00:36:22,500 --> 00:36:24,700
something like that. 
You can merge your code 

785
00:36:24,700 --> 00:36:27,200
continuously into the brains 
because it's toggle off. 

786
00:36:27,400 --> 00:36:29,700
You can deploy it continuously 
to meet action because it's 

787
00:36:29,700 --> 00:36:32,100
toggle off. 
You can release it as a business

788
00:36:32,100 --> 00:36:34,800
decision right on a timer. 
If you want, you can do it 

789
00:36:34,800 --> 00:36:37,800
during a big conference event or
doing some live thing. 

790
00:36:38,000 --> 00:36:40,600
You can just go and say now the 
code is active and now we have 

791
00:36:40,600 --> 00:36:42,300
this new feature and it's super 
cool. 

792
00:36:42,300 --> 00:36:45,600
And it looks like magic which is
part of what marketing is about.

793
00:36:45,600 --> 00:36:47,600
I think. 
And then you can also build TB 

794
00:36:47,600 --> 00:36:50,200
testing that you say on top and 
you can just keep growing 

795
00:36:50,200 --> 00:36:52,300
something. 
Like that, you don't need to do 

796
00:36:52,300 --> 00:36:53,700
anything. 
You just put things in the 

797
00:36:53,700 --> 00:36:55,600
feature targeting system. 
It figures out, whether it 

798
00:36:55,600 --> 00:36:56,700
works. 
It figures out whether it's 

799
00:36:56,700 --> 00:36:59,400
valuable. 
I mean it can get our base 

800
00:36:59,400 --> 00:37:01,300
fairly sophisticated at that 
point. 

801
00:37:02,000 --> 00:37:04,400
So whenever we add more of 
clothes, obviously, the could 

802
00:37:04,400 --> 00:37:07,300
grows bigger and bigger, right? 
You mentioned also we as a 

803
00:37:07,300 --> 00:37:10,200
developers should have this 
habit of deleting code. 

804
00:37:10,500 --> 00:37:12,500
So why do you think it's 
important for us? 

805
00:37:12,500 --> 00:37:16,700
Not to forget deleting code? 
You said it yourself systems 

806
00:37:16,700 --> 00:37:19,400
tend to grow over time and 
become very complex. 

807
00:37:19,700 --> 00:37:22,500
I don't think we We have a good 
solution at the moment, for how 

808
00:37:22,500 --> 00:37:25,400
to get rid of code. 
It seems that our code bases are

809
00:37:25,400 --> 00:37:28,100
growing and growing. 
It's an active thing to go and 

810
00:37:28,100 --> 00:37:32,200
delete something and it takes 
time, but it seems difficult to 

811
00:37:32,200 --> 00:37:35,100
argue why that's valuable in the
same way. 

812
00:37:35,100 --> 00:37:38,000
That is difficult to argue. 
Why refactoring is valuable 

813
00:37:38,400 --> 00:37:40,000
because people don't understand 
that. 

814
00:37:40,000 --> 00:37:42,000
We're carrying this load on our 
back. 

815
00:37:42,000 --> 00:37:44,000
Every time we need to go and 
check something. 

816
00:37:44,200 --> 00:37:46,600
If I need to check, as I said 
the system before, if there is 

817
00:37:46,600 --> 00:37:49,000
an invariant somewhere. 
I need to check the whole code 

818
00:37:49,000 --> 00:37:50,500
base. 
I can't do it in. 

819
00:37:50,700 --> 00:37:53,100
Most cases because it's growing 
out of control. 

820
00:37:53,400 --> 00:37:56,600
Then I think that's also part of
why microservices, had such a 

821
00:37:56,600 --> 00:37:59,600
huge impact. 
We were making the full quote 

822
00:37:59,600 --> 00:38:01,900
based, in quote. 
We're making that smaller. 

823
00:38:02,000 --> 00:38:04,500
We're making the full core 
basis, this service instead of 

824
00:38:04,500 --> 00:38:08,200
the hole on the left, the way to
sort of get through that is by 

825
00:38:08,200 --> 00:38:11,400
constantly cutting off anything.
That's not pulling its own 

826
00:38:11,400 --> 00:38:13,200
weight, anything that's not 
providing value. 

827
00:38:13,200 --> 00:38:17,500
Whether that's documentation or 
bad tests for actually running 

828
00:38:17,500 --> 00:38:19,400
features. 
Sometimes if I have this 

829
00:38:19,400 --> 00:38:22,600
feature, that's super, Expensive
to maintain, but there are two 

830
00:38:22,600 --> 00:38:25,300
people using it. 
I might just cut that feature 

831
00:38:25,300 --> 00:38:27,700
entirely. 
It's not pulling its own weight 

832
00:38:27,800 --> 00:38:29,400
and it's important to get rid of
that. 

833
00:38:29,400 --> 00:38:32,700
And I think it's a big problem 
right now that we don't have 

834
00:38:32,700 --> 00:38:35,900
that structured way of getting 
rid of old or dead code or very 

835
00:38:35,900 --> 00:38:39,700
underutilized code and it's all 
coming back to my earlier 

836
00:38:39,700 --> 00:38:40,200
argument. 
Right? 

837
00:38:40,200 --> 00:38:43,200
Some people also tend to be 
afraid of deleting other 

838
00:38:43,200 --> 00:38:45,600
people's code. 
Any advice for them. 

839
00:38:46,400 --> 00:38:49,400
I do in the book suggests that 
if you have a legacy system, for

840
00:38:49,400 --> 00:38:52,300
instance, that you actually That
in a different class that you 

841
00:38:52,300 --> 00:38:55,100
can then monitor, how often is 
this actually called? 

842
00:38:55,300 --> 00:38:58,700
And it also helps if you want to
start deleting it yet, the type 

843
00:38:58,700 --> 00:39:01,500
system again, as I said, I love 
that the type system will help 

844
00:39:01,500 --> 00:39:04,200
you find all the occurrences 
where you're calling this and 

845
00:39:04,200 --> 00:39:07,300
redirect them or just to see if 
there are no occurrences of the 

846
00:39:07,300 --> 00:39:10,500
method being called, some 
editors can help you say this, 

847
00:39:10,500 --> 00:39:13,600
private Manson's is not call. 
But if you have a public method,

848
00:39:13,700 --> 00:39:17,100
it can't possibly know whether 
it is called because if you're 

849
00:39:17,100 --> 00:39:19,900
doing a library, how will it 
know if somebody else is calling

850
00:39:19,900 --> 00:39:22,900
it, but if You know that you're 
not doing a library, then editor

851
00:39:22,900 --> 00:39:25,200
won't help you. 
So you have to go in and 

852
00:39:25,200 --> 00:39:28,800
actually work with deleting code
and getting rid of things and I 

853
00:39:28,800 --> 00:39:31,700
do it as much as I can. 
I delete comments. 

854
00:39:31,700 --> 00:39:33,700
I delete anything that looks 
like that code. 

855
00:39:33,900 --> 00:39:36,400
After verifying obviously that 
is not going to break anything. 

856
00:39:36,600 --> 00:39:39,200
I delete all the time and 
hopefully you'll see. 

857
00:39:39,200 --> 00:39:42,100
I will also tell you if you 
delete something wrong, the bill

858
00:39:42,100 --> 00:39:44,900
will fail and you can roll it 
back safely and you always have 

859
00:39:44,900 --> 00:39:47,200
the Version Control. 
Anyway, hopefully everyone is 

860
00:39:47,200 --> 00:39:49,500
doing fish and control by know. 
You meant it. 

861
00:39:49,500 --> 00:39:52,600
Beginning that some people Pen 
tool of simplifying, the code 

862
00:39:52,600 --> 00:39:56,400
into one line, multiple lines, 
or as short as possible, right? 

863
00:39:56,500 --> 00:39:59,700
And you mentioned this as an 
anti patterns, so like over 

864
00:39:59,700 --> 00:40:03,100
optimizing your code or come up 
with a more generic framework or

865
00:40:03,100 --> 00:40:05,800
approach where you think, okay. 
This will be useful in the 

866
00:40:05,808 --> 00:40:07,500
future. 
Can you tell us more white? 

867
00:40:07,500 --> 00:40:09,700
These are the danger things we 
should avoid. 

868
00:40:10,200 --> 00:40:13,200
I have a few things that seem 
natural to people that people 

869
00:40:13,200 --> 00:40:15,700
start doing, but that are 
actually counterproductive and 

870
00:40:15,700 --> 00:40:18,900
one of them as you say, is when 
people try to simplify things so

871
00:40:18,900 --> 00:40:22,600
that they are short in terms. 
Terms of lines of code, which 

872
00:40:22,600 --> 00:40:25,400
doesn't make any sense to me at 
all because it's not actually 

873
00:40:25,400 --> 00:40:28,500
making the code faster, or 
usually not even smaller. 

874
00:40:28,700 --> 00:40:31,700
But some people like it and it 
looks cool and it feel cool 

875
00:40:31,700 --> 00:40:34,500
while doing it and saying, look 
at this code that I came up with

876
00:40:34,500 --> 00:40:36,700
to solve this complex thing. 
You just 30 characters. 

877
00:40:36,700 --> 00:40:39,400
It's amazing. 
It's just not very good for 

878
00:40:39,400 --> 00:40:41,500
teamwork. 
And that's actually where the 

879
00:40:41,500 --> 00:40:44,100
productivity happens and where 
the Practical applications 

880
00:40:44,100 --> 00:40:46,500
happen. 
So optimizing lines of code is 

881
00:40:46,500 --> 00:40:48,800
one of them. 
Then we have, as you also said 

882
00:40:48,800 --> 00:40:51,300
is the generality. 
We also, I want to find this. 

883
00:40:51,600 --> 00:40:53,900
Oh, I have this function itself 
is a specific thing. 

884
00:40:54,000 --> 00:40:57,000
But if I just add these two 
parameters and then structured a

885
00:40:57,000 --> 00:40:59,600
little bit differently. 
I can solve this whole other 

886
00:40:59,600 --> 00:41:01,700
class of problems. 
That is much bigger. 

887
00:41:01,900 --> 00:41:05,400
And that seems like it would be 
valuable because then you don't 

888
00:41:05,400 --> 00:41:08,100
have to do another function next
time we can just call this one 

889
00:41:08,100 --> 00:41:10,800
again. 
The problem is as I said earlier

890
00:41:10,800 --> 00:41:13,100
you haven't validated. 
This is ever going to happen. 

891
00:41:13,100 --> 00:41:14,900
My you don't know that this is 
gonna happen. 

892
00:41:15,200 --> 00:41:17,100
So there's no point in this 
serology. 

893
00:41:17,100 --> 00:41:19,200
It's just something that you 
spent time on. 

894
00:41:19,700 --> 00:41:22,700
That's maybe Ever going to pay 
off and even worse. 

895
00:41:22,700 --> 00:41:25,100
Sometimes it actually prevents 
us from doing some 

896
00:41:25,100 --> 00:41:28,300
transformations to the code 
because it's overly General and 

897
00:41:28,300 --> 00:41:30,600
then you can't simplify it in 
the same way. 

898
00:41:31,000 --> 00:41:33,300
So if I spot that something is 
always being called with the 

899
00:41:33,300 --> 00:41:36,200
same parameters. 
I just remove the perimeter just

900
00:41:36,200 --> 00:41:39,300
in line them simplify the code. 
Sometimes it's much easier to 

901
00:41:39,300 --> 00:41:42,200
work with after that, and you'll
never need that generality. 

902
00:41:42,500 --> 00:41:45,300
Optimization is another one. 
A lot of people like to do, like

903
00:41:45,300 --> 00:41:48,600
people look like shaved off 
point zero two milliseconds and 

904
00:41:48,600 --> 00:41:50,400
it's like, that's cool. 
Why? 

905
00:41:50,800 --> 00:41:53,400
Like, how many hours did you 
spend shaving that off? 

906
00:41:53,500 --> 00:41:56,800
It only took me three hours? 
Okay, cool, but the app takes 5 

907
00:41:56,800 --> 00:41:59,400
Seconds to start off. 
I mean you're doing this thing 

908
00:41:59,400 --> 00:42:02,300
and it feels valuable and that's
the danger of it. 

909
00:42:02,400 --> 00:42:04,000
It feels like you're doing 
something good. 

910
00:42:04,100 --> 00:42:06,800
But in fact, it's not the 
appropriate timing to do. 

911
00:42:06,800 --> 00:42:09,000
So dry is like to the another 
one. 

912
00:42:09,000 --> 00:42:10,900
Then I'm sort of on the fence 
about. 

913
00:42:11,100 --> 00:42:14,000
There are certainly cases for 
dry and like their optimizations

914
00:42:14,000 --> 00:42:16,400
in generality. 
They have their cases, but in a 

915
00:42:16,400 --> 00:42:18,900
lot of cases where we see people
doing it, it's actually not the 

916
00:42:18,900 --> 00:42:22,300
right time to do it because Dry 
is another way to unify. 

917
00:42:22,400 --> 00:42:24,200
So, don't repeat yourself as 
dryer. 

918
00:42:24,300 --> 00:42:27,000
Instead of copying some code. 
It's making a new function, 

919
00:42:27,100 --> 00:42:30,400
generalizing it, and then using 
that into place in the step, but

920
00:42:30,400 --> 00:42:32,200
you've now coupled the two 
places. 

921
00:42:32,500 --> 00:42:35,200
These places now changed 
together that might be 

922
00:42:35,200 --> 00:42:37,900
appropriate, but it might also 
just as well, not be 

923
00:42:37,900 --> 00:42:41,600
appropriate, do not repeat 
yourself is in itself, not 

924
00:42:41,600 --> 00:42:43,700
valuable. 
Unless, you know, that the 

925
00:42:43,700 --> 00:42:47,100
underlying Behavior has to stay 
in sync and sometimes that's 

926
00:42:47,100 --> 00:42:49,300
true. 
But without asking the question,

927
00:42:49,500 --> 00:42:52,200
you can't know. 
Have to stop and think, are 

928
00:42:52,200 --> 00:42:54,600
these places gonna change 
together forever? 

929
00:42:54,900 --> 00:42:58,100
Or is it actually better to have
them be two separate copies of 

930
00:42:58,100 --> 00:43:00,200
the same thing? 
And then when they change that 

931
00:43:00,200 --> 00:43:02,500
sign because they're not related
to each other. 

932
00:43:02,800 --> 00:43:05,100
So those are my four of my 
favorite games. 

933
00:43:05,100 --> 00:43:08,100
I call them to bash on the 
developers do because it feel 

934
00:43:08,100 --> 00:43:11,500
good, but they're just not. 
It's very interesting to listen 

935
00:43:11,500 --> 00:43:14,400
to this perspectives because 
sometimes Engineers, we tend to 

936
00:43:14,400 --> 00:43:17,800
focus on some engineering best 
practices, but I treat some of 

937
00:43:17,800 --> 00:43:20,400
these are content to it in 
practice, especially in team. 

938
00:43:20,500 --> 00:43:22,800
Look like you mentioned, Shadow 
lines of code, maybe with 

939
00:43:22,800 --> 00:43:25,500
cryptic name might be shorter, 
but it's actually are 

940
00:43:25,500 --> 00:43:28,600
counterproductive to teamwork 
and how people understand your 

941
00:43:28,600 --> 00:43:30,500
code may be. 
For the last session. 

942
00:43:30,500 --> 00:43:32,800
You mentioned about Atomic 
changes in the beginning. 

943
00:43:33,100 --> 00:43:36,800
Can you maybe share some of your
favorite refactoring, strategies

944
00:43:36,800 --> 00:43:39,300
or methods for people who wants 
to get started? 

945
00:43:39,300 --> 00:43:41,100
So can you tell us some of your 
favorites? 

946
00:43:41,900 --> 00:43:44,700
Obviously, the classical one is 
extract method. 

947
00:43:44,700 --> 00:43:47,100
I mean, that is that sing we 
build everything on. 

948
00:43:47,100 --> 00:43:48,600
That's the foundation of 
everything. 

949
00:43:48,800 --> 00:43:52,000
If we can't break up methods. 
Do all these things with methods

950
00:43:52,000 --> 00:43:55,400
and generalize unify, you know, 
you can do too many things with 

951
00:43:55,400 --> 00:43:56,900
extract method. 
I really like it. 

952
00:43:57,100 --> 00:44:00,800
It's a stable, the start of my 
favorite or factoring pattern 

953
00:44:00,800 --> 00:44:03,900
has always been and probably 
will always be the replaced type

954
00:44:03,900 --> 00:44:07,100
code with classes because the 
first time you take an enum or 

955
00:44:07,100 --> 00:44:10,300
something like it and the 
replace over classes and see how

956
00:44:10,300 --> 00:44:13,500
all the code just magically just
simplifies, all the ifs. 

957
00:44:13,500 --> 00:44:15,400
Go away all the chicks and 
stuff. 

958
00:44:15,600 --> 00:44:18,900
It's just it's so wonderful and 
it just looks really cool. 

959
00:44:18,900 --> 00:44:21,500
I was mind-blowing. 
Chapter 4. 

960
00:44:21,500 --> 00:44:24,000
It is in my opinion. 
If you don't get the chills, all

961
00:44:24,000 --> 00:44:26,800
reading chapter 4, then maybe 
you're too advanced for the 

962
00:44:26,800 --> 00:44:28,900
book. 
You're already too smart, but 

963
00:44:28,900 --> 00:44:32,000
that's just amazing. 
And as I said, probably strategy

964
00:44:32,000 --> 00:44:35,200
pattern is both more useful, 
more powerful, but I still just 

965
00:44:35,200 --> 00:44:37,300
love the replace type code 
thing. 

966
00:44:37,300 --> 00:44:39,600
I mean, it just has a special 
place in my heart. 

967
00:44:39,900 --> 00:44:41,800
That was when I knew 
refactoring, was light. 

968
00:44:41,800 --> 00:44:44,600
So powerful. 
So, for those of you who listen 

969
00:44:44,600 --> 00:44:47,800
to this and you want to feel the
chill, make sure you read 

970
00:44:47,800 --> 00:44:50,400
chapter 4 of Christians book, 
five lines of code. 

971
00:44:51,000 --> 00:44:54,300
When is it going to be out? 
Actually, it's a great question.

972
00:44:54,300 --> 00:44:56,100
I wish I knew it's in 
production. 

973
00:44:56,100 --> 00:44:58,600
So we have some people checking 
the layout and making sure 

974
00:44:58,600 --> 00:45:01,100
everything looks nice and cool, 
and then they send it to me for 

975
00:45:01,100 --> 00:45:02,500
review. 
And that's a process that we're 

976
00:45:02,500 --> 00:45:03,700
in right now. 
We're reviewing all the 

977
00:45:03,700 --> 00:45:06,000
chapters, making sure 
everything's lined up nicely and

978
00:45:06,000 --> 00:45:09,100
the code looks good on paper and
everything is just good to go. 

979
00:45:09,400 --> 00:45:12,100
I'm hoping the ID, but I'm 
fairly certain, it will be this 

980
00:45:12,100 --> 00:45:14,500
year. 
So the question is, how long 

981
00:45:14,500 --> 00:45:17,300
will we take to review all these
changes Apple? 

982
00:45:17,300 --> 00:45:19,000
Bead, go smooth. 
So Christian. 

983
00:45:19,000 --> 00:45:20,300
Thank you so much for spending 
your time. 

984
00:45:20,500 --> 00:45:22,800
I'm here is pretty unpleasant 
talk and I learned a lot from 

985
00:45:22,800 --> 00:45:24,600
you. 
But before I let you go, I have 

986
00:45:24,600 --> 00:45:27,500
this one last question that I 
normally ask for all my guests, 

987
00:45:27,700 --> 00:45:30,300
which is for you to share your 
tree technical leadership. 

988
00:45:30,300 --> 00:45:32,400
Wisdom in all of us here to 
learn from. 

989
00:45:32,400 --> 00:45:35,200
And maybe also a look at some of
the wisdom that I actually met 

990
00:45:35,200 --> 00:45:37,300
the for us. 
So, can you share us your tree 

991
00:45:37,300 --> 00:45:41,100
technical leadership wisdom. 
So since this is called tekhelet

992
00:45:41,100 --> 00:45:43,200
Journal, I'll talk about how my 
experience is. 

993
00:45:43,200 --> 00:45:45,500
It's actually worse and the 
things that I found out to be 

994
00:45:45,500 --> 00:45:47,100
working for him and I was a 
technique. 

995
00:45:47,400 --> 00:45:50,300
First of all, I would say it's 
about inspirational leadership. 

996
00:45:50,500 --> 00:45:53,500
It's about actually inspiring. 
Your people is much more 

997
00:45:53,500 --> 00:45:55,500
powerful than trying to control 
anything. 

998
00:45:55,800 --> 00:45:59,300
So, now, when I coach technical 
techniques, I usually say that 

999
00:45:59,300 --> 00:46:02,900
the only Power they're getting 
is they can host the talk 20 

1000
00:46:02,900 --> 00:46:06,500
minutes every second week where 
they talk about whatever they 

1001
00:46:06,500 --> 00:46:07,900
want. 
That's their time. 

1002
00:46:08,100 --> 00:46:11,500
But if they're not inspirational
the wasting it, that's the only 

1003
00:46:11,500 --> 00:46:14,100
way they can control anything. 
So we have to sort of start 

1004
00:46:14,100 --> 00:46:16,500
being inspirational. 
They have to start talking about

1005
00:46:16,500 --> 00:46:19,200
things in the right way and 
getting the team excited to do 

1006
00:46:19,200 --> 00:46:21,600
the things that they want. 
Things to go in there, right 

1007
00:46:21,600 --> 00:46:23,500
direction. 
So that's definitely the first 

1008
00:46:23,500 --> 00:46:25,200
one. 
It's very important mental. 

1009
00:46:25,200 --> 00:46:27,500
So what I like about teaching 
all these, these inspiring 

1010
00:46:27,500 --> 00:46:30,900
people and the second one I 
guess is to be humble. 

1011
00:46:31,200 --> 00:46:33,900
We're going to run into 
situations that we can't control

1012
00:46:33,900 --> 00:46:35,300
and that are going to be 
chaotic. 

1013
00:46:35,500 --> 00:46:38,800
They're going to be errors and 
outages and managers to shouting

1014
00:46:38,800 --> 00:46:41,500
and customers are showering and 
developers are crying. 

1015
00:46:41,500 --> 00:46:44,100
They're going to be so many 
different things to handle and 

1016
00:46:44,100 --> 00:46:47,000
just going into this with the 
mindset of I'm going to be the 

1017
00:46:47,000 --> 00:46:49,300
best I can control. 
Everything is not going to help 

1018
00:46:49,300 --> 00:46:50,400
you at all. 
It's much. 

1019
00:46:50,500 --> 00:46:52,700
More helpful to just say. 
Okay, these things are going to 

1020
00:46:52,707 --> 00:46:54,100
happen. 
Some of them are out of my 

1021
00:46:54,100 --> 00:46:57,000
control and just have to weather
that into staying. 

1022
00:46:57,000 --> 00:46:59,200
On course. 
The third thing is sort of the 

1023
00:46:59,200 --> 00:47:02,900
same but in a different ways to 
listen to your people, usually, 

1024
00:47:02,900 --> 00:47:05,700
the people have their own brain,
they're actually smart people 

1025
00:47:05,700 --> 00:47:08,800
and they have great ideas and 
just listening to that and 

1026
00:47:08,800 --> 00:47:11,500
supporting them and helping them
and empowering them. 

1027
00:47:11,700 --> 00:47:15,100
Instead of trying to control the
situation, a lot is just a much 

1028
00:47:15,100 --> 00:47:17,800
better way to work. 
When I was doing one of my 

1029
00:47:17,800 --> 00:47:19,200
favorite assignments, as a 
Technique. 

1030
00:47:19,400 --> 00:47:21,800
We had an issue that we I would 
send that choose to review. 

1031
00:47:21,800 --> 00:47:24,000
We would call the customers Aid.
You see the change? 

1032
00:47:24,000 --> 00:47:25,600
Do you like it? 
This is the way that you want 

1033
00:47:25,600 --> 00:47:28,700
it, and they're taking a short, 
but I also need and then I would

1034
00:47:28,700 --> 00:47:30,800
add something, you know, they're
just push something onto the 

1035
00:47:30,800 --> 00:47:33,200
back, look under the table, 
going around all of the 

1036
00:47:33,200 --> 00:47:35,900
prophecies and everything when I
came to the exactly there. 

1037
00:47:35,900 --> 00:47:38,300
I was like, so what are you guys
working on in there? 

1038
00:47:38,300 --> 00:47:40,500
Like I'm working on this thing 
and this thing and like those 

1039
00:47:40,500 --> 00:47:42,500
are not on the backlog. 
Why are you working on those 

1040
00:47:42,500 --> 00:47:44,400
things? 
I can't see what's happening. 

1041
00:47:44,700 --> 00:47:48,100
What the team is doing? 
And so I said to them that from 

1042
00:47:48,100 --> 00:47:50,300
now on, they could not talk to 
the customer the customer. 

1043
00:47:50,500 --> 00:47:53,500
Only talk to me because they 
don't the developers, would we 

1044
00:47:53,500 --> 00:47:55,600
get into active? 
They wouldn't call the developer

1045
00:47:55,600 --> 00:47:58,600
and say, oh also, I need this 
other thing, interrupting them 

1046
00:47:58,600 --> 00:48:01,700
from the flow that they were in 
focusing on flow is like 

1047
00:48:01,700 --> 00:48:03,800
nothing, right? 
You need your team to be 

1048
00:48:03,800 --> 00:48:05,900
productive as much of the time 
as possible. 

1049
00:48:06,200 --> 00:48:10,500
So I just tend to absorb a lot 
of the waste into my time and in

1050
00:48:10,500 --> 00:48:13,000
the developers could be super 
productive deliver, great 

1051
00:48:13,000 --> 00:48:15,400
software and then that would 
bring down sort of the waste 

1052
00:48:15,400 --> 00:48:17,900
over time. 
So yeah, it's listen to your 

1053
00:48:17,900 --> 00:48:20,300
people and enable them Empower 
them focus on. 

1054
00:48:20,400 --> 00:48:23,000
On them and then the sacrifice 
yourself a little bit. 

1055
00:48:23,000 --> 00:48:25,700
Sometimes that's fine. 
I'm laughing at you. 

1056
00:48:25,700 --> 00:48:27,900
Imagine that story, right? 
Because this is like a 

1057
00:48:27,900 --> 00:48:31,600
psychological thing where you 
show people your good work and 

1058
00:48:31,600 --> 00:48:34,900
they acknowledged but they had 
something like psychologically 

1059
00:48:35,100 --> 00:48:38,200
and you become like okay, maybe 
let's just do this small thing 

1060
00:48:38,200 --> 00:48:40,800
and it will be better. 
So thanks again for reminding 

1061
00:48:40,800 --> 00:48:42,600
this. 
So Christian for people who 

1062
00:48:42,600 --> 00:48:45,000
wants to connect with you, 
whether they want to learn more 

1063
00:48:45,000 --> 00:48:48,300
from you, any blocks any 
website, or any Twitter account 

1064
00:48:48,300 --> 00:48:50,200
or LinkedIn for people to look 
for you. 

1065
00:48:50,800 --> 00:48:53,800
Yes, I am. 
The doctor Lambda on GitHub, on 

1066
00:48:53,800 --> 00:48:56,100
medium, on Twitter. 
Pretty much everywhere 

1067
00:48:56,100 --> 00:48:58,100
developers are MD, doctor 
Lambda. 

1068
00:48:58,400 --> 00:49:00,900
Then I try to reserve that in as
many places as possible. 

1069
00:49:00,900 --> 00:49:03,300
So hit me up. 
I love talking about cook 

1070
00:49:03,300 --> 00:49:07,400
quality and software development
in stuff wasn't aware of that. 

1071
00:49:07,500 --> 00:49:10,100
We could have talked about your 
doctor Lambda thing, but maybe 

1072
00:49:10,100 --> 00:49:11,800
for another episode. 
All right. 

1073
00:49:11,800 --> 00:49:13,600
So thanks Christian. 
Good luck with your book. 

1074
00:49:13,700 --> 00:49:16,600
Looking forward to have it on 
Amazon or somewhere where people

1075
00:49:16,600 --> 00:49:18,300
buy books. 
Yeah. 

1076
00:49:18,500 --> 00:49:23,600
Thanks for having me. 
Thank you for listening to this 

1077
00:49:23,600 --> 00:49:26,200
episode and for staying right 
till the end. 

1078
00:49:26,400 --> 00:49:29,300
If you highly enjoyed, please 
share it with your friends and 

1079
00:49:29,300 --> 00:49:32,700
colleagues who you think would 
also benefit from listening to 

1080
00:49:32,700 --> 00:49:34,900
this episode. 
And if you're new to the 

1081
00:49:34,900 --> 00:49:38,300
podcast, make sure to subscribe 
and leave me your valuable 

1082
00:49:38,300 --> 00:49:41,700
review and feedback. 
It really, really helps me a lot

1083
00:49:41,700 --> 00:49:44,200
in order to grow these podcasts 
better. 

1084
00:49:44,700 --> 00:49:48,000
You can also find the full show 
notes of this conversation on 

1085
00:49:48,000 --> 00:49:51,300
the episode page at technology. 
No, the death website. 

1086
00:49:51,500 --> 00:49:54,800
Including the full transcript 
interesting quotes, and links to

1087
00:49:54,800 --> 00:49:57,700
the resources and mentions from 
the conversation. 

1088
00:49:58,200 --> 00:50:01,100
And lastly make sure to 
subscribe to the show's mailing 

1089
00:50:01,100 --> 00:50:04,300
list on technology. 
No, the deaf to get notified for

1090
00:50:04,300 --> 00:50:07,000
any future episodes. 
Stay tuned for the next 

1091
00:50:07,000 --> 00:50:09,500
technique Journal episode. 
And until then. 

1092
00:50:09,700 --> 00:50:10,300
Goodbye.