1
00:00:00,040 --> 00:00:04,120
As people, as individuals, we 
need to change our ways of 

2
00:00:04,120 --> 00:00:06,720
working, where we give 
importance to the work that we 

3
00:00:06,720 --> 00:00:10,680
do in terms of the quality that 
we deliver and ensure that we 

4
00:00:10,680 --> 00:00:13,360
keep raising our bar. 
So software craftsmanship is 

5
00:00:13,360 --> 00:00:17,920
something that we need to work 
on as individuals and also pass 

6
00:00:17,920 --> 00:00:20,240
it on to the next generation of 
developers who work with you in 

7
00:00:20,240 --> 00:00:23,160
your respective organizations so
that they get to learn from you.

8
00:00:23,160 --> 00:00:31,790
I mean you lead by example. 
Hey everyone, my name is Henry 

9
00:00:31,790 --> 00:00:35,950
Surya Virawan and you're 
listening to the Technically 

10
00:00:35,950 --> 00:00:39,110
Journal Podcast, the show where 
I'll be bringing you the 

11
00:00:39,110 --> 00:00:42,230
greatest technical leaders, 
practitioners and thought 

12
00:00:42,230 --> 00:00:45,630
leaders in the industry to 
discuss about their journey, 

13
00:00:45,910 --> 00:00:50,390
ideas and practices that we all 
can learn and apply to build a 

14
00:00:50,390 --> 00:00:53,950
highly performing technical team
and to make an impact in your 

15
00:00:53,950 --> 00:00:57,150
personal work. 
So let's dive into our journal. 

16
00:01:02,180 --> 00:01:04,379
Hey everyone, you're listening 
to the Technically Journal 

17
00:01:04,379 --> 00:01:07,180
Podcast, the podcast where you 
can learn about technical 

18
00:01:07,180 --> 00:01:10,180
leadership and excellence from 
my conversations with great 

19
00:01:10,180 --> 00:01:11,940
thought leaders in the tech 
industry. 

20
00:01:12,660 --> 00:01:15,140
If this is your first time 
listening, don't forget to 

21
00:01:15,140 --> 00:01:18,060
subscribe on your favorite 
podcast app to get notified for 

22
00:01:18,060 --> 00:01:20,700
future episodes. 
Also, subscribe to Technically 

23
00:01:20,700 --> 00:01:24,340
Journal's various other contents
on LinkedIn, Twitter, Instagram,

24
00:01:24,500 --> 00:01:27,440
YouTube, and Tiktok. 
And if you have been enjoying 

25
00:01:27,440 --> 00:01:31,240
this podcast and its contents, 
support my work by either buying

26
00:01:31,240 --> 00:01:35,480
me a coffee at techledjournal 
dot dev tip or becoming a patron

27
00:01:35,520 --> 00:01:37,880
at techledjournal dot dev 
Patron. 

28
00:01:38,760 --> 00:01:41,920
My guest for today's episode is 
Srihari Sridharan. 

29
00:01:42,320 --> 00:01:45,720
Srihari is a software architect 
and the author of Craft Your 

30
00:01:45,720 --> 00:01:48,640
Code. 
In this episode we discussed 

31
00:01:48,640 --> 00:01:51,480
software craftsmanship and how 
to become better software 

32
00:01:51,480 --> 00:01:54,600
engineers. 
Srihari first began by sharing 

33
00:01:54,600 --> 00:01:57,280
the relationship between 
software craftsmanship and high 

34
00:01:57,280 --> 00:02:00,120
quality code. 
He described some practices for 

35
00:02:00,120 --> 00:02:03,640
improving code quality, such as 
establishing coding standards, 

36
00:02:03,920 --> 00:02:08,000
improving code readability, 
doing effective code review, and

37
00:02:08,000 --> 00:02:11,560
managing technical depth. 
He also explained the importance

38
00:02:11,560 --> 00:02:13,800
of software engineers 
understanding different 

39
00:02:13,800 --> 00:02:15,920
architectural styles and domain 
knowledge. 

40
00:02:16,480 --> 00:02:19,600
Srihari also shared strategies 
for creating high performing 

41
00:02:19,600 --> 00:02:21,940
teams. 
By establishing psychological 

42
00:02:21,940 --> 00:02:25,700
safety and trust. 
I hope you enjoy listening to 

43
00:02:25,700 --> 00:02:28,140
this episode and learn some 
insights about software 

44
00:02:28,140 --> 00:02:30,660
craftsmanship and becoming a 
better software engineer. 

45
00:02:31,100 --> 00:02:34,100
If you enjoy listening to this 
episode, please share with your 

46
00:02:34,100 --> 00:02:37,260
colleagues, your friends and 
communities and leave a 5 star 

47
00:02:37,260 --> 00:02:40,180
rating and review on Apple 
Podcast and Spotify. 

48
00:02:40,940 --> 00:02:44,220
Your small help will help me a 
lot in getting more people to 

49
00:02:44,220 --> 00:02:47,580
discover and listen to this 
podcast and I really appreciate 

50
00:02:47,580 --> 00:02:49,530
it. 
So let's now go to my 

51
00:02:49,530 --> 00:02:54,850
conversation with Srihari. 
Welcome to Technically Journal 

52
00:02:54,850 --> 00:02:57,210
Podcast Show. 
Today we have Srihari here. 

53
00:02:57,250 --> 00:02:59,570
Really looking forward to 
discuss things about software 

54
00:02:59,570 --> 00:03:03,130
craftsmanship, how to make your 
software quality higher and 

55
00:03:03,130 --> 00:03:05,850
things like that. 
So welcome to the show, Srihari.

56
00:03:06,490 --> 00:03:08,050
Hi, Henry. 
Thanks for the opportunity. 

57
00:03:08,690 --> 00:03:11,690
So Srihari, in the beginning I 
would like to ask you first to 

58
00:03:11,690 --> 00:03:14,370
share your career journey. 
Maybe if you can give us some 

59
00:03:14,370 --> 00:03:16,490
highlights or turning points 
that you think we all can learn 

60
00:03:16,490 --> 00:03:18,710
from you. 
Sure, Henry. 

61
00:03:18,990 --> 00:03:22,550
So I'm close to two decades of 
industry experience working 

62
00:03:22,550 --> 00:03:25,670
across different products and 
services organizations I've been

63
00:03:25,670 --> 00:03:29,470
in both in product development 
as well as in the services side 

64
00:03:29,470 --> 00:03:31,750
of things. 
We're doing consulting with the 

65
00:03:31,750 --> 00:03:34,110
clients on different domains and
trying to solve complex 

66
00:03:34,110 --> 00:03:37,030
problems. 
So that is my journey across 

67
00:03:37,030 --> 00:03:40,150
this two decades across seven 
different operations. 

68
00:03:40,670 --> 00:03:44,190
And apart from my day job, I do 
reviews and proofreading for 

69
00:03:44,190 --> 00:03:47,430
Manning publications, which I 
started back in 2017. 

70
00:03:47,680 --> 00:03:52,520
So I get to review the titles of
interest and try to proofread 

71
00:03:52,520 --> 00:03:54,960
them and provide feedback to the
authors and closely interact 

72
00:03:54,960 --> 00:03:56,920
with them. 
And that is why I think we also 

73
00:03:56,920 --> 00:03:59,840
got connected through LinkedIn 
discussing about books and 

74
00:03:59,840 --> 00:04:02,320
stuff. 
And apart from that, as a pro 

75
00:04:02,320 --> 00:04:05,920
bono activity, I do connect with
the university here in Chennai 

76
00:04:06,200 --> 00:04:09,920
where I get to decide the 
curriculum for the students who 

77
00:04:09,920 --> 00:04:12,000
are doing engineering as part of
their studies. 

78
00:04:12,320 --> 00:04:15,320
So this is to bridge the gap 
between the academic curriculum 

79
00:04:15,320 --> 00:04:18,300
that is there today and what the
industry actually wants. 

80
00:04:18,300 --> 00:04:20,339
I mean, the curriculum should 
actually help them in two ways. 

81
00:04:20,380 --> 00:04:23,180
Either it should help them find 
a job or help them for their 

82
00:04:23,180 --> 00:04:25,300
higher studies. 
So I'm just trying to bridge the

83
00:04:25,300 --> 00:04:28,420
gap because the industry is very
fast moving and there are a lot 

84
00:04:28,420 --> 00:04:29,660
of changes that are coming our 
way. 

85
00:04:29,900 --> 00:04:32,820
So that's the idea, Henry. 
I mean, that's a short summary 

86
00:04:32,820 --> 00:04:35,900
of what I'm doing. 
This episode is brought to you 

87
00:04:35,900 --> 00:04:39,780
by Miro, as you will hear in 
this episode later about the 

88
00:04:39,780 --> 00:04:43,700
power of mind maps and note 
taking finding a tool that can 

89
00:04:43,700 --> 00:04:45,940
support creating comprehensive 
mind maps. 

90
00:04:46,320 --> 00:04:49,200
While also supporting 
collaboration can be quite a 

91
00:04:49,200 --> 00:04:53,560
challenge, one tool I find that 
allows us to do so effectively 

92
00:04:53,880 --> 00:04:59,920
and in a fun way is Miro Miro. 
At a first glance, it might seem

93
00:04:59,920 --> 00:05:03,000
just like a simple digital 
whiteboard, but Miro's 

94
00:05:03,000 --> 00:05:05,040
capabilities run far beyond 
that. 

95
00:05:05,560 --> 00:05:08,840
It's a visual collaboration tool
where the whole team can build 

96
00:05:08,840 --> 00:05:12,880
on each other's ideas and create
something innovative together 

97
00:05:12,880 --> 00:05:15,880
from anywhere. 
Brainstorming and strategic 

98
00:05:15,880 --> 00:05:19,840
planning become easier when it's
visual and accessible, and it 

99
00:05:19,840 --> 00:05:23,840
can all happen across teams. 
In mirror, you can quickly start

100
00:05:23,840 --> 00:05:27,080
collaborating within 90 seconds 
without having everyone 

101
00:05:27,080 --> 00:05:29,160
registered as a mirror user 
before. 

102
00:05:29,680 --> 00:05:33,120
There are also more than 300 
predefined templates you can use

103
00:05:33,120 --> 00:05:35,960
to kick start your collaboration
within seconds. 

104
00:05:36,400 --> 00:05:39,760
So the next time you are looking
for a digital tool to support 

105
00:05:39,760 --> 00:05:42,920
your brainstorming, designing, 
planning, and online 

106
00:05:42,920 --> 00:05:45,380
collaboration. 
Do give Mirror a try. 

107
00:05:45,780 --> 00:05:48,860
You can Sign up today at 
mirror.com/podcast, 

108
00:05:49,340 --> 00:05:54,100
miro.com/podcast, and your first
three mirror boards. 

109
00:05:54,100 --> 00:05:56,300
Are free forever when you sign 
up now. 

110
00:05:56,540 --> 00:05:58,540
And now let's get back to our 
episode. 

111
00:05:58,900 --> 00:06:00,100
Thank you so much. 
Very interesting. 

112
00:06:00,100 --> 00:06:02,700
You have a day job in a 
consulting company. 

113
00:06:02,700 --> 00:06:05,860
You also review books, right? 
I think you you are part of the 

114
00:06:05,860 --> 00:06:08,180
reviewers of many great titles 
from Manning. 

115
00:06:08,540 --> 00:06:10,860
And the last one you do pro bono
for university. 

116
00:06:11,210 --> 00:06:14,370
So maybe a little bit, if I can 
ask about your pro bono part, 

117
00:06:14,370 --> 00:06:16,050
right. 
So you have been helping the 

118
00:06:16,050 --> 00:06:19,370
university to bridge the gap and
you are also now the author of 

119
00:06:19,370 --> 00:06:22,250
the Craft Your Code. 
Where do you see the biggest gap

120
00:06:22,250 --> 00:06:25,770
between university students and 
also from the practical side of 

121
00:06:25,770 --> 00:06:28,770
view, when they go into the job 
as a software developer? 

122
00:06:29,570 --> 00:06:32,250
Yeah, that's right. 
I mean, things have improved a 

123
00:06:32,250 --> 00:06:36,170
lot in the current situation. 
I mean, a lot of students get to

124
00:06:36,170 --> 00:06:39,010
study about programming 
languages and stuff early in 

125
00:06:39,010 --> 00:06:42,160
their school days. 
When back then when we used to 

126
00:06:42,160 --> 00:06:45,760
study, probably we were not so 
lucky to read programming 

127
00:06:45,760 --> 00:06:48,560
languages early. 
But again today I see students 

128
00:06:48,560 --> 00:06:51,520
are reading much earlier. 
So what happens when they come 

129
00:06:51,520 --> 00:06:54,600
to the university, the subjects 
so need a revision. 

130
00:06:55,000 --> 00:06:58,680
I mean revision in the sense 
what is going to make you do 

131
00:06:58,720 --> 00:07:02,080
things practically, like how 
will you be able to work, apply 

132
00:07:02,080 --> 00:07:04,840
your skills that you learn in 
the industry, how you get 

133
00:07:04,840 --> 00:07:06,840
industry ready because the 
industry is moving at a very 

134
00:07:06,840 --> 00:07:08,960
fast pace. 
Given that you have generative 

135
00:07:09,000 --> 00:07:13,030
AI and other stuff today, how do
we equip students to adjust to 

136
00:07:13,030 --> 00:07:14,550
the new curriculum? 
Forget students, even 

137
00:07:14,550 --> 00:07:17,150
professionals, as we need to 
adjust ourselves to the new 

138
00:07:17,390 --> 00:07:20,670
modern world in terms of the 
current demands, right. 

139
00:07:21,190 --> 00:07:24,790
So that is where I tried to look
into the existing syllabus that 

140
00:07:24,790 --> 00:07:28,110
is there in the university and 
try to work closely with the 

141
00:07:28,310 --> 00:07:29,910
professors and the lecturers out
there. 

142
00:07:30,190 --> 00:07:34,230
Trying to share what to do from 
an industry perspective and what

143
00:07:34,230 --> 00:07:37,230
are the industry trends. 
And see if we could incorporate 

144
00:07:37,230 --> 00:07:40,620
certain subjects in the 
curriculum which actually 

145
00:07:40,740 --> 00:07:43,420
bridges the gap between what is 
there and what is there today. 

146
00:07:43,420 --> 00:07:47,620
So for example, when I studied, 
we never had papers on data 

147
00:07:47,620 --> 00:07:49,820
science we know as such data 
sense did not exist back then, 

148
00:07:49,820 --> 00:07:51,700
but data warehousing, other 
stuff was there. 

149
00:07:52,020 --> 00:07:54,940
I'm talking about 20 gets ago. 
So data warehousing was there, 

150
00:07:54,940 --> 00:07:57,500
database were there. 
I think we were lucky enough to 

151
00:07:57,500 --> 00:07:59,260
grow along with the languages 
and frameworks. 

152
00:07:59,660 --> 00:08:02,340
But today, those who get into 
the industry, they have a huge 

153
00:08:02,460 --> 00:08:06,140
mountain to climb in terms of 
learning, because every language

154
00:08:06,140 --> 00:08:10,360
has become very mature, every 
framework has matured, a lot of 

155
00:08:10,360 --> 00:08:13,360
features have come into the 
frameworks and languages and 

156
00:08:13,360 --> 00:08:15,080
there are a lot of streams as 
well. 

157
00:08:15,080 --> 00:08:17,480
I mean, we are looking more at 
specialization, right? 

158
00:08:17,480 --> 00:08:19,680
I mean, the subjects and the 
streams are getting very 

159
00:08:19,680 --> 00:08:22,160
specialized from a education 
standpoint. 

160
00:08:22,480 --> 00:08:25,600
So that is when we need to see 
the bigger picture, give them 

161
00:08:25,600 --> 00:08:28,000
the bigger picture first of all,
like give students a picture of 

162
00:08:28,000 --> 00:08:31,520
what exists, what you can choose
from and where do you want to 

163
00:08:31,520 --> 00:08:34,159
place yourself in the overall 
journey, right? 

164
00:08:34,320 --> 00:08:35,799
Maybe towards them. 
When we discuss about 

165
00:08:35,799 --> 00:08:37,799
architecture, we'll discuss 
about the importance of having 

166
00:08:37,799 --> 00:08:42,020
the bigger picture, right? 
But the essence is how and what 

167
00:08:42,020 --> 00:08:43,299
exists. 
Because when you take the 

168
00:08:43,299 --> 00:08:46,420
triangle of knowledge, right, 
there are things that you know, 

169
00:08:46,660 --> 00:08:49,340
they exist, and there are things
that you know but you don't 

170
00:08:49,340 --> 00:08:50,500
know. 
Basically, you don't know that 

171
00:08:50,500 --> 00:08:52,580
such a thing exists, but you 
know something exists but you 

172
00:08:52,580 --> 00:08:54,780
don't know about it. 
And the third thing is you don't

173
00:08:54,780 --> 00:08:56,740
know and you don't know. 
You don't know what exists and 

174
00:08:56,740 --> 00:08:58,420
you don't know such a thing 
exists, right? 

175
00:08:58,420 --> 00:09:02,380
So to help students start with 
things that they know they exist

176
00:09:02,380 --> 00:09:06,140
but they don't know about it and
try to educate them and bring 

177
00:09:06,140 --> 00:09:07,500
that awareness and take it 
forward. 

178
00:09:07,500 --> 00:09:09,580
So that's the idea of bridging 
this gap, Henry. 

