1
00:00:00,200 --> 00:00:02,100
As a leader, it's not your 
responsibility to do. 

2
00:00:02,200 --> 00:00:04,700
It's your responsibility to 
teach and help your team to 

3
00:00:04,700 --> 00:00:06,400
level up. 
Your job is to level up your 

4
00:00:06,400 --> 00:00:09,100
team so that you have a team of 
people who can do it better and 

5
00:00:09,100 --> 00:00:15,000
faster. 
Hey everyone. 

6
00:00:15,500 --> 00:00:17,600
My name is Henry Surya. 
Juan. 

7
00:00:18,900 --> 00:00:21,600
And you're listening to the 
tekhelet journal. 

8
00:00:22,200 --> 00:00:25,300
The show will be bringing you 
the greatest technical leaders 

9
00:00:25,600 --> 00:00:29,100
practitioners and thought 
leaders in the industry to 

10
00:00:29,100 --> 00:00:33,400
discuss about their Journey 
ideas and practices that we all 

11
00:00:33,400 --> 00:00:37,200
can learn and apply to build a 
highly performing technical team

12
00:00:37,400 --> 00:00:40,000
and to make an impact in your 
personal work. 

13
00:00:40,600 --> 00:00:47,500
So let's dive into our Journal. 
Hey, hey. 

14
00:00:47,500 --> 00:00:51,000
Hey, welcome back to another 
episode of the tekhelet journal 

15
00:00:51,100 --> 00:00:52,700
with me. 
Ojos, Henry Surya. 

16
00:00:52,700 --> 00:00:57,000
We do one time passes by so 
quick, and I'm extremely happy 

17
00:00:57,000 --> 00:00:59,100
to reach a new milestone for 
this show. 

18
00:00:59,400 --> 00:01:03,000
Today's episode is technically 
Journal episode number ten, 

19
00:01:03,200 --> 00:01:07,100
which is its first double-digit 
episode Special, thanks to all 

20
00:01:07,100 --> 00:01:09,900
of the great guess who 
participated in the show and I 

21
00:01:09,900 --> 00:01:13,400
cannot thank you enough for your
trust support and sharing of 

22
00:01:13,400 --> 00:01:16,900
your knowledge and Them with me 
and all the listeners out there.

23
00:01:17,400 --> 00:01:20,600
I have also been genuinely 
humbled by some of your comments

24
00:01:20,600 --> 00:01:23,700
and feedback either through 
direct messages or the social 

25
00:01:23,700 --> 00:01:26,900
media channels, and I would 
continue to do my best to 

26
00:01:26,900 --> 00:01:29,700
produce, great content for all 
of us to learn from. 

27
00:01:30,300 --> 00:01:33,500
I have some exciting guests for 
the upcoming episodes, and I'm 

28
00:01:33,500 --> 00:01:36,800
looking forward to releasing 
those episodes in the upcoming 

29
00:01:36,800 --> 00:01:39,100
weeks. 
If you have been liking the show

30
00:01:39,100 --> 00:01:42,600
so far, please consider leaving 
me your comments and feedback 

31
00:01:42,800 --> 00:01:46,400
and I would greatly appreciate. 
She ate it and if you'd like to 

32
00:01:46,400 --> 00:01:49,400
pledge your support and make 
contribution to the show, you 

33
00:01:49,400 --> 00:01:52,800
can do so through our patreon 
page at tekhelet journal, the 

34
00:01:52,800 --> 00:01:57,900
death / Patron, Our Guest for 
today's episode is Trisha g, a 

35
00:01:57,900 --> 00:02:01,000
Java Champion author and the 
leader of java developer. 

36
00:02:01,000 --> 00:02:04,900
Advocacy team at jetbrains. 
She has an extensive Java 

37
00:02:04,900 --> 00:02:08,100
experience with an expertise. 
In Java, high performance 

38
00:02:08,100 --> 00:02:10,699
systems. 
Trisha is exceptionally, 

39
00:02:10,699 --> 00:02:13,700
passionate about sharing things 
that help real Developers. 

40
00:02:14,200 --> 00:02:17,500
Includes getting them up to 
speed with the latest version of

41
00:02:17,500 --> 00:02:20,700
java teaching them tips and 
tricks to save time with 

42
00:02:20,700 --> 00:02:24,500
IntelliJ IDEA or promoting 
healthy technical communities 

43
00:02:24,500 --> 00:02:27,600
across the globe. 
Trisha is an author of a few 

44
00:02:27,600 --> 00:02:31,900
books, what to look for in a 
code review and 97 things. 

45
00:02:31,900 --> 00:02:33,700
Every Java developer should 
know. 

46
00:02:34,200 --> 00:02:38,100
Trisha also produces a monthly 
newsletter for jetbrains, called

47
00:02:38,100 --> 00:02:42,100
Java annotated monthly which is 
a great monthly summary for all 

48
00:02:42,100 --> 00:02:44,000
things happening in the Java 
world. 

49
00:02:44,200 --> 00:02:47,100
In this episode. 
I had a chat with Trisha about 

50
00:02:47,100 --> 00:02:50,800
the current state of java and 
how it stands compared to other 

51
00:02:50,800 --> 00:02:54,000
programming languages. 
She also gave some good tips on 

52
00:02:54,000 --> 00:02:57,900
how to transition from old Java 
version to the latest Java 

53
00:02:57,900 --> 00:03:00,200
version as a long time. 
Java developer. 

54
00:03:00,200 --> 00:03:03,900
I have to admit that my Java 
knowledge is still stuck in Java

55
00:03:03,900 --> 00:03:05,700
8. 
While the current Java version 

56
00:03:05,700 --> 00:03:09,300
is version 15 and looking at the
recent surveys. 

57
00:03:09,300 --> 00:03:13,200
It seems that the majority of us
Java developers still use Java 

58
00:03:13,200 --> 00:03:14,900
8. 
So make sure Go to listen to 

59
00:03:14,900 --> 00:03:18,500
Trisha steps Tricia shared about
some of the code review. 

60
00:03:18,500 --> 00:03:22,300
Best practices and explain why 
reading code is harder than 

61
00:03:22,300 --> 00:03:25,700
writing it and that we should 
put more effort in making our 

62
00:03:25,700 --> 00:03:28,600
code more readable. 
She also suggested, why a 

63
00:03:28,608 --> 00:03:32,900
developer should use an IDE and 
how using an ID could help in 

64
00:03:32,900 --> 00:03:36,600
increasing your productivity and
producing a more readable and 

65
00:03:36,600 --> 00:03:39,900
idiomatic code. 
Trisha also shared some of her 

66
00:03:39,900 --> 00:03:43,000
lessons learned from her recent 
transition to become a team 

67
00:03:43,000 --> 00:03:45,200
lead. 
I hope that it enjoyed this 

68
00:03:45,200 --> 00:03:48,500
episode and I'm looking forward 
to hearing your comments and 

69
00:03:48,500 --> 00:03:51,000
feedback. 
Let's get started right after 

70
00:03:51,000 --> 00:03:54,300
our sponsor message. 
Do you want to learn to code? 

71
00:03:54,700 --> 00:03:58,000
Do you have friends who are 
looking to learn how to code our

72
00:03:58,000 --> 00:04:02,000
sponsor at jetbrains recently? 
Launched jetbrains Academy and 

73
00:04:02,000 --> 00:04:05,300
education platform that offers 
interactive Project based 

74
00:04:05,300 --> 00:04:07,700
learning combined, with 
powerful, professional 

75
00:04:07,700 --> 00:04:11,000
development tools, Advanced, 
your Java and python skills. 

76
00:04:11,100 --> 00:04:14,700
With more programming languages 
to come to get an And it three 

77
00:04:14,700 --> 00:04:17,000
month, free trial on jetbrains 
Academy. 

78
00:04:17,100 --> 00:04:19,600
You can go to technology. 
No dot, f /. 

79
00:04:19,600 --> 00:04:22,900
Jetbrains Dash Academy. 
You can go to tekhelet journal 

80
00:04:22,900 --> 00:04:25,500
dot, f /. 
Jetbrains Dash Academy. 

81
00:04:28,000 --> 00:04:30,000
Hey, Trisha is great. 
To have you in the show. 

82
00:04:30,000 --> 00:04:31,600
So, welcome to the Tecla 
Journal. 

83
00:04:31,900 --> 00:04:33,500
Well, thank you for having me. 
So Trish. 

84
00:04:33,500 --> 00:04:36,000
I've seen you a lot about my 
journey in my career. 

85
00:04:36,000 --> 00:04:38,100
I use Java a lot in the previous
jobs. 

86
00:04:38,200 --> 00:04:40,900
You have been the public figure 
of the Java world and also 

87
00:04:40,900 --> 00:04:43,100
jetbrains. 
I'm also a jetbrains users for a

88
00:04:43,100 --> 00:04:44,800
long time. 
It's really great to have you in

89
00:04:44,800 --> 00:04:47,700
the show and hopefully you can 
share some of your knowledge and

90
00:04:47,700 --> 00:04:49,400
probably the state of the Java 
world. 

91
00:04:49,400 --> 00:04:51,100
And what are you up to these 
days? 

92
00:04:51,400 --> 00:04:52,700
I would love to share all that 
stuff. 

93
00:04:52,700 --> 00:04:54,600
I'm happy to talk about pretty 
much anything. 

94
00:04:55,100 --> 00:04:57,800
So maybe before we start, can 
you share your career Journey so

95
00:04:57,800 --> 00:05:00,700
far and also highlighting some 
of the major turning points that

96
00:05:00,700 --> 00:05:03,000
you have in your career that 
probably are interesting for the

97
00:05:03,000 --> 00:05:04,800
listeners here to learn about 
you. 

98
00:05:05,200 --> 00:05:07,200
I'll try to give The Abridged 
version because I don't want to 

99
00:05:07,200 --> 00:05:08,500
give you like the 20-year 
version. 

100
00:05:08,500 --> 00:05:11,100
I came from a traditional Jewish
background for a programmer. 

101
00:05:11,100 --> 00:05:13,300
In that. 
I did a computer science degree 

102
00:05:13,300 --> 00:05:15,100
did computer science. 
Special intelligence. 

103
00:05:15,300 --> 00:05:18,500
I picked that because I was 
doing Computing at between 16 

104
00:05:18,500 --> 00:05:20,900
and 18 in high school. 
And I've figured I really like 

105
00:05:20,900 --> 00:05:23,300
the programming actually, I was 
originally going to do physics 

106
00:05:23,300 --> 00:05:26,000
astrophysics, but I really like 
programming, so I decided to 

107
00:05:26,000 --> 00:05:28,500
computer science at University 
through the first year to study 

108
00:05:28,500 --> 00:05:31,400
Java at University. 
This is like 97 and we were 

109
00:05:31,400 --> 00:05:36,600
studying Java 1.2 and then I 
graduated in 2001 kind of just 

110
00:05:36,600 --> 00:05:40,200
at the.com crash, but I had a 
bit of experience from doing 

111
00:05:40,200 --> 00:05:42,800
some undergraduate work at Ford 
Motor Company. 

112
00:05:42,900 --> 00:05:44,000
That was actually using the 
Microsoft. 

113
00:05:44,100 --> 00:05:46,300
Stack that was fortunate because
I had a little bit of 

114
00:05:46,300 --> 00:05:47,800
experience. 
So even though I was a new 

115
00:05:47,800 --> 00:05:51,000
graduate, I managed to get a job
fairly easily in London from 

116
00:05:51,000 --> 00:05:52,600
then on. 
I was basically doing Java 

117
00:05:52,600 --> 00:05:55,500
because I had my job or 
experienced JSP and servlets 

118
00:05:55,500 --> 00:05:57,200
with coming into their own. 
At that time. 

119
00:05:57,400 --> 00:06:00,400
I was doing web development for 
five years or so, then I've 

120
00:06:00,400 --> 00:06:04,600
ended up moving into backend, 
Java staff and financial markets

121
00:06:04,700 --> 00:06:07,200
and working for banks and stuff 
because I was in London and 

122
00:06:07,200 --> 00:06:09,900
that's where all the jobs were. 
I deliberately moved myself to 

123
00:06:09,900 --> 00:06:13,200
the backend from web development
because again at that time amid 

124
00:06:13,200 --> 00:06:16,000
naughties That's where you get 
taken seriously as a Java 

125
00:06:16,000 --> 00:06:17,900
developer rather than on the 
front end. 

126
00:06:17,900 --> 00:06:21,900
And then, I spent a bit of time 
doing consulting again, Java 

127
00:06:21,900 --> 00:06:24,100
development for the bank's, 
then, I worked for a company 

128
00:06:24,100 --> 00:06:26,900
called lmax for four years and 
that was a financial Exchange in

129
00:06:26,900 --> 00:06:29,000
London and that completely 
changed my career. 

130
00:06:29,000 --> 00:06:31,700
Because until then I was doing 
fairly standard Java 

131
00:06:31,700 --> 00:06:33,300
development, stuff. 
Nothing wrong with that. 

132
00:06:33,300 --> 00:06:35,900
But you normal 925 development 
doing consulting working for the

133
00:06:35,900 --> 00:06:38,900
banks and things like that. 
I've been reading about agile. 

134
00:06:38,900 --> 00:06:41,900
I'd been reading about 
Automation and things like that,

135
00:06:41,900 --> 00:06:43,900
but I haven't really seen a lot 
of that stuff done in. 

136
00:06:44,100 --> 00:06:46,300
In the real world. 
And then when I worked at lmax, 

137
00:06:46,300 --> 00:06:48,900
I was working with Dave Foley, 
who was at the time were 

138
00:06:48,900 --> 00:06:51,200
writing, the continuous delivery
book, and we were doing 

139
00:06:51,200 --> 00:06:54,300
continuous delivery. 
I was working with very talented

140
00:06:54,300 --> 00:06:56,200
team, where we were doing pair 
programming. 

141
00:06:56,300 --> 00:07:00,500
So I learnt so much in terms of 
design, in terms of 

142
00:07:00,600 --> 00:07:03,200
well-structured code, in terms 
of readable code. 

143
00:07:03,200 --> 00:07:06,100
I'd always commented my code 
because my memory is terrible. 

144
00:07:06,100 --> 00:07:08,700
And when I went to El maximize 
pairing with people, they helped

145
00:07:08,700 --> 00:07:11,200
me write code that didn't 
necessarily need comments. 

146
00:07:11,200 --> 00:07:14,000
They use their tools to refactor
stuff if the naming didn't make.

147
00:07:14,100 --> 00:07:16,500
Sense, and this is where I 
really leveled up my IntelliJ 

148
00:07:16,500 --> 00:07:18,900
IDEA knowledge because when you 
pair with people and you see 

149
00:07:18,900 --> 00:07:21,800
them using the tool properly, 
then you get what it's for you, 

150
00:07:21,800 --> 00:07:24,600
get that it's not just an 
editor, you understand that you 

151
00:07:24,600 --> 00:07:27,000
can refactor on the Fly and it 
won't break anything. 

152
00:07:27,000 --> 00:07:30,300
You understand how to write 
tests first and have the tools. 

153
00:07:30,300 --> 00:07:33,200
Generate the code for you, that 
will keep things green. 

154
00:07:33,200 --> 00:07:35,900
And so you work in what I now 
think of as the correct way, 

155
00:07:35,900 --> 00:07:38,300
whereas before I wasn't using 
the tools to their fullest 

156
00:07:38,300 --> 00:07:40,800
extent when I was working. 
There we were doing a bit of 

157
00:07:40,800 --> 00:07:42,300
what we now call developer. 
Advocacy. 

158
00:07:42,300 --> 00:07:47,000
I worked there from And and 92 
2012. 

159
00:07:47,000 --> 00:07:48,400
And so I was doing a bit 
developer. 

160
00:07:48,400 --> 00:07:51,800
Advocacy for them because Dave 
was speaking at conferences on 

161
00:07:51,800 --> 00:07:54,300
continuous delivery in the stuff
related to his book. 

162
00:07:54,300 --> 00:07:56,500
His boss. 
Martin Thompson was speaking at 

163
00:07:56,500 --> 00:07:59,800
conferences about performance in
Java because we were writing 

164
00:07:59,800 --> 00:08:02,100
this low latency Financial 
Exchange in Java. 

165
00:08:02,100 --> 00:08:04,400
Which at the time no one did 
everyone did all of that stuff 

166
00:08:04,400 --> 00:08:07,100
in C and C plus but Martin 
realized that the power of the 

167
00:08:07,100 --> 00:08:10,100
jvm is especially with the 
runtime optimizations and staff.

168
00:08:10,200 --> 00:08:13,400
You can actually get very high 
performance from java code 

