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.