Conf42 JavaScript 2022 - Online

Clean, Concise, Collaborative Code

Video size:

Abstract

I have worked in the industry on and off since the year 2000. I now teach code at The School Of Code. I have a passion for seeing code that is at it’s best and the most friendly for every skill level, whilst still maintaining effectiveness and completeness. This talk has been given in the PHP world several times, and each time this has prompted strong discussion around the definitions of how this might look in practice.

Summary

  • Jamaica real time feedback into the behavior of your distributed systems. Errors in real time allows you to not only experiment with confidence, but respond instantly to get things working again. Liz Kaufman asks Chris Miller six questions about clean, concise, collaborative code.
  • Is your plan extensive enough to help someone else? Is your code abstracted enough to minimize load? And is your code clear enough that a nondeveloper can understand it? Which is a scary question, which is why I put it at the end.
  • A plan is looking at the flow that you're going to take in the code. Do the logic first, and then layer on the code after you've got that plan. Is the path clear enough with every step planned?
  • We put a lot of emphasis at the school of code on pairing and on making sure that the plan is good enough for everybody. A senior can often forget that there are certain things that a junior might not know and conversely, a junior can come up with some brilliant ideas. In a modern tech environment, employers want people who can do this planning process.
  • Is your code abstracted enough to minimize load? Do you think that that carries through to code? Is there a time where you can over abstract or under abstract?
  • So sort of tied into abstraction is the idea of encapsulation. All data should be in a single class that needs to be there. All related things should be easily identifiable. No data inaccessible should be needed. And also in terms of swap. I'd like to think of it as like swap ability as plug and play.
  • Is your code tested enough to be confident? The more your best resemble the way your software is used, the more confidence they can give you. Keeping that user at the center will set you right, not have you bogged down into the weeds.
  • Is your code documented enough to be helpful? What do you think documentation should look like? The sweet spot differs for each tool. There's been a good industry shift toward more friendly documentation. It's important for future you, not just other people.
  • For me, documentation tells you how to get set up and what the code does. But it doesn't need to tell you line by line what each specific thing is doing. I like function names that should say what they do in verb tense and present tense. Testing gives you a leg up on documentation and using conventions like calling things actual.
  • Is your code clear enough that a non developer can understand? Because developers are not in silos anymore. Putting that user at the center will make the lives of your fellow developers so much easier. We want people to have easy, blissful lives.
  • If you were hit by a bus tomorrow, could anybody else pick up your work? If the answer is no, perhaps it's time to revisit some of your code. The panacea of code that can be run by anybody.
  • Liz: Why does clean, collaborative coding matter? Chris: I think it matters because, like I said before, coding is hard. Let's have that rule of leaving the code better than when you found it. If you want to know more about the school of code, please head to school of.

Transcript