169
00:08:13,400 --> 00:08:16,200
without having To contort 
yourself writing high 

170
00:08:16,200 --> 00:08:18,300
performance code. 
You just write clean code and 

171
00:08:18,300 --> 00:08:20,100
the jvm will do the rest for 
you. 

172
00:08:20,200 --> 00:08:22,700
So he was speaking at 
conferences about mechanical 

173
00:08:22,700 --> 00:08:25,200
sympathy about high performance.
Java code. 

174
00:08:25,200 --> 00:08:28,300
I was tagging along with them 
and I was blogging about the 

175
00:08:28,300 --> 00:08:31,100
disruptor, which is this open 
source, Java framework that we 

176
00:08:31,100 --> 00:08:33,799
created a tell Max this 
basically opened up a whole new 

177
00:08:33,799 --> 00:08:37,100
world to me in terms of blogging
in terms of conferences, in 

178
00:08:37,100 --> 00:08:39,299
terms of developer. 
Advocacy after that. 

179
00:08:39,299 --> 00:08:42,100
I left to join mongodb. 
So that I could be a developer 

180
00:08:42,100 --> 00:08:43,799
Advocate and that was going to 
be my role. 

181
00:08:44,000 --> 00:08:47,200
However, mongodb for two years, 
doing open source staff and big 

182
00:08:47,200 --> 00:08:48,800
data and nosql, and things like 
that. 

183
00:08:48,800 --> 00:08:52,800
When I was there, I was doing 
live coding live demos again, 

184
00:08:52,800 --> 00:08:55,000
using IntelliJ IDEA because 
that's what I love. 

185
00:08:55,000 --> 00:08:57,300
And so jetbrains came to me and 
said, why don't you come and do 

186
00:08:57,300 --> 00:08:59,900
that for us since you seem to 
actually know the tool really 

187
00:08:59,900 --> 00:09:01,500
well. 
We want a developer Advocate. 

188
00:09:01,500 --> 00:09:03,700
This is what you do. 
And I was like, well, that makes

189
00:09:03,700 --> 00:09:06,800
sense because at that time I was
doing 50% engineering and 50% 

190
00:09:06,800 --> 00:09:09,000
Advocacy. 
It was just impossible because 

191
00:09:09,000 --> 00:09:11,300
the two sets of deadlines don't 
work, you have release 

192
00:09:11,300 --> 00:09:13,100
deadlines. 
You have hard deadlines for the 

193
00:09:13,100 --> 00:09:15,400
engineering side, you Hard 
deadlines for the conference 

194
00:09:15,400 --> 00:09:18,400
side because there's always a 
cfp due dates conference, dates 

195
00:09:18,500 --> 00:09:21,100
those two sets of deliverables, 
not compatible and you can't 

196
00:09:21,100 --> 00:09:23,300
plan around each other. 
So I decided that being a 

197
00:09:23,300 --> 00:09:26,000
full-time Advocate but still 
doing the engineering more in 

198
00:09:26,008 --> 00:09:29,300
terms of smaller projects, 
learning projects tutorials, 

199
00:09:29,300 --> 00:09:31,100
that kind of thing. 
That's where I keep my 

200
00:09:31,100 --> 00:09:33,200
engineering hand in and just do 
full-time. 

201
00:09:33,200 --> 00:09:35,400
Developer. 
Advocacy teaching in the 

202
00:09:35,400 --> 00:09:38,900
jetbrains way is not to teach 
IntelliJ IDEA but to teach 

203
00:09:38,900 --> 00:09:42,000
programming in IntelliJ IDEA, 
which again, conforms to what I 

204
00:09:42,000 --> 00:09:45,600
want to do, I want to help Java.
Uppers become more effective, 

205
00:09:45,600 --> 00:09:47,900
Java developers. 
I don't need to teach them how 

206
00:09:47,900 --> 00:09:49,400
to be effective. 
IDE users. 

207
00:09:49,400 --> 00:09:51,700
That's not helpful. 
What you want to do is you want 

208
00:09:51,700 --> 00:09:54,600
to write code for your 
organization for your project. 

209
00:09:54,600 --> 00:09:56,700
You don't really care about 
knowing at all inside out. 

210
00:09:56,700 --> 00:09:59,900
But if you can learn at all to 
do your job better, that's 

211
00:09:59,900 --> 00:10:01,400
useful. 
And so that's a brand of 

212
00:10:01,400 --> 00:10:03,800
advocacy that I've been doing 
for about six years for 

213
00:10:03,800 --> 00:10:06,200
jetbrains. 
Now, recently, you mentioned to 

214
00:10:06,200 --> 00:10:08,700
me that you just got promoted to
a team lead. 

215
00:10:08,700 --> 00:10:11,500
Maybe you can share the journey.
How you got promoted. 

216
00:10:11,600 --> 00:10:13,800
Maybe, what have you learned 
throughout this journey? 

217
00:10:14,100 --> 00:10:15,500
So that's really interesting. 
Actually. 

218
00:10:15,500 --> 00:10:17,600
I kind of always wanted to be a 
lead. 

219
00:10:17,600 --> 00:10:20,000
I don't know if that's just you 
always want more responsibility 

220
00:10:20,000 --> 00:10:22,100
because you want more money or 
you want a better job title or 

221
00:10:22,100 --> 00:10:24,800
if it's because I actually want 
to do the leading side of stuff.

222
00:10:24,800 --> 00:10:27,500
I've been a professional for to 
20 years or so. 

223
00:10:27,600 --> 00:10:29,900
And one of the things I've 
learned over those 20 years, is 

224
00:10:29,900 --> 00:10:32,800
that the skills you need as a 
lead and not the same skills you

225
00:10:32,808 --> 00:10:35,300
need as a good programmer. 
So for me, there's always been a

226
00:10:35,308 --> 00:10:37,800
tension between, do I want to 
leave some of the engineering 

227
00:10:37,800 --> 00:10:40,100
behind? 
Because I know I have the skills

228
00:10:40,100 --> 00:10:42,400
for leading, but then I won't 
have the engineering. 

229
00:10:42,500 --> 00:10:45,500
I've done some team-leading in 
the Past of small teams on small

230
00:10:45,500 --> 00:10:48,100
projects and I've always liked 
that as long as I can say, 

231
00:10:48,100 --> 00:10:50,800
Hands-On in terms of being a 
deliver as well. 

232
00:10:50,800 --> 00:10:53,300
But I've never really progressed
up that whole path, probably, 

233
00:10:53,300 --> 00:10:55,200
because the code keeps pulling 
me back. 

234
00:10:55,200 --> 00:10:57,700
I can see the end goal is being 
CTO or something. 

235
00:10:57,700 --> 00:10:59,200
I'm not really sure that's for 
me. 

236
00:10:59,200 --> 00:11:01,300
When I joined jetbrains. 
There are two developer 

237
00:11:01,300 --> 00:11:03,800
advocates for IntelliJ IDEA, but
the other one, Brendan he left 

238
00:11:03,800 --> 00:11:05,900
fairly early on. 
I was the only advocate for 

239
00:11:05,900 --> 00:11:08,400
IntelliJ IDEA for maybe a four 
years or so. 

240
00:11:08,600 --> 00:11:12,200
We hired Malla at the start of 
last year, the overall 

241
00:11:12,200 --> 00:11:13,900
developer. 
Advocacy team for jetbrains. 

242
00:11:14,000 --> 00:11:16,100
When I joined, I was maybe 10 or
12 of us. 

243
00:11:16,100 --> 00:11:19,900
And by the end of last year, 
there was maybe 20 of us and my 

244
00:11:19,900 --> 00:11:21,300
boss is managing. 
All of that. 

245
00:11:21,300 --> 00:11:23,500
I asked my boss. 
Can I manage the team? 

246
00:11:23,500 --> 00:11:26,300
Because I think I could do this 
and he's like, no, but what we 

247
00:11:26,300 --> 00:11:29,200
will do is we will split the 
advocacy team into smaller 

248
00:11:29,200 --> 00:11:31,900
teams, which makes way more 
sense because managing 20 people

249
00:11:31,900 --> 00:11:34,800
is not visible for anyone. 
He split as off into the job. 

250
00:11:34,800 --> 00:11:38,400
Advocacy team, which was me and 
Marla at the start of this year.

251
00:11:38,400 --> 00:11:41,800
And then he also tasked me with 
hiring another person so that we

252
00:11:41,800 --> 00:11:44,000
become a proper team rather than
just two people doing the same. 

253
00:11:44,000 --> 00:11:45,100
Same stuff. 
Technically. 

254
00:11:45,100 --> 00:11:46,800
I was leading malar. 
But when there's only two of 

255
00:11:46,800 --> 00:11:49,600
you, you're not really leading 
so much as mentoring obviously, 

256
00:11:49,600 --> 00:11:51,600
because I've been at jetbrains 
for a long time and I've been 

257
00:11:51,600 --> 00:11:53,400
doing developer. 
Advocacy for longer. 

258
00:11:53,400 --> 00:11:56,500
My focus is leader since January
has been much more mentoring 

259
00:11:56,500 --> 00:11:59,200
teaching helping Malla to grow 
in the direction. 

260
00:11:59,200 --> 00:12:00,800
She wants to go in. 
She doesn't have to become a 

261
00:12:00,808 --> 00:12:02,800
mini Trish. 
She has her own strengths and I 

262
00:12:02,808 --> 00:12:05,400
want to help her figure out what
they are and leverage them. 

263
00:12:05,400 --> 00:12:08,600
And then, we hired Helen in 
July, Helen comes from a 

264
00:12:08,608 --> 00:12:10,800
slightly different background, 
which has been an industry for 

265
00:12:10,800 --> 00:12:12,500
20 years. 
And she's worked with a lot of 

266
00:12:12,508 --> 00:12:14,500
java development teams. 
She's had Bunch of different 

267
00:12:14,500 --> 00:12:17,800
roles, but she's come more from 
a technical writing point of 

268
00:12:17,808 --> 00:12:19,500
view. 
And I thought that was really 

269
00:12:19,500 --> 00:12:22,000
interesting because what I've 
done is I've hired a developer 

270
00:12:22,000 --> 00:12:25,900
Advocate with stronger advocacy 
skills than perhaps recent 

271
00:12:25,900 --> 00:12:28,500
experience in engineering side. 
Whereas what we normally do is 

272
00:12:28,500 --> 00:12:31,000
you normally hire an experienced
engineer and teach them the 

273
00:12:31,000 --> 00:12:33,400
advocacy side of Staff. 
One of the things I'm doing is a

274
00:12:33,408 --> 00:12:33,800
lead. 
Again. 

275
00:12:33,800 --> 00:12:35,500
It's all about mentoring and 
learning and growing for 

276
00:12:35,500 --> 00:12:38,600
everybody is. 
I'm trying to help her see the 

277
00:12:38,600 --> 00:12:41,000
strength. 
She already has in the advocacy 

278
00:12:41,000 --> 00:12:42,700
side of stuff because she 
doesn't think of them as 

279
00:12:42,700 --> 00:12:45,400
advocacy skills because not the 
job title she had before but 

280
00:12:45,400 --> 00:12:47,100
they are absolutely advocacy 
skills. 

281
00:12:47,100 --> 00:12:49,700
Talking about writing was from 
at teaching, were talking about 

282
00:12:49,708 --> 00:12:52,400
influencing were talking about 
all of those kinds of things 

283
00:12:52,400 --> 00:12:55,600
which is generally speaking 
difficult for engineers to 

284
00:12:55,600 --> 00:12:57,800
necessarily learn gross. 
Generalization. 

285
00:12:57,800 --> 00:12:59,300
Let her see, that's her 
strength. 

286
00:12:59,300 --> 00:13:01,600
That's what she's already got. 
And then work a bit on the 

287
00:13:01,600 --> 00:13:03,300
engineering side. 
She comes from an engineering 

288
00:13:03,300 --> 00:13:04,800
background. 
She's worked with engineering 

289
00:13:04,800 --> 00:13:07,300
teams and just modernize those 
skills because it's been a 

290
00:13:07,300 --> 00:13:09,400
while. 
Since she's done them, my role 

291
00:13:09,400 --> 00:13:11,900
as team lead in, my mind is very
much about. 

292
00:13:11,900 --> 00:13:16,200
It's not about being the Deliver
I do know IntelliJ better. 

293
00:13:16,200 --> 00:13:19,400
I have more industry experience 
as a Java program and then both 

294
00:13:19,400 --> 00:13:21,700
Helen and maladjusted because 
I've been around for longer, but

295
00:13:21,700 --> 00:13:24,100
it's not up to me to do all the 
hard stuff. 

296
00:13:24,100 --> 00:13:26,600
It's not up to me to do all the 
key pieces. 

297
00:13:26,600 --> 00:13:29,600
It's up to me to step back from 
that and help level up the two 

298
00:13:29,600 --> 00:13:32,300
members of my team. 
Because if I'm doing all of that

299
00:13:32,300 --> 00:13:35,800
stuff, they're not really able 
to contribute as much for me, a 

300
00:13:35,800 --> 00:13:39,100
team leaders is first and 
foremost, a mentor, a teacher, a

301
00:13:39,100 --> 00:13:40,900
level Opera. 
That's how you get 10x, 

302
00:13:40,900 --> 00:13:43,400
programmers, that the senior 
programmers are people who 

303
00:13:43,400 --> 00:13:45,700
helped the Ten developers around
them, get better. 

304
00:13:45,700 --> 00:13:47,900
I'm still fairly new to this 
though, and I'm interested to 

305
00:13:47,900 --> 00:13:50,300
see this is really a bit of an 
experiment, the way that I want 

306
00:13:50,300 --> 00:13:53,500
to run the team, the focus very 
much on mentoring on teaching 

307
00:13:53,500 --> 00:13:55,600
each other. 
I have a lot to learn from Malla

308
00:13:55,600 --> 00:13:57,300
and Helen as well. 
One of the reasons I want to 

309
00:13:57,300 --> 00:13:59,400
work with them is because they 
have skills. 

310
00:13:59,400 --> 00:14:02,600
I don't have I don't see it as I
am their boss and I tell them 

311
00:14:02,600 --> 00:14:04,600
what to do. 
I see it as I have a bunch of 

312
00:14:04,608 --> 00:14:07,600
experience in certain areas, 
like working at jetbrains like 

313
00:14:07,600 --> 00:14:10,700
IntelliJ IDEA to some extent, 
the Java industry, but Malla has

314
00:14:10,700 --> 00:14:13,800
way deeper knowledge on Java. 
What's coming new in Java? 

315
00:14:14,000 --> 00:14:16,200
Can learn a lot there. 
She's a book or so, which I've 

316
00:14:16,200 --> 00:14:19,000
never done before so I can learn
a lot about writing from her. 

317
00:14:19,000 --> 00:14:21,300
Helen has done a lot of Industry
writing. 

318
00:14:21,300 --> 00:14:24,100
So she writes very effectively 
and very quickly, she 

319
00:14:24,100 --> 00:14:27,300
understands how to identify the 
user and how to speak to that 

320
00:14:27,300 --> 00:14:29,500
user, which is a skill that we 
can all learn. 

321
00:14:29,500 --> 00:14:32,600
From my goal for the team is 
first all level each other up 

322
00:14:32,600 --> 00:14:34,600
and figure out what our 
strengths are, figure out, what 

323
00:14:34,600 --> 00:14:36,400
our weaknesses are some 
weaknesses. 

324
00:14:36,400 --> 00:14:38,800
It's like, well, let's not do 
anything which touches the weak 

325
00:14:38,800 --> 00:14:41,000
area and some weaknesses. 
Are, this is something I'd like 

326
00:14:41,000 --> 00:14:43,400
to strengthen. 
So just identify those kinds of 

327
00:14:43,400 --> 00:14:45,800
things. 
And Puss grow, so I can totally 

328
00:14:45,800 --> 00:14:48,900
understand your journey because 
a lot of aspiring software. 

329
00:14:48,900 --> 00:14:51,800
Engineers also would want to be 
a leaders at some point in time.

330
00:14:51,900 --> 00:14:53,600
But I think the biggest 
challenge, like what you 

331
00:14:53,600 --> 00:14:56,700
mentioned is switching from an 
individual contributor mindset, 

332
00:14:56,700 --> 00:14:59,600
where you be responsible of what
you delivering and also the 

333
00:14:59,600 --> 00:15:02,300
quality and all that, you want 
to do the best, but once you 

334
00:15:02,300 --> 00:15:04,900
step up to become a lead, that's
which sometimes, it's not 

335
00:15:04,900 --> 00:15:06,200
natural. 
For many people. 

