1
00:00:00,000 --> 00:00:02,100
Developer productivity is not 
lines of code written. 

2
00:00:02,100 --> 00:00:05,400
It's not number of commits. 
Its kind of irreducible to any 

3
00:00:05,400 --> 00:00:08,000
sort of low-level metric like 
that. 

4
00:00:08,000 --> 00:00:10,400
It really has to do with the 
ultimate problem. 

5
00:00:10,400 --> 00:00:12,300
You're solving and the users 
that you're solving it. 

6
00:00:12,300 --> 00:00:18,200
For. 
Hey, everyone. 

7
00:00:18,700 --> 00:00:23,400
My name is Henry Surya Barragan.
And you're listening to the 

8
00:00:23,400 --> 00:00:27,200
tekhelet Juno, the show will be 
bringing you the greatest 

9
00:00:27,200 --> 00:00:31,000
technical leaders practitioners 
and thought leaders in the 

10
00:00:31,000 --> 00:00:35,800
industry to discuss about their 
Journey ideas and practices that

11
00:00:35,800 --> 00:00:38,900
we all can learn and apply to 
build a highly performing 

12
00:00:38,900 --> 00:00:42,700
technical team and to make an 
impact in your personal work. 

13
00:00:43,500 --> 00:00:52,200
So let's dive into our Journal. 
Hey everyone, very excited to be

14
00:00:52,200 --> 00:00:55,100
back here again with another new
episode of the tekhelet journal 

15
00:00:55,100 --> 00:00:57,400
podcast. 
Thank you for tuning in and 

16
00:00:57,400 --> 00:00:59,900
spending your time with me 
today, listening to this 

17
00:00:59,900 --> 00:01:02,300
episode. 
If you're new, to the podcast 

18
00:01:02,400 --> 00:01:04,800
know that technology, you know, 
is available for you to 

19
00:01:04,800 --> 00:01:08,900
subscribe on major podcast apps 
such as Spotify, a podcast 

20
00:01:08,900 --> 00:01:11,500
Google podcast, YouTube, and 
many others. 

21
00:01:11,800 --> 00:01:14,000
Also, please check out and 
follow technology, you know, 

22
00:01:14,000 --> 00:01:17,500
social media channels on 
LinkedIn, Twitter and Instagram.

23
00:01:17,900 --> 00:01:21,300
Everyday, you will find words of
wisdom from the latest podcast 

24
00:01:21,300 --> 00:01:24,500
episode and I share them on 
those channels to give us some 

25
00:01:24,500 --> 00:01:28,100
inspiration and motivation for 
us to get better each day. 

26
00:01:28,600 --> 00:01:30,900
And if you'd like to make some 
contribution to the show and 

27
00:01:30,900 --> 00:01:34,200
support the creation of this 
podcast, please consider joining

28
00:01:34,200 --> 00:01:36,200
as a patron by visiting 
technology. 

29
00:01:36,200 --> 00:01:40,000
No dot f /, Patron. 
I highly appreciate any kind of 

30
00:01:40,000 --> 00:01:43,200
support and your contribution 
would help me to add sustainably

31
00:01:43,200 --> 00:01:46,700
producing this show every week. 
For today's episode. 

32
00:01:46,800 --> 00:01:49,900
I am happy to share. 
My conversation with Bianca, you

33
00:01:50,300 --> 00:01:54,300
beiong is the CTO and co-founder
of sauce graph, a developer 

34
00:01:54,300 --> 00:01:58,200
tools company that brings 
universal code search capability

35
00:01:58,200 --> 00:02:01,900
for developers in open source 
and every software organization 

36
00:02:02,000 --> 00:02:06,600
including leading companies like
uber, Dropbox, Yelp, PayPal, and

37
00:02:06,600 --> 00:02:09,800
cloudflare. 
In this episode, beiong, shared 

38
00:02:09,800 --> 00:02:13,300
with me his story on why he 
started building Source graph, 

39
00:02:13,700 --> 00:02:17,300
and the kind of problems that 
he's trying to solve it learning

40
00:02:17,300 --> 00:02:20,700
from his Has experience working 
at Google and experiencing 

41
00:02:20,700 --> 00:02:24,000
firsthand a great developer 
experience using Google internal

42
00:02:24,000 --> 00:02:27,700
tool called code search. 
He shared with me, his 

43
00:02:27,700 --> 00:02:31,100
perspective about developers 
productivity and how we should 

44
00:02:31,100 --> 00:02:33,900
go about measuring. 
It, including some words of 

45
00:02:33,900 --> 00:02:36,800
caution for measuring 
productivity, using proxy 

46
00:02:36,800 --> 00:02:40,700
metrics, such as lines of code, 
number of comets, or pull 

47
00:02:40,700 --> 00:02:44,300
requests Etc. 
We then discuss the rationale 

48
00:02:44,300 --> 00:02:47,700
for universal code search and 
why he thinks there's a massive.

49
00:02:47,900 --> 00:02:51,500
Need for such developer tool to 
increase developers productivity

50
00:02:52,000 --> 00:02:55,600
and especially to cope in the 
current ERA of big code. 

51
00:02:55,800 --> 00:02:59,000
A new kind of challenge that 
every software team and company 

52
00:02:59,200 --> 00:03:02,600
has to deal with related to the 
ever increasing size and 

53
00:03:02,600 --> 00:03:06,300
complexity of the code bases 
that are typical organization 

54
00:03:06,300 --> 00:03:11,000
has to maintain towards the end 
being shared, how individuals 

55
00:03:11,000 --> 00:03:14,500
can improve their personal 
developer productivity, and what

56
00:03:14,500 --> 00:03:17,700
the future state of developer 
tools would look like Duo. 

57
00:03:17,800 --> 00:03:21,000
So listen and check out some of 
the source craft cool use cases 

58
00:03:21,000 --> 00:03:24,100
that Beyond shared with me. 
Based on the feedback given by 

59
00:03:24,100 --> 00:03:27,000
his customers. 
Those use cases, are pretty cool

60
00:03:27,000 --> 00:03:30,100
to me and you may understand why
universal code search. 

61
00:03:30,200 --> 00:03:33,200
Might just be a tool that you 
need to increase your developers

62
00:03:33,200 --> 00:03:36,200
productivity. 
I enjoyed my conversation with 

63
00:03:36,200 --> 00:03:39,300
be young and if you also enjoy 
listening to this episode, 

64
00:03:39,500 --> 00:03:43,100
consider helping the show by 
living it a rating review or 

65
00:03:43,100 --> 00:03:47,200
comment on your podcast app or 
social media channels, those 

66
00:03:47,200 --> 00:03:50,100
reviews and Comments are one of 
the best ways to get this 

67
00:03:50,100 --> 00:03:53,600
podcast to reach more listeners 
and hopefully they can also 

68
00:03:53,600 --> 00:03:56,000
benefit from the contents in 
this podcast. 

69
00:03:56,500 --> 00:03:59,400
So, let's get this episode 
started right after a sponsor 

70
00:03:59,400 --> 00:04:01,600
message. 
Are you looking for a new cool 

71
00:04:01,600 --> 00:04:05,100
swag tekhelet Journal. 
Now offers you some swags that 

72
00:04:05,100 --> 00:04:08,900
you can purchase online. 
These wax are printed on demand 

73
00:04:08,900 --> 00:04:12,300
based on your preference and 
will be delivered safely to you 

74
00:04:12,400 --> 00:04:14,800
all over the world where 
shipping is available. 

75
00:04:15,300 --> 00:04:17,700
Check out all the cool swag is 
available by visiting. 

76
00:04:17,800 --> 00:04:20,600
Eating technology. 
No dot, f / shop, and don't 

77
00:04:20,600 --> 00:04:23,500
forget to break yourself. 
Once you receive any of those 

78
00:04:23,500 --> 00:04:28,900
tracks. 
Hey everyone, welcome to another

79
00:04:28,900 --> 00:04:30,800
new episode of the package. 
You know, today. 

80
00:04:30,800 --> 00:04:34,400
I have a special guest with me. 
His name is being Lou, he is the

81
00:04:34,400 --> 00:04:36,800
co-founder and CTO of sauce 
graph. 

82
00:04:37,100 --> 00:04:39,800
So, if you haven't heard about 
Source, graph is actually a tool

83
00:04:39,800 --> 00:04:42,500
for developers to do code 
searching. 

84
00:04:42,500 --> 00:04:45,100
And basically, helping the 
developers in order to be more 

85
00:04:45,100 --> 00:04:48,300
productive with their code. 
I'll let beiong to A mobile 

86
00:04:48,300 --> 00:04:51,200
Source graph later. 
So being welcome to the show. 

87
00:04:51,800 --> 00:04:53,400
Hey, Henry. 
Thanks for having me on. 

88
00:04:54,000 --> 00:04:57,200
So, beyond before we start, 
maybe let me hear from you your 

89
00:04:57,200 --> 00:04:59,300
introduction. 
What's your background? 

90
00:04:59,300 --> 00:05:02,100
What's your highlights selling 
points in your career for us to 

91
00:05:02,100 --> 00:05:03,800
hear about? 
Yeah, definitely. 

92
00:05:03,800 --> 00:05:07,700
So I've been programming since 
maybe like Middle High School. 

93
00:05:07,700 --> 00:05:11,000
I think I got into it first on, 
like a TI-83, graphing 

94
00:05:11,000 --> 00:05:12,800
calculator. 
There's like a dial, like, the 

95
00:05:12,808 --> 00:05:15,300
basic that you could code in 
that kind of got me into. 

96
00:05:15,300 --> 00:05:17,800
It is really fun. 
I was always kind of like a And 

97
00:05:17,800 --> 00:05:21,100
science nerd in my elementary 
middle school days and this kind

98
00:05:21,100 --> 00:05:23,900
of fit right in with that. 
After I got to college. 

99
00:05:23,900 --> 00:05:27,800
I took cs101 and fell in love 
with it and things unfurled from

100
00:05:27,800 --> 00:05:29,300
there. 
I guess from there. 

101
00:05:29,300 --> 00:05:32,700
I ended up doing this internship
at Google during my college 

102
00:05:32,700 --> 00:05:34,700
Years. 
I just mentioned that because 

103
00:05:34,700 --> 00:05:37,700
that was where I first got 
exposed to this concept of code 

104
00:05:37,700 --> 00:05:40,300
search, which is a thing that 
started me down this path, that 

105
00:05:40,300 --> 00:05:43,800
ultimately culminated in the 
starting Source graph with Quinn

106
00:05:43,800 --> 00:05:46,900
and building developer tools, 
but that was cool because it 

107
00:05:46,900 --> 00:05:49,200
gave me a bunch of Experience 
playing around with like 

108
00:05:49,200 --> 00:05:51,900
different developer tools that 
Google had built in internally, 

109
00:05:52,000 --> 00:05:54,300
one of which was with this 
Google code search thing. 

110
00:05:54,600 --> 00:05:56,800
After I left Google and work at 
other companies. 

111
00:05:56,800 --> 00:05:59,100
I kind of realize that code 
search was not the standard 

112
00:05:59,100 --> 00:06:00,700
thing. 
And so it always felt like this 

113
00:06:00,700 --> 00:06:02,200
piece of the toolkit that was 
missing. 

114
00:06:02,400 --> 00:06:06,000
That was the case at palantir. 
I joined palantir shortly after 

115
00:06:06,000 --> 00:06:08,000
graduating college and worked on
the commercial side of the 

116
00:06:08,000 --> 00:06:12,700
company or building Big Data 
analysis, tools for large Banks,

117
00:06:12,700 --> 00:06:15,200
and financial institutions. 
And that's where I got to work 

118
00:06:15,200 --> 00:06:17,600
closely with Quinn. 
My co-founder for the first. 

119
00:06:17,700 --> 00:06:20,000
Time we were on this kind of 
like small and startup within 

120
00:06:20,000 --> 00:06:23,500
the startup team, trying to 
tackle the data related problems

121
00:06:23,500 --> 00:06:26,800
of these large Banks Quinn and I
were both programmers by 

122
00:06:26,800 --> 00:06:29,200
background. 
Both had this kind of like side 

123
00:06:29,200 --> 00:06:31,300
hobby of trying out different 
tools, different editors 

124
00:06:31,300 --> 00:06:33,000
different command line 
utilities. 

125
00:06:33,200 --> 00:06:37,100
And we were always talking about
how much of our time was spent 

126
00:06:37,100 --> 00:06:39,200
reading through existing code 
and making sense of that. 

127
00:06:39,300 --> 00:06:42,600
And also, this like gap between.
When we first got into 

128
00:06:42,600 --> 00:06:44,300
programming. 
I think a lot of people get into

129
00:06:44,300 --> 00:06:46,800
and fall in love with it with 
that sense of being able to 

130
00:06:46,800 --> 00:06:49,800
create something. 
Sit down type away your desk and

131
00:06:49,800 --> 00:06:52,500
then couple hours later or maybe
a couple days later. 

132
00:06:52,500 --> 00:06:55,400
However, long the coding session
is you walk away with something 

133
00:06:55,400 --> 00:06:58,700
that you built and created. 
That is almost like this living 

134
00:06:58,700 --> 00:07:01,400
thing that does what you want 
contrast that to like the 

135
00:07:01,407 --> 00:07:04,600
experience of typical 
professional software developer,

136
00:07:04,600 --> 00:07:06,600
which we're getting more and 
more acquainted with. 

137
00:07:06,900 --> 00:07:09,500
And they're like, man, we spend 
very little of our times doing 

138
00:07:09,500 --> 00:07:12,300
that and way too much of our 
times, just trying to make sense

139
00:07:12,300 --> 00:07:15,500
of the existing code base. 
We saw also that pain reflected 

140
00:07:15,500 --> 00:07:18,800
over in the software engineers 
at our Customers that were 

141
00:07:18,800 --> 00:07:21,800
working with, that was the 
kernel or the initial 

142
00:07:21,800 --> 00:07:24,300
conversation that ultimately 
grew into Source graph. 

143
00:07:24,500 --> 00:07:27,600
So wanting to get back to that 
awesome flow states. 

144
00:07:27,600 --> 00:07:30,200
That every developer loves that 
inspired us to get into 

145
00:07:30,200 --> 00:07:32,500
programming. 
Make that more accessible to 

146
00:07:32,500 --> 00:07:36,000
day-to-day developers by helping
them understand their existing 

147
00:07:36,000 --> 00:07:38,000
code. 
So we end up starting Source 

148
00:07:38,000 --> 00:07:39,300
graph from there. 
At this point. 

149
00:07:39,300 --> 00:07:41,300
Probably the majority of my 
professional career has been 

150
00:07:41,300 --> 00:07:43,400
working at source craft. 
So we started the company back 

151
00:07:43,400 --> 00:07:47,000
in mid 2013 and now it's seven 
going on eight years later. 

152
00:07:47,500 --> 00:07:49,300
Thanks for sharing your story. 
Definitely. 

153
00:07:49,300 --> 00:07:52,400
It's interesting because you 
bumped into this opportunity. 

154
00:07:52,400 --> 00:07:56,400
Also, by chance, seeing how 
Google does the internal tooling

155
00:07:56,400 --> 00:07:58,600
for developers. 
You mentioned a lot of times 

156
00:07:58,600 --> 00:08:01,700
about developers productivity. 
Maybe let's start by the 

157
00:08:01,700 --> 00:08:03,600
definition. 
What do you mean by developers 

158
00:08:03,600 --> 00:08:05,600
productivity? 
Because these days, there are so

159
00:08:05,608 --> 00:08:06,900
many things about productivity, 
right? 