179
00:09:10,020 --> 00:09:12,580
Yeah, a little bit empathy as 
well for those students or the 

180
00:09:12,580 --> 00:09:14,580
new people who just graduated, 
right? 

181
00:09:14,580 --> 00:09:17,380
So there are so many things in 
technology these days, right? 

182
00:09:17,380 --> 00:09:18,940
You just mentioned generative 
AI. 

183
00:09:18,940 --> 00:09:21,140
Maybe that's the buzzwords this 
day previously. 

184
00:09:21,140 --> 00:09:24,140
Data science, right, Previously 
blockchain and so many other 

185
00:09:24,140 --> 00:09:25,700
things that keep coming along, 
right. 

186
00:09:25,980 --> 00:09:28,780
I think it's really, really a 
big challenge for all those 

187
00:09:28,780 --> 00:09:30,980
people, including me, myself. 
I can't keep up. 

188
00:09:31,260 --> 00:09:33,780
With all these changes as well. 
So I think your work is really, 

189
00:09:33,780 --> 00:09:36,340
really tremendous in terms of 
helping them bridging the gap. 

190
00:09:36,780 --> 00:09:40,660
So moving on to maybe that's why
you write this book, right, 

191
00:09:40,660 --> 00:09:43,180
Craft your code, because I, I 
had a look and read off your 

192
00:09:43,180 --> 00:09:46,420
book in a glance, right. 
So you cover the breadth of the 

193
00:09:46,420 --> 00:09:48,740
technology from software 
engineering point of view, 

194
00:09:48,740 --> 00:09:50,780
right. 
So maybe if you can share a 

195
00:09:50,780 --> 00:09:53,460
little bit what was your 
motivation behind writing this 

196
00:09:53,460 --> 00:09:55,820
book, right? 
So maybe we can learn from that 

197
00:09:55,820 --> 00:09:57,910
story itself. 
Definitely. 

198
00:09:57,910 --> 00:10:01,430
So one cool thing that happened 
is it was back in 2018 when I 

199
00:10:01,430 --> 00:10:05,270
was actually having this idea of
writing this book and just to 

200
00:10:05,270 --> 00:10:08,550
explain that journey, right? 
I would had the idea, had the 

201
00:10:08,550 --> 00:10:11,790
proposal to write the book. 
But again, maybe I wasn't so 

202
00:10:11,870 --> 00:10:14,510
popular. 
I would say like I did not have 

203
00:10:14,510 --> 00:10:17,390
enough connection in the 
industry or the publishing front

204
00:10:17,630 --> 00:10:20,550
where I found it difficult to 
actually sell this idea of 

205
00:10:20,550 --> 00:10:23,230
writing a book on Crafty Code. 
Because you have industry 

206
00:10:23,230 --> 00:10:26,720
stalwarts like Robert C Martin 
who wrote Clean Code, you have 

207
00:10:26,720 --> 00:10:29,520
Steve McConnell who wrote Code 
Complete, you have paid good 

208
00:10:29,520 --> 00:10:31,840
life, who wrote Code Craft and a
lot of things, right? 

209
00:10:32,280 --> 00:10:35,760
And when you as an engineer, as 
a person want to write something

210
00:10:35,760 --> 00:10:38,400
about it, I mean, all of this is
about your experience. 

211
00:10:38,400 --> 00:10:41,080
Again, knowledge is borrowed, 
but the experiences are unique. 

212
00:10:41,480 --> 00:10:44,600
The experience that I wanted to 
share in this book was about 

213
00:10:44,600 --> 00:10:47,600
what I went through as a 
developer during my early days, 

214
00:10:47,600 --> 00:10:50,560
what I learned from my mentors, 
and what I learned from 

215
00:10:50,560 --> 00:10:51,920
experience. 
I just want to share that 

216
00:10:51,920 --> 00:10:54,360
knowledge with others and make 
it available. 

217
00:10:54,840 --> 00:10:58,200
So that is the whole motivation 
of actually coming up with this 

218
00:10:58,200 --> 00:11:00,720
idea of writing a book. 
And I wanted to make it a 

219
00:11:00,720 --> 00:11:03,520
polyglot in the sense give 
examples from multiple 

220
00:11:03,520 --> 00:11:06,320
languages, right? 
Actually, I'm working with 

221
00:11:06,400 --> 00:11:09,800
Manning on a proposal to 
actually write a book on the 

222
00:11:09,800 --> 00:11:13,840
next generation offered Crafty 
of Good with Generative AI where

223
00:11:14,360 --> 00:11:16,440
I tried to explore the 
possibilities of using Gen. 

224
00:11:16,440 --> 00:11:18,800
AI for software development and 
traffic code. 

225
00:11:18,800 --> 00:11:21,120
So that's the idea. 
Again, it's in the service 

226
00:11:21,120 --> 00:11:25,170
stages, so I cannot comment more
on it, but the idea is about 

227
00:11:25,210 --> 00:11:27,010
sharing that knowledge, which is
the core. 

228
00:11:27,330 --> 00:11:30,090
And as you know, authors don't 
write books to become rich. 

229
00:11:30,850 --> 00:11:32,930
They intend us not to make 
money, but the intent is to 

230
00:11:32,930 --> 00:11:35,810
share the knowledge. 
So that is the background of 

231
00:11:35,810 --> 00:11:37,410
this book, Henry. 
Yeah. 

232
00:11:37,410 --> 00:11:39,010
Thanks for sharing the 
background, right. 

233
00:11:39,010 --> 00:11:41,810
So, yeah, I mean, for people who
don't know yet, authors write 

234
00:11:41,810 --> 00:11:45,730
book not to get rich, right? 
Maybe some authors do because of

235
00:11:45,730 --> 00:11:48,610
the royalties and all the other 
things outside of the book, 

236
00:11:48,610 --> 00:11:50,330
right. 
But I think the first thing is 

237
00:11:50,330 --> 00:11:52,890
about instilling their knowledge
and share it with other people. 

238
00:11:53,410 --> 00:11:56,210
It's also about the legacy. 
Yeah, Sorry to cut you. 

239
00:11:56,210 --> 00:11:58,090
I mean, it's also about the 
legacy, Henry. 

240
00:11:58,090 --> 00:12:01,850
I mean leaving behind something 
for others to consume, right? 

241
00:12:02,130 --> 00:12:04,050
That's correct. 
And also, yeah, like you 

242
00:12:04,050 --> 00:12:06,130
mentioned, I find something 
interesting about your book, 

243
00:12:06,130 --> 00:12:07,730
right? 
You actually use Polygon 

244
00:12:07,810 --> 00:12:10,730
languages, right? 
So this is I think quite rare as

245
00:12:10,730 --> 00:12:12,370
well. 
I don't see much technical books

246
00:12:12,370 --> 00:12:15,610
also using multiple languages. 
There's pros and cons to that. 

247
00:12:15,610 --> 00:12:17,770
But I think, yeah, this is quite
unique in, in a sense. 

248
00:12:18,390 --> 00:12:20,670
So if I read. 
Your book I think, if I can pick

249
00:12:20,670 --> 00:12:23,630
a theme, one is about software 
craftsmanship and the other one 

250
00:12:23,630 --> 00:12:26,470
is about high quality code. 
So maybe if you can touch on a 

251
00:12:26,470 --> 00:12:29,270
little bit from your industry 
experience 2 decades, right? 

252
00:12:29,270 --> 00:12:31,710
Well what do you see? 
Why it is important for 

253
00:12:31,710 --> 00:12:34,430
engineers to look into the 
aspects of software 

254
00:12:34,430 --> 00:12:36,550
craftsmanship and also high 
quality code? 

255
00:12:37,390 --> 00:12:39,230
Definitely so the first thing, 
right? 

256
00:12:39,230 --> 00:12:42,710
I mean writing code that works, 
I mean that's very lowest, but I

257
00:12:42,710 --> 00:12:45,070
mean anybody can cross that path
of writing code. 

258
00:12:45,520 --> 00:12:48,960
Again, writing code that you 
yourself understand after six 

259
00:12:48,960 --> 00:12:51,720
months of being in a project or 
somewhere is vital. 

260
00:12:52,120 --> 00:12:54,600
I mean you're not going to do a 
good to others, but do good to 

261
00:12:54,600 --> 00:12:57,760
yourself by writing some clean 
code which you can understand in

262
00:12:57,760 --> 00:13:00,200
six months time, right? 
I mean as as prominent authors 

263
00:13:00,200 --> 00:13:03,440
like Robert used to say, so the 
essence of a software 

264
00:13:03,440 --> 00:13:06,160
craftsmanship. 
As such, if we just rewind the 

265
00:13:06,160 --> 00:13:09,680
whole 2 decades of the industry 
or three decades of it, right 

266
00:13:10,120 --> 00:13:14,850
back then we did not have cloud,
we did not have sophisticated 

267
00:13:15,010 --> 00:13:18,770
systems, we did not have lot of 
RAM and lot of processing power,

268
00:13:19,050 --> 00:13:22,410
We did not have SSDs, right, We 
did not have anything. 

269
00:13:22,410 --> 00:13:26,170
We did not have powerful IDs. 
But today we have all of them. 

270
00:13:26,450 --> 00:13:30,330
But still projects fail. 
Still the cost of software 

271
00:13:30,330 --> 00:13:33,250
development is pretty high and 
still getting it right is very 

272
00:13:33,250 --> 00:13:35,690
rare, right. 
The success rate is like hardly 

273
00:13:35,690 --> 00:13:40,270
1516 or less than 20% maximum. 
Either it shows by budget or by 

274
00:13:40,270 --> 00:13:43,350
time or by any resource, right. 
So why does that happen? 

275
00:13:43,350 --> 00:13:46,950
So the problem lies with us as 
individuals, as people, as 

276
00:13:46,950 --> 00:13:50,150
individuals. 
We need to change our ways of 

277
00:13:50,150 --> 00:13:53,710
working where we give importance
to the work that we do in terms 

278
00:13:53,710 --> 00:13:57,430
of the quality that we deliver 
and ensure that we keep raising 

279
00:13:57,430 --> 00:13:59,150
our bar. 
Again, here probably I would 

280
00:13:59,150 --> 00:14:01,030
like to quote an example of 
ample right. 

281
00:14:01,030 --> 00:14:03,110
Apple never compares themselves 
to other products. 

282
00:14:03,390 --> 00:14:05,030
They compare themselves with 
their own products. 

283
00:14:05,030 --> 00:14:08,640
So if you see iPhone 15, it's 
better than iPhone 14 by so and 

284
00:14:08,640 --> 00:14:11,040
so terms, right? 
I mean same way the code that 

285
00:14:11,040 --> 00:14:13,440
you write, the software that you
write, the development, don't 

286
00:14:13,440 --> 00:14:15,800
compare with this, just compare 
yourself with your own work, 

287
00:14:16,000 --> 00:14:18,200
right? 
Try delivering better quality in

288
00:14:18,200 --> 00:14:20,320
terms of the code that you 
write, the documentation that 

289
00:14:20,320 --> 00:14:23,320
you generate, the attention to, 
detail that you provide, the cab

290
00:14:23,320 --> 00:14:27,760
that you take that shows how 
much you love your profession or

291
00:14:27,760 --> 00:14:30,600
how much you give importance to 
the quality, right? 

292
00:14:30,840 --> 00:14:33,320
I mean it is all about again 
passion meeting profession. 

293
00:14:33,320 --> 00:14:35,950
It happens for a few people. 
At the same time you can also 

294
00:14:35,950 --> 00:14:39,030
use your profession to fuel your
passion right either ways. 

295
00:14:39,310 --> 00:14:42,790
So software craftsmanship is 
something that we need to work 

296
00:14:42,790 --> 00:14:46,510
on as individuals and also pass 
it on to the next generation of 

297
00:14:46,510 --> 00:14:49,390
developers who work with you in 
your respective organizations so

298
00:14:49,390 --> 00:14:51,790
that they get to learn from you.
I mean you lead by example, I 

299
00:14:51,790 --> 00:14:53,830
mean all of these principles 
you'd have seen in management 

300
00:14:53,830 --> 00:14:54,870
books. 
I'm just trying to connect the 

301
00:14:54,870 --> 00:14:57,790
dots how from a software 
development dangle and a 

302
00:14:57,790 --> 00:15:00,510
craftsmanship dangle. 
You can lead by example and also

303
00:15:00,510 --> 00:15:02,310
learn from them. 
So learning is always a two way 

304
00:15:02,310 --> 00:15:04,650
St. the fresh minds who come 
into the industry. 

305
00:15:04,650 --> 00:15:06,930
They have a fresh perspective 
looking at the code in the 

306
00:15:06,930 --> 00:15:08,770
system and they can do their 
feedback. 

307
00:15:08,770 --> 00:15:11,610
So be open to feedback. 
So learn from people who are 

308
00:15:11,610 --> 00:15:13,770
younger than you. 
They are much faster in learning

309
00:15:13,770 --> 00:15:15,770
something than you. 
Possibly you might have the 

310
00:15:15,770 --> 00:15:16,930
experience but they have the 
speed. 

311
00:15:16,930 --> 00:15:19,850
So instead of competing it's 
like complementing each other 

312
00:15:19,850 --> 00:15:21,530
together you solve a problem 
right? 

313
00:15:21,530 --> 00:15:24,970
So that is my view about 
software craftsmanship and 

314
00:15:25,010 --> 00:15:26,560
writing clean code. 
Right. 

315
00:15:26,560 --> 00:15:29,280
So I think when you explain 
that, it intrigued me, right, 

316
00:15:29,280 --> 00:15:32,880
the fact that the technologies 
have moved so advanced so 

317
00:15:32,880 --> 00:15:34,840
rapidly. 
We have so many choices, 

318
00:15:34,960 --> 00:15:38,920
programming languages, cloud, 
infrastructure, I don't know, so

319
00:15:38,920 --> 00:15:40,480
many exotic things happening, 
right? 

320
00:15:40,680 --> 00:15:44,120
But still we have the fact that 
projects fail, The cost of the 

321
00:15:44,120 --> 00:15:47,210
project is really, really high. 
And yeah, sometimes it also 

322
00:15:47,210 --> 00:15:48,890
doesn't meet the user 
requirements right. 

323
00:15:48,890 --> 00:15:51,890
So I think it's a true fact. 
Plus one thing that I just want 

324
00:15:51,890 --> 00:15:54,930
to add, we have these kind of 
resources, the books that are 

325
00:15:54,930 --> 00:15:57,690
available since long time as 
well, you know, like those clean

326
00:15:57,690 --> 00:16:00,970
code, refactoring, TDDXP all 
exists like I don't know how 

327
00:16:00,970 --> 00:16:03,610
many decades ago, right? 
But still we have this problem 

328
00:16:03,610 --> 00:16:06,250
that software engineering is 
sometimes tricky to deliver 

329
00:16:06,250 --> 00:16:08,190
right. 
So maybe in your view, right, 

330
00:16:08,190 --> 00:16:10,630
maybe also touch on from your 
books what are the some of the 

331
00:16:10,630 --> 00:16:14,390
root causes of low quality code.
Maybe if you can highlight some 

332
00:16:14,390 --> 00:16:16,910
of the categories for us here to
remind ourselves. 

333
00:16:17,710 --> 00:16:22,190
So low quantity code in the 
sense I mean again first things,

334
00:16:22,550 --> 00:16:25,510
the code should align with the 
architecture, the overall 

335
00:16:25,510 --> 00:16:27,150
architecture, the bigger 
picture, right? 

336
00:16:27,710 --> 00:16:30,470
So that is where I mean we'll 
again touch upon visualizing 

337
00:16:30,470 --> 00:16:32,590
architecture for the developers 
towards the end. 

338
00:16:32,670 --> 00:16:35,950
But again, since you want to 
connect the dots, if developers 

339
00:16:35,950 --> 00:16:39,510
understand what they're trying 
to achieve, say developers are 

340
00:16:39,510 --> 00:16:41,990
going to be probably working on 
a given component or a 

341
00:16:41,990 --> 00:16:45,150
particular module or a feature 
to deliver something. 

342
00:16:45,510 --> 00:16:48,550
So you have a feature, a set of 
modules work together to provide

343
00:16:48,550 --> 00:16:50,750
you the feature. 
So within the module you will 

344
00:16:50,750 --> 00:16:53,150
have players and components that
interact with each other and 

345
00:16:53,150 --> 00:16:56,110
then you get it working right. 
So they need to connect the dots

346
00:16:56,110 --> 00:17:00,310
in terms of where their work 
fits in, which actually helps 

347
00:17:00,310 --> 00:17:04,280
them to go ahead and deliver the
feature meeting all the 

348
00:17:04,280 --> 00:17:06,680
criterion, the acceptance 
criteria, whatever you call it, 

349
00:17:06,800 --> 00:17:10,079
right, so that it meets the 
requirements of the user. 

350
00:17:10,560 --> 00:17:15,880
So in a sense, the overrun 
quality depends upon the 

351
00:17:15,880 --> 00:17:19,119
understanding that people have. 
Like the moment you understand 

352
00:17:19,119 --> 00:17:21,440
the problem, you can easily 
design it. 

353
00:17:21,800 --> 00:17:23,440
You can. 
I mean, in my opinion, you need 

354
00:17:23,440 --> 00:17:26,440
to invest more time in design 
than writing code, because once 

355
00:17:26,440 --> 00:17:28,880
your design is robust, 
translating that into the code 