336
00:15:06,200 --> 00:15:09,000
Do you have some tips for them? 
I think the longer you've been 

337
00:15:09,000 --> 00:15:11,700
an individual contributor, the 
more difficult it is to let go 

338
00:15:11,700 --> 00:15:14,700
of that because you've been 
doing it for so long. 20 years 

339
00:15:14,700 --> 00:15:17,700
of individual contributor, and 
you are usually very good at 

340
00:15:17,700 --> 00:15:19,900
what you do and faster at what 
you do. 

341
00:15:19,900 --> 00:15:23,700
And so used to doing that often 
when the team is given a task. 

342
00:15:23,700 --> 00:15:25,000
You like. 
Well, I could do that and I'll 

343
00:15:25,000 --> 00:15:27,300
just get it done. 
You have to think very hard 

344
00:15:27,300 --> 00:15:30,000
about is that the right thing to
do because by that point, 

345
00:15:30,000 --> 00:15:33,700
probably got 10 tasks that you 
could do in a day and your team 

346
00:15:33,700 --> 00:15:36,700
has a one task each which might 
take them for days. 

347
00:15:36,700 --> 00:15:39,600
But if they don't learn those 
things, you're always going to 

348
00:15:39,600 --> 00:15:42,500
have 10 tasks that you have to 
do and they're always going to 

349
00:15:42,500 --> 00:15:45,000
be underutilized one. 
The things that I've been trying

350
00:15:45,000 --> 00:15:48,200
to do is your team is not going 
to do that task the same way 

351
00:15:48,200 --> 00:15:50,300
that you would do it. 
And that's the first and most 

352
00:15:50,300 --> 00:15:52,800
important thing to learn. 
For example, when mallow first 

353
00:15:52,800 --> 00:15:55,800
came on board and she's writing 
about topics that I often write 

354
00:15:55,800 --> 00:15:58,300
about, like what's new in Java. 
She does it in a different way 

355
00:15:58,300 --> 00:16:00,600
to me. 
My initial instinct is will 

356
00:16:00,600 --> 00:16:02,000
change this. 
Do that. 

357
00:16:02,000 --> 00:16:04,400
Shorten. 
This I want to turn her into me.

358
00:16:04,400 --> 00:16:07,100
I want her to do it in my style 
and you really have to resist 

359
00:16:07,100 --> 00:16:08,900
that. 
You have to sit back and think 

360
00:16:08,900 --> 00:16:10,700
this isn't a piece that you 
could have written. 

361
00:16:10,800 --> 00:16:13,100
This is a piece for the users. 
Does this? 

362
00:16:13,100 --> 00:16:16,400
Give the Is some value her style
is different. 

363
00:16:16,400 --> 00:16:20,000
My stuff is for the developer 
who is senior ish has stuff they

364
00:16:20,000 --> 00:16:23,300
need to do and they need to do 
it now and they just really need

365
00:16:23,300 --> 00:16:26,100
to know only what they need to 
know to fix their problem. 

366
00:16:26,100 --> 00:16:29,600
My stuff is generally, a short 
Snappy in your face, and it 

367
00:16:29,600 --> 00:16:31,800
shortcuts a lot of the 
background because it's all 

368
00:16:31,808 --> 00:16:33,900
about the Delta between where 
you are, and where you want to 

369
00:16:33,908 --> 00:16:36,200
be malice stuff is much more in 
depth. 

370
00:16:36,200 --> 00:16:39,600
So my instinct is to say all of 
that down, but actually, malice 

371
00:16:39,600 --> 00:16:41,400
audience is a slightly different
audience. 

372
00:16:41,400 --> 00:16:43,800
She goes more in-depth. 
She goes into stuff, which is 

373
00:16:43,900 --> 00:16:45,900
quite interesting. 
I don't need it for my day job, 

374
00:16:45,900 --> 00:16:48,500
but it's interesting and I might
need it at some point. 

375
00:16:48,500 --> 00:16:50,400
I read her stuff. 
Okay, I wouldn't have done it 

376
00:16:50,400 --> 00:16:51,800
this way. 
Does it add value? 

377
00:16:51,900 --> 00:16:54,300
Is there an audience for it? 
And then when you start to see 

378
00:16:54,300 --> 00:16:57,000
actually her audience is a 
slightly different audience in 

379
00:16:57,000 --> 00:16:59,900
my audience, you realize that 
your skills are complementary. 

380
00:16:59,900 --> 00:17:03,600
I can still carry on doing my 
thing in my way to my audience, 

381
00:17:03,600 --> 00:17:06,700
and she does her thing in her 
way to a slightly different 

382
00:17:06,700 --> 00:17:09,200
audience and we reach more 
people, but you do need to step 

383
00:17:09,200 --> 00:17:10,599
back. 
It's not your piece. 

384
00:17:10,599 --> 00:17:13,800
It's not to be done your way is 
to be done the team's way. 

385
00:17:13,900 --> 00:17:16,300
Average, the team's ability in 
an engineering team. 

386
00:17:16,300 --> 00:17:18,500
If they've used a different 
design pattern, but it still 

387
00:17:18,500 --> 00:17:21,300
works and it's a recognizable 
design pattern, go with that. 

388
00:17:21,300 --> 00:17:23,900
That's absolutely fine. 
They don't have to do it the way

389
00:17:23,900 --> 00:17:26,400
that you would have done it if 
the rest of the team understands

390
00:17:26,400 --> 00:17:29,600
it that is good enough. 
That's really great tips there. 

391
00:17:29,600 --> 00:17:32,300
So I hope all the listeners who 
are switching to a lead role. 

392
00:17:32,300 --> 00:17:35,700
Could also switch your mindset 
in terms of you don't have to be

393
00:17:35,700 --> 00:17:38,800
the one who takes all 
responsibility or for everyone 

394
00:17:38,800 --> 00:17:41,400
to do your own way. 
Sometimes stepping back and also

395
00:17:41,400 --> 00:17:44,000
allowing the team to explore, 
what they are good at is so 

396
00:17:44,000 --> 00:17:47,100
something that is great 
switching now to the Java world.

397
00:17:47,100 --> 00:17:50,100
So you've been doing Java for 
how many years now if you can't 

398
00:17:50,100 --> 00:17:53,400
University 25 and I just read as
well, another block from 

399
00:17:53,400 --> 00:17:55,700
jetbrains. 
It seems this year is the 25th 

400
00:17:55,700 --> 00:17:58,400
year of java. 
You have been there seen a lot 

401
00:17:58,400 --> 00:18:01,600
of things but recently I noticed
that a lot of languages. 

402
00:18:01,600 --> 00:18:04,400
Also the popping up taking some 
of the market share of java 

403
00:18:04,400 --> 00:18:06,100
world. 
So the first question is Java, 

404
00:18:06,100 --> 00:18:08,500
losing popularity after such a 
long while. 

405
00:18:08,900 --> 00:18:11,700
I think Java was losing 
popularity, probably before Java

406
00:18:11,700 --> 00:18:15,400
8, when there was such a big 
weight between 6 in Java 7 with 

407
00:18:15,400 --> 00:18:18,900
the Oracle acquisition and took 
a long time to get 7 out of the 

408
00:18:18,900 --> 00:18:21,500
door and then seven was out of 
the door and it was nice. 

409
00:18:21,500 --> 00:18:23,600
It has some nice features but 
there was nothing groundbreaking

410
00:18:23,600 --> 00:18:25,900
about it. 
So really there's a big gap 

411
00:18:25,900 --> 00:18:28,600
between six and eight. 
I think it was about seven years

412
00:18:28,600 --> 00:18:32,500
or something at that time the 
relevance of java started to 

413
00:18:32,500 --> 00:18:34,800
fade a little bit. 
We had a lot of jvm languages 

414
00:18:34,800 --> 00:18:37,900
specifically that were growing 
in popularity with Scala and 

415
00:18:37,900 --> 00:18:41,400
groovy jruby Jonathan on all on 
the jvm. 

416
00:18:41,400 --> 00:18:43,800
They were adding different types
of features and different types 

417
00:18:43,800 --> 00:18:47,000
of Of programming paradigms like
Scala embracing functional style

418
00:18:47,000 --> 00:18:48,900
programming. 
I think back then there was a 

419
00:18:48,900 --> 00:18:51,400
bit of a concern around Java the
language. 

420
00:18:51,400 --> 00:18:54,000
Even then people realize the jvm
platform is important. 

421
00:18:54,000 --> 00:18:56,000
It's got automatic garbage 
collection runtime 

422
00:18:56,000 --> 00:18:58,200
optimizations. 
It allows you to write the 

423
00:18:58,200 --> 00:19:00,800
Syntax for a language without 
worrying about the underlying 

424
00:19:00,800 --> 00:19:02,400
platform. 
And of course, it's write once 

425
00:19:02,400 --> 00:19:04,900
run anywhere as well. 
So the jvm I don't think was 

426
00:19:04,900 --> 00:19:07,400
ever in any danger. 
But since Java 8 when we got 

427
00:19:07,400 --> 00:19:10,200
lambdas and streams that took 
Java the language, a big step 

428
00:19:10,200 --> 00:19:12,600
forward in terms of embracing 
some modern styles of 

429
00:19:12,600 --> 00:19:15,100
programming, Java. 
One was a big release. 

430
00:19:15,100 --> 00:19:17,800
That was a lot of concern around
Java 9 because of Jigsaw or 

431
00:19:17,800 --> 00:19:19,900
backwards. 
Compatibility is important to 

432
00:19:19,900 --> 00:19:22,700
consider those things because 
backwards compatibility is a key

433
00:19:22,700 --> 00:19:25,200
part of the Java story, but I 
think once some of the 

434
00:19:25,208 --> 00:19:27,700
concessions that were made by 
the language developers, plus 

435
00:19:27,700 --> 00:19:30,200
the libraries and Frameworks 
doing the updates that were 

436
00:19:30,208 --> 00:19:32,000
needed. 
I think that actually, for 

437
00:19:32,000 --> 00:19:35,100
application developers, that's 
not as big as scary as step as 

438
00:19:35,100 --> 00:19:37,000
people thought it would be since
Java 9. 

439
00:19:37,000 --> 00:19:40,100
We've had a release, every six 
months, Java 15 just came out. 

440
00:19:40,200 --> 00:19:43,700
And for anyone who's new to Java
or who was using Java way. 

441
00:19:43,800 --> 00:19:46,300
Way back when they're going to 
be like wait, 15. 

442
00:19:46,300 --> 00:19:48,500
What happened? 
Most developers are still on 

443
00:19:48,500 --> 00:19:50,300
Java 8 because that was the 
nice. 

444
00:19:50,300 --> 00:19:52,900
Last big release. 
But the reality is Ron 15. 

445
00:19:52,900 --> 00:19:55,800
Now with the six monthly release
Cadence is really interesting 

446
00:19:55,800 --> 00:19:58,600
because we get predictable 
releases every six months, 

447
00:19:58,600 --> 00:20:01,300
regardless of how many features 
are in them regardless of how 

448
00:20:01,300 --> 00:20:04,500
big the release is even Oracle, 
was a bit concerned that maybe 

449
00:20:04,500 --> 00:20:07,000
we might end up doing a release 
which actually has nothing for 

450
00:20:07,000 --> 00:20:09,600
the developers in or maybe 
nothing at all in it. 

451
00:20:09,600 --> 00:20:12,400
But the reality is that by 
moving to six, monthly release 

452
00:20:12,400 --> 00:20:14,800
Cadence, it means that we've 
Predictable releases. 

453
00:20:14,800 --> 00:20:17,800
But Oracle also said that they 
found that because there's no 

454
00:20:17,800 --> 00:20:21,100
big bang release because there's
no Crunch at the end because 

455
00:20:21,100 --> 00:20:23,200
it's predictable because it's 
all about flow. 

456
00:20:23,200 --> 00:20:24,600
Our work on the next thing and 
the next thing. 

457
00:20:24,600 --> 00:20:27,100
And my featured might not make 
it in this release, but it will 

458
00:20:27,100 --> 00:20:28,600
definitely make it into the next
release. 

459
00:20:28,700 --> 00:20:31,000
Then it turns out that actually.
There's quite a few features 

460
00:20:31,000 --> 00:20:33,800
that go into each release. 
And each release has had some 

461
00:20:33,900 --> 00:20:37,100
interesting language features to
the six monthly release Cadence 

462
00:20:37,100 --> 00:20:40,100
allows the language developers 
to put features in which our 

463
00:20:40,100 --> 00:20:42,600
preview features so they can say
look, it's functionally, 

464
00:20:42,600 --> 00:20:46,800
correct, but We don't recommend 
using in production because it 

465
00:20:46,800 --> 00:20:49,300
will probably change. 
But what we want you to do is we

466
00:20:49,300 --> 00:20:52,700
want you to try this feature out
now and then we will change it 

467
00:20:52,700 --> 00:20:55,900
if necessary, which is a much 
better way of getting feedback 

468
00:20:55,900 --> 00:20:57,900
and allowing developers to 
influence. 

469
00:20:57,900 --> 00:21:01,200
How the language evolves to Java
15, for example, has preview 

470
00:21:01,200 --> 00:21:04,300
features for records, which is 
really in small data classes. 

471
00:21:04,300 --> 00:21:06,800
It's got preview features for 
pattern matching for instance, 

472
00:21:06,800 --> 00:21:09,800
which is quite a small feature 
but pattern matching leads to a 

473
00:21:09,800 --> 00:21:13,200
lot of interesting new reduction
in boilerplate features that we 

474
00:21:13,200 --> 00:21:15,500
can have enjoy. 
In the future, we have text 

475
00:21:15,500 --> 00:21:18,400
blocks as a standard feature, 
which was a preview feature. 

476
00:21:18,400 --> 00:21:21,100
So, text box allows you to embed
things like long strings of 

477
00:21:21,100 --> 00:21:23,500
sequel, or Json, or something 
like that, without having to 

478
00:21:23,508 --> 00:21:25,400
escape every single quote, or 
whatever. 

479
00:21:25,500 --> 00:21:29,000
These are things, which can be 
more gradually introduced and 

480
00:21:29,000 --> 00:21:31,200
experimented and iterated over 
text blocks. 

481
00:21:31,200 --> 00:21:32,900
Took quite a few iterations to 
get, right. 

482
00:21:32,900 --> 00:21:36,000
They could have put multi-line 
strings in Java 12 and just 

483
00:21:36,000 --> 00:21:37,500
gone, that's it. 
That's what you've got. 

484
00:21:37,500 --> 00:21:40,100
And then we'd be like, 
struggling with this, not great,

485
00:21:40,100 --> 00:21:42,500
implementation of multi-line 
strings, but actually what they 

486
00:21:42,500 --> 00:21:44,700
did is they looked at it and 
went Real developers, give a 

487
00:21:44,700 --> 00:21:47,000
bunch of feedback on how 
multi-line strings are working 

488
00:21:47,000 --> 00:21:49,800
and language developers went. 
This is not providing the end 

489
00:21:49,800 --> 00:21:52,600
goal that we wanted to provide. 
So they took all of that out and

490
00:21:52,600 --> 00:21:54,900
started with text blocks. 
Text blocks is a really nice 

491
00:21:54,900 --> 00:21:56,900
feature. 
It works nicely for exactly what

492
00:21:56,900 --> 00:21:58,600
we wanted to embed other 
languages. 

493
00:21:58,600 --> 00:22:01,400
For example, in our Java code, 
there definitely was a concern 

494
00:22:01,400 --> 00:22:05,000
about the relevancy of java, but
with the move to six monthly, 

495
00:22:05,000 --> 00:22:08,700
releases with the introduction 
of preview features, we're able 

496
00:22:08,700 --> 00:22:11,400
to see the evolution of the 
language and the language is 

497
00:22:11,400 --> 00:22:14,600
evolving faster and we the 
Developers To influence the 

498
00:22:14,600 --> 00:22:16,900
evolution of that language. 
So, especially if we've been 

499
00:22:16,900 --> 00:22:19,100
working with other languages, 
whether there are other jvm 

500
00:22:19,100 --> 00:22:22,800
languages, like kotlin or real 
other languages like python or 

501
00:22:22,800 --> 00:22:25,800
JavaScript or whatever, then we 
can say we have a thing in this 

502
00:22:25,800 --> 00:22:28,100
other language that we really 
like like data classes in 

503
00:22:28,100 --> 00:22:29,900
kotlin. 
Now, we've got records in Java, 

504
00:22:29,900 --> 00:22:32,600
for example, the I think the 
release cycle the preview 

505
00:22:32,600 --> 00:22:35,600
features and the fact that a lot
of developers are polyglot 