160
00:08:06,900 --> 00:08:09,500
Everyone is into productivity by
the, your to-do list, your 

161
00:08:09,508 --> 00:08:11,400
calendar, whatever apps that you
use. 

162
00:08:11,600 --> 00:08:14,200
What do you mean exactly by 
developers productivity? 

163
00:08:14,200 --> 00:08:16,800
Is it any different than any 
kind of productivity out there? 

164
00:08:17,400 --> 00:08:20,300
Yeah, that's a great question. 
Developer productivity is a 

165
00:08:20,308 --> 00:08:23,000
notoriously difficult thing to 
Define. 

166
00:08:23,300 --> 00:08:27,100
So I will try to come at it from
maybe a couple different angles 

167
00:08:27,100 --> 00:08:30,600
and see if that can help hone in
on roughly what it means. 

168
00:08:30,800 --> 00:08:32,700
First off. 
I just want to say developer 

169
00:08:32,700 --> 00:08:34,500
productivity is not lines of 
code written. 

170
00:08:34,500 --> 00:08:37,799
It's not number of commits. 
Its kind of irreducible to any 

171
00:08:37,799 --> 00:08:40,500
sort of low-level metric like 
that. 

172
00:08:40,600 --> 00:08:42,900
Because if you think about it, 
at the end of the day, what we 

173
00:08:42,900 --> 00:08:45,300
do as developers is, we're 
really creating new technology 

174
00:08:45,500 --> 00:08:48,300
every single feature or product.
That we work on. 

175
00:08:48,300 --> 00:08:51,000
Is this new thing. 
It's never existed before our 

176
00:08:51,000 --> 00:08:54,500
job is to build a program that 
solves that new problem in a new

177
00:08:54,500 --> 00:08:56,400
way. 
It's almost like a mini R&D 

178
00:08:56,400 --> 00:08:59,300
project rather than a factory 
model where you just like 

179
00:08:59,300 --> 00:09:03,100
turning out Widgets or whatever 
because of that property. 

180
00:09:03,300 --> 00:09:05,900
You can't really break it down 
until okay. 

181
00:09:06,000 --> 00:09:10,800
This is just the sum of all the 
functions and classes and files 

182
00:09:10,800 --> 00:09:13,400
that you author. 
It really has to do with the 

183
00:09:13,400 --> 00:09:15,600
ultimate problem, you're solving
and the users that you're 

184
00:09:15,600 --> 00:09:18,100
solving it for. 
So So that's one angle. 

185
00:09:18,100 --> 00:09:20,300
It's not lines of code. 
It's not like any sort of 

186
00:09:20,300 --> 00:09:23,500
low-level metric organizations 
that end up, treating that as a 

187
00:09:23,508 --> 00:09:26,100
proxy even like a first-order 
proxy. 

188
00:09:26,100 --> 00:09:28,900
I think end up introducing 
perverse incentives into their 

189
00:09:28,900 --> 00:09:31,100
development teams. 
That's how you get a lot of code

190
00:09:31,100 --> 00:09:33,400
written, but not actually 
solving user problems. 

191
00:09:33,700 --> 00:09:35,400
The other kind of angle to look 
at. 

192
00:09:35,400 --> 00:09:39,000
This is just view it. 
In terms of the overall picture 

193
00:09:39,200 --> 00:09:42,700
in some sense. 
Every piece of software is worth

194
00:09:42,700 --> 00:09:47,200
some amount of time saved or 
money because time is money in 

195
00:09:47,300 --> 00:09:49,900
Certain sense. 
So if you look at the value that

196
00:09:49,900 --> 00:09:52,300
you're creating, one thing that 
you can look at is, how much is 

197
00:09:52,300 --> 00:09:55,800
this piece of software being 
used by users who's using it? 

198
00:09:55,800 --> 00:09:58,900
And how much are they, paying 
you or how much revenue are you 

199
00:09:58,900 --> 00:10:00,300
generating from this piece of 
software? 

200
00:10:00,500 --> 00:10:03,800
Because that gives you, I think 
a better proxy for how much 

201
00:10:03,800 --> 00:10:06,500
productivity you're generating 
because at the end of the day 

202
00:10:06,500 --> 00:10:09,400
software is all about solving 
and automating problems for 

203
00:10:09,400 --> 00:10:11,800
people, saving people time 
having the computer do 

204
00:10:11,800 --> 00:10:13,400
something. 
So that a human being doesn't 

205
00:10:13,400 --> 00:10:15,700
have to do this wrote in 
repetitive process. 

206
00:10:16,000 --> 00:10:18,000
And so if you want to measure 
productivity, Ava T at a high 

207
00:10:18,000 --> 00:10:19,800
level. 
You start with the end user 

208
00:10:19,900 --> 00:10:22,500
think about time, saved or 
money, saved for the use of your

209
00:10:22,500 --> 00:10:25,000
software. 
Now, that's the high level 

210
00:10:25,000 --> 00:10:27,600
principled way of looking at it.
How does that actually help you 

211
00:10:27,600 --> 00:10:30,400
if you're an engineering manager
or a program around a 

212
00:10:30,400 --> 00:10:33,200
development team, inside a large
organization, the connection 

213
00:10:33,200 --> 00:10:37,000
between your individual work or 
your team's work to the overall 

214
00:10:37,000 --> 00:10:40,700
revenue of the company or the 
time saved across all the users 

215
00:10:40,700 --> 00:10:45,400
of the product is often a hard 
line to draw and that's why you 

216
00:10:45,400 --> 00:10:49,400
get things like the Organization
coming up with points like 

217
00:10:49,400 --> 00:10:51,300
Sprint points. 
If you use a scrum or a drawer, 

218
00:10:51,300 --> 00:10:54,000
one of those processes, one of 
the responsibilities of the 

219
00:10:54,000 --> 00:10:57,500
product organization is to 
roughly map user value time 

220
00:10:57,500 --> 00:11:00,900
saved, whatever it matters to 
the company into the customers 

221
00:11:00,900 --> 00:11:04,200
to this point system, that 
reduces all those complex 

222
00:11:04,200 --> 00:11:06,200
factors and their 
interrelationships between 

223
00:11:06,200 --> 00:11:08,700
different teams to rough Point. 
Allocation. 

224
00:11:08,700 --> 00:11:12,200
That's easy for engineering 
teams to reason about. 

225
00:11:12,300 --> 00:11:15,500
And so then you're talking about
how many points are you doing in

226
00:11:15,500 --> 00:11:18,100
a given quarter or so? 
I don't know if that's a 

227
00:11:18,108 --> 00:11:21,300
satisfying answer but that's 
roughly how productivity is 

228
00:11:21,300 --> 00:11:25,000
measured organizationally, but I
think at an individual level 

229
00:11:25,000 --> 00:11:28,300
it's almost like this feeling. 
It's almost like this binary 

230
00:11:28,300 --> 00:11:30,900
thing because a developer you 
either feel productive, you 

231
00:11:30,908 --> 00:11:33,200
don't feel productive. 
If you've done any amount of 

232
00:11:33,200 --> 00:11:35,700
software engineering, you know, 
that feeling the difference 

233
00:11:35,700 --> 00:11:38,500
between being in this Flow State
where your brain feels like. 

234
00:11:38,500 --> 00:11:41,500
It's firing on all cylinders, 
you know, you have all the 

235
00:11:41,500 --> 00:11:44,000
contextual information you need 
is coding away and you're like, 

236
00:11:44,100 --> 00:11:46,600
holy crap. 
I'm getting a lot done versus 

237
00:11:46,600 --> 00:11:48,800
the other. 
Which is when you're like, I 

238
00:11:48,800 --> 00:11:51,200
don't actually know how this 
piece of code that I'm 

239
00:11:51,200 --> 00:11:54,200
contributing to works. 
So all the changes I make are 

240
00:11:54,200 --> 00:11:58,400
like to local or I keep breaking
things, or I keep having to ask 

241
00:11:58,400 --> 00:12:01,500
this other person, a bunch of 
questions or the iteration 

242
00:12:01,500 --> 00:12:04,200
Cycles too long for me to get 
feedback to get into that, kind 

243
00:12:04,200 --> 00:12:07,200
of Flow State. 
So, an individual level, I think

244
00:12:07,200 --> 00:12:10,100
it often reduces to just, which 
mode are you in? 

245
00:12:10,300 --> 00:12:12,700
Are you in kind of paralysis 
mode? 

246
00:12:12,700 --> 00:12:14,400
Or are you in getting stuff, 
done? 

247
00:12:14,400 --> 00:12:17,600
Shipping code mode? 
I like the way that you Explain 

248
00:12:17,600 --> 00:12:19,000
that. 
At the end of the day, it has to

249
00:12:19,000 --> 00:12:22,000
bring value either to your users
or brings Revenue to your 

250
00:12:22,000 --> 00:12:23,900
company. 
But obviously, this is a very 

251
00:12:23,900 --> 00:12:28,500
tough thing to Define because 
how do you actually map back 

252
00:12:28,500 --> 00:12:31,300
what you do as a developer, you 
know, like churning code, maybe 

253
00:12:31,300 --> 00:12:35,200
debugging testing and map that 
back into how you bring value to

254
00:12:35,200 --> 00:12:37,000
the user? 
And I think it's taken for 

255
00:12:37,000 --> 00:12:39,800
granted and many companies that 
they don't actually do this kind

256
00:12:39,800 --> 00:12:41,900
of measurement. 
I know, and you say for 

257
00:12:41,900 --> 00:12:43,900
individual, we know it. 
When we feel it. 

258
00:12:44,000 --> 00:12:46,500
There will be a day when you 
feel like, oh, you're on fire, 

259
00:12:46,500 --> 00:12:49,200
you getting along Things done, 
you could just works pretty 

260
00:12:49,200 --> 00:12:51,100
fine. 
But there are days where you are

261
00:12:51,100 --> 00:12:53,800
judging to maybe processes. 
Maybe. 

262
00:12:53,800 --> 00:12:57,900
I don't know like very difficult
box to solve or even competing 

263
00:12:57,900 --> 00:13:00,600
priorities between multiple 
tasks that you need to do. 

264
00:13:00,800 --> 00:13:04,100
But in the first place because 
in many companies, I'm sure that

265
00:13:04,100 --> 00:13:07,500
there's no such thing as a good 
well-defined developers 

266
00:13:07,500 --> 00:13:10,400
productivity metrics or 
measurement, but do you think 

267
00:13:10,400 --> 00:13:14,200
that we should start measuring 
and investing our time in coming

268
00:13:14,200 --> 00:13:17,000
up with this developers 
productivity, numbers match? 

269
00:13:17,200 --> 00:13:19,400
Alex, or even like some kind of 
rough proxy. 

270
00:13:20,000 --> 00:13:22,500
Yeah, that's a great question. 
I think it is important to 

271
00:13:22,500 --> 00:13:26,600
measure things in to quantify 
them because I think numbers, 

272
00:13:26,700 --> 00:13:29,100
keep people honest. 
Obviously, they're never going 

273
00:13:29,100 --> 00:13:30,900
to capture everything that you 
care about. 

274
00:13:31,000 --> 00:13:34,300
But in order to have something 
falsifiable and checkable, it's 

275
00:13:34,300 --> 00:13:37,000
good to define a metric. 
And then track your progress 

276
00:13:37,000 --> 00:13:38,800
toward it. 
Because if you just Define 

277
00:13:38,800 --> 00:13:41,800
things in terms of 
qualitatively, it's very easy to

278
00:13:41,800 --> 00:13:44,100
trick yourself and other people 
into thinking that. 

279
00:13:44,100 --> 00:13:46,800
Oh, they actually hit that where
maybe you didn't actually 

280
00:13:46,800 --> 00:13:48,300
deliver. 
On what you were trying to 

281
00:13:48,300 --> 00:13:52,800
deliver on so metrics and 
quantifying things is important,

282
00:13:52,800 --> 00:13:56,000
but it's really important. 
What metric you choose and how 

283
00:13:56,000 --> 00:13:59,300
you quantify that right now. 
I don't know if there is like a 

284
00:13:59,308 --> 00:14:03,000
single Universal metric of 
developer productivity, that it 

285
00:14:03,000 --> 00:14:06,100
makes sense to adopt across 
every software organization, 

286
00:14:06,200 --> 00:14:09,500
because, I think, whatever 
metrics that you use are in some

287
00:14:09,500 --> 00:14:14,100
sense, tied to your unique 
organization, and in some sense,

288
00:14:14,100 --> 00:14:16,900
tied to the problem that you're 
solving or the type of software 

289
00:14:16,900 --> 00:14:19,700
that You're building. 
So the way I think about it is 

290
00:14:19,800 --> 00:14:22,700
if you're a single developer 
working on a solo project. 

291
00:14:22,700 --> 00:14:24,100
That's completely 
self-contained. 

292
00:14:24,200 --> 00:14:25,400
Let's say you're an indie 
developer. 

293
00:14:25,400 --> 00:14:27,300
You're going to build a simple 
tool and then you going to sell 

294
00:14:27,300 --> 00:14:30,500
that for money your metric. 
The one that matters is really 

295
00:14:30,500 --> 00:14:32,100
Revenue. 
How much money are you 

296
00:14:32,100 --> 00:14:34,200
generating? 
How much our users willing to 

297
00:14:34,200 --> 00:14:36,800
pay for this piece of software? 
Because that tells you how 

298
00:14:36,800 --> 00:14:40,600
useful this piece of software is
to them in some sense or it's at

299
00:14:40,600 --> 00:14:43,500
least a lower bound on how 
useful this thing is to them. 

300
00:14:43,800 --> 00:14:46,500
And you scale that up to a 
hundred person or or thousand 

301
00:14:46,500 --> 00:14:49,300
person or At the top of your 
product engineering 

302
00:14:49,300 --> 00:14:51,600
organization. 
There's a person may be their 

303
00:14:51,600 --> 00:14:53,800
title is VP. 
Maybe the title is sitio. 

304
00:14:53,800 --> 00:14:57,900
Maybe it's director, who is 
responsible for delivery of the 

305
00:14:57,900 --> 00:15:01,900
whole system and is in some 
sense responsible for ensuring 

306
00:15:01,900 --> 00:15:04,700
that system is delivering as 
much value as it can to its 

307
00:15:04,700 --> 00:15:07,000
users. 
Whether its measured by Revenue 

308
00:15:07,000 --> 00:15:10,700
that product generates or time 
spent using the product. 

309
00:15:11,000 --> 00:15:13,100
Whatever it is. 
They probably have one or two 

310
00:15:13,100 --> 00:15:16,700
metrics that really are the kpi 
key performance indicator of 

311
00:15:16,700 --> 00:15:18,100
how. 
Well, They're doing their job 

312
00:15:18,200 --> 00:15:21,000
when they report to the CEO and 
they report to the board. 

313
00:15:21,100 --> 00:15:24,500
That's how they're evaluated, at
least in most well-run suffer 

314
00:15:24,500 --> 00:15:26,700
companies. 
It's that person's job to then, 

315
00:15:26,700 --> 00:15:28,700
go break it down, like the 
people reporting them. 

316
00:15:28,700 --> 00:15:32,100
Okay, what do I need them to do 
in order to achieve this goal? 

317
00:15:32,300 --> 00:15:33,900
In some cases? 
They might be able to break it 

318
00:15:33,900 --> 00:15:34,800
down, such that. 
Okay. 

319
00:15:34,800 --> 00:15:37,600
This part of the product is very
independent from this other part

320
00:15:37,600 --> 00:15:39,700
of the product. 
So I'm going to have to reports 

321
00:15:39,700 --> 00:15:41,300
of mine. 
You're responsible for this one 