356
00:17:28,880 --> 00:17:30,880
is going to be a matter of time,
right? 

357
00:17:30,880 --> 00:17:33,280
Again with Gen. 
AI and other tools that you get 

358
00:17:33,500 --> 00:17:36,300
the pair programming assistance 
which is going to help you code 

359
00:17:36,300 --> 00:17:39,700
faster is what we observe. 
At least that's the claim today.

360
00:17:39,980 --> 00:17:42,940
Again, we need to validate this 
claim with more data as we 

361
00:17:42,940 --> 00:17:45,260
practice more with this coding 
assistance. 

362
00:17:45,580 --> 00:17:48,620
But definitely they are a way 
forward. 

363
00:17:48,820 --> 00:17:50,540
We cannot ignore and move on 
right. 

364
00:17:50,540 --> 00:17:53,220
People who embrace these 
assistance, they will get to 

365
00:17:53,220 --> 00:17:56,500
code faster. 
So maintaining that code quality

366
00:17:56,820 --> 00:17:59,380
is important. 
Having coding standards within 

367
00:17:59,380 --> 00:18:02,780
the team and the project is 
important and most importantly 

368
00:18:02,780 --> 00:18:04,540
trying to automate these coding 
standards. 

369
00:18:04,540 --> 00:18:07,580
I mean having coding standards. 
Not every human being can or 

370
00:18:07,580 --> 00:18:10,140
developer can remember all of 
these standards day in day out, 

371
00:18:10,420 --> 00:18:12,420
right? 
We need to see how we can 

372
00:18:12,420 --> 00:18:14,780
provide faster feedback by 
automating these coding 

373
00:18:14,780 --> 00:18:16,780
standards. 
So let's say you get a coding 

374
00:18:16,780 --> 00:18:19,500
standard, you have some PMD, 
Textile kind of stuff. 

375
00:18:19,900 --> 00:18:22,140
Or you have the effects COP and 
style copandthe.net trend. 

376
00:18:22,140 --> 00:18:25,100
Or some linters in terms of 
JavaScript and TypeScript which 

377
00:18:25,140 --> 00:18:27,380
provides developers with 
immediate feedback on code 

378
00:18:27,380 --> 00:18:29,460
quality. 
Once they get the immediate 

379
00:18:29,460 --> 00:18:32,790
feedback, once they understand 
what is going on, because 

380
00:18:33,030 --> 00:18:37,510
getting a feedback from a CICD 
server or a downstream system is

381
00:18:37,510 --> 00:18:38,870
going to increase your cycle 
time. 

382
00:18:39,310 --> 00:18:44,390
Instead, if you try to get that 
feedback ahead of time, that is 

383
00:18:44,390 --> 00:18:46,430
going to be much more useful to 
developers. 

384
00:18:46,830 --> 00:18:49,670
So that's the whole idea. 
Thank you for sharing that, 

385
00:18:49,670 --> 00:18:51,350
right. 
I think it's very interesting 

386
00:18:51,350 --> 00:18:53,990
when you said that, you know, 
understanding is the first 

387
00:18:53,990 --> 00:18:56,150
thing, right. 
Sometimes all engineers just 

388
00:18:56,150 --> 00:18:58,400
want, you know, to. 
Straight away write the code, 

389
00:18:58,600 --> 00:19:01,000
You give me what you want and 
I'll just write the code. 

390
00:19:01,160 --> 00:19:04,960
But I think in so many good 
practices that is advocated by 

391
00:19:04,960 --> 00:19:07,440
the thought leaders out there, 
understanding the problem, 

392
00:19:07,480 --> 00:19:10,400
understanding the requirements, 
coming up with the right design.

393
00:19:10,480 --> 00:19:13,440
Of course, it doesn't have to be
very heavyweight and, you know, 

394
00:19:13,440 --> 00:19:15,200
take a long time to come up 
with, right? 

395
00:19:15,560 --> 00:19:18,120
But actually you do need to take
time to actually understand what

396
00:19:18,120 --> 00:19:19,520
kind of software that you want 
to build. 

397
00:19:20,020 --> 00:19:22,460
And I think from my experience 
as well, right, building a good 

398
00:19:22,500 --> 00:19:25,300
robust system, you know, yeah, 
you need to plan it, right? 

399
00:19:25,340 --> 00:19:29,140
You cannot just come up with the
perfect software design by just 

400
00:19:29,140 --> 00:19:31,420
writing the code all the way 
from the low level, right? 

401
00:19:31,660 --> 00:19:33,020
So I think that's a very good 
thing. 

402
00:19:33,460 --> 00:19:36,100
One part I would like to add to 
that Henry, I mean design 1 

403
00:19:36,100 --> 00:19:39,660
pages are definitely helpful. 
I mean you need to write the 

404
00:19:39,660 --> 00:19:43,900
design one pager, write a wiki 
page or a Confluence page, which

405
00:19:43,900 --> 00:19:46,420
actually helps you share your 
thought process with the team. 

406
00:19:46,700 --> 00:19:49,210
Let's say you're doing power 
programming as a prior and you 

407
00:19:49,210 --> 00:19:51,250
want to communicate your design 
and get it solved with your 

408
00:19:51,250 --> 00:19:54,370
technical lead. 
Write A1 pager which contains or

409
00:19:54,370 --> 00:19:57,370
outlines the overall design that
you're thinking for solving the 

410
00:19:57,370 --> 00:20:00,890
problem and also document how it
is staying in line with the 

411
00:20:00,890 --> 00:20:04,930
existing architecture that is 
there right and present it to 

412
00:20:04,930 --> 00:20:07,890
the audience. 
Get to the feedback and then 

413
00:20:08,010 --> 00:20:12,170
probably get into coding it. 
Then it's going to decrease your

414
00:20:12,170 --> 00:20:15,050
back and forth loops that you'll
have and rework and all this 

415
00:20:15,050 --> 00:20:16,140
stuff. 
Right. 

416
00:20:16,460 --> 00:20:18,900
And you mentioned just now about
coding standards, right? 

417
00:20:19,180 --> 00:20:21,740
And that we have to automate it.
I think that's the first thing. 

418
00:20:21,820 --> 00:20:24,300
In the past I used to do it 
manually. 

419
00:20:24,300 --> 00:20:27,540
So I think it really, really 
relies heavily on your brain 

420
00:20:27,540 --> 00:20:30,300
power, right, to actually align 
with the coding standards. 

421
00:20:30,420 --> 00:20:32,580
Don't do that, right. 
Use automation as much as 

422
00:20:32,580 --> 00:20:34,500
possible. 
And I also find something 

423
00:20:34,500 --> 00:20:36,740
related to standards that I just
want to highlight from your 

424
00:20:36,740 --> 00:20:38,620
book, right. 
You mentioned that high quality 

425
00:20:38,620 --> 00:20:40,140
code. 
If you follow the coding 

426
00:20:40,140 --> 00:20:43,220
standards right, it is as if 
written by a single developer, 

427
00:20:43,260 --> 00:20:46,500
even on one file that is, you 
know, modified by multiple 

428
00:20:46,500 --> 00:20:49,140
people. 
So why I said that? 

429
00:20:49,140 --> 00:20:52,820
Yeah, I can explain you. 
So one of the important thing is

430
00:20:52,820 --> 00:20:56,380
consistency when it comes to 
looking at code. 

431
00:20:56,380 --> 00:20:59,660
When it comes to aesthetics of 
your code, our brain usually 

432
00:20:59,660 --> 00:21:02,020
forms patterns. 
Take this example right? 

433
00:21:02,020 --> 00:21:04,740
You see somebody, say your 
childhood friend, after 10 

434
00:21:04,740 --> 00:21:06,760
years. 
You are able to recognize this 

435
00:21:06,760 --> 00:21:08,120
person, right? 
Hey, how are you? 

436
00:21:08,400 --> 00:21:10,320
So how the brain works. 
It works based on pattern 

437
00:21:10,320 --> 00:21:12,320
matching. 
So it matches the pattern of the

438
00:21:12,360 --> 00:21:15,000
person and the kind of 
calculates, OK, this is how this

439
00:21:15,000 --> 00:21:17,120
person looks. 
Now I can see the resemblance. 

440
00:21:17,560 --> 00:21:20,000
That resemblance is the 
important factor with respect to

441
00:21:20,000 --> 00:21:22,960
code in terms of familiarity. 
And that familiarity is nothing 

442
00:21:22,960 --> 00:21:26,360
but standards, right? 
You see a piece of code that 

443
00:21:26,360 --> 00:21:28,240
adheres to a standard. 
You know what it does, how it 

444
00:21:28,240 --> 00:21:29,240
does. 
Easy to read. 

445
00:21:29,600 --> 00:21:32,280
Let's say you have certain ways 
of structuring your conditionals

446
00:21:32,280 --> 00:21:34,840
and loops and all this stuff. 
The fundamental elements. 

447
00:21:35,240 --> 00:21:37,640
Even though let's say for 
example you write streams or 

448
00:21:37,640 --> 00:21:41,560
link code and streams in Java 
and link in C#, the way you 

449
00:21:41,560 --> 00:21:43,920
formulate your query and the way
you write your query, right? 

450
00:21:43,960 --> 00:21:47,000
Imagine you write a SQL query. 
If you put your columns in a 

451
00:21:47,000 --> 00:21:49,320
single line, it's going to be 
very difficult to read 

452
00:21:49,320 --> 00:21:50,760
everything. 
Instead, if you put them in 

453
00:21:50,760 --> 00:21:53,600
different lines, one column name
per line, and then write the 

454
00:21:53,600 --> 00:21:56,320
select statement with one join 
per line and then formulate it 

455
00:21:56,320 --> 00:21:59,920
accordingly, it helps you to 
easily grasp and understand the 

456
00:21:59,920 --> 00:22:03,040
concept of what you're trying to
do because code is written once.

457
00:22:03,550 --> 00:22:06,150
A study that claims that the 
code is written once for 310 

458
00:22:06,150 --> 00:22:09,310
times. 
So this kind of a pattern 

459
00:22:09,310 --> 00:22:11,870
matching is crucial for 
understanding your code. 

460
00:22:11,910 --> 00:22:14,790
And now when it comes to the 
standard, at times you get to 

461
00:22:14,790 --> 00:22:17,590
modify legacy code. 
Legacy code in the sense a code 

462
00:22:17,590 --> 00:22:20,070
that is old are brownfield 
applications for that matter, 

463
00:22:20,150 --> 00:22:22,350
right? 
I have huge respect for legacy 

464
00:22:22,350 --> 00:22:23,710
systems, I'll get to that 
shortly. 

465
00:22:24,070 --> 00:22:26,750
But when you see the brownfield 
code or existing application, 

466
00:22:27,190 --> 00:22:29,350
the best thing that you can do 
is to adhere to the standards 

467
00:22:29,350 --> 00:22:31,350
that is there at that particular
file level at least. 

468
00:22:31,740 --> 00:22:34,260
Minimum the file level because 
that is the consistency 

469
00:22:34,260 --> 00:22:37,020
boundary. 
I look at the code 1 file at a 

470
00:22:37,020 --> 00:22:39,700
time. 
So you can at least ensure that 

471
00:22:39,700 --> 00:22:42,420
the minimum amount of 
consistency is maintained at the

472
00:22:42,420 --> 00:22:45,860
file level so that the key is to
be consistent. 

473
00:22:45,860 --> 00:22:47,700
The reason is, let's say you 
want to fix something. 

474
00:22:48,060 --> 00:22:51,140
You can go and fix it in all the
places in one go because you 

475
00:22:51,140 --> 00:22:53,540
know the consistent pattern 
where it is written in a 

476
00:22:53,540 --> 00:22:56,340
consistent manner and let us say
that needs to be addressed. 

477
00:22:56,340 --> 00:22:58,460
You can go and address it. 
When there is lack of 

478
00:22:58,460 --> 00:23:00,740
consistency, it's going to make 
things difficult. 

479
00:23:01,140 --> 00:23:03,580
There is another angle to 
consistency, which is following 

480
00:23:03,580 --> 00:23:05,740
industry standards. 
Why should teams follow industry

481
00:23:05,740 --> 00:23:08,060
standards? 
Because let us say you have a 

482
00:23:08,060 --> 00:23:11,020
new person joining your team. 
Now this new person joining the 

483
00:23:11,020 --> 00:23:13,260
team is going to be the lowest 
common denominator. 

484
00:23:13,660 --> 00:23:15,780
So when you communicate 
something, when you share 

485
00:23:15,780 --> 00:23:18,900
knowledge, when you discuss 
about your problem domain or 

486
00:23:18,900 --> 00:23:21,380
discuss about a solution, you 
need to ensure that this person 

487
00:23:21,380 --> 00:23:23,180
understands. 
That is why you build a 

488
00:23:23,180 --> 00:23:25,380
inclusive environment where the 
person understands this whole 

489
00:23:25,380 --> 00:23:28,000
thing so. 
Doing something that is 

490
00:23:28,000 --> 00:23:30,200
consistent with industry 
standards and maintaining the 

491
00:23:30,200 --> 00:23:32,800
consistency at the file level to
start with and then at the 

492
00:23:32,800 --> 00:23:36,080
project level and then at the 
code base level will help you 

493
00:23:36,160 --> 00:23:39,800
ensure that people can quickly 
come in from outside and grasp 

494
00:23:39,800 --> 00:23:42,680
and start being productive. 
So that's the reason I wrote 

495
00:23:42,680 --> 00:23:45,080
about that consistency boundary 
within the file. 

496
00:23:45,320 --> 00:23:47,960
And then you slowly expand it to
the project and then to the 

497
00:23:48,160 --> 00:23:50,680
entire code base, right? 
So that's the idea. 

498
00:23:51,290 --> 00:23:52,970
Yeah, it's very interesting. 
And you mentioned about 

499
00:23:52,970 --> 00:23:56,250
consistency boundaries, we're 
talking about how to write code 

500
00:23:56,250 --> 00:23:58,970
consistently well, you know, 
within your code base. 

501
00:23:59,330 --> 00:24:01,930
So I think that's really, really
powerful, right, If you get it 

502
00:24:01,930 --> 00:24:04,530
right within the team and it 
will be even more powerful 

503
00:24:04,530 --> 00:24:07,010
within the company, right. 
I know that in Google, right, 

504
00:24:07,010 --> 00:24:09,650
they all have this coding 
standards, they can automate it 

505
00:24:09,770 --> 00:24:12,090
and it's a safe ride. 
The whole company is written by 

506
00:24:12,090 --> 00:24:15,050
same kind of styles and same 
kind of a people, right. 

507
00:24:15,450 --> 00:24:16,850
I think that's really, really 
powerful. 

508
00:24:17,170 --> 00:24:19,450
And you touch on a little bit 
about aesthetics part of the 

509
00:24:19,450 --> 00:24:22,530
code base when you say about you
know formatting your stream or 

510
00:24:22,530 --> 00:24:26,250
maybe the way you write queries.
So maybe not all software 

511
00:24:26,250 --> 00:24:29,410
engineers are taught about this 
aesthetics part, right? 

512
00:24:29,690 --> 00:24:32,890
Maybe a little bit touch on 
elaborate more why aesthetics so

513
00:24:32,890 --> 00:24:35,170
so much important? 
How can they start doing it 

514
00:24:35,170 --> 00:24:36,650
right? 
Sure. 

515
00:24:36,730 --> 00:24:39,650
I mean, aesthetics again ties 
down to your visual appeal of 

516
00:24:39,650 --> 00:24:41,890
the code base. 
So as I mentioned earlier, I 

517
00:24:41,890 --> 00:24:44,690
spoke about pattern matching. 
So there is a very good book 

518
00:24:44,690 --> 00:24:47,970
that I would suggest folks to 
take a look at which is Thinking

519
00:24:47,970 --> 00:24:50,650
and Learning Refactor Your 
Hardware, which is about how the

520
00:24:50,650 --> 00:24:53,490
brain works and the pattern 
matching and all this stuff. 

521
00:24:54,090 --> 00:24:57,170
So the moment you have that 
consistency and the way you 

522
00:24:57,170 --> 00:25:01,530
layout your code, say for 
example all the variables that 

523
00:25:01,530 --> 00:25:04,290
are used in a class, say in 
object oriented programming 

524
00:25:04,290 --> 00:25:06,650
paradigm should be organized 
properly at the top. 

525
00:25:07,010 --> 00:25:10,730
So, as Robert C Martin calls it,
he also gives that newspaper 

526
00:25:10,730 --> 00:25:12,810
analogy right when you read a 
newspaper article. 

527
00:25:13,160 --> 00:25:16,840
He speaks about having the 
various gist of the news and 

528
00:25:16,840 --> 00:25:19,000
then going into the details of 
the time summarizing. 

529
00:25:19,000 --> 00:25:22,480
So people who have a lack of 
time, who are not so interested 

530
00:25:22,720 --> 00:25:25,840
in your news, they're just going
to read the first paragraph or 

531
00:25:25,840 --> 00:25:27,240
the headline and probably move 
on. 

532
00:25:27,640 --> 00:25:29,440
Those who are interested will 
dive deep into it. 

533
00:25:29,440 --> 00:25:31,080
The same is applicable to the 
code. 

534
00:25:31,520 --> 00:25:34,000
When you put your public methods
that are implemented by an 

535
00:25:34,000 --> 00:25:36,400
interface or this particular 
class that implements the 

536
00:25:36,400 --> 00:25:39,760
interface, you're going to have 
this at the top of the file, so 

