1
00:00:00,200 --> 00:00:03,100
Hey, a quick message, for those 
of you who are listening to this

2
00:00:03,100 --> 00:00:07,500
episode on Spotify, I have a 
small favor to ask Spotify. 

3
00:00:07,600 --> 00:00:11,100
Now allows mobile users to rate 
podcasts, I would really 

4
00:00:11,100 --> 00:00:13,500
appreciate it. 
If you can take a quick, pause 

5
00:00:13,500 --> 00:00:16,200
to go to the technique Journal 
podcast page, and leave your 

6
00:00:16,200 --> 00:00:18,900
favorite show. 
Your best rating on Spotify. 

7
00:00:19,300 --> 00:00:21,900
It will help me a lot to get 
this podcast to reach more 

8
00:00:21,900 --> 00:00:24,400
people on the platform. 
Thanks a lot. 

9
00:00:24,900 --> 00:00:29,500
The goal of software is often to
sustain an organization in some 

10
00:00:29,500 --> 00:00:31,500
way. 
It doesn't have to be a private 

11
00:00:31,500 --> 00:00:33,200
Enterprise. 
It might also be a government 

12
00:00:33,200 --> 00:00:36,600
organization or an India, or 
things like that, but the 

13
00:00:36,600 --> 00:00:39,100
software rarely exists, just for
its own sake. 

14
00:00:39,100 --> 00:00:42,900
It always exists to fulfill some
other goals that an organization

15
00:00:42,900 --> 00:00:46,600
has, an organization, invests in
software in order to achieve the

16
00:00:46,608 --> 00:00:48,400
goal. 
And hopefully also to sustain 

17
00:00:48,400 --> 00:00:51,600
itself in helping achieve that 
go to software. 

18
00:00:51,600 --> 00:00:54,200
Is there to sustain the 
organization basically. 

19
00:00:58,900 --> 00:01:01,600
Hey everyone. 
My name is Henry Surya with 

20
00:01:01,600 --> 00:01:05,000
Robin. 
And you're listening to the 

21
00:01:05,000 --> 00:01:08,400
technology you know, podcast the
show where I'll be bringing you 

22
00:01:08,400 --> 00:01:11,600
the greatest technical leaders 
practitioners and thought 

23
00:01:11,600 --> 00:01:15,100
leaders in the industry, who 
discuss about their Journey 

24
00:01:15,300 --> 00:01:19,800
ideas and practices that we all 
can learn and apply to build a 

25
00:01:19,800 --> 00:01:23,400
highly performing technical team
and to make an impact in your 

26
00:01:23,400 --> 00:01:26,600
personal work. 
So let's dive into our Journal. 

27
00:01:31,700 --> 00:01:33,700
Hello, again, my friends and 
listeners. 

28
00:01:34,000 --> 00:01:37,200
Welcome to the tekhelet journal 
podcast the show where you can 

29
00:01:37,200 --> 00:01:40,000
learn about technical leadership
and Excellence from my 

30
00:01:40,000 --> 00:01:43,300
conversations, with great 
thought leaders, and this is 

31
00:01:43,300 --> 00:01:46,500
episode number 89. 
Thank you for tuning in today, 

32
00:01:46,500 --> 00:01:49,500
listening to this episode. 
If this is your first time 

33
00:01:49,500 --> 00:01:53,000
listening to tackle, e-journal, 
subscribe and follow the show on

34
00:01:53,000 --> 00:01:56,000
your podcast app and social 
media on LinkedIn. 

35
00:01:56,000 --> 00:01:59,000
Twitter and Instagram. 
G, if you enjoy listening to the

36
00:01:59,000 --> 00:02:02,100
podcast and would like to 
contribute for future episodes 

37
00:02:02,400 --> 00:02:06,200
support me and this podcast by 
subscribing as a patron at 

38
00:02:06,200 --> 00:02:09,800
technology. 
Not Dev slash Patron as a 

39
00:02:09,800 --> 00:02:12,200
developer. 
Many of you would have seen it 

40
00:02:12,200 --> 00:02:16,000
in your project or when working 
with Legacy software a code 

41
00:02:16,000 --> 00:02:18,400
base. 
That is very complex how to 

42
00:02:18,400 --> 00:02:22,500
trace an understand and is super
difficult to make changes to it.

43
00:02:22,800 --> 00:02:26,600
This kind of code is a code that
doesn't fit in our head and it's

44
00:02:26,600 --> 00:02:30,400
one of the main Reasons that 
software deteriorates and rods 

45
00:02:30,400 --> 00:02:33,400
over the time and thus becomes 
an maintainable. 

46
00:02:33,700 --> 00:02:36,600
So how can we avoid this problem
in our code base? 

47
00:02:37,300 --> 00:02:41,200
My guest for today's episode is 
mocked, Seaman, Mark isn't a 

48
00:02:41,200 --> 00:02:44,200
claim author. 
International speaker are highly

49
00:02:44,200 --> 00:02:47,800
experienced developer and has 
published a number of books and 

50
00:02:47,800 --> 00:02:50,800
courses. 
In this episode, Mark shed, some

51
00:02:50,800 --> 00:02:54,600
insights from his latest book. 
Code that fits in your head on 

52
00:02:54,600 --> 00:02:56,900
how we can write sustainable 
software and man. 

53
00:02:57,000 --> 00:03:00,800
Age, software complexity, Mark, 
first started by sharing the 

54
00:03:00,800 --> 00:03:04,200
reasons why he wrote this book 
and explained why software 

55
00:03:04,200 --> 00:03:06,200
development is actually very 
hard. 

56
00:03:06,500 --> 00:03:09,400
He pointed out the difference 
between software engineering and

57
00:03:09,400 --> 00:03:12,600
other physical engineering, 
disciplines, especially the 

58
00:03:12,600 --> 00:03:16,700
difference on the set of 
constraints Mark, then explained

59
00:03:16,700 --> 00:03:20,000
the importance of writing 
sustainable software, and shared

60
00:03:20,000 --> 00:03:23,900
a unique perspective that code 
is actually a liability instead 

61
00:03:23,900 --> 00:03:26,900
of an asset towards the end mark
shared. 

62
00:03:27,100 --> 00:03:30,600
The rule of seven that he 
Advocates a lot in the book as a

63
00:03:30,600 --> 00:03:33,700
guideline to manage code 
complexity and a few other 

64
00:03:33,700 --> 00:03:37,100
practices that we can use to 
build sustainable software such 

65
00:03:37,100 --> 00:03:40,900
as using checklists, building 
vertical slices X driven 

66
00:03:40,900 --> 00:03:44,100
development and implementing 
command query separation 

67
00:03:44,100 --> 00:03:47,100
pattern. 
I really enjoyed my conversation

68
00:03:47,100 --> 00:03:50,600
with Mark learning from him 
about human brain, shut the 

69
00:03:50,600 --> 00:03:54,000
memory and how to write code 
that could fit in our head 

70
00:03:54,100 --> 00:03:56,200
easier. 
I also love some of the 

71
00:03:56,200 --> 00:03:59,300
practices that At Mark shared in
this episode which are very 

72
00:03:59,300 --> 00:04:02,200
practical and is something that 
we can start applying straight 

73
00:04:02,200 --> 00:04:04,900
away. 
If you also enjoyed this episode

74
00:04:04,900 --> 00:04:07,600
and find it useful, share it 
with your friends and 

75
00:04:07,600 --> 00:04:09,700
colleagues. 
Who may also benefit from 

76
00:04:09,700 --> 00:04:13,100
listening to this episode, leave
a rating and review on your 

77
00:04:13,100 --> 00:04:16,700
podcast app and share some 
comments or feedback about this 

78
00:04:16,700 --> 00:04:20,200
episode on social media. 
It is my ultimate mission to 

79
00:04:20,200 --> 00:04:24,000
make this podcast available to 
more people and I need your help

80
00:04:24,000 --> 00:04:26,400
to support me towards fulfilling
my mission. 

81
00:04:27,100 --> 00:04:29,900
Before we continue to the 
conversation, let's hear some 

82
00:04:29,900 --> 00:04:33,100
words from our sponsor. 
Today's episode is proudly 

83
00:04:33,100 --> 00:04:36,700
sponsored by skills matter. 
The global community and events 

84
00:04:36,700 --> 00:04:39,400
platform. 
With more than 100,000 software 

85
00:04:39,400 --> 00:04:43,100
professionals here members. 
Can organize their learning 

86
00:04:43,100 --> 00:04:45,500
experiences around the 
technology topics. 

87
00:04:45,500 --> 00:04:49,300
They care about most you get 
on-demand access to their latest

88
00:04:49,300 --> 00:04:52,600
content thought, leadership 
insights, as well, as the 

89
00:04:52,600 --> 00:04:56,800
exciting schedule of tech events
running across all time zones. 

90
00:04:57,200 --> 00:05:00,700
So whether the devops our data 
science is your bus or you're a 

91
00:05:00,700 --> 00:05:04,600
fan of functional programming or
all things Cloud, you can make 

92
00:05:04,600 --> 00:05:08,400
real connections with people who
share your interests head on 

93
00:05:08,400 --> 00:05:11,400
over to skills method or calm to
become part of the tech 

94
00:05:11,400 --> 00:05:13,500
community that matters most to 
you. 

95
00:05:13,800 --> 00:05:17,000
It's free to join and you will 
find it easy to keep up with the

96
00:05:17,000 --> 00:05:20,100
latest tech Trends. 
Are you looking for a new cool 

97
00:05:20,100 --> 00:05:21,800
swag? 
Taglit Journal? 

98
00:05:21,800 --> 00:05:25,000
Now offers you some swags that 
you can purchase online? 

99
00:05:25,400 --> 00:05:29,200
These wax are printed on Month 
based on your preference and 

100
00:05:29,200 --> 00:05:31,800
will be delivered safely to you 
all over the world. 

101
00:05:31,800 --> 00:05:35,100
We're shipping is available. 
Check out all the cool swags 

102
00:05:35,100 --> 00:05:38,000
available by visiting 
technology, know that death / 

103
00:05:38,000 --> 00:05:40,400
shop and don't forget to break 
yourself. 

104
00:05:40,500 --> 00:05:46,100
Once you receive any of those 
threats, hello everyone. 

105
00:05:46,100 --> 00:05:49,200
Welcome back to another episode 
of the tech Lejeune our podcast.

106
00:05:49,200 --> 00:05:52,000
Today, I have with me, I guess 
named Mark semen. 

107
00:05:52,200 --> 00:05:54,000
He's based in Denmark 
Copenhagen. 

108
00:05:54,100 --> 00:05:57,300
Mark is actually a well-known 
author and also Publisher. 

109
00:05:57,300 --> 00:06:01,400
A few videos courses on plural 
side and also clean coders. 

110
00:06:01,600 --> 00:06:05,100
He recently published a book 
with a title coat that fits in 

111
00:06:05,100 --> 00:06:06,700
your head. 
So today, we are going to 

112
00:06:06,700 --> 00:06:09,900
discuss a lot about what he 
means by coat that fits in your 

113
00:06:09,900 --> 00:06:12,700
head previously. 
Mark, also authored a book which

114
00:06:12,700 --> 00:06:15,900
is very popular. 
It won the jolt award, which is 

115
00:06:15,900 --> 00:06:19,700
titled, dependency injection. 
So mark is really good to meet 

116
00:06:19,700 --> 00:06:21,700
you today. 
Thank you for spending your time

117
00:06:21,700 --> 00:06:23,700
and looking forward to have a 
chat more about your recent 

118
00:06:23,700 --> 00:06:25,900
book. 
Well, thank you for having me. 

119
00:06:26,700 --> 00:06:29,500
So, maybe in the beginning, if 
you can tell us more about your 

120
00:06:29,500 --> 00:06:32,300
background and maybe turning 
points or highlights in your 

121
00:06:32,300 --> 00:06:34,300
career, all right. 
Okay. 

122
00:06:34,300 --> 00:06:37,800
So I was only nineteen seventy 
and grew up without computers. 

123
00:06:38,000 --> 00:06:40,900
I'm not your typical software 
developer who actually grew up 

124
00:06:40,900 --> 00:06:42,600
with early computers. 
I didn't. 

125
00:06:42,700 --> 00:06:44,900
So I actually didn't think that 
I was going to have anything to 

126
00:06:44,900 --> 00:06:47,200
do with computers. 
I have a degree in economics 

127
00:06:47,200 --> 00:06:50,500
from the University of 
Copenhagen started out actually 

128
00:06:50,500 --> 00:06:53,500
in a career in government and 
then figure out that that was 

129
00:06:53,500 --> 00:06:56,600
really not my Property. 
So I thought that I wanted to do

130
00:06:56,600 --> 00:06:59,300
something else, and I had bought
a computer in order to write 

131
00:06:59,300 --> 00:07:01,400
some of my master thesis and 
stuff like that. 

132
00:07:01,600 --> 00:07:02,900
I thought that was much more 
interesting. 

133
00:07:03,200 --> 00:07:05,800
So I tried to get a job and I T,
and this is back in the 

134
00:07:05,800 --> 00:07:07,800
mid-1990s. 
So, basically, if you could 

135
00:07:07,800 --> 00:07:11,200
spell HTML back, then, you could
get a job 90 which was what 

136
00:07:11,200 --> 00:07:13,300
happened. 
I actually started out as being 

137
00:07:13,300 --> 00:07:15,000
just your normal IT, 
professional. 

138
00:07:15,000 --> 00:07:17,400
And then because I could spell 
HTML actually written a little 

139
00:07:17,400 --> 00:07:19,300
bit of HTML. 
I actually got the job of being 

140
00:07:19,300 --> 00:07:22,200
the company's first wit Master 
because no one else knew how to 

141
00:07:22,200 --> 00:07:24,100
do that. 
It started out really as a niche

142
00:07:24,100 --> 00:07:24,800
thing. 
Back then. 

143
00:07:24,800 --> 00:07:27,400
And then I discovered, I don't 
really want to be an IT problem.

144
00:07:27,600 --> 00:07:29,600
I thought it's all quite a bit 
of a much more interesting. 

145
00:07:29,900 --> 00:07:31,900
I had written it a bit of code 
before that. 

146
00:07:32,000 --> 00:07:34,800
So I got myself another job as a
software developer. 

147
00:07:34,800 --> 00:07:37,900
And then, I basically never 
looked back since then, thank 

148
00:07:37,900 --> 00:07:39,700
you for sharing your story. 
I think it's kind of like, 