This transcript was autogenerated. To make changes, submit a PR.
Jamaica real time feedback into the behavior of your distributed systems and observing changes exceptions. Errors in real time allows you to not only experiment with confidence, but respond instantly to get things working again. You. Hello. So we've been invited here to talk to you about clean, concise, collaborative code, and I thought we'd start with introducing ourselves. So I'm Chris Miller, head of IT and development at School of Code. Been working with computers since 2000. Professionally been using computers since 1983, back when eight colors was considered fun. Liz, do you want to introduce yourself? Absolutely. Hi, I'm Liz Kaufman. Great to be here as well. After graduating with a history and archaeology degree. Still didn't know quite what I wanted to be when I grew up. Worked in project management and operations in the private and public sector till nearly 30, when I thought, if not now, when? I'm going to follow that little what if in the back of my head toward technology. Heard about a thing called the school of code boot camp, saw that it was free and thought, oh, I'll give this a go. And I discovered as a boot camper that code is the closest thing to magic in real life. And then after graduating as an assistant coach, coach and lead, lead, lead, lead coach and head of bootcamps School of code, I have helped share that magic with over 300 people and counting. Amazing. And it's great to be able to help hundreds of people each year. And the number of those boot campers that talk about our course being life changing, changing is incredible. So we're going to have a look at six questions, Liz, and we're just going to chat through them and see what we come up with. So if I go to our next slide, here are our six questions. So we're going to start by looking at plans. And is your plan extensive enough to help someone else? Is your code abstracted enough to minimize load? And that's talking about the mental load. Is your code encapsulated enough to be clear? Is it tested enough to allow you to be confident? Is it documented enough to help? And is your code clear enough that a nondeveloper can understand it? Which is a scary question, which is why I put it at the end. Absolutely. So let's start with that first question. Is your clean extensive enough to help someone else? What do you think a plan looks like this? I think a plan, and we go on a lot. Any boot campers listening or ex boot campers will have a little bit of a flinch when they hear the word plan because we go on about it so much during the boot camp. But I think a plan looks like, if you think about all of the logic that's going to go into what you're trying to accomplish with the code, and you break that down and keep breaking it down, break it down until you cannot break it down anymore, that computational thinking, that first stage of computational thinking, where you break it down into those little bitty chunks, I think that's the foundation of a good plan. Because, let's face it, especially for people new to code, but probably for people everywhere, the logic is hard, and the syntax is hard. So, trying to do both of those hard things at the same time, recipe for trouble. So, why not make it a little bit easier on yourself, on your fellow developers, on anyone else helping out or coming across this work by separating those out. Do the logic. Break down that logic first, and then layer on the code after you've got that plan. What about you, Chris? What do you think? So, for me, a plan is looking at the flow that you're going to take in the code. So, yes, you can break it down to the minute details, and experience will tell you when you've got far enough for you. So, as a beginner, yeah, by all means, go to the deepest level. As a senior, you may just be able to say, I want a request all from this database table. The sort of way that I generally talk about it is that, is the path clear enough with every step planned? So, is that clear enough for somebody else to look at your plan and go, oh, yeah, I can see where you're going. Does that mean that you have to detail every mortal minor thing? Not always. Sometimes, yes, you do. It depends on who you're talking to and who you're with. So, normally I'd say, let's go through a plan together. You're up for perhaps working through a plan just out loud on how we might do something simple. So, let's talk about a calculator. Now, imagine we want a calculator that handles whole numbers only, and we want it to be able to add two, divide two, subtract two, and multiply two. What might your clean look like for that? Yeah, I think for me, I would separate them out. I would tackle each of those functions. So the addition, the subtraction, the division, the multiplication, I would tackle them. I'd start with the basics. We always say you can iterate on a plan multiple times to get it right. So a basic plan might be, hey, I want to put a couple of numbers in, and I want to get one number out. That's the sum of these two numbers. Okay. That's one level of the plan. Then you take another pass at it, get a bit deeper. Okay, so what's going to happen? Maybe I need to have some parameters, have some functionality, have that operator. Okay, what operator do I need? Let's pseudocode this out. This is very simplified for addition, but the pattern track. So pseudocoding that out, what do we need to return? What type does it need to come out as? How is it going to be expected in places where this function might be used? How are we thinking making it reusable? Lots of things to keep in mind. So yeah, I love how you're saying like, you don't have to go into the minute detail as a general rule, but the level of detail that you need, like you said, to help somebody else read that plan. So stepping through it in each of those operations and seeing if there are any pitfalls as well. Any pitfalls. Because running into pitfalls during the plan is always a little bit less scary than running into pitfalls during the actual code, for sure. Absolutely. And actually there is a pitfall in that plan, isn't there? So we've got the idea of adding numbers together and producing a whole number at the other end. What's three divided by two? Yeah. And as you step through, you're like, oh, division. Division might give us a little problem there because we've got our friend the decimal coming in. Yeah. So then you discuss how you'd handle that. So we might decide to round up, we might decide to round down, or we might decide to change the original plan and have a decimal for that, or a floating point, as it's called in code. And that discussion can happen between the developers, between the people that have come up with the original request. But that's why we plan. For me, it's about finding out where the pitfalls are, getting a plan ahead, and if I disappear tomorrow, somebody else can pick up my plan and run with it. Or at least that's the dream, I think also just to cut in there. When we talk about walking the walk with agile methodology as well, we're talking about iterating. We're talking about going back to those stakeholders, the users, the other people in your business, and if they've given you a brief, if they've said, hey, I want this calculator to only kick out whole numbers during the plan. If you find out that division issue, you've got some floats in there that might throw that back. You can go back to them early and you can be honest and say this doesn't match up. And that's that really agile, that old picture. If you google it with like, it starts with a skateboard, then a scooter, then a bicycle, then a car, you can go through those stages earlier on in the process to refine the whole ask. So I thought that was a really important part that people don't often think about with planning as well. Absolutely. And it also becomes part of the documentation of how you've developed this. So it's something that other people can refer back to, because if you've solved a problem and you've got the plan for how you solved it, then somebody can take that plan and solve a different problem that's similar. Exactly that. Finding those patterns at algorithmic thinking, for sure. Yeah, plans are definitely useful, but I think that's like the very first step. I think we then get on to the next step, which would be, can somebody understand and execute that plan? So that's where it's useful to think about the language you're using in your plan, perhaps. So if I'm using terms that the team aren't going to know, you don't know PHP, for example, whereas I do. So if I came to you and said, well, we're going to create a trait that we're going to attach to an abstract class, you're going to look at me, we're going to do what now? And it's about thinking that language through looking at how it interprets to the next person. And sometimes that language is unavoidable. And what I'll do in that is, even though I'm writing the plan primarily for me, I'll actually put the definitions in for anything that looks a little odd or linked to some documentation on how it works. Definitely. I think that's really important to have that ability to make that plan readable. So like you said, links to documentation, defining any buzzword. So you clean, take it to other people. Also, we put a lot of emphasis at the school of code on pairing and on making sure that when you are working with other developers that might have those differences in experience in what they specialize in, in what languages they code in, things like that, that we make sure that the plan is good enough for everybody because it's a bit of a toxic environment. If you say, well, okay, I've made a plan, put the, I can't even remember what you said about the PHP lingo there, and then move on, start developing, and you've got a junior developer. If you're a senior developer, you've got a junior developer sitting there next to you, ostensibly pairing, ostensibly learning from you, and they're still not clean about what's happening in that plan. That's not going to be good for them. Then it's not going to be good for you either when it comes time to hand something over to them or work with them, or if you get hit by a bus, if heaven forbid, that fosters that environment where you're not truly pairing, working together. Yeah, for sure. Absolutely. And that pairing process actually plays into how you write the plan, because a senior can often forget that there are certain things that a junior might not know and conversely, a junior can come up with some brilliant ideas. I've been in scenarios where the junior developer in the situation has given me a solution that I hadn't even thought of, and then the senior in the situation has gone, yeah, that looks fun, let's try that. It's amazing how just having a conversation makes a difference. And I mean, we all know the old stereotype of developers in a corner, headphones on, not talking to anybody. That stereotype is fast disappearing. I'm not seeing that as much in the industry anymore. No, for sure. That's kind of our whole ethos that if you want to learn to code like that, you can still, you can go on the free solo resources out there and put your head down and do that. But in a modern tech environment, the employers that hire from school of code want people who can do this planning process, who can collaborate, who can talk to other people and not just computers, for sure. Absolutely. So let's take a look at our second question. Is your code abstracted enough to minimize load? So we've got that illustration there of the three different hearts. I love that picture. Do you think that that carries through to code? Is there a time where you can over abstract or under abstract? Yeah, I think it does, and it's hard for, especially when you're just starting out, to know where that line is. I might nick that picture for some of my slides for the boot campers, actually. I think because that's a good illustration of it, that you can spend time putting all the detail in one big old file, that cognitive load doing it to death. That might be easier at first. So recently we taught the exprs JS framework. We were writing servers using javascript and exprs, and we go from writing everything, all of the code for your server in one big old app js file. And then when we split off into things like the routers being separate or the actual models that are talking to the data being separate. Everybody starts to panic and everybody goes, oh, I don't know what's happening. Code is going everywhere. So it's showing them, it's finding that balance. Yes, it is a little bit harder at first to start splitting things out, to not have that comfort blanket of everything being in front of you in one place. But then when things get more complicated, when you have like hundreds of lines of code in one file, then they start to see, okay, now it's a lot easier if I don't have to parse through all of my routing, all of that sort of governance, getting the path parameter up just to see how this one thing works. So yeah, definitely. What do we think abstraction is? For me, it's showing what's needed at the time and hiding what's not needed right now. So like you were saying about the routers, do we need to know the ins and outs of every single route when we're looking at how the server stands up? Not really. Do we even need to know how the controller is handling the input if we're looking at what the root is? Well, no, not really. And I think that's part of what plays into abstraction. It's thinking about what do we need to make that clear at that time? So if I'm in a file, do I need to know about the thing that we've got there? If not, let's put it somewhere else. Yeah, I think an important bit on that as well is if you do need to know, making it clear where to find that somewhere else. So making it clear with, if you've abstracted some logic away into a function, name that function, well, say in the name what it's doing, and then have your file structures organized so that you have some breadcrumbs, so that you've got a file path, so that that's in a logical folder. So if you do need to go under the hood and see what's there, it's not a panic, it's not a black box, it's away for now, but it's not out of reach if you need it. Yeah, absolutely. And that naming convention really helps. That's actually one of the hardest things in development is looking at how to name something. I mean, what do you do if you've got three things that are called user, do you call them user a, user b user C do you call them active user, suspended user, user, do you call them. And again, it comes back to that same thing, talk to people, because names don't actually matter. To the code. We could call it whatever we wanted to. We could call our users fish if we wanted. Yeah, you're not going to help it. Example, during class they go, why are we calling it that? I'm like, look, I'm going to call it potato and show you that the code still runs. Boom. So sort of tied into abstraction is the idea of encapsulation. So I come from an oop background. So encapsulation is a bit clearer in there where you'd have a class, you'd have some public methods that are visible to everybody and then you'd have some variables inside that that are hidden away. And that whole thing encapsulated together gives you this idea of exactly like it shows a pill that we can look at and we can see that all of those things make sense together. Now you come from a slightly different background of functional programming. What do you think that looks like for you? Yeah, I think that looks like a little bit like we were talking about before encapsulating things almost in terms of abstraction. So we were talking about before with the routes and the methods of the server. So with that methods file, for example, if you are talking to data, we often tell boot campers like that methods file, it does not know that it's in a router. It does not need to know that. However, it does need how it's connected to the database. It needs how it's going to get that data. Even though it's not in a class, even though it's a bunch of functions in a JavaScript file, they're not neatly wrapped in that little capsule like your illustration there. We still need to lay out what that file needs to see what needs to be in scope there. It needs to take in, it needs to import in how it gets what it needs. It needs to import in any sort of config, any sort of things it needs and then it needs to expose. So thinking about what it exposes as well, exposes those functions, exposes that functionality in a way that elsewhere it can be picked up. So thinking about what it needs to run and what it needs to expose to make that run. And also in terms of, I think we also emphasize there, swap. There's probably Chris, you will know a better word for this, but I'd like to think of it as like swap ability as plug and play. So in terms of that connection to the database, for example, if you go from last week, we had an issue where one of our database providers went down and we had to quickly shift to another one because all of our code was all encapsulated neatly in that file, except for that connection string to that database coming in. We could just unplug that connection string, plug in a separate one to that nice little capsule, and get up and running again very quickly. Yeah. And what you're actually talking there is what professionals would talk about, the solid principles which I know we introduce on the boot camp, and we talk about dependency inversion, so not being so reliant on something else that we can't swap it out. And we often take very complex principles and we teach it with boot campers in simple language. And often I find that when we've taken that and explained it to somebody, they can go, yeah, I can do that. But you tell them to do dependency inversion, they go, do what now? I mean, to be fair, that's exactly what I do as well. Every time I look at the words dependency inversion, I have to google what it is. Yeah, same. You can see just there. I just could not think of the proper word for it. But yeah, I like how you explained it to me a few minutes ago before we started rolling, putting stuff together that goes together, keeping things tied together in a sensible way. So really looking at your code and saying, does this make sense to be here? Kind of giving it that vibe check, as the youth say, each little bit, does this make sense to be in here? Or does this make more sense to be somewhere? I mean, I've just shared a few points that I've pulled out from oop. But change the word class to file functions and it still applies. So I've got all data should be in a single class that needs to be there. All methods should be in that place. All related things should be easily identifiable and all unrelated things should be easily distinguishable. No data should be accessible that's not needed. And no data should be inaccessible that is needed. So a common example that I've used with boot campus, when I'm talking about that idea of data being accessible or inaccessible. Imagine we've got a user and we've got a password attached to that user. Do we ever want to be passing that back to the front end? No. So that should be inaccessible. But do we need it on the back end? Sometimes we need to be able to read and write from it. So on the back end, yes, we want that to be accessible. And that's where the difference can come in, even with how we present the same item dependent on where we are in code. And often we'll think about that and sometimes we'll forget and of course, we make mistakes. We're human. But that's where having the concept of code review and pull requests comes in. I have no problem with somebody looking at my code and going, actually, there's this wrong over here. Or we could do this another way. I mean, I've been developing on and off for 22 years, and I'm still learning, and I still have those days where I think I'm not capable of doing this. And I'll let you know when that whole concept goes away. But 22 years and counting so far. Yeah, we're still waiting on that. Oh, my goodness. Same. Absolutely. And then even code reviews are really cool to do that, to get that second opinion. But going back to pairing as well, it might be really intimidating, like you're saying, to think, okay, have I gotten this exactly right? Am I doing the right things? Am I exposing any sorts of risk but having someone sitting beside you to bounce things off of, to just do this in a conversation, getting that different perspective, you don't have to go alone. This doesn't have to be solo mission. And that kind of ties into the whole collaborative thing. That code isn't a solo sport anymore, and it's something that we work together on to get the best end result. And you put two minds with different opinions, and you're going to end up with a brilliant result so long as those people are able to converse and not fall out over simple things. Absolutely. So let's have a look at a question that I guess kind of ties into everything we've just covered, which is, is your code tested enough to be confident? So on the screen, we've got unit best forming the base of a pyramid, integration tests on top, end to end tests sitting on top of that, and then manual tests, almost like an afterthought. So does that mean manual tests are a bad thing? Does that mean that we need all of it? Where do you think testing fits in? Yeah, that is an interesting question. I think another thing that might make xbootcamp precise twitch here is the word trade off. So everything we always emphasize everything is a trade off. And this includes testing. It's so easy when you first start learning testing to have so many people going. Testing is super important. Is it really important? You got to spend, like, 200% of your time testing for every second you code tests for 5 seconds. It's important to put it in that context, that wider context, though, of what do you need to test? And I really like what you put on that slide there. Chris, is your code tested enough to be confident. Are you confident that the user is getting what they need? Are you confident that other people can work on different parts of your code without what you've worked on falling over? So if I add something to your code, I can run the test that you've written and go, okay, I've added this new feature, but I haven't broken Chris's work. He's not going to come knocking on my door saying, you broke my code from two days ago. And just to also sum this up, Kent C. Dodds, who I'm sure that lots of people will be familiar with, has a good quote. The more your best resemble the way your software is used, the more confidence they can give you. So I think really keeping that user at the center, whether the user is the person using the software out in the real world or the fellow developer who's adding to it and wanting to replicate, make sure you haven't broken it. I think keeping that user as the focus and that confidence will set you right, not have you bogged down into the weeds. Absolutely. And Brennan Keller has another great quote from Twitter. He says, a QA engineer walks into a bar, orders a beer, orders zero beers, orders 999,000,000 been, orders a lizard, orders minus one beers, orders a random set of letters. The first real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone. Now, that, to me, shows that we could write tests that cover absolutely every edge case for our function. And we can go, yes, we can handle been. But we forgot about the bathroom, which is kind of important. Yeah. I was writing a word counter for fun on a personal project, and I counted if there's one space, if there are two spaces, if there are three periods in a row without spaces, if there's a new line. I forgot about the fact that you could have more than one new line. It would put that as a break. Tag in the HTML and then squidge two words together when that HTML was stripped. The same thing. Yeah, it's those simple little things that we often forget of when we're looking at code. If we're doing it, whether we're doing it for fun or professionally, really, we can forget some of those edge cases. And again, that's the concept of talk to people, show it to your user. I'll often take code I've written and give it to the user early, as early as I can. I'll put it in front of a user and I'll go, this isn't yet complete, but can you tell me whether this bit works? Like you expect it to. Yeah. And if I've has the answer of yes to that on ten different things, then when I give it to them at the end for UAt or user acceptance testing, then usually that's a lot shorter because they've already seen it and they can go, yeah, that bit works. And it's just running through it again to check nothing's changed when we've put all those little bits together. Yeah, I think with cognitive diversity as well, because we each come from our own perspective, we know how we would use the software. But the amount of times that I've been surprised when I hand it to somebody and like in your example here, they do something completely different, I'm like, okay, you need to click these button, that button, that button. I have my lovely journey. I've got it in a flowchart, got it in my wireframes. They just skip three stages and wonder why it doesn't work. No, you're not supposed to do that, but you can't say that to all your users. You need to see them do those deviating paths to figure out what you couldn't have expected. There's that brilliant meme, and I wish I'd got it to hand of the cat feeder. Three feeders. And user experience is easy. You put one cat in front of each one. But cats are like users, and they come up with the most complicated way of doing it ever. And they're crossing over, they're underneath each other, they're over the top of each other. Sounds like most users. Fair enough, fair enough. Users, cats, we love them both. So the next question. I've got a picture of a book on there. Excuses for not writing documentation. I've read that book and I've used them all. Is your code documented enough to be helpful? So what do you think documentation should look like? Oh, that is the age old question, because I know there are so many different views. Talk to people who think that good code should fully self document it. That's a nice buzzword. Self documenting code with your naming conventions, with all of that clean code aesthetics. Then I've talked to people who think, comment everything, make sure that everything is absolutely. Got a comment saying what it does, what it ate for breakfast that morning, all of that good stuff. But I think that the sweet spot differs for each tool. It differs for the intended audience of that tool or that piece of software that you're writing. And I think that there's been a good industry shift that I've noticed toward more friendly documentation. So sometimes you get to documentation. It's full of really technical terms, it's really impenetrable. And you think, okay, I'm not in the cool kid treehouse, I don't belong here. I don't know enough to even start reading this documentation. Whereas things like the new react docs that I think are still in beta, they might have released them yet, but that is a really good example of how plain language can really help documentation be usable for people across the spectrum, from juniors up to seniors. In addition, one of the other points of documentation I really like to emphasize is it's important for future you, not just other people. Because if you're writing some software today, I guarantee you, because I've done it a million times before, you will forget what the intricacies were that you were really close to like six months down the line. So in terms of being helpful, what's going to help you in the future? Use it? What is it for? What do you need to run it? How do you run it? What does it do? Where could it go wrong? Those tent posts, what are you going to need to use this in the future? What are other people going to need? Yeah, I've just switched to the next slide because you've actually spoken exactly about that balance between documentation, which is brilliant. So for me, the way that I look at it, and you're absolutely right, there's a million different trains of thought on what documentation looks like. But the way I work through it, I've gone through documentation where I've done a comment on everything that explains exactly what that line is doing. One plus one. This adds one and one together. I can guess that from the fact that it says one plus one. But I've also gone through times where I've not written a single thing and then a week later tried to stand up the same software and gone, how do I do that? So for me, documentation tells you how to get set up and what the code does, but it doesn't need to tell you line by line what each specific thing is doing, especially if it's self explanatory. Now, sometimes you do need to put in some comments in your code to help understand why you've done certain things. So a while back I had a function where a number was changed from an integer to a string and then to a float. Now that seems like a really stupid thing to do, and it probably was, but the context was that the calculation needed it as an integer, the front end needed it as a string, and the database needed it as a float. So I explained at the top why that was happening. People could see what was happening because we had functions convert to string, convert to integer, convert to float. But explaining why we'd taken that route means that somebody else doesn't have to scratch their head for ten minutes trying to work it out. Yeah, if you've already done all that work to figure that out, don't make other people do that work as well. Leave that logic, leave the result of that work. You didn't. There's a method to my madness, folks, and this is it. Make people's life. Definitely, I think as well. We were talking earlier about semantic naming and the importance of things like that, so I think those really help tip the balance a little bit more toward not needing to document with comments what is self explanatory. And something that I find as we're teaching how to do this well, good functions, especially in functional programming. I'm coming from that my javascript has on, rather than your Php hat. I like function names that should say what they do in verb tense and present tense, like greet, like calculate, like add, things like that, which is pretty basic stuff, but it makes a huge difference. And then one of the bugbears is that people have a beautiful function name, and then they call what they're taking in x, they call that parameter x, and it's just like you've nearly gotten to the edge and then you've just not crossed the finish line. So for example, with our calculator, we could say add and take in X and Y. Add is beautiful documents. What it says on the tin X and Y, though vague, especially if you're doing something more complicated. So you could say first number, second number, something like that, number one, number two. There's multiple ways of calling the same thing, but making it clear, I try to think about code like it's telling a story. So if you're telling a story with your code, you're not going to read a story that says Bob went to f and on the way he took x and y. When he got there, he gave z to Bob. Oh God. Or you could go something like, bob took a journey on the way he went through the calculator, and in the calculator he chose to use add, and he added number one and number two together. At the end he took out the answer and he gave that to the next person. Yeah, he returned some and he gives away. Yeah, absolutely. That goes in. Testing has, well, because one of the benefits of testing is that it gives you a leg up on documentation and using conventions like calling things actual, calling things expected, using the three a's. So that's a range act assert. I mean, I'm giving examples, what I'm familiar with, but other conventions are available. But having things like that can be as intimidating, as obtuse as testing. Read like a sentence. So expect add two plus two to be what it actually is. So expect the actual to be the expected to be. It reads like a sentence. Things like that are really powerful, those conventions as well. So we're heading towards our last question, and this kind of ties into what we've just been talking about, that whole idea of storytelling. Is your code clear enough that a non developer can understand? Now, why would we say non developer? Because developers are not in silos anymore. Like you were saying, chris, the days of the hoodie, all the way up the dark corners, big headphones, can of energy, drink, the don't bother me face. Unfortunately for some, those are over now. People are involved, other people in the business, other people in your team. We've got tech adjacent roles. Some of our boot campers go, they get a foundation in coding from our course, but they don't always go into developer role. So you've got product owners, you've got business analysts, you've got people around you, designers. People need to look at your code and get that understanding of what it does. Not how it does, but what it does on that level that they can do their jobs. They can be part of that ecosystem as well. Yeah, and boot campers get fed up of hearing me say, if a non developer can understand what is happening, even if they don't understand how it's happening, then we've achieved what we want to achieve. Absolutely. Putting that user at the center, and if it's clear enough for that non developer, it will make the lives of your fellow developers so much easier. We want people to have easy, blissful lives. Code is hard enough, so let's not make things harder on ourselves and our fellow developers. Absolutely. And I've been in code bases where it's definitely not that, and I've been in code bases where it definitely is. And I know which I prefer working in. You're here. So you kind of alluded to this earlier on, but we sort of finish with that bus factor idea. If you were hit by a bus tomorrow, could anybody else pick up your work? If the answer is no, perhaps it's time to revisit some of your code, some of your processes, to refine that a little bit further, to make it possible for somebody to take over. Now, do we ever get to the point where we're completely indispensable and it's just a number? No, but that's the ideal to aim for. If I can take myself out of the scenario and the system can carry on, whether that's a code system, a business system, a teaching system, if that can carry on with me out of the scenario, then actually we've got to the panacea of code that can be run by anybody. Absolutely, yeah. It's taking away that precipice where you start to stress and you start to worry again. It's taking away that stress. Making things easier for the users, making things easier for your fellow developers, people you're working with. It's good for the ego to have everything depend on you. And we do a lot of work on the boot camp in terms of taking your ego out of code. You can be amazing and a great coder and be respected by your colleagues without having to be the source of knowledge, without having to be that guru in that tower. Oh, Bob is the only one who knows how this works. We must bow down to Bob. No, that has gone out of the window with that hooded coder in the corner on their own. We need code that. Like you were saying, chris, anybody can run, anybody can add to, anybody can maintaining as well, for sure. Absolutely. So, anything you want to close with this? I don't think so at the moment. I think we covered a lot of my bugbears and a lot of what keeps me sane in coding. So I appreciate the opportunity to chat with you, but just in terms of, why does clean, collaborative coding matter? And I've forgotten your other c. Chris, I'm so sorry. Concise. Concise. There we go. I'm not good at being concise, as you might have been able to see. I think it matters because, like I said before, coding is hard. Doing these logical coping with all of these factors, all of this logic in our brains is hard. So let's do all we can to make it more easy, more pleasant for ourselves, for our users, for other people in the business. Let's make life a little nicer. Let's have that rule of leaving the code better than when you found it. Let's make things easier on ourselves with clean, collaborative and concise code. What about you, Chris? I think you've just summed it up perfectly. It's that boy scout idea, isn't it, of leave the camp cleaner than when you're here. You're here. Absolutely. Wonderful. Well, thank you very much for joining me. Liz, and I'm sure that there will be questions for us. We are both on Twitter. You can find me at CC Miller 2018. And, Liz, yes, you can find me at. At codingbumblebee, which is a brilliant Twitter handle. Thank you so much. And if you want to know more about the school of code as well, please do head to school of. Excellent. Thanks very much, Liz. Thank you so much. It's been great. Thank you.
...

Chris Miller

Internal Services Lead @ School Of Code

Chris Miller's LinkedIn account Chris Miller's twitter account

Liz Kaufman

Lead Coach and Head of Bootcamps @ School Of Code

Liz Kaufman's LinkedIn account



Awesome tech events for

Priority access to all content

Video hallway track

Community chat

Exclusive promotions and giveaways