537
00:25:39,760 --> 00:25:42,320
you clearly. 
Demarcate and communicate like 

538
00:25:42,320 --> 00:25:43,640
this is what this class is 
doing. 

539
00:25:43,640 --> 00:25:46,200
These are the responsibilities 
class and if somebody is more 

540
00:25:46,200 --> 00:25:48,720
interested, they'll probably 
drive into the stuff that is 

541
00:25:49,040 --> 00:25:51,640
below, which is the private 
methods and other stuff, right? 

542
00:25:52,160 --> 00:25:54,640
So aesthetically you need to 
organize your codes as that if 

543
00:25:54,640 --> 00:25:57,480
the concepts are well 
encapsulated, well split within 

544
00:25:57,480 --> 00:25:59,720
the file. 
So let's say you have a class in

545
00:25:59,720 --> 00:26:02,920
a file and then you have the 
members, properties, methods, 

546
00:26:03,280 --> 00:26:05,520
the construct of the methods and
then the private methods. 

547
00:26:05,800 --> 00:26:08,680
That is a neat way to organize 
it aesthetically, and the 

548
00:26:08,680 --> 00:26:12,070
aesthetics also boils down to. 
Putting things together in terms

549
00:26:12,070 --> 00:26:15,030
of stuff that is related and 
putting things that are not 

550
00:26:15,030 --> 00:26:18,150
related separately, in a sense, 
let us say you're trying to do 

551
00:26:18,150 --> 00:26:20,990
something within the loop, or a 
for loop or a while loop or 

552
00:26:20,990 --> 00:26:23,390
whatever, right? 
What we are doing within that 

553
00:26:23,390 --> 00:26:26,630
loop is a very kind of a closed 
construct, right? 

554
00:26:26,630 --> 00:26:29,230
What you're trying to do within 
the iteration, what is outside 

555
00:26:29,230 --> 00:26:30,710
of it? 
If you leave a blank line next 

556
00:26:30,710 --> 00:26:34,430
to this, loop the line very 
dense and then leave a blank 

557
00:26:34,430 --> 00:26:38,510
line and then start the next 
possible line clearly gives you 

558
00:26:38,510 --> 00:26:41,850
a separation between this. 
On the next concept that is 

559
00:26:41,850 --> 00:26:46,090
coming up right, so the same is 
applicable to if blocks, else 

560
00:26:46,090 --> 00:26:47,570
blocks, switch cases and all 
this stuff. 

561
00:26:47,610 --> 00:26:50,290
All this constructs. 
So anytime there is an 

562
00:26:50,290 --> 00:26:53,290
indentation, the indentation 
that takes your code towards the

563
00:26:53,290 --> 00:26:54,970
right. 
If you take Python, there are no

564
00:26:54,970 --> 00:26:56,810
brackets, it's all indentation 
right? 

565
00:26:57,370 --> 00:26:59,970
So the way you write your code 
it should be. 

566
00:27:00,330 --> 00:27:02,210
There should be a clear 
demarcation between these 

567
00:27:02,210 --> 00:27:05,490
concepts. 
So that is your vertical way of 

568
00:27:05,490 --> 00:27:08,090
organizing your code 
aesthetically when it comes to 

569
00:27:08,090 --> 00:27:09,970
horizontally organizing, as you 
might know. 

570
00:27:10,360 --> 00:27:13,000
Living spaces between operators 
and variables and then 

571
00:27:13,280 --> 00:27:16,120
assignment and variable living 
spaces wherever required. 

572
00:27:16,480 --> 00:27:20,160
Writing the comments in a very 
clean manner in a very concise 

573
00:27:20,160 --> 00:27:21,880
and understanding. 
And all of this boils down to 

574
00:27:21,880 --> 00:27:24,320
aesthetics. 
So visually when you see the 

575
00:27:24,320 --> 00:27:27,200
code, when it is aesthetically 
pleasing, it is easier to work 

576
00:27:27,200 --> 00:27:28,280
with it. 
It's welcoming for the 

577
00:27:28,280 --> 00:27:31,240
developers who are new to the 
system rather than that. 

578
00:27:31,240 --> 00:27:33,800
If your code is not visually 
consistent or aesthetically 

579
00:27:33,800 --> 00:27:37,360
pleasant, then probably you take
a step back and say OK, it takes

580
00:27:37,360 --> 00:27:40,530
me some time to understand this.
So make your life easier, right?

581
00:27:40,530 --> 00:27:42,290
I mean, make everyone's life 
easier. 

582
00:27:42,650 --> 00:27:45,370
After all, software development 
should be fun in my opinion. 

583
00:27:45,730 --> 00:27:49,130
So giving importance to 
aesthetics is really crucian 

584
00:27:49,530 --> 00:27:52,690
when reading code is done more 
frequently than writing it, 

585
00:27:53,450 --> 00:27:54,850
right? 
You mentioned about visually 

586
00:27:54,850 --> 00:27:56,810
appealing. 
I think it also helps a lot for 

587
00:27:56,810 --> 00:27:59,690
your cognitive load, for your 
brain, right to actually read 

588
00:27:59,690 --> 00:28:02,050
the code because or you 
mentioned that the code is 

589
00:28:02,050 --> 00:28:04,690
written once, read 10 times or 
even more, right? 

590
00:28:04,970 --> 00:28:06,690
So you you need to help 
yourself, right? 

591
00:28:06,690 --> 00:28:08,730
In order to actually understand 
what you read. 

592
00:28:09,300 --> 00:28:12,220
I mean another thing, right? 
It's about writing code that is 

593
00:28:12,420 --> 00:28:16,140
understandable by everybody. 
Meaning say for example, why are

594
00:28:16,140 --> 00:28:18,260
we using English in programming 
more? 

595
00:28:18,660 --> 00:28:23,060
The reason is English kind of is
a widespread language that many 

596
00:28:23,060 --> 00:28:25,540
of us understand, right? 
At least the majority 

597
00:28:25,540 --> 00:28:29,340
understands English and using 
variable names that can be 

598
00:28:29,340 --> 00:28:31,020
spelled properly is very 
important. 

599
00:28:31,420 --> 00:28:33,900
I mean, back then we had 
challenges with memory and other

600
00:28:33,900 --> 00:28:36,900
things where we used to shorten 
the variable names and a lot of 

601
00:28:36,900 --> 00:28:39,800
the things in the past. 
But given that those things are 

602
00:28:39,800 --> 00:28:42,760
no more a problem even you have 
typing assistance from your 

603
00:28:42,920 --> 00:28:46,440
Ides, even if you give a 
meaningful name, it is not very 

604
00:28:46,440 --> 00:28:48,280
hard to type. 
You just put a control space and

605
00:28:48,280 --> 00:28:49,800
the command space and move on 
right. 

606
00:28:50,200 --> 00:28:53,600
So giving meaningful variable 
names that are readable is 

607
00:28:53,600 --> 00:28:55,320
crucial for understanding your 
code. 

608
00:28:55,680 --> 00:28:58,080
I mean naming as you know naming
and caching. 

609
00:28:58,120 --> 00:29:00,200
The though important problems 
are difficult problems to solve 

610
00:29:00,560 --> 00:29:03,960
is when to invalidate the cache 
and naming things right. 

611
00:29:03,960 --> 00:29:06,920
So naming. 
Definitely invest time in giving

612
00:29:06,920 --> 00:29:09,930
proper names and never. 
Worry about revisiting your 

613
00:29:09,930 --> 00:29:12,170
names. 
Meaning once you name something 

614
00:29:12,170 --> 00:29:15,330
the way you get a better domain 
understanding down the line. 

615
00:29:15,890 --> 00:29:18,770
You need to revise your 
ubiquitous Language from a 

616
00:29:19,090 --> 00:29:22,610
Domain Driven Design standpoint 
to see if a better word or a 

617
00:29:22,610 --> 00:29:25,490
better term unveils that meaning
in a better way. 

618
00:29:26,050 --> 00:29:29,540
So that is another piece of 
input I just want to add on, 

619
00:29:29,540 --> 00:29:31,220
maybe as part of the aesthetics,
right. 

620
00:29:31,220 --> 00:29:34,980
So the few things that I feel 
some engineers do not actually 

621
00:29:34,980 --> 00:29:36,580
realize yet are actually 
powerful. 

622
00:29:36,580 --> 00:29:38,900
So things like vertical new 
line, like you mentioned, 

623
00:29:38,900 --> 00:29:43,020
vertical space, sometimes just 
adding new lines in between some

624
00:29:43,020 --> 00:29:45,300
sections of your code, actually,
that's really powerful. 

625
00:29:45,620 --> 00:29:48,700
And the second thing is about 
maximum width that you can 

626
00:29:48,820 --> 00:29:51,380
expand to the right, right. 
So I think some teams actually 

627
00:29:51,660 --> 00:29:55,060
enforce the maximum width so 
that you don't scroll to the 

628
00:29:55,060 --> 00:29:57,140
right. 
I have some interesting stories 

629
00:29:57,140 --> 00:30:00,350
there. 
So Once Upon a time, there is 

630
00:30:00,350 --> 00:30:02,750
one of the developers who I was 
working with, two stories in 

631
00:30:02,750 --> 00:30:05,270
fact. 
One is one of the developers who

632
00:30:05,270 --> 00:30:07,190
I was working with. 
He used to write very long 

633
00:30:07,190 --> 00:30:09,110
methods. 
I mean this is back when I was 

634
00:30:09,110 --> 00:30:11,270
in US. 
Like I used to ask him why is 

635
00:30:11,270 --> 00:30:14,230
that your methods are long. 
Then he told me like, OK, my 

636
00:30:14,230 --> 00:30:17,030
methods are long because 
whenever it crosses my screen 

637
00:30:17,030 --> 00:30:19,230
limit, I tend to break into a 
new method. 

638
00:30:19,750 --> 00:30:22,550
OK, that thing should be a very 
interesting yardstick to break 

639
00:30:22,550 --> 00:30:24,950
into a new method. 
Then I thought even then you 

640
00:30:24,950 --> 00:30:27,870
should be breaking it. 
So half the size of it, or even 

641
00:30:27,870 --> 00:30:29,670
3 by 4th of it, Why are it 
taking so long? 

642
00:30:29,670 --> 00:30:31,550
Then I went and visited his 
desk. 

643
00:30:32,110 --> 00:30:36,110
So he had the monitoring 
portrait board where the monitor

644
00:30:36,110 --> 00:30:38,150
was actually in a portrait board
and he was trying to break a 

645
00:30:38,150 --> 00:30:39,950
line where it does the next 
screen. 

646
00:30:39,950 --> 00:30:42,310
So I mean, well it might sound 
funny, right? 

647
00:30:42,310 --> 00:30:44,430
I mean, the most important thing
is to add it to single 

648
00:30:44,430 --> 00:30:47,590
responsibility principle, right?
Single responsibility is not 

649
00:30:47,590 --> 00:30:50,710
that it crosses your screen 
limit, but instead try to see 

650
00:30:50,710 --> 00:30:53,350
how to have a well defined 
responsibility for a given 

651
00:30:53,350 --> 00:30:55,190
method that you're writing. 
I mean, don't do more than one 

652
00:30:55,190 --> 00:30:58,200
thing, as Roberts is. 
Another instance was I was again

653
00:30:58,600 --> 00:31:02,000
working with a set of folks who 
actually write long lines which 

654
00:31:02,000 --> 00:31:05,400
make you scroll to the right and
then read the code and then come

655
00:31:05,400 --> 00:31:06,600
back. 
So it feels like you are doing 

656
00:31:06,600 --> 00:31:09,520
typewriting work where the head 
goes to the right and then comes

657
00:31:09,520 --> 00:31:11,480
back to the reset. 
I mean those who have seen 

658
00:31:11,480 --> 00:31:14,240
typewriters. 
So the comment that came was 

659
00:31:14,240 --> 00:31:15,760
like, I was asking like, why do 
you do that? 

660
00:31:15,960 --> 00:31:18,480
There are very wide monitors. 
We don't find any challenges in 

661
00:31:18,480 --> 00:31:20,920
working with such a code. 
It was like, OK, you might have 

662
00:31:20,920 --> 00:31:23,440
wide monitors, but doesn't mean 
you should make others suffer. 

663
00:31:23,680 --> 00:31:25,880
I mean, some people might have 
smaller screens, right? 

664
00:31:26,350 --> 00:31:29,510
Not only that, I mean, research 
has shown that beyond the point,

665
00:31:29,510 --> 00:31:31,950
the cognitive load increases 
when you keep scrolling and 

666
00:31:31,950 --> 00:31:34,470
going back and forth and then 
all of the stuff, right? 

667
00:31:34,470 --> 00:31:37,070
When you write long methods or 
when you write horizontally long

668
00:31:37,070 --> 00:31:40,390
lines, cognitive load on 
readability is going to be more 

669
00:31:40,390 --> 00:31:42,550
on the reader. 
It's very difficult to 

670
00:31:42,870 --> 00:31:46,390
understand the whole stuff. 
I mean, even I would say for 

671
00:31:46,390 --> 00:31:49,990
methods if the number of 
arguments is more than three. 

672
00:31:50,310 --> 00:31:53,150
In my view, I think the method 
is doing more than what it is 

673
00:31:53,150 --> 00:31:55,440
supposed to do. 
And your app probably folding 

674
00:31:55,440 --> 00:31:57,760
things into a data structure and
then sending it to the method. 

675
00:31:58,040 --> 00:32:00,680
Initially you are sending in 
arguments that are separated. 

676
00:32:01,080 --> 00:32:03,480
So try to see how we can make it
coercive in terms of method 

677
00:32:03,480 --> 00:32:06,440
arguments that go into a method.
At the same time try to see if 

678
00:32:06,440 --> 00:32:08,520
you can stick to it 60 to 80 
character limit. 

679
00:32:08,520 --> 00:32:09,960
Again, this is all proven by 
research. 

680
00:32:10,400 --> 00:32:12,800
I think that I researched. 
But again, people before me, 

681
00:32:12,800 --> 00:32:14,320
they have done the research and 
given the results. 

682
00:32:14,890 --> 00:32:16,450
Thank you for such a fun 
stories, right. 

683
00:32:16,450 --> 00:32:19,130
I think that's completely right.
So the reason why you don't want

684
00:32:19,130 --> 00:32:22,410
to have like a too long to the 
right is because yeah, you have 

685
00:32:22,410 --> 00:32:24,810
to be inclusive, right? 
Not everyone has the same set of

686
00:32:24,810 --> 00:32:27,970
monitors and resolutions as you.
Sometimes we work on laptops, 

687
00:32:27,970 --> 00:32:30,850
right, Because we travel. 
So yeah, please do set mix with 

688
00:32:31,130 --> 00:32:33,570
the other thing I just want to 
add right not to not to start a 

689
00:32:33,570 --> 00:32:36,660
debate or something right. 
Tab versus space for 

690
00:32:36,660 --> 00:32:38,820
indentation, right. 
So I think need to be 

691
00:32:38,820 --> 00:32:42,580
consistently set, even though ID
now helps you no matter whether 

692
00:32:42,580 --> 00:32:45,540
you set tabs or you know, space.
But sometimes you have to go to 

693
00:32:45,540 --> 00:32:47,540
terminal, sometimes you go VI 
right. 

694
00:32:48,020 --> 00:32:49,860
I have another fun story, I 
guess. 

695
00:32:50,380 --> 00:32:53,220
I have a solution. 
No, no, not a fun story. 

696
00:32:53,260 --> 00:32:56,580
I have a solution. 
So the solution is see don't 

697
00:32:56,580 --> 00:32:59,980
debate. 
First of all because you're 

698
00:32:59,980 --> 00:33:02,100
using your productive time 
depending on trivial things, 

699
00:33:02,100 --> 00:33:03,380
right? 
Especially tabs and spaces. 

700
00:33:03,780 --> 00:33:06,790
So the essence is. 
Try to use spot formatters that 

701
00:33:06,790 --> 00:33:09,070
are built for specific languages
right? 

702
00:33:09,430 --> 00:33:11,910
Say for example Visual Studio 
Extensions like Prettier do a 

703
00:33:11,910 --> 00:33:13,430
great job in formatting your 
code. 

704
00:33:13,950 --> 00:33:15,870
My solution is to use a pre 
commit hook. 

705
00:33:16,230 --> 00:33:19,590
Write a pre commit hook which 
formats the code in a uniform 

706
00:33:19,590 --> 00:33:23,190
manner for every developer. 
So before they commit this hook 

707
00:33:23,190 --> 00:33:25,350
runs formatted in a very 
consistent way. 

708
00:33:25,350 --> 00:33:29,030
Because I don't want to see this
in the code which is actually 

709
00:33:29,030 --> 00:33:31,190
not modified just because of 
formatting, you will see a lot 

710
00:33:31,190 --> 00:33:33,480
of DIF here and there. 
But actually there have been a 

711
00:33:33,480 --> 00:33:35,560
couple of lines that got 
modified end of the day. 

712
00:33:35,960 --> 00:33:38,480
So what really happens is the 
consistency is maintained when 

713
00:33:38,480 --> 00:33:41,960
you use this kind of formatting 
tool and a pre commit hook which

714
00:33:41,960 --> 00:33:44,760
helps you achieve that 
consistency across the board. 

715
00:33:44,760 --> 00:33:47,480
I mean everybody in the team, 
they can have their own settings

716
00:33:47,480 --> 00:33:49,000
and their own ideas, which is 
fine. 