149
00:07:39,700 --> 00:07:42,200
interesting, right? 
You started from the government.

150
00:07:42,200 --> 00:07:46,400
You figure out HTML quite a few 
of us, probably started as a web

151
00:07:46,400 --> 00:07:49,400
developer, and then moving onto 
as a software developer in 

152
00:07:49,400 --> 00:07:51,800
general. 
So you recently published a book

153
00:07:51,800 --> 00:07:54,200
titled code that fits in your 
head, I assume. 

154
00:07:54,300 --> 00:07:57,500
That code that we wrote is 
sometimes too big too complex. 

155
00:07:57,700 --> 00:08:01,100
Is that something that you're 
trying to suggest by writing 

156
00:08:01,100 --> 00:08:02,800
this book? 
Or is there any kind of problem 

157
00:08:02,800 --> 00:08:05,900
that you see that you try to 
tackle by writing this book? 

158
00:08:06,700 --> 00:08:10,000
Well, so the book actually 
started out more as a catalog of

159
00:08:10,000 --> 00:08:13,400
software development software, 
engineering heuristics, because 

160
00:08:13,400 --> 00:08:16,000
I spend a lot of time coaching 
various different software 

161
00:08:16,000 --> 00:08:19,300
development teams over the last 
decade or more. 

162
00:08:19,600 --> 00:08:22,500
I discovered that there were 
certain explanation and certain 

163
00:08:22,500 --> 00:08:24,200
rules of thumb that people kept 
asking. 

164
00:08:24,400 --> 00:08:27,200
Me the same questions basically 
and I kept giving them the same 

165
00:08:27,200 --> 00:08:30,100
answer, so I thought. 
Well, okay, there's actually a 

166
00:08:30,200 --> 00:08:34,100
catalog of things here ideas. 
Some of them have learned from 

167
00:08:34,100 --> 00:08:36,700
other sources and some of them 
are sort of figure out by 

168
00:08:36,700 --> 00:08:38,400
myself. 
So I thought it's probably 

169
00:08:38,400 --> 00:08:41,100
worthwhile to connect all of 
those things but we also need a 

170
00:08:41,100 --> 00:08:44,200
little bit of a backbone, a 
ceases to put a lot of those 

171
00:08:44,200 --> 00:08:46,600
legs together. 
And particularly with the things

172
00:08:46,600 --> 00:08:48,800
that I've tried to figure out 
myself. 

173
00:08:49,100 --> 00:08:52,000
I've been thinking now for quite
a few years, that one of the 

174
00:08:52,000 --> 00:08:55,300
things that make software 
development cult is that one 

175
00:08:55,300 --> 00:08:58,200
thing is writing the code, but 
as Martin Fowler says any fool, 

176
00:08:58,200 --> 00:09:00,000
could write code that a computer
can understand. 

177
00:09:00,200 --> 00:09:02,400
Good progress, write code that 
people can understand. 

178
00:09:02,600 --> 00:09:04,700
That's from his book 
refactoring. 

179
00:09:05,000 --> 00:09:07,500
And that interested me quite a 
bit because I think what makes 

180
00:09:07,500 --> 00:09:10,200
software development hard, it is
sometimes writing the code is 

181
00:09:10,200 --> 00:09:12,900
difficult, but it's more the 
fact that you have to go back 

182
00:09:12,900 --> 00:09:15,700
and read what was already 
written, and try to understand 

183
00:09:15,700 --> 00:09:18,100
what was the purpose of it, and 
why was it written in that way 

184
00:09:18,300 --> 00:09:21,700
was actually doing and where can
I insert some new Behavior into 

185
00:09:21,700 --> 00:09:24,200
the existing code? 
So we spend much more time 

186
00:09:24,300 --> 00:09:26,000
Encode. 
And we actually spent writing 

187
00:09:26,000 --> 00:09:29,600
code and I have this thesis that
runs through the book bed, one 

188
00:09:29,600 --> 00:09:33,000
of the reasons why we are having
trouble reading code, is that 

189
00:09:33,000 --> 00:09:35,600
the human brain has certain 
cognitive constraints? 

190
00:09:35,900 --> 00:09:38,800
There is just so much working 
memory that the brain actually 

191
00:09:38,800 --> 00:09:41,900
has and it's quite limited. 
On the other hand, computer has 

192
00:09:41,900 --> 00:09:44,300
a completely different way that 
its memory works. 

193
00:09:44,600 --> 00:09:47,200
So if you only take into 
account, the computer's memory 

194
00:09:47,400 --> 00:09:49,800
computer can jog or 10,000 
Global variables. 

195
00:09:49,800 --> 00:09:52,700
If you wanted to, there's a 
famous case with Toyota. 

196
00:09:53,000 --> 00:09:56,000
If you look up, something called
the Unintended acceleration bug.

197
00:09:56,200 --> 00:09:59,200
They figured out that maybe they
actually had about 10,000 Global

198
00:09:59,200 --> 00:10:01,700
variables in the code that ran 
the car. 

199
00:10:02,000 --> 00:10:04,800
Well, okay, so I'm just guessing
here but basically the computer 

200
00:10:04,800 --> 00:10:08,500
can easily juggle ten thousand 
things at the same time and the 

201
00:10:08,500 --> 00:10:11,300
human brain can juggle maybe six
or seven things. 

202
00:10:11,600 --> 00:10:14,800
So the guiding principle then 
becomes to see if you can write 

203
00:10:14,800 --> 00:10:18,000
code that takes into account, 
not the memory little bit of the

204
00:10:18,000 --> 00:10:20,100
computer but the memory limit of
the reader. 

205
00:10:20,400 --> 00:10:23,000
So that's basically the idea and
that's why the book is called 

206
00:10:23,000 --> 00:10:25,700
coat that fits in your head. 
I'm sure that almost all the 

207
00:10:25,708 --> 00:10:29,000
developers here the listeners 
me, myself included, we have 

208
00:10:29,000 --> 00:10:32,300
seen code that probably cannot 
fit in our head first. 

209
00:10:32,300 --> 00:10:34,800
It's like, it's too big. 
These either too many lines of 

210
00:10:34,800 --> 00:10:38,400
code in one class, for example, 
one function, or just too many 

211
00:10:38,400 --> 00:10:40,500
variables or too many things in 
one go. 

212
00:10:40,700 --> 00:10:43,100
And then also at the same time 
sometimes you have to jump into 

213
00:10:43,100 --> 00:10:46,100
multiple files in order to get 
the full picture of certain 

214
00:10:46,100 --> 00:10:48,200
things. 
I think we all have been there 

215
00:10:48,200 --> 00:10:50,000
and I can see this is a real 
problem. 

216
00:10:50,200 --> 00:10:52,700
And when you mention about human
memory limit, I think that 

217
00:10:52,700 --> 00:10:55,800
speaks why that sometimes We 
struggle to read the code. 

218
00:10:55,900 --> 00:10:58,200
You mentioned that software 
development is hard. 

219
00:10:58,500 --> 00:11:01,000
Most people predominantly from 
the business side of the product

220
00:11:01,000 --> 00:11:02,400
side. 
They will think that writing 

221
00:11:02,400 --> 00:11:04,200
software is easy for software 
Engineers. 

222
00:11:04,200 --> 00:11:06,400
Sometimes we think it's not 
really not that easy. 

223
00:11:06,800 --> 00:11:08,600
Why do you think there's this 
mismatch? 

224
00:11:08,600 --> 00:11:11,300
Like when you say software is 
hard, can you explain a little 

225
00:11:11,300 --> 00:11:13,500
bit more? 
Why is it really difficult? 

226
00:11:14,100 --> 00:11:18,000
I think, complexity grows 
exponentially with software. 

227
00:11:18,000 --> 00:11:20,500
So writing something like hello 
world is not difficult. 

228
00:11:20,500 --> 00:11:23,300
You know, most people can do 
that getting started with things

229
00:11:23,300 --> 00:11:25,900
that are little bit more. 
Vacated than that is again 

230
00:11:25,900 --> 00:11:29,100
something that most people can 
learn, that's one thing that 

231
00:11:29,100 --> 00:11:31,500
might influence, the way that 
people from the outside. 

232
00:11:31,500 --> 00:11:34,200
Look at the industry, they say, 
well it's easy to get started. 

233
00:11:34,200 --> 00:11:37,400
So why is it so hard? 
And you see this very often in 

234
00:11:37,400 --> 00:11:40,300
projects development software? 
The start from scratch, from 

235
00:11:40,300 --> 00:11:43,800
Greenfield, the first couple of 
months things actually go pretty

236
00:11:43,800 --> 00:11:47,600
well and developers move at a 
good pace and then as time goes 

237
00:11:47,600 --> 00:11:50,200
by things starts to be slower 
and slower. 

238
00:11:50,400 --> 00:11:53,300
One problem with the other 
stakeholders is that often they 

239
00:11:53,300 --> 00:11:56,100
discovered That velocity 
decreases. 

240
00:11:56,100 --> 00:11:58,700
They discover that too late and 
then they start to complain 

241
00:11:58,700 --> 00:12:00,000
about why I say everything 
going. 

242
00:12:00,000 --> 00:12:02,500
So slow with the developers, 
must be lazy, or something like 

243
00:12:02,500 --> 00:12:04,700
that, you often get that sort of
response. 

244
00:12:04,900 --> 00:12:07,600
So I think there's a problem 
from the outside is that first 

245
00:12:07,600 --> 00:12:10,500
of all, you have this sort of 
exponential growth of complexity

246
00:12:10,500 --> 00:12:12,800
as time goes by. 
If you don't do anything to 

247
00:12:12,800 --> 00:12:15,500
manage that complexity, that's 
one thing and I think another 

248
00:12:15,500 --> 00:12:18,900
thing is that there is a 
disconnect between how easy it 

249
00:12:18,900 --> 00:12:21,700
is to formulate a problem and 
then how difficult it actually 

250
00:12:21,700 --> 00:12:24,600
is to implement code. 
So there are things Is that are 

251
00:12:24,600 --> 00:12:28,300
difficult right there, still a 
Frontier where people are trying

252
00:12:28,300 --> 00:12:31,300
to figure out how to redo all 
sorts of advanced. 

253
00:12:31,300 --> 00:12:33,900
Artificial intelligence, 
whatever people call it these 

254
00:12:33,900 --> 00:12:36,700
days, there's still things that 
are hard to do. 

255
00:12:36,900 --> 00:12:40,600
There's this famous XKCD comic 
where they say something like, 

256
00:12:40,900 --> 00:12:44,500
someone comes by and starts 
giving the software developer a 

257
00:12:44,500 --> 00:12:46,500
set of requirements. 
The person said, that's the 

258
00:12:46,500 --> 00:12:49,300
stakeholder, the stakeholder 
says, we need our application to

259
00:12:49,300 --> 00:12:54,000
be able to identify, if a photo 
was taken in a national park and

260
00:12:54,000 --> 00:12:55,300
then The developer says, oh, 
that's easy. 

261
00:12:55,300 --> 00:12:58,700
We just look at the coordinates 
of the metadata on the phone or 

262
00:12:58,700 --> 00:13:01,000
the photo and correlate that 
with the national park, that's 

263
00:13:01,000 --> 00:13:02,500
easy. 
And then tag it. 

264
00:13:02,500 --> 00:13:05,200
If the picture contains a bird 
and then the program I says, 

265
00:13:05,300 --> 00:13:07,800
okay, I'm going to need a 
research Grant and 10 developers

266
00:13:07,800 --> 00:13:10,900
in 10 years because that is as 
easy to say. 

267
00:13:11,000 --> 00:13:14,500
But it's an order of magnitude 
more difficult to actually 

268
00:13:14,500 --> 00:13:17,400
Implement a feature like that. 
So we have this disconnect as 

269
00:13:17,400 --> 00:13:20,500
well where people who don't have
the technical insight there 

270
00:13:20,500 --> 00:13:23,400
often get completely surprised 
by how difficult the hard things

271
00:13:23,400 --> 00:13:25,700
are. 
Even get surprised by that 

272
00:13:25,700 --> 00:13:28,300
ourselves. 
Sometimes we get a requirement 

273
00:13:28,300 --> 00:13:30,600
and we say, oh yeah, I could do 
that. 

274
00:13:30,700 --> 00:13:33,600
I could do that in the week and 
then when you start diving into 

275
00:13:33,600 --> 00:13:35,500
it, you figure out. 
Oh, this is actually really 

276
00:13:35,500 --> 00:13:37,000
difficult. 
I have no idea. 

277
00:13:37,100 --> 00:13:39,300
I thought it was going to be 
easy, I don't know. 

278
00:13:39,800 --> 00:13:42,700
It's going to be really hard so 
that happens a lot in software 

279
00:13:42,700 --> 00:13:45,000
development as well. 
So I'm paraphrasing and I 

280
00:13:45,008 --> 00:13:47,600
apologize that I can't remember 
what the source was. 

281
00:13:47,800 --> 00:13:51,000
But someone said something like,
you know, software development 

282
00:13:51,100 --> 00:13:54,100
copying things is free. 
We do now. 

283
00:13:54,200 --> 00:13:57,200
New things every time because we
never do the same thing in 

284
00:13:57,200 --> 00:13:59,900
Industry. 
You may build thousand copies of

285
00:13:59,900 --> 00:14:04,000
the same car because there's 
actually a cost associated with 

286
00:14:04,000 --> 00:14:07,700
creating a copy, but there's no 
cost associated with creating a 

287
00:14:07,708 --> 00:14:11,000
copy and software. 
So, we never actually spent much

288
00:14:11,000 --> 00:14:15,000
time creating copies, everything
we do is always produce a new 

289
00:14:15,000 --> 00:14:17,000
things. 
When we're producing new things,

290
00:14:17,000 --> 00:14:19,600
it also means we do things. 
We've never done before. 

291
00:14:20,000 --> 00:14:23,400
So we are constantly engaged 
with doing things that we have 

292
00:14:23,400 --> 00:14:25,100
never done before. 
Sometimes it looks like 

293
00:14:25,100 --> 00:14:27,400
something we've done before we 
have some experience. 

294
00:14:27,600 --> 00:14:30,100
But we are always doing new 
things because if we weren't, we

295
00:14:30,100 --> 00:14:32,500
could just have copied what you 
already have four created 

296
00:14:32,500 --> 00:14:35,400
earlier on some development 
organizations, call the 

297
00:14:35,400 --> 00:14:38,700
development part, they called 
R&D research and development. 