506
00:22:35,600 --> 00:22:38,000
programmers and they get to 
bring their ideas into their 

507
00:22:38,000 --> 00:22:39,800
preferred. 
Language has really helped to 

508
00:22:39,800 --> 00:22:42,300
energize Java. 
So I firmly believe that job is 

509
00:22:42,300 --> 00:22:44,900
not going to go anywhere. 
Or anytime soon. 

510
00:22:44,900 --> 00:22:46,500
It's only going to continue in 
popularity. 

511
00:22:46,500 --> 00:22:48,400
I think. 
So even personally myself. 

512
00:22:48,400 --> 00:22:50,400
I haven't been following a lot 
since Java 8. 

513
00:22:50,400 --> 00:22:53,000
I must be honest as well. 
Now, it seems like 15. 

514
00:22:53,000 --> 00:22:55,700
There's a lot of things, but if 
you look back to the time, 

515
00:22:55,700 --> 00:22:58,200
actually, it's not that big 
because seven releases. 

516
00:22:58,200 --> 00:23:00,200
That means probably around 34 
years. 

517
00:23:00,200 --> 00:23:03,000
So it seems like we have this 
kind of common misconception 

518
00:23:03,000 --> 00:23:04,600
about Java. 
Now, that things are moving 

519
00:23:04,600 --> 00:23:06,200
rapidly. 
But also there are a lot of 

520
00:23:06,200 --> 00:23:09,200
other languages coming in, new 
setup, Paradigm, new set of 

521
00:23:09,200 --> 00:23:12,100
features. 
For example, Russ go and kotlin 

522
00:23:12,100 --> 00:23:13,700
are some of the most prominent 
language. 

523
00:23:13,800 --> 00:23:16,600
This day, what are your thoughts
about all these new programming?

524
00:23:16,600 --> 00:23:19,600
Paradigms coming out. 
Small, caveat this with, I've 

525
00:23:19,600 --> 00:23:21,700
been programming Java since 
1997. 

526
00:23:21,700 --> 00:23:24,000
I have used other languages. 
I've used JavaScript. 

527
00:23:24,000 --> 00:23:26,500
I originally programmed in basic
way back in the day. 

528
00:23:26,600 --> 00:23:28,400
I've done a little bit of C 
sharp. 

529
00:23:28,400 --> 00:23:30,000
I think I've even done Pearl and
stuff. 

530
00:23:30,000 --> 00:23:32,600
But again, like a lot of 
developers, if I needed to fix a

531
00:23:32,600 --> 00:23:36,100
thing I was doing, I do a little
bit of a programming in that 

532
00:23:36,100 --> 00:23:38,700
language. 
My main language is Java, so I 

533
00:23:38,700 --> 00:23:41,400
know it inside out, so I'm 
always going to be biased as an 

534
00:23:41,400 --> 00:23:43,600
I don't want to invest 20 years 
in another language. 

535
00:23:43,700 --> 00:23:46,300
Which jetbrains creative kotlin.
So obviously I have a bit more 

536
00:23:46,300 --> 00:23:48,600
insight into kotlin than other 
languages. 

537
00:23:48,600 --> 00:23:50,400
There's a lot of things I like 
about kotlin. 

538
00:23:50,400 --> 00:23:53,800
Particularly the goal of kotlin 
from jetbrains, was always to 

539
00:23:53,800 --> 00:23:57,200
create a productive language for
Java developers. 

540
00:23:57,200 --> 00:23:59,800
It's not like Scala which you 
need to understand a bit more 

541
00:23:59,800 --> 00:24:02,200
about how things work in a real 
functional way. 

542
00:24:02,300 --> 00:24:04,700
Cochran is going to assume 
you're a Java programmer and 

543
00:24:04,700 --> 00:24:08,200
that you just want something 
with a bit less crap around the 

544
00:24:08,200 --> 00:24:10,400
boilerplate. 
I also like the fact that kotlin

545
00:24:10,400 --> 00:24:13,100
is primarily on the jvm. 
Although you can run it on other

546
00:24:13,100 --> 00:24:15,000
platforms. 
Because you get all the benefits

547
00:24:15,000 --> 00:24:16,900
of the jvm as well. 
You get all your runtime 

548
00:24:16,900 --> 00:24:18,700
optimizations garbage collection
and stuff. 

549
00:24:18,700 --> 00:24:21,200
A lot of the good ideas in 
Cotton are now available in 

550
00:24:21,200 --> 00:24:23,900
Java. 
So we have records, we have VAR 

551
00:24:23,900 --> 00:24:26,500
we can use VAR instead of having
to declare the whole thing 

552
00:24:26,500 --> 00:24:29,000
cotton was quite popular in 
Android when Android was stuck 

553
00:24:29,000 --> 00:24:31,500
on, Java, 6, because kotlin 
allows you to use Lambda 

554
00:24:31,500 --> 00:24:33,500
Expressions, but Colin gets to 
move forward, and we got 

555
00:24:33,500 --> 00:24:35,500
co-routines as well. 
Column has some interesting 

556
00:24:35,500 --> 00:24:37,600
stuff for multi-threaded 
programming, but we're getting 

557
00:24:37,600 --> 00:24:40,700
it preview feature of lumen Java
16, Loom will be lightweight 

558
00:24:40,700 --> 00:24:43,000
threads on the jvm. 
So that's really interesting. 

559
00:24:43,200 --> 00:24:46,400
One of My viewpoints for this is
that it's great to have all 

560
00:24:46,400 --> 00:24:48,700
these different languages 
because my favorite language 

561
00:24:48,700 --> 00:24:51,600
Java gets to pick and choose the
cool stuff and see what works 

562
00:24:51,600 --> 00:24:53,900
for Java programmers. 
See what works from a backwards 

563
00:24:53,900 --> 00:24:57,000
compatibility point of view and 
just really cherry pick the nice

564
00:24:57,000 --> 00:24:59,100
stuff. 
And with the now releasing every

565
00:24:59,100 --> 00:25:02,500
six months, do that in a 
incrementally faster way, but I 

566
00:25:02,508 --> 00:25:05,800
have to wait, three years for a 
Big Blob of language features 

567
00:25:05,800 --> 00:25:07,500
that was relevant two and a half
years ago. 

568
00:25:07,700 --> 00:25:10,100
I'm definitely on board with 
other jvm languages because you 

569
00:25:10,100 --> 00:25:12,900
get to leverage all the cool 
stuff about the jvm platform. 

570
00:25:12,900 --> 00:25:15,700
I don't know that much. 
A trust, I do not bit about go. 

571
00:25:15,800 --> 00:25:18,100
When I worked at mongodb. 
They were very big on go. 

572
00:25:18,100 --> 00:25:21,100
They like to go because it was 
one of those languages you could

573
00:25:21,100 --> 00:25:23,800
just get stuff done with a 
similar reason that a lot people

574
00:25:23,800 --> 00:25:26,600
like continent because there's 
less boilerplate and you can 

575
00:25:26,600 --> 00:25:28,900
write stuff that works the way 
that you want it to work. 

576
00:25:29,000 --> 00:25:32,500
Go seems great. 
But at some point, I feel that 

577
00:25:32,500 --> 00:25:34,300
they're going to wake up and go,
you know, what? 

578
00:25:34,300 --> 00:25:37,100
We do need different types of 
garbage collectors because there

579
00:25:37,100 --> 00:25:39,800
are different profiles for 
different types of applications.

580
00:25:39,900 --> 00:25:42,900
So, I often think that from the 
bottom up languages will end up 

581
00:25:42,900 --> 00:25:45,300
rediscovering. 
I'm stuff that Java has already 

582
00:25:45,300 --> 00:25:47,900
put into 25 years of 
development. 

583
00:25:47,900 --> 00:25:50,100
Java has been incrementally 
improving their garbage 

584
00:25:50,100 --> 00:25:52,000
collector. 
Everyone always has a go at Java

585
00:25:52,000 --> 00:25:55,600
because garbage collection and 
Java is slow and none of that is

586
00:25:55,600 --> 00:25:58,200
really true anymore. 
And the fact is the way they've 

587
00:25:58,200 --> 00:26:00,200
built a platform. 
There are now multiple different

588
00:26:00,200 --> 00:26:03,000
types of garbage collectors. 
So you plug in the one that you 

589
00:26:03,000 --> 00:26:04,800
want. 
That works for your application.

590
00:26:04,800 --> 00:26:07,700
So you can configure your 
language to do what you want it 

591
00:26:07,700 --> 00:26:09,600
to do. 
I feel like some of the newer 

592
00:26:09,600 --> 00:26:12,000
languages they will wake up to 
the fact that they're going to 

593
00:26:12,008 --> 00:26:13,600
need things like different types
of garbage. 

594
00:26:13,800 --> 00:26:16,500
Actors, they're going to need 
things that run on different 

595
00:26:16,500 --> 00:26:18,100
platforms. 
I know that we're all in the 

596
00:26:18,100 --> 00:26:20,300
cloud now, maybe we don't care 
about our Hardware. 

597
00:26:20,300 --> 00:26:22,500
But ultimately Java is an 
interesting language for the 

598
00:26:22,500 --> 00:26:24,500
cloud because you don't care 
about the hardware. 

599
00:26:24,600 --> 00:26:27,200
You just run it on anything 
wherever you want to run it and 

600
00:26:27,200 --> 00:26:29,100
it would just work. 
I think the space for lots of 

601
00:26:29,100 --> 00:26:31,500
different types of languages 
JavaScript for example, is never

602
00:26:31,500 --> 00:26:33,400
going to die. 
JavaScript is here to stay. 

603
00:26:33,400 --> 00:26:35,800
Whether you like it or not. 
JavaScript has a really nice 

604
00:26:35,800 --> 00:26:37,800
place to obviously it lives in 
the web. 

605
00:26:37,900 --> 00:26:40,700
It's great for scripting. 
It's good for beginners, even 

606
00:26:40,700 --> 00:26:43,600
though I'm personally not a fan 
of dynamic languages are used. 

607
00:26:43,700 --> 00:26:45,600
To do a lot of JavaScript 
development because I used to be

608
00:26:45,600 --> 00:26:47,500
a web developer. 
What I hated about JavaScript 

609
00:26:47,500 --> 00:26:49,900
versus Java is. 
Can't the compiler tell me 

610
00:26:49,900 --> 00:26:52,700
what's wrong with this thing. 
Instead of it not just freaking 

611
00:26:52,700 --> 00:26:55,400
working but a lot of people like
to start with Dynamic languages 

612
00:26:55,400 --> 00:26:57,800
because you just write it and 
you don't get error. 

613
00:26:57,900 --> 00:27:00,100
The other thing I was going to 
say, is this whole world is just

614
00:27:00,100 --> 00:27:02,600
getting more and more 
programmed, more and more 

615
00:27:02,600 --> 00:27:05,300
computers, more, and more 
automated, there is definitely 

616
00:27:05,300 --> 00:27:07,900
space for more than one 
programming language. 

617
00:27:07,900 --> 00:27:11,100
If rust grows in popularity. 
That doesn't mean that Java 

618
00:27:11,100 --> 00:27:13,400
necessarily has to shrink. 
If python is growing because 

619
00:27:13,400 --> 00:27:15,400
it's Right language for machine 
learning. 

620
00:27:15,400 --> 00:27:18,000
That doesn't mean that Java has 
to shrink in the finance world, 

621
00:27:18,000 --> 00:27:20,800
for example, so I think the 
space for everybody to play, you

622
00:27:20,800 --> 00:27:24,100
got a good point there in terms 
of the jvm maturity and more and

623
00:27:24,100 --> 00:27:27,400
more people relying on a, lots 
of libraries that are already 

624
00:27:27,400 --> 00:27:29,800
being written. 
The ecosystem in the Java World.

625
00:27:29,800 --> 00:27:32,100
Also, you have a lot of 
application servers already 

626
00:27:32,100 --> 00:27:34,100
running as well for longest 
years. 

627
00:27:34,200 --> 00:27:37,200
One thing that I would like to a
specially for me and those Java 

628
00:27:37,200 --> 00:27:40,400
Old-Timers out there. 
We are still stuck in Java 8 

629
00:27:40,400 --> 00:27:43,400
mindset and now seems like Java 
15, what do you think are some 

630
00:27:43,400 --> 00:27:45,700
good? 
Suggestions for us to move on 

631
00:27:45,700 --> 00:27:48,800
from java it and continue with 
the Java release Cadence. 

632
00:27:49,100 --> 00:27:51,300
I have a lot of suggestions. 
I do have a whole talk on this 

633
00:27:51,300 --> 00:27:52,900
if you want. 
I can share a link with you and 

634
00:27:52,900 --> 00:27:54,000
you can put it in the podcast 
night. 

635
00:27:54,000 --> 00:27:56,900
So whatever I have a talk called
Beyond Java 8 and this is a 

636
00:27:56,900 --> 00:28:00,600
50-minute talk where I give the 
tldr of what has happened since 

637
00:28:00,600 --> 00:28:03,000
Java 8 and some tips for 
migrating. 

638
00:28:03,100 --> 00:28:05,400
There's an interesting thing 
about how licensing works when 

639
00:28:05,400 --> 00:28:08,700
you're migrating off Java 8. 
You actually have two options. 

640
00:28:08,700 --> 00:28:11,800
You can migrate to jar 11, which
is the next long-term support 

641
00:28:11,800 --> 00:28:15,800
release Oracle has agreed to 
Port 1 release for three years, 

642
00:28:15,800 --> 00:28:18,300
every three years. 
So for Enterprises who don't 

643
00:28:18,300 --> 00:28:21,200
want to upgrade every six months
because honestly, lots of people

644
00:28:21,200 --> 00:28:22,700
don't want to upgrade every six 
months. 

645
00:28:22,700 --> 00:28:24,400
Then you pick the long term 
support release. 

646
00:28:24,400 --> 00:28:26,300
So you want to move from 8 to 
11? 

647
00:28:26,400 --> 00:28:28,100
11 will give you a bunch of nice
features. 

648
00:28:28,100 --> 00:28:30,200
Nothing really groundbreaking 
but it gives you some nice 

649
00:28:30,200 --> 00:28:31,900
stuff. 11, basically, builds off
eight. 

650
00:28:32,000 --> 00:28:34,100
You get some more stream 
operations, you get better 

651
00:28:34,100 --> 00:28:37,700
optional you get unmodifiable 
collections, you get Factory 

652
00:28:37,700 --> 00:28:40,300
methods for collections. 
You getting just really nice 

653
00:28:40,300 --> 00:28:43,800
little helpful language features
you get VAR as well in 11. 911 

654
00:28:44,200 --> 00:28:45,900
from a language. 
Point of view is a nice step 

655
00:28:45,900 --> 00:28:49,400
forward from ate, it should be 
achievable to migrate to 11. 

656
00:28:49,400 --> 00:28:52,900
You do have to go past the bump 
of nine, but it should be fine 

657
00:28:52,900 --> 00:28:55,600
for most people. 
The other alternative is, if you

658
00:28:55,600 --> 00:28:58,000
want to get everything if you're
happy too, I do want to say, 

659
00:28:58,000 --> 00:29:00,600
take risks is not risky. 
But if you want to be upgrading 

660
00:29:00,600 --> 00:29:03,600
every 6 months, then you go to 
15 and then you keep upgrading 

661
00:29:03,600 --> 00:29:06,300
every six months for me. 
What I really would like to see 

662
00:29:06,300 --> 00:29:08,800
organizations and applications 
doing is I really want to see 

663
00:29:08,800 --> 00:29:12,000
them move to 11 now because in 
theory 17 will be the next 

664
00:29:12,000 --> 00:29:15,100
long-term support release. 
Will be coming next September. 

665
00:29:15,200 --> 00:29:18,200
So I would really like to see 
people migrated from 8 to 11. 

666
00:29:18,300 --> 00:29:20,500
Take that jump. 
Make the changes that need to 

667
00:29:20,500 --> 00:29:23,500
happen because I don't want to 
see people jump from 8 to 17. 

668
00:29:23,500 --> 00:29:26,100
I think that will be a big jump 
in the same way that if you were

669
00:29:26,100 --> 00:29:30,300
jumping from java, 1.32 Java 6. 
And there was a very painful I 

670
00:29:30,300 --> 00:29:31,900
don't think you want to jump 
from 8 to 17. 

671
00:29:31,900 --> 00:29:36,800
I think you want to go 8 to 11, 
11 to 17 or 8 to 11, 11 to 15, 

672
00:29:36,800 --> 00:29:39,900
and then keep going up every six
months, 15 sounds intimidating 

673
00:29:39,900 --> 00:29:41,500
because it's like a long way 
away from eight. 