717
00:33:49,280 --> 00:33:51,120
You put touch bases, whatever 
you want to do it. 

718
00:33:51,480 --> 00:33:54,040
There's no point to debate. 
I'll just as a ticket, I'll just

719
00:33:54,040 --> 00:33:55,960
go ahead and set a pre commit 
hook which does the job. 

720
00:33:56,560 --> 00:33:59,160
Yeah, that's very powerful 
advice right? 

721
00:33:59,160 --> 00:34:02,500
So automate as much as possible 
and do set convention within 

722
00:34:02,500 --> 00:34:03,180
your team. 
Right. 

723
00:34:03,420 --> 00:34:05,580
And no debates, right? 
Like you shouldn't debate so 

724
00:34:05,580 --> 00:34:07,300
much about it. 
I mean like it's not to say 

725
00:34:07,300 --> 00:34:08,380
that. 
No debate. 

726
00:34:08,380 --> 00:34:10,540
I mean, debate is healthy. 
Yeah, I just debates are 

727
00:34:10,540 --> 00:34:12,340
healthy. 
Definitely debate, but on worthy

728
00:34:12,340 --> 00:34:14,980
things, correct? 
OK, so let's move on to maybe 

729
00:34:14,980 --> 00:34:17,500
other aspects of software 
engineering where it also 

730
00:34:17,500 --> 00:34:19,219
determines the code quality, 
right? 

731
00:34:19,500 --> 00:34:21,620
So I'm talking about code 
reviews. 

732
00:34:21,620 --> 00:34:24,580
Now that you maybe follow 
convention, follow standards, 

733
00:34:24,580 --> 00:34:26,659
you write the code right? 
The other aspects is actually 

734
00:34:26,659 --> 00:34:29,050
someone reviewing it. 
Is there anything that you want 

735
00:34:29,050 --> 00:34:32,210
to elaborate here on how we can 
become a better software 

736
00:34:32,210 --> 00:34:35,210
Craftsman? 
Definitely for code reviews. 

737
00:34:35,210 --> 00:34:37,210
Before touching upon code 
reviews, I'll probably touch 

738
00:34:37,210 --> 00:34:39,130
upon the version control 
strategies or the approaches 

739
00:34:39,130 --> 00:34:41,409
that you take. 
Because version control 

740
00:34:41,409 --> 00:34:44,929
strategies and your programming 
approach actually has an impact 

741
00:34:44,929 --> 00:34:47,610
on code reviews. 
The First things first, Pad 

742
00:34:47,610 --> 00:34:50,929
programming is an excellent 
concept which actually you have 

743
00:34:50,929 --> 00:34:53,850
a programmer, you have a driver 
and you have a person who is 

744
00:34:53,850 --> 00:34:56,810
padding along with you who's a 
navigator who keeps looking at 

745
00:34:56,810 --> 00:35:00,080
your code in real time. 
Again, for team startup pad 

746
00:35:00,080 --> 00:35:02,320
programming, you need certain 
amount of maturity because there

747
00:35:02,320 --> 00:35:03,880
are some pad programming IT 
patterns. 

748
00:35:04,200 --> 00:35:07,960
So you should have a fair 
timeshare between both the 

749
00:35:07,960 --> 00:35:10,600
developers who are writing code.
So it's not like one person will

750
00:35:10,600 --> 00:35:12,920
always be writing and the other 
person is always a navigator. 

751
00:35:13,400 --> 00:35:14,640
Those kind of things cannot 
happen. 

752
00:35:14,640 --> 00:35:16,520
You should not be having pad 
affinity where the same 

753
00:35:16,520 --> 00:35:18,680
developer gets to pad with the 
other person, right? 

754
00:35:18,680 --> 00:35:21,000
Those kind of things cannot 
happen when you do this pad 

755
00:35:21,000 --> 00:35:22,560
programming. 
The other person gets to review 

756
00:35:22,560 --> 00:35:26,000
the code on the fly, gives you 
the feedback, so it actually 

757
00:35:26,000 --> 00:35:27,720
essentially cuts down in your 
cycle time. 

758
00:35:28,240 --> 00:35:31,120
What is a pro and a con? 
The Pro is that you get to ask 

759
00:35:31,120 --> 00:35:33,960
the feedback and you can easily 
incorporate the feedback in 

760
00:35:33,960 --> 00:35:35,840
terms of the review comments 
that might potentially come. 

761
00:35:36,840 --> 00:35:38,480
Three requisite is the 
expertise. 

762
00:35:39,000 --> 00:35:42,800
Developers who are pairing at 
least should have a fair amount 

763
00:35:42,800 --> 00:35:44,880
of understanding of the coding 
standards followed in the 

764
00:35:44,880 --> 00:35:46,880
project. 
It'll understand things. 

765
00:35:47,400 --> 00:35:50,000
Let us say you cannot let 2 new 
developers to a team pair 

766
00:35:50,400 --> 00:35:52,440
because they might not know the 
coding standards that are 

767
00:35:52,440 --> 00:35:54,660
adopted by the team. 
When there is new developer 

768
00:35:54,660 --> 00:35:57,020
coming in as a pair, you can 
probably pair them with an 

769
00:35:57,020 --> 00:35:59,900
existing developer who knows the
standards very well and they can

770
00:35:59,900 --> 00:36:02,380
act as a navigator to let the 
new developer write the code and

771
00:36:02,380 --> 00:36:04,780
train them on the job by 
providing the feedback on code 

772
00:36:04,780 --> 00:36:07,660
reviews. 
So this goes well with front 

773
00:36:07,660 --> 00:36:10,460
based development where you 
commit to the main line instead 

774
00:36:10,460 --> 00:36:13,980
of having feature branches or 
short load branches as you might

775
00:36:13,980 --> 00:36:16,460
know. 
But again, this might not be 

776
00:36:16,460 --> 00:36:20,380
possible in certain scenarios 
like regulatory environments or 

777
00:36:20,780 --> 00:36:23,260
public sector work that you're 
getting to do. 

778
00:36:23,680 --> 00:36:25,800
And these kind of things don't 
let you work with. 

779
00:36:26,280 --> 00:36:28,880
Recall trunk based development, 
it's not possible to be used in 

780
00:36:28,880 --> 00:36:31,320
those bases. 
So that is when you have to do a

781
00:36:31,320 --> 00:36:33,160
feature branch based 
development, which requires a 

782
00:36:33,160 --> 00:36:35,920
separate code review process 
before you merge your branch 

783
00:36:35,920 --> 00:36:38,680
into the release branch or a 
development branch or a master 

784
00:36:38,680 --> 00:36:41,160
whatever, right? 
Typically we cut from master. 

785
00:36:41,160 --> 00:36:43,160
We have a development branch and
from the development you have a 

786
00:36:43,160 --> 00:36:45,320
release branch. 
You keep committing to release 

787
00:36:45,320 --> 00:36:48,640
and development and then once 
that release goes out then the 

788
00:36:49,000 --> 00:36:51,190
main. 
Hot fixes when bug fixes happen 

789
00:36:51,190 --> 00:36:53,470
in the master and then they are 
merged back into this. 

790
00:36:53,670 --> 00:36:57,430
So all of these steps require 
you to have proper code reviews 

791
00:36:57,430 --> 00:37:00,390
being done and the most 
important thing is to 

792
00:37:00,910 --> 00:37:02,950
decentralize this whole process 
in my view. 

793
00:37:02,950 --> 00:37:05,830
I mean one person should not be 
responsible for code reviews 

794
00:37:06,350 --> 00:37:10,070
which actually increases the 
cycle time and more developers 

795
00:37:10,070 --> 00:37:12,150
have the challenges of going 
back and forth in a sense. 

796
00:37:12,150 --> 00:37:15,110
Like let's say there is a dev 
pad who is working on waiting 

797
00:37:15,110 --> 00:37:17,070
for a review and then by the 
time you. 

798
00:37:17,580 --> 00:37:19,180
Indeed, let us say you're 
reviewing that you are the 

799
00:37:19,180 --> 00:37:20,740
single point of failure then 
right? 

800
00:37:20,740 --> 00:37:23,420
So you go on off, then the 
reviews get piled up and you 

801
00:37:23,420 --> 00:37:25,900
cannot review and respond to it 
in a timely manner. 

802
00:37:26,300 --> 00:37:28,980
And what happens? 
These devs keep waiting for you.

803
00:37:28,980 --> 00:37:31,260
And then once you get to the 
review of it and it's your other

804
00:37:31,260 --> 00:37:33,260
responsibilities, because code 
review is not the sole 

805
00:37:33,260 --> 00:37:36,580
responsibility. 
So once you get to the review, 

806
00:37:36,740 --> 00:37:39,420
you approve it and then you let 
these developers or the dev per 

807
00:37:39,420 --> 00:37:41,380
merge. 
But once these people merge, 

808
00:37:41,980 --> 00:37:45,140
other folks, let us say they are
the critical path. 

809
00:37:45,840 --> 00:37:49,040
They need to again down merge 
and resolve the merge conflicts 

810
00:37:49,040 --> 00:37:52,320
that might arise, ensure that 
there are no merge conflicts and

811
00:37:52,320 --> 00:37:53,960
then try to resubmit it for a 
review. 

812
00:37:53,960 --> 00:37:56,680
By then you will be elsewhere so
the cycle continues. 

813
00:37:57,080 --> 00:37:59,760
So the developers have that back
and forth in terms of reviewing,

814
00:38:00,000 --> 00:38:03,080
waiting for a review, merging 
conflicts again waiting for a 

815
00:38:03,080 --> 00:38:04,760
review. 
So that keeps on going right? 

816
00:38:05,480 --> 00:38:07,320
So we need to see how to 
decentralize it. 

817
00:38:07,320 --> 00:38:09,840
I'm not saying feature brands 
based development is bad or 

818
00:38:09,840 --> 00:38:11,720
trunk based is good, It's all 
trade-offs right? 

819
00:38:11,720 --> 00:38:14,480
It depends upon the specific 
project, depends upon the 

820
00:38:14,480 --> 00:38:17,430
scenario. 
The essence is try to see how 

821
00:38:17,430 --> 00:38:20,350
you can decentralize it, how 
more people who have the 

822
00:38:20,350 --> 00:38:23,390
authority review and approve. 
And these people should be the 

823
00:38:23,390 --> 00:38:25,870
core members who understand the 
code very well, who understand 

824
00:38:25,870 --> 00:38:28,270
the process very well, 
understand the standards very 

825
00:38:28,270 --> 00:38:29,270
well. 
So they are the long time 

826
00:38:29,270 --> 00:38:32,590
members and in the process of 
time also groom the newer 

827
00:38:32,590 --> 00:38:36,590
members to become those 
reviewers or champions, right? 

828
00:38:37,030 --> 00:38:39,590
And don't just have one person 
review it and approve it and it 

829
00:38:39,590 --> 00:38:41,910
can go ahead. 
No, you should at least have two

830
00:38:41,910 --> 00:38:44,230
people or another paraphrase 
looking at the code. 

831
00:38:44,730 --> 00:38:47,730
Before it gets reviewed and 
approved, another thing that at 

832
00:38:47,730 --> 00:38:50,730
least we have followed in my 
team just to see if we can do it

833
00:38:50,770 --> 00:38:52,890
once in iteration. 
Let us say we have the 

834
00:38:52,890 --> 00:38:54,970
developers present their code 
and chain to the team. 

835
00:38:55,010 --> 00:38:57,290
I mean what they have done in 
the given iteration. 

836
00:38:57,690 --> 00:38:59,650
Go through the features with 
everyone. 

837
00:38:59,650 --> 00:39:02,410
What are the changes that were 
made in a given component or the

838
00:39:02,410 --> 00:39:03,810
code based on the specific 
project. 

839
00:39:04,250 --> 00:39:07,730
That way the familiarity about 
the changes increases within the

840
00:39:07,730 --> 00:39:10,050
team and everybody has a fair 
understanding of what it is 

841
00:39:10,410 --> 00:39:12,610
based on the time and interest 
they can go ahead and read 

842
00:39:12,610 --> 00:39:14,760
further and make themselves. 
Today. 

843
00:39:15,200 --> 00:39:18,080
So these are my ideas. 
And yeah, I mean these are my 

844
00:39:18,080 --> 00:39:21,280
views on board reviews. 
Henry, thanks for sharing all 

845
00:39:21,280 --> 00:39:23,720
these different variations 
permutations, right. 

846
00:39:23,800 --> 00:39:26,120
And you are right when you touch
on different, first of all it's 

847
00:39:26,120 --> 00:39:28,400
about different version control 
strategy, right. 

848
00:39:28,680 --> 00:39:30,200
Sometimes you use strong based 
development. 

849
00:39:30,200 --> 00:39:33,120
The way you review is slightly 
different than if you do you 

850
00:39:33,120 --> 00:39:35,520
know branching strategies. 
So thank you for sharing all 

851
00:39:35,520 --> 00:39:37,440
that. 
So other aspects of 

852
00:39:37,440 --> 00:39:40,360
craftsmanship that I think is 
really, really important is that

853
00:39:40,480 --> 00:39:42,600
how do you control technical 
depth? 

854
00:39:43,070 --> 00:39:46,310
So sometimes you know when you 
write software, after a few 

855
00:39:46,310 --> 00:39:48,750
weeks, few months, right, you'll
accumulate some debt. 

856
00:39:49,070 --> 00:39:52,230
Is there anything from your site
to actually advise us how we can

857
00:39:52,230 --> 00:39:55,390
manage technical debt? 
The first and foremost thing is 

858
00:39:55,390 --> 00:39:57,190
to know that you are absorbing 
technical debt. 

859
00:39:58,670 --> 00:40:01,550
If you don't know that you are 
absorbing technical debt, then 

860
00:40:01,550 --> 00:40:04,550
it's hard to save, right? 
So technical debt can be 

861
00:40:04,550 --> 00:40:07,470
classified into code debt 
designed at an architectural 

862
00:40:07,470 --> 00:40:10,190
debt, right? 
Let's say on the code front you 

863
00:40:10,190 --> 00:40:13,960
want to do something from a. 
Coding style or a programming 

864
00:40:13,960 --> 00:40:16,680
construct standpoint. 
But due to the delivery pressure

865
00:40:16,680 --> 00:40:19,960
or the lack of knowledge or the 
lack of fairness of existence of

866
00:40:19,960 --> 00:40:22,880
such a feature in your language 
and framework to write some 

867
00:40:22,880 --> 00:40:25,440
code, you deliver it, you get it
working, then you understand 

868
00:40:25,440 --> 00:40:28,240
that OK, if instead of 
handcrafting this I have a 

869
00:40:28,240 --> 00:40:31,440
better way of doing this with 
the framework and the base class

870
00:40:31,440 --> 00:40:34,360
library in a given language, I 
can very well try to do that. 

871
00:40:34,360 --> 00:40:36,640
I can, instead of doing it 
handcrafting it. 

872
00:40:36,640 --> 00:40:39,000
I can very well go out and use 
that framework feature and get 

873
00:40:39,000 --> 00:40:41,480
it done. 
So once that is the thing, 

874
00:40:42,160 --> 00:40:45,560
capturing that is crucial. 
Meaning, once you identify that,

875
00:40:45,560 --> 00:40:49,080
immediately you need to create a
backlog item or a recall JIRA 

876
00:40:49,080 --> 00:40:50,760
item or something. 
Wherever you have your backlog, 

877
00:40:50,760 --> 00:40:53,840
whether it's Azure DevOps or 
JIRA or whatever, capture as a 

878
00:40:53,840 --> 00:40:56,880
ticket in the system and ensure 
that it gets prioritized. 

879
00:40:56,880 --> 00:40:58,760
Because again, capturing alone 
doesn't take you anywhere. 

880
00:40:58,760 --> 00:41:01,840
As a team, you need to convince 
your product folks, convince 

881
00:41:01,840 --> 00:41:03,960
your product managers and 
engineering managers to ensure 

882
00:41:03,960 --> 00:41:07,520
that we are going to implement 
product features at the same 

883
00:41:07,520 --> 00:41:09,560
time. 
Handling technical, that is 

884
00:41:09,560 --> 00:41:12,640
important as you know, right? 
So you need to have a fine 

885
00:41:12,640 --> 00:41:15,280
balance within technical debt, 
repaying the technical debt and 

886
00:41:16,280 --> 00:41:18,360
project side of things, the 
feature side of things. 

887
00:41:18,920 --> 00:41:22,480
So for example, or probably a 
analogy that I would like to 

888
00:41:22,480 --> 00:41:24,960
quote is woodcutter example, 
right? 

889
00:41:25,480 --> 00:41:27,360
As a woodcutter you go and cut 
your wood. 

890
00:41:27,840 --> 00:41:29,160
Sometimes you need to sharpen 
your axe. 

891
00:41:29,160 --> 00:41:31,920
You're going to use the same axe
to keep on cutting at the same 

892
00:41:31,920 --> 00:41:33,640
pace, right? 
You need to slow down, sharpen 

893
00:41:33,640 --> 00:41:35,600
your axe and then that's part of
your profession. 

894
00:41:35,600 --> 00:41:37,720
This is applicable to both 
technical debt and engineers in 

895
00:41:37,720 --> 00:41:39,920
terms of learning. 
Whatever on software 

896
00:41:39,920 --> 00:41:42,450
craftsmanship, whatever on 
learning you need to learn. 

897
00:41:42,570 --> 00:41:44,370
This learning is nothing but 
sharpening your axe. 