298
00:14:38,900 --> 00:14:41,100
And I think that's actually not 
too far from the truth. 

299
00:14:41,400 --> 00:14:44,300
We should probably recognize 
more than most software 

300
00:14:44,300 --> 00:14:47,700
development organizations are 
actually research departments. 

301
00:14:47,900 --> 00:14:51,100
That might actually go a bit of 
a way towards setting 

302
00:14:51,100 --> 00:14:52,600
expectations. 
A little bit better. 

303
00:14:52,900 --> 00:14:55,600
That last part is Thing that 
just occurred to me right now. 

304
00:14:55,600 --> 00:14:57,800
So I haven't really thought that
through whether that's a good 

305
00:14:57,800 --> 00:14:59,500
idea or not. 
But you know, that's that's at 

306
00:14:59,500 --> 00:15:03,000
least worth thinking about it. 
I think, in your book, the first

307
00:15:03,000 --> 00:15:05,800
few chapters you are talking 
about the metaphors of software 

308
00:15:05,800 --> 00:15:08,400
engineering forces, the 
physical, or mechanical 

309
00:15:08,400 --> 00:15:10,500
engineering, which has been 
around for quite some time. 

310
00:15:10,800 --> 00:15:13,300
And you mentioned that software 
engineering, cannot be treated 

311
00:15:13,300 --> 00:15:16,200
similar to building a house. 
Can you explain a little bit? 

312
00:15:16,200 --> 00:15:19,000
Why is of engineering is 
different than the other types 

313
00:15:19,000 --> 00:15:20,500
of engineering. 
Yeah. 

314
00:15:20,600 --> 00:15:24,000
Okay so engineering is always 
about producing. 

315
00:15:24,200 --> 00:15:26,700
Outcome decide I'll come within 
a set of constraints. 

316
00:15:27,100 --> 00:15:29,900
I think in the sense that we 
could talk about software 

317
00:15:29,900 --> 00:15:31,500
engineering, that's true as 
well. 

318
00:15:31,500 --> 00:15:33,000
But let's talk about the other 
things. 

319
00:15:33,000 --> 00:15:36,300
First, you asked about the very 
common metaphor for software 

320
00:15:36,300 --> 00:15:38,000
development is like building a 
house. 

321
00:15:38,000 --> 00:15:40,300
That's the metaphor. 
I don't believe in that metaphor

322
00:15:40,300 --> 00:15:42,900
but it's very common and one of 
the problems is that the set of 

323
00:15:42,900 --> 00:15:45,200
constraints is completely 
different because when you build

324
00:15:45,200 --> 00:15:48,300
a house you have some 
constraints that are imposed 

325
00:15:48,300 --> 00:15:52,000
upon you basically by the real 
world you have gravity, you have

326
00:15:52,000 --> 00:15:55,500
strength of materials, you have 
a A lot of logistics you need to

327
00:15:55,500 --> 00:15:58,600
take care of for example. 
You can't just start by building

328
00:15:58,600 --> 00:16:01,600
the roof and then later on say, 
well, yeah, I don't like roof. 

329
00:16:01,600 --> 00:16:03,800
Let's try to build another roof 
and then later on, once you've 

330
00:16:03,800 --> 00:16:06,500
done with the roof, you say okay
let's now do the foundation's, 

331
00:16:06,800 --> 00:16:09,600
that's not kind of work with the
building because the set of 

332
00:16:09,600 --> 00:16:13,800
constraints is based in the real
world where as you also have a 

333
00:16:13,800 --> 00:16:16,000
set of constraints in the case 
of software development, but 

334
00:16:16,000 --> 00:16:18,200
constraints are quite different 
often. 

335
00:16:18,200 --> 00:16:20,000
There's no implied or water to 
things. 

336
00:16:20,000 --> 00:16:22,600
So the example that I just gave 
the way you can't start with the

337
00:16:22,600 --> 00:16:25,600
roof, there is an implied. 
I'd order to things you have to 

338
00:16:25,600 --> 00:16:27,900
sort of start from the bottom 
and go up if you're building a 

339
00:16:27,908 --> 00:16:31,300
house, the constraints implied, 
or they enforce that order. 

340
00:16:31,300 --> 00:16:34,300
On the way you have to do things
in a certain order, that's not 

341
00:16:34,300 --> 00:16:36,600
so much the case when you do 
software development because you

342
00:16:36,600 --> 00:16:39,900
can basically start wherever 
you'd like to start. 

343
00:16:39,900 --> 00:16:42,000
If you want to start with the 
user interface, you can do that 

344
00:16:42,000 --> 00:16:43,900
if you want to start with the 
database, you can do that. 

345
00:16:44,100 --> 00:16:47,600
So that's much more flexible but
then you have another set of 

346
00:16:47,600 --> 00:16:50,100
constraints and people are often
not really aware of those. 

347
00:16:50,300 --> 00:16:53,200
First constraint is the software
needs to actually execute 

348
00:16:53,200 --> 00:16:55,800
correctly on the Pewter, that 
sort of like the bottom line 

349
00:16:56,000 --> 00:16:57,900
that's not the end goal. 
That's sort of like the bare 

350
00:16:57,900 --> 00:17:00,600
minimum but then you have all 
these other problems where you 

351
00:17:00,600 --> 00:17:02,700
say well okay? 
So in order to be able to keep 

352
00:17:02,700 --> 00:17:06,000
on developing, on the software 
developers will have to read the

353
00:17:06,008 --> 00:17:09,800
existing code in order to 
understand how to move next. 

354
00:17:09,800 --> 00:17:12,900
So it's a little bit comparable 
to Logistics in this sense that 

355
00:17:12,900 --> 00:17:15,500
you can't build a house. 
If you can't get materials on 

356
00:17:15,500 --> 00:17:18,400
site and if you excavate the 
foundation, you need to move all

357
00:17:18,400 --> 00:17:20,200
the dirt away from the building 
site. 

358
00:17:20,200 --> 00:17:22,800
So there's some Logistics in the
real world and I think it's a 

359
00:17:22,808 --> 00:17:26,000
little bit comparable in The 
area of software engineering in 

360
00:17:26,000 --> 00:17:29,300
the sense that the logistics are
more related to know. 

361
00:17:29,300 --> 00:17:33,900
How can you enable people to 
keep on working on adding more 

362
00:17:33,900 --> 00:17:35,900
stuff to the software six months
from now. 

363
00:17:35,900 --> 00:17:39,000
A year from now, or two years 
from now, and the logistics that

364
00:17:39,000 --> 00:17:42,100
are involved in, that is also 
the hygiene that is involved 

365
00:17:42,100 --> 00:17:45,100
because you have to make sure 
that the code is understandable 

366
00:17:45,100 --> 00:17:48,200
to those people who come after 
you, or just your future self. 

367
00:17:48,400 --> 00:17:50,200
So that's also a set of 
constraint. 

368
00:17:50,400 --> 00:17:53,400
So that's why I think that we 
can still talk about engineering

369
00:17:53,700 --> 00:17:56,100
but it's just just very 
different from physical 

370
00:17:56,200 --> 00:17:59,400
Structural Engineering. 
I think it's a good segue as 

371
00:17:59,400 --> 00:18:02,100
well because the topic that you 
just described is actually 

372
00:18:02,100 --> 00:18:04,900
sustainability right. 
In his, I think one of the main 

373
00:18:04,900 --> 00:18:07,700
theme of the book you want the 
code that fits in your head 

374
00:18:07,700 --> 00:18:10,600
because you want to aim for 
sustainable software, you have 

375
00:18:10,600 --> 00:18:12,700
this lovely quote, which I will 
read. 

376
00:18:12,700 --> 00:18:14,600
The goal is not to write code 
fast. 

377
00:18:14,700 --> 00:18:17,700
The goal is to sustainable 
software, so you can you explain

378
00:18:17,700 --> 00:18:19,800
a little bit further. 
What do you mean by sustainable 

379
00:18:19,800 --> 00:18:22,700
software and why we should aim 
for sustainable software instead

380
00:18:22,700 --> 00:18:24,600
of just rapidly turning out? 
Coat. 

381
00:18:25,100 --> 00:18:28,700
Okay, so a lot of people talk 
about maintainable software and 

382
00:18:28,700 --> 00:18:30,400
I did that for many years as 
well. 

383
00:18:30,700 --> 00:18:33,200
And then I thought, what if I 
start to call a sustainable 

384
00:18:33,200 --> 00:18:34,800
software instead of 
maintainable? 

385
00:18:35,000 --> 00:18:37,200
Because I think we're using the 
word like maintainable, you're 

386
00:18:37,200 --> 00:18:39,900
talking about that 
characteristic of the software 

387
00:18:39,900 --> 00:18:43,000
from the developers perspective.
Other developers probably going 

388
00:18:43,000 --> 00:18:45,400
to understand what it is that 
you mean by, but it doesn't 

389
00:18:45,400 --> 00:18:47,700
sound sexy. 
It doesn't sound like something 

390
00:18:47,700 --> 00:18:50,100
that other stakeholders would 
actually be interested in. 

391
00:18:50,500 --> 00:18:52,800
So I thought what other words 
could we look for when I 

392
00:18:52,808 --> 00:18:53,900
thought? 
Well, the goal. 

393
00:18:54,100 --> 00:18:57,600
Of software is often to sustain 
an organization. 

394
00:18:57,600 --> 00:19:00,400
In some way, it doesn't have to 
be a private Enterprise. 

395
00:19:00,400 --> 00:19:03,800
It might also be a government 
organization or an in Geo, or 

396
00:19:03,800 --> 00:19:06,900
things like that, but the 
software rarely exists, just for

397
00:19:06,900 --> 00:19:09,700
its own sake. 
It always exists to fulfill some

398
00:19:09,700 --> 00:19:13,700
other goals that an organization
has, an organization, invests in

399
00:19:13,700 --> 00:19:15,300
software in order to achieve the
goal. 

400
00:19:15,300 --> 00:19:18,800
And hopefully also to sustain 
itself in helping achieve that 

401
00:19:18,800 --> 00:19:21,200
goal. 
So software is there to stay in 

402
00:19:21,208 --> 00:19:23,900
the organization basically and 
that's why I chose that word. 

403
00:19:24,100 --> 00:19:26,800
Datable code, rather than 
maintainable code because I 

404
00:19:26,800 --> 00:19:28,700
thought the Outlook is a little 
bit wider. 

405
00:19:28,900 --> 00:19:31,400
You can sort of include other 
stakeholders when you talk about

406
00:19:31,400 --> 00:19:34,000
sustainable software instead of 
maintainable software. 

407
00:19:34,900 --> 00:19:36,600
Yeah, because I'm dense, this 
can be tricky, right? 

408
00:19:36,600 --> 00:19:39,000
So, for something Engineers, 
sometimes we think writing 

409
00:19:39,000 --> 00:19:42,400
software is easy, we just add a 
few lines of code, doing some 

410
00:19:42,400 --> 00:19:44,800
debugging or just compile and 
build and see the output and 

411
00:19:44,800 --> 00:19:46,900
that's it. 
But actually, if you want to see

412
00:19:46,900 --> 00:19:49,000
sustainable or maintainable 
software, it's like you have to 

413
00:19:49,000 --> 00:19:51,300
look at the bigger picture. 
Probably, is there a place where

414
00:19:51,300 --> 00:19:53,900
maybe there are duplicates or 
maybe there are better designs? 

415
00:19:54,100 --> 00:19:56,200
And you have to do refactoring 
and things like that. 

416
00:19:56,200 --> 00:19:59,100
And you mentioned in the 
beginning that code is mostly 

417
00:19:59,100 --> 00:20:01,200
red. 
It's not written mostly. 

418
00:20:01,400 --> 00:20:04,100
So there are many Legacy or 
maybe lines of code that are 

419
00:20:04,100 --> 00:20:05,900
already written. 
That probably you just need to 

420
00:20:05,900 --> 00:20:09,000
build and improve from their own
optimized for readability is one

421
00:20:09,000 --> 00:20:11,100
thing that you suggest in your 
book, right? 

422
00:20:11,300 --> 00:20:14,500
Because adding more code in your
view is not actually an asset. 

423
00:20:14,600 --> 00:20:16,900
It's actually a liability. 
Maybe, you can explain a little 

424
00:20:16,900 --> 00:20:19,900
bit more about this aspect of 
readability and encode as a 

425
00:20:19,900 --> 00:20:23,200
liability instead of asset. 
Okay, so first of all, again, 

426
00:20:23,200 --> 00:20:25,000
the observation that Go to the 
liability. 

427
00:20:25,000 --> 00:20:26,600
Not an asset. 
That's not mine. 

428
00:20:26,800 --> 00:20:30,300
I think I have it from Tim 
ottinger who claims to have it 

429
00:20:30,300 --> 00:20:32,600
from someone else, that's how it
always goes. 

430
00:20:32,900 --> 00:20:36,100
So that's not my idea at all. 
But basically the idea is that 

431
00:20:36,200 --> 00:20:40,300
if we want to talk about assets 
versus liabilities, the code 

432
00:20:40,300 --> 00:20:42,800
itself is really not worth 
anything. 

433
00:20:42,800 --> 00:20:44,700
You can make this thought 
experiment. 

434
00:20:44,800 --> 00:20:47,400
If you imagine that, you've 
written the perfect software for

435
00:20:47,500 --> 00:20:50,800
the purpose of whatever it is 
that you're trying to do and by 

436
00:20:50,800 --> 00:20:53,800
some magical way, you know that 
there are no bugs in the 

437
00:20:53,800 --> 00:20:56,000
software. 
Where it does exactly what it's 

438
00:20:56,000 --> 00:20:57,600
supposed to do. 
And there will be no change 

439
00:20:57,600 --> 00:20:59,900
requirements. 
This is a hypothetical thought 

440
00:20:59,900 --> 00:21:01,800
experiment. 
That's never going to happen in 

441
00:21:01,800 --> 00:21:03,800
the real world. 
But, you know, if you imagine 

442
00:21:03,800 --> 00:21:06,700
that, you have the perfect 
software, it's done. 

443
00:21:07,200 --> 00:21:09,100
Why would you need to keep the 
code around? 

444
00:21:09,500 --> 00:21:12,600
The code, just created the 
software the state of exe files 

445
00:21:12,600 --> 00:21:15,000
at dlls or whatever it is. 
You can always just copy them. 

446
00:21:15,200 --> 00:21:17,900
You don't need to be able to 
compile them ever again. 

