1 00:00:06,580 --> 00:00:09,330 - Hi, I want to make sure that you fully understand 2 00:00:09,330 --> 00:00:13,130 what this material is and where it's coming from. 3 00:00:13,130 --> 00:00:16,710 This is why I truly hope you start these lessons 4 00:00:16,710 --> 00:00:18,710 right here with Prepare Your Mind. 5 00:00:18,710 --> 00:00:20,890 Follow these lessons in this first section, 6 00:00:20,890 --> 00:00:23,090 because it's really gonna help prepare you 7 00:00:23,090 --> 00:00:24,720 for not just the material we're gonna teach, 8 00:00:24,720 --> 00:00:26,050 but how I'm teaching it, 9 00:00:26,050 --> 00:00:28,550 and why I'm teaching it the way it is. 10 00:00:28,550 --> 00:00:30,720 Now you know, somewhere along the line, 11 00:00:30,720 --> 00:00:34,100 we came up with this idea that programs and projects, 12 00:00:34,100 --> 00:00:36,610 large amounts of codes were really, really cool. 13 00:00:36,610 --> 00:00:37,660 They were awesome. 14 00:00:37,660 --> 00:00:38,500 But I want you to understand 15 00:00:38,500 --> 00:00:41,510 that this is not really where we want to go today. 16 00:00:41,510 --> 00:00:43,140 We're gonna learn that lines of code 17 00:00:43,140 --> 00:00:46,880 really can affect how healthy a project is, 18 00:00:46,880 --> 00:00:48,540 how healthy a team is. 19 00:00:48,540 --> 00:00:51,790 And I want to start moving away from being oppressed 20 00:00:51,790 --> 00:00:54,060 with projects with large amounts of code. 21 00:00:54,060 --> 00:00:56,380 If you look at the Linux operating system 22 00:00:56,380 --> 00:00:57,750 as an open-source project, 23 00:00:57,750 --> 00:01:00,870 there's about 24 million lines of code 24 00:01:00,870 --> 00:01:02,160 in that project today. 25 00:01:02,160 --> 00:01:04,510 That is immense; it's massive. 26 00:01:04,510 --> 00:01:07,250 It's gonna take a massive team to be able to deal with that, 27 00:01:07,250 --> 00:01:10,030 and I personally don't want to be on projects like that. 28 00:01:10,030 --> 00:01:12,780 Now here's another thing that I want us to focus on 29 00:01:12,780 --> 00:01:14,935 and understand that Go is trying to solve. 30 00:01:14,935 --> 00:01:17,730 We were taught to create these large abstractions 31 00:01:17,730 --> 00:01:19,900 in our code base to deal with change. 32 00:01:19,900 --> 00:01:20,750 In fact, we've been taught 33 00:01:20,750 --> 00:01:23,970 to put abstractions on top of abstractions. 34 00:01:23,970 --> 00:01:26,170 This is something that we also need to get rid of, 35 00:01:26,170 --> 00:01:28,610 because all this is doing is adding more code 36 00:01:28,610 --> 00:01:31,540 to our project, which is gonna be causing more pain. 37 00:01:31,540 --> 00:01:34,060 I think one of the most beautiful things about Go 38 00:01:34,060 --> 00:01:36,330 is that we're gonna learn how we can create 39 00:01:36,330 --> 00:01:38,830 these very thin layers of decoupling 40 00:01:38,830 --> 00:01:42,180 and still achieve our ability to deal with change 41 00:01:42,180 --> 00:01:46,000 without all these extra generic layers of abstraction. 42 00:01:46,000 --> 00:01:48,410 Now here's another one that a lot of people lose, 43 00:01:48,410 --> 00:01:49,600 and it's not fair. 44 00:01:49,600 --> 00:01:51,367 The languages you may have been using 45 00:01:51,367 --> 00:01:55,430 could have been using a VM, like Java and C Sharp, 46 00:01:55,430 --> 00:01:57,330 where there's a virtual machine there 47 00:01:57,330 --> 00:02:01,150 taking care of what we will call mechanical sympathy. 48 00:02:01,150 --> 00:02:03,480 We're gonna learn mechanical sympathy in this class. 49 00:02:03,480 --> 00:02:05,220 But what's important here is this, 50 00:02:05,220 --> 00:02:07,410 is that if performance matters, and it does, 51 00:02:07,410 --> 00:02:09,180 that's why we're here using Go, 52 00:02:09,180 --> 00:02:11,100 then it's the hardware that matters, 53 00:02:11,100 --> 00:02:13,800 because it is the hardware that executes instructions. 54 00:02:13,800 --> 00:02:15,260 Your performance is gonna come 55 00:02:15,260 --> 00:02:17,380 from the hardware, nothing else. 56 00:02:17,380 --> 00:02:18,960 So we either need to be sympathetic 57 00:02:18,960 --> 00:02:20,430 with the hardware or not. 58 00:02:20,430 --> 00:02:23,700 The hardware is the platform at the end of the day, 59 00:02:23,700 --> 00:02:27,750 if performance matters, and we all know that it does. 60 00:02:27,750 --> 00:02:30,010 And the last thing here, 61 00:02:30,010 --> 00:02:31,810 and again, I think it's lost 62 00:02:31,810 --> 00:02:34,940 because of the languages that we've been working with, 63 00:02:34,940 --> 00:02:38,670 is that engineering is about understanding cost. 64 00:02:38,670 --> 00:02:42,210 Every decision you make comes with a cost. 65 00:02:42,210 --> 00:02:45,010 There's a benefit for that decision and a cost, 66 00:02:45,010 --> 00:02:47,660 and if the benefit is not outweighing the cost, 67 00:02:47,660 --> 00:02:49,260 you shouldn't be taking the decision, 68 00:02:49,260 --> 00:02:50,950 shouldn't be making that decision. 69 00:02:50,950 --> 00:02:53,220 So part of this class, a big part of this class 70 00:02:53,220 --> 00:02:55,100 is understanding that engineering 71 00:02:55,100 --> 00:02:58,450 is about understanding the costs you are taking. 72 00:02:58,450 --> 00:03:00,210 And when you don't, you're not coding, 73 00:03:00,210 --> 00:03:01,100 you're not engineering. 74 00:03:01,100 --> 00:03:03,870 You're hacking, and we can't have that today at all. 75 00:03:03,870 --> 00:03:06,540 Now another thing that's very important, 76 00:03:06,540 --> 00:03:09,850 these are things that I believe Go is trying to solve. 77 00:03:09,850 --> 00:03:12,150 These are problems that Go has seen, 78 00:03:12,150 --> 00:03:13,890 and we're trying to solve them with Go. 79 00:03:13,890 --> 00:03:15,560 And this other one is that the idea is 80 00:03:15,560 --> 00:03:18,170 that you cannot throw more hardware at the problem. 81 00:03:18,170 --> 00:03:20,250 Now not many of us have data centers anymore. 82 00:03:20,250 --> 00:03:21,720 We're using the cloud. 83 00:03:21,720 --> 00:03:23,270 And so I can apply that to the idea 84 00:03:23,270 --> 00:03:25,820 that you can't through more cloud computing 85 00:03:25,820 --> 00:03:26,890 at the problem anymore. 86 00:03:26,890 --> 00:03:28,636 It's expensive stuff. 87 00:03:28,636 --> 00:03:30,950 So one of the big things about Go 88 00:03:30,950 --> 00:03:32,840 is we're trying to write software 89 00:03:32,840 --> 00:03:34,990 that minimizes the use of resources, 90 00:03:34,990 --> 00:03:37,120 minimizes the use of that hardware, 91 00:03:37,120 --> 00:03:38,780 minimizing the use of cloud. 92 00:03:38,780 --> 00:03:39,613 Why? 93 00:03:39,613 --> 00:03:40,446 We'll keep those costs down. 94 00:03:40,446 --> 00:03:41,650 We're on shared machines, 95 00:03:41,650 --> 00:03:43,710 making all these things that are gonna tie back in together 96 00:03:43,710 --> 00:03:46,010 into the language as we continue to learn it. 97 00:03:46,010 --> 00:03:48,070 And we already know that you can't throw 98 00:03:48,070 --> 00:03:49,850 more developers at a problem. 99 00:03:49,850 --> 00:03:52,390 At least historically it hasn't been the case. 100 00:03:52,390 --> 00:03:53,570 How many times have you been on a team, 101 00:03:53,570 --> 00:03:55,260 and a manager, somebody in management 102 00:03:55,260 --> 00:03:56,317 comes and says, "well, you know, 103 00:03:56,317 --> 00:03:58,487 "if I throw another developer on this project, 104 00:03:58,487 --> 00:04:00,180 "could we get it done faster?" 105 00:04:00,180 --> 00:04:02,320 And I'm always like, look, this isn't accounting. 106 00:04:02,320 --> 00:04:03,707 It's not like I can throw an accountant on here 107 00:04:03,707 --> 00:04:05,310 and we're gonna move faster. 108 00:04:05,310 --> 00:04:06,460 This is software development, 109 00:04:06,460 --> 00:04:08,520 and there are things that cause us 110 00:04:08,520 --> 00:04:10,710 to have pain as a team grows. 111 00:04:10,710 --> 00:04:13,010 I think Go is solving a lot of these problems 112 00:04:13,010 --> 00:04:14,680 also around package-oriented design. 113 00:04:14,680 --> 00:04:16,200 We're gonna talk about these things. 114 00:04:16,200 --> 00:04:17,470 And there are ways to structure, 115 00:04:17,470 --> 00:04:19,510 package projects together 116 00:04:19,510 --> 00:04:21,068 where we could put more projects, 117 00:04:21,068 --> 00:04:25,200 developers on a team and potentially get more work done. 118 00:04:25,200 --> 00:04:27,660 But we have to know and think about this up front, 119 00:04:27,660 --> 00:04:29,550 and the language has kind of done that. 120 00:04:29,550 --> 00:04:32,470 So throughout this class, throughout this class, 121 00:04:32,470 --> 00:04:35,210 throughout the 15 hours that we're gonna be together here, 122 00:04:35,210 --> 00:04:38,590 I need you to always be a champion 123 00:04:38,590 --> 00:04:41,290 for quality, efficiency, and simplicity. 124 00:04:41,290 --> 00:04:43,280 I'm gonna try to teach you how to do that. 125 00:04:43,280 --> 00:04:44,530 It's critically important 126 00:04:44,530 --> 00:04:46,476 that you always have a point of view 127 00:04:46,476 --> 00:04:50,430 and self-reflect about who you are as a developer. 128 00:04:50,430 --> 00:04:52,680 But I don't want you to hold back on your point of view. 129 00:04:52,680 --> 00:04:54,930 I want you to analyze and self-reflect. 130 00:04:54,930 --> 00:04:56,815 What is my philosophy here? 131 00:04:56,815 --> 00:05:00,287 What is driving the engineering decisions that I'm making? 132 00:05:00,287 --> 00:05:02,680 Am I improving as a developer? 133 00:05:02,680 --> 00:05:06,960 It usually means that you're improving your point of view, 134 00:05:06,960 --> 00:05:07,800 that it's changing. 135 00:05:07,800 --> 00:05:10,490 It's okay to change your mind on something. 136 00:05:10,490 --> 00:05:13,970 That's growth, and we want to have that all the time. 137 00:05:13,970 --> 00:05:17,670 So as we continue to focus on this class, 138 00:05:17,670 --> 00:05:19,700 I want you to open up your mind. 139 00:05:19,700 --> 00:05:22,020 Look, technology is changing quickly. 140 00:05:22,020 --> 00:05:24,110 We feel it and see it every day. 141 00:05:24,110 --> 00:05:25,960 But our minds change slowly. 142 00:05:25,960 --> 00:05:27,516 We resist to change. 143 00:05:27,516 --> 00:05:30,340 And it's always easy to adopt new technology, 144 00:05:30,340 --> 00:05:32,770 but it's hard to adopt a new way of thinking. 145 00:05:32,770 --> 00:05:34,740 And one of the things I've gotta do in this class 146 00:05:34,740 --> 00:05:38,150 is kind of break you down and build you back up. 147 00:05:38,150 --> 00:05:40,710 There are things that I'm gonna be asking you not to do 148 00:05:40,710 --> 00:05:43,980 that you've been doing historically or been taught to do. 149 00:05:43,980 --> 00:05:46,900 Go has different costs for things, 150 00:05:46,900 --> 00:05:49,660 and that means that you've got to make different decisions. 151 00:05:49,660 --> 00:05:52,660 And it's not that what you were doing before was wrong. 152 00:05:52,660 --> 00:05:54,850 It's just that it's not necessarily the best 153 00:05:54,850 --> 00:05:57,990 or the right thing to do when we are coding in Go. 154 00:05:57,990 --> 00:06:00,670 And these are things that I'm gonna try to teach you 155 00:06:00,670 --> 00:06:03,970 over the time that we're gonna spend together in this class. 156 00:06:03,970 --> 00:06:06,580 Now as we continue to talk about this, 157 00:06:06,580 --> 00:06:10,120 I want to focus on this idea of legacy software. 158 00:06:10,120 --> 00:06:11,640 If you ever met me in a bar 159 00:06:11,640 --> 00:06:12,810 and I've been drinking a little whiskey, 160 00:06:12,810 --> 00:06:15,570 and you happen to tell me that you're a software developer, 161 00:06:15,570 --> 00:06:17,800 well, one of the very first things I'm gonna ask you 162 00:06:17,800 --> 00:06:21,600 is what is the legacy you're leaving behind? 163 00:06:21,600 --> 00:06:24,370 This is a critical, critical question 164 00:06:24,370 --> 00:06:26,220 that you should be asking yourself. 165 00:06:26,220 --> 00:06:29,830 Now I've got some really great historical quotes here. 166 00:06:29,830 --> 00:06:32,140 I think history is critically important, 167 00:06:32,140 --> 00:06:34,450 mechanics after that, and semantic behavior. 168 00:06:34,450 --> 00:06:36,080 We're gonna talk about all of these things 169 00:06:36,080 --> 00:06:37,250 throughout the class. 170 00:06:37,250 --> 00:06:39,167 But I love this quote from Peter. 171 00:06:39,167 --> 00:06:41,077 "There are two kinds of software projects, 172 00:06:41,077 --> 00:06:44,610 "those that fail and those that turn into legacy horrors." 173 00:06:44,610 --> 00:06:45,443 This is great. 174 00:06:45,443 --> 00:06:47,140 Every time I say it, I crack up a little bit. 175 00:06:47,140 --> 00:06:48,760 But it's so true, right? 176 00:06:48,760 --> 00:06:50,210 What is a project that fails? 177 00:06:50,210 --> 00:06:51,817 A project that fails is a project 178 00:06:51,817 --> 00:06:55,263 that never makes it into production. 179 00:06:55,263 --> 00:06:58,610 But a project that gets into production 180 00:06:58,610 --> 00:07:00,980 and is no longer able to be maintained, 181 00:07:00,980 --> 00:07:02,890 that's a legacy horror. 182 00:07:02,890 --> 00:07:04,190 And if you really think about it, 183 00:07:04,190 --> 00:07:05,996 we've got 40 years of software 184 00:07:05,996 --> 00:07:08,268 in this country, around the world, 185 00:07:08,268 --> 00:07:11,276 that is really a legacy nightmare. 186 00:07:11,276 --> 00:07:12,109 It is. 187 00:07:12,109 --> 00:07:13,030 I can't tell you how many times 188 00:07:13,030 --> 00:07:13,960 I walk down the street 189 00:07:13,960 --> 00:07:16,010 and just wait for the lights to turn off. 190 00:07:16,010 --> 00:07:18,380 I'm always saying that I don't want Hollywood anymore 191 00:07:18,380 --> 00:07:20,890 to write movies about earthquakes and asteroids. 192 00:07:20,890 --> 00:07:23,110 I want a movie about legacy software 193 00:07:23,110 --> 00:07:25,570 systematically failing all over the planet 194 00:07:25,570 --> 00:07:27,520 and no one being able to do anything about it, 195 00:07:27,520 --> 00:07:29,440 because there aren't any Unitests to deal with it. 196 00:07:29,440 --> 00:07:32,160 And I've got clients today, today 197 00:07:32,160 --> 00:07:34,750 that are writing legacy code out of the box, 198 00:07:34,750 --> 00:07:36,070 mainly because, one, they don't know 199 00:07:36,070 --> 00:07:37,390 how to do it any other way, 200 00:07:37,390 --> 00:07:38,340 and two, they create 201 00:07:38,340 --> 00:07:42,860 these incredibly short-term milestones for themselves 202 00:07:42,860 --> 00:07:44,280 which just really can't be met. 203 00:07:44,280 --> 00:07:46,790 And at the end of the day, all they're doing is hacking. 204 00:07:46,790 --> 00:07:48,267 Look, Chuck Moore said it best, 205 00:07:48,267 --> 00:07:51,570 "legacy software is an unappreciated but serious problem. 206 00:07:51,570 --> 00:07:54,130 It is gonna "be the downfall of our civilization." 207 00:07:54,130 --> 00:07:55,880 I really believe that. 208 00:07:55,880 --> 00:07:58,340 But we today have opportunities to learn 209 00:07:58,340 --> 00:08:01,460 how to write software that isn't legacy out of the box. 210 00:08:01,460 --> 00:08:03,550 Go is at the forefront of this. 211 00:08:03,550 --> 00:08:06,890 We've just got to learn how to rethink 212 00:08:06,890 --> 00:08:08,210 how we do software development, 213 00:08:08,210 --> 00:08:09,880 restructure our software development, 214 00:08:09,880 --> 00:08:13,150 and keep this in the front of our minds at all time. 215 00:08:13,150 --> 00:08:14,940 But I think one of my favorite quotes 216 00:08:14,940 --> 00:08:17,310 throughout this entire class in all the material 217 00:08:17,310 --> 00:08:18,690 comes from Sarah Mei. 218 00:08:18,690 --> 00:08:21,280 If you don't know Sarah Mei, you need to look her up. 219 00:08:21,280 --> 00:08:25,180 She is a powerhouse, a thought leader in our industry. 220 00:08:25,180 --> 00:08:28,670 And though she spends most of her time coding in Ruby, 221 00:08:28,670 --> 00:08:29,560 I don't care. 222 00:08:29,560 --> 00:08:31,317 What she talks about, 223 00:08:31,317 --> 00:08:34,290 and the things that she tells us 224 00:08:34,290 --> 00:08:36,130 applies to almost any engineering 225 00:08:36,130 --> 00:08:37,650 that we're doing in software development. 226 00:08:37,650 --> 00:08:39,627 And she said this, and I love this quote. 227 00:08:39,627 --> 00:08:43,677 "We think awful code is written by awful devs. 228 00:08:43,677 --> 00:08:45,907 "But in reality, it's written by reasonable devs 229 00:08:45,907 --> 00:08:48,250 "in awful circumstances." 230 00:08:48,250 --> 00:08:49,380 And I want us to understand that, 231 00:08:49,380 --> 00:08:51,660 because all of us at some point 232 00:08:51,660 --> 00:08:53,190 are gonna be asked to look at a piece of code 233 00:08:53,190 --> 00:08:54,580 that we haven't written. 234 00:08:54,580 --> 00:08:55,830 And when we look at that code, 235 00:08:55,830 --> 00:08:57,460 we might come up with a conclusion 236 00:08:57,460 --> 00:08:59,508 that I don't know what kind of drugs 237 00:08:59,508 --> 00:09:00,969 this developer was on, 238 00:09:00,969 --> 00:09:02,810 but they should have been sharing them, 239 00:09:02,810 --> 00:09:04,900 because this is out of control. 240 00:09:04,900 --> 00:09:06,430 But I want us to step back and think, 241 00:09:06,430 --> 00:09:08,270 and say, whoa, whoa, whoa, whoa, whoa. 242 00:09:08,270 --> 00:09:11,370 Let's not trash the developer who wrote this piece of code. 243 00:09:11,370 --> 00:09:13,350 Let's come back and ask ourselves, 244 00:09:13,350 --> 00:09:15,900 what was the condition or situation they were in 245 00:09:15,900 --> 00:09:18,130 when they had to write this piece of software? 246 00:09:18,130 --> 00:09:19,840 And now we're here to maintain it, 247 00:09:19,840 --> 00:09:21,747 and maybe we can even improve it. 248 00:09:21,747 --> 00:09:24,310 And so I want us to all have empathy 249 00:09:24,310 --> 00:09:25,610 for everything that we're doing, 250 00:09:25,610 --> 00:09:26,920 because every environment is different. 251 00:09:26,920 --> 00:09:28,500 Every situation is different. 252 00:09:28,500 --> 00:09:29,830 And we're going to be asked 253 00:09:29,830 --> 00:09:32,400 also to maintain code that exists. 254 00:09:32,400 --> 00:09:34,610 But as you continue to write new code, 255 00:09:34,610 --> 00:09:36,450 I want you to think about that person 256 00:09:36,450 --> 00:09:39,140 that has to maintain that code after you. 257 00:09:39,140 --> 00:09:40,640 That's going to help us move away 258 00:09:40,640 --> 00:09:42,270 from these legacy issues. 259 00:09:42,270 --> 00:09:44,450 Sarah Mei, brilliant quote. 260 00:09:44,450 --> 00:09:46,370 Now if we really are gonna focus 261 00:09:46,370 --> 00:09:50,760 around not creating legacy code out of the box, 262 00:09:50,760 --> 00:09:52,770 for me the number one thing, 263 00:09:52,770 --> 00:09:54,190 the number one thing we have to keep in mind 264 00:09:54,190 --> 00:09:56,630 are mental models of the code base. 265 00:09:56,630 --> 00:09:58,430 Mental models are everything. 266 00:09:58,430 --> 00:09:59,510 And it's gonna be part 267 00:09:59,510 --> 00:10:03,340 of your daily refactoring of the code. 268 00:10:03,340 --> 00:10:05,140 Mental models, number one. 269 00:10:05,140 --> 00:10:09,953 Now Tom Love was the inventor of Objective C, 270 00:10:09,953 --> 00:10:10,786 who said this. 271 00:10:10,786 --> 00:10:12,930 And Tom Love works for the Department of Defense 272 00:10:12,930 --> 00:10:15,460 on very, very, very large projects. 273 00:10:15,460 --> 00:10:17,197 But he said that, "let's imagine a project 274 00:10:17,197 --> 00:10:20,237 "that's gonna end up with a million lines of code or more. 275 00:10:20,237 --> 00:10:23,397 "The probability of that project being successful 276 00:10:23,397 --> 00:10:26,320 "at least in the United States is about 50%." 277 00:10:26,320 --> 00:10:29,490 This is a nasty thought that once projects 278 00:10:29,490 --> 00:10:31,210 get over a million lines of code, 279 00:10:31,210 --> 00:10:33,130 they're probably going to fail. 280 00:10:33,130 --> 00:10:34,400 This is scary. 281 00:10:34,400 --> 00:10:36,280 But why is Tom saying this? 282 00:10:36,280 --> 00:10:38,590 He's saying it because he identified that 283 00:10:38,590 --> 00:10:42,970 a ream of copy paper is about 10,000 lines of code. 284 00:10:42,970 --> 00:10:43,803 Now put that in your head. 285 00:10:43,803 --> 00:10:44,790 I mean, we can all imagine 286 00:10:44,790 --> 00:10:46,360 what a ream of copy paper looks like. 287 00:10:46,360 --> 00:10:48,100 I'm sure we've all touched a ream 288 00:10:48,100 --> 00:10:49,830 at one point of time in our lives. 289 00:10:49,830 --> 00:10:52,160 That's 10,000 lines of code. 290 00:10:52,160 --> 00:10:54,760 What Tom is saying is that a developer, 291 00:10:54,760 --> 00:10:56,803 the average developer really can't maintain 292 00:10:56,803 --> 00:11:00,160 a mental model of code beyond that 10,000. 293 00:11:00,160 --> 00:11:01,990 When we talk about maintaining a mental model, 294 00:11:01,990 --> 00:11:04,360 I don't mean memorizing every line of code. 295 00:11:04,360 --> 00:11:05,670 What we mean is that you know 296 00:11:05,670 --> 00:11:07,380 where everything in that code is. 297 00:11:07,380 --> 00:11:08,680 If I ask you where this function is, 298 00:11:08,680 --> 00:11:10,240 if I ask you where certain things are, 299 00:11:10,240 --> 00:11:11,780 you can find it quickly. 300 00:11:11,780 --> 00:11:13,390 You know how the flows work. 301 00:11:13,390 --> 00:11:14,780 You know how variables are named. 302 00:11:14,780 --> 00:11:18,180 You understand the code base intimately enough 303 00:11:18,180 --> 00:11:20,090 where if there is a problem, 304 00:11:20,090 --> 00:11:21,940 you can probably go to the code, 305 00:11:21,940 --> 00:11:23,650 identify where to start looking, 306 00:11:23,650 --> 00:11:25,960 and start reading that code very, very quickly. 307 00:11:25,960 --> 00:11:27,250 That's the mental model. 308 00:11:27,250 --> 00:11:28,780 This is what we're looking for. 309 00:11:28,780 --> 00:11:30,630 And Go is going to allow us to do this, 310 00:11:30,630 --> 00:11:32,850 because we're gonna be able to write less code. 311 00:11:32,850 --> 00:11:34,870 But this is really what happens. 312 00:11:34,870 --> 00:11:36,100 If the average developer 313 00:11:36,100 --> 00:11:38,660 can only handle 10,000 lines of code, 314 00:11:38,660 --> 00:11:41,280 then once a project goes beyond 10,000 lines of code, 315 00:11:41,280 --> 00:11:44,020 you need a new developer on that project. 316 00:11:44,020 --> 00:11:45,800 And when we start talking about code bases 317 00:11:45,800 --> 00:11:47,680 with a million lines of code, 318 00:11:47,680 --> 00:11:51,128 we're talking about 100 developers on that project 319 00:11:51,128 --> 00:11:53,620 if we really want to maintain our mental models 320 00:11:53,620 --> 00:11:55,310 and the health of the project. 321 00:11:55,310 --> 00:11:56,910 And I don't know about you, 322 00:11:56,910 --> 00:11:59,240 but historically I've only ever worked on teams 323 00:11:59,240 --> 00:12:01,160 of about three or four people. 324 00:12:01,160 --> 00:12:03,120 And I can tell you, it is difficult 325 00:12:03,120 --> 00:12:05,188 to keep three or four people rowing the boat 326 00:12:05,188 --> 00:12:08,690 in the same direction every day. 327 00:12:08,690 --> 00:12:11,300 Imagine trying to do that with 100 people. 328 00:12:11,300 --> 00:12:13,350 This is why these projects fail. 329 00:12:13,350 --> 00:12:15,510 As the larger the code base gets, 330 00:12:15,510 --> 00:12:17,920 it's not even so much a technical issue anymore 331 00:12:17,920 --> 00:12:20,540 beyond the fact that you have to manage more people. 332 00:12:20,540 --> 00:12:22,650 You have to maintain these mental models. 333 00:12:22,650 --> 00:12:24,330 You probably don't have even one person 334 00:12:24,330 --> 00:12:26,710 that knows the full mental model of that code base. 335 00:12:26,710 --> 00:12:30,250 It really becomes both a technical and a management issue. 336 00:12:30,250 --> 00:12:32,510 So we really want to focus on lines of code 337 00:12:32,510 --> 00:12:36,480 and reduce it and to identify the health of our teams. 338 00:12:36,480 --> 00:12:37,820 We really need to understand is there, 339 00:12:37,820 --> 00:12:41,290 that 10,000 to one developer balance. 340 00:12:41,290 --> 00:12:44,900 Now cognitive load is really, really important. 341 00:12:44,900 --> 00:12:47,577 Brian Kernighan said this best, 342 00:12:47,577 --> 00:12:48,837 "the hardest bugs are those 343 00:12:48,837 --> 00:12:51,667 "where your mental model of the situation is just wrong, 344 00:12:51,667 --> 00:12:54,320 "because you can't see the problem at all." 345 00:12:54,320 --> 00:12:56,320 And everybody knows that debugging a program 346 00:12:56,320 --> 00:12:57,770 is twice as hard as writing it, 347 00:12:57,770 --> 00:12:59,180 so if you're clever when you write it, 348 00:12:59,180 --> 00:13:00,650 how are you gonna debug it? 349 00:13:00,650 --> 00:13:02,900 People find this really interesting, 350 00:13:02,900 --> 00:13:06,900 but historically I've been writing software for 30 years. 351 00:13:06,900 --> 00:13:10,080 Historically, I never allowed developers on my team 352 00:13:10,080 --> 00:13:13,460 to use a debugger without asking for permission. 353 00:13:13,460 --> 00:13:15,430 This is primarily because when there is 354 00:13:15,430 --> 00:13:17,300 a problem in production, 355 00:13:17,300 --> 00:13:20,040 all you have is your mental model of the code base 356 00:13:20,040 --> 00:13:21,587 and the logs that you're writing. 357 00:13:21,587 --> 00:13:23,990 But if these are not helping you find bugs, 358 00:13:23,990 --> 00:13:25,050 you're done, you're lost. 359 00:13:25,050 --> 00:13:26,980 You're not gonna hook your debugger 360 00:13:26,980 --> 00:13:28,910 up into your production environment. 361 00:13:28,910 --> 00:13:31,310 And I'm not saying that debuggers are necessarily bad. 362 00:13:31,310 --> 00:13:32,143 They are a tool. 363 00:13:32,143 --> 00:13:35,350 But they shouldn't be your first tool to finding the bugs. 364 00:13:35,350 --> 00:13:37,330 They're great if you've got a brand-new code base 365 00:13:37,330 --> 00:13:39,680 and you want to understand how it flows, 366 00:13:39,680 --> 00:13:41,860 but I have a 20 minute rule, 367 00:13:41,860 --> 00:13:43,550 and that 20 minute rule would say 368 00:13:43,550 --> 00:13:45,220 leverage your mental model, 369 00:13:45,220 --> 00:13:48,220 leverage your logging to find that bug. 370 00:13:48,220 --> 00:13:50,170 And if you can't after that, we'll turn it on. 371 00:13:50,170 --> 00:13:51,680 But we've got a refactoring problem 372 00:13:51,680 --> 00:13:52,970 in front of us at this point, 373 00:13:52,970 --> 00:13:54,750 because we've lost it, right? 374 00:13:54,750 --> 00:13:58,610 So I don't want us becoming attached to debuggers. 375 00:13:58,610 --> 00:14:01,900 I want us to focus on our mental models 376 00:14:01,900 --> 00:14:04,370 and really also making sure that we create logs 377 00:14:04,370 --> 00:14:06,350 that have more signal to noise. 378 00:14:06,350 --> 00:14:08,107 Because I love this quote, 379 00:14:08,107 --> 00:14:09,950 "debuggers don't remove bugs." 380 00:14:09,950 --> 00:14:10,783 They really don't. 381 00:14:10,783 --> 00:14:12,790 "They just show them in slow motion." 382 00:14:12,790 --> 00:14:13,720 At the end of the day, 383 00:14:13,720 --> 00:14:17,780 we've got to refactor that code cleanly 384 00:14:17,780 --> 00:14:18,930 so those bugs disappear. 385 00:14:18,930 --> 00:14:22,060 But at the same time, if more bugs start to show, 386 00:14:22,060 --> 00:14:23,980 I don't need to waste time on the debugger. 387 00:14:23,980 --> 00:14:26,513 Our mental models, our logging, it all helps.