898
00:41:44,810 --> 00:41:46,290
The same is applicable to 
technical debt. 

899
00:41:46,290 --> 00:41:48,690
So you need to repay the 
technical debt in a timely 

900
00:41:48,690 --> 00:41:51,490
manner which lets you and 
faster. 

901
00:41:51,490 --> 00:41:53,250
Again. 
There is an excellent book I 

902
00:41:53,250 --> 00:41:55,770
came across As far as technical 
debt is concerned. 

903
00:41:56,330 --> 00:41:58,290
I don't remember the title on 
top of my head. 

904
00:41:58,290 --> 00:42:00,730
I think it's Refactoring Design 
Smells. 

905
00:42:00,730 --> 00:42:04,250
It's a wonderful book which 
actually talks about these 

906
00:42:04,250 --> 00:42:07,170
aspects of and smells and 
technical debt and how to repay 

907
00:42:07,170 --> 00:42:08,730
them. 
And one more thing is from a 

908
00:42:08,730 --> 00:42:11,420
people's standpoint, people 
standpoint, you need to ensure 

909
00:42:11,420 --> 00:42:13,780
that you convince the folks the 
organizational buy in should be 

910
00:42:13,780 --> 00:42:15,740
there. 
The leadership should understand

911
00:42:15,740 --> 00:42:17,860
the importance of technical debt
and repaying it in a timely 

912
00:42:17,860 --> 00:42:19,220
manner. 
I mean this includes 

913
00:42:19,220 --> 00:42:21,140
architectural debt and 
redesigning stuff as well. 

914
00:42:21,460 --> 00:42:23,980
Let's say with the particular 
understanding of a given domain 

915
00:42:24,660 --> 00:42:26,540
or a sub domain. 
You designed it in a certain 

916
00:42:26,540 --> 00:42:28,140
way, you architected that in a 
certain way. 

917
00:42:28,620 --> 00:42:30,780
But let us say down there and 
you discover that, OK, this is a

918
00:42:30,780 --> 00:42:33,540
better way to actually 
communicate between these two 

919
00:42:33,540 --> 00:42:35,700
bounded contexts. 
I can probably refactor this 

920
00:42:35,700 --> 00:42:39,410
design and redesign this and 
it's better to get it done, or 

921
00:42:39,410 --> 00:42:41,370
at least explore the 
possibilities of doing it again.

922
00:42:41,370 --> 00:42:44,170
The pros and cons, do the 
analysis, do the groundwork, 

923
00:42:44,650 --> 00:42:48,570
have the facts ready so that 
they can present these facts to 

924
00:42:48,970 --> 00:42:50,810
the leadership and then get 
their buy in. 

925
00:42:51,010 --> 00:42:53,970
In terms of the benefits, the 
pros and cons of doing that and 

926
00:42:53,970 --> 00:42:56,610
ultimately right, people don't 
see technical debt. 

927
00:42:56,610 --> 00:43:00,290
I mean, users might not see, end
user might not worry, they might

928
00:43:00,290 --> 00:43:03,090
not see, but where they will 
feel is all about the quality. 

929
00:43:03,650 --> 00:43:06,410
You have a car, The car keeps 
running every day. 

930
00:43:06,970 --> 00:43:10,160
You are not appreciating your 
car that wow, I started you. 

931
00:43:10,160 --> 00:43:11,880
You got started the moment I 
started. 

932
00:43:12,200 --> 00:43:15,160
Excellent. 
But the lack of that, when it 

933
00:43:15,160 --> 00:43:16,600
doesn't start, you feel the 
pain. 

934
00:43:17,160 --> 00:43:19,320
Same goes with technical debt 
under the hood. 

935
00:43:19,880 --> 00:43:21,600
Technical debt keeps on 
building. 

936
00:43:22,000 --> 00:43:24,200
You won't realize it one fine 
day. 

937
00:43:24,200 --> 00:43:27,440
It is like changing the oil for 
your car engine, right? 

938
00:43:27,880 --> 00:43:30,880
It just ceases to run. 
And then you realize, Oh no, I 

939
00:43:30,880 --> 00:43:33,000
should not have delayed it this 
much. 

940
00:43:33,440 --> 00:43:36,640
Only that is the time where it 
is too late to handle it right, 

941
00:43:37,240 --> 00:43:40,480
and again it goes into a cycle. 
The problem is there are systems

942
00:43:40,480 --> 00:43:43,600
that have so much technical debt
you decide to rewrite the 

943
00:43:43,600 --> 00:43:44,640
system. 
I've been through this. 

944
00:43:45,040 --> 00:43:46,440
You decide to rewrite the 
system. 

945
00:43:46,960 --> 00:43:49,680
When you rewrite the system, 
possibly you don't have the 

946
00:43:49,680 --> 00:43:52,680
original developers who wrote 
the system, no more with you. 

947
00:43:53,160 --> 00:43:55,280
So there is a lack of domain 
understanding or a lack of 

948
00:43:55,280 --> 00:43:56,960
knowledge. 
You have a newer team, newer set

949
00:43:56,960 --> 00:43:59,560
of folks trying to reverse 
engineer the old system by 

950
00:43:59,560 --> 00:44:01,880
understanding the behavior and 
then trying to break it apart 

951
00:44:01,880 --> 00:44:05,160
and implement it. 
Now without that understanding, 

952
00:44:05,160 --> 00:44:08,310
without that level of 
background, they will start 

953
00:44:08,310 --> 00:44:11,070
designing the system with 
technical debt from day one or a

954
00:44:11,070 --> 00:44:15,470
design debt from day one and it 
never meets because you need to 

955
00:44:15,470 --> 00:44:18,630
keep repaying the technical debt
that is there in the existing 

956
00:44:18,630 --> 00:44:21,510
system because you have users 
who are using it and you'll make

957
00:44:21,510 --> 00:44:24,590
changes to it and this new 
system is going to play a catch 

958
00:44:24,590 --> 00:44:26,830
up game with the old one which 
is already getting changed. 

959
00:44:27,390 --> 00:44:29,870
It's very difficult. 
I mean the essence is pay 

960
00:44:29,870 --> 00:44:33,350
technical debt as soon as 
possible and then maintain a 

961
00:44:33,350 --> 00:44:36,930
backlog, revise the backlog, 
revisit the backlog and keep 

962
00:44:36,930 --> 00:44:39,850
reducing the backlog, right. 
It is never going to be 0. 

963
00:44:40,090 --> 00:44:42,330
Let me tell you that. 
You cannot do away with 

964
00:44:42,330 --> 00:44:45,370
technical debt entirely because 
people keep moving across 

965
00:44:45,370 --> 00:44:47,890
projects, people keep moving 
across organizations, people 

966
00:44:47,890 --> 00:44:50,210
come and go. 
So when new people come in, 

967
00:44:50,410 --> 00:44:53,330
there might be an increased 
technical debt because they are 

968
00:44:53,330 --> 00:44:56,170
understanding our system, they 
need time to themselves, to the 

969
00:44:56,170 --> 00:44:58,770
system, right? 
But as they learn, they will 

970
00:44:58,770 --> 00:45:00,770
understand the nuances, they 
will learn the system and they 

971
00:45:00,770 --> 00:45:03,610
will start working. 
So this technical debt that you 

972
00:45:03,610 --> 00:45:06,510
incur, I'm not saying every new 
person will bring in a technical

973
00:45:06,510 --> 00:45:08,230
debt, but there is a 
possibility, right? 

974
00:45:08,230 --> 00:45:11,590
So once that happens you try to 
repay that and ensure that as a 

975
00:45:11,590 --> 00:45:14,670
team you support this new person
so that there is no technical 

976
00:45:14,670 --> 00:45:15,870
debt. 
That's a better way to put it. 

977
00:45:16,150 --> 00:45:19,750
Try to see how you can repay the
technical debt and stay on top 

978
00:45:19,750 --> 00:45:21,070
of it. 
Meaning have know that you are 

979
00:45:21,070 --> 00:45:22,470
absorbing technical debt. 
First of all. 

980
00:45:23,030 --> 00:45:25,750
That is where trade off analysis
and understanding trade-offs is 

981
00:45:25,750 --> 00:45:28,270
vital. 
That is where understanding 

982
00:45:28,270 --> 00:45:30,990
design, understanding the 
architectural styles and 

983
00:45:30,990 --> 00:45:34,470
awareness of these possibilities
that you have is important. 

984
00:45:34,950 --> 00:45:37,510
The lower most level you have 
probably have the design 

985
00:45:37,510 --> 00:45:39,910
patterns and to have a fair 
understanding of design 

986
00:45:39,910 --> 00:45:41,390
patterns, like which one to 
apply when. 

987
00:45:41,790 --> 00:45:43,630
It is not about knowing the 
patterns, it's about applying 

988
00:45:43,630 --> 00:45:46,390
the pattern right. 
It's about knowing what to apply

989
00:45:46,390 --> 00:45:50,110
when in a given context. 
So these are some thoughts on 

990
00:45:50,110 --> 00:45:52,030
technical debt, Henry. 
Right. 

991
00:45:52,110 --> 00:45:54,470
Thank you for sharing your 
thoughts about technical debt. 

992
00:45:54,470 --> 00:45:57,190
I think all what you said is 
really insightful, right So and 

993
00:45:57,190 --> 00:45:58,710
you mentioned also about 
rewrites, right? 

994
00:45:58,710 --> 00:46:00,610
Sometimes. 
Software engineers, especially 

995
00:46:00,610 --> 00:46:03,170
the new software engineers, when
they deal with legacy code, oh, 

996
00:46:03,170 --> 00:46:05,810
we need to rewrite this. 
You know, like I think you 

997
00:46:05,810 --> 00:46:08,050
mentioned that the first day 
that they do that, right. 

998
00:46:08,090 --> 00:46:11,570
They probably have lost much of 
the knowledge behind why the 

999
00:46:11,570 --> 00:46:14,370
code was written that way and 
they will incur that in the 1st 

1000
00:46:14,370 --> 00:46:16,930
place itself, right. 
Unless you can maybe restructure

1001
00:46:16,930 --> 00:46:19,810
what kind of domain knowledge 
that was maybe behind all those 

1002
00:46:19,810 --> 00:46:22,170
code, right. 
So I think that's a very, very 

1003
00:46:22,170 --> 00:46:23,850
key lesson as well. 
So now. 

1004
00:46:24,400 --> 00:46:27,120
Let's say assume you know 
individuals, teams and all that 

1005
00:46:27,120 --> 00:46:29,760
have this kind of high quality 
code, they are software 

1006
00:46:29,760 --> 00:46:32,240
Craftsman. 
I think the next is about how we

1007
00:46:32,240 --> 00:46:35,040
can transform the team into a 
highly performing engineering 

1008
00:46:35,040 --> 00:46:37,640
teams, right? 
I think here you also have some 

1009
00:46:37,640 --> 00:46:41,000
stories that you want to share 
right, about how you actually 

1010
00:46:41,000 --> 00:46:44,480
transform the team to become a 
highly performing or software 

1011
00:46:44,480 --> 00:46:47,160
Craftsman all around, right. 
So maybe if you can touch on a 

1012
00:46:47,160 --> 00:46:48,920
little bit on this, that will be
great. 

1013
00:46:49,520 --> 00:46:51,200
Definitely. 
I mean, there's an existing 

1014
00:46:51,200 --> 00:46:55,270
model you might find online as 
well, like which actually show 

1015
00:46:55,270 --> 00:46:57,550
psychological safety and 
performance and accountability 

1016
00:46:57,750 --> 00:46:59,990
in a graph, right. 
So I'll probably, before jumping

1017
00:46:59,990 --> 00:47:02,110
into that, so many teams that 
I've met a touch upon 

1018
00:47:02,110 --> 00:47:05,270
psychological safety. 
So one of the key aspects today 

1019
00:47:05,270 --> 00:47:07,950
at least is to give equal 
importance to mental health 

1020
00:47:07,990 --> 00:47:10,990
compared to, I mean as important
as physical health because this 

1021
00:47:10,990 --> 00:47:12,950
is going to also impact your 
physical health in a way. 

1022
00:47:13,470 --> 00:47:17,710
So as leaders, as technical 
leads, the first thing that I 

1023
00:47:17,710 --> 00:47:20,110
would probably request folks to 
do is to create a 

1024
00:47:20,110 --> 00:47:23,800
psychologically safe environment
for your developers wherein they

1025
00:47:23,800 --> 00:47:26,720
can be their true selves, they 
can speak without any vision, 

1026
00:47:26,840 --> 00:47:29,160
they can be open about their 
issues that they are facing on a

1027
00:47:29,160 --> 00:47:32,400
daily basis because 
psychological safety forms the 

1028
00:47:32,400 --> 00:47:35,720
foundation of anything right On 
top of it, I would recommend 

1029
00:47:35,720 --> 00:47:39,920
transparency, which is be 
transparent one the behavior 

1030
00:47:39,920 --> 00:47:42,120
that you can observe which is 
more than work and life. 

1031
00:47:42,600 --> 00:47:45,600
People are hesitant to tell the 
truth, but they don't think 

1032
00:47:45,600 --> 00:47:48,210
twice. 
To lie about something, be true 

1033
00:47:48,210 --> 00:47:50,650
to yourself and be true to 
others, I mean tell the truth. 

1034
00:47:50,690 --> 00:47:52,610
And the truth comes only with 
transparency. 

1035
00:47:52,610 --> 00:47:55,210
You try to be transparent. 
Let us say you have a personal 

1036
00:47:55,210 --> 00:47:57,890
appointment that is actually 
coming on your way. 

1037
00:47:58,370 --> 00:48:00,290
Be transparent about it. 
Let others understand. 

1038
00:48:00,290 --> 00:48:02,730
Everybody has a life, right? 
You might be undergoing a tough 

1039
00:48:02,730 --> 00:48:04,810
time. 
You don't need to take a 

1040
00:48:04,810 --> 00:48:06,290
loudspeaker and tell it to 
everybody. 

1041
00:48:06,290 --> 00:48:08,650
But you can definitely 
communicate with your leadership

1042
00:48:08,650 --> 00:48:10,770
about the challenges that you 
are facing as individual. 

1043
00:48:10,770 --> 00:48:13,490
Because I see that many 
individuals today need that 

1044
00:48:13,490 --> 00:48:17,410
emotional support, need that 
emotional bonding to connect 

1045
00:48:17,410 --> 00:48:19,490
with them. 
Don't say that work is a family 

1046
00:48:19,490 --> 00:48:21,290
or something, right? 
I don't want to use such fancy 

1047
00:48:21,290 --> 00:48:22,690
words. 
Family is family. 

1048
00:48:22,690 --> 00:48:24,370
Work is work. 
It's a professional environment,

1049
00:48:24,370 --> 00:48:25,650
right? 
Stay professional. 

1050
00:48:25,650 --> 00:48:29,890
At the same time, people 
definitely are social beings who

1051
00:48:29,890 --> 00:48:33,530
need that emotional support to 
try to see how we can provide 

1052
00:48:33,530 --> 00:48:35,810
that psychologically safe 
environment with transparency. 

1053
00:48:35,810 --> 00:48:38,090
And these are the two 
foundational layers for you to 

1054
00:48:38,090 --> 00:48:40,890
build trust. 
As you know, trust is going to 

1055
00:48:40,890 --> 00:48:42,730
take time to build within the 
team. 

1056
00:48:43,370 --> 00:48:48,100
So one of the situations is like
I had a a project where we had a

1057
00:48:48,100 --> 00:48:51,380
team of individuals, really good
individuals, handpicked for the 

1058
00:48:51,380 --> 00:48:54,180
project, but the project was 
really a tough one to achieve in

1059
00:48:54,180 --> 00:48:56,860
a given time frame. 
So happened that the team was 

1060
00:48:56,860 --> 00:48:59,620
actually very good. 
I mean in terms of psychological

1061
00:48:59,620 --> 00:49:01,300
safety and performance 
accountability, there were some 

1062
00:49:01,300 --> 00:49:03,020
challenges. 
We tried to fix it as a team. 

1063
00:49:03,500 --> 00:49:05,620
So what happens is not specific 
to that team, right. 

1064
00:49:05,620 --> 00:49:07,540
In general, it is split into 
four zones. 

1065
00:49:07,540 --> 00:49:09,860
When there is no psychological 
safety and low performance 

1066
00:49:09,860 --> 00:49:11,660
accountability, you are there in
the data zone. 

1067
00:49:12,140 --> 00:49:15,500
So the data zone is where 
developers don't understand what

1068
00:49:15,500 --> 00:49:19,120
they're doing, why they are even
going to work, What is it that 

1069
00:49:19,120 --> 00:49:21,280
is going on with them? 
They don't understand the 

1070
00:49:21,280 --> 00:49:23,760
dynamics and the politics and 
the all the organizational fancy

1071
00:49:23,760 --> 00:49:26,400
stuff that's going on right. 
The next one is actually a 

1072
00:49:26,640 --> 00:49:28,360
anxiety zone. 
Let us say there is no 

1073
00:49:28,360 --> 00:49:31,160
psychological safety, but there 
is more performance and 

1074
00:49:31,160 --> 00:49:33,040
accountability. 
You have a lot of performance 

1075
00:49:33,040 --> 00:49:35,840
and accountability expectations 
on the individuals become 

1076
00:49:35,840 --> 00:49:37,880
anxious, how am I going to 
deliver? 