447
00:21:18,300 --> 00:21:20,900
I'm assuming here a compiled 
language and not an interpreted 

448
00:21:20,900 --> 00:21:23,100
one. 
This make that assumption so I 

449
00:21:23,100 --> 00:21:27,200
would argue that the Code is at 
best worth noting in that 

450
00:21:27,200 --> 00:21:29,700
scenario, there's no reason to 
keep it about. 

451
00:21:30,200 --> 00:21:33,400
So the reason why we keep code 
around this, not because it has 

452
00:21:33,400 --> 00:21:37,600
an inherent worth in itself, we 
keep it around in order to be 

453
00:21:37,600 --> 00:21:41,400
able to make changes to the 
software, because in the thought

454
00:21:41,400 --> 00:21:43,000
experiment, the software was 
perfect. 

455
00:21:43,000 --> 00:21:46,000
But in the real world, it's not,
it will have box and even if it 

456
00:21:46,000 --> 00:21:49,000
has no box, it will need new 
features because there will be 

457
00:21:49,000 --> 00:21:51,500
change requirements and so on. 
So we keep the code around in 

458
00:21:51,500 --> 00:21:54,500
order to be able to produce the 
outcome that we we actually 

459
00:21:54,500 --> 00:21:57,100
desire. 
So that's just like any other 

460
00:21:57,100 --> 00:22:00,500
liability in the sense that you 
can keep spare parts around in 

461
00:22:00,500 --> 00:22:03,000
your factory. 
In order to be able to create 

462
00:22:03,000 --> 00:22:06,500
new cars, whatever it is that 
you produce all the parts. 

463
00:22:06,500 --> 00:22:10,000
You keep on stock is a liability
and the same thing goes with 

464
00:22:10,000 --> 00:22:12,200
code, so that's the reason for 
that. 

465
00:22:12,400 --> 00:22:16,900
So that also means that in terms
of being productive, you have to

466
00:22:16,900 --> 00:22:21,200
manage the liability, that means
minimizing the cost of owning 

467
00:22:21,200 --> 00:22:23,900
that liability. 
So again we come back to this. 

468
00:22:24,100 --> 00:22:27,400
Were you know if you make it as 
readable as possible, the cost 

469
00:22:27,400 --> 00:22:30,900
of hooning or having that on 
stock, the cost goes down. 

470
00:22:31,700 --> 00:22:34,100
Thanks for explaining this. 
Sometimes it's count, eight to 

471
00:22:34,100 --> 00:22:36,400
eight different because it is we
write the code. 

472
00:22:36,400 --> 00:22:38,700
It is an asset. 
It keeps producing values that 

473
00:22:38,700 --> 00:22:41,200
we wanted to do. 
So thanks for sharing that, that

474
00:22:41,200 --> 00:22:43,100
perspective. 
It's also something that I 

475
00:22:43,100 --> 00:22:46,000
learned you mentioned about 
optimizing for readability and 

476
00:22:46,000 --> 00:22:48,600
also you quoted Martin Fowler in
the beginning saying any fool 

477
00:22:48,600 --> 00:22:51,500
can write a somewhere that 
computer understand, but not 

478
00:22:51,500 --> 00:22:53,900
everyone can actually write a 
software that people. 

479
00:22:54,000 --> 00:22:56,100
A understand I think again is 
true. 

480
00:22:56,200 --> 00:22:59,200
We all have seen it in our real 
life and that code that is quite

481
00:22:59,200 --> 00:23:02,600
complex and big and doesn't fit 
in our head and you have this 

482
00:23:02,600 --> 00:23:05,500
rule of thumb or maybe just 
guidelines for people in your 

483
00:23:05,500 --> 00:23:08,100
book over and over again, which 
is the rule of seven. 

484
00:23:08,500 --> 00:23:11,000
Can you explain? 
What is Rule of seven? 

485
00:23:11,200 --> 00:23:13,400
Why is it 7.5? 
Not then. 

486
00:23:14,200 --> 00:23:17,000
Yeah, so this is a little bit of
a cheat again in the sense that 

487
00:23:17,000 --> 00:23:20,000
it doesn't have to be 7, but the
reason why I picked seven, 

488
00:23:20,000 --> 00:23:22,500
there's a couple reasons for 
that but there's a very famous 

489
00:23:22,500 --> 00:23:25,400
paper in experimental. 
Ecology called the magical 

490
00:23:25,400 --> 00:23:28,800
number 7 plus minus 2. 
This was based on some 

491
00:23:28,800 --> 00:23:31,800
experiments done by an 
experimental psychologist called

492
00:23:31,800 --> 00:23:34,500
George Miller and the papers 
from 1956. 

493
00:23:34,500 --> 00:23:37,100
So it's actually quite a robust 
result. 

494
00:23:37,300 --> 00:23:39,900
One of the conclusions of this 
paper is that we have short term

495
00:23:39,900 --> 00:23:43,600
memory and it can hold about 
seven things in our short-term 

496
00:23:43,600 --> 00:23:46,600
memory plus minus 2. 
So that means that if we try to 

497
00:23:46,600 --> 00:23:51,500
remember random numbers names or
colors or variables that were 

498
00:23:51,500 --> 00:23:53,900
reading code, we can juggle 
around. 

499
00:23:54,000 --> 00:23:56,500
And things in our short-term 
memory before we start to 

500
00:23:56,500 --> 00:23:58,000
forgetting some of that stuff 
again. 

501
00:23:58,200 --> 00:24:01,300
So I think that's a very 
interesting Insight in terms of 

502
00:24:01,300 --> 00:24:04,600
what it means to read code. 
Because what we do when we read 

503
00:24:04,600 --> 00:24:08,500
code is that we do our best to 
sort of interpret the code as we

504
00:24:08,500 --> 00:24:09,400
go. 
So it's almost like we're 

505
00:24:09,400 --> 00:24:11,800
running a little interpreter, a 
little compiler, a little 

506
00:24:11,800 --> 00:24:14,200
emulator in our brain, that sort
of tries to understand, okay? 

507
00:24:14,200 --> 00:24:16,900
So if the input here is that you
know it's going to branch and 

508
00:24:16,900 --> 00:24:18,600
this one. 
So we're sort of running an 

509
00:24:18,600 --> 00:24:21,100
interpreter in their brain and 
that means we need to keep track

510
00:24:21,100 --> 00:24:23,200
of State. 
Because if we encounter and if 

511
00:24:23,200 --> 00:24:26,100
statement, for example, We need 
to be able to say to ourselves, 

512
00:24:26,100 --> 00:24:28,800
okay? 
So if the input was that that if

513
00:24:28,800 --> 00:24:30,800
statements going to be full. 
So we're going to fall through 

514
00:24:30,808 --> 00:24:34,100
into the ill statement. 
All of these things, we can't 

515
00:24:34,100 --> 00:24:37,300
make those interpretations of 
code, unless we are able to 

516
00:24:37,300 --> 00:24:40,400
maintain state in our head. 
Again, you know, I think we can 

517
00:24:40,400 --> 00:24:44,000
keep track of as the paper says 
maybe seven things, but if they 

518
00:24:44,000 --> 00:24:47,200
are small state that we need to 
keep track of and those seven 

519
00:24:47,200 --> 00:24:50,200
things, then the code becomes 
really much harder to 

520
00:24:50,200 --> 00:24:52,600
understand. 
So I wind a little bit with the 

521
00:24:52,600 --> 00:24:54,600
number seven for a couple of No 
reasons. 

522
00:24:54,600 --> 00:24:57,800
First of all, I wanted something
simple and easy to remember. 

523
00:24:58,000 --> 00:25:02,200
So instead of keep on saying 5 
to 9 + - I'm just using this 

524
00:25:02,200 --> 00:25:05,100
because it's easy to remember, 
there's also this thing we're in

525
00:25:05,100 --> 00:25:08,200
lots of cultures 7 is solid like
a magical number anyway because 

526
00:25:08,200 --> 00:25:09,900
you know from fairytales and so 
on. 

527
00:25:09,900 --> 00:25:13,200
So it's easy to remember. 
So I never call it the rule of 

528
00:25:13,200 --> 00:25:16,300
seven in the book, I don't think
I'll be able to do that but you 

529
00:25:16,300 --> 00:25:18,300
did that and I've heard other 
people do that now. 

530
00:25:18,500 --> 00:25:20,100
So that's actually quite great 
that. 

531
00:25:20,100 --> 00:25:22,900
It turns out that the ideas 
catchy enough, that you begin to

532
00:25:22,900 --> 00:25:25,300
put it in your own words. 
Which means that it's somehow 

533
00:25:25,300 --> 00:25:27,800
must be working, which I'm very 
happy about. 

534
00:25:27,900 --> 00:25:31,200
As you can tell, sometimes I'm 
being a little bit deliberate 

535
00:25:31,200 --> 00:25:34,900
with the way that I choose words
or the way that I put things, I 

536
00:25:34,900 --> 00:25:38,300
don't think that I'm cheating. 
I think it's very much On Target

537
00:25:38,300 --> 00:25:40,800
in terms of what I've read 
about, what this human 

538
00:25:40,800 --> 00:25:43,400
short-term memory can do. 
But I also think it's quite 

539
00:25:43,400 --> 00:25:46,800
important to present things in a
way that their memory rules, and

540
00:25:46,800 --> 00:25:50,000
that's why I'm sometimes picking
one number instead of a range. 

541
00:25:50,200 --> 00:25:53,100
That's the story. 
Basically, So to make it more 

542
00:25:53,100 --> 00:25:55,700
practical, right? 
So when we look at code, we 

543
00:25:55,700 --> 00:25:58,600
count the number of variables. 
We count the number of lines to 

544
00:25:58,600 --> 00:26:00,900
become the number of what in 
your book. 

545
00:26:00,900 --> 00:26:03,600
You mention about cyclomatic 
complexity, but what is exactly 

546
00:26:03,600 --> 00:26:07,300
seven here refers to. 
So there could be lots of 

547
00:26:07,300 --> 00:26:10,300
different things I like to look 
at cyclomatic complexity. 

548
00:26:10,600 --> 00:26:13,300
So that's one thing where you 
might say you'd like to have 

549
00:26:13,300 --> 00:26:15,100
some sort of threshold in your 
code. 

550
00:26:15,300 --> 00:26:18,300
In the book, I also talked about
thresholds because I think it's 

551
00:26:18,300 --> 00:26:19,900
very important to have some 
thresholds. 

552
00:26:20,000 --> 00:26:22,900
You can agree on as a team to 
say And measurement like 

553
00:26:22,900 --> 00:26:26,400
cyclomatic complexity should, in
general, not exceed a particular

554
00:26:26,400 --> 00:26:28,500
threshold. 
The threshold might be seven, 

555
00:26:28,700 --> 00:26:30,800
might be something else. 
And the reason why I think we're

556
00:26:30,800 --> 00:26:34,200
so so important is that there's 
no one looks after the win are 

557
00:26:34,200 --> 00:26:37,900
things getting near to, or 
something that is problematic. 

558
00:26:38,000 --> 00:26:40,800
If no one pays attention to 
that, your code will grow in 

559
00:26:40,800 --> 00:26:44,400
complexity in lots of different 
dimensions and you're not really

560
00:26:44,400 --> 00:26:47,200
going to notice until it 
actually really hurts. 

561
00:26:47,700 --> 00:26:50,800
At that time, it's very late, 
it's difficult and it's 

562
00:26:50,800 --> 00:26:53,900
expensive to fix. 
He's so it's better to sort of 

563
00:26:53,900 --> 00:26:56,600
knit things in the bud, if you 
will by having some thresholds 

564
00:26:56,600 --> 00:26:59,300
where, for example, with 
cyclomatic complexity you could 

565
00:26:59,300 --> 00:27:02,000
say, we should set an aggressive
threshold. 

566
00:27:02,200 --> 00:27:05,100
I just picked number 7 again, 
just because I do that all the 

567
00:27:05,100 --> 00:27:07,500
way through the book, I've 
written the code that goes with 

568
00:27:07,500 --> 00:27:09,600
the book, that demonstrates 
that's possible to do. 

569
00:27:09,800 --> 00:27:12,000
Most of the code that I write 
actually doesn't have even 

570
00:27:12,000 --> 00:27:15,200
cyclomatic complexity of seven. 
It's more like three or four 

571
00:27:15,300 --> 00:27:17,500
typically, so, that's definitely
possible. 

572
00:27:17,800 --> 00:27:20,300
So that's just one 
quantification mechanism. 

573
00:27:20,500 --> 00:27:23,000
I'm looking for those Patience 
various different 

574
00:27:23,000 --> 00:27:25,900
quantifications in order to be 
able to monitor thresholds. 

575
00:27:26,200 --> 00:27:29,600
Cyclomatic complexity is one. 
You also mentioned just counting

576
00:27:29,600 --> 00:27:31,700
objects. 
Basically accounting variables 

577
00:27:31,700 --> 00:27:35,400
is a very unsophisticated way of
introducing a metric. 

578
00:27:35,700 --> 00:27:38,300
But the thing I want to do with 
metrics, I don't want the 

579
00:27:38,300 --> 00:27:41,400
metrics to be something that 
only the machine can do for you.

580
00:27:41,700 --> 00:27:44,600
I want metrics to be something 
where you can just do it. 

581
00:27:44,600 --> 00:27:47,100
If you're discussing with the 
colleague, if you're doing pair 

582
00:27:47,100 --> 00:27:50,100
programming, or if you're doing 
a code review, you should be 

583
00:27:50,100 --> 00:27:52,600
able to just do that in your 
head and say, oh, that's just 

584
00:27:52,600 --> 00:27:55,400
too many variables. 
Here you can just count them so 

585
00:27:55,400 --> 00:27:58,700
simple, stuff like that. 
So those two things like object 

586
00:27:58,700 --> 00:28:01,500
activation and cyclomatic 
complexity, I just picked seven 

587
00:28:01,500 --> 00:28:04,200
because I think that's actually 
quite a reasonable threshold for

588
00:28:04,200 --> 00:28:06,600
those. 
Anyway, you also mentioned, I 

589
00:28:06,600 --> 00:28:08,900
talk about lines of code and 
also with the number of 

590
00:28:08,900 --> 00:28:12,800
characters, you can use on a 
horizontal line, that's not 7x7.

591
00:28:12,800 --> 00:28:15,100
I'm not suggesting that people 
should buy curled in the seven 

