0:00:05.600,0:00:10.320 My talk is called... Coding in the Dark, which is actually a quote from 0:00:10.320,0:00:17.280 a developer that I interviewed about their daily experience at a big tech company on a fancy team. 0:00:17.280,0:00:21.920 They said that they felt like they went into work and they had to sit in the dark and 0:00:21.920,0:00:26.880 code that way despite all of their resources. So I want to talk to you about why that happens 0:00:26.880,0:00:31.600 to people, and I want to start with a story rather than starting with data, and this story 0:00:31.600,0:00:38.000 will probably sound kind of familiar to you. I want us all to imagine that that we are 0:00:38.000,0:00:40.880 junior software engineers. Imagine that you've just 0:00:40.880,0:00:46.320 started working on an unfamiliar code base. Now maybe you have a little bit of ramp up - you 0:00:46.320,0:00:50.800 got to meet with some senior engineers who wrote a lot of the code that you'll be working on, 0:00:50.800,0:00:54.960 and it's a pretty good meeting - they tell you a little bit about their decisions. 0:00:54.960,0:00:58.400 You're not tracking all of it but you think you've got the handle on it. 0:00:58.400,0:01:03.280 And maybe something you've really benefited from before in similar onboarding situations 0:01:03.840,0:01:09.200 is paired programming, so you suggest it, but you get a really strong negative reaction 0:01:09.200,0:01:12.720 from one of the senior engineers. Maybe they even say something like, 0:01:12.720,0:01:17.120 oh, we kind of think that's a waste of time here. So you feel a little embarrassed and you go 0:01:17.120,0:01:21.280 back to your desk, but you dig in - you dig into the code, and as you do 0:01:21.280,0:01:25.520 your plan of attack falls apart. The code is a lot more complicated 0:01:25.520,0:01:29.920 than you thought it would be and you end up spending a lot more time exploring dead ends. 0:01:30.480,0:01:34.800 During this time you also feel a little bit anxious, because remember, you're a junior 0:01:34.800,0:01:39.040 engineer, so you're not just thinking about the code, you're thinking about things like, 0:01:39.040,0:01:43.520 are other people working as fast as I am, am I making a good showing on this team? 0:01:43.520,0:01:48.640 But you learn a lot and you even start noting down what you're learning, noticing some interesting 0:01:48.640,0:01:54.000 ways your mental model didn't match what you found, and you maybe even write some of that down. 0:01:54.000,0:01:57.520 Now imagine you go into your first code review again. 0:01:57.520,0:02:03.440 It's with somebody you've never met before, and it's okay but it doesn't go great. 0:02:03.440,0:02:07.360 This senior engineer has a lot more context on the code base than you do, 0:02:07.360,0:02:12.240 and relevant to the talk we just heard, let's imagine they criticize your choices a little bit. 0:02:12.240,0:02:17.120 You end up feeling kind of defensive and you mention, hey, you know, I also spent a lot of 0:02:17.120,0:02:22.240 time bettering my mental model of the code base, I didn't understand all of these trade-offs, 0:02:22.240,0:02:26.800 and I'm even working on an onboarding doc for the next person who's joining the team. 0:02:26.800,0:02:30.640 But again the senior engineer is a little dismissive and you get the 0:02:30.640,0:02:35.360 sense that this was a waste of time. So you go back to work but you've 0:02:35.360,0:02:40.720 taken some really important messages with you. First, you stopped writing that documentation 0:02:40.720,0:02:44.160 you were working on that you were going to give to your next junior colleague. 0:02:44.160,0:02:49.280 Second, you decide you're going to be a little bit more guarded and careful about making suggestions 0:02:49.280,0:02:53.360 about what would help your learning. And third, you think to yourself, I have 0:02:53.360,0:02:58.160 to start sounding like these senior engineers, because this is what I'm supposed to sound like. 0:02:59.600,0:03:04.000 Now, we could focus on a lot of pieces of this, and there's a lot of great research across 0:03:04.000,0:03:09.680 these sessions on different pieces - code review, how to give feedback - but I would like to draw 0:03:09.680,0:03:16.160 your attention to the secret tool that I use as a learning scientist to kind of sort through all of 0:03:16.160,0:03:20.880 these features, and that's thinking about the culture that we put people in for learning. 0:03:22.000,0:03:26.800 People are always looking around them, all the time, for clues about whether or not they're in a 0:03:26.800,0:03:32.080 safe place to learn, and we know that in order to create the code that we need - that works in the 0:03:32.080,0:03:38.320 world - we need people to be continually learning. But what I have found in my work with developers 0:03:38.320,0:03:42.560 is that we are creating instead a cycle of learning debt. 0:03:42.560,0:03:47.760 Learning debt is a - is a metaphor that I use, similar to how we talk about tech debt. 0:03:47.760,0:03:52.880 It can be understood as a long-term cycle of damage that happens when developers 0:03:52.880,0:03:57.920 face an environment where they feel that learning is necessary but it's discouraged. 0:03:59.600,0:04:02.640 The study that I'm mentioning in this talk, which I'm only going to, 0:04:02.640,0:04:07.520 you know, skate across the surface for - we interviewed 25 different developers. 0:04:07.520,0:04:10.240 We had a lot of different content with these developers. 0:04:10.240,0:04:15.440 You can see it at the link here, but in short we had a reflective piece where we went into 0:04:15.440,0:04:20.960 in-depth interviews where we talked about their collaboration experiences - how they got feedback, 0:04:20.960,0:04:25.120 barriers to learning - and we also had a real problem-solving moment. 0:04:25.120,0:04:30.400 So I sat there as a researcher and listened to them talk out loud as they tried to write code, 0:04:30.400,0:04:34.080 as they ramped up on an unfamiliar code base, as they did research, 0:04:34.080,0:04:38.800 and with those two artifacts together - the reflective and the kind of active process - we 0:04:38.800,0:04:44.400 ended up with over 30 hours of conversation that we could do a thematic analysis over. 0:04:44.400,0:04:49.040 So see our report for a lot more details where we link all of this to different 0:04:49.040,0:04:54.320 learning science mechanisms that we observed, but in short, we found this 0:04:54.320,0:05:00.880 learning debt cycle was almost ubiquitous for developers across all of these conversations. 0:05:00.880,0:05:06.880 We explored stories where developers first experienced this active learning moment where 0:05:06.880,0:05:11.760 they needed to build mental models of the code base, and they were also noticing that they were 0:05:11.760,0:05:16.880 not being given enough learning support. They took that conflict with them into 0:05:16.880,0:05:21.520 code reviews where they weren't sure whether or not they were supposed to share this learning. 0:05:21.520,0:05:25.120 And when those formal processes of feedback gave them negative 0:05:25.120,0:05:30.400 messages about learning they shut down. And here's the really interesting part: in the 0:05:30.400,0:05:36.240 third stage they go back into their environment and they replicate exactly what they experienced. 0:05:36.240,0:05:42.480 So this cycle changes people's behavior: they keep their own work hidden, they make choices 0:05:42.480,0:05:47.120 to share less about what they've learned, and it perpetuates the environment onto the next person. 0:05:48.720,0:05:52.160 There are a lot of quotes and details in the report, but I just want to share 0:05:52.160,0:05:57.600 the real voices of some developers here. One of the people - people that I interviewed 0:05:57.600,0:06:02.640 said, "We tried to advocate for more paired programming and we got a lot of pushback." 0:06:02.640,0:06:06.960 Another quote, "Ideally we were supposed to comment code, yeah, yeah, you know, 0:06:06.960,0:06:12.080 of course we're supposed to do this, but actually in reality less than 10 percent of 0:06:12.080,0:06:16.880 our code was actually well commented." And this was very, very common, 0:06:16.880,0:06:20.880 so even though we might believe all these best practices, we might know them, people 0:06:20.880,0:06:24.720 made mention of them in the interviews, other things are winning on the ground. 0:06:25.360,0:06:31.040 Okay, so you might say to yourself, you know, good news, doing good stuff is hard, it's just really 0:06:31.040,0:06:35.280 hard to sustain a good culture: we have time pressure, we have barriers, we all know this, 0:06:35.280,0:06:40.000 but I want to give you a slightly different framework to think about this from social science. 0:06:40.000,0:06:45.920 It is actually very easy to create culture. We actually do this by default. 0:06:45.920,0:06:50.000 We're just creating the wrong culture on developer teams. 0:06:50.000,0:06:53.760 What we're creating is something that we call a performance culture. 0:06:53.760,0:06:59.280 When we only measure performance and output in terms of these explicit markers, 0:06:59.840,0:07:03.600 people learn that what they're supposed to share is only performance. 0:07:03.600,0:07:06.880 They see moments of feedback and review and reflection 0:07:06.880,0:07:10.640 as actually just moments where they need to defend against criticism. 0:07:10.640,0:07:15.360 And they take away these kinds of feelings: no one else is going to feel like I do, 0:07:15.360,0:07:19.280 no one else is probably learning like I do, no one else is struggling like I do. 0:07:19.280,0:07:25.600 I cannot emphasize to you enough how interesting it is to sit there as a researcher and hear 25 0:07:25.600,0:07:30.560 different people tell you the same thing, and then say, no one else thinks this thing, and I 0:07:30.560,0:07:36.160 think part of this happens because these teams told me, we are investing a lot in technology 0:07:36.160,0:07:40.320 but we're sort of assuming this human stuff, it's magically just going to work. 0:07:42.480,0:07:46.800 so what is the opposite of this? What would happen if we allowed ourselves 0:07:46.800,0:07:49.840 to really commit to learning? I'm going to give you another 0:07:49.840,0:07:55.040 secret from learning science, and that is that real long-term sustainable learning 0:07:55.040,0:08:00.480 actually looks worse before it looks better. What I mean by that is that when we learn, we make 0:08:00.480,0:08:06.640 mistakes, and exploration - creativity - making mistakes - all of those things are dampened by 0:08:06.640,0:08:12.160 a culture that focuses on short-term performance but they're crucial to real long-term learning. 0:08:12.160,0:08:17.360 So I want you to imagine this shift: if we think back to that junior software engineer, 0:08:17.360,0:08:22.960 we might realize it's not just about the fact that they didn't get support from senior engineers. 0:08:22.960,0:08:27.840 The senior engineers also missed something really important and critical, 0:08:27.840,0:08:31.440 and that's - that could have been very valuable to the organization, and that was 0:08:31.440,0:08:36.160 a moment that the junior engineer was learning and was ready to share about their learning. 0:08:36.160,0:08:40.560 See a learning scientist perspective on collaborative work is that all of these 0:08:40.560,0:08:45.680 mistakes are really valuable sources of learning whether they come from juniors or seniors. 0:08:45.680,0:08:50.160 So I'll end finally with calling back to this learning culture environment. 0:08:50.160,0:08:54.720 If we really want to care about it our environment needs to protect it. 0:08:54.720,0:09:00.880 We can protect it by measuring it, recognizing it, and rewarding it, no matter where it comes from. 0:09:00.880,0:09:07.520 Thank you.