674
00:29:41,500 --> 00:29:43,500
There's a lot of features. 
I don't know if I'm going to 

675
00:29:43,600 --> 00:29:45,700
Able to get the most out of 
these language features because 

676
00:29:45,700 --> 00:29:47,600
it feels like perhaps a lot of 
stuff happened. 

677
00:29:47,600 --> 00:29:51,600
But I would say go to 11, make 
the jump past 9, make sure 

678
00:29:51,600 --> 00:29:53,200
everything works. 
I've tried it with a few 

679
00:29:53,200 --> 00:29:55,100
applications. 
It wasn't too painful. 

680
00:29:55,200 --> 00:29:57,400
Make sure you upgrade your 
Gradle or Maven. 

681
00:29:57,400 --> 00:29:59,400
Make sure you upgrade all your 
dependencies. 

682
00:29:59,400 --> 00:30:02,100
Make sure you address any 
compiler warnings before you do 

683
00:30:02,100 --> 00:30:04,300
the upgrade. 
So, do all of those upgrades 

684
00:30:04,300 --> 00:30:07,700
first then move to 11, and then 
take a look and see if there's 

685
00:30:07,700 --> 00:30:09,800
anything in the more recent 
versions of java that you want. 

686
00:30:09,800 --> 00:30:11,500
But 11 from a language point of 
view. 

687
00:30:11,500 --> 00:30:14,500
There's not that many new 
features which Some teams will 

688
00:30:14,500 --> 00:30:15,800
think. 
Well, I don't really see why I 

689
00:30:15,800 --> 00:30:18,000
should take the pain of going to
11 since I'm not going to get 

690
00:30:18,000 --> 00:30:20,300
that much but I do think it's a 
nice step. 

691
00:30:20,300 --> 00:30:23,600
Make the jump to the get off. 
Eight, take the small language 

692
00:30:23,600 --> 00:30:25,900
features. 
No, 117 comes along, you'll be 

693
00:30:25,900 --> 00:30:27,800
able to use. 
Probably records will be 

694
00:30:27,800 --> 00:30:29,300
probably a standard feature by 
then. 

695
00:30:29,300 --> 00:30:31,100
You'll be able to get records. 
You've got to get text blocks, 

696
00:30:31,100 --> 00:30:32,200
you be able to get pattern 
matching. 

697
00:30:32,200 --> 00:30:35,400
For instance of you, be able to 
get perhaps, maybe Loom, you'll 

698
00:30:35,400 --> 00:30:36,800
be able to get lightweight 
threads. 

699
00:30:36,800 --> 00:30:39,000
So 17 is a really interesting 
release. 

700
00:30:39,000 --> 00:30:43,000
So my advice is jump to 11 and 
then look at moving on to 17, so

701
00:30:43,000 --> 00:30:45,600
it's very Interesting tips. 
Definitely what I can see. 

702
00:30:45,600 --> 00:30:48,500
Also from Enterprise point of 
view, upgrading the platform, 

703
00:30:48,500 --> 00:30:51,800
the jvm and all that. 
Does it entail some kind of race

704
00:30:51,800 --> 00:30:53,900
and backward compatibility and 
things like that, where they 

705
00:30:53,900 --> 00:30:56,700
have to go all over again to 
test the whole applications 

706
00:30:56,700 --> 00:30:58,400
whether it works fine from your 
experience. 

707
00:30:58,400 --> 00:31:00,300
Do you have any? 
Yeah, I've got experience that 

708
00:31:00,300 --> 00:31:02,800
when we move from one point, 
three to six in the bank. 

709
00:31:02,800 --> 00:31:05,600
Basically, at that time. 
We released every three months 

710
00:31:05,600 --> 00:31:08,500
and we had to set aside 
three-month release window for 

711
00:31:08,600 --> 00:31:10,900
no new features. 
In our application. 

712
00:31:11,000 --> 00:31:12,600
Obviously. 
We were also using application 

713
00:31:12,600 --> 00:31:15,000
server like you're saying The 
old world of using Enterprise 

714
00:31:15,000 --> 00:31:17,900
Java and application servers. 
So we had to upgrade our 

715
00:31:17,900 --> 00:31:19,000
version. 
We had to upgrade our 

716
00:31:19,000 --> 00:31:20,800
application server. 
We had to upgrade our 

717
00:31:20,808 --> 00:31:22,700
dependencies. 
Then we have to upgrade our 

718
00:31:22,700 --> 00:31:24,700
version of java. 
Then we had to make sure that 

719
00:31:24,700 --> 00:31:26,900
everything is still working. 
The most painful thing was 

720
00:31:26,900 --> 00:31:29,000
upgrading the application server
looking back. 

721
00:31:29,000 --> 00:31:31,500
Now. 
I think that it was suboptimal 

722
00:31:31,500 --> 00:31:35,200
for them to decide the upgrading
application service was so risky

723
00:31:35,200 --> 00:31:36,800
that they would never do it to 
be honest. 

724
00:31:36,800 --> 00:31:38,700
They should have been upgrading 
their application server, every 

725
00:31:38,700 --> 00:31:41,100
time a new version came out and 
then they wouldn't have to do 

726
00:31:41,100 --> 00:31:43,100
this big jump and I think that's
true of everything. 

727
00:31:43,100 --> 00:31:45,600
What I'm Seeing now, having 
worked with Dave on continuous 

728
00:31:45,600 --> 00:31:50,100
delivery is much less risky to 
continually update, continually 

729
00:31:50,100 --> 00:31:52,100
release to continually do the 
stuff. 

730
00:31:52,100 --> 00:31:55,000
If you do these big chunky 
things, it's just extremely 

731
00:31:55,000 --> 00:31:56,400
painful. 
I had a conversation with 

732
00:31:56,400 --> 00:31:59,300
someone from IBM. 
She works a lot with application

733
00:31:59,300 --> 00:32:01,000
servers. 
Now, in the modern world, she 

734
00:32:01,000 --> 00:32:03,300
has a presentation, which is 
similar to mine about upgrading 

735
00:32:03,300 --> 00:32:05,400
off Java 8. 
And her pain points are all 

736
00:32:05,400 --> 00:32:08,100
around application server 
because a lot of Enterprises are

737
00:32:08,100 --> 00:32:11,100
using application servers and 
this is not a criticism of the 

738
00:32:11,100 --> 00:32:12,900
application server world. 
If you're writing an 

739
00:32:12,900 --> 00:32:15,000
application. 
That you have to wait for the 

740
00:32:15,008 --> 00:32:16,800
new version of java to come out 
before. 

741
00:32:16,800 --> 00:32:20,100
You can start updating your code
AS application server. 

742
00:32:20,200 --> 00:32:23,400
Also, the application servers 
are using using Java ee which is

743
00:32:23,400 --> 00:32:26,600
also behind the SE version of 
java, so there will be a big gap

744
00:32:26,600 --> 00:32:31,800
between Jakarta ee9 is only just
coming out and we're on Java 15 

745
00:32:31,800 --> 00:32:34,800
and the Java ee 9 is only just 
really coming out. 

746
00:32:34,800 --> 00:32:37,700
So yes, there will be a long 
tail and my advice is literally 

747
00:32:37,700 --> 00:32:39,800
just try and keep everything up 
to date. 

748
00:32:39,800 --> 00:32:42,400
As much as you can update your 
application server, update your 

749
00:32:42,400 --> 00:32:45,500
version of Gradle met. 
Ivan update spring because I 

750
00:32:45,500 --> 00:32:48,800
remember when we had to update 
spring with Java 5 generics came

751
00:32:48,800 --> 00:32:50,800
in, it was quite difficult 
because, you know, it's came 

752
00:32:50,800 --> 00:32:53,800
into the language, but are 
Frameworks and libraries, didn't

753
00:32:53,800 --> 00:32:55,900
support generics yet. 
So again, you just have to 

754
00:32:55,900 --> 00:32:58,800
update everything as you go 
along as they become available. 

755
00:32:58,800 --> 00:33:00,500
It's painful. 
But Enterprises don't want to 

756
00:33:00,508 --> 00:33:03,400
take the risk. 
They feel like it takes a lot to

757
00:33:03,400 --> 00:33:05,500
swap in a new dependency. 
They feel like you should have 

758
00:33:05,500 --> 00:33:07,600
to test all of it. 
Of course, especially if you've 

759
00:33:07,600 --> 00:33:10,300
got manual testing and that 
becomes very painful. 

760
00:33:10,400 --> 00:33:13,800
So again continuous Livery, 
continuous integration or My to 

761
00:33:13,800 --> 00:33:16,300
testing automated regression, 
test coverage. 

762
00:33:16,400 --> 00:33:18,900
Everything should be automated 
as much as possible. 

763
00:33:19,000 --> 00:33:21,000
It's really difficult with 
Legacy systems. 

764
00:33:21,100 --> 00:33:22,700
The system is working on at the 
bank. 

765
00:33:22,700 --> 00:33:25,400
I wrote the first unit test 
there and that system was 10 

766
00:33:25,400 --> 00:33:28,900
years old and it took me months 
to write the first unit test 

767
00:33:28,900 --> 00:33:32,300
because I had to put in place a 
framework to test it because it 

768
00:33:32,300 --> 00:33:34,000
wasn't written with testing in 
Mind. 

769
00:33:34,000 --> 00:33:36,700
By the time I left. 
We got 25 percent test coverage,

770
00:33:36,700 --> 00:33:39,600
which was a massive win, but 
it's very difficult to retrofit 

771
00:33:39,600 --> 00:33:40,700
this stuff. 
It's difficult. 

772
00:33:40,700 --> 00:33:43,000
It's challenging. 
Thank you for your story as 

773
00:33:43,000 --> 00:33:44,800
well. 
From Your past experience. 

774
00:33:44,800 --> 00:33:46,600
I think you mentioned continuous
integration, continuous 

775
00:33:46,600 --> 00:33:48,500
delivery. 
All these best practices about 

776
00:33:48,500 --> 00:33:50,300
testing automated testing as 
well. 

777
00:33:50,300 --> 00:33:53,300
That's a good idea for all of us
here, who wants to make the leap

778
00:33:53,300 --> 00:33:56,600
and jump from 8 to 11 to 15. 
Next Trisha. 

779
00:33:56,600 --> 00:33:58,200
I know you also wrote A Few 
books. 

780
00:33:58,200 --> 00:34:01,100
One thing in particular that I 
have interest in is actually 

781
00:34:01,100 --> 00:34:04,500
doing the code review. 
You have a book about how to do 

782
00:34:04,500 --> 00:34:07,400
code review in the best way. 
Can you share with us some of 

783
00:34:07,400 --> 00:34:09,600
the highlights? 
What do you think are the best 

784
00:34:09,600 --> 00:34:12,300
practices for doing cool review?
Because they are so many code 

785
00:34:12,300 --> 00:34:15,199
being written these days and So 
many new developers coming into 

786
00:34:15,199 --> 00:34:16,600
the industry. 
What do you think? 

787
00:34:16,600 --> 00:34:18,600
Are some of the things that you 
can share with all of them? 

788
00:34:18,800 --> 00:34:21,699
So, when I wrote that book, I do
advocacy for IntelliJ IDEA, 

789
00:34:21,699 --> 00:34:24,199
obviously, but jetbrains also 
has a code review tool called up

790
00:34:24,199 --> 00:34:25,699
source. 
And when I started doing 

791
00:34:25,699 --> 00:34:28,400
advocacy for up Source, they 
asked me to write a blog post on

792
00:34:28,400 --> 00:34:30,800
code of you best practice and I 
wrote three thousand words. 

793
00:34:30,800 --> 00:34:32,300
I'm code review. 
Best practices and I was like, 

794
00:34:32,300 --> 00:34:34,500
oh my goodness and that's just 
the highlights. 

795
00:34:34,600 --> 00:34:37,199
Then I wrote a whole series of 
blog posts or what to look for 

796
00:34:37,199 --> 00:34:39,199
in a coat of you. 
So I did that highlight of you 

797
00:34:39,199 --> 00:34:41,400
should care about security, you 
should care about bugs. 

798
00:34:41,400 --> 00:34:43,100
Obviously you should care about 
readability, you should care 

799
00:34:43,107 --> 00:34:46,000
about All these things split 
those out into individual post 

800
00:34:46,000 --> 00:34:48,600
performance and then put them 
together into a lean pump book 

801
00:34:48,600 --> 00:34:50,000
called what to look for in a 
code of you. 

802
00:34:50,000 --> 00:34:52,100
I like that because at this 
Bank, actually, the bank, I was 

803
00:34:52,100 --> 00:34:54,800
just talking about, I was asked 
to review someone else's code 

804
00:34:54,800 --> 00:34:57,000
once and I don't really know 
what I'm looking for. 

805
00:34:57,000 --> 00:34:58,300
It's a bit like the team lead 
thing. 

806
00:34:58,400 --> 00:35:01,700
I can tell this developer to 
write the code, the way that I 

807
00:35:01,700 --> 00:35:04,600
would have written it, but that 
seems a bit stupid because all 

808
00:35:04,600 --> 00:35:06,300
I'm doing is telling him how to 
write the code. 

809
00:35:06,300 --> 00:35:10,200
The wire that I would write it, 
surely if his code works then it

810
00:35:10,200 --> 00:35:12,400
doesn't really matter how he 
wrote it as long as I understand

811
00:35:12,400 --> 00:35:14,600
what it does. 
And It works correctly. 

812
00:35:14,700 --> 00:35:17,700
So I feel like in the industry. 
We don't have a lot of guidance 

813
00:35:17,700 --> 00:35:19,200
on what to look for in a code of
you. 

814
00:35:19,200 --> 00:35:21,800
We don't have a lot of guidance 
on, what is a code review for? 

815
00:35:21,900 --> 00:35:24,400
And we get told a lot, you 
should do code reviews code of 

816
00:35:24,400 --> 00:35:26,700
user a good thing, but we don't 
really get told why or what to 

817
00:35:26,707 --> 00:35:28,300
look for. 
That's why I write that book but

818
00:35:28,300 --> 00:35:30,100
then thinking more and more over
time. 

819
00:35:30,100 --> 00:35:32,200
I've been stung with code 
reviews when people have 

820
00:35:32,200 --> 00:35:34,300
reviewed my code and told me 
it's rubbish and then you get 

821
00:35:34,300 --> 00:35:36,400
really upset about it. 
I've had the same thing from 

822
00:35:36,400 --> 00:35:39,100
bosses who want me to rewrite my
code, the way that they would 

823
00:35:39,100 --> 00:35:42,000
have written it and I'm like, 
look, either, tell me up, front,

824
00:35:42,000 --> 00:35:45,100
the way you want it written. 
So just leave me or write it 

825
00:35:45,100 --> 00:35:47,100
yourself. 
Don't tell me in the code of you

826
00:35:47,100 --> 00:35:49,200
when I've been working on it for
two weeks that I've written it. 

827
00:35:49,200 --> 00:35:51,600
Wrong that the design is wrong 
because it is too late to tell 

828
00:35:51,600 --> 00:35:53,500
me at the end that the design is
wrong. 

829
00:35:53,600 --> 00:35:56,100
You tell me up front, how you 
want to Designed, or you accept 

830
00:35:56,100 --> 00:35:57,900
the fact that I have written 
automated test. 

831
00:35:57,900 --> 00:36:00,200
They prove that it works and it 
is readable. 

832
00:36:00,300 --> 00:36:02,900
So you should just let it go. 
Just tell me the stuff. 

833
00:36:02,900 --> 00:36:05,700
That is a showstopper that led 
me to think a different thing 

834
00:36:05,700 --> 00:36:08,600
which is that code reviews, are 
for different reasons. 

835
00:36:08,600 --> 00:36:10,900
You have to understand the 
reason that you're doing a code 

836
00:36:10,900 --> 00:36:14,200
of you, to figure out what to 
look for in the code of If your 

837
00:36:14,200 --> 00:36:16,900
code view is literally Gateway 
code abuse. 

838
00:36:16,900 --> 00:36:18,600
The thing that happens at the 
end that says, should it go to 

839
00:36:18,600 --> 00:36:21,000
production or not, which is a 
very common form of code of you.

840
00:36:21,100 --> 00:36:23,200
If you're doing that kind of 
code of you, I don't think you 

841
00:36:23,200 --> 00:36:25,100
should be looking at the design.
It's too late. 

842
00:36:25,100 --> 00:36:26,900
It's far too late to look at the
design because all you're going 

843
00:36:26,900 --> 00:36:28,700
to say is redo it all over 
again. 

844
00:36:28,700 --> 00:36:30,300
If you're doing a Gateway code 
of you, you should be looking 