322
00:15:41,300 --> 00:15:43,500
and you're responsible for that 
one, and I'm going to look at 

323
00:15:43,500 --> 00:15:46,400
the engagement numbers of each 
separately and I'm going to tie 

324
00:15:46,400 --> 00:15:48,600
your compensation. 
Shinto those metrics, because 

325
00:15:48,600 --> 00:15:52,000
that's a really good proxy of 
the overall usefulness of each 

326
00:15:52,000 --> 00:15:54,800
part of the system. 
Now, that's the lucky case, if 

327
00:15:54,800 --> 00:15:56,900
you can take apart the things 
and it breaks down nicely 

328
00:15:56,900 --> 00:15:59,600
without interdependencies. 
I think more commonly is that. 

329
00:15:59,600 --> 00:16:01,300
There's a lot of 
interdependencies. 

330
00:16:01,600 --> 00:16:05,300
You can't really say that you 
can't evaluate any piece of an 

331
00:16:05,300 --> 00:16:08,300
end user software application in
isolation, without reasoning 

332
00:16:08,300 --> 00:16:12,100
about its impact on other parts.
And there's also a cross-cutting

333
00:16:12,100 --> 00:16:15,100
concerns such as technical debt 
test coverage and things like 

334
00:16:15,100 --> 00:16:16,500
that. 
You have to worry about like the

335
00:16:16,500 --> 00:16:17,600
overall health. 
Our team. 

336
00:16:17,800 --> 00:16:19,900
And at the end of the day, it 
really is that person's 

337
00:16:19,900 --> 00:16:23,100
responsibility to figure out how
this all breaks down. 

338
00:16:23,300 --> 00:16:24,800
Yeah. 
I unfortunately don't have a 

339
00:16:24,800 --> 00:16:27,400
satisfying answer here because I
think every organization is a 

340
00:16:27,408 --> 00:16:30,200
little bit for any. 
It starts from the top that 

341
00:16:30,200 --> 00:16:33,500
person has a number that they're
trying to optimize that as a 

342
00:16:33,500 --> 00:16:36,200
proxy for the overall, end user 
value that they're trying to 

343
00:16:36,208 --> 00:16:39,100
deliver. 
And then part of the art and 

344
00:16:39,100 --> 00:16:41,700
craft of building, an 
organization is figure out what 

345
00:16:41,700 --> 00:16:45,900
the right breakdown of 
responsibility is and what 

346
00:16:45,900 --> 00:16:48,700
metrics are going to. 
Used to evaluate how each 

347
00:16:48,700 --> 00:16:51,200
constituent part of that 
organization is working. 

348
00:16:51,800 --> 00:16:54,000
So, in the beginning, you 
mentioned things like story 

349
00:16:54,000 --> 00:16:55,900
points, right? 
These days almost every 

350
00:16:55,900 --> 00:16:59,200
company's running, some kind of 
a jaw methodology, scrum or 

351
00:16:59,200 --> 00:17:02,800
T-shirt size, whatever they use.
A lot of them actually starts 

352
00:17:02,800 --> 00:17:06,300
using that as the measurement of
productivity or either like the 

353
00:17:06,300 --> 00:17:09,599
product engineering team or even
like individuals, and I know 

354
00:17:09,599 --> 00:17:12,400
these are like two edged sword. 
Sometimes it works. 

355
00:17:12,599 --> 00:17:15,200
But many cases actually, it 
doesn't work because, you know, 

356
00:17:15,200 --> 00:17:18,000
you can game the system, you 
create a As many points as you 

357
00:17:18,000 --> 00:17:21,300
want to, but actually doesn't 
mean anything or sometimes you 

358
00:17:21,300 --> 00:17:23,200
just take it. 
Okay, this story points. 

359
00:17:23,200 --> 00:17:25,200
Let's assume it's done. 
Let's create a new card. 

360
00:17:25,500 --> 00:17:27,599
So it's an illusion that you're 
making progress. 

361
00:17:27,900 --> 00:17:30,600
But my question on this is that 
do you start seeing these as a 

362
00:17:30,600 --> 00:17:33,700
problem coming up with the proxy
that actually doesn't work. 

363
00:17:33,900 --> 00:17:37,200
And if so, what will be from 
your experience, some basic 

364
00:17:37,200 --> 00:17:40,400
indicators that may be any team 
could start with that. 

365
00:17:40,400 --> 00:17:44,000
Doesn't lead them into something
that mislead the actual things 

366
00:17:44,000 --> 00:17:46,900
that they want to measure. 
Yeah, so if you're using any 

367
00:17:46,900 --> 00:17:49,800
sort, Points-based system, I 
think one of the things you want

368
00:17:49,800 --> 00:17:53,100
to be wary of is ensuring that 
you're being honest with 

369
00:17:53,100 --> 00:17:54,700
yourselves about Point 
allocation. 

370
00:17:54,800 --> 00:17:56,200
A lot of. 
It depends on the specific 

371
00:17:56,200 --> 00:17:58,100
people. 
You have on the team if you have

372
00:17:58,100 --> 00:18:01,200
someone who's experienced are 
running scrum or agile, who 

373
00:18:01,200 --> 00:18:03,700
knows how to work the system 
that can make the difference. 

374
00:18:03,700 --> 00:18:06,300
Between this being a working 
system for your team and it 

375
00:18:06,300 --> 00:18:08,200
being a not working system for 
your team. 

376
00:18:08,400 --> 00:18:10,900
Another thing that a lot of 
organizations do is, there's a 

377
00:18:10,900 --> 00:18:12,800
separation of product from 
engineering. 

378
00:18:13,000 --> 00:18:16,100
So that product is responsible 
for allocating the points and 

379
00:18:16,100 --> 00:18:19,400
then engineering is responsible 
for executing the projects 

380
00:18:19,400 --> 00:18:21,600
Associated those points. 
And because there's that 

381
00:18:21,600 --> 00:18:25,400
separation, you remove one of 
the incentives to game the 

382
00:18:25,400 --> 00:18:28,400
system because in some sense, 
engineering is measuring 

383
00:18:28,400 --> 00:18:30,900
themselves by velocity, but they
don't get to choose. 

384
00:18:31,000 --> 00:18:33,800
How many points are associated 
with each project. 

385
00:18:33,900 --> 00:18:35,700
So that's if you're using a 
points-based system. 

386
00:18:35,800 --> 00:18:38,600
It's not for everyone, full 
disclosure Source graph. 

387
00:18:38,600 --> 00:18:41,400
We used a points-based system, 
the past we currently don't on 

388
00:18:41,400 --> 00:18:44,900
any of the engineering teams. 
We might use one on select 

389
00:18:44,900 --> 00:18:47,000
engineering teams in the future,
not ruling it out. 

390
00:18:47,100 --> 00:18:49,200
It's perfectly good system, but 
it's not the one that we're 

391
00:18:49,200 --> 00:18:52,300
currently using. 
I think there are a lot of other

392
00:18:52,300 --> 00:18:54,700
proxy metrics that you can. 
Look at that. 

393
00:18:54,700 --> 00:18:57,900
Give you a sense of is your 
organization overall in a 

394
00:18:57,900 --> 00:19:01,100
healthy or not healthy State. 
I think one thing you can do is 

395
00:19:01,100 --> 00:19:04,500
you can send out survey just 
surveying your developers to see

396
00:19:04,500 --> 00:19:07,600
how satisfied they are and ask 
them how predicted they feel 

397
00:19:07,900 --> 00:19:12,100
relative to their ideal level of
productivity, or the levels of 

398
00:19:12,100 --> 00:19:15,200
productivity that they attain 
working at previous companies. 

399
00:19:15,400 --> 00:19:18,500
I think a lot of developers have
a And innate sense of how 

400
00:19:18,500 --> 00:19:21,200
productive they feel. 
Because again, it's this binary 

401
00:19:21,200 --> 00:19:23,700
thing where you either feel 
like, okay and getting stuff 

402
00:19:23,700 --> 00:19:27,500
done, or know there's a lot of 
barriers and paper cuts that are

403
00:19:27,500 --> 00:19:29,900
hurting me, preventing me from 
getting my job done. 

404
00:19:30,200 --> 00:19:33,500
You can also look at the Ops and
deployment side. 

405
00:19:33,500 --> 00:19:36,500
There's a standard set of 
metrics now, or I should say an 

406
00:19:36,500 --> 00:19:40,500
emerging standard related to how
quickly you deploy and ship 

407
00:19:40,500 --> 00:19:43,100
software. 
So those I think they go by the 

408
00:19:43,100 --> 00:19:46,200
name accelerate or sometimes 
Dora metrics. 

409
00:19:46,300 --> 00:19:48,500
I think there's four of them. 
It have to do with like how 

410
00:19:48,500 --> 00:19:51,600
frequently you deploy decode, 
how much time there is between 

411
00:19:51,600 --> 00:19:54,100
submitting, a commit into the 
Upstream git repository, to when

412
00:19:54,100 --> 00:19:56,200
it shows up in production, 
things like that. 

413
00:19:56,300 --> 00:19:58,300
Those are good things to 
minimize. 

414
00:19:58,500 --> 00:20:01,600
If they're too high, then that's
an indicator that your organs is

415
00:20:01,600 --> 00:20:04,000
likely, not as productive as it 
could be. 

416
00:20:04,100 --> 00:20:06,500
In fact, probably much less 
productive than it could be. 

417
00:20:06,700 --> 00:20:10,300
So those more quantitative 
things are tied, more to the 

418
00:20:10,300 --> 00:20:12,100
operational side. 
In my view. 

419
00:20:12,100 --> 00:20:15,000
The operational side tends to be
a little bit more quantitative 

420
00:20:15,000 --> 00:20:18,400
because Ops is all about taking.
Taking the software, the source 

421
00:20:18,400 --> 00:20:21,900
code that you've written and 
just getting it into production 

422
00:20:22,200 --> 00:20:24,000
that process tends to be these 
days. 

423
00:20:24,000 --> 00:20:27,300
A more automated process. 
A lot of humans have been taken 

424
00:20:27,300 --> 00:20:28,700
out of the loop there with 
things. 

425
00:20:28,700 --> 00:20:30,700
Like see ICD. 
You have these systems are 

426
00:20:30,700 --> 00:20:33,500
designed to take the changes to 
source code and then push them 

427
00:20:33,500 --> 00:20:35,900
through some sort of q, a 
pipeline, until they're 

428
00:20:35,900 --> 00:20:39,300
automatically deployed on the 
more product in application 

429
00:20:39,300 --> 00:20:42,100
engineering side. 
It's tougher to quantify and 

430
00:20:42,100 --> 00:20:44,700
that's why you have these Point 
systems where that's an attempt 

431
00:20:44,700 --> 00:20:46,900
at quantification through 
product prioritization. 

432
00:20:47,300 --> 00:20:50,000
But you know, unfortunately, I 
don't have a great answer other 

433
00:20:50,000 --> 00:20:51,900
than talking to your developers 
and asking them. 

434
00:20:51,900 --> 00:20:55,000
Hey, are you hurting right now 
or do you feel like you're being

435
00:20:55,000 --> 00:20:57,800
really productive? 
There isn't really a good 

436
00:20:57,800 --> 00:21:00,700
Universal set of metrics that 
you can look at on the 

437
00:21:00,708 --> 00:21:03,500
application engineering and 
product side that gives you a 

438
00:21:03,500 --> 00:21:05,600
good idea of how good your team 
is operating. 

439
00:21:05,800 --> 00:21:08,800
I think that side of the picture
is almost like emotional 

440
00:21:08,800 --> 00:21:12,100
intuitive empathetic and I think
that's why I put these such an 

441
00:21:12,100 --> 00:21:14,600
important quality and 
Engineering managers because 

442
00:21:14,600 --> 00:21:16,700
they kind of have their finger 
on the pulse of the development 

443
00:21:16,700 --> 00:21:18,200
team. 
They can a know what the 

444
00:21:18,200 --> 00:21:21,600
potential of the people is on 
that team and how close they are

445
00:21:21,600 --> 00:21:24,500
to realizing or actualizing that
potential. 

446
00:21:25,000 --> 00:21:28,300
I like the way that you simplify
all this just by talking to your

447
00:21:28,300 --> 00:21:30,700
developers. 
So sometimes a lot of managers, 

448
00:21:30,700 --> 00:21:33,400
a lot of leaders. 
They forget this aspect, maybe 

449
00:21:33,400 --> 00:21:35,800
also relates back to the empathy
thing that you mentioned, 

450
00:21:36,100 --> 00:21:39,200
because maybe they try to find 
the perfect system, either like 

451
00:21:39,200 --> 00:21:42,500
a gel story points. 
Technical debt lines of code, 

452
00:21:42,500 --> 00:21:46,000
being tested or whatever that is
without actually thinking back 

453
00:21:46,000 --> 00:21:48,300
on The Human Side. 
And the developers themselves, 

454
00:21:48,300 --> 00:21:51,300
they might give a lot of 
insights into a daily 

455
00:21:51,300 --> 00:21:53,100
productive. 
Or are they being hindered by 

456
00:21:53,100 --> 00:21:57,300
processes or politics teams or 
even technical debt, which has 

457
00:21:57,300 --> 00:21:59,400
been surrounded over a period of
time. 

458
00:21:59,600 --> 00:22:02,400
So I like the way that you 
relates back to Developers for 

459
00:22:02,400 --> 00:22:04,000
leaders out there. 
I think it's very easy. 

460
00:22:04,000 --> 00:22:05,700
Just talked to your developers. 
Ask them. 

461
00:22:05,700 --> 00:22:08,400
How do they feel when they work 
on some code lately? 

462
00:22:08,700 --> 00:22:10,300
Just real quick. 
I just want to clarify. 

463
00:22:10,400 --> 00:22:12,100
You're absolutely right. 
You should have your finger on 

464
00:22:12,100 --> 00:22:13,800
the pulse of the development 
team and you should be talking 

465
00:22:13,800 --> 00:22:15,900
to your developers daily. 
I'm not saying that you can't 

466
00:22:15,900 --> 00:22:17,000
come up with any sort of 
quantitative. 

467
00:22:17,100 --> 00:22:20,500
Metrics on the engineering side,
like a lot of organizations do, 

468
00:22:20,700 --> 00:22:23,600
let's say you identify Tech debt
as a big problem and then you 

469
00:22:23,600 --> 00:22:26,200
come up with a way to evaluate 
code for Tech tip. 

470
00:22:26,300 --> 00:22:29,100
Maybe there's some simple 
parsing or linting mechanism. 

471
00:22:29,100 --> 00:22:32,400
That is a proxy for that or if 
there's not enough testing your 

472
00:22:32,400 --> 00:22:34,900
code base. 
If that's a clear need, then you

473
00:22:34,900 --> 00:22:38,200
can spin up a coverage tool like
coveralls are code Cove and 

474
00:22:38,200 --> 00:22:40,800
track that metric down because 
that gives you a line by line, 

475
00:22:41,000 --> 00:22:43,500
but I think you can't use those 
as top-line indicators of 

476
00:22:43,500 --> 00:22:46,100
overall health. 
They are just kpis that you 

477
00:22:46,100 --> 00:22:50,100
track to Specific problems. 
And you always keep the human in

478
00:22:50,100 --> 00:22:52,000
the loop here. 
You're always in touch with your

479
00:22:52,000 --> 00:22:54,300
development team. 
To ensure that as the number 

480
00:22:54,300 --> 00:22:57,300
goes down, people also feel 
better about it. 

481
00:22:57,700 --> 00:23:00,200
So, in the context of that 
technology Industries these 

482
00:23:00,200 --> 00:23:01,900
days, right? 
Obviously, there's this 