1077
00:49:38,360 --> 00:49:41,040
How am I going to achieve this? 
There is a huge deadline that is

1078
00:49:41,040 --> 00:49:43,280
looming over me or the team, 
right? 

1079
00:49:43,280 --> 00:49:45,000
How are we going to solve this 
as a team that makes them 

1080
00:49:45,000 --> 00:49:47,960
anxious? 
The third zone on the top left 

1081
00:49:48,160 --> 00:49:51,400
is about low performance 
accountability, but high cycle 

1082
00:49:51,400 --> 00:49:54,040
is considered this kind of a 
very comfort safe zone. 

1083
00:49:54,520 --> 00:49:57,120
People are laid back, OK, nobody
questions. 

1084
00:49:57,680 --> 00:49:59,920
There is some legacy system 
which is paying our bills. 

1085
00:50:00,080 --> 00:50:03,160
It is generating the revenue and
a lot of time for developed 

1086
00:50:03,320 --> 00:50:05,200
software delivered. 
Some kind of. 

1087
00:50:05,480 --> 00:50:08,160
I'm just giving the cooking of 
an example, right, some kind of 

1088
00:50:08,160 --> 00:50:10,720
a situation like that where 
people are very laid back, they 

1089
00:50:10,720 --> 00:50:14,280
know they won't get fired. 
There is no hard motivation or 

1090
00:50:14,280 --> 00:50:17,200
something to actually run and 
keep yourself up to date with 

1091
00:50:17,200 --> 00:50:20,440
stuff and you just keep doing in
a very slow manner, right. 

1092
00:50:21,000 --> 00:50:24,640
So that is the comfort zone and 
finally the learning zone where 

1093
00:50:24,640 --> 00:50:27,400
there's high performance, high 
accountability and also high 

1094
00:50:27,400 --> 00:50:30,800
psychological safety. 
So we want our teams to actually

1095
00:50:30,800 --> 00:50:33,200
go from these three zones 
mentioned earlier, which is the 

1096
00:50:33,200 --> 00:50:37,880
detached comfort zone and the 
anxiety zone into the learning 

1097
00:50:37,880 --> 00:50:40,040
zone. 
So how to take these teams? 

1098
00:50:40,560 --> 00:50:44,120
There are two parts you can see.
Either you take them through the

1099
00:50:44,850 --> 00:50:47,570
comfort zone or through the 
ANSID zone. 

1100
00:50:48,170 --> 00:50:51,050
So the first one is don't take 
the ANSID zone. 

1101
00:50:51,050 --> 00:50:54,610
That is, don't increase the 
performance and accountability 

1102
00:50:55,010 --> 00:50:57,810
without increasing the 
psychological safety and trust. 

1103
00:50:58,330 --> 00:51:01,090
Work on psychological safety, 
work on trust, try to increase 

1104
00:51:01,090 --> 00:51:02,010
it. 
So when you keep your 

1105
00:51:02,010 --> 00:51:04,890
performance and accountability 
expectations constant for a 

1106
00:51:04,890 --> 00:51:07,730
moment and then try to focus on 
improving the performance and 

1107
00:51:07,730 --> 00:51:10,770
accountability for some time, 
you take the team into the 

1108
00:51:10,770 --> 00:51:13,370
comfort zone, meaning it is not 
a permanent comfort zone but the

1109
00:51:13,370 --> 00:51:15,850
temporary pathway, right. 
Instead of going through the 

1110
00:51:15,850 --> 00:51:18,970
anxious zone, you take them to 
the comfort zone and once you 

1111
00:51:18,970 --> 00:51:21,490
know they are there, they are 
the psychological safety, they 

1112
00:51:21,490 --> 00:51:24,650
have the transparency and trust.
Then you start increasing your 

1113
00:51:24,650 --> 00:51:26,170
performance and accountability 
bars. 

1114
00:51:26,610 --> 00:51:29,490
When you raise that bar, the 
team naturally transforms. 

1115
00:51:29,490 --> 00:51:31,810
Again. 
This was done with a set of 

1116
00:51:31,810 --> 00:51:35,490
individuals by working with them
and theoretical right. 

1117
00:51:35,890 --> 00:51:38,770
So we worked as a team to apply 
these concepts. 

1118
00:51:39,210 --> 00:51:41,330
Concepts are in new. 
I mean, as I told earlier, 

1119
00:51:41,410 --> 00:51:44,480
knowledge is everywhere, 
knowledge is borrowed, but the 

1120
00:51:44,480 --> 00:51:47,320
experiences are unique, right? 
So there's one such experience 

1121
00:51:47,320 --> 00:51:49,880
where we got an opportunity to 
transform a team and it has 

1122
00:51:49,880 --> 00:51:52,480
worked in more than one this 
entry in my opinion. 

1123
00:51:53,080 --> 00:51:55,360
So connecting with the 
individuals and improving the 

1124
00:51:55,360 --> 00:51:58,040
psychological safety is the 
fundamental to building a 

1125
00:51:58,040 --> 00:51:59,640
stronger team. 
Right. 

1126
00:52:00,040 --> 00:52:01,920
So I think it's really 
insightful for people who are 

1127
00:52:01,920 --> 00:52:04,600
interested to see these 
quadrants, as Rihari just now 

1128
00:52:04,600 --> 00:52:06,560
mentioned, right? 
Some of you may not be able to 

1129
00:52:06,560 --> 00:52:08,800
follow, but I'll put it in the 
show notes if we can find a 

1130
00:52:08,800 --> 00:52:11,930
link. 
And also I saw Srihari come up 

1131
00:52:11,930 --> 00:52:14,610
with a mind maps for these kind 
of things, including this. 

1132
00:52:14,770 --> 00:52:16,890
How to actually go into learning
zone? 

1133
00:52:16,890 --> 00:52:19,450
How to transform teams right? 
And also in the software 

1134
00:52:19,450 --> 00:52:21,290
architecture of software 
craftsmanship, you also have 

1135
00:52:21,290 --> 00:52:23,930
another mind maps, right? 
Maybe tell us a little bit more 

1136
00:52:23,930 --> 00:52:25,850
why do you love creating mind 
maps? 

1137
00:52:25,850 --> 00:52:28,570
How does your brain actually 
work with mind maps? 

1138
00:52:28,850 --> 00:52:30,330
Maybe a little bit of intrigue 
here. 

1139
00:52:30,970 --> 00:52:34,850
Mind maps is an idea is always 
about how your brain organizes 

1140
00:52:34,850 --> 00:52:37,310
information. 
So you have neurons which are 

1141
00:52:37,310 --> 00:52:41,510
actually 3 dimensional in 
connection and let you retain 

1142
00:52:41,550 --> 00:52:44,350
and remember a lot of things. 
So mind maps as a concept or as 

1143
00:52:44,350 --> 00:52:47,630
an approach capturing knowledge.
Just to give you an example, 

1144
00:52:47,630 --> 00:52:52,670
Boeing captured their entire 747
details in a mind map that was 

1145
00:52:52,670 --> 00:52:55,750
25 feet long. 
So a 25 feet long mind map was 

1146
00:52:55,750 --> 00:52:58,230
used by Boeing to capture the 
entire knowledge about 747. 

1147
00:52:58,510 --> 00:53:02,270
So the essence of mind map is to
capture a lot of information and

1148
00:53:02,270 --> 00:53:05,710
try to present in a way it can 
be recollected easily. 

1149
00:53:06,070 --> 00:53:08,070
That is you have a central 
concept and then you have other 

1150
00:53:08,070 --> 00:53:10,910
concepts that are linked to it 
and then there is a linking 

1151
00:53:10,910 --> 00:53:12,910
between these sub concepts as 
well at times. 

1152
00:53:12,910 --> 00:53:16,550
So it's like a three-dimensional
graph where concepts and things 

1153
00:53:16,550 --> 00:53:19,630
are linked together right. 
So that is how I found interest 

1154
00:53:19,630 --> 00:53:22,710
in creating mind maps and I 
tried to create mind maps 

1155
00:53:22,710 --> 00:53:24,950
whenever I have a complex 
concept that I want to share 

1156
00:53:24,950 --> 00:53:28,430
with my team and then present it
to them and share it with them. 

1157
00:53:28,430 --> 00:53:31,870
And it helps in multiple ways. 
One is to share knowledge in a 

1158
00:53:31,870 --> 00:53:34,630
very concise manner. 
Second, it also helps me in 

1159
00:53:34,630 --> 00:53:38,140
teaching and learning. 
And 3rd it also helps you 

1160
00:53:38,140 --> 00:53:40,380
reconnect faster. 
I mean if you want to reconnect 

1161
00:53:40,380 --> 00:53:43,180
the concept, the mind map is 
something that will help you to 

1162
00:53:43,180 --> 00:53:45,380
collect faster. 
So that is a road that mind maps

1163
00:53:45,380 --> 00:53:48,140
in shop and. 
Sometimes you also see it in the

1164
00:53:48,140 --> 00:53:49,940
movie, right? 
When you have a detective 

1165
00:53:49,940 --> 00:53:53,140
investigation, you have all 
these, you know, lines on the 

1166
00:53:53,140 --> 00:53:55,500
wall, right? 
It's kind of kind of like that 

1167
00:53:55,500 --> 00:53:58,420
as well, to recollect all the 
threads, threads connecting the 

1168
00:53:58,420 --> 00:54:00,020
photographs and pins and 
everything. 

1169
00:54:00,680 --> 00:54:02,520
Yeah. 
So about software craftsmanship,

1170
00:54:02,520 --> 00:54:04,920
right, I think we have covered 
about code base, a little bit of

1171
00:54:04,920 --> 00:54:07,280
practices, right. 
We also touched on about teams, 

1172
00:54:07,280 --> 00:54:10,640
right, going to learning zone. 
The other aspect of good high 

1173
00:54:10,640 --> 00:54:13,760
quality software or product is 
actually about architecture and 

1174
00:54:13,760 --> 00:54:15,280
the domain knowledge that you 
mentioned, right. 

1175
00:54:15,560 --> 00:54:18,320
So maybe we can touch on a 
little bit as well to become a 

1176
00:54:18,320 --> 00:54:21,440
good software Craftsman or what 
aspects of architecture and 

1177
00:54:21,440 --> 00:54:25,360
domain knowledge that we have to
actually adhere to as sort of 

1178
00:54:25,360 --> 00:54:28,160
architecture is concerned. 
As you know there are a lot of 

1179
00:54:28,160 --> 00:54:32,590
different architectural styles 
from layered to monolith to 

1180
00:54:32,590 --> 00:54:36,790
micro services to space based, 
even based even driven in all of

1181
00:54:36,790 --> 00:54:39,630
this architecture, service 
oriented kind of architectural 

1182
00:54:39,630 --> 00:54:42,750
sites out there. 
As such we have as an industry 

1183
00:54:42,750 --> 00:54:45,150
we have undergone translation in
terms of these architecture. 

1184
00:54:45,150 --> 00:54:47,910
In my view if you see this back 
then we used to have layered 

1185
00:54:47,910 --> 00:54:50,070
architecture. 
As convey's law says, the 

1186
00:54:50,070 --> 00:54:52,950
creature will be very team 
structure and inverse Convey 

1187
00:54:52,950 --> 00:54:55,070
manualist, this is your 
architecture that you want to 

1188
00:54:55,070 --> 00:54:56,590
achieve. 
Then probably you try to 

1189
00:54:56,590 --> 00:55:00,650
structure your teams this way. 
Right back then we used to have 

1190
00:55:00,650 --> 00:55:04,530
layered architecture, we used to
have client server right, we 

1191
00:55:04,530 --> 00:55:07,730
take web pages, we had server 
side rendering as such, we had 

1192
00:55:07,730 --> 00:55:09,650
server side rendering which 
servers used to render. 

1193
00:55:10,210 --> 00:55:13,930
But in my view, right, if you 
take the advent of smartphones 

1194
00:55:14,250 --> 00:55:17,970
again, the iPhone and iPad in 
20/10/2011 timeframe actually 

1195
00:55:17,970 --> 00:55:21,610
changed things from even the 
impact of the development 

1196
00:55:21,610 --> 00:55:24,450
ecosystem in my view. 
Because back then when server 

1197
00:55:24,450 --> 00:55:27,450
side rendering was so prominent,
the number and devices hitting 

1198
00:55:27,450 --> 00:55:29,570
these servers was actually a 
finite set. 

1199
00:55:30,090 --> 00:55:32,650
But with the proliferation of 
mobile devices, the number of 

1200
00:55:32,650 --> 00:55:35,450
devices hitting these servers 
became exorbitant wherein the 

1201
00:55:35,450 --> 00:55:38,970
servers could not keep up with 
that load and they eventually 

1202
00:55:38,970 --> 00:55:42,650
had to scale right, scale 
horizontally as well as try to 

1203
00:55:42,650 --> 00:55:46,290
offload the responsibility of 
rendering into the client, use 

1204
00:55:46,290 --> 00:55:48,450
the client side power to render 
right. 

1205
00:55:48,450 --> 00:55:52,810
Which gave a way to the kind of 
simple page applications and 

1206
00:55:52,810 --> 00:55:54,770
frameworks and all these 
JavaScript frameworks and stuff,

1207
00:55:55,380 --> 00:55:56,780
right? 
Then you also have the mobile 

1208
00:55:56,780 --> 00:55:58,780
apps and other things that are 
communicating with the server. 

1209
00:55:58,780 --> 00:56:02,180
So there is more computing power
that got distributed from a 

1210
00:56:02,420 --> 00:56:06,260
computational perspective. 
So all of these are different 

1211
00:56:06,700 --> 00:56:10,100
events that shaped up newer 
architectural styles. 

1212
00:56:10,820 --> 00:56:14,300
So from layered we got into 
service oriented which resulted 

1213
00:56:14,300 --> 00:56:17,740
in some distribution and then 
from there it became micro 

1214
00:56:17,740 --> 00:56:21,220
service on the server side and 
then micro front ends on the 

1215
00:56:21,220 --> 00:56:23,520
client side. 
Now I mean not that every 

1216
00:56:23,520 --> 00:56:25,800
architecture is suitable for 
every problem, right? 

1217
00:56:25,800 --> 00:56:28,080
I mean first of all you need to 
understand one thing very 

1218
00:56:28,080 --> 00:56:30,760
clearly. 
No architectural style is 

1219
00:56:30,760 --> 00:56:34,120
superior or inferior. 
I see a lot of debates online 

1220
00:56:34,160 --> 00:56:38,120
where probably I have stepped in
and given my suggestions that I 

1221
00:56:38,120 --> 00:56:40,200
learned from different authors 
and different people in the 

1222
00:56:40,200 --> 00:56:43,280
industry by reviewing these 
books and expanding my 

1223
00:56:43,280 --> 00:56:44,800
knowledge. 
Not that it's my personal view 

1224
00:56:44,800 --> 00:56:46,640
and I have also learned from 
others and also seen an 

1225
00:56:46,640 --> 00:56:50,600
experience both put together. 
Architectural stylist, superior 

1226
00:56:50,600 --> 00:56:54,390
or inferior you'll be wondering,
I mean working in a fancy micro 

1227
00:56:54,390 --> 00:56:57,670
service based project, but it 
might be some humble legacy 

1228
00:56:57,670 --> 00:56:59,950
system which will be sitting in 
the back Rd. and funding your 

1229
00:56:59,950 --> 00:57:01,950
project. 
But that will be the cash code 

1230
00:57:01,950 --> 00:57:04,390
from a management perspective 
which gives you the cash and the

1231
00:57:04,390 --> 00:57:08,150
funding for the R&D division to 
invest in micro services and 

1232
00:57:08,150 --> 00:57:10,550
develop a new version of your 
product, right. 

1233
00:57:10,630 --> 00:57:14,350
So we need to see, I mean I have
huge respect for this legacy 

1234
00:57:14,350 --> 00:57:16,830
system because the developers 
who wrote it, they didn't have 

1235
00:57:16,830 --> 00:57:20,810
all these fancy things back 
then, not have faster missions, 

1236
00:57:20,810 --> 00:57:23,730
they did not have a lot of RAM, 
they did not have cloud, they 

1237
00:57:23,730 --> 00:57:25,610
did not have fancy IDs and all 
this stuff. 

1238
00:57:25,610 --> 00:57:28,090
But even then they produce 
something that's of great 

1239
00:57:28,090 --> 00:57:31,450
quality, right? 
They are are pioneers in terms 

1240
00:57:31,450 --> 00:57:35,690
of software craftsmanship. 
Those who wrote such systems, 

1241
00:57:36,250 --> 00:57:38,610
they need to get their fair 
share of respect. 

1242
00:57:39,090 --> 00:57:41,890
And every time I see people 
complaining about legacy systems

1243
00:57:41,890 --> 00:57:44,410
but also try to look at the 
positives of legacy system, it 

1244
00:57:44,410 --> 00:57:46,410
is giving you the funding that 
you need today. 

1245
00:57:46,850 --> 00:57:49,930
In essence, understand the 
different architectural styles, 

1246
00:57:50,610 --> 00:57:53,410
try to see how it is going to 
fit together. 

1247
00:57:53,970 --> 00:57:58,210
And no single architectural 
style might be helping you solve

1248
00:57:58,210 --> 00:58:01,170
a very complex problem. 
Let's say you take a example 

1249
00:58:01,170 --> 00:58:04,850
like Amazon, a part of it might 
be micro services, a part of it 

1250
00:58:04,850 --> 00:58:07,290
might be a mobile app, a part of
it might be a layered stuff. 