845
00:36:30,300 --> 00:36:30,800
for. 
Is it? 

846
00:36:30,800 --> 00:36:32,700
Correct? 
Are the tests testing the right 

847
00:36:32,700 --> 00:36:35,000
things. 
All things that humans can look 

848
00:36:35,000 --> 00:36:37,900
at anything which is automatable
is your semicolon in the right 

849
00:36:37,900 --> 00:36:40,400
place, who cares? 
Get a linter to do that stuff. 

850
00:36:40,400 --> 00:36:43,100
It's not important for a human 
to be doing that kind of thing 

851
00:36:43,100 --> 00:36:44,500
or two. 
I ate as much as possible. 

852
00:36:44,500 --> 00:36:47,400
The most important thing a human
can do is do the test because 

853
00:36:47,400 --> 00:36:49,800
there should be tests. 
Do the tests test the right 

854
00:36:49,800 --> 00:36:51,500
thing? 
Because a human can read the 

855
00:36:51,500 --> 00:36:53,600
requirements. 
Then they can read the test and 

856
00:36:53,600 --> 00:36:56,000
say is the test actually testing
that the code meets. 

857
00:36:56,000 --> 00:36:58,300
The requirements are as the test
is some rubbish thing, which is 

858
00:36:58,300 --> 00:37:00,600
testing two completely different
for Gateway code of you. 

859
00:37:00,600 --> 00:37:03,100
That's the most important thing 
is the code correct. 

860
00:37:03,100 --> 00:37:04,800
Does it do what it's supposed to
do? 

861
00:37:04,800 --> 00:37:07,800
Is it code that I can live with 
later on, if I have to maintain 

862
00:37:07,800 --> 00:37:10,000
this code, there are different 
types of code reviews as well, 

863
00:37:10,000 --> 00:37:11,500
though. 
I spoke to a bunch of people who

864
00:37:11,500 --> 00:37:13,700
are doing code reviews for 
sharing the knowledge and The 

865
00:37:13,700 --> 00:37:16,300
team when I worked at lmax the 
financial exchange, we would 

866
00:37:16,300 --> 00:37:18,500
impair programming. 
So we didn't have code reviews 

867
00:37:18,500 --> 00:37:19,900
because there's no point in a 
code of you. 

868
00:37:19,900 --> 00:37:22,100
If you're pairing with someone 
because you're telling them what

869
00:37:22,100 --> 00:37:23,800
they're doing. 
There's at least two people who 

870
00:37:23,800 --> 00:37:26,000
know what the code does and then
you just share that we used to 

871
00:37:26,008 --> 00:37:28,300
rotate pairs as well. 
So you just share the knowledge,

872
00:37:28,300 --> 00:37:30,000
amongst the whole team. 
There's a sort of code of you 

873
00:37:30,000 --> 00:37:31,600
where I just wanna be able to 
read the code. 

874
00:37:31,600 --> 00:37:34,100
What happened, what new design 
patterns came in, what changes 

875
00:37:34,100 --> 00:37:36,100
got made and it's fine to 
suggest things. 

876
00:37:36,100 --> 00:37:37,600
Like, I don't really understand 
the name of this. 

877
00:37:37,600 --> 00:37:39,100
I don't understand how this 
works. 

878
00:37:39,100 --> 00:37:41,400
Or could we have an extra test, 
but with those sorts of code of 

879
00:37:41,400 --> 00:37:43,100
use, you're not going to say 
you've done it all wrong. 

880
00:37:43,200 --> 00:37:44,500
The too late. 
It's already there. 

881
00:37:44,500 --> 00:37:45,500
It's out. 
It's in production. 

882
00:37:45,500 --> 00:37:48,600
If you do want the type of code 
of you where it's okay to say 

883
00:37:48,600 --> 00:37:50,400
the design is wrong. 
Then those sorts of code, 

884
00:37:50,400 --> 00:37:52,500
reviews need to happen right at 
the beginning. 

885
00:37:52,500 --> 00:37:54,500
Not when it's finished. 
I'm thinking about how can you 

886
00:37:54,500 --> 00:37:57,000
create a code review process, 
which is a bit like pairing 

887
00:37:57,000 --> 00:37:59,500
because the nice thing about 
code reviews is asynchronous, 

888
00:37:59,500 --> 00:38:01,500
which means that you don't have 
to worry so much about time 

889
00:38:01,500 --> 00:38:03,500
zones of physicality or any of 
that stuff. 

890
00:38:03,500 --> 00:38:05,400
And particularly now are all 
working remotely. 

891
00:38:05,400 --> 00:38:06,700
It's much more important to do 
this. 

892
00:38:06,800 --> 00:38:09,400
So I feel like there's a 
potential for code of use where 

893
00:38:09,400 --> 00:38:12,800
you can sketch out your design 
with some test name. 

894
00:38:12,800 --> 00:38:15,100
So the tests, Tell you what, 
they should be testing, you 

895
00:38:15,100 --> 00:38:18,100
sketch out the classes and the 
methods and their stubs. 

896
00:38:18,100 --> 00:38:21,100
Basically, they don't do very 
much and then someone can come 

897
00:38:21,100 --> 00:38:23,300
in and say, oh, you know what? 
I wouldn't put this class here. 

898
00:38:23,300 --> 00:38:25,900
I feel like this business logic 
belongs somewhere else. 

899
00:38:25,900 --> 00:38:27,200
Oh, I think that what you're 
testing here. 

900
00:38:27,200 --> 00:38:29,000
I don't think that's really what
we're trying to achieve. 

901
00:38:29,000 --> 00:38:30,600
I think we're trying to do 
something different. 

902
00:38:30,600 --> 00:38:33,100
Do you really want to have that 
kind of feedback much earlier, 

903
00:38:33,100 --> 00:38:36,500
on not when someone's invested 
two weeks in creating a piece of

904
00:38:36,500 --> 00:38:39,200
code, which leads to another 
Point code of you should happen.

905
00:38:39,400 --> 00:38:41,900
They shouldn't be huge. 
If you've got 200 classes. 

906
00:38:41,900 --> 00:38:43,300
They either never going to 
review that. 

907
00:38:43,400 --> 00:38:44,500
Or they're just going to say. 
Yeah, sure. 

908
00:38:44,500 --> 00:38:46,000
That's fine. 
They need to be small amounts of

909
00:38:46,000 --> 00:38:47,400
code. 
It needs to be a short amount of

910
00:38:47,400 --> 00:38:50,000
time, because if you've invested
a month in the work, then you 

911
00:38:50,008 --> 00:38:51,300
really don't want to hear it's 
wrong. 

912
00:38:51,300 --> 00:38:53,900
So if you've rested at three 
days in the work and someone 

913
00:38:53,900 --> 00:38:55,700
says, you know what, I think 
perhaps this business logic 

914
00:38:55,700 --> 00:38:58,000
belongs over here, you use your 
automatic refactoring in 

915
00:38:58,000 --> 00:39:00,300
IntelliJ, IDEA, move it around, 
move on. 

916
00:39:00,500 --> 00:39:02,800
I also feel that Korea is like 
an art. 

917
00:39:02,800 --> 00:39:04,900
Sometimes there's no like 
perfect guides. 

918
00:39:04,900 --> 00:39:07,400
Okay, here's how you do code 
review properly and everyone 

919
00:39:07,400 --> 00:39:09,900
just follows it because 
obviously different languages 

920
00:39:09,900 --> 00:39:12,900
different type of applications 
different skill set within the 

921
00:39:12,900 --> 00:39:16,000
team has The experience that 
they have 10 to matter and I 

922
00:39:16,000 --> 00:39:18,400
also see a lot of him lately. 
Now, it becomes their 

923
00:39:18,400 --> 00:39:21,000
responsibility to do the curry 
before everybody. 

924
00:39:21,000 --> 00:39:23,600
Do you think it's a good thing 
to do for team needs to review 

925
00:39:23,600 --> 00:39:25,600
everyone? 
Or do you just want to rely with

926
00:39:25,600 --> 00:39:27,700
the collective mindset? 
My personal opinion? 

927
00:39:27,700 --> 00:39:29,500
It depends on which sort of code
of you doing. 

928
00:39:29,600 --> 00:39:32,500
If you don't a Gateway type 
review, someone has to decide 

929
00:39:32,500 --> 00:39:33,800
whether it's good enough to go 
into production. 

930
00:39:33,800 --> 00:39:36,100
And again, this happens in a lot
of big Banks or other regulated 

931
00:39:36,100 --> 00:39:38,300
environments. 
You do need a senior person. 

932
00:39:38,300 --> 00:39:41,000
You do need a senior architect 
or someone who understands the 

933
00:39:41,000 --> 00:39:42,700
implications of saying. 
Yes or no. 

934
00:39:42,700 --> 00:39:44,400
If they need to be. 
L too have the veto. 

935
00:39:44,400 --> 00:39:47,500
But I don't think that it's the 
responsibility of the team leads

936
00:39:47,500 --> 00:39:50,300
or the senior people to be 
reviewing every single line of 

937
00:39:50,300 --> 00:39:52,000
code. 
I actually think you should 

938
00:39:52,000 --> 00:39:55,200
include at least one Junior in 
all code of use and the reason 

939
00:39:55,200 --> 00:39:58,100
being, if your Junior can't 
understand your code, you did 

940
00:39:58,100 --> 00:40:01,500
not write readable code. 
It's fine for a senior person to

941
00:40:01,500 --> 00:40:03,400
understand your code because 
they know the business logic. 

942
00:40:03,400 --> 00:40:06,000
They know the framework. 
They know the niche things of 

943
00:40:06,000 --> 00:40:07,800
your application. 
They understand it. 

944
00:40:07,900 --> 00:40:10,800
You really want to cater to the 
lowest common denominator. 

945
00:40:10,800 --> 00:40:13,600
You really want your Juniors to 
be able to understand it as Soon

946
00:40:13,600 --> 00:40:15,500
as possible. 
I would have everybody review 

947
00:40:15,500 --> 00:40:17,900
code at some point. 
Definitely, you want to split it

948
00:40:17,900 --> 00:40:19,700
amongst the team. 
But if you're doing a Gateway 

949
00:40:19,700 --> 00:40:23,000
type code of you, I would 
probably have at least a junior 

950
00:40:23,000 --> 00:40:25,400
and a mid-level appear of 
whoever wrote it. 

951
00:40:25,400 --> 00:40:27,300
They do the detailed code 
review. 

952
00:40:27,300 --> 00:40:29,500
In terms of this doesn't seem to
be named very well. 

953
00:40:29,500 --> 00:40:32,000
I don't really understand what 
this is doing or this test 

954
00:40:32,000 --> 00:40:34,700
doesn't seem to match very well 
to what the requirements are. 

955
00:40:34,800 --> 00:40:37,900
And then ultimately, the senior 
person goes through all of those

956
00:40:37,900 --> 00:40:39,700
comments and any of the changes 
that might have happened and 

957
00:40:39,700 --> 00:40:41,400
then ticks that and signs that 
off. 

958
00:40:41,400 --> 00:40:43,300
So it's not up to the senior 
person to do the line. 

959
00:40:43,400 --> 00:40:45,800
By line staff actually, it 
should be down to everybody to 

960
00:40:45,800 --> 00:40:48,200
do the line by line staff. 
It's up to the senior person to 

961
00:40:48,200 --> 00:40:50,100
see did the Junior and mid-level
person. 

962
00:40:50,100 --> 00:40:52,300
Did they catch the sorts of 
things that I would be looking 

963
00:40:52,300 --> 00:40:54,100
for? 
And if so, does it look like 

964
00:40:54,100 --> 00:40:56,000
everything's been addressed the 
way that I would like them. 

965
00:40:56,000 --> 00:40:59,600
So that relieves the burden off 
the senior person and also helps

966
00:40:59,600 --> 00:41:02,200
to spread the responsibility 
amongst the whole team and 

967
00:41:02,300 --> 00:41:04,900
allows you to make sure that 
your code really is 

968
00:41:04,900 --> 00:41:07,000
understandable by the whole team
at the whole team. 

969
00:41:07,000 --> 00:41:10,100
Learns, what changes are going 
into the application apart, from

970
00:41:10,100 --> 00:41:12,400
the Gateway review. 
Are there any other reviews that

971
00:41:12,400 --> 00:41:14,300
you can mention for? 
To learn more. 

972
00:41:14,800 --> 00:41:17,700
It depends a lot on the team and
the application in teams where 

973
00:41:17,700 --> 00:41:20,000
you can trust that everyone's 
doing the right job or perhaps 

974
00:41:20,000 --> 00:41:21,900
that there aren't that many new 
people on there, or there are 

975
00:41:21,900 --> 00:41:24,000
high performing team. 
You just do the code of you for 

976
00:41:24,000 --> 00:41:25,700
learning the pattern with that 
is quite often. 

977
00:41:25,700 --> 00:41:27,100
You'll be submitting your 
commits. 

978
00:41:27,100 --> 00:41:30,400
Maybe even just published in two
main straightaway, your code of 

979
00:41:30,400 --> 00:41:33,400
you might select individual 
commits and put them together in

980
00:41:33,408 --> 00:41:35,500
a single code of you, rather 
than having to look at the whole

981
00:41:35,500 --> 00:41:37,000
of main. 
One of the things with code of 

982
00:41:37,008 --> 00:41:39,600
you, of course, is putting aside
time to do this, the whole team 

983
00:41:39,600 --> 00:41:42,000
every morning. 
Let's say you put aside 30 

984
00:41:42,000 --> 00:41:45,000
minutes to review which Whatever
code reviews have come in from 

985
00:41:45,000 --> 00:41:47,000
the previous day. 
We just literally look over the 

986
00:41:47,000 --> 00:41:49,100
code and just see, do I 
understand it. 

987
00:41:49,107 --> 00:41:51,000
Does it make sense? 
What sort of functionality? 

988
00:41:51,000 --> 00:41:53,600
Just got added to the 
application and this is not a 

989
00:41:53,600 --> 00:41:55,300
burden. 
This is not, oh, I have to 

990
00:41:55,300 --> 00:41:57,100
decide whether this code is good
enough to go or not. 

991
00:41:57,107 --> 00:41:59,000
This is a learning experience 
for you. 

992
00:41:59,000 --> 00:42:03,300
If I have to maintain the new 
orders segment, do I understand 

993
00:42:03,300 --> 00:42:05,600
what the New Order segment looks
like and how it works. 

994
00:42:05,600 --> 00:42:08,600
So, it's really for you to 
understand what's going on in 

995
00:42:08,600 --> 00:42:11,000
the application. 
So you keep mentioning a lot of 

996
00:42:11,008 --> 00:42:14,000
times about reading the code, 
making sure that Understand what

997
00:42:14,000 --> 00:42:17,000
the code has been written for. 
And you also wrote a blog post 

998
00:42:17,000 --> 00:42:19,000
reading code, is harder than 
writing it. 

999
00:42:19,000 --> 00:42:21,300
So I'm sure that there's a thing
that you want to send message 

1000
00:42:21,300 --> 00:42:24,500
across what other important 
thing for person who writes the 

1001
00:42:24,500 --> 00:42:26,100
code. 
In terms of readability. 

1002
00:42:26,400 --> 00:42:28,900
I did a presentation about 
reading code, is more difficult 

1003
00:42:28,900 --> 00:42:31,200
than writing it because this is 
often code of you stuff. 

1004
00:42:31,200 --> 00:42:33,600
So, I was working with another 
person in jetbrains Maria, and 

1005
00:42:33,600 --> 00:42:35,500
she was saying, look, it's 
really weird when we're doing 

1006
00:42:35,500 --> 00:42:37,000
code reviews. 
One of the things about code 

1007
00:42:37,000 --> 00:42:39,000
reviews is very difficult, to 
read the code. 

1008
00:42:39,000 --> 00:42:41,200
We're not taught how to read 
code when we learn other 

1009
00:42:41,200 --> 00:42:42,700
languages. 
So, Maria's learning French at 

1010
00:42:42,700 --> 00:42:44,600
the moment. 
I'm constantly learning Spanish 

1011
00:42:44,600 --> 00:42:46,700
because I live in Spain, where 
you learn how to read it. 

1012
00:42:46,700 --> 00:42:49,100
You learn how to listen to it. 
You don't necessarily learn how 

1013
00:42:49,100 --> 00:42:51,300
to write, it is. 
Absolutely the last thing that 

1014
00:42:51,300 --> 00:42:53,600
you learn but with programming 
were taught how to write it 

1015
00:42:53,600 --> 00:42:56,300
right from the beginning. 
And we're not really taught how 