483
00:23:01,900 --> 00:23:05,000
Enterprise to traditional 
Enterprises companies who have 

484
00:23:05,000 --> 00:23:07,900
been around a long time. 
They might have a well-defined 

485
00:23:07,900 --> 00:23:11,000
software development process and
there's also the startups which 

486
00:23:11,000 --> 00:23:13,900
probably arguably do not have 
any process in place, and they 

487
00:23:13,900 --> 00:23:15,600
just figure it out along the 
way. 

488
00:23:15,800 --> 00:23:18,900
So, do you think they are? 
To set of problems where from 

489
00:23:18,900 --> 00:23:21,900
the Legacy Point of View, maybe 
you have traditional ways of 

490
00:23:21,900 --> 00:23:24,200
doing software development, 
either the waterfall or the 

491
00:23:24,200 --> 00:23:26,800
software development lifecycle 
that companies adopt and also 

492
00:23:26,800 --> 00:23:29,900
the Other Extreme, which the 
startups who are trying to come 

493
00:23:29,900 --> 00:23:32,700
up with a good way of making the
app developers, more productive 

494
00:23:32,700 --> 00:23:34,600
turning out more features for 
their products. 

495
00:23:34,900 --> 00:23:37,100
Do you think that these two 
extremes that you need to think 

496
00:23:37,100 --> 00:23:40,100
about, especially for those who 
work on these set of companies? 

497
00:23:40,800 --> 00:23:42,700
Yeah. 
So between startups and 

498
00:23:42,700 --> 00:23:45,400
Enterprises, I guess the 
question is, how different are 

499
00:23:45,400 --> 00:23:46,900
they actually do? 
We need? 

500
00:23:47,000 --> 00:23:50,400
A completely different set of 
rules and best practices for how

501
00:23:50,400 --> 00:23:53,500
to do great software development
inside large Enterprises versus 

502
00:23:53,500 --> 00:23:55,000
startups. 
My cents on. 

503
00:23:55,008 --> 00:23:58,700
That is it's always yes, and no 
but I think fundamentally, it's 

504
00:23:58,700 --> 00:24:00,800
the same, right? 
Like software developers 

505
00:24:00,800 --> 00:24:02,900
wherever you are, whether in a 
big company or a small company. 

506
00:24:02,900 --> 00:24:05,400
There's a couple things that you
really care about that. 

507
00:24:05,400 --> 00:24:08,500
Make you really productive fast 
feedback loop. 

508
00:24:08,600 --> 00:24:12,800
Are you able to build tests 
compile the code quickly? 

509
00:24:13,100 --> 00:24:15,900
How long does it take between 
offering a change and seeing it 

510
00:24:15,900 --> 00:24:19,200
in production and getting the 
Users, all those Loops you care 

511
00:24:19,200 --> 00:24:20,900
about making as quick as 
possible. 

512
00:24:21,100 --> 00:24:23,200
You care about automating as 
much as you can. 

513
00:24:23,500 --> 00:24:26,400
So if there's any certainty way 
that you need to do in order to 

514
00:24:26,400 --> 00:24:29,200
ensure that your suffer meets a 
certain quality bar. 

515
00:24:29,300 --> 00:24:32,000
Ideally, you want that automated
without human beings in the 

516
00:24:32,000 --> 00:24:33,700
loop. 
So that everything just works. 

517
00:24:33,700 --> 00:24:35,500
You can focus on the creative 
parts of the job. 

518
00:24:35,700 --> 00:24:38,600
And you want a really robust 
development environment where 

519
00:24:38,600 --> 00:24:42,000
it's easy to look up the context
that you need to have in order 

520
00:24:42,000 --> 00:24:44,000
to be productive. 
One of the things that might be 

521
00:24:44,000 --> 00:24:46,800
undervalued at both startups and
large Enterprises is the amount 

522
00:24:46,800 --> 00:24:49,500
of the job of being a 
professional software engineer 

523
00:24:49,500 --> 00:24:53,400
or developer that is reading and
understanding code before you 

524
00:24:53,408 --> 00:24:56,400
can actually write the code that
builds the specific feature that

525
00:24:56,400 --> 00:24:58,300
you're implementing. 
You have to understand the code 

526
00:24:58,300 --> 00:24:59,700
base that you're contributing 
to. 

527
00:25:00,000 --> 00:25:02,100
You have to understand how your 
change fits into that. 

528
00:25:02,200 --> 00:25:04,700
You have to understand what 
other shared libraries are 

529
00:25:04,700 --> 00:25:08,100
packages exist in your code base
or perhaps out there in the open

530
00:25:08,100 --> 00:25:10,500
source world that you can use in
leverage because you don't want 

531
00:25:10,500 --> 00:25:12,800
to reinvent the wheel. 
And then when you go to submit 

532
00:25:12,800 --> 00:25:15,800
the change, most organizations 
these days, practice code 

533
00:25:15,800 --> 00:25:17,600
review. 
So someone else Team has to go 

534
00:25:17,600 --> 00:25:19,300
and review the code and 
understand your change. 

535
00:25:19,300 --> 00:25:21,800
Understand how it impacts the 
rest of the code base. 

536
00:25:22,100 --> 00:25:24,600
Ideally, understand it, as well 
as the person who authored the 

537
00:25:24,600 --> 00:25:26,900
change, which is no small feat. 
In some ways. 

538
00:25:26,900 --> 00:25:29,100
It's more difficult, but we can 
get into that later. 

539
00:25:29,400 --> 00:25:30,700
That's a problem. 
That applies. 

540
00:25:30,900 --> 00:25:34,100
I think universally from the 
largest Enterprise development 

541
00:25:34,100 --> 00:25:37,500
organizations, all the way down 
to the individual developer. 

542
00:25:37,800 --> 00:25:40,100
I think where it gets different 
between the two scenarios is 

543
00:25:40,100 --> 00:25:42,200
just the constraints that you 
have to work with. 

544
00:25:42,500 --> 00:25:45,100
So, if you're working inside a 
large existing organizations, 

545
00:25:45,100 --> 00:25:46,900
especially one that has an 
established product. 

546
00:25:47,000 --> 00:25:49,900
Duct, the ton of users you're 
going to be working in an 

547
00:25:49,900 --> 00:25:51,800
environment with more 
constraints. 

548
00:25:52,100 --> 00:25:55,100
Those constraints are sometimes 
bad, but often good, they always

549
00:25:55,100 --> 00:25:58,200
exist for a reason, you have 
quality constraints to ensure 

550
00:25:58,200 --> 00:26:01,000
that code that breaks 
functionality for end-users 

551
00:26:01,000 --> 00:26:04,200
doesn't make it into production.
You have the constraints of 

552
00:26:04,200 --> 00:26:07,100
fitting your change into the 
overall code base following the 

553
00:26:07,100 --> 00:26:11,800
stylistic conventions meeting 
the necessary test coverage bars

554
00:26:11,900 --> 00:26:15,700
passing Architectural Review 
from the senior engineers and 

555
00:26:15,700 --> 00:26:19,100
architects, who are Possible for
maintaining a certain level of 

556
00:26:19,100 --> 00:26:21,300
consistency and quality across 
the code. 

557
00:26:21,400 --> 00:26:25,600
These are all constraints that 
are necessary to make the team 

558
00:26:25,600 --> 00:26:28,900
functional at a larger scale, 
all in the service of building 

559
00:26:29,000 --> 00:26:31,400
more complex product, that's 
able to do more stuff from where

560
00:26:31,400 --> 00:26:34,500
users and so dealing with those 
constraints, especially in the 

561
00:26:34,500 --> 00:26:37,900
context of a larger code base. 
I think it becomes a bigger part

562
00:26:37,900 --> 00:26:40,800
of the problem solving role of 
software engineering inside 

563
00:26:40,800 --> 00:26:43,600
larger organizations, because 
you're not just solving, for the

564
00:26:43,600 --> 00:26:46,700
needs of the users directly, but
you're solving also for these 

565
00:26:46,900 --> 00:26:51,100
Strains imposed by the overall 
organization in the service of 

566
00:26:51,100 --> 00:26:53,700
the overall user set, or 
customer set of the 

567
00:26:53,700 --> 00:26:56,300
organization, definitely makes 
sense. 

568
00:26:56,500 --> 00:26:59,600
I think you brought a wonderful 
point for developers. 

569
00:26:59,600 --> 00:27:02,700
Most of the time you don't work 
with like Greenfield project. 

570
00:27:02,700 --> 00:27:04,800
We don't come up with code from 
the scratch. 

571
00:27:05,000 --> 00:27:08,000
Even if we do right. 
We normally utilize code from 

572
00:27:08,000 --> 00:27:10,900
somewhere either like open 
source projects, somewhere like,

573
00:27:10,900 --> 00:27:14,000
stack Overflow, and we just 
search and maybe copy paste and 

574
00:27:14,000 --> 00:27:16,000
adopt. 
I think it's a good segue as 

575
00:27:16,000 --> 00:27:18,400
well to talk about. 
Code search, which is what 

576
00:27:18,400 --> 00:27:21,600
you're doing with Source graph. 
So maybe you can share, why do 

577
00:27:21,600 --> 00:27:24,800
you think companies should 
invest in building tool? 

578
00:27:24,800 --> 00:27:28,100
Like so scrap or having a code 
search capability within a 

579
00:27:28,100 --> 00:27:30,400
company? 
And how does it differ with 

580
00:27:30,400 --> 00:27:32,800
normal IDE, which can search 
code as well. 

581
00:27:32,800 --> 00:27:35,800
So, maybe you can share a little
bit more about code search. 

582
00:27:35,800 --> 00:27:38,900
Yeah. 
So code search is a solution to 

583
00:27:38,900 --> 00:27:40,900
a problem and I'll start with 
the problem. 

584
00:27:40,900 --> 00:27:45,200
The problem is this collection 
of challenges and difficulties 

585
00:27:45,200 --> 00:27:48,900
that people who are starting to 
call Big code. 

586
00:27:48,900 --> 00:27:51,500
Big code is a buzzword. 
It's like big data in a sense, I

587
00:27:51,500 --> 00:27:55,400
guess, but it would encapsulate 
Siz all the things that get much

588
00:27:55,400 --> 00:27:59,000
harder when you're developing 
code at scale inside this world 

589
00:27:59,000 --> 00:28:02,900
and universe with way more code 
than there used to be and that 

590
00:28:02,900 --> 00:28:05,600
applies to both to co bases 
inside organizations. 

591
00:28:05,700 --> 00:28:08,000
And now you have more and more 
companies that are more and more

592
00:28:08,000 --> 00:28:11,000
software driven, and they have 
larger and larger code bases 

593
00:28:11,100 --> 00:28:13,300
than ever before. 
And a lot of these companies, by

594
00:28:13,300 --> 00:28:15,600
the way, are not like what you 
would call tech companies. 

595
00:28:15,600 --> 00:28:17,400
Traditionally. 
There are a couple He's in other

596
00:28:17,400 --> 00:28:21,200
sectors, like agriculture, 
Healthcare or Finance, or 

597
00:28:21,200 --> 00:28:23,600
whatever. 
The some really old established 

598
00:28:23,600 --> 00:28:26,000
companies that are now mainly 
software companies. 

599
00:28:26,400 --> 00:28:29,300
So that's one side a bit code is
the code inside your company's 

600
00:28:29,500 --> 00:28:31,400
these large proprietary code 
bases. 

601
00:28:31,400 --> 00:28:35,300
And the other side is, the 
exploding world of Open Source. 

602
00:28:35,600 --> 00:28:39,400
Open source has been around for 
a while now is decades old, but 

603
00:28:39,400 --> 00:28:43,200
the past 10 years have seen 
this, just like sharp uptick in 

604
00:28:43,200 --> 00:28:47,500
the volume and the number and 
the diversity of Open source 

605
00:28:47,500 --> 00:28:51,300
libraries in packages that are 
available a lot of this driven 

606
00:28:51,300 --> 00:28:54,300
by proliferation of the web and 
web services. 

607
00:28:54,600 --> 00:28:56,600
All of which is Howard by these 
open source. 

608
00:28:56,600 --> 00:28:58,200
Libraries. 
There's not a software 

609
00:28:58,200 --> 00:29:01,800
organization today that isn't 
heavily reliant on open source 

610
00:29:01,800 --> 00:29:06,200
code, which is amazing in a way.
But with all this progress also 

611
00:29:06,200 --> 00:29:08,600
come challenges, right? 
So the challenges of working 

612
00:29:08,600 --> 00:29:11,600
inside a large code base. 
It means that there's more kind 

613
00:29:11,600 --> 00:29:13,500
of context that you might be 
unaware. 

614
00:29:13,500 --> 00:29:16,700
That there's more to kind of 
read it and understand before 

615
00:29:16,700 --> 00:29:18,400
you. 
And start writing your new 

616
00:29:18,400 --> 00:29:22,200
feature with confidence. 
There's often this like Paradox 

617
00:29:22,200 --> 00:29:25,900
of choice or embarrassment of 
riches issue that comes along 

618
00:29:25,900 --> 00:29:27,700
with you know, you start writing
something. 

619
00:29:27,700 --> 00:29:29,700
You don't want to reinvent the 
wheel and you're like, oh, yeah,

620
00:29:29,700 --> 00:29:31,300
there's probably an open-source 
package. 

621
00:29:31,300 --> 00:29:33,200
That already does this thing 
that I'm building. 

622
00:29:33,200 --> 00:29:35,000
Let me go find it. 
And turns out there's not just 

623
00:29:35,000 --> 00:29:37,600
one there's five and then you 
have to go and figure out which 

624
00:29:37,600 --> 00:29:41,100
one is the right one to use. 
If I choose incorrectly it could

625
00:29:41,100 --> 00:29:42,800
cause me a lot of pain down the 
road. 

626
00:29:42,800 --> 00:29:46,100
So this important decision, but 
how do I evaluate things all 

627
00:29:46,100 --> 00:29:48,500
these challenges? 
Has are related to the fact that

628
00:29:48,500 --> 00:29:51,900
we're operating in this world, 
of unprecedented, volume of 

629
00:29:51,900 --> 00:29:53,900
code. 
And all of it might be relevant 

630
00:29:53,900 --> 00:29:55,000
to the task. 
You're doing and you want to 

631
00:29:55,000 --> 00:29:56,900
take advantage of that wealth of
knowledge. 

632
00:29:57,200 --> 00:29:59,800
And at the same time you have to
also satisfy the constraints 

633
00:29:59,800 --> 00:30:02,100
that volume of code might impose
on you. 

634
00:30:02,300 --> 00:30:04,500
So this is going back to the 
proprietary side. 

635
00:30:04,500 --> 00:30:06,100
A bit code. 
If you're contributing to a 

636
00:30:06,100 --> 00:30:09,000
large established codebase, you 
need to ensure that you follow 

637
00:30:09,000 --> 00:30:11,400
conventions Union. 
Sure that the change that you 

638
00:30:11,400 --> 00:30:14,300
commit doesn't just work in 
isolation but interacts. 

639
00:30:14,300 --> 00:30:18,200
Well with other components you 
need to And essentially like how

640
00:30:18,200 --> 00:30:20,300
it's going to fit in. 
So anyways, all these 

641
00:30:20,300 --> 00:30:23,000
challenges, they add up and they
add up so much that at some 

642
00:30:23,000 --> 00:30:24,400
point, reaches, a breaking 
point. 

643
00:30:24,400 --> 00:30:27,100
It's some point it reaches the 
point where the constraints that

644
00:30:27,100 --> 00:30:29,400
have to work with and the 
context that you have to load up