592
00:28:15,100 --> 00:28:17,700
by seven bucks because that's 
not really going to be useful. 

593
00:28:18,000 --> 00:28:20,600
So, I have some other numbers 
there, it's not seven all the 

594
00:28:20,600 --> 00:28:23,600
way but it's 7 in a lot of In 
lots of places but that's 

595
00:28:23,600 --> 00:28:26,000
basically the measurements that 
I tend to look for. 

596
00:28:26,000 --> 00:28:29,100
You know, cyclomatic complexity 
object activation number 

597
00:28:29,100 --> 00:28:32,800
variables lines of code in a 
method and the width of the 

598
00:28:32,800 --> 00:28:34,400
code, that's pretty much what 
I'm looking for. 

599
00:28:35,100 --> 00:28:37,700
So maybe for people who are not 
familiar yet with the cyclomatic

600
00:28:37,700 --> 00:28:40,300
complexity, if you can take a 
few minutes to explain, what is 

601
00:28:40,300 --> 00:28:43,000
exactly cyclomatic complexity? 
How do we count it? 

602
00:28:43,400 --> 00:28:45,500
Yeah, we should really come up 
with a better name for it 

603
00:28:45,500 --> 00:28:48,600
because the name sounds really 
scary, but it's a super simple 

604
00:28:48,600 --> 00:28:50,500
concept. 
The idea is basically just to 

605
00:28:50,500 --> 00:28:53,600
count the number of Inked 
pathways through the code. 

606
00:28:53,600 --> 00:28:56,000
So, if you imagine, you have a 
method where there's a single, 

607
00:28:56,000 --> 00:29:00,200
if Ranch, either the code can go
through the if Branch, if the 

608
00:29:00,200 --> 00:29:03,000
Boolean expression turns out to 
be true or it can fall through 

609
00:29:03,000 --> 00:29:04,700
that your files. 
If the Boolean expression turns 

610
00:29:04,700 --> 00:29:07,100
out to be false. 
So in this very simple example, 

611
00:29:07,100 --> 00:29:09,400
you have two distinct pathways 
through the code. 

612
00:29:09,600 --> 00:29:13,300
We count looping as a distinct 
pathway as well, because in most

613
00:29:13,300 --> 00:29:15,600
cases if you look over the 
collection and the collection is

614
00:29:15,600 --> 00:29:19,200
empty, all the code that's 
within the loop is not going to 

615
00:29:19,200 --> 00:29:20,900
be executed. 
So there's a little bit like a 

616
00:29:20,900 --> 00:29:24,400
branch instruction. 
Well, so basically you just stop

617
00:29:24,400 --> 00:29:26,900
by one because there's always 
going to be one distinct 

618
00:29:26,900 --> 00:29:28,900
pathways through the simplest 
line of code. 

619
00:29:29,000 --> 00:29:31,300
Hello world has cyclomatic 
complexity of one because 

620
00:29:31,300 --> 00:29:34,200
there's just one thing you can 
do to just start by one of these

621
00:29:34,200 --> 00:29:36,500
every time you see a branch 
instruction or looping 

622
00:29:36,500 --> 00:29:38,500
instruction, you just increment,
the counter by one. 

623
00:29:38,500 --> 00:29:41,200
So it's super simple. 
And again this is something you 

624
00:29:41,200 --> 00:29:43,700
don't need a tool to do that. 
You can do that your brain while

625
00:29:43,700 --> 00:29:46,500
you're just looking at the code,
the name is horrible but it's 

626
00:29:46,500 --> 00:29:50,100
just counting distinct pathways 
through the code and it tells 

627
00:29:50,100 --> 00:29:52,700
you a little bit about the load 
on your A short-term memory as 

628
00:29:52,700 --> 00:29:54,700
well because it's almost like 
those distinct Pathways. 

629
00:29:54,700 --> 00:29:57,500
They're sort of like parallel 
Dimensions or method that can 

630
00:29:57,500 --> 00:30:00,400
take three different ways. 
You're looking at something that

631
00:30:00,400 --> 00:30:03,700
can be healed in one of mutually
exclusive ways to sort of like, 

632
00:30:03,700 --> 00:30:06,300
you're looking at the things 
that exist in three dimensions 

633
00:30:06,300 --> 00:30:08,100
at once. 
So again, I think if you're 

634
00:30:08,100 --> 00:30:10,600
looking at something with the 
cyclomatic complexity of 7, for 

635
00:30:10,600 --> 00:30:13,200
example, it's sort of like 
you're looking at a thing that 

636
00:30:13,200 --> 00:30:15,600
is one of seven things at the 
same time. 

637
00:30:15,600 --> 00:30:18,200
And that's probably going to 
tax, your short-term memory as 

638
00:30:18,200 --> 00:30:20,200
well. 
And again, I think the threshold

639
00:30:20,200 --> 00:30:21,900
of seven actually makes a lot of
sense to me. 

640
00:30:22,300 --> 00:30:24,700
But if you look at the older 
literature about cyclomatic 

641
00:30:24,700 --> 00:30:28,000
complexity, most other sources 
would say that cyclomatic 

642
00:30:28,000 --> 00:30:31,400
complexity of 20 or 30 is 
actually considered to be quite 

643
00:30:31,400 --> 00:30:33,700
acceptable. 
So if I have anything new to 

644
00:30:33,700 --> 00:30:35,900
say, if this book brings 
anything new to the table is 

645
00:30:35,900 --> 00:30:37,900
more, that it really 
dramatically lowers. 

646
00:30:37,900 --> 00:30:41,300
What I think the threshold ought
to be thanks for explaining 

647
00:30:41,300 --> 00:30:43,100
that. 
So again for people who may not 

648
00:30:43,100 --> 00:30:46,400
be familiar, so you just count 
by the number of parts that the 

649
00:30:46,400 --> 00:30:50,000
code could possibly execute. 
So if you have, if statements is

650
00:30:50,000 --> 00:30:51,800
probably two Pathways created 
there. 

651
00:30:52,000 --> 00:30:54,200
If you have more and more, if 
statements, basically you keep 

652
00:30:54,200 --> 00:30:57,500
adding the cyclomatic complexity
and I think one of the quote in 

653
00:30:57,500 --> 00:31:00,200
the book I think is from can 
back or someone else, the goal 

654
00:31:00,200 --> 00:31:03,400
of survey design is to create 
chunks or slices that fit into a

655
00:31:03,408 --> 00:31:05,800
human mind. 
So you mention here about the 

656
00:31:05,800 --> 00:31:08,000
cognitive load in your brain 
short-term memories. 

657
00:31:08,200 --> 00:31:10,900
So when you reach a certain 
threshold maybe it's seventh, 

658
00:31:10,900 --> 00:31:13,400
maybe something else. 
Keep spitting maybe the chunks 

659
00:31:13,400 --> 00:31:15,200
of code in the smaller 
compartments, right? 

660
00:31:15,200 --> 00:31:18,000
So that you don't have this 
cognitive load and your software

661
00:31:18,000 --> 00:31:20,600
does become more sustainable 
which is again the theme of the 

662
00:31:20,600 --> 00:31:22,400
book. 
The code that fits in your Hit. 

663
00:31:22,600 --> 00:31:25,900
So thanks for sharing all this. 
So you mentioned a number of 

664
00:31:25,900 --> 00:31:28,000
practices in the book. 
Maybe, when we have time, we 

665
00:31:28,000 --> 00:31:31,200
covered some of them. 
The first one sounds very simple

666
00:31:31,600 --> 00:31:34,200
but actually it's quite 
powerful, which is checklist. 

667
00:31:34,500 --> 00:31:37,700
I think we sometimes also hear 
it from medical or maybe we look

668
00:31:37,700 --> 00:31:40,200
at the book as well. 
The checklist Manifesto, can you

669
00:31:40,200 --> 00:31:43,100
explain to us what is this 
checklist and how we should use 

670
00:31:43,100 --> 00:31:46,500
it in our day-to-day? 
Yeah, so we can, I actually just

671
00:31:46,600 --> 00:31:49,300
also took a lot of inspiration 
from the checklist Manifesto. 

672
00:31:49,500 --> 00:31:52,500
You just mention that which is 
written by Atul gawande who's a 

673
00:31:52,508 --> 00:31:54,900
surgeon. 
He has this wonderful phrase 

674
00:31:54,900 --> 00:31:56,300
that one of the people who 
partook. 

675
00:31:56,300 --> 00:31:59,200
In this experiment, saved the 
checklists, increase the 

676
00:31:59,200 --> 00:32:01,700
outcome, without any increase in
skill. 

677
00:32:01,900 --> 00:32:04,800
So you can use the exactly the 
same skill level as you already 

678
00:32:04,800 --> 00:32:07,100
have. 
But then by using a very simple 

679
00:32:07,100 --> 00:32:10,400
Aid to memory, which is a 
checklist, you can improve the 

680
00:32:10,400 --> 00:32:14,000
overall outcome of a process by 
making sure that we do things in

681
00:32:14,000 --> 00:32:16,300
the right order. 
And I know that the checklist is

682
00:32:16,300 --> 00:32:19,200
something that to most people 
sounds little bit oppressive, 

683
00:32:19,300 --> 00:32:21,900
or, at least ordering what we 
need to understand. 

684
00:32:21,900 --> 00:32:24,500
First of all, did originals are 
from military. 

685
00:32:24,500 --> 00:32:28,000
Aviation, you can imagine Pilots
going through checklist before 

686
00:32:28,000 --> 00:32:30,700
they take off and before they go
into landing and so on. 

687
00:32:30,900 --> 00:32:33,600
So you have to imagine those 
sorts of situations instead of 

688
00:32:33,600 --> 00:32:37,100
imagining filling out boring 
forms on paper because that's 

689
00:32:37,100 --> 00:32:38,800
actually not really what you're 
supposed to do. 

690
00:32:39,100 --> 00:32:41,700
So a checklist is an aid to 
memory is basically just to make

691
00:32:41,700 --> 00:32:45,600
sure that you always remember to
do things in a certain order. 

692
00:32:45,700 --> 00:32:47,700
If you are really good at it, 
you can just run through the 

693
00:32:47,700 --> 00:32:49,700
checklist and say okay today 
remember to do that. 

694
00:32:49,900 --> 00:32:51,700
Yeah actually to do remember to 
do that. 

695
00:32:52,000 --> 00:32:54,800
I also actually did remember to 
that because if you actually do 

696
00:32:54,800 --> 00:32:56,200
that as a process you will be 
surprised. 

697
00:32:56,200 --> 00:32:59,800
How many small things you forget
this human nature, that we 

698
00:32:59,800 --> 00:33:02,200
forget all of those things. 
And again I think we have this 

699
00:33:02,200 --> 00:33:05,700
very limited capacity in our 
short-term memory, so everything

700
00:33:05,700 --> 00:33:08,300
we can offload and say, well, 
sometimes, we can remember 

701
00:33:08,300 --> 00:33:10,900
things by putting them in long 
term memory, but if we can 

702
00:33:10,900 --> 00:33:13,600
somehow automate things away in 
various different ways. 

703
00:33:13,600 --> 00:33:16,500
By, for example, following A 
checklist that means we don't 

704
00:33:16,500 --> 00:33:19,900
have to spend limited brain 
power of making sure that we 

705
00:33:19,908 --> 00:33:22,100
remember to do all the things 
correctly, which is the go 

706
00:33:22,100 --> 00:33:24,900
through a checklist. 
So I want to be very explicit 

707
00:33:24,900 --> 00:33:27,800
here that a checklist is not a 
control mechanism. 

708
00:33:27,800 --> 00:33:30,500
It's not something that your 
manager should be able to 

709
00:33:30,500 --> 00:33:33,000
leverage in order to keep an eye
on you. 

710
00:33:33,300 --> 00:33:36,400
Ideally it's just something for 
example, with the search in some

711
00:33:36,400 --> 00:33:38,800
of the experiments that are to 
go out the did in the hospital, 

712
00:33:38,800 --> 00:33:41,500
he worked on, he put the 
checklist, you created posters 

713
00:33:41,500 --> 00:33:43,200
of the checklist. 
It was questions. 

714
00:33:43,200 --> 00:33:46,000
Like did you remember to wash 
your Hands before you went into 

715
00:33:46,000 --> 00:33:49,200
surgery, are you sure you're 
operating on the right, patient?

716
00:33:49,300 --> 00:33:51,300
Things like that. 
You'd actually be surprised. 

717
00:33:51,300 --> 00:33:54,700
How often these things go wrong.
If you don't explicit the deal 

718
00:33:54,700 --> 00:33:57,100
with them. 
The point is It's a poster on a 

719
00:33:57,100 --> 00:34:00,200
wall, so it leaves. 
No, audit Trace. 

720
00:34:00,400 --> 00:34:03,400
There's nothing where some 
manager can come by afterwards 

721
00:34:03,400 --> 00:34:06,800
and try to extract information 
about how you work or how 

722
00:34:06,800 --> 00:34:08,300
efficiently you work or 
whatever. 

723
00:34:08,500 --> 00:34:10,199
It's there to improve the 
process. 

724
00:34:10,199 --> 00:34:12,000
It's not there to keep an eye on
you. 

725
00:34:12,199 --> 00:34:13,400
And I think that's very 
important. 

726
00:34:13,699 --> 00:34:17,400
I would think twice Ice before I
started turning checklist into 

727
00:34:17,400 --> 00:34:20,300
something the produced reports 
you can also make the checklist.

728
00:34:20,500 --> 00:34:22,000
I talked about that in the book 
as well. 

729
00:34:22,500 --> 00:34:24,900
You know, most languages and 
most development environment 

730
00:34:24,900 --> 00:34:28,500
comes with all sorts of extra 
tools that can make suggestions 

731
00:34:28,600 --> 00:34:30,800
about it code. 
So in some languages, should 

732
00:34:30,800 --> 00:34:34,400
call them dentists and in.net. 
We call them static code 

733
00:34:34,400 --> 00:34:36,100
analysis. 
But the idea is basically the 

734
00:34:36,100 --> 00:34:39,100
same, it's sort of like a 
checklist where it says over you

735
00:34:39,100 --> 00:34:40,900
are using that overload of the 
method. 

736
00:34:40,900 --> 00:34:43,300
But that's not really supposed 
to do that because it might be 

737
00:34:43,300 --> 00:34:44,500
deprecated in the future. 
You should. 

738
00:34:44,600 --> 00:34:47,699
Use that one instead that's sort
of like an automated checklist 