1251
00:58:07,850 --> 00:58:10,370
It depends upon the problem of 
domain and the subdomains that 

1252
00:58:10,370 --> 00:58:11,730
are interacting and working 
together. 

1253
00:58:11,730 --> 00:58:14,250
So these architectural sites 
some part might be event driven 

1254
00:58:14,990 --> 00:58:17,590
write these architectural styles
should actually work together in

1255
00:58:17,590 --> 00:58:20,590
tandem to solve the business 
problem wherein you can even go 

1256
00:58:20,590 --> 00:58:22,670
ahead and apply a given 
architectural child for a given 

1257
00:58:22,670 --> 00:58:26,950
problem or a bounded context and
then solve it that way and the 

1258
00:58:26,950 --> 00:58:28,910
way it interacts with another 
bounded context. 

1259
00:58:29,190 --> 00:58:31,670
So again it boils. 
It has a close link to Domain 

1260
00:58:31,670 --> 00:58:35,350
Driven Design as such because in
my view Domain Driven Design is 

1261
00:58:35,350 --> 00:58:39,270
kind of an eternal concept in 
software timeframe because it 

1262
00:58:39,270 --> 00:58:42,390
was written in 2003, 2004 by 
Eric Evans. 

1263
00:58:43,310 --> 00:58:45,750
But I feel there is more 
traction in the last few years 

1264
00:58:45,750 --> 00:58:50,790
or last decade or so where 
people have started looking back

1265
00:58:50,790 --> 00:58:53,230
into the literature of Domain 
Driven Design and they're trying

1266
00:58:53,230 --> 00:58:56,990
to take these concepts like 
stuff that is there in books 

1267
00:58:56,990 --> 00:58:59,110
like Accelerates, stuff that is 
there in books like team 

1268
00:58:59,110 --> 00:59:02,630
topologies, some there is in 
every microservice book, stuff 

1269
00:59:02,630 --> 00:59:03,990
that is there in all the 
architecture and books. 

1270
00:59:03,990 --> 00:59:06,190
Everything boils down to Domain 
Driven Design, the strategic 

1271
00:59:06,190 --> 00:59:08,750
patterns of Domain Driven Design
and the tactical patterns of 

1272
00:59:08,750 --> 00:59:11,710
Domain Driven Design. 
So an organization for leaders, 

1273
00:59:11,750 --> 00:59:15,790
I feel it is important for 
leaders to read about Domain 

1274
00:59:15,790 --> 00:59:18,550
Driven design, especially the 
strategic part of it, because 

1275
00:59:18,550 --> 00:59:22,630
that is going to give you a lot 
of insights on what work remains

1276
00:59:22,630 --> 00:59:26,230
within the organization. 
Where do you put the best people

1277
00:59:26,350 --> 00:59:28,710
in your organization or the best
minds, right? 

1278
00:59:28,870 --> 00:59:30,350
I mean, we don't have an 
inclusive environment. 

1279
00:59:30,350 --> 00:59:34,310
As I mentioned earlier, people 
differ by their own knowledge 

1280
00:59:34,310 --> 00:59:38,390
levels and abilities, but it is 
not a matter of learning. 

1281
00:59:38,390 --> 00:59:40,630
Everybody can learn and work. 
It is just a matter of 

1282
00:59:40,630 --> 00:59:42,350
experience, not a question about
ability. 

1283
00:59:42,740 --> 00:59:45,220
It's just a matter of learning 
and time, right? 

1284
00:59:45,740 --> 00:59:49,620
So given that, people will learn
and they will definitely get up 

1285
00:59:49,620 --> 00:59:51,740
to speed. 
So if you take an organization 

1286
00:59:51,740 --> 00:59:54,140
where you have the best minds or
the most experienced folks, they

1287
00:59:54,140 --> 00:59:55,940
should be trying to solve the 
core problem. 

1288
00:59:56,620 --> 01:00:00,260
An organization, the core domain
and this knowledge should not be

1289
01:00:00,460 --> 01:00:04,420
going out of the organization to
other folks who are like say you

1290
01:00:04,420 --> 01:00:07,820
have a conducting firm or a 
subcontracting or an outsourcing

1291
01:00:07,820 --> 01:00:10,410
firm. 
Sometimes the problem is complex

1292
01:00:10,410 --> 01:00:12,210
enough where you need 
specialized skin sets from an 

1293
01:00:12,210 --> 01:00:14,130
outsourcing firm. 
I'm not saying don't outsource 

1294
01:00:14,130 --> 01:00:17,450
your core domain, but also have 
some people in your organization

1295
01:00:17,450 --> 01:00:19,570
who pad with these people to 
solve the complex problem 

1296
01:00:19,570 --> 01:00:23,130
together. 
So that is a supporting domain 

1297
01:00:23,370 --> 01:00:27,450
which is not a off the shelf 
solution, but I need to build 

1298
01:00:27,450 --> 01:00:29,250
it. 
That is where you can actually 

1299
01:00:29,250 --> 01:00:32,050
probably give an opportunity to 
your younger developers or the 

1300
01:00:32,050 --> 01:00:34,650
junior developers or people who 
are new to the organizations. 

1301
01:00:34,650 --> 01:00:37,510
You can put these people into 
these areas and they will have 

1302
01:00:37,510 --> 01:00:39,510
to know the application, how to 
develop it and how to move 

1303
01:00:39,510 --> 01:00:40,630
forward with the supporting 
domain. 

1304
01:00:41,190 --> 01:00:44,550
And of course for the things 
that are not going to give you a

1305
01:00:44,550 --> 01:00:49,470
competitive advantage like the 
generic domain, something like 

1306
01:00:49,470 --> 01:00:51,630
authentication, authorization, 
don't read when they will just 

1307
01:00:51,630 --> 01:00:55,190
go ahead and buy something off 
the shelf, say for authorization

1308
01:00:55,190 --> 01:00:57,670
use after. 
So it depends. 

1309
01:00:57,670 --> 01:01:00,390
So all of all of this stuff try 
to get that perspective. 

1310
01:01:00,390 --> 01:01:04,120
So when leaders, they read about
Domain Driven design and these 

1311
01:01:04,120 --> 01:01:07,120
kind of concepts that we 
discussed about architecture, 

1312
01:01:07,120 --> 01:01:09,840
the styles and stuff, you need 
to connect the dots. 

1313
01:01:10,280 --> 01:01:13,760
So I'm probably trying to cover 
these as well in my next book. 

1314
01:01:13,760 --> 01:01:17,800
So I'll be writing about these 
and much more in the coming 

1315
01:01:17,800 --> 01:01:20,120
days. 
So I think if we look back the 

1316
01:01:20,120 --> 01:01:22,800
whole episode right, we cover a 
lot of things for all software 

1317
01:01:22,800 --> 01:01:25,200
engineers to actually upscale 
and become a better Craftsman, 

1318
01:01:25,200 --> 01:01:27,280
right? 
We start from the code we start 

1319
01:01:27,280 --> 01:01:30,420
then for some practices. 
And also transforming the teams 

1320
01:01:30,420 --> 01:01:32,180
into learning zones and things 
like that. 

1321
01:01:32,420 --> 01:01:34,940
We also touch on about mind 
maps, a little bit of how you 

1322
01:01:34,940 --> 01:01:37,700
could recollect knowledge. 
And then lastly we talk about 

1323
01:01:37,780 --> 01:01:40,500
architectural styles and also 
understanding domain driven 

1324
01:01:40,500 --> 01:01:42,700
design. 
So all these, I feel, I agree 

1325
01:01:42,700 --> 01:01:45,420
with you that these are all 
very, very important aspects for

1326
01:01:45,420 --> 01:01:47,380
us to become a much better 
software engineer. 

1327
01:01:48,260 --> 01:01:51,140
I want to touch on one more 
thing but just to take notes. 

1328
01:01:52,140 --> 01:01:55,780
I mean have a notebook and a pen
next to you. 

1329
01:01:55,780 --> 01:01:59,060
Whenever you read a book, either
you write it in the book itself 

1330
01:01:59,060 --> 01:02:02,500
in the sidebar or underline or 
mark it or write notes 

1331
01:02:03,260 --> 01:02:05,340
definitely. 
I request folks who are learning

1332
01:02:05,340 --> 01:02:08,460
to take notes. 
Visual note taking is a concept 

1333
01:02:08,460 --> 01:02:10,820
that you can explore which I am 
also collecting a lot of visual 

1334
01:02:10,820 --> 01:02:13,740
note taking samples nowadays. 
So whenever I find something 

1335
01:02:13,740 --> 01:02:15,900
interesting I just take a quick 
screenshot or I just save the 

1336
01:02:15,900 --> 01:02:17,940
image. 
And I have a library of visual 

1337
01:02:17,940 --> 01:02:21,260
notes now which I can refer back
to different styles of visual 

1338
01:02:21,260 --> 01:02:23,380
note. 
Taking it also like mind maps 

1339
01:02:23,380 --> 01:02:27,140
helps you capture complex 
concepts and it helps you in 

1340
01:02:27,140 --> 01:02:30,740
storytelling. 
So my two cents, always learn. 

1341
01:02:31,180 --> 01:02:34,060
Take notes of what you learn. 
Right. 

1342
01:02:34,220 --> 01:02:37,140
Thanks for the plug as well. 
So, Sri Hari, I think we have 

1343
01:02:37,140 --> 01:02:39,700
covered a lot of things 
unfortunately due to the time we

1344
01:02:39,700 --> 01:02:42,980
we have to you know leave soon. 
But I have one last question 

1345
01:02:42,980 --> 01:02:45,420
that I would like to ask you, 
which is a custom question that 

1346
01:02:45,420 --> 01:02:48,220
I, I have to to ask for all my 
guests. 

1347
01:02:48,460 --> 01:02:50,580
I call this 3 technical 
leadership wisdom. 

1348
01:02:50,930 --> 01:02:53,090
So you can think of it just like
advice that you want to give to 

1349
01:02:53,090 --> 01:02:55,890
us to learn from you. 
So what will be your 3 technical

1350
01:02:55,890 --> 01:02:59,210
leadership system? 
Not every problem is technical 

1351
01:02:59,210 --> 01:03:02,050
in nature. 
Many of the time it's people, 

1352
01:03:02,570 --> 01:03:04,810
right? 
So give respect to people and 

1353
01:03:04,810 --> 01:03:08,370
treat them with immense respect.
And everybody should get their 

1354
01:03:08,370 --> 01:03:11,130
share of respect irrespective of
their background, irrespective 

1355
01:03:11,130 --> 01:03:14,130
of anything, right? 
So respect your folks who are 

1356
01:03:14,130 --> 01:03:16,930
working with you and your team. 
That will go a long way in 

1357
01:03:16,930 --> 01:03:19,950
building a working relationship,
but it's not about who is right 

1358
01:03:19,950 --> 01:03:21,710
or who is wrong, it's about the 
working relationship. 

1359
01:03:21,710 --> 01:03:25,110
So gracious behavior is one of 
the key aspects that I would 

1360
01:03:25,230 --> 01:03:28,310
recommend to folks. 
I'm also in the process of 

1361
01:03:28,310 --> 01:03:31,510
learning. 
Not that I'm perfect, so always 

1362
01:03:31,510 --> 01:03:33,990
try to be gracious. 
Let the other person save face 

1363
01:03:33,990 --> 01:03:35,710
and keep moving. 
That is one thing. 

1364
01:03:36,710 --> 01:03:41,270
Second advice that I would not 
an advice, an input, or a wisdom

1365
01:03:41,270 --> 01:03:44,430
I would like to share is to 
learn something every day. 

1366
01:03:45,230 --> 01:03:48,620
I mean you cannot conquer 
without practice, right? 

1367
01:03:48,860 --> 01:03:53,220
It might not be a new piece of 
wisdom, but as technical folks 

1368
01:03:53,220 --> 01:03:56,780
or technical leads or 
architects, we need to keep 

1369
01:03:57,500 --> 01:04:01,860
learning and capture your 
learning so that you can share 

1370
01:04:01,860 --> 01:04:05,100
and recollect and teach others. 
Always share what you learn, as 

1371
01:04:05,100 --> 01:04:07,100
Yoda said. 
So that is one thing. 

1372
01:04:08,020 --> 01:04:13,220
And the third piece of input 
would be try to bring in variety

1373
01:04:13,220 --> 01:04:15,620
in your learning. 
I mean, don't learn the same 

1374
01:04:15,620 --> 01:04:18,090
kind of stuff. 
Let us say you're learning a 

1375
01:04:18,090 --> 01:04:21,210
programming language in a given 
paradigm, say object oriented. 

1376
01:04:21,730 --> 01:04:25,170
The next language try to learn 
in a functional way. 

1377
01:04:25,810 --> 01:04:29,770
This gives you different set of 
tools that you can apply for 

1378
01:04:29,770 --> 01:04:32,490
specific problems. 
Because it is not the 

1379
01:04:32,490 --> 01:04:35,250
programming language that 
determines a given project that 

1380
01:04:35,250 --> 01:04:39,250
they're going to work on, but it
is the problem domain that 

1381
01:04:39,370 --> 01:04:42,320
demands a given technology 
stack, right? 

1382
01:04:42,440 --> 01:04:44,400
Let's say you want to develop an
enterprise app. 

1383
01:04:44,400 --> 01:04:46,880
You are better off doing it with
javaor.net or something. 

1384
01:04:47,760 --> 01:04:49,680
And if you want to do something 
in data engineering, you are 

1385
01:04:49,680 --> 01:04:52,120
better off doing it with Python.
Let us say you want to do 

1386
01:04:52,120 --> 01:04:53,360
something with statistical 
computing. 

1387
01:04:53,360 --> 01:04:55,640
You want to better off doing it 
with R or Python. 

1388
01:04:56,440 --> 01:04:58,720
And if you go, probably if you 
go and use some of the text 

1389
01:04:58,720 --> 01:05:00,640
stack which is not appropriate, 
you will burn your fingers, 

1390
01:05:00,840 --> 01:05:03,200
right? 
So use the right tool for the 

1391
01:05:03,200 --> 01:05:08,040
right problem and the right 
domain, which actually helps you

1392
01:05:08,320 --> 01:05:11,670
become a better person. 
So have that variety in terms of

1393
01:05:11,670 --> 01:05:15,310
learning and try to apply your 
learning and share your 

1394
01:05:15,310 --> 01:05:17,350
learning. 
I like the last part, right? 

1395
01:05:17,350 --> 01:05:20,310
So you also need to know the 
variety and the options that you

1396
01:05:20,310 --> 01:05:22,550
do have, right? 
So that you can tackle the 

1397
01:05:22,550 --> 01:05:25,750
problem with the right tool. 
So thank you so much Sihari for 

1398
01:05:25,750 --> 01:05:28,030
this conversation. 
If people would like to connect 

1399
01:05:28,030 --> 01:05:30,590
and find you online or ask you 
about questions, is there a 

1400
01:05:30,590 --> 01:05:34,030
place where they can find you? 
Yeah, they can find me on top. 

1401
01:05:34,030 --> 01:05:38,240
Meet as well as LinkedIn and I'm
happy to you wanna break with 

1402
01:05:38,240 --> 01:05:41,040
folks and try to provide any 
help that I can all. 

1403
01:05:42,040 --> 01:05:43,520
Right. 
Thank you so much again for your

1404
01:05:43,520 --> 01:05:45,200
time. 
I hope everyone who listens to 

1405
01:05:45,200 --> 01:05:48,640
this episode can become a better
software Craftsman and thank you

1406
01:05:48,640 --> 01:05:51,000
for your opportunity. 
Henry and I'm also learning in 

1407
01:05:51,000 --> 01:05:53,440
the process. 
It was a great conversation and 

1408
01:05:53,440 --> 01:05:55,120
thank you for interesting your 
time and having this 

1409
01:05:55,120 --> 01:06:00,480
conversation. 
Thank you for listening to this 

1410
01:06:00,480 --> 01:06:03,880
episode and for staying right 
until the end if you highly 

1411
01:06:03,880 --> 01:06:06,270
enjoyed it. 
I would appreciate if you share 

1412
01:06:06,270 --> 01:06:08,590
it with your friends and 
colleagues who you think would 

1413
01:06:08,590 --> 01:06:10,870
also benefit from listening to 
this episode. 

1414
01:06:11,270 --> 01:06:14,070
And if you're new to the 
podcast, make sure to subscribe 

1415
01:06:14,070 --> 01:06:16,430
and leave me your valuable 
review and feedback. 

1416
01:06:16,790 --> 01:06:19,670
It helps me a lot in order to 
grow this podcast better. 

1417
01:06:20,150 --> 01:06:23,070
You can also find the full show 
notes of this conversation on 

1418
01:06:23,070 --> 01:06:26,030
the episode page at Technically 
journal dot dev website, 

1419
01:06:26,350 --> 01:06:29,950
including the full transcript, 
interesting quotes and links to 

1420
01:06:29,950 --> 01:06:32,350
the resources mentioned from the
conversation. 

1421
01:06:32,750 --> 01:06:35,150
And lastly. 
Make sure to subscribe to the 

1422
01:06:35,150 --> 01:06:38,990
shows mailing list on Techly 
Juno dot dev to get notified for

1423
01:06:38,990 --> 01:06:42,190
any future episodes. 
Stay tuned for the next Techly 

1424
01:06:42,190 --> 01:06:45,150
Juno episode, and until then, 
goodbye.