645
00:30:29,400 --> 00:30:33,200
and your head starts to be too 
much to fit into your IDE. 

646
00:30:33,400 --> 00:30:36,400
You can't just clone all the 
code that you need to know about

647
00:30:36,400 --> 00:30:38,700
to your local machine and one by
one set up their development 

648
00:30:38,700 --> 00:30:40,400
environments and spend up in 
your IDE. 

649
00:30:40,700 --> 00:30:42,900
And at some point, it can get so
bad that inside some of these 

650
00:30:42,900 --> 00:30:46,100
larger organizations, the 
customers that we've worked with

651
00:30:46,100 --> 00:30:48,300
the Developers. 
Is literally say like we don't 

652
00:30:48,300 --> 00:30:51,000
feel like we can get stuff done.
Like, we're not shipping things 

653
00:30:51,000 --> 00:30:54,400
anymore because the burden of 
the existing code base is so 

654
00:30:54,400 --> 00:30:56,800
great. 
And so that's where code search 

655
00:30:56,900 --> 00:30:58,700
comes into play. 
Because code search, is this 

656
00:30:58,700 --> 00:31:02,100
tool that 20 years ago, there 
wouldn't be a need for it inside

657
00:31:02,100 --> 00:31:05,200
most organizations because code 
bases were smaller back then. 

658
00:31:05,400 --> 00:31:08,000
But these days because 
everyone's working inside these 

659
00:31:08,000 --> 00:31:10,300
large code bases, where they 
want to know about the code. 

660
00:31:10,300 --> 00:31:12,800
That's not their local machine. 
They want to understand what's 

661
00:31:12,800 --> 00:31:14,700
out there. 
They want to see what libraries 

662
00:31:14,700 --> 00:31:15,900
exist. 
And how to use them. 

663
00:31:16,100 --> 00:31:19,200
They need a Rule to search over 
this giant Corpus of data. 

664
00:31:19,400 --> 00:31:21,600
Just like, in the early days of 
the internet. 

665
00:31:21,600 --> 00:31:23,900
You didn't necessarily need a 
search engine because it was 

666
00:31:23,900 --> 00:31:26,000
smaller and you could use 
something like Yahoo! 

667
00:31:26,000 --> 00:31:28,500
And that got you everywhere, 
that you might want to go. 

668
00:31:28,700 --> 00:31:32,000
But then as the volume of data 
and knowledge increase in that 

669
00:31:32,000 --> 00:31:34,300
Corpus of data, you wanted 
something that allowed you to 

670
00:31:34,300 --> 00:31:37,200
instantly jump to what you're 
trying to get to and make 

671
00:31:37,200 --> 00:31:40,800
accessible the kind of long tail
of things available in that 

672
00:31:40,800 --> 00:31:44,300
Global Knowledge Graph. 
And so with code, it's things 

673
00:31:44,300 --> 00:31:46,700
like, okay, how do I discover 
the libraries that? 

674
00:31:46,800 --> 00:31:49,100
Are available either internal or
external. 

675
00:31:49,100 --> 00:31:51,900
They might help me get my 
current job or task at hand 

676
00:31:51,900 --> 00:31:54,100
done. 
Once I find the available 

677
00:31:54,100 --> 00:31:55,900
libraries. 
How do I use them? 

678
00:31:56,000 --> 00:31:58,700
How do other people use them? 
The best way to learn a new 

679
00:31:58,700 --> 00:32:01,700
libraries Often by example, so I
want to see like, how this 

680
00:32:01,700 --> 00:32:04,900
particular function is called, 
but other folks, my teammates or

681
00:32:04,900 --> 00:32:07,500
maybe other open source 
contributors out there once I 

682
00:32:07,500 --> 00:32:09,700
start using it. 
Maybe this is a bug that tap is 

683
00:32:09,700 --> 00:32:11,500
in production. 
Now, I have to go and explore 

684
00:32:11,500 --> 00:32:14,000
this unfamiliar. 
Codebase this code that I didn't

685
00:32:14,000 --> 00:32:16,600
write someone else wrote. 
Maybe I've never met that 

686
00:32:16,600 --> 00:32:17,300
person. 
Before. 

687
00:32:17,300 --> 00:32:19,600
But now I need to go and debug 
their code and figure out. 

688
00:32:19,600 --> 00:32:22,400
Okay, is this error message 
coming from within this library?

689
00:32:22,400 --> 00:32:26,100
And if it is, how can I fix it? 
And sometimes you're doing it. 

690
00:32:26,100 --> 00:32:28,600
While production is down, so 
that your company is literally 

691
00:32:28,600 --> 00:32:31,000
burning money while you're 
trying to fix this problem. 

692
00:32:31,200 --> 00:32:33,800
So all these things go back to 
like you're operating in this 

693
00:32:33,800 --> 00:32:36,300
giant codebase. 
You never know when you're going

694
00:32:36,300 --> 00:32:38,800
to have to understand a part of 
that code that's unfamiliar to 

695
00:32:38,800 --> 00:32:42,300
you or that you've never worked 
on before and in order to get 

696
00:32:42,300 --> 00:32:43,700
there as quickly as possible 
with minimal. 

697
00:32:43,700 --> 00:32:46,500
Friction, with minimal context, 
switching, you need something 

698
00:32:46,500 --> 00:32:49,100
like Code search. 
That's optimized to help you 

699
00:32:49,100 --> 00:32:53,300
discover and understand those 
unfamiliar pieces of code. 

700
00:32:53,900 --> 00:32:56,400
So, this is my first time I 
could a hearing, the term be 

701
00:32:56,400 --> 00:32:58,000
coat. 
I mean, we all know about big 

702
00:32:58,000 --> 00:33:00,700
data, but because I think the 
way that you explain it, I think

703
00:33:00,700 --> 00:33:03,000
it makes sense. 
We see a lot of more and more 

704
00:33:03,000 --> 00:33:06,100
code, even if you just count 
GitHub repositories with the 

705
00:33:06,100 --> 00:33:08,300
open source world. 
I think it just increases 

706
00:33:08,300 --> 00:33:11,500
exponentially, it will keep 
growing as more and more people 

707
00:33:11,500 --> 00:33:14,500
are into engineering programming
and things like that. 

708
00:33:14,700 --> 00:33:17,800
I think the other term it could 
certainly make Coming back to 

709
00:33:17,800 --> 00:33:19,800
the use case, here of the code 
search. 

710
00:33:19,800 --> 00:33:22,800
Maybe you can share some of the 
case studies from some of your 

711
00:33:22,800 --> 00:33:25,800
customers. 
How does actually something like

712
00:33:25,800 --> 00:33:29,000
code search help to improve 
their productivity. 

713
00:33:29,100 --> 00:33:31,300
Is there anything for a 
particular research that you 

714
00:33:31,300 --> 00:33:33,700
have done that actually owe you?
But using code search really 

715
00:33:33,700 --> 00:33:36,400
improve something by X. 
Yeah. 

716
00:33:36,400 --> 00:33:39,400
So there's a couple different 
case studies and are irrelevant.

717
00:33:39,500 --> 00:33:43,100
I'll start with kind of the most
concrete one, which is when your

718
00:33:43,100 --> 00:33:46,400
site goes down, when there's a 
production issue, you want to 

719
00:33:46,400 --> 00:33:48,000
get this. 
Right back up as quickly as 

720
00:33:48,000 --> 00:33:50,700
possible, and you want to solve 
the root problem as quickly as 

721
00:33:50,700 --> 00:33:52,800
possible. 
But in either case, you want 

722
00:33:52,800 --> 00:33:54,300
that time to be as short as 
possible. 

723
00:33:54,300 --> 00:33:57,200
Ideally seconds. 
If not minutes, definitely 

724
00:33:57,200 --> 00:34:01,400
within the same day when an 
issue arises, the first question

725
00:34:01,400 --> 00:34:05,000
engineer gets paged and often 
woken up in the middle of night,

726
00:34:05,000 --> 00:34:07,800
and you wake up, wipe the sleep 
from your eyes and log onto your

727
00:34:07,800 --> 00:34:09,300
machine. 
The first question is, what the 

728
00:34:09,300 --> 00:34:11,500
heck went wrong. 
You're trying to root cause that

729
00:34:11,500 --> 00:34:13,000
issue. 
So you go through the logs, you 

730
00:34:13,000 --> 00:34:15,600
see an error message in the 
logs, and now you have to go and

731
00:34:15,600 --> 00:34:18,300
actually make that change in. 
Code or maybe you have to 

732
00:34:18,300 --> 00:34:21,600
identify which commits caused 
that change and revert that a 

733
00:34:21,600 --> 00:34:23,699
lot of our customers. 
When they start using Source 

734
00:34:23,699 --> 00:34:25,500
graph. 
It becomes our go-to tool for 

735
00:34:25,500 --> 00:34:27,600
doing this. 
You just take whatever are is 

736
00:34:27,600 --> 00:34:28,400
appearing. 
The logs. 

737
00:34:28,400 --> 00:34:32,000
You pop into the source graph 
and nine times out of 10 that 

738
00:34:32,000 --> 00:34:33,300
gives you exactly what you're 
looking for. 

739
00:34:33,300 --> 00:34:35,300
You click on the result. 
You see exactly the line of 

740
00:34:35,300 --> 00:34:38,300
code, that's throwing the air 
and then from there, you can 

741
00:34:38,300 --> 00:34:41,500
quickly figure out what's going 
on and write the fix and commit.

742
00:34:41,500 --> 00:34:45,000
It get production back online. 
So, we've heard from customers 

743
00:34:45,000 --> 00:34:46,699
who have honed in on that use 
cases. 

744
00:34:46,800 --> 00:34:49,300
Has we've turned some incidents.
That would have been like 

745
00:34:49,300 --> 00:34:53,100
hour-long, downtime incidents, 
two things that were solved in a

746
00:34:53,100 --> 00:34:54,900
matter of minutes, which is 
huge. 

747
00:34:54,900 --> 00:34:58,100
I think, especially in this age 
when a lot of applications are 

748
00:34:58,100 --> 00:35:00,500
web services. 
So if there's a production error

749
00:35:00,500 --> 00:35:02,800
means, your site is literally 
down and means you can't make 

750
00:35:02,800 --> 00:35:05,100
any money off the site. 
In your users are also yelling 

751
00:35:05,100 --> 00:35:07,800
at you because this thing that 
they probably started to depend 

752
00:35:07,800 --> 00:35:09,500
on rely on is currently 
unavailable. 

753
00:35:09,700 --> 00:35:12,300
So that's the very like a cute 
thing that we've been able to 

754
00:35:12,300 --> 00:35:15,100
solve for at the opposite end of
the spectrum. 

755
00:35:15,100 --> 00:35:17,900
There is what impact? 
How we Had on just like the 

756
00:35:17,900 --> 00:35:20,700
day-to-day developer 
productivity that, as I said 

757
00:35:20,700 --> 00:35:24,100
before, is a notoriously 
difficult thing to measure. 

758
00:35:24,400 --> 00:35:28,300
So, one of the challenges that 
we face is, when we go sell the 

759
00:35:28,308 --> 00:35:29,800
companies. 
They're like, okay, you know, 

760
00:35:29,800 --> 00:35:31,800
we'd like to measure the impact 
that you're having on our 

761
00:35:31,800 --> 00:35:34,200
organization and then we say, 
okay, great. 

762
00:35:34,400 --> 00:35:37,900
How do you currently measure the
productivity of your developers?

763
00:35:38,200 --> 00:35:40,900
Some people that use Sprint 
points in which case we'll say 

764
00:35:41,000 --> 00:35:43,400
after adopting Source graph. 
You'll see an increase in 

765
00:35:43,400 --> 00:35:46,600
overall velocity measured in 
points, but if they don't use 

766
00:35:46,800 --> 00:35:48,700
One of those Frameworks and they
don't have a good way of 

767
00:35:48,700 --> 00:35:50,200
measuring developer 
productivity. 

768
00:35:50,200 --> 00:35:54,100
Then one of our roles is sort of
becomes our responsibility to 

769
00:35:54,100 --> 00:35:57,300
help them determine a metric. 
That is a reasonably good proxy 

770
00:35:57,300 --> 00:35:59,300
for the productivity of their 
developers. 

771
00:35:59,600 --> 00:36:02,500
And sometimes it literally just 
reduces to developer 

772
00:36:02,500 --> 00:36:05,300
satisfaction. 
So we had cases, especially over

773
00:36:05,300 --> 00:36:07,600
the past year, with covid and 
the pandemic. 

774
00:36:07,600 --> 00:36:12,500
We actually had zero customers 
churn through the past year when

775
00:36:12,500 --> 00:36:16,000
we went and asked our contacts 
at a lot of customers and said, 

776
00:36:16,000 --> 00:36:17,800
you know, it's interesting. 
I knew that your business was 

777
00:36:17,800 --> 00:36:19,300
really hard. 
We expected you to be a 

778
00:36:19,308 --> 00:36:22,500
potential turn risk. 
They said well, when covid first

779
00:36:22,500 --> 00:36:25,900
hit we did like a survey of all 
the third party vendors and 

780
00:36:25,900 --> 00:36:28,600
tools that we use to see which 
ones we could possibly cut. 

781
00:36:28,600 --> 00:36:31,200
Because remember February, March
last year. 

782
00:36:31,200 --> 00:36:34,100
The sky was falling and everyone
was like, okay, if we have to 

783
00:36:34,100 --> 00:36:36,800
cut things, what can we cut when
they got to Source graph? 

784
00:36:36,800 --> 00:36:37,900
And I like, hey, development 
team. 

785
00:36:38,000 --> 00:36:39,600
How would you feel if we cut 
Source graph? 

786
00:36:39,600 --> 00:36:41,100
The response is just 
overwhelming. 

787
00:36:41,500 --> 00:36:44,100
This is a need to have tool. 
If you remove this, to, I 

788
00:36:44,100 --> 00:36:45,700
literally won't be able to get 
my job done. 

789
00:36:46,100 --> 00:36:48,800
The Us, was that intense for 
that reason. 

790
00:36:48,900 --> 00:36:52,000
It's saved our necks last year. 
So that's like the opposite end 

791
00:36:52,000 --> 00:36:53,900
of the spectrum. 
And then there's this like third

792
00:36:53,900 --> 00:36:56,900
angle, which touches upon one of
the other metrics that I 

793
00:36:56,908 --> 00:36:59,500
mentioned before, which are 
these kind of ad hoc 

794
00:36:59,500 --> 00:37:03,700
organization specific metrics. 
If a particular organization has

795
00:37:03,700 --> 00:37:06,500
a goal in mind. 
Let's say it's like increased 

796
00:37:06,500 --> 00:37:09,900
test coverage by X percent, or 
maybe we want to deprecate. 

797
00:37:09,900 --> 00:37:13,400
This old hacky API that, we've 
been trying to get rid of for 

798
00:37:13,400 --> 00:37:16,400
the past couple of years, but 
somehow it's impossible to Stamp

799
00:37:16,400 --> 00:37:18,400
Out. 
We've recently built into our 

800
00:37:18,400 --> 00:37:21,800
app, the ability to track usages
of particular functions and 

801
00:37:21,800 --> 00:37:24,600
things like that and also the 
ability to track this 

802
00:37:24,600 --> 00:37:26,500
numerically on like a chart 
basis. 

803
00:37:26,700 --> 00:37:29,600
So if you have one of these 
metrics that you can Define, in 

804
00:37:29,600 --> 00:37:32,600
terms of a small piece of code, 
that takes your code, bases 

805
00:37:32,600 --> 00:37:34,400
input and spits out a number 
for. 