739
00:34:47,900 --> 00:34:51,900
and I'm all for that but as far 
as I know also the static code 

740
00:34:51,900 --> 00:34:54,600
analysis that comes with that. 
Net for example, Justin create a

741
00:34:54,607 --> 00:34:58,300
report and I would be very 
concerned if it started doing 

742
00:34:58,300 --> 00:35:00,000
that. 
So I think it's very important 

743
00:35:00,000 --> 00:35:03,200
when we talk about checklist to 
say it's for your benefit. 

744
00:35:03,600 --> 00:35:06,400
It's not for your managers. 
Benefit is just there to make 

745
00:35:06,400 --> 00:35:09,700
sure that you remember to do 
things in the right order and 

746
00:35:09,700 --> 00:35:12,000
while it seems stupid, it's 
probably a good idea. 

747
00:35:12,700 --> 00:35:16,000
So actually, from my personal 
Checklist is also powerful. 

748
00:35:16,200 --> 00:35:19,200
Imagine for example, I've been 
producing this podcast 80 plus 

749
00:35:19,200 --> 00:35:23,000
episodes, so I use checklists as
well because it's times, depends

750
00:35:23,000 --> 00:35:26,100
on stress, depends on mood, 
depending on the complexity of 

751
00:35:26,100 --> 00:35:29,100
the episode sometimes you tend 
to miss certain parts of the 

752
00:35:29,100 --> 00:35:31,600
process which even though you 
assume you know, but you 

753
00:35:31,600 --> 00:35:34,500
sometimes miss it and actually 
you also mention in the book 

754
00:35:34,500 --> 00:35:37,300
that sometimes just following a 
checklist doesn't mean that you 

755
00:35:37,300 --> 00:35:39,300
will produce the successful 
outcome. 

756
00:35:39,300 --> 00:35:42,000
But it even increases the 
chances that you will get 

757
00:35:42,000 --> 00:35:44,500
successful outcome. 
Do keep in mind, maybe in your 

758
00:35:44,600 --> 00:35:47,000
your day-to-day process. 
If there's something that you 

759
00:35:47,000 --> 00:35:50,500
want to increase in terms of 
success rate, maybe you should 

760
00:35:50,500 --> 00:35:52,900
use a checklist. 
So, thanks again for explaining 

761
00:35:53,200 --> 00:35:55,400
the second practice that you 
mentioned is about vertical 

762
00:35:55,400 --> 00:35:58,000
slice, so maybe explain a little
bit. 

763
00:35:58,000 --> 00:36:00,600
Why we should aim for this 
vertical slice. 

764
00:36:01,400 --> 00:36:04,000
Yeah, okay, so again, another 
idea that's not mine are 

765
00:36:04,000 --> 00:36:06,700
basically stolen that from net 
price and Steve Freeman. 

766
00:36:07,000 --> 00:36:09,100
They have this wonderful book 
called growing object-oriented 

767
00:36:09,100 --> 00:36:12,400
software Guided by tests. 
So that's an entire book about 

768
00:36:12,400 --> 00:36:14,800
basically, that idea. 
But I just thought I Gee 

769
00:36:14,800 --> 00:36:18,600
included when I coach teams. 
I'm trying to teach them to do 

770
00:36:18,600 --> 00:36:21,200
some test driven development but
then it sort of can't really 

771
00:36:21,200 --> 00:36:23,700
figure out where to start. 
So, I'm not saying we should 

772
00:36:23,700 --> 00:36:26,300
always do this vertical slice, 
but I think it's a very good 

773
00:36:26,300 --> 00:36:28,400
idea. 
If you don't have better ideas, 

774
00:36:28,400 --> 00:36:30,200
then do that as a default, if 
you will. 

775
00:36:30,300 --> 00:36:32,600
So that might also be a 
checklist where to start. 

776
00:36:32,800 --> 00:36:34,300
Do you have a good idea for 
where to start? 

777
00:36:34,300 --> 00:36:36,900
If yes, go there. 
Follow your good idea if no 

778
00:36:37,200 --> 00:36:39,700
start with a vertical slice. 
So basically this idea from 

779
00:36:39,700 --> 00:36:43,400
vertical slices to say, try to 
implement a feature of the 

780
00:36:43,400 --> 00:36:47,000
software all The way through as 
narrowly as possible. 

781
00:36:47,200 --> 00:36:51,400
Because I've seen lots of teams 
that get hung up on all sorts of

782
00:36:51,400 --> 00:36:54,000
side quests, if you will, where 
they say. 

783
00:36:54,000 --> 00:36:56,000
Well, yeah. 
But before we can Implement that

784
00:36:56,000 --> 00:36:59,300
feature, we need to have the 
Locking System in place. 

785
00:36:59,700 --> 00:37:01,700
That means we need to pick a 
locking framework. 

786
00:37:01,700 --> 00:37:04,200
And then we need to create our 
own framework on top of the 

787
00:37:04,200 --> 00:37:07,900
other logging Frameworks weeks 
go by and nothing actually gets 

788
00:37:07,900 --> 00:37:09,400
produced. 
And once you actually start 

789
00:37:09,400 --> 00:37:12,300
creating features, it turns out 
that the Locking framework, they

790
00:37:12,300 --> 00:37:14,000
created all the database 
framework. 

791
00:37:14,000 --> 00:37:16,400
They created Doesn't really 
actually solve the problems, 

792
00:37:16,400 --> 00:37:19,100
they need to solve and then they
have to go back and retrofit it.

793
00:37:19,100 --> 00:37:20,900
So that's just racist a lot of 
time. 

794
00:37:21,200 --> 00:37:24,400
So instead basically the idea 
with the vertical slices to same

795
00:37:24,500 --> 00:37:27,200
figure out a simple way to get 
all the way through. 

796
00:37:27,500 --> 00:37:29,900
You don't have to have layered 
application architecture, but 

797
00:37:29,900 --> 00:37:33,000
basically just say well, 
Implement a feature so that it 

798
00:37:33,000 --> 00:37:35,800
actually works. 
The book has one running example

799
00:37:35,800 --> 00:37:38,400
that goes all the way through 
which is an online restaurant 

800
00:37:38,400 --> 00:37:41,300
reservation system. 
And the first one I start doing 

801
00:37:41,300 --> 00:37:43,900
is to enable you to post 
reservation. 

802
00:37:43,900 --> 00:37:46,400
This is a Stay Pi. 
So you should be able to post a 

803
00:37:46,408 --> 00:37:48,500
reservation little Json 
document. 

804
00:37:48,500 --> 00:37:51,100
The I considered the feature 
complete when that reservation 

805
00:37:51,100 --> 00:37:54,200
is persisted in a dollar store. 
So that's the first vertical 

806
00:37:54,200 --> 00:37:57,000
slice. 
I start by writing a test an 

807
00:37:57,000 --> 00:38:00,500
automated test that posts that 
Json document to self-hosted 

808
00:38:00,500 --> 00:38:02,800
rest API. 
The first thing is, just to 

809
00:38:02,800 --> 00:38:06,800
ensure that the API response 
with some 200 Response Code. 

810
00:38:06,900 --> 00:38:09,400
And that point is not persisting
anything, but just to make sure 

811
00:38:09,400 --> 00:38:12,200
that the in point is there and 
then you can sort of Flesh it 

812
00:38:12,200 --> 00:38:15,400
out from there, this B takes a 
lot of time it Almost half the 

813
00:38:15,400 --> 00:38:17,600
book just getting to the point 
where they actually saves into 

814
00:38:17,600 --> 00:38:19,600
the database. 
But then, you know, I introduced

815
00:38:19,600 --> 00:38:21,700
all sorts of different 
engineering techniques. 

816
00:38:21,700 --> 00:38:25,000
Using that idea of the vertical 
slice, so that's just a very 

817
00:38:25,000 --> 00:38:27,600
thin slice through the 
application, but now you 

818
00:38:27,600 --> 00:38:30,100
actually have something that has
real Behavior. 

819
00:38:30,100 --> 00:38:32,800
So at this point, you could say,
we could actually take and 

820
00:38:32,800 --> 00:38:36,600
deploy this code to production 
and conceivably. 

821
00:38:36,700 --> 00:38:40,000
Someone could start using it 
because it actually is useful. 

822
00:38:40,200 --> 00:38:42,500
It's not very useful, but it 
actually does what it's supposed

823
00:38:42,500 --> 00:38:44,400
to do. 
So the reason why it's called a 

824
00:38:44,500 --> 00:38:46,400
Vertical, slice. 
By the way, is that? 

825
00:38:46,400 --> 00:38:50,300
I think it's named like that, in
opposition to the traditional 

826
00:38:50,300 --> 00:38:52,600
horizontally, layered 
architecture, where you 

827
00:38:52,600 --> 00:38:55,200
typically tried an architecture 
with the set of layers where the

828
00:38:55,200 --> 00:38:57,700
bottom layer is going to be a 
Delta X is 3 and then you have 

829
00:38:57,700 --> 00:39:00,900
maybe a business logic in the 
middle and you have UI and the 

830
00:39:00,900 --> 00:39:02,800
top and maybe some more layers 
in between. 

831
00:39:03,100 --> 00:39:05,300
So the idea with the vertical 
slices, just to say, well, 

832
00:39:05,300 --> 00:39:07,800
instead of thinking about those 
horizontal layers, you didn't 

833
00:39:07,800 --> 00:39:11,100
create a vertical little section
through that layer cake, if you 

834
00:39:11,100 --> 00:39:12,700
will. 
So that's the reason for the 

835
00:39:12,700 --> 00:39:14,400
name. 
I like your metaphor. 

836
00:39:14,600 --> 00:39:16,600
Side quests on those. 
We Engineers when we work on 

837
00:39:16,607 --> 00:39:19,300
something, we like to go into a 
certain different Quest. 

838
00:39:19,500 --> 00:39:21,700
We did our rabbit hole and then 
it goes away. 

839
00:39:21,900 --> 00:39:25,200
You mentioned that a newbie come
up with vertical slice as narrow

840
00:39:25,200 --> 00:39:27,400
as possible, and then we ship 
it. 

841
00:39:27,400 --> 00:39:30,600
I treated as a value in that, 
right, when you ship this code 

842
00:39:30,600 --> 00:39:34,100
into deduction instead of just 
building code over time and 

843
00:39:34,100 --> 00:39:35,900
actually don't deploy to 
production. 

844
00:39:35,900 --> 00:39:38,700
I think that also doesn't give 
any value to anyone including 

845
00:39:38,700 --> 00:39:41,500
your stakeholders and you 
mentioned after we come up with 

846
00:39:41,500 --> 00:39:45,900
this vertical slice, you've 
tried to find A certain factor 

847
00:39:45,900 --> 00:39:48,900
to keep on improving from there.
The next practice that we want 

848
00:39:48,900 --> 00:39:52,100
to talk about is about X driven 
development, mention that to 

849
00:39:52,100 --> 00:39:55,000
make a change to the code. 
You should find a motivation to 

850
00:39:55,000 --> 00:39:56,900
do that. 
These days, we have so many X 

851
00:39:56,900 --> 00:39:59,700
driven development like Custer 
new development, maybe German 

852
00:39:59,700 --> 00:40:02,500
driven development or maybe 
Behavior driven development. 

853
00:40:02,700 --> 00:40:05,000
Maybe he can explain a little 
bit more about this concept X 

854
00:40:05,000 --> 00:40:07,800
driven development and I 
wouldn't Visions to change code.

855
00:40:08,300 --> 00:40:10,900
Yeah, so you already mentioned 
test-driven development which I 

856
00:40:10,900 --> 00:40:13,900
think is probably the most 
well-known of those extra and 

857
00:40:13,900 --> 00:40:14,800
development. 
Things. 

858
00:40:15,100 --> 00:40:17,600
I just noticed that once tester 
and development gains 

859
00:40:17,600 --> 00:40:20,700
popularity, lots of other 
similar techniques came by where

860
00:40:20,700 --> 00:40:22,800
people started to name things in
the same way. 

861
00:40:22,800 --> 00:40:25,300
So you have Behavior driven 
development and property based 

862
00:40:25,300 --> 00:40:28,000
testing is also sometimes called
property driven development and 

863
00:40:28,000 --> 00:40:30,200
then you mentioned domain driven
development. 

864
00:40:30,300 --> 00:40:31,900
So you have various things like 
that. 

865
00:40:32,100 --> 00:40:35,200
But this idea about using some 
sort of driver in order to 

866
00:40:35,200 --> 00:40:37,500
inform you of what's a good 
idea. 

867
00:40:37,600 --> 00:40:40,500
What should I be doing next? 
I think that's an important 

868
00:40:40,500 --> 00:40:43,700
thing to do because again the 
human brain is actually not very

869
00:40:43,700 --> 00:40:45,600
good at that. 
Thinking formally. 

870
00:40:45,700 --> 00:40:48,500
So before I talked about the 
limitations of our short-term 

871
00:40:48,500 --> 00:40:52,000
memory, but also if you just 
look at our ability to do a 

872
00:40:52,000 --> 00:40:55,100
formal analysis of things, we're
not very good at that actually. 

873
00:40:55,100 --> 00:40:57,100
And that's one of the reasons 
why I've despite our best 

874
00:40:57,100 --> 00:40:59,900
intentions, we always create 
defects in the code because we 

875
00:40:59,900 --> 00:41:03,200
write code that we think behaves
in one way and then our brains 

876
00:41:03,200 --> 00:41:05,200
just weren't really up to the 
task. 

877
00:41:05,200 --> 00:41:08,100
And then we created off by one 
error and whatever it is that we

878
00:41:08,100 --> 00:41:09,900
do. 
And that happens all the time. 

879
00:41:10,200 --> 00:41:14,000
So I think for that reason it's 
always a good idea to say, okay 

880
00:41:14,000 --> 00:41:17,200
can we Statute some processes. 
That will help us verify that 

881
00:41:17,200 --> 00:41:19,800
what it is that we're doing, is 
actually appropriate. 

882
00:41:20,000 --> 00:41:22,600
So, that's the idea behind 
tissue development issue, right?

883
00:41:22,600 --> 00:41:24,600
A tests. 
And the idea of the test is that

884
00:41:24,600 --> 00:41:27,600
it's a stimulus. 
Our response is to write the 

885
00:41:27,600 --> 00:41:30,800
code that can pass the test. 
We get the verification that 

886
00:41:30,800 --> 00:41:33,800
we've done the right thing by 
first received the test fail. 