1016
00:42:56,300 --> 00:42:59,500
to read it, or we're not taught 
to Value the skill of reading 

1017
00:42:59,500 --> 00:43:02,300
it, if we read code, and we 
don't understand it. 

1018
00:43:02,300 --> 00:43:04,900
We often just say nasty things 
about the person who wrote the 

1019
00:43:04,900 --> 00:43:07,000
code, even if it's us. 
So, it leads into this 

1020
00:43:07,000 --> 00:43:10,400
constantly - critical thing, of 
course, the code you wrote six 

1021
00:43:10,400 --> 00:43:13,200
months ago isn't as good as you 
would right now. 

1022
00:43:13,400 --> 00:43:15,800
Because you've got six months of
learning the language better. 

1023
00:43:15,800 --> 00:43:18,400
The Domaine better things have 
evolved in your applications are

1024
00:43:18,400 --> 00:43:19,700
no that's not the way that you 
would do it. 

1025
00:43:19,700 --> 00:43:21,600
Now. 
Let's accept the fact that 

1026
00:43:21,600 --> 00:43:23,900
things evolve and things change,
and that you would do things 

1027
00:43:23,900 --> 00:43:26,000
differently today than how you 
did them yesterday. 

1028
00:43:26,000 --> 00:43:28,200
That's fine. 
Let's not be critical of this. 

1029
00:43:28,200 --> 00:43:30,900
Let's not accuse the person who 
wrote the code of not writing 

1030
00:43:30,900 --> 00:43:33,100
readable code. 
Let's accept the fact that we 

1031
00:43:33,100 --> 00:43:36,800
need to learn how to read code 
and how to live in the code 

1032
00:43:36,900 --> 00:43:39,500
because most of what we do, even
if we're not doing code reviews,

1033
00:43:39,500 --> 00:43:41,100
most of what we do is reading 
code. 

1034
00:43:41,100 --> 00:43:43,200
When we're trying to find out 
where the bug is. 

1035
00:43:43,300 --> 00:43:45,300
Is or where we're going to add 
the new feature. 

1036
00:43:45,300 --> 00:43:48,000
We spend 90% of the time, 
reading the code figuring out. 

1037
00:43:48,000 --> 00:43:49,500
What's the design pose. 
The problem? 

1038
00:43:49,500 --> 00:43:51,600
What are the tests do? 
It's not that we don't know how 

1039
00:43:51,600 --> 00:43:54,700
to read code because we do read 
code but we don't value it. 

1040
00:43:54,700 --> 00:43:56,800
We sort of see it as a waste of 
time and not writing lines of 

1041
00:43:56,800 --> 00:43:58,000
code. 
I'm not writing stuff. 

1042
00:43:58,000 --> 00:44:00,800
So I'm not productive whenever 
measured on our ability to read 

1043
00:44:00,800 --> 00:44:03,600
code but our ability to read 
Code maps directly to our 

1044
00:44:03,600 --> 00:44:06,500
ability to write good code 
because we know the right place 

1045
00:44:06,500 --> 00:44:09,400
to make the changes. 
We know how to write new code 

1046
00:44:09,400 --> 00:44:12,500
that fits in with the existing 
code by reading our code base. 

1047
00:44:12,500 --> 00:44:14,700
Of course, we're going to Right 
readable code. 

1048
00:44:14,800 --> 00:44:17,500
If I'm reading a book in German 
and I decide this needs a new 

1049
00:44:17,500 --> 00:44:19,800
paragraph here and I write a new
paragraph in English. 

1050
00:44:19,800 --> 00:44:21,700
That's dumb. 
You just wouldn't do that. 

1051
00:44:21,700 --> 00:44:24,000
But in your in applications, we 
quite often go. 

1052
00:44:24,000 --> 00:44:25,600
Well. 
This is really old code and has 

1053
00:44:25,600 --> 00:44:28,300
an old dialect if you like as an
old style of java. 

1054
00:44:28,300 --> 00:44:30,300
I'm just going to add a Lambda 
expression in here because 

1055
00:44:30,300 --> 00:44:33,200
that's a modern way of doing 
stuff, but that's not idiomatic 

1056
00:44:33,200 --> 00:44:35,200
to this application. 
So although your writing 

1057
00:44:35,200 --> 00:44:38,400
readable code in some context. 
It's not readable code in the 

1058
00:44:38,400 --> 00:44:40,500
context of someone who's going 
to have to read this whole 

1059
00:44:40,500 --> 00:44:42,500
application. 
We are talk a lot about writing 

1060
00:44:42,500 --> 00:44:44,000
readable code with. 
I've talked a lot about what 

1061
00:44:44,000 --> 00:44:46,500
that really means and how it 
applies to the rest of the team 

1062
00:44:46,500 --> 00:44:49,500
to that rest of the application 
to the dialect of the code. 

1063
00:44:49,500 --> 00:44:51,800
If you like, because your code, 
bases do have different dialects

1064
00:44:51,800 --> 00:44:53,700
and you don't have to live 
within that and accept it. 

1065
00:44:53,700 --> 00:44:55,200
Not just try and change it all 
the time. 

1066
00:44:55,400 --> 00:44:57,600
Yeah, sometimes I think, for all
of us to take, he's here. 

1067
00:44:57,600 --> 00:45:01,400
We do have this kind of buzz 
words or the up-and-coming shiny

1068
00:45:01,400 --> 00:45:02,800
new features. 
We just, you know what? 

1069
00:45:02,800 --> 00:45:04,800
I'm gonna change the library. 
I'm going to use this new 

1070
00:45:04,800 --> 00:45:06,800
features and we just dump it in 
the code. 

1071
00:45:06,800 --> 00:45:09,700
And yes, we did it. 
So, I think sometimes that's not

1072
00:45:09,700 --> 00:45:11,800
a good practice, as well. 
Like what you said, you have to 

1073
00:45:11,800 --> 00:45:14,900
be also adaptive in terms. 
What was the code written in the

1074
00:45:14,908 --> 00:45:17,100
beginning? 
And just adapt to the style that

1075
00:45:17,100 --> 00:45:19,800
it was listening, rather than 
changing, then confusing. 

1076
00:45:19,800 --> 00:45:22,400
The other people who are reading
the code seeing like a mixed 

1077
00:45:22,400 --> 00:45:26,000
style patterns, Trish, you also 
a developer advocate for gender.

1078
00:45:26,000 --> 00:45:28,200
And so let's talk a little bit 
about jetbrains. 

1079
00:45:28,200 --> 00:45:30,900
I know these days, there are a 
lot of proliferation of text 

1080
00:45:30,900 --> 00:45:33,300
editors or code editors. 
Some are in the cloud. 

1081
00:45:33,300 --> 00:45:35,000
Some are just different 
applications. 

1082
00:45:35,100 --> 00:45:38,200
Why do you think developers 
should use an ID from jetbrains 

1083
00:45:38,300 --> 00:45:39,900
pesos? 
For example, the S code or 

1084
00:45:39,900 --> 00:45:41,500
probably add them or things like
that. 

1085
00:45:41,800 --> 00:45:43,200
Again. 
This is going to be created. 

1086
00:45:43,300 --> 00:45:45,500
With my background as a Java 
programmer, we generally like 

1087
00:45:45,500 --> 00:45:47,100
our ID. 
He's granted Javas. 

1088
00:45:47,100 --> 00:45:49,100
Got a bit of boilerplate. 
So having cogeneration is 

1089
00:45:49,100 --> 00:45:51,900
helpful for as the code 
navigation is helpful. 

1090
00:45:52,000 --> 00:45:54,000
Java is a statically typed 
language. 

1091
00:45:54,000 --> 00:45:56,500
So your ID can give you a lot 
because it can give you a 

1092
00:45:56,500 --> 00:45:58,900
compiler warnings in line. 
You don't have to compile a 

1093
00:45:58,908 --> 00:46:01,400
whole application. 
Static language, is also allow 

1094
00:46:01,400 --> 00:46:04,500
you to do data flow analysis. 
Some of the stuff in IntelliJ. 

1095
00:46:04,500 --> 00:46:07,500
IDEA is so cool because it goes 
this value will never be null. 

1096
00:46:07,500 --> 00:46:08,800
You like really? 
Okay. 

1097
00:46:08,800 --> 00:46:10,400
I trust you. 
I'm sure you've figured that 

1098
00:46:10,400 --> 00:46:12,100
out. 
So I don't have to worry about 

1099
00:46:12,100 --> 00:46:14,700
all the nuts and bolts. 
I just write the business logic.

1100
00:46:14,700 --> 00:46:16,900
When the business tells me. 
I need a button which allows me 

1101
00:46:16,900 --> 00:46:19,300
to place new orders. 
I just have to worry about how 

1102
00:46:19,300 --> 00:46:20,800
the flow goes through the 
system. 

1103
00:46:20,800 --> 00:46:23,900
Instead of worrying about the 
intricacies of checking this or 

1104
00:46:23,900 --> 00:46:25,500
making sure this is the right 
type of whatever. 

1105
00:46:25,600 --> 00:46:27,200
Given my background as a Java 
programmer. 

1106
00:46:27,200 --> 00:46:30,800
When I did see Sharp programming
years ago, I use visual studio 

1107
00:46:30,800 --> 00:46:33,000
and I was like, oh, I don't 
really understand this. 

1108
00:46:33,000 --> 00:46:34,600
Then I found out about 
resharper. 

1109
00:46:34,600 --> 00:46:35,900
So I put re sharper in there. 
Mike. 

1110
00:46:35,900 --> 00:46:38,900
Oh now I can navigate the code 
the way I expect to do it inside

1111
00:46:38,900 --> 00:46:40,700
IntelliJ IDEA. 
I know Visual Studio has come a 

1112
00:46:40,707 --> 00:46:43,200
long way since then but still we
shop is still one of the most 

1113
00:46:43,300 --> 00:46:46,800
Other plugins for that. 
The IDE allows me to have a set 

1114
00:46:46,800 --> 00:46:50,200
of skills to understand my tool 
and that's transferable to other

1115
00:46:50,200 --> 00:46:52,900
languages. 
Now, when I'm writing C sharp, I

1116
00:46:52,908 --> 00:46:55,000
can use resharper to get the 
same sorts of suggestions, 

1117
00:46:55,000 --> 00:46:57,400
especially when I write Java 
style, C sharp, and then it 

1118
00:46:57,408 --> 00:46:58,800
goes, no. 
No, you don't want to do that. 

1119
00:46:58,800 --> 00:47:01,400
And what I do, I quite often 
write JavaScript in angular and 

1120
00:47:01,400 --> 00:47:03,600
stuff like that, and I'm using 
webstorm for that because 

1121
00:47:03,600 --> 00:47:06,300
webstorm allows me to write 
JavaScript the way that I would 

1122
00:47:06,300 --> 00:47:08,700
expect to write Java. 
It gives me code suggestions. 

1123
00:47:08,700 --> 00:47:11,200
It gives me analysis. 
It gives me inspections and 

1124
00:47:11,200 --> 00:47:13,200
warnings, especially from using 
typescript. 

1125
00:47:13,300 --> 00:47:15,600
Camp nou to it says all perhaps 
you want to do it this way. 

1126
00:47:15,600 --> 00:47:18,000
I don't have to go off and 
research that and learn that. 

1127
00:47:18,000 --> 00:47:21,600
I get the learning in line as 
I'm typing it when I need it. 

1128
00:47:21,900 --> 00:47:24,000
That's what I like about. 
The idea is it just gives you 

1129
00:47:24,000 --> 00:47:26,000
the knowledge that you need 
right now, in that particular 

1130
00:47:26,000 --> 00:47:28,600
piece of code that you're 
working on as developers. 

1131
00:47:28,600 --> 00:47:31,000
We can always get code to work. 
Getting working code, is not 

1132
00:47:31,000 --> 00:47:32,500
really the problem. 
Again, it comes down to 

1133
00:47:32,500 --> 00:47:35,300
idiomatic code, especially if 
you're a polyglot program, run, 

1134
00:47:35,300 --> 00:47:36,700
you're going from language to 
language. 

1135
00:47:36,700 --> 00:47:38,700
When I'm writing groovy 
IntelliJ. 

1136
00:47:38,700 --> 00:47:40,900
IDEA will say look, I course it 
will work because Java Works 

1137
00:47:40,900 --> 00:47:42,800
inside groovy, but I wouldn't do
it that way. 

1138
00:47:42,800 --> 00:47:44,600
This is Is a more groovy way of 
doing it. 

1139
00:47:44,600 --> 00:47:47,700
So it really helps you to write 
readable code, idiomatic code. 

1140
00:47:47,700 --> 00:47:50,000
And it will also tell you if 
you're writing stuff, which is 

1141
00:47:50,000 --> 00:47:51,600
inefficient. 
That's just from the code point 

1142
00:47:51,600 --> 00:47:53,200
of view. 
One of the things that I've been

1143
00:47:53,200 --> 00:47:55,600
wanting to work on for ages. 
Haven't got around to yet, is a 

1144
00:47:55,600 --> 00:47:57,700
tutorial for using get inside 
until ago. 

1145
00:47:57,700 --> 00:48:00,000
Dear. 
I know most real developers use 

1146
00:48:00,000 --> 00:48:02,500
get from the command line. 
I am not capable of that because

1147
00:48:02,500 --> 00:48:04,900
I'm a visual person. 
I want to see the little dots. 

1148
00:48:05,000 --> 00:48:07,400
I want to see the branches. 
I want to see the timeline and I

1149
00:48:07,400 --> 00:48:10,100
can work that way in IntelliJ 
IDEA has full integration for 

1150
00:48:10,100 --> 00:48:12,400
git and GitHub. 
So I just do everything inside 

1151
00:48:12,400 --> 00:48:15,400
the IDE and I You my cherry 
picking my merging, my rebasing,

1152
00:48:15,400 --> 00:48:17,700
and it all makes a lot more 
logical sense to me because it's

1153
00:48:17,700 --> 00:48:19,200
all inside. 
The IDE. 

1154
00:48:19,300 --> 00:48:22,600
The IDE is not just about code 
suggestions and code analysis. 

1155
00:48:22,600 --> 00:48:24,900
It's an integrated development 
environment. 

1156
00:48:24,900 --> 00:48:27,700
So I get integration with get if
I'm using application servers. 

1157
00:48:27,700 --> 00:48:30,200
Like we're talking about before 
I get my integrated application 

1158
00:48:30,200 --> 00:48:32,000
server. 
I can debug inside my 

1159
00:48:32,000 --> 00:48:34,400
application server. 
I can even debug remotely, I can

1160
00:48:34,400 --> 00:48:36,900
debug in the cloud. 
If I want to we have plugins for

1161
00:48:36,900 --> 00:48:39,600
like AWS and Azure. 
I haven't used either of them, 

1162
00:48:39,600 --> 00:48:42,700
but we are plugins for deploying
to and debugging in the cloud, 

1163
00:48:42,700 --> 00:48:44,200
which is much. 
More common, these days. 

1164
00:48:44,300 --> 00:48:46,800
Everything is there and it all 
runs integrated. 

1165
00:48:46,800 --> 00:48:49,300
I don't have to talk to a 
terminal or to a different tool 

1166
00:48:49,300 --> 00:48:51,600
to do my get stuff. 
I love the fact that all my 

1167
00:48:51,600 --> 00:48:53,900
database stuff is inside there. 
I want to be able to run a 

1168
00:48:53,908 --> 00:48:57,800
database query inside my IDE. 
I can run the SQL inside my Java

1169
00:48:57,800 --> 00:49:00,700
inside, IntelliJ IDEA by saying 
run this Sequel, and I don't 

1170
00:49:00,700 --> 00:49:02,800
have to mess around with moving 
from tool to Tool. 

1171
00:49:02,800 --> 00:49:05,400
So that's what an integrated 
development environment does. 

1172
00:49:05,500 --> 00:49:07,400
I do see the value of code 
editors. 

1173
00:49:07,400 --> 00:49:10,500
If you want to pop into 
something and make some changes,

1174
00:49:10,500 --> 00:49:12,800
which happens all the time, 
particularly in production, you 

1175
00:49:12,800 --> 00:49:15,400
want to How to quickly open up 
an editor and make those 

1176
00:49:15,400 --> 00:49:17,100
changes. 
And you do want a syntax 

1177
00:49:17,100 --> 00:49:20,000
highlighting and code completion
for those sorts of things too. 

1178
00:49:20,100 --> 00:49:22,500
So you get a lot of benefit from
that kind of tool to. 

1179
00:49:22,500 --> 00:49:25,600
But for me, you can't take my 
IDE from being, you can't rest 