806
00:37:34,400 --> 00:37:36,800
What is this metric? 
We can actually help you track 

807
00:37:36,800 --> 00:37:39,800
that number as it goes down. 
Another case study is like 

808
00:37:39,900 --> 00:37:43,200
particular customer has this, 
use case of deprecating this API

809
00:37:43,200 --> 00:37:45,900
and so we actually have a 
burndown chart over here are all

810
00:37:45,900 --> 00:37:49,000
the out. 
Outstanding usages of this API. 

811
00:37:49,100 --> 00:37:52,200
Now your goal as an organization
is to make this go to 0 by the 

812
00:37:52,200 --> 00:37:54,100
end of the year and here's how 
you're doing right now. 

813
00:37:54,600 --> 00:37:58,200
Wow, I left all those use cases 
that you mentioned suddenly I 

814
00:37:58,207 --> 00:38:01,700
can relate and I really like the
true validation of your tool 

815
00:38:01,800 --> 00:38:05,400
when things are in crisis. 
Like in the covid situation, the

816
00:38:05,400 --> 00:38:08,500
true validation of developers, 
most of them who would like to 

817
00:38:08,500 --> 00:38:10,000
have social graph still in 
place. 

818
00:38:10,200 --> 00:38:13,500
I think that's a true validation
of how your tool or code search 

819
00:38:13,500 --> 00:38:16,600
in this place is the true 
measurement of how Developers 

820
00:38:16,800 --> 00:38:20,500
Can be productive, definitely 
some of the companies or teams 

821
00:38:20,500 --> 00:38:23,800
might find it fancy for these 
use cases, but I think if you 

822
00:38:23,800 --> 00:38:27,300
asked developers, these are 
definitely very important, but 

823
00:38:27,300 --> 00:38:30,900
there is just no tool around to 
solve this problem and thank you

824
00:38:30,900 --> 00:38:33,600
for solving this problem. 
Definitely, few years ago. 

825
00:38:33,600 --> 00:38:36,300
You wrote this blog post about 
current state of developers 

826
00:38:36,300 --> 00:38:38,400
tools and I think code search 
with Source. 

827
00:38:38,400 --> 00:38:41,200
Graph is one thing. 
What are the other tools that 

828
00:38:41,200 --> 00:38:44,100
you think Worth to try out an 
experiment, whether you can 

829
00:38:44,100 --> 00:38:46,600
bring the same impact like 
Source graph into a team. 

830
00:38:47,200 --> 00:38:49,200
Yeah, totally. 
I think this is a really 

831
00:38:49,200 --> 00:38:52,000
exciting time to be working on 
developer tools. 

832
00:38:52,000 --> 00:38:55,400
And I guess to be a software 
developer in general because 

833
00:38:55,400 --> 00:38:59,600
what we've seen in the past five
years or so, but probably even 

834
00:38:59,600 --> 00:39:01,000
the past like two or three 
years. 

835
00:39:01,200 --> 00:39:06,500
There's just been this explosion
in the number of available open 

836
00:39:06,500 --> 00:39:08,800
source developer tools and 
developer tool companies. 

837
00:39:09,200 --> 00:39:10,900
It used to be very much the 
case. 

838
00:39:10,900 --> 00:39:13,800
I think that really good 
developer tools were associated 

839
00:39:13,800 --> 00:39:18,800
with a single proprietary. 
System of think windows in the 

840
00:39:18,800 --> 00:39:22,900
90s they had visual studio and 
dotnet and c-sharp, I guess to 

841
00:39:22,900 --> 00:39:24,400
some extent. 
You could argue like the Java 

842
00:39:24,400 --> 00:39:27,700
ecosystems fostered by Sun and 
then Oracle and that was the 

843
00:39:27,707 --> 00:39:30,000
case for a long time. 
But I think in recent years 

844
00:39:30,100 --> 00:39:33,100
perhaps driven by the 
proliferation of cloud and web 

845
00:39:33,100 --> 00:39:36,500
services, you've just seen this 
explosion of tools that are not 

846
00:39:36,500 --> 00:39:39,300
tied to any particular vendor 
ecosystem. 

847
00:39:39,500 --> 00:39:42,400
They're just vailable for anyone
to use regardless of whether you

848
00:39:42,400 --> 00:39:45,700
using this particular technology
stack, that's been a huge Boon 

849
00:39:45,700 --> 00:39:48,000
because it's freed. 
He's up a lot of room for 

850
00:39:48,000 --> 00:39:50,700
Innovation, but it's also been a
bit of a challenge because now, 

851
00:39:50,700 --> 00:39:52,500
there's like a bunch of 
different choices to choose 

852
00:39:52,500 --> 00:39:54,700
from, it's no longer. 
Just choose your vertical, 

853
00:39:54,700 --> 00:39:57,000
choose, which stack your on, and
then adopt all those standard 

854
00:39:57,000 --> 00:39:59,100
tools and that ecosystem. 
Sorry. 

855
00:39:59,100 --> 00:40:01,300
I have degress from the original
question here, which is what 

856
00:40:01,300 --> 00:40:03,600
tools would I recommend that are
really useful. 

857
00:40:03,900 --> 00:40:05,100
Yeah. 
So I think there are a lot of 

858
00:40:05,100 --> 00:40:07,500
great tools. 
I think that there is a lot of 

859
00:40:07,500 --> 00:40:11,000
great work being done and the 
devops or op side of things 

860
00:40:11,000 --> 00:40:15,700
right now, so couple of tools 
that we use at source graph on 

861
00:40:15,700 --> 00:40:18,000
the monitor. 
Inside we use this tool called 

862
00:40:18,000 --> 00:40:19,500
Centre. 
It's like application are 

863
00:40:19,500 --> 00:40:23,300
monitoring think of it as like a
stack Trace Explorer but on 

864
00:40:23,300 --> 00:40:25,700
steroids for your production 
systems. 

865
00:40:25,900 --> 00:40:28,000
That's great. 
We use this tool called 

866
00:40:28,000 --> 00:40:30,700
honeycomb, which is for 
observability. 

867
00:40:31,000 --> 00:40:33,200
Observability. 
Is this new way of thinking 

868
00:40:33,200 --> 00:40:36,500
about how you keep an eye on the
state of your production 

869
00:40:36,500 --> 00:40:38,700
systems. 
It allows us to instrument our 

870
00:40:38,700 --> 00:40:42,200
application and then go and 
explore the data set of 

871
00:40:42,200 --> 00:40:45,400
production events in this kind 
of open-ended fashion, which is 

872
00:40:45,400 --> 00:40:48,100
very important for debugging. 
Being anomalous events. 

873
00:40:48,300 --> 00:40:50,800
Hopefully you're at fixing 
issues as they pop up in 

874
00:40:50,800 --> 00:40:53,400
production, but that also means 
that every new error in 

875
00:40:53,400 --> 00:40:55,400
production is one that you 
haven't seen before. 

876
00:40:55,600 --> 00:40:58,200
So, in order to be able to 
diagnose as effectively, you 

877
00:40:58,207 --> 00:41:00,700
kind of want this more, 
open-ended exploration tool, 

878
00:41:00,700 --> 00:41:02,800
which is what honeycomb is great
for. 

879
00:41:03,100 --> 00:41:06,200
On the employment side. 
We use a tool called Palou me, 

880
00:41:06,200 --> 00:41:08,400
and we also use care reform from
Hashi. 

881
00:41:08,400 --> 00:41:10,700
Corp. 
The infrastructure management 

882
00:41:10,700 --> 00:41:14,100
deployment tools have gotten a 
lot better since 2013. 

883
00:41:14,400 --> 00:41:16,500
The tools were using. 
I think it was like AWS cloud. 

884
00:41:16,700 --> 00:41:19,500
Nation and doctor didn't even 
exist back then. 

885
00:41:19,800 --> 00:41:21,800
Nowadays. 
You got tools like terraform and

886
00:41:21,800 --> 00:41:25,000
plumy that make it much better 
to manage all the configuration 

887
00:41:25,000 --> 00:41:28,500
state of what you want deployed 
in kind of decorative fashion. 

888
00:41:28,600 --> 00:41:31,300
So easy to reason about and then
the system takes care of 

889
00:41:31,300 --> 00:41:32,800
spinning up. 
The proper infrastructure. 

890
00:41:33,000 --> 00:41:36,000
There's obviously Doctrine 
kubernetes, which have made 

891
00:41:36,000 --> 00:41:39,700
deploying software a lot easier.
I think especially multi-service

892
00:41:39,700 --> 00:41:43,400
applications, which source graph
is a multi-service application. 

893
00:41:43,700 --> 00:41:46,500
It's also been critical for 
making your software available. 

894
00:41:46,700 --> 00:41:49,800
Oil in a self-hosted way the 
conventional wisdom these days 

895
00:41:49,800 --> 00:41:54,100
is the world is moving to Cloud.
But from our experience many, if

896
00:41:54,100 --> 00:41:57,100
not, most large Enterprises 
still prefer a solution that 

897
00:41:57,100 --> 00:41:59,900
they can deploy into their own 
environment, especially a 

898
00:41:59,900 --> 00:42:03,400
product that indexes their code,
which is very sensitive data. 

899
00:42:03,800 --> 00:42:07,000
And so without Doctrine, 
kubernetes it be much harder to 

900
00:42:07,000 --> 00:42:09,800
offer a self-hosted product 
because you wouldn't have as 

901
00:42:09,800 --> 00:42:12,100
much control over the 
application deployment 

902
00:42:12,100 --> 00:42:14,400
environment and a lot of this is
going to be organization 

903
00:42:14,400 --> 00:42:16,600
specific, right? 
So what works for us might not 

904
00:42:16,700 --> 00:42:18,700
Certainly be the right thing for
you. 

905
00:42:19,000 --> 00:42:21,700
But those are the tools that we 
use, right? 

906
00:42:21,700 --> 00:42:24,200
And I couldn't also relate that 
to another article that you 

907
00:42:24,200 --> 00:42:27,200
wrote which is an ex-googler 
this guy to develop a tool 

908
00:42:27,400 --> 00:42:30,500
during your internship. 
You exposed to a lot of internal

909
00:42:30,500 --> 00:42:33,800
tools that maybe Google build, 
or maybe they used from it open 

910
00:42:33,800 --> 00:42:35,700
source or wherever they find it.
Yeah. 

911
00:42:35,700 --> 00:42:38,500
Why do you think it's important 
for you to write it? 

912
00:42:38,500 --> 00:42:42,400
And what's your mission in? 
Educating people to know about 

913
00:42:42,400 --> 00:42:46,000
what tools exist in Google and 
how it helps back to the world. 

914
00:42:46,500 --> 00:42:49,500
Yeah, so I have my own 
experience as an ex-googler, but

915
00:42:49,500 --> 00:42:52,000
to be fully up front. 
I did an internship at Google. 

916
00:42:52,000 --> 00:42:53,500
So I was there for all of three 
months. 

917
00:42:53,600 --> 00:42:55,600
It's been a while since I've 
been at Google and I had that 

918
00:42:55,600 --> 00:42:58,500
experience. 
But what we started to realize 

919
00:42:58,500 --> 00:43:02,000
as usage or Source graph group 
was that we were Landing in 

920
00:43:02,000 --> 00:43:05,200
those customers because an 
ex-googler would bring us in. 

921
00:43:05,500 --> 00:43:08,900
Because the pattern that we saw 
over and over again was someone 

922
00:43:08,900 --> 00:43:12,300
would leave Google, they would 
miss Google code search which is

923
00:43:12,308 --> 00:43:15,700
Google's, internal code search 
utility index does all Google's 

924
00:43:15,700 --> 00:43:18,100
code. 
Accessible to every developer. 

925
00:43:18,300 --> 00:43:21,400
They would look around and they 
would find source craft. 

926
00:43:21,400 --> 00:43:23,200
And they would say, this is 
awesome. 

927
00:43:23,200 --> 00:43:25,300
I'm going to introduce this to 
my new company. 

928
00:43:25,600 --> 00:43:28,500
Google as a development 
organization, is one of the most

929
00:43:28,500 --> 00:43:30,800
advanced and sophisticated in 
the world. 

930
00:43:30,900 --> 00:43:33,900
They really pioneered a lot of 
tools and technologies that have

931
00:43:33,900 --> 00:43:37,300
since, either made it into open 
source, or the inspired, similar

932
00:43:37,300 --> 00:43:41,000
open-source counterparts, but 
because all these kind of 

933
00:43:41,000 --> 00:43:43,600
Technologies are things were 
first built at Google and 

934
00:43:43,600 --> 00:43:46,200
there's like, Google specific 
tools inside, Google. 

935
00:43:46,300 --> 00:43:49,800
Google has become something of 
this like evolutionary the 

936
00:43:49,800 --> 00:43:52,700
analogy, I like to use is it's 
kind of like Australia, you go 

937
00:43:52,700 --> 00:43:54,300
to Australia, you look at the 
animals there. 

938
00:43:54,300 --> 00:43:56,300
They look similar to animals 
elsewhere in the world, but 

939
00:43:56,300 --> 00:43:58,800
they're all different. 
They got Kangaroos and stuff. 

940
00:43:59,000 --> 00:44:02,200
Google is like that where they 
branched off from the rest of 

941
00:44:02,207 --> 00:44:04,600
the world, a while back and 
they've been on their own 

942
00:44:04,600 --> 00:44:07,300
evolutionary path. 
A lot of the tools that they use

943
00:44:07,300 --> 00:44:09,500
internally are similar to ones 
in open source, but they're not 

944
00:44:09,500 --> 00:44:12,300
the same ones. 
And so one of the challenges 

945
00:44:12,300 --> 00:44:15,900
that we saw in speaking with all
these X googlers who became 

946
00:44:15,900 --> 00:44:19,300
source, Users and customers was 
like Hey, you know having some 

947
00:44:19,300 --> 00:44:22,800
difficulty mapping from Google 
internal technology to what's 

948
00:44:22,800 --> 00:44:26,000
available outside and that's a 
pain point because I think the 

949
00:44:26,000 --> 00:44:28,300
developer experience inside 
Google is so good. 

950
00:44:28,300 --> 00:44:31,000
That one of the first things 
that developers do when they 

951
00:44:31,000 --> 00:44:33,400
leave Google is they try to 
recreate pieces of that 

952
00:44:33,400 --> 00:44:36,900
developer experience, because 
like I felt the absence of code 

953
00:44:36,900 --> 00:44:40,300
search was super painful. 
And so wrote that blog post, 

954
00:44:40,300 --> 00:44:44,200
based on conversations with a 
bunch of such X googlers and 

955
00:44:44,200 --> 00:44:48,000
tried to put together a kind of 
a quick, Explainer for how do 

956
00:44:48,000 --> 00:44:51,700
you map from Google internal 
tools to ones available, outside

957
00:44:51,900 --> 00:44:54,400
to be a front. 
This was not the first post that

958
00:44:54,400 --> 00:44:57,100
touched on the topic. 
I think there's a GitHub repo 

959
00:44:57,100 --> 00:44:59,500
actually, which I think we 
linked to in the post that just 

960
00:44:59,500 --> 00:45:03,000
gives a comprehensive listing of
all the Google internal tools 

961
00:45:03,000 --> 00:45:06,200
and their external counterparts.
And our goal in the post was 

962
00:45:06,200 --> 00:45:08,700
just to present some of that 
information in more of a 

963
00:45:08,707 --> 00:45:12,000
narrative fashion and talk 
about, not only what tools you 

964
00:45:12,000 --> 00:45:13,700
might want to look at. 
But like how do you bring those 