887
00:41:34,000 --> 00:41:36,400
And then we write a simple 
implementation and then we see 

888
00:41:36,400 --> 00:41:39,400
the test pass. 
So that's one way where you can 

889
00:41:39,400 --> 00:41:43,200
use an external driver in order 
to make sure that you doing the 

890
00:41:43,200 --> 00:41:46,200
appropriate thing. 
Another just editing code and 

891
00:41:46,200 --> 00:41:47,900
thinking it works, you're 
actually getting some 

892
00:41:47,900 --> 00:41:50,000
verification of that. 
So that's one thing. 

893
00:41:50,200 --> 00:41:52,700
Another thing that I talked 
about is if you working in a 

894
00:41:52,700 --> 00:41:55,900
language that is statically 
compiled and has static typing, 

895
00:41:56,100 --> 00:41:58,500
you can use the type system to 
tell you whether or not you're 

896
00:41:58,500 --> 00:42:01,100
done the right thing because if 
the code doesn't compile, it 

897
00:42:01,100 --> 00:42:04,300
certainly doesn't work either 
and that doesn't mean that if 

898
00:42:04,300 --> 00:42:06,300
the code does compile that it 
works. 

899
00:42:06,600 --> 00:42:10,000
But again, you can design things
in certain ways, so that if your

900
00:42:10,000 --> 00:42:13,700
code compiles, it's more or less
likely to actually compile. 

901
00:42:13,700 --> 00:42:15,900
So, I will spend A lot of 
research time with the 

902
00:42:15,900 --> 00:42:17,900
programming language called 
Haskell which most people 

903
00:42:17,900 --> 00:42:20,800
probably have heard about and 
there's this phrase going around

904
00:42:20,800 --> 00:42:25,500
about Haskell that if it 
compiles it works, it does often

905
00:42:25,500 --> 00:42:27,600
take your couple of hours 
actually getting your ass to 

906
00:42:27,600 --> 00:42:30,400
code to compile because it's a 
language where the compiler has 

907
00:42:30,400 --> 00:42:32,700
a lot to say, but there's some 
truth in it. 

908
00:42:32,800 --> 00:42:35,600
You can also write books into 
Haskell code, that's absolutely 

909
00:42:35,600 --> 00:42:37,400
possible. 
It language like Haskell 

910
00:42:37,400 --> 00:42:39,000
definitely leans in that 
direction. 

911
00:42:39,000 --> 00:42:42,000
Where if it compiles there's a 
pretty good chance that it 

912
00:42:42,000 --> 00:42:44,200
probably works. 
But once you understand what it 

913
00:42:44,200 --> 00:42:46,100
is, That makes Haskell work like
that. 

914
00:42:46,100 --> 00:42:49,100
You can actually take some of 
those ideas and poured back into

915
00:42:49,100 --> 00:42:51,300
languages. 
Like I work in c-sharp, the book

916
00:42:51,300 --> 00:42:53,900
is written in C sharp. 
So, if you deliberately started 

917
00:42:53,900 --> 00:42:57,200
signing in ways where you 
emulate, some of the things that

918
00:42:57,200 --> 00:42:59,600
gives Haskell that 
characteristic, you can also 

919
00:42:59,600 --> 00:43:02,300
pull your code in that direction
yourself where you can see, I've

920
00:43:02,300 --> 00:43:05,300
designed this API over here. 
So that it's really difficult to

921
00:43:05,300 --> 00:43:07,500
use wrongly. 
There's a concept from lean, 

922
00:43:07,500 --> 00:43:10,700
manufacturing called Pocoyo key,
and I'm probably not pronouncing

923
00:43:10,700 --> 00:43:13,100
it correctly, but it's Japanese 
and it means something like 

924
00:43:13,100 --> 00:43:16,100
mistake proof. 
But basically the idea is that 

925
00:43:16,100 --> 00:43:20,900
you can ride any PI so that if 
the API called compiles, it 

926
00:43:20,900 --> 00:43:24,700
probably also works the way it's
intended to work because it's 

927
00:43:24,700 --> 00:43:27,200
designed in such a way that you 
can't really call it in the 

928
00:43:27,200 --> 00:43:29,300
wrong way. 
I have some examples of that in 

929
00:43:29,300 --> 00:43:31,700
the book as well, so that's 
another way where you can sort 

930
00:43:31,700 --> 00:43:35,200
of use the static type system as
a driver for changes. 

931
00:43:35,600 --> 00:43:38,600
I also talked about how to use 
things, like static code 

932
00:43:38,600 --> 00:43:41,600
analysis, or other languages 
would call that linters and use 

933
00:43:41,600 --> 00:43:44,000
that for drivers of changes. 
So, for example, in my code I 

934
00:43:44,000 --> 00:43:47,600
have quite Quite a few places 
where there's a guard as null 

935
00:43:47,600 --> 00:43:50,500
values and all input. 
There's no junit test. 

936
00:43:50,500 --> 00:43:53,900
That provoked me to write that 
card Clause because there's a 

937
00:43:53,908 --> 00:43:56,300
static analysis tool that 
provokes me to write the 

938
00:43:56,300 --> 00:43:58,500
characters. 
That means if I remove that card

939
00:43:58,500 --> 00:44:01,700
flaws, the code doesn't compile.
Because then the analysis true 

940
00:44:01,700 --> 00:44:03,900
kicks in and says, well, you 
haven't checked for now here. 

941
00:44:03,900 --> 00:44:06,600
And you should do that. 
I also turned all warnings into 

942
00:44:06,600 --> 00:44:09,200
errors so it's simply not going 
to compile in that case. 

943
00:44:09,500 --> 00:44:11,500
And that means, I don't have to 
write a test for it because I 

944
00:44:11,500 --> 00:44:14,100
have another thing that drives 
that particular change. 

945
00:44:14,500 --> 00:44:17,400
I take whatever I can get from 
all sorts of different shelves 

946
00:44:17,400 --> 00:44:21,100
and combined it into something, 
where I try very much to always 

947
00:44:21,100 --> 00:44:24,500
have some sort of external 
thing, that pushes me to write 

948
00:44:24,500 --> 00:44:26,800
code in a certain way, because 
then I also have a degree of 

949
00:44:26,800 --> 00:44:29,300
confidence that Nick cooked us. 
What it's supposed to do. 

950
00:44:30,000 --> 00:44:31,700
Thanks for sharing this powerful
concept. 

951
00:44:31,700 --> 00:44:34,400
I think it's really powerful 
because sometimes we change code

952
00:44:34,400 --> 00:44:37,200
out of our curiosity or maybe 
certain ways that you mentioned 

953
00:44:37,200 --> 00:44:39,000
in the beginning. 
But I think the lesson here is 

954
00:44:39,000 --> 00:44:42,800
that find the appropriate 
drivers and then use that as the

955
00:44:42,800 --> 00:44:45,800
motivation to change the code. 
Code instead of just changing 

956
00:44:45,800 --> 00:44:48,900
for the sake of changing it and 
you mentioned about poke, okay? 

957
00:44:48,900 --> 00:44:51,100
I don't know how to pronounce it
and you compare that with the 

958
00:44:51,100 --> 00:44:53,900
Swiss Army, kind of behavior 
where you have, simply 

959
00:44:53,900 --> 00:44:57,300
everything you can do anything. 
But I think foolproof, maybe 

960
00:44:57,300 --> 00:45:00,400
API, design, contract, whatever,
that is very simple for people 

961
00:45:00,400 --> 00:45:02,600
to understand right. 
Again, that if it's in your 

962
00:45:02,600 --> 00:45:04,900
head, probably rather than 
having to understand the 

963
00:45:04,908 --> 00:45:08,300
context, how to use the thing, 
there's another powerful 

964
00:45:08,300 --> 00:45:11,000
practice that you mentioned for 
API design, which is this 

965
00:45:11,000 --> 00:45:13,400
pattern called command query 
separation. 

966
00:45:13,700 --> 00:45:16,400
I think this is also Worth to 
explain for people so that they 

967
00:45:16,400 --> 00:45:19,600
can improve their API design. 
Maybe you can explain what is 

968
00:45:19,600 --> 00:45:23,300
command query, separation there.
So that's an idea from Baskin 

969
00:45:23,300 --> 00:45:27,500
Meyer, which goes back to the 
middle of the 1980s bathroom. 

970
00:45:27,500 --> 00:45:31,000
I invented this language called 
Eiffel and he was a Pioneer in 

971
00:45:31,100 --> 00:45:33,500
object-oriented programming. 
He thought it would be a good 

972
00:45:33,500 --> 00:45:37,100
idea to distinguish between two 
types of operations. 

973
00:45:37,200 --> 00:45:39,600
We call one of them commands and
he called the other one queries 

974
00:45:39,900 --> 00:45:42,800
if I should explain this as 
succinctly as possible command 

975
00:45:42,800 --> 00:45:46,400
is something that changes this. 
State of basically observable 

976
00:45:46,400 --> 00:45:48,300
universe. 
So that might be something like 

977
00:45:48,300 --> 00:45:50,600
if your software sends an email 
that changes the state of the 

978
00:45:50,600 --> 00:45:52,500
universe. 
If it adds a road to the 

979
00:45:52,500 --> 00:45:55,300
database that's also changing 
the state of the application, at

980
00:45:55,300 --> 00:45:58,800
least, if repaints, the screen 
change the pixels on your 

981
00:45:58,800 --> 00:46:00,900
screen, that also changes the 
state of things. 

982
00:46:01,200 --> 00:46:03,900
So, all of those things we call 
side effects better. 

983
00:46:03,900 --> 00:46:07,500
My, I thought that if you have a
side effect, the API and 

984
00:46:07,500 --> 00:46:11,200
operational methods, should then
be about side effects on the 

985
00:46:11,200 --> 00:46:13,100
other hand. 
If you want to have some data, 

986
00:46:13,200 --> 00:46:16,300
then you should have Kind of 
operation that can go and read 

987
00:46:16,300 --> 00:46:18,400
data from somewhere and return 
data. 

988
00:46:18,700 --> 00:46:21,800
It might also just be hard, 
coded data or calculation like 

989
00:46:21,800 --> 00:46:24,700
adding numbers together, but, 
you know, if you want data, 

990
00:46:24,900 --> 00:46:27,500
that's a different operation and
he call that queries. 

991
00:46:27,800 --> 00:46:29,500
So it doesn't have to be a 
database query. 

992
00:46:29,500 --> 00:46:32,300
It could be any sort of thing 
that produces data. 

993
00:46:32,300 --> 00:46:35,100
That's on my I said it's not a 
good idea to mix those two 

994
00:46:35,100 --> 00:46:37,100
things together, right? 
If you want to produce that. 

995
00:46:37,100 --> 00:46:39,300
So then produce started don't 
mix them. 

996
00:46:39,600 --> 00:46:43,000
So that's command. 
Curry separation, separate those

997
00:46:43,000 --> 00:46:45,200
two things. 
You still You thought about them

998
00:46:45,200 --> 00:46:48,300
as belonging to the same class 
so you can have a class of 

999
00:46:48,300 --> 00:46:50,800
objects and then some of the 
methods would be changing the 

1000
00:46:50,808 --> 00:46:53,700
state of the object and then 
other methods would be methods 

1001
00:46:53,700 --> 00:46:56,200
that produce data and maybe 
about the contents of the 

1002
00:46:56,200 --> 00:46:58,100
object. 
So his idea was, you could 

1003
00:46:58,100 --> 00:47:00,200
definitely mix them on the same 
object. 

1004
00:47:00,200 --> 00:47:03,000
But each method used in 
isolation, should be doing one 

1005
00:47:03,000 --> 00:47:06,100
of those things and not both. 
That's the general idea. 

1006
00:47:07,000 --> 00:47:09,700
Yeah, I think this pattern 
really is powerful because I 

1007
00:47:09,700 --> 00:47:13,100
once worked with a code that has
no separation of this, like we 

1008
00:47:13,100 --> 00:47:14,700
produce side effects, you 
Something. 

1009
00:47:14,700 --> 00:47:17,200
And also you read them may be 
the result of that or maybe some

1010
00:47:17,200 --> 00:47:19,300
other extra computation 
afterwards. 

1011
00:47:19,500 --> 00:47:21,700
So it makes it slightly more 
difficult to trace. 

1012
00:47:21,700 --> 00:47:23,800
And also understand what is 
actually happening. 

1013
00:47:24,100 --> 00:47:27,100
I think this pattern is really 
worth to implement in your code.

1014
00:47:27,600 --> 00:47:31,300
Yeah I actually didn't explain 
why it's beneficial to think, 

1015
00:47:31,300 --> 00:47:33,700
the reason why this is 
beneficial is that again, 

1016
00:47:33,700 --> 00:47:36,300
particularly if you're looking 
at things that have a static 

1017
00:47:36,300 --> 00:47:39,700
type system, if you have an 
operation that is a command 

1018
00:47:39,700 --> 00:47:42,400
only, you know, it's all about 
the side effects and it's not 

1019
00:47:42,400 --> 00:47:44,200
allowed to produce any sort of 
output. 

1020
00:47:44,700 --> 00:47:47,600
It's very recognizable because 
you always tell by the method 

1021
00:47:47,600 --> 00:47:50,600
signature that it has void, it 
has no return value. 

1022
00:47:50,900 --> 00:47:53,900
So that means whenever you 
encounter something that is void

1023
00:47:53,900 --> 00:47:56,400
that has no return value, you 
know, it's going to be about the

1024
00:47:56,400 --> 00:47:59,300
side effect. 
So this is a big if but then if 

1025
00:47:59,300 --> 00:48:02,700
you know that a particular code 
base is designed according to 

1026
00:48:02,700 --> 00:48:05,400
the command crew separation 
principle, then you know that 

1027
00:48:05,400 --> 00:48:08,600
whenever you run into something 
that does produce an output, it 

1028
00:48:08,600 --> 00:48:12,500
will have no side effects. 
Again, this is a big conditional

1029
00:48:12,500 --> 00:48:14,900
thing here saying. 
Well, you have to Be able to 

1030
00:48:14,900 --> 00:48:17,100
trust that this code follows the
principle. 

1031
00:48:17,300 --> 00:48:20,400
I've worked with code bases, 
that follow this principle in a 

1032
00:48:20,400 --> 00:48:23,400
systematically, and it just 
makes things so much easier 

1033
00:48:23,400 --> 00:48:25,900
because that means whenever 
you're looking at an API and 

