Bummer! This is just a preview. You need to be signed in with a Pro account to view the entire video.
Developing in Public45:27 with Daniel Hengeveld
When we work on software with others, we expect that our collaborators will share their *code* in a way that makes it easy to see what the’ve been working on. We should have the same expectation for all the *other* artifacts of software development like setup, deployment, and perhaps most importantly, the discussions and decision-making processes that accompany each phase of the project's lifecycle.
Hi everybody. 0:01 My name's Daniel [UNKNOWN]. 0:03 I'm, work for GitHub, I live in Los Angeles. 0:05 I'm really glad to be here in Las Vegas, talking to you today. 0:07 I wanna thank you for, both coming out to 0:10 Future Insights and to for coming to my talk. 0:13 I would like to talk to you today about something 0:17 that I think is really interesting or at least, important. 0:18 I call it, developing in public. 0:22 I think that we as a group of people that are 0:24 involved in software development, need to challenge the myth of the, 0:27 the genius programmer going off by himself with junk food into 0:31 a dark cave and returning with a shining gem of software. 0:35 And considering that, the sort of romantic ideal of, of creating software. 0:38 And I think that we also need to. 0:43 Really emphasize working in a way that makes all of 0:45 the artifacts of software developments as easy to search, review, 0:47 collaborate on, and get understanding and real meaning from as 0:54 it is for us to dig through version control code, right. 0:58 Code the, the classic artifact of software development. 1:01 What everyone thinks when they think of. 1:04 What are you doing when you're developing software? 1:06 Well, I'm writing code. 1:08 It's a lot more than that. 1:08 But I will admit, it's probably not controversial to talk to a room 1:11 full of people that have experience in the biz that doing a bunch 1:14 of solo work by yourself and handing it in like homework is not 1:18 a great way to ship a great 1.0 product or hit a deadline. 1:21 And we even as an industry, have a 1:25 term for development processes that are run this way. 1:27 How many of you have heard the phrase cowboy coder? 1:31 Okay, most of you, so I don't need to go into depth let me scroll on my notes here. 1:35 But it's fine to be a cowboy right? 1:41 Cowboys, it's a fine calling. 1:42 Cowboying needs to be done, it's fine to be a coder. 1:45 It's definitely not a good thing to be called a cowboy coder. 1:47 And well just like it's romantic to think of the cowboy's 1:52 life from the range as like a, wonderful camping vacation with gun 1:54 play, you know, and hanging out with your horse and like going 1:58 to the saloon in the town and stuff, like in the movies. 2:02 In reality being a cowboy was just low paid farm labor and. 2:05 Again, like a fine job to have, but not really 2:08 as exciting as, as the movies might make it out. 2:10 And it's similarly romantic to think of the, great works 2:13 of software as being products of essentially cowboy coders, right? 2:17 But Richard Stallman, for example. 2:21 When he wrote eMax, he had the entire MIT MIT iLab and Guy Steele. 2:24 Working with him, collaborating with him, giving him feedback. 2:29 When John Carmack and the early id guys wrote the Doom engine. 2:32 Yeah Carmack is a genius but 2:37 but he had the support and the testing, and the. 2:41 Influence of all the people that we're working with him to do it. 2:45 And so, you hear all these romantic stories about, like the solo 2:48 genius that built the software, because 2:52 it's fun, but it's not necessarily reality, 2:54 and at the same time you don't hear the stories about all 2:57 the charismatic non-communicative cowboy coders that 3:00 drove their companies and products off cliffs. 3:04 Partly because it's not as fun of a story and also because it's just 3:06 too common to be interesting, it's just kind of happens every day, but I digress. 3:10 Let me tell a story a story about a classic software defect. 3:16 So, who has heard of the Mars climate orbiter? 3:22 Ver, very small section of people. 3:29 So I'll explain a little bit. 3:31 It's a classic cautionary tale, of engineering gone awry. 3:32 And when I tell the story, you'll probably remember seeing it in the papers or 3:36 hearing about it because it became a, sort of, a butt of a lot of jokes. 3:39 So, anyway. 3:43 The Mars climate orbiter met a hot and messy 3:46 end, this is obviously not a real video because 3:48 it happened at Mars, so, [LAUGH] probably not someone 3:50 like taking an iPhone camera of it, of it exploding. 3:56 Long story short there are a number of 4:00 systems and pieces of software involved in the orbiter. 4:02 One of the systems reported thrust. 4:04 And it did so in the unit pound seconds. 4:08 Which is an imperial unit. 4:10 And another piece of software, took those thrust measurements and made 4:12 decisions, but it was expecting them, to be in metric units. 4:15 Newton seconds. 4:19 So, you know, it came in. 4:20 I think it was too low. 4:22 It came in at the wrong orbit. 4:23 Was lost. 4:24 And, you know, classic software engineering mistake. 4:25 Somebody should have commented their code, there weren't unit tests. 4:28 You know. 4:31 Maybe a quarter of you would have solved this problem. 4:32 But, maybe not. 4:35 Maybe it wasn't just a classic software bug. 4:36 Maybe it was something else. 4:38 I read the official after incident report. 4:40 And a few of the details stood out to me. 4:43 So, I mean this is a bit of a glib summary of the points, but the, the 4:45 navigation team wasn't fully informed on the way 4:50 of the details, the orbiter was maneuvered in space. 4:53 And, they normally had very deep systems engineering checks in 4:57 building these space missions, but for the first time ever. 5:01 The mission was handed over from a construction 5:06 team to an operations team, the idea being that 5:08 one team would operate all the Mars missions 5:10 no matter who built it and chucked in space. 5:12 And, some communication channels among 5:16 project engineering groups were too informal. 5:18 And it's the last one that I think is. 5:21 Most interesting for us, as people that are involved with 5:23 making software for the web for apps, for things less expensive. 5:26 Things that when we launch them don't go to space, for example. 5:30 so, informal communication channels. 5:33 I mean, what does too informal mean. 5:36 It could mean a lot of things. 5:38 This is kind of what I imagine, right? 5:39 I imagine this girl on the right is. 5:42 On the one of the module teams that needs to measure the thrust, and she's 5:45 saying, you know, oh yeah, be sure you 5:48 measure the thrust in Newton seconds, Newton seconds. 5:51 Listen it's super loud in here. 5:54 The World Cup is on. 5:55 Just make sure you get the thrust right, or I'll be in trouble. 5:57 Oh by the way did you ever get your dog back from the pound? 6:00 Second time this year. 6:03 Yeah, I said pound. 6:04 What, why, I gotta go. 6:05 Click, right? 6:07 That's what I imagined. 6:08 It was probably not exactly that scenario but, 6:09 even if it was email or conversations at lunch. 6:13 Those things are total black holes for, essential data. 6:15 And I think that this, is an 6:18 essential piece of information about the software right? 6:20 Even though it's. 6:22 Probably only referenced in the code in one place. 6:23 It's, this decision making process is still part of software development. 6:25 So, you know it's a communication problem then. 6:29 It's not a software problem. 6:32 It's not relevant to, my talk on 6:34 how software development should be carried out. 6:36 But, I think that we should consider communication and design processes 6:39 and being good at those things as part of software development. 6:42 It's really common in my career, and maybe in your experience too. 6:45 To think of communication skills as something that 6:48 management is good at, so that engineers can 6:51 be good at engineering, and design skills are 6:53 something that the design team is good at. 6:55 And everyone is kind of, playing to their strengths. 6:57 But, I don't think that coming out of school, for example, 7:00 with a 4.0 in Computer Science or in a software engineering course. 7:03 Perfect. 7:07 Photographic memory recall, of data structures and algorithms class. 7:09 I don't think that makes you a software developer. 7:13 I don't think it makes you a good software developer. 7:14 I don't even think it makes you a baseline competent software developer. 7:16 Because you only have one of the pieces of software development. 7:19 So, it's a human problem. 7:24 Right? 7:27 Software development is not. 7:27 A process of like, making a computer do backflips by being clever. 7:29 You're going to whoops, you're going to work with other 7:34 human beings on software at some point in your career. 7:40 I imagine everyone, in this room, is working 7:42 with other human beings on software right now. 7:45 I mean, there may be exceptions but. 7:47 It's likely that if you are working by 7:50 yourself now, you won't be working by yourself forever. 7:51 And you've probably been doing this for a while, 7:53 and if you're a coder you have good habits for 7:57 making sure that you don't, step on other people's 8:01 toes and mess up their code, or duplicate their efforts. 8:03 The easiest way to do this right, is to sit in 8:08 the same room with someone and talk about what you're working on. 8:10 The classic San Francisco, three people in a cafe or a garage. 8:13 Full bandwidth constant communication. 8:17 And sometimes people even share a computer, and 8:19 work on a same piece of software together. 8:23 You know, pair programming. 8:24 It's popular. 8:26 A lot of the people on my team do it a lot. 8:27 Like it a bit, I won't dwell on it but, if that sounds interesting to you 8:29 I really encourage you to try out pair programming, but that's a bit of an aside. 8:32 We have, the point is we have these 8:37 practices for managing the code, but it doesn't 8:39 necessarily scale to a large team and it 8:42 doesn't encompass all of the aspects of software development. 8:44 So. 8:47 You know, how can we do better? 8:49 We'll start with, you know, what I've been referring to 8:50 as these practices that we already have around software archaeology. 8:52 There are good solutions for solving these problems 8:57 as they relate to the actual code itself. 8:59 There's not a lot of debate that you should 9:02 use a modern version control system of some kind. 9:04 Git or Mercurial, or whatever your. 9:07 Tool of choice is. 9:10 And, this has been agreed way to do it for long enough that we have best practices 9:12 around how to use these tools and how to 9:17 make reviewing, what you put into these tools useful. 9:19 For example, how commit messages should be written, right. 9:22 Here's an example of good commit message. 9:25 It says, what the change was. 9:27 Says why the changes made it would be 9:31 better if it listed potential side effects, you know. 9:35 If this is inaccurate we will crash into Mars. 9:37 But, yeah, okay, we have mostly solved this for code. 9:41 There are best practices around commenting 9:44 and formatting your code, things like that. 9:46 So I guess maybe my talk's over at this 9:50 point, because if, the production of code is what 9:52 software development is, then coders need to focus on 9:55 what I just described and forget the rest of it. 9:59 But, I don't think so. 10:02 So. 10:06 I was two slides behind, didn't even notice. 10:08 I guess my talk can be over ha, ha, [UNKNOWN] nope. 10:10 So, all right, so along these lines here's a cliche. 10:12 Here's a couple pithy statements that like all pithy statements have. 10:20 Truth to them, but can also be used to gloss over 10:25 a lot of interesting relevant aspects of what they used to describe. 10:27 It's better to work together than to work alone. 10:31 This is something you hear a lot where I work, 10:33 it's an idea, that's the core of what we do. 10:35 You know, it's on the front page of our website, essentially. 10:38 And It's even our current slogan, build software better together right. 10:42 You got together, in there. 10:48 But, what if, what if together is miles and hours apart. 10:50 Right, what if writing software better together, doesn't 10:53 even mean together in the same room, or even 10:56 if it usually does what if you take a sick day or you wanna go on vacation. 10:59 Or you need to take a late night and come in you know, late the next day. 11:03 You can't spend every minute sitting in that, you 11:06 know, classic three person San Francisco coffee shop company. 11:09 And even if you could spend all of your time in full bandwidth 11:13 face to face communication, it wouldn't be a great way to get things done. 11:16 Sometimes you need to know, what your co worker did yesterday, right? 11:19 So you're communicating, not across space, but across time. 11:23 And, talking to someone face to face is very good for finding 11:28 out what they're thinking now, what their decision making process is like now. 11:32 But, you'll always get sort of a colored response filtered through 11:35 their memory and their opinions about what they were thinking months ago. 11:40 Sometimes you wanna know, what you did yesterday, right? 11:44 Or what you did six months ago. 11:47 And again the mem, our, we tell ourselves stories in our memory. 11:48 It's not perfect transcription. 11:53 And, you know, how can you sort of clone yourself six months ago? 11:54 And have a conversation in a way that, is repeatable. 12:00 That informs you about the process that you, that you're Pursuing. 12:03 So. 12:08 [COUGH] 12:08 >> This is all part of the idea is that software is not software 12:09 development, which is, what I've been kind 12:11 of hammering through the beginning of this talk. 12:13 Software is a subset of software development, obviously. 12:15 But the actual code is only half of the equation. 12:18 Here's a breakdown of a typical day, my typical 12:22 day working on a web application, with other people. 12:24 Because that is. 12:27 Probably the most common work task that I have. 12:28 And the numbers are off the top of my head so, you know, they're an estimate. 12:30 [SOUND] So each of these stars is, say half an hour of a, eight hour work day. 12:39 I spend a big chunk of time coding. 12:46 writing, fixing, organizing code in my editor. 12:49 My editor by the way, which is the fantastic Adam 12:54 editor, which is the team that I work on at GitHub. 12:57 So if you haven't tried out Adam I think you really should. 12:59 It's awesome. 13:01 It's, built on web technologies. 13:01 It's, it's it's really cool, really easily extensible. 13:03 So that's self-explanatory, right? 13:07 That's the classic artifact of software development. 13:08 The next chunk is, communicating and coordinating. 13:12 Things like, what are you gonna work on? 13:16 What am I gonna work on? 13:18 Who's gonna work on what? 13:21 And whether this is carried out in. 13:22 A lot of people carry this out in email, face to face, on the phone. 13:24 On issues in their, issue tracker of choice. 13:29 There's a million different ways that this can be done. 13:31 But if I didn't do this, the first, I could waste half of 13:34 my first chunk of four hours there 13:38 just writing code that someone's already written. 13:40 Working on the wrong thing, right? 13:42 So the next thing below that is reviewing code and. 13:45 Merging pull requests and that's not coding in the classical 13:48 sense because I'm not, I'm just reading someone else's code. 13:54 You know, I'm not writing the code, I'm not producing the code. 13:56 So when someone sends you a pull request they're basically 13:59 saying here's something I wrote, please maintain it for me. 14:01 On Twitter. 14:05 I don't remember who said it. 14:06 But I like that idea that, when you're sending someone a, 14:06 a change, you're not just saying here I'm fixing your software. 14:08 You're saying, here is a bunch of stuff I generated. 14:11 Please maintain it for me forever. 14:14 So that takes, some serious contemplation in considering like, how the, how 14:16 it interacts with the rest of the system and what your goals are. 14:20 The next point below that is. 14:23 Considerations related to runtime, to 14:25 continuous integration, to infrastructure, right? 14:28 So Coda Hale gave a talk on metrics a couple years ago that was 14:32 really well-received where he asserted that, software 14:36 doesn't generate business value while it's being written. 14:38 It only generates value for the business, while it's being run. 14:41 So we should be really concerned about what happens at runtime. 14:44 And I think that as a software developer that has a job, that pays my salary, 14:47 I need to be concerned to some degree 14:53 about, the business value that my work generates right? 14:55 So I can't just throw code over the wall 14:58 to ops and just tell them to figure it out. 15:00 So I spend time making sure that things are tested automatically, that. 15:02 The infrastructure that's in place is right and performance. 15:07 And that my code is doing at runtime what I, not only what 15:11 I intend it to do but what other people need it to do. 15:15 And the last little bit is long term project planning. 15:16 Because as the saying goes, you dream of pyramids but cut stone, right? 15:20 If you only cut stone, you're gonna end up with a pile of bricks. 15:26 If you dream of pyramids you can actually focus towards 15:30 something larger and I think that it's important for even 15:35 people that are working kind of on the line at 15:37 a low level to understand, you know, the long term plan. 15:40 So, anyway, that's my day. 15:43 And I only spend half of this day writing code. 15:46 And my title is software developer or software 15:49 engineer you know how you wanna say it. 15:51 But does that mean I'm only spending half of my day doing my job? 15:54 Does that mean I'm not really a software engineer? 15:56 I think all of these things are software development and I think, if we 15:58 take it as given that we've solved 16:03 the collaborative side of the first point, right? 16:05 We know how to collaborate on code, use version 16:07 control, blah, blah, blah, all the things I talked about. 16:09 We still have only solved half of the picture. 16:12 So, what are the best practices around the other aspects of software development. 16:15 There are a lot of strategies, theories, religions that 16:21 all claim to help you get your work done. 16:23 Agile [UNKNOWN] endless waterfall planning meetings, 16:26 government procurement processes and like that test. 16:28 Standards, you know, list goes on and on. 16:33 Most of them are built around discussion and generating long 16:35 email threads that no one's ever gonna look at again. 16:39 I mean, when's the last time you looked back at the 16:41 points that you assigned in pivotal tracker three months ago, right? 16:43 Probably never done that. 16:46 And when does that sort of decision making process helped you 16:48 in the moment of solving a difficult problem with a colleague, right? 16:51 Gonna say, oh, let me dig up this 16:54 email thread from the planning meeting six months ago. 16:56 That sort of thing is useful but it's not really the work of software development. 16:59 It's kind of metawork unless we treat it in a more mature way. 17:02 So, what's the work? 17:07 Here are some dirty words. 17:11 Not in a cursing, I mean this is definitely a 17:14 family friendly talk but, these are things that engineers that 17:16 I've worked with and in my career have really tried 17:19 to distance myself from and I think, to my detriment. 17:22 Management. 17:27 Right? 17:28 If you're in the comic that this guy's from, you know, you've got. 17:29 The clueless man, manager who has no idea what's going on 17:33 and you've got Dilbert and the rest of his co-workers doing engineering. 17:35 Never the twain shall meet. 17:38 Office space situation. 17:39 But, if that's what your management situation's like and if that's what you 17:41 think of as management, then maybe your workplace could be a little healthier. 17:44 I mean I'm not gonna, cast stones. 17:49 I don't know exactly what your, what your experience 17:51 is like but, the goal of management is to. 17:53 Make sure that everyone can work productively, right? 17:56 To move the roadblocks out of people's way and make sure 17:58 that they're happy, that they can proceed, they get things done. 18:03 And that when they have concerns, that everyone that 18:06 needs to be aware of them is aware of them. 18:09 And this is in a large company filled by managers, you know. 18:11 Middle managers, team leaders, whatever. 18:14 But, in my role and if you're a software developer, 18:17 in your role as a software developer, it is your job 18:20 to make sure that your teammates don't have road blocks, that 18:23 you understand their concerns, and that you know about them, right? 18:27 So, you need to take on the role of management, to get the software build. 18:30 And again, I'm not talking about just a healthy workplace. 18:34 I don't, I'm not concerned in this talk. 18:37 I almost said I don't care about but that would be too callous. 18:40 In this talk I'm not concerned about like, you know, what your workplace 18:43 is like or you know, what your day to day work is necessarily like. 18:46 All of this is about, successfully building software and. 18:50 If you're working with a team of people, and you 18:55 don't take on some of the traditional communication roles and management. 18:56 You're gonna have a lot of trouble successfully building software that 19:00 works, comes out on time, and is still around in a year. 19:04 And it, a lot, lot of people don't wanna hear it. 19:08 But when you think of management simply as unblocking people. 19:10 Making sure that they can do their best work. 19:13 And, making sure their concerns are known by the people that need to know them. 19:15 It's, it's really not so bad. 19:18 So dirty word number two, politics. 19:20 Politics, oh man, office politics, is, the worst thing in the world. 19:25 People talk about like, politics in terms of 19:31 this television show involves backstabbing and lying and manipulation. 19:33 And so no one wants to say, part of my job, as making software is politics. 19:37 I went into software development, I wasn't in 19:41 software development in my first first job, but 19:43 I very heavily swayed towards pure engineering because 19:46 I didn't want to be involved in politics. 19:49 But, I had a different perspective on 19:51 this, after reading Ed Catmull's book Creativity Inc. 19:53 He's one of the founders of Pixar. 19:57 And also, you know, a genius technical person. 19:59 Basically, I mean, everything, not everything. 20:03 But many of the fundamental techniques in computer graphics 20:07 are created by or contributed to by to Ed Catmull. 20:11 So he's not just, a suit at Pixar. 20:15 But he says. 20:17 Other people are your allies, in other words, I should 20:20 have taken out the in other words from this quote. 20:23 [LAUGH] Other people are your allies, but 20:25 that alliance takes sustained effort to build. 20:27 And you should be prepared for that, not irritated by it. 20:28 You're collaborating. 20:30 You're working on a team. 20:32 You're working better together. 20:33 And that doesn't mean, you show up and everyone is your 20:34 friend and everyone cares the things you care about by default. 20:37 And if your goal is to make good software, you can't just, ignore the fact that three 20:40 of your four teammates don't care at all 20:47 about performance and you really strongly care about performance. 20:49 But eh, you don't wanna, you don't wanna argue with these people. 20:53 It's a political problem. 20:57 It's a person problem. 20:58 It's, everything is of relative importance and these will maybe get done. 20:59 Like you have to work on these 21:03 relationships with your teammates to be able 21:05 to successfully build software, in a way that, fits your goals as an engineer. 21:06 It's not about lying and it's not about back stabbing. 21:11 It's not about trying to get promotions. 21:13 In this case, it's about. 21:16 Knowing who your friends are, who your 21:17 teammates are, and working on those relationships, like 21:19 you'd work on any kind of relationship, a 21:21 friendship you know, a relationship with your partner. 21:22 So, this is less of a dirty word, but 21:26 it's not as exciting for people working on software development. 21:29 There are entire documentation teams in some companies that don't write 21:33 software, aren't directly involved in writing 21:37 software, and aren't seen as engineers. 21:38 And I think that, that's a mistake. 21:41 I think that beyond explaining what, you know, what 21:43 you've written, like A plus 1, B equals A 21:48 plus 1, you don't write a comment, sets B to the value of 1 more than A, right? 21:51 Writing really, really solid documentation that explains your thought process 21:58 and your design process, is a key part of software development. 22:02 And sometimes I'll spend an hour 22:05 writing documentation, two hours writing documentation. 22:06 I've spent entire days with writing documentation. 22:08 Stuff that wasn't even docs in the code. 22:10 Things about how to play it, why it was done, what the goals are. 22:12 And if that wasn't done. 22:15 I've had to have all of these crappy offline or low 22:18 bandwidth conversations trying to explain it to people over and over again. 22:22 And just because I didn't generate code that 22:25 day, doesn't mean, that I'm not doing software development. 22:26 And, transcription. 22:30 And this is, this is kind of a huge one, 22:32 and I'll touch on this in a little bit again. 22:34 But when we have those conversations in 22:36 the bar and when we have those conversations 22:38 at lunch and when we have those 22:40 conversations on the phone or even in email. 22:41 It's okay right? 22:45 It's high bandwidth, they're gonna have it's 22:46 natural people that's how you know that but 22:48 I live in Los Angeles and my entire team is in San Francisco and [INAUDIBLE]. 22:51 And decisions get made or analysis happens, discussions happen 22:57 in San Francisco, that I would never hear about. 23:02 And it doesn't mean that they are bad decisions. 23:04 It doesn't mean that, I need to be video conferenced into lunch. 23:06 But, what it does mean, is that, for me to be able to go back 23:11 and to understand the reasoning behind, [COUGH] 23:15 behind why a decision was made and why 23:17 something was built the way it was 23:19 built, the people involved need to transcribe this 23:21 in a way that I can find, that I can search and I can understand. 23:24 They need to say, went to lunch with Cory, made a 23:27 decision about the editor, this is what we thought, you know, 23:29 doesn't have to be, entirely grunt work, it doesn't have to 23:32 be long and detailed, but it has to be recorded somewhere. 23:35 And this is something that's far 23:38 outside of what people consider software development. 23:39 But without it, I, I as the lone Angelino, 23:42 will find myself, following sort of dark paths of 23:46 reasoning about a feature or implementation that have already 23:51 been discussed at length that I just don't know about. 23:54 Wasting my time, wasting others. 23:57 okay, another element of software development. 24:00 Not floating the pool, not staring off into space design. 24:04 And I don't mean UX design and UI design, 24:08 I just mean, the design of how the software's built. 24:10 Whatever that means to you in your building software. 24:14 And it might mean, you know, classes that are inherited rather than 24:17 composed, or it might mean, you know, red buttons versus blue buttons. 24:23 But this is this is work that is done that is not typing code in. 24:27 I might not even be at my computer. 24:32 You might be at your computer. 24:34 But if this isn't done, again, your goal is to 24:35 build software that is successful, on time and lasts, right? 24:37 If you don't do this, if you just charge in and immediately write code 24:43 because you're a coder and all you do is write code, you're gonna suffer. 24:46 You're gonna make your teammates suffer and yeah, it's not gonna end well for you. 24:49 Oh, and there's, one more element of software development. 24:54 Coding, right? 24:58 It's, I mean I can't deny it. 24:59 It is, it is the most time consuming 25:00 in the largest part of software development practice. 25:02 But it's, hopefully you will agree with me by now, 25:05 not the, not the only thing you do as a developer. 25:08 So, how can we keep track of this stuff? 25:13 In a way that makes it useful to, know 25:17 how to do things and know why things are done. 25:21 Here's a few ideas that we find useful on my team at, the company I work 25:26 at, and it's by no means a comprehensive list, but it's just a few things that. 25:30 Make it less grunt work to develop in a way that's easy to search, and 25:36 review, and understand, and will hopefully allow collaboration 25:43 to blossom in a way I'll describe later. 25:47 So the first one, and this is something 25:50 very simple, is the work in progress pole request. 25:52 Does anyone not know what a pole request is. 25:56 Okay everybody knows what a pole request is. 25:59 Good. 26:00 I think it's like a standardized term across any kind 26:01 of all the tools now GitHub and gitbucket and whatever. 26:04 So, before I started working at GitHub, I would 26:08 fork projects and I would do a bunch of work. 26:13 And i would send an import [UNKNOWN] to al my changes, and the maintainer or the 26:16 owner or my boss or whatever would say 26:21 this is good, this is bad, please explain this. 26:25 And then after the fact of actually working on 26:29 the code, we'd have a bunch of conversations about it. 26:31 And this might be really obvious to some of you. 26:34 I find about in my travels, in my talks with people, about half 26:36 the people I talk to do this, about half the people had the same 26:40 perspective as I did that, it is 26:42 really enlightening and eye-opening to start getting 26:46 in the practice of opening a [UNKNOWN] request the minute you create the branch. 26:49 First commit. 26:53 Even if it's causing all the tests to fail, even if it's 26:54 just adding failing tests, even if it's just adding empty files, right. 26:56 Start from one by, opening a portal request, sending it 27:01 to maintainer and saying, this is what I'm going to do. 27:05 And then they can see every step of your decision making process, without 27:08 you having to make an effort to explain it to them after the fact. 27:12 And not just that. 27:15 But if will be and [UNKNOWN] realistic vision of 27:16 your decision making process and what you wanted to do. 27:19 Not, the one that you kinda rationalize 27:23 two weeks later, and like, try to remember. 27:26 U,, and, again, it's a really simple little thing, but when you do this, 27:28 you have this history of this discussion about, how decisions were made and why. 27:34 That is easily searchable and connected to your code in your, 27:38 you know, tool of choice, whether it's gethub or something else. 27:43 And that is really essential, because otherwise all 27:46 of these decision making processes are sort of 27:48 between the lines or the conversations never happened 27:52 or their lost in a black hole of email. 27:54 But if you open up poll request as a work in progress 27:57 instead of as a finished thing then your process becomes more public. 28:00 Another thing I said I'd talk a little bit about, pair programming later. 28:06 I'm not gonna try and preach you the gospel of pair 28:12 programming because that's, a bit of, outside the scope of this talk. 28:15 But I will say this, that the activity of pair 28:18 programming, makes it easier for these transcription, documentation, and sort 28:21 of, recorded knowledge sharing to happen, because there are twice 28:26 as many people working on a particular aspect of the software. 28:30 And you know, it becomes less, kind of, administrative-feeling work. 28:34 Something else that is not related to the code aspect of code. 28:38 But is also, about self documentation search ability. 28:43 Is something called ChatOps. 28:47 Do you guys. 28:48 Are you guys familiar with ChatOps? 28:48 Is anyone not? 28:49 Should I give a, give a, give a quick explanation. 28:50 Filive ChatOps is, so it offers operations Keeping infrastructure 28:53 running bringing up servers, things like that, deploying software. 28:59 So at our company and a lot of companies we have, 29:03 we use chat to organize our work, and we have a chatbot, 29:07 Hubot, and unlike, he does all the basic things chatbots have done 29:10 forever, you know, tell you the weather, show you pictures of pugs. 29:14 And whatnot, but in our case, all of our operations and 29:18 infrastructure work is done in a chat room through this chat bot. 29:23 I was going to do a bit of a demo but, I don't think 29:26 I'll have time for that so I'll just kinda give you a run down. 29:29 For example, I can say, what's the CI status, of a particular branch? 29:36 Deploy this piece of software. 29:42 Graph, give me the ten minute app performance graph. 29:44 Give me the status of all the unicorn processes. 29:47 Show me the critical how long a critical queue is, in our queue system. 29:50 You know, look, tell me about the connections on a front end server. 29:55 Tell me what apps [UNKNOWN] are on call. 29:58 All right, this all has to do with software, you 30:00 know, as it lives, in it's natural habitat, at run time. 30:04 And of course, ops teams everywhere 30:07 have great configuration management tools that manage 30:10 things in a code base and you can use the same sorts of tools. 30:14 But when it comes or the same sort of tools to analyze and research 30:18 them as you can with code, but when it comes to actually like making 30:21 changes, making big changes, pushing code a lot of that becomes sort of arcane 30:23 secret knowledge or something that, you have to go dig out of documents somewhere. 30:29 But you know, why is this important? 30:32 Why can I just, use my shell, why can't I just log in? 30:36 Why can't I click a button in a web app. 30:38 By putting this kind of activity around software at run time, in the middle of 30:40 a conversation everyone is having about ops, 30:46 everyone is kind of pairing all the time. 30:48 You have the benefit of, sharing this process 30:51 of fixing things and deciding how to fix 30:54 things with everyone on the team, even if 30:55 they're not looking at chat the whole time. 30:57 They're, they can drop into chat, look every now and again. 30:59 And see what's being done and why, and what the commands are. 31:01 And another excellent benefit and a one hour 31:08 visit at the end, is that, when you start, 31:12 I didn't need to be taught how to deploy the software and how to, see the graphs. 31:14 The first time I saw someone run the grapheme command in our chatroom. 31:17 And saw it auto complete a bunch of graph frames, 31:20 I knew how to get graphs for every piece of metrics 31:23 that we gathered and I knew how to deploy it 31:27 and I knew how to provisions servers and things like that. 31:29 And that minimizes the amount of training you have to do and the amount of 31:33 boarding and ramping up that, needs to be done in a one to one way. 31:37 So what if you don't have Hubot? 31:41 Right? 31:44 I mean, our chat room is a product 31:44 of a organization as a large engineering team and 31:46 mostly everyone is engineers and it isn't a 31:49 big deal for us to build these deployment tools. 31:51 So what, if you don't have a team that is that technique focused 31:56 or doesn't, doesn't have the time or resources to build up something like that. 31:59 There are a few other things, sort of using 32:05 these tools [INAUDIBLE] Hubot that you can use to 32:06 build a habit of this kind of developing public 32:10 and recording of all the other aspects of software development. 32:15 Self reporting culture. 32:19 So, a lot of people use the word culture to mean a lot of things. 32:20 I'm not gonna touch on the large, kinda contentious issue 32:25 around what company culture is or can be or should be. 32:28 But we can talk about what the word culture might mean 32:31 for groups of people working that work together to build things. 32:35 Even if you don't have the resources to 32:39 run everything through [UNKNOWN], you don't wanna use polar 32:40 quests, you can still gain the benefits of developing 32:42 public and searching through all of your non-code artifacts. 32:45 You let the people know, that you're 32:51 working with, that it's important to you that 32:52 you keep everyone informed of their decision making 32:54 process, no matter what communication tools you use. 32:55 When you bring people on, make sure they know that talking things through, 32:59 in a place that's recorded with all the offers is part of their job. 33:01 But it sounds like I can imagine someone playing devil's advocate, but I'm 33:05 just advising everyone in this room to do a bunch of grunt work. 33:11 To like, take notes at their own meetings, even 33:13 if it, their the only people making these decisions. 33:16 And that, is a terrible idea, right, like I talked about how you 33:19 needed to document and how you needed to subscribe and it sounds like. 33:25 I'm turning a bunch of people working on 33:29 software into a bunch of court reporters, a 33:31 bunch of like medieval scribes, that just spend 33:34 all their time writing down what was said. 33:37 What makes it not about grunt work, is embracing good tools. 33:39 I mentioned earlier ChatOps. 33:43 We have we use, Campfire for chat. 33:44 We wrote our own, client for it. 33:48 Everything is very easily searchable. 33:50 And it's trivial for anyone without any training to come to chat, 33:52 look at history, search through history, see what people did and why. 33:58 If we use the poor chat tool, I mean 34:01 all these chat tools support this kinda stuff now. 34:03 But if, imagine that we had a terrible search system in our chat. 34:05 And we'd spend a lot of time transcribing things into issues and discussions. 34:10 And you know I think that GitHub is a good tool right? 34:14 And that's why, I emphasize core requests and 34:17 issues and responding to things in that way. 34:20 But whatever tools you use, you need to treat your tools as you office. 34:25 This should go without saying. 34:31 I, I would hope especially in this 2014 where distributed teams and teams that 34:33 work asynchronously, and teams with the mixed 34:37 parts where the full time are the norm. 34:39 But it doesn't matter where, how nice your office is, or where your computers are, 34:41 if your tools are bad, because that is 34:46 how your colleagues are gonna interact with you. 34:47 Another thing you can do as a smaller organization, to make it easier to develop 34:51 in a way where all your decision making process as a public, is to be predictable. 34:57 And what I mean by this, is to have 35:01 [UNKNOWN] cross all the things that you work on. 35:02 One of the first projects that I had, at [UNKNOWN] was working at our 35:04 internal tools, and we had, many dozens of web [UNKNOWN] other and API of things. 35:07 That were of only, only of interest to people 35:12 that worked at the company and they were all 35:15 written to scratch an itch by people that were 35:16 working on other products and they all were very different. 35:19 And we went through a big push to consolidate, all of these things to 35:21 use similar platforms similar versions of frameworks. 35:26 The same templating language everywhere. 35:32 Even if people really hate it. 35:34 Cuz in the Ruby world, there's a kind of a holy 35:35 war between people that like this thing called Hamill, people that don't. 35:37 And we just said it doesn't matter. 35:40 It's better that they're all the same. 35:42 And so we picked one templating language, and stuck with it. 35:43 What this means, is, instead of having to do 35:46 a bunch of grunt work, writing about why you decided. 35:49 Tease this template and language with are that framework. 35:51 A shared understanding of, if it's an internal 35:54 tool it uses this, that, and the other thing. 35:56 Let's you talk about the decision-making process, 35:59 the design and the ultimate business goals. 36:02 Preferred communication this is simple. 36:06 If you're debating whether or not to 36:10 discuss something, always choose to discuss it. 36:12 This may sound like a recipe for endless 36:15 meetings it sounds like it'll slow things down. 36:17 It might slow things down sometimes, but it doesn't have to be 36:20 a recipe for sitting and hashing 36:23 everything out completely before doing any work. 36:25 Remember the work in progress pull request. 36:27 If your discussion is constantly ongoing and public from the beginning of every 36:29 project you are, you don't have to hash every detail out before doing work. 36:34 It can happen alongside. 36:39 You're building software, while you discuss. 36:40 But it's better that you do that, with communication than without. 36:42 Because you don't know who's gonna be 36:45 working on something in six months, whether 36:47 it'll even be a going concern or whether it's gonna be related to another project. 36:49 But as much communication as you can get on paper, so to speak. 36:52 And in a good tool, that's searchable and public and 36:59 available to everyone in your, in your organization, the better. 37:01 Before I move on to the conclusion I wanna add one very important caveat. 37:05 It sounds like. 37:10 It might sound like from what I'm saying 37:12 that I'm describing a culture in which interruption is 37:14 important or which nothing gets done until details are 37:17 changed or you can be diverted midstream at anytime. 37:21 That's absolutely not the case. 37:24 And it would be the case, if you didn't fall out of this as a golden rule. 37:25 We're I work and hopefully [UNKNOWN] a lot 37:30 of places, you guys work, all communications treated asynchronously. 37:32 I'm comfortable jumping into chat saying Nathan, what do you think of this? 37:36 Whatever. 37:42 This pull request on this repo? 37:43 And I know he'll get a thing on his phone, but he knows that my 37:45 expectation is that I don't, he doesn't need to get back to me right away. 37:49 Right? 37:52 Every issue comment I reply to, every email 37:53 I respond to, every chat thing I get. 37:54 Needs to be dealt with, when it's time for 37:58 me to take my communication hours out of a day. 38:00 And it's, I need to expect that my colleagues and my teammates do 38:03 the same thing because otherwise this 38:07 much communication, would completely drown a team. 38:08 You just need to understand that people 38:11 will respond it's like, you know, asynchronous programming. 38:13 I originally had like a no JS logo behind this, but it made the text hard to read. 38:17 But [LAUGH] you can't expect synchronous communication unless it's 38:20 something really crucial that's worth, stopping the assembly line for. 38:26 And just treat if you got a lot of heads down quoting to do some 38:30 days, you know, some days I have to, you know, spend eight hours writing quotes. 38:33 Some days I don't. 38:36 Just treat answering all these pings like another task, right? 38:37 Like the 10th thing on my list. 38:40 Fix all these issues and then issue number ten 38:42 is, respond to those ten chat pings that I got. 38:43 So, ultimately why do this? 38:47 Why, why, why is the things I talked about important. 38:51 It sounds like a bunch of unnecessary 38:52 complications to the task of building software, 38:54 when this whole let managers do only 38:56 communication, and let coders do only code. 38:59 And let designers do only designs seems to be working fine for 39:01 a lot of people, so why bother with this tedious self documentation? 39:04 I have a couple of reasons that I think are important. 39:08 This enables truly productive remote work. 39:12 Working this way and building your 39:15 habits around [INAUDIBLE] communication and public, 39:18 shared, searchable communication makes it possible to have a functional remote team. 39:21 And you may think, oh, you know, we have weak incentives, and Google 39:25 hang up Google Hang Outs, and we get our software done, you know? 39:28 We're a, we're a functional remote team. 39:30 But you're never going to have as satisfying an experience as face to face 39:33 communication by trying to create an intermediated 39:40 like computer version of face to face communication. 39:43 That is good, for certain things. 39:48 Sitting in a coffee shop, talking to someone face to 39:50 face, is very powerful and very useful but necessarily trying to 39:52 do it over a Google Hangout or trying to just conference 39:56 someone in sometimes into meetings, is obviously a degraded experience, right? 39:59 Rather than just trying to just create a bad 40:06 clone of something that works for a remote team 40:08 we need new patterns of working, that aren't just 40:11 attempting to do one to one's over 5,000 miles. 40:14 And sometimes that sort of thing's essential but it's 40:17 not the core of working with a remote team. 40:20 And frankly I don't know if any of you, how many 40:23 of you are in a position to hire developers in this room? 40:25 Anybody? 40:29 So, it's probably, you've probably noticed in the last couple 40:30 of years that working remotely or working from home is 40:33 an expected perk, for anyone that's been in the business 40:36 for, for anybody that's not straight out of college, right? 40:39 And to support those people and be able to hire 40:41 those people you need to make certain concessions to them. 40:45 But you also need to work in a way that it's 40:49 worth it to pay their salary and they can work productively. 40:51 So embracing this kind of asynchronous, 40:54 public communication is important in that way. 40:56 Fast onboarding. 40:59 I mentioned this earlier. 41:00 ChatOps. 41:02 I see the deploy commands. 41:02 I know how to deploy software on my first day. 41:04 No one has to teach me. 41:06 Or I go, look at the github, github depository, the website. 41:07 I can look at the history of the portal class that added a major feature 41:12 and I can see the discussion from, some employ saying, I think we should do this. 41:17 He is, like, a spiked out version of the future that's not tested. 41:22 And literally hundreds of comments. 41:25 And the feature ended up looking 41:28 completely different than the original engineer intended. 41:29 And I can understand why these decisions were made, before, you know, I 41:31 go propose some other similar, huge change because it's all publicly available to me. 41:35 And it's all easily searchable and in logical places. 41:39 And effort was made, to make these decisions in public. 41:42 And this is something, transparent strategies and realtalk. 41:45 It's kind of a obscure slide, I guess. 41:50 But I, could've, have you guys heard of that radio show, 41:55 radio ab, I imagine you have, it's pretty popular, among this crowd. 41:59 And by which I mean, it's a little nerdy. 42:04 They did a show on the prisoner's dilemma, which is 42:05 a classic sociological competition where it, anyway that's beside the point. 42:09 The idea is the, the conclusion of this this Radiolab story about. 42:16 This classic sociological experiment was that, the more 42:23 obvious your strategy is to someone that you're playing 42:27 a game with, the more you'll be able 42:30 to cooperate because they understand your decision making process. 42:34 There's a great book about it. 42:37 I wrote a blog post about it on my site I linked on the last page. 42:38 The idea is that, if you can see me and the way that 42:42 I argued in the past and why I make the decisions that I do. 42:45 The less likely it is that my teammates are gonna suspect 42:51 that I have a hidden agenda, that I'm playing politics, right? 42:54 You can see, I've generated volumes and volumes of arguments and 42:58 proposals and things that aren't code but are related to code. 43:02 And you understand why I value the things I value. 43:06 You're not gonna come into an argument with me or 43:08 a discussion with me thinking, well Daniel says this, but he's 43:11 really just trying to build his own prestige, or write 43:15 his next talk, or impress, you know, a founder or something. 43:18 If you understand the way that I've argued in 43:23 the past and you see that my strategies are 43:25 transparent we can work together in an open and 43:26 honest way even if we don't really know each other. 43:31 And this one is my personal favorite benefit 43:34 of this, the thing that I think is, probably 43:39 the most important, because when you work in 43:41 this way, you naturally have a lot of autonomy. 43:44 And in a lot of situations, we've all seen 43:46 it, when someone is not prepared to meet a challenge 43:48 or not necessarily set up for success in what 43:51 their working on, goes off by themselves and works autonomously, 43:53 they can fail and fail badly enough that, by 43:57 the time you realize they failed, the software's in production, 44:00 or they spent a month on it, or you 44:03 missed a deadline or you're going to blow a budget. 44:05 But if you have this very open you know, collaborative 44:07 public development and decision making process, people don't get lost. 44:13 I go in and I work on something and I'm 44:16 totally out of my depth, but I'm oblivious to that fact. 44:18 One of my co-workers can come in on day two and say, 44:21 you know, Daniel I think you're headed in totally the wrong direction. 44:23 Why don't you look at this other portal request or why don't 44:28 you do it this way or why don't you let me do? 44:31 And we can talk it out and we, we can solve that before I 44:32 fail or get lost so badly that the work that I've done, is totally wasted. 44:36 So, to sum up, I think that you should develop in public, 44:41 and when I say develop, I mean, all the aspects of software development. 44:45 Because it enables remote work, it gets new people 44:48 started fast, it teaches your teammates how your brain works 44:52 so that they can work with you better, and 44:55 it exposes failure early enough that, that can be fixed. 44:57 And, that person can go on and become a productive team 45:00 member, instead of, getting frustrated and quitting or, something along those lines. 45:03 And that pretty much sums it up. 45:08 I have five minutes left if anyone, 45:10 [APPLAUSE] wants to make comments or questions. 45:12 Otherwise, we'll call it a time. 45:15 Does anybody, wanna, say anything? 45:18 All right. 45:19 Cool. 45:22 Thank you. 45:24 [APPLAUSE] 45:26
You need to sign up for Treehouse in order to download course files.Sign up