965
00:45:13,700 --> 00:45:17,500
tools into your organization as 
an Blur entering the outside 

966
00:45:17,500 --> 00:45:19,500
world. 
So for those of you who would 

967
00:45:19,500 --> 00:45:23,000
like to learn more about all 
these mapping what tools exist 

968
00:45:23,000 --> 00:45:25,300
in Google and how it maps with 
others in the world. 

969
00:45:25,400 --> 00:45:28,300
I put that in the show notes 
also having seen inside Google 

970
00:45:28,300 --> 00:45:30,700
itself. 
I can validate that actually 

971
00:45:30,700 --> 00:45:33,400
these tools really brings a lot 
of productivity and they are 

972
00:45:33,400 --> 00:45:36,600
well integrated end-to-end from 
the beginning of your software 

973
00:45:36,600 --> 00:45:39,100
development life cycle to the 
end up to your code being 

974
00:45:39,100 --> 00:45:42,300
deployed on even maybe the locks
and monitoring observability and

975
00:45:42,300 --> 00:45:44,400
all that. 
So sometimes the integration 

976
00:45:44,400 --> 00:45:47,700
part probably is one of the most
Crucial piece of all this 

977
00:45:47,700 --> 00:45:50,400
developer tools because without 
that, you'll still scrambling 

978
00:45:50,400 --> 00:45:53,100
insiders when you want to debug 
something that you go to this 

979
00:45:53,100 --> 00:45:55,700
tool, but when you find another 
problem, you go to the other 

980
00:45:55,700 --> 00:45:59,000
tools, so I think it will be 
great one day in the future. 

981
00:45:59,000 --> 00:46:01,600
Hopefully soon that we will 
start seeing all these 

982
00:46:01,600 --> 00:46:04,500
interoperability between 
different developer tools, and 

983
00:46:04,500 --> 00:46:07,400
it'll be great experience for 
developers to have that as well.

984
00:46:07,800 --> 00:46:10,400
So, coming back to the 
developers productivity, right? 

985
00:46:10,600 --> 00:46:13,200
So, we talked a lot about from 
the product engineering point of

986
00:46:13,207 --> 00:46:17,000
view, company, team and all 
that, but what if I as an 

987
00:46:17,000 --> 00:46:20,400
individual as a programmer. 
I would like to also improve my 

988
00:46:20,400 --> 00:46:22,000
productivity. 
What should I do? 

989
00:46:22,000 --> 00:46:23,900
Maybe you have some perspective 
here. 

990
00:46:24,600 --> 00:46:29,100
Yeah, so on an individual basis,
I think you always want to start

991
00:46:29,100 --> 00:46:31,100
with the pain that you're trying
to solve. 

992
00:46:31,400 --> 00:46:34,800
When you're coding everyday, 
make note of what you find 

993
00:46:34,800 --> 00:46:38,300
difficult, what annoys you where
you're kind of like context 

994
00:46:38,300 --> 00:46:41,700
switching away from code. 
Like anything that takes you out

995
00:46:41,700 --> 00:46:44,400
of that flow state, where the 
state of flow is this kind of 

996
00:46:44,400 --> 00:46:46,900
mental state, where you just 
feel feel like your thought 

997
00:46:46,900 --> 00:46:50,200
processes is extremely fluid and
you just cranking out code and 

998
00:46:50,200 --> 00:46:52,800
he takes you out of that or 
anything that prevents you from 

999
00:46:52,800 --> 00:46:53,800
getting into. 
That. 

1000
00:46:53,800 --> 00:46:56,400
That's something that you should
address and you should address 

1001
00:46:56,400 --> 00:46:59,200
it in the way that programmers 
address. 

1002
00:46:59,200 --> 00:47:01,700
Every problem, which is figure 
out how to automate it. 

1003
00:47:01,800 --> 00:47:03,300
Chances are if it's causing you 
pain. 

1004
00:47:03,300 --> 00:47:06,100
It's because it's something 
wrote or repetitive or manual, 

1005
00:47:06,100 --> 00:47:09,500
or potentially unnecessary 
something that is boring to your

1006
00:47:09,500 --> 00:47:12,700
brain, but you have to do. 
And so when you go to automate 

1007
00:47:12,700 --> 00:47:14,600
it, there's obviously two ways 
of doing that. 

1008
00:47:14,600 --> 00:47:17,400
You can either build something 
that It's it for you, or you 

1009
00:47:17,400 --> 00:47:20,300
could find a tool that already 
exists, that solves the issue, 

1010
00:47:20,400 --> 00:47:22,900
do a quick Google search and see
if anything exists. 

1011
00:47:23,100 --> 00:47:26,300
So that's like a very needs 
driven way of addressing pain 

1012
00:47:26,300 --> 00:47:28,600
points. 
The other angle, I'd recommend 

1013
00:47:28,600 --> 00:47:32,500
going about, it is just find 
developers on the internet, who 

1014
00:47:32,500 --> 00:47:36,500
write blog posts or maybe they 
tweet about their work flow or 

1015
00:47:36,500 --> 00:47:40,100
the tools that they use and use 
the tools that they use. 

1016
00:47:40,300 --> 00:47:43,200
Because I think one of the ways 
you get good at any sort of 

1017
00:47:43,207 --> 00:47:46,500
craft as you learn from the 
Masters that craft and It's not 

1018
00:47:46,500 --> 00:47:49,400
even about learning from masters
of The Craft per se because I 

1019
00:47:49,400 --> 00:47:51,000
think software development is 
one of those things where 

1020
00:47:51,000 --> 00:47:53,800
there's so many tools that 
chances are if you talk to 

1021
00:47:53,800 --> 00:47:56,900
anyone who's been doing this for
at least, some period of time. 

1022
00:47:56,900 --> 00:48:00,600
They'll probably have at least 
one tool that they are aware of,

1023
00:48:00,600 --> 00:48:02,300
that would be really useful to 
you. 

1024
00:48:02,300 --> 00:48:04,500
That would be really cool to try
out. 

1025
00:48:04,500 --> 00:48:06,500
In fact, we actually started 
doing this thing during 

1026
00:48:06,500 --> 00:48:08,100
quarantine on our development 
team. 

1027
00:48:08,100 --> 00:48:11,500
We're a bunch of Engineers on 
the source craft team would join

1028
00:48:11,500 --> 00:48:14,600
like a live stream and we have 
one person just screen, share 

1029
00:48:14,600 --> 00:48:17,500
their Dev environment. 
Up and walk us through. 

1030
00:48:17,500 --> 00:48:19,100
Like how do you make a code? 
Commit? 

1031
00:48:19,200 --> 00:48:22,100
Show us your editor? 
What command line utility is to 

1032
00:48:22,100 --> 00:48:25,700
use on a daily basis? 
And that was awesome. 

1033
00:48:25,900 --> 00:48:28,300
On the first one that we did. 
I walked away with three new 

1034
00:48:28,300 --> 00:48:31,400
tools that I had to try out that
weekend because it was like, 

1035
00:48:31,400 --> 00:48:32,800
wow. 
You can actually do that. 

1036
00:48:32,800 --> 00:48:34,900
I had no idea. 
I don't think it's announced 

1037
00:48:34,900 --> 00:48:37,400
yet, but we're going to turn 
that into web series because we 

1038
00:48:37,400 --> 00:48:40,300
think that that sort of 
conversation is so interesting 

1039
00:48:40,300 --> 00:48:43,400
and useful especially in the 
covid world or as the world 

1040
00:48:43,400 --> 00:48:45,600
becomes more remote. 
I think one of the things that 

1041
00:48:45,600 --> 00:48:48,000
we lose out on On is the ability
to look over. 

1042
00:48:48,000 --> 00:48:50,700
Our teammates, shoulders walk 
over to the desk and be like, 

1043
00:48:50,700 --> 00:48:54,000
oh, what is that on your screen 
that sort of like social 

1044
00:48:54,000 --> 00:48:55,800
connection. 
I think it's just a great way to

1045
00:48:55,800 --> 00:48:58,100
discover new tools and 
Technologies. 

1046
00:48:58,700 --> 00:49:00,400
I totally agree with you on 
this. 

1047
00:49:00,600 --> 00:49:03,600
So from my experience, with the 
way I figure out other tools is 

1048
00:49:03,600 --> 00:49:06,100
when I normally did pairing with
other developers. 

1049
00:49:06,300 --> 00:49:09,600
So, during the time when we can 
sit together side by side and 

1050
00:49:09,600 --> 00:49:12,200
also yeah, like what you said on
Twitter, people sometimes post 

1051
00:49:12,200 --> 00:49:15,400
random things that looks cool or
maybe it's just new open source 

1052
00:49:15,400 --> 00:49:17,900
tools that someone We just wrote
it and publish it. 

1053
00:49:18,000 --> 00:49:20,200
You think that it will help for 
your productivity. 

1054
00:49:20,400 --> 00:49:23,700
So I think I totally agree and I
think the permutation of many 

1055
00:49:23,700 --> 00:49:26,400
things that we can apply in our 
developer workflow. 

1056
00:49:26,600 --> 00:49:29,200
I think it's just tremendous, 
there will be a lot of things 

1057
00:49:29,200 --> 00:49:31,900
that you can try to improve in 
terms of your productivity. 

1058
00:49:32,200 --> 00:49:34,500
So a little bit here. 
I know that you mentioned. 

1059
00:49:34,700 --> 00:49:38,300
This is the time, the current 
exciting times for developer 

1060
00:49:38,300 --> 00:49:40,700
productivity tools, right? 
What are some of your 

1061
00:49:40,700 --> 00:49:43,000
predictions seeing this, maybe? 
I don't know. 

1062
00:49:43,000 --> 00:49:45,500
Five years forward. 
What will be the state of this 

1063
00:49:45,500 --> 00:49:46,900
developer productivity? 
Activity tools. 

1064
00:49:47,500 --> 00:49:50,800
Yeah, so I think right now we're
in this explosion of different 

1065
00:49:50,800 --> 00:49:53,700
tools in the kind of diversity 
of offerings in the parts of the

1066
00:49:53,700 --> 00:49:56,200
software development lifecycle 
that they tackle and it's 

1067
00:49:56,200 --> 00:49:58,600
amazing. 
I think that will continue over 

1068
00:49:58,600 --> 00:50:01,400
the next five years. 
I think this is a trend that's 

1069
00:50:01,400 --> 00:50:02,700
already playing out which is 
more. 

1070
00:50:02,700 --> 00:50:06,000
And more of these tools are 
either open source or opencore 

1071
00:50:06,000 --> 00:50:08,300
including the ones that 
enterprises pay for. 

1072
00:50:08,500 --> 00:50:11,900
And so there's a lot of 
companies that are pioneering 

1073
00:50:11,900 --> 00:50:14,700
business models built on top of 
Open Source Technologies, which 

1074
00:50:14,800 --> 00:50:18,700
I think is really cool. 
As developers care a lot about 

1075
00:50:18,700 --> 00:50:21,400
the openness of the software 
they build on top of, and also 

1076
00:50:21,400 --> 00:50:24,200
the software that you use. 
I think that kind of gets at the

1077
00:50:24,200 --> 00:50:27,000
importance of being able to 
introspect into your tools. 

1078
00:50:27,300 --> 00:50:30,500
If something goes wrong, you can
poke in and see what went wrong.

1079
00:50:30,700 --> 00:50:34,300
This is also, this almost like 
philosophical feeling that. 

1080
00:50:34,300 --> 00:50:37,200
Hey, if I'm building a 
substantial portion of my 

1081
00:50:37,200 --> 00:50:40,800
workflow on top of this tool, 
then I deserve a certain level 

1082
00:50:40,800 --> 00:50:44,300
of freedom in terms of ability 
to continue using that tool to 

1083
00:50:44,300 --> 00:50:45,800
some extent. 
I think people are still burned 

1084
00:50:45,800 --> 00:50:48,700
by Proprietary lock in which was
a common strategy. 

1085
00:50:48,700 --> 00:50:53,300
I think for software vendors in 
the 1990s, but increasingly the 

1086
00:50:53,300 --> 00:50:55,400
consensus is that open is the 
way to go. 

1087
00:50:55,500 --> 00:50:57,900
And so I think you'll see more 
and more companies that are 

1088
00:50:57,900 --> 00:51:00,200
building tools where the tool 
that's relevant for the 

1089
00:51:00,200 --> 00:51:02,800
individual developer. 
That part is going to be open 

1090
00:51:02,800 --> 00:51:06,000
source, and then there's like an
Enterprise component that is 

1091
00:51:06,000 --> 00:51:09,100
more important for teams or 
organizations. 

1092
00:51:09,100 --> 00:51:11,900
That might be kept proprietary. 
In order to be able to build a 

1093
00:51:11,900 --> 00:51:14,000
sustainable business on top of 
the technology. 

1094
00:51:14,200 --> 00:51:16,000
So that's one Trend that I think
will continue. 

1095
00:51:16,500 --> 00:51:19,700
I do think that with the 
explosion in diversity of tools 

1096
00:51:19,700 --> 00:51:22,900
that we're currently looking at 
there, will inevitably be the 

1097
00:51:22,900 --> 00:51:25,700
pendulum swing backwards, a 
little bit into more 

1098
00:51:25,700 --> 00:51:30,700
consolidation, especially around
particular, ecosystems and 

1099
00:51:30,700 --> 00:51:33,200
targeting specific aspects of 
the software development life 

1100
00:51:33,200 --> 00:51:35,200
cycle. 
You'll see essentially like 

1101
00:51:35,200 --> 00:51:38,300
winners and losers to certain 
extent, and the winners will 

1102
00:51:38,300 --> 00:51:40,300
probably buy up some of the 
losers and they'll be some 

1103
00:51:40,300 --> 00:51:42,900
amount of consolidation and 
standardization, but I don't 

1104
00:51:42,900 --> 00:51:45,500
think it will ever go all the 
way back because I think we're 

1105
00:51:45,500 --> 00:51:46,700
really in this. 
World. 

1106
00:51:46,700 --> 00:51:48,700
Right now. 
I think in the old world, the 

1107
00:51:48,700 --> 00:51:52,100
model was you had these 
proprietary vendors that built 

1108
00:51:52,100 --> 00:51:53,300
up. 
These vertically integrated 

1109
00:51:53,300 --> 00:51:56,500
ecosystems that they control, 
they controlled the marketplace.

1110
00:51:56,500 --> 00:51:58,800
They controlled what Partners 
were able to get in front of 

1111
00:51:58,800 --> 00:52:00,900
customers and they control the 
technology stack. 

1112
00:52:01,200 --> 00:52:04,500
Microsoft built out the tech 
stack for Windows and made it a 

1113
00:52:04,500 --> 00:52:06,500
really lucrative environment 
thing. 

1114
00:52:06,900 --> 00:52:09,500
And I don't think that models 
necessarily wrong it obviously 

1115
00:52:09,500 --> 00:52:12,200
yield a lot of value over the 
years, but I think now we've 

1116
00:52:12,200 --> 00:52:16,100
gotten to the point where there 
is no single entity that can 

1117
00:52:16,300 --> 00:52:20,100
Capture all the creativity and 
Innovation that can happen with 

1118
00:52:20,100 --> 00:52:21,800
software and you see that with a
web. 

1119
00:52:21,800 --> 00:52:23,900
Why is the web? 
The platform that appears to 

1120
00:52:23,908 --> 00:52:27,100
have won out over all the 
existing, kind of incumbent 

1121
00:52:27,100 --> 00:52:30,100
desktop operating systems? 
And I think that some of it is 

1122
00:52:30,100 --> 00:52:33,400
tied to the openness of the web.
The fact that it's not under the