1180
00:49:25,600 --> 00:49:28,200
it from my cold, dead hands. 
Yeah. 

1181
00:49:28,200 --> 00:49:30,000
I can also relate to some of 
your stories. 

1182
00:49:30,000 --> 00:49:33,400
So when I learn how to write in 
Ruby, I also got suggested. 

1183
00:49:33,400 --> 00:49:35,700
Hey, you should not do this. 
There's this Ruby features. 

1184
00:49:35,700 --> 00:49:38,600
Ok, just click shortcuts been, 
my code just gets transformed. 

1185
00:49:38,600 --> 00:49:40,000
I think it's pretty nice. 
One way. 

1186
00:49:40,000 --> 00:49:42,700
Is that the code gets better? 
And also I learned new things 

1187
00:49:42,800 --> 00:49:45,800
like you Said I also used it 
from the ID instead of doing all

1188
00:49:45,800 --> 00:49:47,900
this to get command. 
So I find it quite efficient 

1189
00:49:47,900 --> 00:49:50,700
just by pressing a few key and 
nothing gets done out of the 

1190
00:49:50,700 --> 00:49:52,700
box. 
What are some of the exciting 

1191
00:49:52,700 --> 00:49:55,800
Trends or products or maybe 
Focus areas or Innovations? 

1192
00:49:55,800 --> 00:49:58,700
Coming out from jetbrains, if 
you can share with some of us, 

1193
00:49:58,900 --> 00:50:00,400
it's really interesting working 
for jetbrains. 

1194
00:50:00,400 --> 00:50:03,400
I've been here for six years and
we're constantly evolving and 

1195
00:50:03,400 --> 00:50:06,400
moving forward. 
Given that our main product is 

1196
00:50:06,400 --> 00:50:09,900
IntelliJ IDEA, which is the main
IDE for the Java world. 

1197
00:50:09,900 --> 00:50:12,200
It would be quite tempting to be
like, you know what? 

1198
00:50:12,200 --> 00:50:15,500
We can't have one without On a 
fine, we can carry on being the 

1199
00:50:15,500 --> 00:50:18,900
most popular IDE for Java and 
carry on making money but 

1200
00:50:18,900 --> 00:50:21,400
jetbrains is an organization of 
a thousand engineers. 

1201
00:50:21,400 --> 00:50:22,600
And you know what Engineers are 
like? 

1202
00:50:22,600 --> 00:50:24,500
They're like, well, we could do 
something cool. 

1203
00:50:24,500 --> 00:50:26,800
We could do something different.
We have a new product called 

1204
00:50:26,800 --> 00:50:30,600
space, which is a team tool as 
an integrated environment for 

1205
00:50:30,600 --> 00:50:31,900
team stuff. 
It's got chart. 

1206
00:50:31,900 --> 00:50:34,400
It's got issue tracking. 
It's got continuous integration.

1207
00:50:34,400 --> 00:50:36,600
It's got code review. 
It's all integrated into a 

1208
00:50:36,600 --> 00:50:38,400
single tool. 
We can do things that meeting 

1209
00:50:38,400 --> 00:50:40,400
tracking and it's got location 
people in offices. 

1210
00:50:40,400 --> 00:50:42,700
It's got the whole team, the 
whole organization in their 

1211
00:50:42,700 --> 00:50:44,100
Theory. 
Everything that you want to do 

1212
00:50:44,100 --> 00:50:46,100
with the people in your 
organization, you can do that. 

1213
00:50:46,100 --> 00:50:48,500
I think that's still an EOP at 
the moment but it is available. 

1214
00:50:48,600 --> 00:50:52,900
We have just launched a very 
early EAP of collaborative 

1215
00:50:52,900 --> 00:50:55,000
development. 
I'm really excited about this 

1216
00:50:55,000 --> 00:50:59,100
because this is remote pairing. 
It's not quite remote pairing 

1217
00:50:59,100 --> 00:51:00,200
yet. 
It's not. 

1218
00:51:00,200 --> 00:51:03,100
I have my IDE open. 
You have your IDE open and we 

1219
00:51:03,107 --> 00:51:05,600
code in the same thing. 
But what it is is you have your 

1220
00:51:05,600 --> 00:51:07,700
IDE open. 
You want some help from me or 

1221
00:51:07,700 --> 00:51:08,700
something. 
You want to pair with me on 

1222
00:51:08,700 --> 00:51:10,400
something. 
You send me a link, and that 

1223
00:51:10,400 --> 00:51:12,900
will open a lightweight client 
on my computer. 

1224
00:51:12,900 --> 00:51:15,800
It, Looks like IntelliJ, it acts
like intelligent, but it's not 

1225
00:51:15,800 --> 00:51:17,400
my IDE. 
It is a client. 

1226
00:51:17,500 --> 00:51:20,900
I can then hop in and I can be 
coding inside your IDE. 

1227
00:51:20,900 --> 00:51:23,100
You can see my cursor and I can 
be like, oh, what if we do this?

1228
00:51:23,100 --> 00:51:25,800
What if we do that, we have 
loads of ideas on how to make 

1229
00:51:25,800 --> 00:51:28,200
this better at the moment. 
I've been using it with my team 

1230
00:51:28,300 --> 00:51:31,200
in terms of we usually have 
something like meat open so we 

1231
00:51:31,200 --> 00:51:33,900
can be chatting and then we can 
be coding at the same time. 

1232
00:51:33,900 --> 00:51:35,600
There's some caveats to it at 
the moment. 

1233
00:51:35,600 --> 00:51:37,600
In terms of, if I'm using a 
lightweight client on my 

1234
00:51:37,600 --> 00:51:39,200
machine. 
I shouldn't have access to your 

1235
00:51:39,200 --> 00:51:41,000
terminal to run anything on your
machine. 

1236
00:51:41,100 --> 00:51:43,900
There's obviously security 
caveats and How we do stuff. 

1237
00:51:43,900 --> 00:51:47,000
So that's why we don't have full
access to everything in the IDE.

1238
00:51:47,000 --> 00:51:50,000
But this is very exciting. 
And this is something that is 

1239
00:51:50,000 --> 00:51:51,800
obviously extremely relevant. 
This year. 

1240
00:51:51,800 --> 00:51:54,700
It's also our oldest bug in our 
bug tracker. 

1241
00:51:54,800 --> 00:51:57,300
We've had collaborative 
development open for like over 

1242
00:51:57,300 --> 00:51:59,300
10 years. 
I think that's the most exciting

1243
00:51:59,300 --> 00:52:02,100
thing working on at the moment. 
We are looking for people who 

1244
00:52:02,100 --> 00:52:04,900
are interested in trying it out.
We are actively looking for 

1245
00:52:04,900 --> 00:52:06,800
feedback. 
Obviously, we're using it 

1246
00:52:06,800 --> 00:52:09,800
ourselves, the products that we 
dog food ourselves are the best,

1247
00:52:09,800 --> 00:52:12,400
because we use IntelliJ IDEA to 
write IntelliJ IDEA. 

1248
00:52:12,400 --> 00:52:15,600
We use IntelliJ The right kotlin
and so we're always improving 

1249
00:52:15,600 --> 00:52:16,300
those things. 
Now. 

1250
00:52:16,300 --> 00:52:19,800
We have a thousand Engineers 
working collaboratively out of 

1251
00:52:19,800 --> 00:52:21,900
the office. 
I expect this tool to improve 

1252
00:52:21,900 --> 00:52:23,900
but also, we're really 
interested in getting feedback 

1253
00:52:23,900 --> 00:52:26,600
from real developers and their 
real use cases and what they do 

1254
00:52:26,700 --> 00:52:28,200
by all means. 
We would quite like people to 

1255
00:52:28,200 --> 00:52:31,000
try this out, but be aware that 
it's early access. 

1256
00:52:31,000 --> 00:52:32,700
There's a lot of work which 
needs to happen. 

1257
00:52:32,900 --> 00:52:35,700
I'm also one of the voter for 
that bug that you mentioned 

1258
00:52:35,800 --> 00:52:39,700
especially for us now having to 
work from home and we rely on 

1259
00:52:39,700 --> 00:52:42,200
just doing remote. 
So, all these pairing and 

1260
00:52:42,200 --> 00:52:45,700
co-editing Your screen casting 
of the code that we working. 

1261
00:52:45,700 --> 00:52:48,400
I think it's going to be useful 
and I'm very excited to hear 

1262
00:52:48,400 --> 00:52:49,200
that. 
This product. 

1263
00:52:49,200 --> 00:52:51,400
Is there as an EAP, but still 
good enough. 

1264
00:52:51,400 --> 00:52:54,500
Probably are also check it out. 
And for those of us who wants to

1265
00:52:54,500 --> 00:52:57,900
learn how to do this on IntelliJ
or jetbrains products, make sure

1266
00:52:57,900 --> 00:53:00,100
to check it out. 
Trish is a pleasure talking to 

1267
00:53:00,100 --> 00:53:01,200
you. 
Obviously, we learned a lot 

1268
00:53:01,200 --> 00:53:03,200
about Java, but jetbrains about 
Korea views. 

1269
00:53:03,300 --> 00:53:05,800
I have one last question that 
normally I would ask for all my 

1270
00:53:05,800 --> 00:53:08,600
guests here in the show. 
Would you be able to share with 

1271
00:53:08,600 --> 00:53:11,600
us, three, technical leadership,
wisdom, probably for all of us 

1272
00:53:11,600 --> 00:53:14,600
to learn as well from you. 
I guess my primary technical 

1273
00:53:14,600 --> 00:53:15,900
leadership wisdom. 
That is the thing. 

1274
00:53:15,900 --> 00:53:17,400
I talked about earlier as the 
leader. 

1275
00:53:17,400 --> 00:53:20,200
It's not your responsibility to 
do is your responsibility to 

1276
00:53:20,200 --> 00:53:22,800
teach and help your team to 
level up and that's probably the

1277
00:53:22,800 --> 00:53:25,600
hardest transition to make and 
you just have to constantly 

1278
00:53:25,600 --> 00:53:27,400
remind yourself. 
That, of course, you could 

1279
00:53:27,400 --> 00:53:30,600
probably do it faster, maybe 
even better, but that's not what

1280
00:53:30,600 --> 00:53:32,500
your job is. 
Your job is to level up your 

1281
00:53:32,500 --> 00:53:35,200
team so that you have a team of 
people who can do it better and 

1282
00:53:35,200 --> 00:53:36,800
faster. 
Another piece of technical 

1283
00:53:36,800 --> 00:53:38,200
leadership. 
When you're a leader. 

1284
00:53:38,200 --> 00:53:39,800
You're just not going to have as
much time. 

1285
00:53:39,800 --> 00:53:41,700
You just not, you're going to be
in meetings. 

1286
00:53:41,700 --> 00:53:43,300
It's your job to network. 
Work. 

1287
00:53:43,300 --> 00:53:45,300
You are going to be the umbrella
for the team. 

1288
00:53:45,400 --> 00:53:47,900
You have to go to the meeting. 
So that not everyone in the team

1289
00:53:47,900 --> 00:53:50,300
has to go to meetings. 
You have to be the filter for 

1290
00:53:50,300 --> 00:53:52,200
information. 
You're in those meetings so that

1291
00:53:52,200 --> 00:53:54,900
you learn stuff from the rest of
the organization or from 

1292
00:53:54,900 --> 00:53:57,200
outside. 
The organization, your job is to

1293
00:53:57,200 --> 00:53:59,900
filter through all our 
information and make sure other 

1294
00:53:59,900 --> 00:54:02,800
people know it to you. 
Are the umbrella for the team. 

1295
00:54:02,800 --> 00:54:04,900
You don't want to distract the 
team, but you also do need to 

1296
00:54:04,908 --> 00:54:07,800
remember to feed on some of the 
valid information so that they 

1297
00:54:07,800 --> 00:54:10,000
feel like they're in the loop 
and that things don't take them 

1298
00:54:10,000 --> 00:54:12,400
by surprise. 
Not everyone is going to make a 

1299
00:54:12,408 --> 00:54:14,600
good leader. 
That doesn't mean that you're a 

1300
00:54:14,607 --> 00:54:16,400
bad person. 
It doesn't mean that you haven't

1301
00:54:16,400 --> 00:54:17,600
grown. 
It doesn't mean that you haven't

1302
00:54:17,600 --> 00:54:19,400
progressed. 
Sometimes you want to try 

1303
00:54:19,400 --> 00:54:21,500
leading, but it's a different 
set of skills, especially as an 

1304
00:54:21,500 --> 00:54:23,700
engineer. 
If you're a great developer, you

1305
00:54:23,700 --> 00:54:27,000
might not want to be a leader. 
It's not great in our 

1306
00:54:27,000 --> 00:54:29,300
environment because in our 
industry, we still tend to 

1307
00:54:29,300 --> 00:54:32,300
reward late leaders and managers
with more money and more 

1308
00:54:32,300 --> 00:54:34,400
bonuses. 
We're not necessarily doing 

1309
00:54:34,400 --> 00:54:35,700
more. 
You might just want to keep 

1310
00:54:35,700 --> 00:54:38,200
paying the site engineer. 
More money, not encourage them 

1311
00:54:38,200 --> 00:54:40,100
into a leadership role. 
They might not have the skills 

1312
00:54:40,100 --> 00:54:42,200
for that, and it's fine. 
And I think that should be fine.

1313
00:54:42,200 --> 00:54:45,300
We shouldn't always be Poking, 
senior people up into senior 

1314
00:54:45,300 --> 00:54:48,300
positions, they might just be 
much more effective as an 

1315
00:54:48,300 --> 00:54:50,300
individual contributor. 
Thank you, for sharing your 

1316
00:54:50,300 --> 00:54:52,500
wisdom. 
So Trish, where can people find 

1317
00:54:52,500 --> 00:54:54,600
you online. 
I'm active on Twitter. 

1318
00:54:54,800 --> 00:54:58,100
Tricia underscore GE or Twitter.
I do have a GitHub which is 

1319
00:54:58,100 --> 00:55:00,300
strategy. 
Arie launched my website. 

1320
00:55:00,300 --> 00:55:02,200
Trisha g.com. 
I'm Vlogging again. 

1321
00:55:02,200 --> 00:55:03,700
I haven't blocked for the 
longest time. 

1322
00:55:03,800 --> 00:55:05,600
So that's probably a good place 
to find me. 

1323
00:55:05,700 --> 00:55:07,500
I'm usually at conferences, but 
not this year. 

1324
00:55:08,400 --> 00:55:11,400
Okay, so I'll make sure everyone
check out all your Tweet, the 

1325
00:55:11,400 --> 00:55:13,000
website and all that. 
I'll put in the show notes. 

1326
00:55:13,200 --> 00:55:15,600
Thanks again, Trish for spending
your time with us, but it's 

1327
00:55:15,600 --> 00:55:18,000
really great to see you. 
And also hearing from what you 

1328
00:55:18,000 --> 00:55:20,400
have learned and what you have 
been doing in the Java world. 

1329
00:55:20,400 --> 00:55:22,100
So, thanks again. 
Thanks very much for having me. 

1330
00:55:22,107 --> 00:55:24,900
It was really fun. 
Thank you for listening to this 

1331
00:55:24,900 --> 00:55:27,600
episode and for staying right 
till the end. 

1332
00:55:27,800 --> 00:55:30,700
If you highly enjoyed, please 
share it with your friends and 

1333
00:55:30,700 --> 00:55:34,000
colleagues who you think would 
also benefit from listening to 

1334
00:55:34,000 --> 00:55:36,300
this episode. 
And if you're new to the 

1335
00:55:36,300 --> 00:55:39,600
podcast, make sure to subscribe 
and leave me your valuable 

1336
00:55:39,600 --> 00:55:43,000
review and feedback. 
It really really helps me a lot.

1337
00:55:43,100 --> 00:55:45,600
In order to grow this podcast 
better. 

1338
00:55:46,100 --> 00:55:49,400
You can also find the full show 
notes of this conversation on 

1339
00:55:49,400 --> 00:55:52,600
the episode page at tackle, the 
journal, the death website, 

1340
00:55:52,700 --> 00:55:56,100
including the full transcript, 
interesting quotes, and links to

1341
00:55:56,100 --> 00:56:00,300
the resources and mentions from 
the conversation, and lastly, 

1342
00:56:00,400 --> 00:56:03,400
make sure to subscribe to the 
shows mailing list on technology

1343
00:56:03,400 --> 00:56:06,900
on of the deaf to get notified 
for any future episodes. 

1344
00:56:07,200 --> 00:56:10,000
Stay tuned for the next 
technique Journal episode. 

1345
00:56:10,000 --> 00:56:11,700
And until then. 
Goodbye.