1034
00:48:25,900 --> 00:48:28,500
maybe it's not something you're 
familiar with, oh, you forgot. 

1035
00:48:28,500 --> 00:48:30,700
Even if you wrote it, you 
forgotten how you did it. 

1036
00:48:30,700 --> 00:48:33,100
You don't have to go and read 
the actual implementation code, 

1037
00:48:33,100 --> 00:48:35,700
you just look at the API and 
say, oh, this one has voiced. 

1038
00:48:35,700 --> 00:48:37,300
Its co-producing. 
So the side effect. 

1039
00:48:37,400 --> 00:48:40,700
Oh, this return starter. 
I know that it's safe to call it

1040
00:48:41,000 --> 00:48:43,100
because even if I called it too 
many times, the only thing 

1041
00:48:43,100 --> 00:48:45,100
that's going to happen here is 
that That it might use some 

1042
00:48:45,100 --> 00:48:47,700
extra CPU Cycles but it's not 
going to change the state of the

1043
00:48:47,700 --> 00:48:51,200
system and being able to just 
add a glance which of those two 

1044
00:48:51,200 --> 00:48:54,000
buckets. 
So particular method Falls that 

1045
00:48:54,000 --> 00:48:57,000
just saves you so much time 
because now you don't have to go

1046
00:48:57,000 --> 00:48:58,900
and read implementation in order
to understand. 

1047
00:48:58,900 --> 00:49:02,100
She said, one or the other so 
there's just fewer surprises in 

1048
00:49:02,100 --> 00:49:04,800
the code base like that when we 
go back and talk about reading 

1049
00:49:04,800 --> 00:49:08,300
time, let's just freeze. 
Our breeding time that cuts down

1050
00:49:08,300 --> 00:49:10,100
on the number of different 
files. 

1051
00:49:10,100 --> 00:49:11,900
You have to go and visit in 
order to understand what's going

1052
00:49:11,908 --> 00:49:12,900
on. 
I'm not saying that it 

1053
00:49:12,900 --> 00:49:15,600
completely eliminates the need 
to And we do the thing but it 

1054
00:49:15,600 --> 00:49:19,200
saves you some time there, it 
definitely will save our brain 

1055
00:49:19,200 --> 00:49:23,100
cycle, not to be able to read 
multiple files again following 

1056
00:49:23,100 --> 00:49:25,300
the principles strictly. 
I think that's still the 

1057
00:49:25,300 --> 00:49:28,700
keyword, and also maybe the 
naming of the API design itself,

1058
00:49:28,700 --> 00:49:31,500
the methods or the function name
or whatever API. 

1059
00:49:31,700 --> 00:49:34,000
So that is also must be 
self-explanatory. 

1060
00:49:34,200 --> 00:49:36,500
Advising and you will have this 
cognitive load to guess. 

1061
00:49:36,500 --> 00:49:38,400
Okay, what is this function 
about? 

1062
00:49:38,600 --> 00:49:41,300
So marketing, there are plenty 
more practices that you have in 

1063
00:49:41,300 --> 00:49:43,600
the book, right? 
So I really highly suggest the 

1064
00:49:43,600 --> 00:49:45,600
listeners here. 
To read the book because in 

1065
00:49:45,600 --> 00:49:47,900
preparation of this recording, I
actually took a loop. 

1066
00:49:48,000 --> 00:49:50,200
There are so many tears and 
insights there. 

1067
00:49:50,400 --> 00:49:51,900
I think this book is really 
great. 

1068
00:49:52,100 --> 00:49:54,500
Thanks for writing this. 
If you haven't check it out, 

1069
00:49:54,500 --> 00:49:56,200
please do check. 
And I'll put it in the show 

1070
00:49:56,200 --> 00:49:57,500
notes. 
How you can get the book as 

1071
00:49:57,500 --> 00:49:59,400
well. 
Unfortunately, you to time, we 

1072
00:49:59,400 --> 00:50:02,200
have to end this conversation. 
So Before I Let You Go, 

1073
00:50:02,200 --> 00:50:05,200
normally, I have this one last 
question that I asked to all my 

1074
00:50:05,200 --> 00:50:07,600
guests, which is what you to 
share your tree. 

1075
00:50:07,600 --> 00:50:08,900
Technical leadership is. 
Mmm. 

1076
00:50:09,100 --> 00:50:11,700
So think of it like an advisor. 
You want to give to the 

1077
00:50:11,700 --> 00:50:14,000
listeners here so that they can 
follow. 

1078
00:50:14,400 --> 00:50:17,000
Maybe do your best practice, 
okay? 

1079
00:50:17,000 --> 00:50:19,800
So the first one, doesn't sound 
like a technical advice, but I 

1080
00:50:19,808 --> 00:50:22,300
think is very useful for 
technical people. 

1081
00:50:22,500 --> 00:50:25,200
Take breaks, I regularly take 
breaks. 

1082
00:50:25,400 --> 00:50:28,200
I run the Pomodoro Timer. 
So, I work for 25 minutes and 

1083
00:50:28,200 --> 00:50:29,400
then, let's take a five-minute 
break. 

1084
00:50:29,600 --> 00:50:32,300
So, that's one thing. 
But I also during the day often 

1085
00:50:32,300 --> 00:50:35,700
take longer breaks where I go 
grocery shopping or go and do 

1086
00:50:35,700 --> 00:50:37,100
the dishes or other things like 
that. 

1087
00:50:37,200 --> 00:50:39,500
The reason for that is, again, 
this has something to do with 

1088
00:50:39,500 --> 00:50:41,900
how the brain works. 
I'm not sure I completely 

1089
00:50:41,900 --> 00:50:44,900
understand what's going on here,
but I get old my insights. 

1090
00:50:44,900 --> 00:50:48,100
When I'm away from the computer,
I can sit and look at code or 

1091
00:50:48,100 --> 00:50:50,000
problem. 
Definitions for a long time. 

1092
00:50:50,100 --> 00:50:53,000
And not really go anywhere. 
And then I go grocery shopping 

1093
00:50:53,200 --> 00:50:54,700
while I'm in the supermarket. 
I'll go. 

1094
00:50:54,800 --> 00:50:57,000
Oh, now I know what I need to do
and then they could go back and 

1095
00:50:57,000 --> 00:51:00,500
actually do something useful. 
So if at all possible, take 

1096
00:51:00,500 --> 00:51:03,500
breaks during the day, that's 
really gonna help your brain to 

1097
00:51:03,500 --> 00:51:07,200
come up with good ideas. 
The second tip or advice I would

1098
00:51:07,200 --> 00:51:10,900
say is that, if at all possible?
See if you can get to continuous

1099
00:51:10,900 --> 00:51:13,100
delivery. 
I'm basing this advice on this 

1100
00:51:13,100 --> 00:51:16,200
book called accelerate by And he
called for screen and Jin Kim. 

1101
00:51:16,200 --> 00:51:19,000
And just humble, you could 
discuss whether you want to call

1102
00:51:19,000 --> 00:51:20,700
it research. 
I think research is a fair 

1103
00:51:20,700 --> 00:51:22,800
enough work to use. 
So it's based on a lot of 

1104
00:51:22,800 --> 00:51:25,100
surveys. 
Just like 50,000 people answered

1105
00:51:25,100 --> 00:51:27,200
the survey. 
It seems like the single most 

1106
00:51:27,200 --> 00:51:30,400
important thing in order to 
determine whether or not your 

1107
00:51:30,400 --> 00:51:32,200
organization Works effectively 
or not. 

1108
00:51:32,200 --> 00:51:35,200
Is, can you do continuous 
delivery because so many other 

1109
00:51:35,200 --> 00:51:38,600
things will sort of come as a 
by-product in that Journey 

1110
00:51:38,600 --> 00:51:41,300
towards continuous delivery and 
it's a big Journey if you don't 

1111
00:51:41,300 --> 00:51:43,900
already doing it. 
But it's really worthwhile to go

1112
00:51:43,900 --> 00:51:45,400
in that. 
That direction that would 

1113
00:51:45,400 --> 00:51:47,400
definitely be something that I 
would look into. 

1114
00:51:47,800 --> 00:51:50,300
The last thing I want to say is,
if you're interested in code, 

1115
00:51:50,300 --> 00:51:52,600
the fish in your head, learn 
functional programming. 

1116
00:51:52,900 --> 00:51:55,500
I have an argument to prove, 
again, that sort of takes this 

1117
00:51:55,500 --> 00:51:58,100
idea, we talk about democracy 
operation little bit further and

1118
00:51:58,100 --> 00:52:01,300
say, well, if we add another 
constraint, another idea to this

1119
00:52:01,300 --> 00:52:04,100
idea about queries and say, not 
only must they be side-effect 

1120
00:52:04,100 --> 00:52:06,200
free. 
They must also be deterministic,

1121
00:52:06,400 --> 00:52:08,400
you have something called a pure
function. 

1122
00:52:08,600 --> 00:52:10,700
There are various reasons why I 
argue in the book. 

1123
00:52:10,700 --> 00:52:13,200
Why that actually fits in your 
brain very well. 

1124
00:52:13,500 --> 00:52:15,400
So definitely. 
Leave courage people to learn 

1125
00:52:15,400 --> 00:52:18,200
some functional programming, the
best language to really 

1126
00:52:18,200 --> 00:52:20,100
understand functional program 
with this Haskell. 

1127
00:52:20,200 --> 00:52:21,900
But it's also really difficult 
to learn. 

1128
00:52:22,100 --> 00:52:24,800
If you're up to the challenge, 
if you're curious and I would 

1129
00:52:24,800 --> 00:52:28,400
recommend that they in my 
previous episode, I had a chance

1130
00:52:28,400 --> 00:52:32,100
to talk to Scott lotion, so he 
Advocates, F sharp F. 

1131
00:52:32,100 --> 00:52:33,700
Sharp is a wonderful language as
well. 

1132
00:52:33,900 --> 00:52:36,500
I write quite a bit of a shot as
well, for me. 

1133
00:52:36,500 --> 00:52:39,800
It was a great stepping stone. 
So I came from C sharp, and then

1134
00:52:39,800 --> 00:52:42,000
I'd learned F-sharp. 
And then from a shop, I learned 

1135
00:52:42,000 --> 00:52:43,500
high school and that was 
actually great. 

1136
00:52:43,700 --> 00:52:45,300
I don't know. 
If I could have learned Haskell 

1137
00:52:45,300 --> 00:52:47,800
straight from C sharp that might
not actually have been the case.

1138
00:52:48,000 --> 00:52:51,000
But spending some years with 
their shop enabled, me to then 

1139
00:52:51,000 --> 00:52:53,900
learn Haskell later on. 
If you ask me, which language 

1140
00:52:53,900 --> 00:52:56,600
would I pick from all the 
languages that I know for an 

1141
00:52:56,600 --> 00:52:59,300
important project I would 
probably pick up shop because 

1142
00:52:59,300 --> 00:53:02,500
while I really like Haskell, I'm
not so convinced that the 

1143
00:53:02,500 --> 00:53:05,100
ecosystem is actually something 
that you would b. 

1144
00:53:05,100 --> 00:53:08,700
A real Enterprise on, whereas I 
knew that if Charles is running 

1145
00:53:08,700 --> 00:53:11,300
on the.net framework and I know 
that I can trust that pretty 

1146
00:53:11,300 --> 00:53:13,500
well, he mentioned about this as
well. 

1147
00:53:13,800 --> 00:53:17,200
So, As for this wisdom Mark has 
been a pleasant to talk to you 

1148
00:53:17,200 --> 00:53:19,800
and discuss about this idea 
could that fits in your head. 

1149
00:53:20,000 --> 00:53:23,000
So for people who want to follow
you or find out more from the 

1150
00:53:23,000 --> 00:53:26,100
book, where can they find it 
online to find me? 

1151
00:53:26,100 --> 00:53:29,100
That's probably the existing, I 
have this blog called block the 

1152
00:53:29,100 --> 00:53:30,600
plate. 
The Decay that's the address 

1153
00:53:30,900 --> 00:53:33,800
from there, you can find links 
to the book and to my Twitter 

1154
00:53:33,800 --> 00:53:37,300
profile and anything else, but 
otherwise you just using your 

1155
00:53:37,300 --> 00:53:40,100
favorite web search engine and 
searching for go to fit in your 

1156
00:53:40,100 --> 00:53:41,100
head. 
It's probably going to work 

1157
00:53:41,100 --> 00:53:43,900
pretty well as well. 
Thanks again for your time today

1158
00:53:43,900 --> 00:53:45,400
mark. 
It's been a pleasant learning 

1159
00:53:45,400 --> 00:53:46,800
from you. 
So thanks again. 

1160
00:53:47,800 --> 00:53:49,400
It was a pleasure, thank you for
having me. 

1161
00:53:52,100 --> 00:53:55,400
Thank you for listening to this 
episode and for staying, right 

1162
00:53:55,400 --> 00:53:57,900
until the end if you highly 
enjoyed it. 

1163
00:53:58,000 --> 00:54:00,400
I would appreciate if you share 
it with your friends and 

1164
00:54:00,400 --> 00:54:03,400
colleagues who you think would 
also benefit from listening to 

1165
00:54:03,400 --> 00:54:05,400
this episode. 
And if you are new to the 

1166
00:54:05,400 --> 00:54:08,400
podcast, make sure to subscribe 
and leave me your valuable 

1167
00:54:08,400 --> 00:54:11,000
review and feedback. 
It helps me a lot. 

1168
00:54:11,000 --> 00:54:13,000
In order to grow this podcast 
better. 

1169
00:54:13,400 --> 00:54:16,300
You can also find the full show 
notes of this conversation on 

1170
00:54:16,300 --> 00:54:20,400
the episode page, at Tech Legion
o.f website, including the full 

1171
00:54:20,400 --> 00:54:23,800
transcript enter, In quotes and 
links to the resources 

1172
00:54:23,800 --> 00:54:25,700
mentioned, from the 
conversation. 

1173
00:54:26,000 --> 00:54:29,100
And lastly, make sure to 
subscribe to the shows mailing 

1174
00:54:29,100 --> 00:54:31,400
list on package. 
You know, that deaf to get 

1175
00:54:31,400 --> 00:54:33,600
notified for any future 
episodes. 

1176
00:54:34,100 --> 00:54:36,500
Stay tuned for the next 
technology, no episode. 

1177
00:54:36,800 --> 00:54:38,500
And until then goodbye.