1123
00:52:33,400 --> 00:52:37,400
control of any single entity and
that permits this kind of 

1124
00:52:37,400 --> 00:52:41,200
flourishing and diversity of 
ideas that can spring up and 

1125
00:52:41,200 --> 00:52:44,000
find users and use cases. 
That would have been 

1126
00:52:44,000 --> 00:52:46,000
Unthinkable, even a couple years
before. 

1127
00:52:46,000 --> 00:52:48,100
And so I think that's going to 
very much continue. 

1128
00:52:48,400 --> 00:52:50,700
You're going to see the 
continual flourishing of this, 

1129
00:52:50,700 --> 00:52:54,300
like third-party independent 
developer tools ecosystem, 

1130
00:52:54,300 --> 00:52:58,400
that's going to resist complete 
consolidation into that kind of 

1131
00:52:58,400 --> 00:52:59,800
world. 
What's going to become more 

1132
00:52:59,800 --> 00:53:03,300
important are these kind of like
meta tools or aggregators that 

1133
00:53:03,300 --> 00:53:07,300
unify multiple tools into a 
single coherent experience and 

1134
00:53:07,300 --> 00:53:09,700
at some point I think as 
software continues to eat the 

1135
00:53:09,700 --> 00:53:12,800
world as software development 
becomes ubiquitous at some 

1136
00:53:12,800 --> 00:53:14,700
point. 
The devtools market will just 

1137
00:53:14,700 --> 00:53:18,700
become like the Petit tools 
Market because code will become 

1138
00:53:18,700 --> 00:53:22,400
so synonymous with knowledge 
work that the vast majority of 

1139
00:53:22,408 --> 00:53:25,400
people in the economy could be 
building software in some shape 

1140
00:53:25,400 --> 00:53:28,000
or form and that's going to be 
like in this huge vibrant 

1141
00:53:28,000 --> 00:53:31,000
diverse ecosystem. 
The last thing I'll say there is

1142
00:53:31,000 --> 00:53:34,000
that in that explosion of 
different offerings, anytime. 

1143
00:53:34,000 --> 00:53:38,000
You have a large data set or 
Market that explodes like that. 

1144
00:53:38,000 --> 00:53:41,000
I think search is going to be an
incredibly piece of 

1145
00:53:41,000 --> 00:53:44,000
functionality because it's just 
going to be like so many things 

1146
00:53:44,000 --> 00:53:45,800
to consider in a good search 
engine. 

1147
00:53:45,800 --> 00:53:47,700
I think, we'll, I started to 
make sense of it all. 

1148
00:53:48,000 --> 00:53:50,100
And I hope Source. 
Graphing, continue to play a 

1149
00:53:50,100 --> 00:53:52,200
good role. 
They're definitely very 

1150
00:53:52,200 --> 00:53:53,600
exciting. 
You're right. 

1151
00:53:53,600 --> 00:53:55,000
I mean, software is eating the 
world. 

1152
00:53:55,100 --> 00:53:58,400
So more and more people get into
programming writing code, more 

1153
00:53:58,400 --> 00:54:01,200
and more open source, projects 
are being published, and it's 

1154
00:54:01,200 --> 00:54:04,000
going to be tremendously growing
over the time. 

1155
00:54:04,200 --> 00:54:07,400
And I'm sure developer tools 
will be a plenty as well for us 

1156
00:54:07,400 --> 00:54:09,300
to try out. 
And I think, don't forget as 

1157
00:54:09,300 --> 00:54:12,800
well, the code these days is not
just sometimes, impacts, right? 

1158
00:54:12,800 --> 00:54:15,100
There are a lot of audio, 
something like this, or even 

1159
00:54:15,100 --> 00:54:18,200
like videos on Tube. 
I think those probably are some 

1160
00:54:18,200 --> 00:54:20,800
of the opportunities that 
haven't been tapped by people 

1161
00:54:20,800 --> 00:54:23,400
who are teaching tutorials on 
the videos. 

1162
00:54:23,600 --> 00:54:25,700
Maybe sometimes they just want 
to search, which part of the 

1163
00:54:25,700 --> 00:54:28,500
video that actually teach this. 
Maybe it's going to be cool. 

1164
00:54:28,800 --> 00:54:31,300
So thanks so much for sharing 
all these stories. 

1165
00:54:31,400 --> 00:54:33,600
I think due to time, we have to 
cut it out. 

1166
00:54:33,600 --> 00:54:36,200
But before I let you leave, 
normally, I would ask this one 

1167
00:54:36,200 --> 00:54:39,000
question for all my guests to 
share with my audience here, 

1168
00:54:39,200 --> 00:54:41,100
which is the three technical 
leadership wisdom. 

1169
00:54:41,400 --> 00:54:44,300
So being do you have any kind of
wisdom that you want to share 

1170
00:54:44,300 --> 00:54:46,100
with all of us here? 
Yeah. 

1171
00:54:46,600 --> 00:54:50,000
The one piece of advice that I 
got early in my career, as a 

1172
00:54:50,000 --> 00:54:52,500
tech lead or an engineering 
manager that really stuck with 

1173
00:54:52,500 --> 00:54:55,900
me, is when it comes to 
motivating the people on your 

1174
00:54:55,900 --> 00:54:58,600
team and unlocking their 
potential. 

1175
00:54:58,900 --> 00:55:02,700
You always want to start with 
the why aspect of their jobs. 

1176
00:55:03,100 --> 00:55:05,600
So, rather than telling people 
do this, do that. 

1177
00:55:05,600 --> 00:55:09,100
You always want to give them a 
kind of high level goal that 

1178
00:55:09,100 --> 00:55:12,400
they can creatively, use their 
creativity to find a solution 

1179
00:55:12,400 --> 00:55:15,100
to, for a junior engineer. 
That high level goal might be 

1180
00:55:15,100 --> 00:55:18,100
something that is Ultimately 
low-level go and make this 

1181
00:55:18,100 --> 00:55:21,300
button work really well for 
users, but the should always be 

1182
00:55:21,300 --> 00:55:23,900
that component of here is what 
the end goal is. 

1183
00:55:24,100 --> 00:55:27,400
And I do not care how you do it.
That's up to you to figure out. 

1184
00:55:27,408 --> 00:55:31,400
That's up to you, to exercise, 
your human brain and creative 

1185
00:55:31,400 --> 00:55:34,000
inspiration to figure out how 
best to solve that problem. 

1186
00:55:34,200 --> 00:55:38,200
Because I think that Creative 
Drive is what motivates every 

1187
00:55:38,200 --> 00:55:39,400
developer. 
It's like why we got into 

1188
00:55:39,400 --> 00:55:41,800
programming, right? 
That Act of Creation, that 

1189
00:55:41,800 --> 00:55:45,300
active creative problem solving,
I think, oftentimes especially 

1190
00:55:45,300 --> 00:55:48,300
as the organization Rose and 
you're trying to solve these 

1191
00:55:48,300 --> 00:55:50,700
bigger problems and you're 
solving them by breaking them 

1192
00:55:50,700 --> 00:55:53,900
down into smaller bits can be 
very easy to just become more 

1193
00:55:53,900 --> 00:55:57,500
prescriptive or more imperative 
when it comes to telling people 

1194
00:55:57,500 --> 00:56:01,500
what they need to do, but what I
found works for both myself and 

1195
00:56:01,500 --> 00:56:04,700
the people I work with is always
keeping that goal in a way that 

1196
00:56:04,700 --> 00:56:07,300
the person actually, satisfying 
that goal is able to work 

1197
00:56:07,300 --> 00:56:09,100
creatively. 
That's good advice. 

1198
00:56:09,200 --> 00:56:11,400
I would say for both, like tech 
leads when you're talking to 

1199
00:56:11,400 --> 00:56:14,100
others and explaining a problem 
that you want them to solve. 

1200
00:56:14,200 --> 00:56:16,800
And for the person who's 
receiving that If your manager 

1201
00:56:16,800 --> 00:56:19,900
is explaining this problem to 
you, ask the questions about 

1202
00:56:19,900 --> 00:56:23,600
what is the end desired State 
here rather than just taking 

1203
00:56:23,600 --> 00:56:25,800
down the orders. 
Because I think that will 

1204
00:56:25,800 --> 00:56:29,100
ultimately help you do your job 
better and lead to a happier 

1205
00:56:29,100 --> 00:56:31,800
manager because you've done a 
better job, he found a more 

1206
00:56:31,800 --> 00:56:34,200
creative solution to the problem
that you were asked to solve. 

1207
00:56:34,500 --> 00:56:37,600
I think another piece of advice 
is, if you find yourself doing 

1208
00:56:37,600 --> 00:56:41,100
anything twice that you don't 
like, doing find a way to 

1209
00:56:41,100 --> 00:56:43,300
automate it or look for a tool 
that automates. 

1210
00:56:43,300 --> 00:56:46,700
It that is your kind of job as a
programmer is to Make things. 

1211
00:56:46,700 --> 00:56:49,700
And if you're not automating 
your own life, then you're not 

1212
00:56:49,700 --> 00:56:53,600
living your own values. 
And then, lastly, just remember 

1213
00:56:53,600 --> 00:56:56,100
to have fun. 
It's amazing that we get to work

1214
00:56:56,100 --> 00:56:58,900
in a job like this because 
coding is so fun. 

1215
00:56:58,900 --> 00:57:02,000
You get to create these like 
applications that are used by 

1216
00:57:02,000 --> 00:57:04,900
dozens or hundreds or thousands 
or maybe sometimes you millions 

1217
00:57:04,900 --> 00:57:07,800
of users and you get to do all 
that just by sitting at your 

1218
00:57:07,800 --> 00:57:09,900
desk and typing things into a 
computer. 

1219
00:57:10,400 --> 00:57:12,600
I think that there's a lot of 
complexity to deal with 

1220
00:57:12,800 --> 00:57:15,300
professional software. 
Engineering is there's a lot of 

1221
00:57:15,300 --> 00:57:17,400
people issues. 
Shoes, there's a lot of 

1222
00:57:17,400 --> 00:57:20,400
understanding existing context. 
There's a lot of slog to the 

1223
00:57:20,400 --> 00:57:22,400
job. 
But I think at the end of the 

1224
00:57:22,400 --> 00:57:26,000
day, the best way to make 
yourself, do a good job and also

1225
00:57:26,000 --> 00:57:28,700
not get overwhelmed by the 
complexity of deal with. 

1226
00:57:28,700 --> 00:57:31,800
Is to remember what got you into
program in the first place? 

1227
00:57:32,100 --> 00:57:35,600
Focus on that, and try to 
experience that as many times 

1228
00:57:35,600 --> 00:57:39,100
per day as possible because I 
think, if you do that, it will 

1229
00:57:39,100 --> 00:57:42,100
drive you to focus on more of 
the creative aspects of the job.

1230
00:57:42,200 --> 00:57:44,900
It will also motivate you to 
automate the more mundane or 

1231
00:57:44,900 --> 00:57:47,500
wrote aspects of the job. 
And it'll just make you a 

1232
00:57:47,500 --> 00:57:49,900
happier person, because it'll 
feel like you're doing something

1233
00:57:49,900 --> 00:57:52,500
that's truly exercises. 
The human creative aspects of 

1234
00:57:52,500 --> 00:57:54,500
your brain. 
Thanks for sharing the wisdom. 

1235
00:57:54,500 --> 00:57:57,100
I like the last one. 
Definitely, we all got into 

1236
00:57:57,100 --> 00:57:59,800
programming because of something
something that's, you know, 

1237
00:57:59,800 --> 00:58:02,100
spark when we try it, writing 
some code and something 

1238
00:58:02,100 --> 00:58:05,100
magically happen. 
I think it's also synonymous 

1239
00:58:05,100 --> 00:58:07,500
with the productivity concept of
a developer, right? 

1240
00:58:07,600 --> 00:58:09,600
When you are productive. 
Basically, you can generate 

1241
00:58:09,600 --> 00:58:12,100
code, that actually works, may 
be impacted many part of 

1242
00:58:12,107 --> 00:58:15,700
people's lives, but I think we 
have to be conscious over the 

1243
00:58:15,700 --> 00:58:17,700
time. 
Let's say we don't enjoy what we

1244
00:58:17,707 --> 00:58:19,400
are doing the programming 
things. 

1245
00:58:19,400 --> 00:58:22,300
Maybe the productivity goes down
and we are not having fun. 

1246
00:58:22,600 --> 00:58:26,200
So you always have to look back 
and think what got you into the 

1247
00:58:26,200 --> 00:58:29,000
programming in the first place. 
So thanks again for your time. 

1248
00:58:29,000 --> 00:58:32,100
Being for people who wants to 
find you online or learn more 

1249
00:58:32,100 --> 00:58:34,100
about social graph. 
Do you have a place where they 

1250
00:58:34,100 --> 00:58:37,100
can go to? 
Yeah, first graph just go to 

1251
00:58:37,100 --> 00:58:39,400
short script that calm you 
should be able to search over 

1252
00:58:39,400 --> 00:58:43,500
all the open source code from 
that URL or you can download and

1253
00:58:43,500 --> 00:58:45,300
run your own source graph 
instance. 

1254
00:58:45,600 --> 00:58:47,400
And for me. 
Probably the best place to reach

1255
00:58:47,400 --> 00:58:51,000
me is just on Twitter. 
I'm at biamby ey A and G. 

1256
00:58:51,000 --> 00:58:54,600
Feel free to reach out or DM me 
or tweet at me or whatever you 

1257
00:58:54,600 --> 00:58:57,200
like cool. 
So, thanks again Beyond. 

1258
00:58:57,200 --> 00:59:00,300
I hope one day I would be able 
to use your tools in my 

1259
00:59:00,300 --> 00:59:02,500
development workflow, and it 
will be great. 

1260
00:59:02,500 --> 00:59:05,000
I think to have all these 
superpowers for developer. 

1261
00:59:05,500 --> 00:59:07,300
Awesome. 
Thank you, Henry, and thank you 

1262
00:59:07,300 --> 00:59:09,000
so much for having me. 
This is great. 

1263
00:59:11,100 --> 00:59:14,500
Thank you for listening to this 
episode and for staying right 

1264
00:59:14,500 --> 00:59:17,400
till the end. 
If you highly enjoyed, please 

1265
00:59:17,400 --> 00:59:20,200
share it with your friends and 
colleagues who you think would 

1266
00:59:20,200 --> 00:59:23,000
also benefit from listening to 
this episode. 

1267
00:59:23,200 --> 00:59:26,100
And if you're new to the 
podcast, make sure to subscribe 

1268
00:59:26,100 --> 00:59:29,000
and leave me your valuable 
review and feedback. 

1269
00:59:29,100 --> 00:59:32,800
It really, really helps me a lot
in order to grow these podcasts 

1270
00:59:32,800 --> 00:59:35,400
better. 
You can also find the full show 

1271
00:59:35,400 --> 00:59:38,900
notes of this conversation on 
the episode page at technology. 

1272
00:59:38,900 --> 00:59:42,300
No, the death website. 
Including the full transcript 

1273
00:59:42,300 --> 00:59:45,900
interesting quotes, and links to
the resources and mentions from 

1274
00:59:45,900 --> 00:59:48,700
the conversation. 
And lastly make sure to 

1275
00:59:48,700 --> 00:59:52,100
subscribe to the show's mailing 
list on technology node are deaf

1276
00:59:52,100 --> 00:59:54,700
to get notified for any future 
episodes. 

1277
00:59:55,000 --> 00:59:57,700
Stay tuned for the next 
technique Journal episode. 

1278
00:59:57,800 --> 00:59:59,400
And until then. 
Goodbye.