WEBVTT 1 00:00:05.759 --> 00:00:08.640 Hey everybody, and welcome back to another episode of the 2 00:00:08.800 --> 00:00:11.400 Ruby Rogues podcast. This week, on our panel we have 3 00:00:11.560 --> 00:00:16.480 Dave Kamura everyone. We also have Luke Stutters Hello, Charles 4 00:00:16.519 --> 00:00:18.839 Maxwood from dev chat dot tv. And this week we 5 00:00:18.879 --> 00:00:22.120 have a special guest and that is Mason mclead. 6 00:00:22.440 --> 00:00:24.320 Hey everyone, and thanks for having me on. Yeah. 7 00:00:24.399 --> 00:00:26.039 Now, we've had you on a couple of other shows. 8 00:00:26.039 --> 00:00:29.839 We've been talking about basically getting more done. I'm kind 9 00:00:29.839 --> 00:00:31.879 of curious as we dive in first, you want to 10 00:00:31.879 --> 00:00:33.359 just give a little bit more of an introduction. 11 00:00:33.439 --> 00:00:36.799 I kind of lost over all the cool stuff. 12 00:00:36.560 --> 00:00:38.880 You're doing at software dot com and all the tools 13 00:00:38.880 --> 00:00:40.600 that you provide to people and things like that, as 14 00:00:40.640 --> 00:00:41.679 well as the research that. 15 00:00:41.640 --> 00:00:43.039 You're doing on productivity. 16 00:00:43.439 --> 00:00:45.679 But yeah, you want to just give us the quick 17 00:00:45.679 --> 00:00:47.200 elevator pitch and then we can dive in. 18 00:00:47.759 --> 00:00:48.079 Sure. 19 00:00:48.439 --> 00:00:52.359 Yeah, So, Mason, I'm CTO at Software dot Com. We 20 00:00:52.439 --> 00:00:58.159 make tools for developers and it's all around time tracking 21 00:00:58.320 --> 00:01:02.520 and efficiency and productivity. So the core thing that we 22 00:01:02.600 --> 00:01:06.760 do is track telemetry about how you code and give 23 00:01:06.760 --> 00:01:09.400 you that feedback and that observeability about how the development 24 00:01:09.480 --> 00:01:11.599 process is working for your team and for you as 25 00:01:11.640 --> 00:01:16.319 an individual, and we also got editor extensions across all 26 00:01:16.359 --> 00:01:19.920 the main editors that give you access to that data 27 00:01:20.239 --> 00:01:23.040 right and line. And also we have a tool called 28 00:01:23.120 --> 00:01:26.400 flow Mode which connects to Slack and your calendar and 29 00:01:26.519 --> 00:01:29.640 starts to block out times whenever you're coding so that 30 00:01:29.680 --> 00:01:32.799 you don't get distracted, because I think everyone's had that 31 00:01:32.879 --> 00:01:35.799 feeling where you finally get into the zone like you've 32 00:01:35.840 --> 00:01:37.359 got everything in your head and then you get a 33 00:01:37.359 --> 00:01:40.959 bunch of Slack messages or meetings coming up, and then 34 00:01:41.000 --> 00:01:45.040 you lose it all, and that's really valuable time that's 35 00:01:45.120 --> 00:01:47.760 then lost. So we've got tools to help you do that. 36 00:01:48.319 --> 00:01:50.879 And a lot of the research that we're doing is 37 00:01:51.519 --> 00:01:56.159 looking at the impact analysis of meeting time versus how 38 00:01:56.239 --> 00:02:00.480 people can get stuff done during the day, which is 39 00:02:00.599 --> 00:02:03.400 also leading cause of why developers work at night a 40 00:02:03.400 --> 00:02:07.000 lot of the times or on weekends. And then the 41 00:02:07.040 --> 00:02:12.520 impact of other distractions like Slack and meeting sorry, working 42 00:02:12.520 --> 00:02:15.639 at the office versus working remote when that is an 43 00:02:15.680 --> 00:02:19.159 option depending on what country you're in, And yeah, all 44 00:02:19.199 --> 00:02:21.560 sorts of other stuff going into that. So a lot 45 00:02:21.560 --> 00:02:24.360 of really interesting data that we can see and a 46 00:02:24.360 --> 00:02:27.919 lot of assumptions that people have that can be proven 47 00:02:27.960 --> 00:02:30.840 correct through the data or actually debunked, which is I 48 00:02:30.919 --> 00:02:32.599 think a really interesting part of it as well. 49 00:02:32.919 --> 00:02:34.719 Right, And like I said, you know, we had your 50 00:02:34.759 --> 00:02:37.520 on Adventures in DevOps, we had you on I can't 51 00:02:37.560 --> 00:02:39.400 remember which of the other shows we talked to you on, 52 00:02:39.479 --> 00:02:42.439 but most of those conversations kind of went the same 53 00:02:42.560 --> 00:02:45.360 kinds of ways. I'm a little curious as we dive 54 00:02:45.439 --> 00:02:49.719 into this with Ruby Rogues, are there are there things 55 00:02:49.759 --> 00:02:51.759 that we didn't get to in the other shows that 56 00:02:51.800 --> 00:02:54.159 we we could talk about here and then maybe we 57 00:02:54.199 --> 00:02:57.199 can circle back around to kind of the big ideas 58 00:02:57.240 --> 00:02:59.159 that we got to on the other shows that are 59 00:02:59.199 --> 00:02:59.919 going to help folks. 60 00:03:00.439 --> 00:03:05.240 Well, there was something that I actually found out yesterday 61 00:03:05.280 --> 00:03:10.680 with my data scientist and breaking news breaking top line 62 00:03:10.719 --> 00:03:15.319 research here. So I was looking at what we've got 63 00:03:15.400 --> 00:03:18.120 certain measures that we see in the data, and we'll 64 00:03:18.199 --> 00:03:21.879 be able to mark sessions of your coding. We have 65 00:03:21.919 --> 00:03:24.199 a thing called code time, which is when you're in 66 00:03:24.240 --> 00:03:27.280 the editor, you're looking at files, you're doing research, not 67 00:03:27.319 --> 00:03:30.599 necessarily editing the code. And then we have a section 68 00:03:30.680 --> 00:03:33.000 of time called active code time, which is when you're 69 00:03:33.560 --> 00:03:37.039 actively editing. And so one things you can do when 70 00:03:37.039 --> 00:03:39.319 you've got those is look at the ratio that people 71 00:03:39.400 --> 00:03:42.960 spend in the day of how much of their code 72 00:03:43.000 --> 00:03:47.199 time is also active code time, which is kind of 73 00:03:47.240 --> 00:03:51.000 a proxy for focus in the time that it takes 74 00:03:51.000 --> 00:03:54.879 for them to ramp up to productivity in that session. 75 00:03:55.479 --> 00:03:58.280 So how long does it of reading does it take 76 00:03:58.520 --> 00:04:00.919 to get you into editing? And I was looking at 77 00:04:00.919 --> 00:04:05.120 that per day of week and found that for that 78 00:04:05.280 --> 00:04:11.159 particular ratio, Saturday is the most focused day that developers have, 79 00:04:11.280 --> 00:04:16.600 so of developers that code on the weekend, Saturday has 80 00:04:16.720 --> 00:04:20.560 a far higher kind of focus factor than any day 81 00:04:20.600 --> 00:04:24.279 of the week, although Tuesday is a close runner up. 82 00:04:24.800 --> 00:04:28.120 So from that I think we'll be able to dive 83 00:04:28.160 --> 00:04:31.000 further into it, like, Okay, why is that the way 84 00:04:31.000 --> 00:04:33.360 it is? But just on the observation and kind of 85 00:04:33.399 --> 00:04:36.720 the assumption that you have about Saturdays and tuesdays, there's 86 00:04:36.800 --> 00:04:40.199 less people bothering you, there's less meetings, there's less messages, 87 00:04:40.920 --> 00:04:43.480 and so if you want to work on Saturday and 88 00:04:43.480 --> 00:04:46.040 that works for your lifestyle, great, it seems to be 89 00:04:46.120 --> 00:04:48.160 a good one. If you don't, and that's just a 90 00:04:48.240 --> 00:04:52.240 byproduct of you not having gotten stuff done during the week. 91 00:04:52.279 --> 00:04:53.639 Because you're distracted all the time. 92 00:04:53.959 --> 00:04:57.000 It's like, how do you make a Saturday like environment 93 00:04:57.720 --> 00:05:00.000 during the week so that you can have that same 94 00:05:00.040 --> 00:05:03.879 amount of focus to be as productive on those days? 95 00:05:03.879 --> 00:05:08.079 And like, those are some of the small behavioral shifts 96 00:05:08.480 --> 00:05:12.160 that you can start to put into your work week 97 00:05:12.199 --> 00:05:15.759 as a team and as an individual so that you 98 00:05:15.800 --> 00:05:18.720 can get more focus work done during the week and 99 00:05:18.720 --> 00:05:21.439 then actually take time off because you're a person as well, 100 00:05:22.360 --> 00:05:24.279 and do you need to do other things? 101 00:05:24.519 --> 00:05:27.560 I got a question for you here, So as a 102 00:05:27.639 --> 00:05:30.279 understanding it a soult dot com, you've got loads of 103 00:05:30.279 --> 00:05:32.680 really cool tools that can kind of look at people's 104 00:05:32.720 --> 00:05:37.879 commits or some other metric you're looking at to assess productivity. 105 00:05:38.680 --> 00:05:42.480 Yeah, so we've got several metrics that go into it, 106 00:05:42.560 --> 00:05:46.279 and in the coming weeks we'll have it all connected 107 00:05:46.319 --> 00:05:48.879 to get commits and those sorts of things. We're doing 108 00:05:48.920 --> 00:05:52.000 that internally right now, just kind of refining the product 109 00:05:52.040 --> 00:05:54.920 before we put it out there where we can look 110 00:05:54.959 --> 00:05:57.319 at Like if you if you kind of arrange how 111 00:05:57.360 --> 00:06:02.160 development works in line of kind of a physical factory, 112 00:06:02.199 --> 00:06:04.160 it's not the same because you're not recreating the same 113 00:06:04.160 --> 00:06:05.160 thing over and over again. 114 00:06:05.199 --> 00:06:06.399 It's a creative endeavor. 115 00:06:06.480 --> 00:06:09.680 But right if you kind of look at it that 116 00:06:09.720 --> 00:06:12.759 way as a metaphor and say, there's all these inputs 117 00:06:12.800 --> 00:06:16.639 that go into it, and that for us is the time, 118 00:06:17.480 --> 00:06:20.439 the amount of characters and lines, and like just the 119 00:06:20.560 --> 00:06:23.480 raw materials that go into it, and then you look 120 00:06:23.480 --> 00:06:27.639 at the outputs. And I think so far the best 121 00:06:27.800 --> 00:06:30.600 sort of abstraction for what an output a unit of 122 00:06:30.680 --> 00:06:33.439 output is is a merged pull request. It's a chunk 123 00:06:33.439 --> 00:06:37.040 of work that someone has thought is enough to stand 124 00:06:37.079 --> 00:06:39.800 on its own, and it's good enough gone through quality 125 00:06:39.879 --> 00:06:42.399 checks to get merged into the default branch, which would 126 00:06:42.439 --> 00:06:46.160 then go to production. So those are the inputs and 127 00:06:46.199 --> 00:06:49.000 the outputs of this factory. And if you look at 128 00:06:49.000 --> 00:06:53.959 the traditional definition of efficiency and productivity, it's how much 129 00:06:54.000 --> 00:06:57.720 input does it take to get to some unit of output. 130 00:06:58.079 --> 00:06:59.920 So as soon as you have that, now you've got 131 00:07:00.120 --> 00:07:05.639 the full view of the development cycle, what is going in, 132 00:07:05.800 --> 00:07:07.759 what is coming out, and you can start to get 133 00:07:07.800 --> 00:07:11.600 a lot of really interesting measurements about the overall system 134 00:07:11.959 --> 00:07:14.839 and then each of the steps along the way. So 135 00:07:15.439 --> 00:07:18.560 when you hear about things like cycle time, which is 136 00:07:19.160 --> 00:07:22.639 typically when someone's looking at at that from another tool, 137 00:07:22.680 --> 00:07:25.600 they're looking at when the commit was pushed to when 138 00:07:25.639 --> 00:07:26.319 it was merged. 139 00:07:27.000 --> 00:07:29.879 And I don't know how how you like to commit. 140 00:07:30.000 --> 00:07:33.240 People do it differently, but I usually code nearly all 141 00:07:33.279 --> 00:07:36.360 of everything before I do the first commit, and then 142 00:07:36.399 --> 00:07:38.319 I commit, make a PR, push it, and then I'll 143 00:07:38.319 --> 00:07:40.879 get feedback and maybe you make some changes. But the 144 00:07:40.920 --> 00:07:44.319 bulk of the work of the input side is before 145 00:07:44.439 --> 00:07:48.000 that first commit, which is completely missed by these other tools. 146 00:07:48.360 --> 00:07:51.240 And it also gives you a like, depending on how 147 00:07:51.279 --> 00:07:55.360 your behavior is, it gives you a false number about 148 00:07:55.360 --> 00:07:57.720 what your cycle speed is when really there's this. 149 00:07:57.920 --> 00:07:59.920 Doesn't order to work and that one committed to stuff. 150 00:08:00.439 --> 00:08:05.199 Yeah, exactly. So getting a realistic number and just observing 151 00:08:06.000 --> 00:08:09.519 what the team is actually doing gives you an empowerment 152 00:08:09.600 --> 00:08:11.839 to go and actually make positive changes to it. And 153 00:08:11.879 --> 00:08:13.920 that's really at the core of it. This is what 154 00:08:13.959 --> 00:08:14.720 this is about. 155 00:08:14.920 --> 00:08:18.000 I went on code Climate the up day wasn't my idea, 156 00:08:18.079 --> 00:08:20.040 my colleagues did, and it gave my code a D 157 00:08:20.560 --> 00:08:22.240 and quite honestly, that kind of put me off on 158 00:08:22.240 --> 00:08:24.560 all of these kind of co assessment tools. I'm now 159 00:08:24.560 --> 00:08:26.519 a bit scared that if you've got a software dot 160 00:08:26.560 --> 00:08:28.879 com and show to my work. They'll say that, you know, 161 00:08:29.439 --> 00:08:32.559 Looke's only productive on like Tuesday morning, and even then 162 00:08:32.600 --> 00:08:35.559 it doesn't do much work. Is this it sounds like 163 00:08:35.559 --> 00:08:37.879 a great tool for managers. Is it going to help 164 00:08:38.360 --> 00:08:41.080 the software grunts the frontline cod is like me. 165 00:08:41.679 --> 00:08:44.480 Yeah, I think that is a really interesting point. That's 166 00:08:44.480 --> 00:08:47.200 something that we think about a lot, and you're right 167 00:08:47.200 --> 00:08:49.720 about you know, co climate or any of those other tools. 168 00:08:49.799 --> 00:08:55.000 They do have a very manager first approach to it all, 169 00:08:55.519 --> 00:08:59.480 which is something that we actively avoid. So first of 170 00:08:59.480 --> 00:09:03.159 all with with our tools, and I think everyone should 171 00:09:03.159 --> 00:09:07.159 do this, is that we don't show individual data to 172 00:09:07.240 --> 00:09:08.600 anyone except that individual. 173 00:09:09.000 --> 00:09:10.919 If the team is looking at the data, they see. 174 00:09:10.840 --> 00:09:15.679 Aggregated anonymized data at the team level, so the team 175 00:09:15.759 --> 00:09:19.840 is an object or an entity that is creating code 176 00:09:19.879 --> 00:09:24.639 together and looking at it at individual parts is not 177 00:09:24.759 --> 00:09:27.200 as helpful for the metrics that you would actually want 178 00:09:27.200 --> 00:09:32.759 to track, and that's really a manager task to do. 179 00:09:32.799 --> 00:09:34.879 And I don't think automating that out to a bunch 180 00:09:34.919 --> 00:09:38.279 of stats is a healthy or productive thing to do. 181 00:09:38.879 --> 00:09:41.200 By mix stats like that's what we do, I don't 182 00:09:41.200 --> 00:09:43.480 think it's right for that. It could be a supplement, 183 00:09:44.120 --> 00:09:47.559 but it doesn't replace being a manager. And yeah, so 184 00:09:48.120 --> 00:09:50.559 for us, we only show the individual data to the 185 00:09:50.600 --> 00:09:53.679 individual so that they can see it for themselves. And 186 00:09:53.720 --> 00:09:55.799 then the thing that I'm really proud of is that 187 00:09:55.840 --> 00:10:00.639 we have the what we call editor ops tools extensions 188 00:10:00.639 --> 00:10:02.960 that are running in your editor. So just like chat 189 00:10:02.960 --> 00:10:06.360 ops brought a lot of automations and cool stuff into 190 00:10:06.759 --> 00:10:10.000 Slack or whatever, we bring that into the editor so 191 00:10:10.039 --> 00:10:12.759 that you can start to control your environment from there 192 00:10:12.799 --> 00:10:15.519 without context switching. Like we have an extension called music 193 00:10:15.559 --> 00:10:19.240 Time that allows you to control your Spotify from the 194 00:10:19.360 --> 00:10:22.720 editor with like keyboard shortcuts or some clicks. And it 195 00:10:22.759 --> 00:10:26.440 also shows you in a correlative sort of way, what 196 00:10:26.480 --> 00:10:29.480 are the most productive songs that you listen to or 197 00:10:29.519 --> 00:10:31.480 genres and like what. 198 00:10:32.200 --> 00:10:34.480 A code with Alice Cooper. 199 00:10:34.200 --> 00:10:38.000 On So you can check software dot Com slash Top 200 00:10:38.039 --> 00:10:40.919 forty we have the top forty songs ranked by productivity 201 00:10:40.919 --> 00:10:45.559 for the week and crazy sometimes like Alison Alis will 202 00:10:45.600 --> 00:10:50.120 be on there. It depends on what data we get 203 00:10:50.159 --> 00:10:53.960 for that week. It's always updating every week and that 204 00:10:54.080 --> 00:10:56.440 you can see it for yourself, like mine is my 205 00:10:56.840 --> 00:10:59.840 best genre is on a second edge. 206 00:11:00.240 --> 00:11:03.840 Ed Sharing's in the top three good God. 207 00:11:04.320 --> 00:11:05.000 You know what. 208 00:11:05.080 --> 00:11:07.600 I what I think it is, and I don't have 209 00:11:07.679 --> 00:11:09.879 the data yet to prove it. I think it's there's 210 00:11:10.840 --> 00:11:13.799 songs that are really familiar and you've heard a billion times, 211 00:11:14.120 --> 00:11:16.919 so you don't have to actively think about what's going on. 212 00:11:17.080 --> 00:11:20.440 Is just in the background, and it's the smooth tones 213 00:11:20.559 --> 00:11:24.720 of Ed Sheeran. Then it allows you to kind of 214 00:11:25.600 --> 00:11:28.000 mute out everything else and that takes the place of 215 00:11:28.080 --> 00:11:31.360 background noise, and then you can have your mind available 216 00:11:31.360 --> 00:11:34.000 to focus. And I think whenever you see that, like, 217 00:11:34.039 --> 00:11:36.879 it's not always new songs. Although popular songs tend to 218 00:11:36.919 --> 00:11:38.879 rise up because the people listen to them, but a 219 00:11:38.879 --> 00:11:40.840 lot of older songs as well that people have listened 220 00:11:40.879 --> 00:11:43.600 to many many times and it's just their go to 221 00:11:43.879 --> 00:11:48.519 thing in order to get into the zone. 222 00:11:49.840 --> 00:11:51.679 I do have to push back a little bit because 223 00:11:51.720 --> 00:11:54.799 the number twenty four slot is the real slim shady. 224 00:11:55.399 --> 00:11:58.080 I don't know how well my coding would go if 225 00:11:58.080 --> 00:12:01.759 I'm listening to that Eminem's bat or anything, but that's 226 00:12:01.759 --> 00:12:05.279 on in particular. I just I'm sorry, I don't have 227 00:12:05.360 --> 00:12:06.399 the full buy in yet. 228 00:12:08.159 --> 00:12:11.039 He just had me at Emacs Spotify. I'm just saying 229 00:12:13.320 --> 00:12:14.639 control X control play. 230 00:12:14.879 --> 00:12:18.120 But yeah, whatever I do have to say though that 231 00:12:18.240 --> 00:12:20.720 I mean, it's it's interesting, right, these are all things 232 00:12:20.720 --> 00:12:23.000 that you measure or don't measure. I also just want 233 00:12:23.000 --> 00:12:25.759 to back up to the kind of the team stats, right, 234 00:12:25.840 --> 00:12:28.600 because there are a couple of things. One is that 235 00:12:28.679 --> 00:12:35.200 my team were wepair or mob everything, and so measuring 236 00:12:35.320 --> 00:12:37.720 that kind of productivity. I may not be the person 237 00:12:37.720 --> 00:12:40.759 who's actually even in the editor, right, I may be 238 00:12:41.480 --> 00:12:45.120 participating over the call or pushing you know, I may 239 00:12:45.200 --> 00:12:47.080 put the pr together, but none of the commits are 240 00:12:47.080 --> 00:12:50.799 actually commits that came off of my machine, like excuse 241 00:12:50.879 --> 00:12:52.039 like that, which. 242 00:12:52.519 --> 00:12:55.159 Maybe it could be. 243 00:12:55.799 --> 00:12:59.480 But my point is is that by measuring the velocity 244 00:12:59.519 --> 00:13:01.399 of the team, or measuring the output of the team, 245 00:13:01.440 --> 00:13:04.440 measuring the team as a whole. If I'm out for 246 00:13:04.519 --> 00:13:06.919 a week, they can see what the impact is, right, 247 00:13:07.360 --> 00:13:08.919 or somebody else is out for the week, they can 248 00:13:08.960 --> 00:13:13.399 see what the impact is even if they're not seeing specifically. Oh, 249 00:13:13.519 --> 00:13:16.080 there are fewer commits by Chuck or fewer commits by 250 00:13:16.080 --> 00:13:18.840 one of the other guys, right, Yeah. 251 00:13:18.200 --> 00:13:20.399 And even just looking at the metrics at the team 252 00:13:20.480 --> 00:13:26.840 level aligns with the purpose and virtues of pair or 253 00:13:26.879 --> 00:13:30.279 mob programming where you're doing this as a team. It's 254 00:13:30.320 --> 00:13:33.320 not a bunch of individuals writing a bunch of different code. 255 00:13:33.440 --> 00:13:38.000 It's everyone coming together to do this and measuring the 256 00:13:38.240 --> 00:13:41.320 velocity and the lead time and the throughput at that 257 00:13:41.519 --> 00:13:44.360 level seems to me to be the right level to 258 00:13:44.440 --> 00:13:44.919 do it at. 259 00:13:45.159 --> 00:13:47.240 Well, I've been on teams where we didn't pair, right, 260 00:13:47.279 --> 00:13:49.919 We didn't pair, we didn't mob, We just do the work. 261 00:13:49.960 --> 00:13:54.320 But we were still collaborating, collaborating, collaborated to dating whatever. 262 00:13:54.879 --> 00:13:56.679 We were still talking to each other about what we 263 00:13:56.679 --> 00:13:59.200 were working on. We were still Hey, I'm stuck on this. 264 00:13:59.240 --> 00:14:00.000 Can you help me out? 265 00:14:00.320 --> 00:14:02.639 Hey? How does this go together so that I can 266 00:14:02.679 --> 00:14:03.720 integrate with it? Hey? 267 00:14:03.799 --> 00:14:06.960 How does this going to get integrated on CI? How 268 00:14:07.039 --> 00:14:09.200 is this going to get come together when we deploy it? 269 00:14:09.679 --> 00:14:11.840 Hey? You know, how does this work? Hey? 270 00:14:11.840 --> 00:14:14.399 Do you know a good algorithm to solve this particular problem? 271 00:14:14.759 --> 00:14:18.080 And so there's always going to be interplay between the 272 00:14:18.120 --> 00:14:21.200 members of the team, whether you have them sitting together 273 00:14:21.440 --> 00:14:26.600 or on a zoom or teams or skype call. And 274 00:14:27.480 --> 00:14:30.000 so the reality is is if you're not measuring it 275 00:14:30.000 --> 00:14:33.200 as a team, you're not measuring all of that other stuff, 276 00:14:33.240 --> 00:14:37.720 and you're going to miss really a big part of 277 00:14:37.720 --> 00:14:40.279 how this all kind of comes together, because at the 278 00:14:40.320 --> 00:14:42.159 end of the day, everything that I'm working on, and 279 00:14:42.200 --> 00:14:44.440 everything that you're working on, and everything that everybody else 280 00:14:44.480 --> 00:14:47.720 is working on on this particular app or set of apps, 281 00:14:48.679 --> 00:14:52.360 it all goes into the same bucket, and we're all 282 00:14:52.360 --> 00:14:56.200 measuring that progress on the same rubric. 283 00:14:56.360 --> 00:14:57.519 Yeah, exactly. 284 00:14:57.559 --> 00:15:01.519 And if you took that case where you and your 285 00:15:02.600 --> 00:15:05.840 other half of the pair have been programming for two 286 00:15:05.919 --> 00:15:10.879 weeks on a particular sprint and the other person's always 287 00:15:10.879 --> 00:15:15.200 been the typest in that case, then if you're looking 288 00:15:15.320 --> 00:15:19.279 at the way that other tools traditionally do this, where 289 00:15:19.320 --> 00:15:22.480 it's per person, you're going to see one person did 290 00:15:22.480 --> 00:15:25.679 everything and the other person did nothing based on who 291 00:15:25.799 --> 00:15:29.039 committed what, and that wasn't the case at all. Like, 292 00:15:29.120 --> 00:15:31.960 this is definitely a team effort, and so if you've 293 00:15:32.039 --> 00:15:35.879 just abstracted away to the proper level, then you don't 294 00:15:35.919 --> 00:15:39.039 fall into that trap of having this false stack rank 295 00:15:39.759 --> 00:15:43.799 of individuals assuming that they're all doing their own individual stuff, 296 00:15:43.840 --> 00:15:47.200 which is never the case when you're on a team 297 00:15:47.240 --> 00:15:51.080 that's working well together. And the communication side of it 298 00:15:51.120 --> 00:15:54.679 is a it's kind of an invisible and I think 299 00:15:54.759 --> 00:15:59.000 undervalued in a lot of times aspect of team building, 300 00:15:59.720 --> 00:16:03.159 that that really you'll see the effects of it when 301 00:16:03.159 --> 00:16:05.600 it's going well at the team level, but you can't 302 00:16:05.600 --> 00:16:06.799 really see it if you just look at all the 303 00:16:06.840 --> 00:16:08.240 individuals by themselves. 304 00:16:08.519 --> 00:16:11.360 I've never tried or looked into this because I never 305 00:16:11.399 --> 00:16:15.279 had to need to. But within get or get hub, 306 00:16:15.320 --> 00:16:20.080 whatever version control and methodology you're using, can you assign 307 00:16:20.159 --> 00:16:23.840 multiple authors to single commit, which would then in turn 308 00:16:23.960 --> 00:16:25.879 maybe solve that issue. 309 00:16:26.080 --> 00:16:29.000 Since we've been digging into this a lot, there's a 310 00:16:29.039 --> 00:16:32.000 big difference between what get by itself is and what 311 00:16:32.120 --> 00:16:36.879 get hub or bitbucket does on top. Yeah, like get 312 00:16:37.039 --> 00:16:43.080 itself is this wild web of there is no default. Well, actually, 313 00:16:43.519 --> 00:16:45.159 I think in the newest version there is now the 314 00:16:45.200 --> 00:16:48.600 concept of a default branch. In get itself. All of 315 00:16:48.639 --> 00:16:52.159 the structure and the hierarchy that makes it really workable 316 00:16:52.200 --> 00:16:55.080 at scale came from the providers on top of it, 317 00:16:55.679 --> 00:16:58.039 which I found really interesting because I was trying to 318 00:16:58.240 --> 00:16:59.840 just figure it out at the get level and it's 319 00:16:59.879 --> 00:17:03.159 just it's really really difficult because it's designed to be 320 00:17:03.919 --> 00:17:07.960 very widespread and non hierarchical, so that it can be 321 00:17:08.119 --> 00:17:09.400 as scalable as it is. 322 00:17:10.039 --> 00:17:11.039 Get hub or bitbucket. 323 00:17:11.079 --> 00:17:15.000 You'd be able to have multiple authors on a pull request. 324 00:17:15.079 --> 00:17:18.839 It's kind of their main object. In the commit level itself, 325 00:17:18.880 --> 00:17:22.000 you've got an author and a committer. They can be 326 00:17:22.079 --> 00:17:25.440 the same they usually are, they could be different. It's basically, 327 00:17:25.480 --> 00:17:27.839 if you take someone else's commit, rebase it kind of 328 00:17:27.839 --> 00:17:30.359 rewrite history, they're still the author, but you're the committer. 329 00:17:31.160 --> 00:17:33.160 So you can get kind of mixed identities in it 330 00:17:33.200 --> 00:17:38.440 that way. But otherwise you've got to use what abstractions 331 00:17:38.480 --> 00:17:41.960 and additions other companies put on top of it. 332 00:17:42.519 --> 00:17:46.960 Yeah, it's pretty interesting. I guess you just had to assume. Okay, 333 00:17:47.079 --> 00:17:51.559 no one ever works alone. They're always pairing, so both 334 00:17:51.599 --> 00:17:53.680 people get credit or whatever. 335 00:17:54.359 --> 00:17:54.599 Yeah. 336 00:17:54.720 --> 00:17:57.559 I mean the thing about the way that I look 337 00:17:57.599 --> 00:18:01.480 at like someone getting credit for like an individual getting 338 00:18:01.480 --> 00:18:04.119 credit for a PR for a commit or something like that. 339 00:18:04.799 --> 00:18:07.279 I think it makes sense when the individual's looking at 340 00:18:07.599 --> 00:18:12.200 their own data. But from a team perspective, if the 341 00:18:12.240 --> 00:18:16.039 group is getting it done well together, then I think 342 00:18:16.079 --> 00:18:18.599 that's the main thing that matters. And if there's someone 343 00:18:18.640 --> 00:18:22.200 that's not like pulling their weight or there there is 344 00:18:22.240 --> 00:18:24.279 a performance problem with the individual, you're going to be 345 00:18:24.279 --> 00:18:26.680 able to know that without looking at the stats here, 346 00:18:26.720 --> 00:18:29.960 Like I'm sure we've all experienced that over the years, 347 00:18:30.599 --> 00:18:34.839 and I've done that personally in years ago. I got 348 00:18:34.839 --> 00:18:37.680 a tool that did like the stack ranking based on 349 00:18:37.720 --> 00:18:40.640 commits and all that stuff, basically just to prove what 350 00:18:40.680 --> 00:18:45.200 I already knew and that I as the manager, needed 351 00:18:45.240 --> 00:18:47.319 to let this person go because it wasn't a good 352 00:18:47.319 --> 00:18:51.200 fit for the team, and like the data that I 353 00:18:51.240 --> 00:18:53.559 pulled in that that was really just a crutch, like 354 00:18:53.559 --> 00:18:56.160 I already knew. I was just I didn't feel confident 355 00:18:56.200 --> 00:18:58.599 in myself as a manager at that point to do it. 356 00:18:59.160 --> 00:19:02.759 The data didn't really help it. And then actually the team, 357 00:19:02.839 --> 00:19:05.319 knowing that that tool was in place and that I 358 00:19:05.440 --> 00:19:07.720 had access to it, and like no one else did 359 00:19:07.720 --> 00:19:09.400 because that's the way the tool was set up, they 360 00:19:09.440 --> 00:19:12.680 actually really really didn't like it, and we kicked it 361 00:19:12.720 --> 00:19:15.799 out after two months. So there's a there's a trust 362 00:19:15.839 --> 00:19:22.960 factor there, and in a transparency that with a responsible 363 00:19:22.960 --> 00:19:26.240 and well put together team, you don't really need to 364 00:19:26.319 --> 00:19:28.960 hide this stuff. When it's abstracted to the team level, 365 00:19:28.960 --> 00:19:30.920 everyone can benefit from it, so there's no point in 366 00:19:31.000 --> 00:19:33.880 hiding it. So I think as long as you stick 367 00:19:33.920 --> 00:19:36.720 with the individual data belongs to the individual and team 368 00:19:36.799 --> 00:19:40.200 to the team, then it all works out pretty well there. 369 00:19:40.559 --> 00:19:44.160 So one thing that I'm wondering about then, is so 370 00:19:44.240 --> 00:19:47.039 let's say that we have this aggregated team data, right, 371 00:19:47.599 --> 00:19:50.599 we know how the team's doing. We can kind of 372 00:19:50.640 --> 00:19:56.200 see how the team flows, how things generally work. I mean, 373 00:19:56.200 --> 00:19:57.960 what do we do with it? Do we just try 374 00:19:58.039 --> 00:20:00.720 different things to see what makes it better? Or will 375 00:20:00.799 --> 00:20:02.839 actually give us indicators of what to try to make 376 00:20:02.880 --> 00:20:03.359 these better? 377 00:20:04.200 --> 00:20:08.279 Yeah, that's always the big question, Like, Okay, now I 378 00:20:08.680 --> 00:20:10.880 have data, I can see stuff, what do I do? 379 00:20:11.880 --> 00:20:14.119 Because that's always the point of the data is to 380 00:20:14.200 --> 00:20:16.880 get something out of it, not just to see it. 381 00:20:17.400 --> 00:20:21.640 So there's particular things that we show, like your code 382 00:20:21.640 --> 00:20:27.480 time to meeting time ratios, which generally for your development team, 383 00:20:27.559 --> 00:20:29.960 you want them to probably be coding more. 384 00:20:29.880 --> 00:20:32.160 Than meeting and please yes. 385 00:20:33.319 --> 00:20:36.359 Yeah, so there's specific things that you can do there 386 00:20:36.519 --> 00:20:41.119 and we'll find out when you as an individual. And 387 00:20:41.160 --> 00:20:45.200 then also your team has their kind of peak hours 388 00:20:45.279 --> 00:20:47.839 in the day, and then you can use our tool 389 00:20:47.880 --> 00:20:52.480 to block out the calendars for everyone during that peak 390 00:20:52.559 --> 00:20:55.519 time so that no meetings can get put there, so 391 00:20:55.519 --> 00:20:58.759 it's just protected code time on everyone's calendar, so that 392 00:20:58.799 --> 00:21:02.079 you've got that set aside where you know that people 393 00:21:02.119 --> 00:21:06.319 are generally at their peak productivity and their peak output, 394 00:21:06.759 --> 00:21:09.759 So that's one thing to do is just protect that time. 395 00:21:10.720 --> 00:21:16.160 Using the flow mode tool in the extensions gets you 396 00:21:16.319 --> 00:21:20.319 to block out notifications and distractions whenever you are in 397 00:21:20.359 --> 00:21:22.920 the zone, and we're actually coming out very soon experimenting 398 00:21:22.920 --> 00:21:26.960 with it internally where we can detect when you're about 399 00:21:27.480 --> 00:21:30.000 to get into what we call a flow session. This 400 00:21:30.200 --> 00:21:33.960 is a high productivity, high focus section of coding, and 401 00:21:34.079 --> 00:21:38.160