Waiting..
Auto Scroll
Sync
Top
Bottom
Select text to annotate, Click play in YouTube to begin
00:00:01
hey everybody casemirotori here we are at the end of our kickstarter promotional videos this is the last one it's a two-parter if you haven't checked out the kickstarter already please do it's for a graphic novel meow the infinite it's awesome we'd love to send
00:00:13
you a book or two please check it out when you get a chance this video is an invited lecture that i gave to a company called infuria.io and i submitted like a thing saying please give me topics that that you'd
00:00:26
like me to cover and one of the things that i saw in a lot of the topics that came back was sort of this underlying concept of like code kind of getting out of control like being you know to huge code bases and slow and underperforming
00:00:38
and so on and so this was my attempt to give sort of a general audience answer to the question where does bad code come from like where do these problems come from
00:00:50
this is a two-parter the first part is the lecture the second part will be the q a so i hope you enjoy it and i'll be back afterwards to talk about part two where does bad code come from
00:01:03
we kind of know that it's everywhere right now like there's a sense if you have experienced programming for a long time or if you just in general look at the way things are going from a
00:01:15
removed sort of more objective observer standpoint you can see that there seems to be a lot wrong with software today and first of all there's way too much code a lot of the times even fairly simple
00:01:29
pieces of software now are like hundreds of thousands of lines of code millions of lines of code and so on uh they're typically built in these very very fragile build systems
00:01:41
oftentimes so complicated that they end up having to be wrapped inside things like docker containers or things like this even to just try and get them to keep running into the future because they have so many crazy dependencies and
00:01:53
there's really no way to guarantee that all the things will remain working or will remain in lockstep as they move forward um when you actually do have everything installed properly on your machine and when you've finished having a package
00:02:05
manager install the language which installs some package manager which then goes and gets the packages which unpack which install their own packages blah blah after you manage to get all of that going and you actually can run a build the builds take forever sometimes things
00:02:18
like tensorflow or stuff like this that a lot of people use that are very popular projects seem to take hours to build sometimes which is absolutely incredible if you think about how much power computers have today that the
00:02:30
things could take that long to build when the actual software comes out the other end the quality is not very high there's a lot of sitting around waiting for it to do things like load or communicate with a network and it really
00:02:43
kind of just stalls while that's happening and doesn't really let you do very much it's slow when it actually does things things that probably should be much faster on today's hardware are not they're still quite slow
00:02:54
um it takes a ton of space as well so not only do these programs now take up huge amounts of space you have like 100 200 megabyte executables which is insane and their working footprints are like
00:03:06
many gigabytes of memory even for doing things that seem very simple like just scrolling some 2d images or things that are very basic nonetheless are taking tremendous amounts of storage tremendous amounts of memory it's just kind of very
00:03:18
odd that that would be going on and finally it's not like software got tremendously more reliable or something else happened it's still totally buggy and it has all the same problems if not more problems than it has always had
00:03:32
before it sort of jumped uh this level of sort of kind of complexity and and kind of in general this this overall uh overriding sort of sense of decay that seems to be seeping in
00:03:45
to whatever we call the software industry currently and so thinking about this if we want to actually try and talk about where bad code comes from we have to start making
00:03:57
some judgment calls about what do we mean when we say bad code anyway i can talk about all those things and and complain about stuff but if i don't really have some kind of a more specific understanding of what it really is that
00:04:09
i'm talking about it's not going to be possible for us to like get anywhere we can't really get anywhere fixing the problem we're just sort of saying that the problem exists which is great but we do have to then figure out how are we going to move
00:04:21
forward so i'm going to make a little bit of a judgment call here and say when i'm talking about bad code or what we should be concerned about with bad code it doesn't really have much to do with money if you're talking about wanting to
00:04:33
make money i don't think the current environment anyway at least for the time being really cares that much about the quality of your code i think there's so little competition in the software space right
00:04:44
now because there's so much software to write we're still relatively early in the evolution of software there's still so many places you can take software too that there isn't a lot of market
00:04:57
pressure to ship high quality stuff a lot of times consumers or whoever your customers are are choosing between a very small field of options so being someone who ships a
00:05:09
quality product while it may be a tremendous competitive advantage if you do it will not exactly be a requirement competitively because other people are not shipping quality software so you
00:05:21
really don't need this to make money yet you might in the future but i'm not gonna try and make an argument that you need to do this uh for your financial well-being of your company or your career whatever or anything like that and i'm also not claiming that people
00:05:34
aren't having fun or anything like that they might not be it may be that current software practices are really not fun for them but it could be that you know you just drop on your vr goggles and you you download a bunch of frameworks and you get them all called together
00:05:46
eventually and you just play around with it and you had fun and it was okay right who knows right so i'm not going to claim either of those two things because i don't think there's really any need to go down that route because all i'm trying to talk about when we talk about bad code is
00:05:59
like what's our potential like like what could we be doing what could we be doing engineering-wise versus where we currently are are we performing up to that potential at all
00:06:11
or are we actually kind of falling pretty far behind where we could be if we looked at what we could be delivering to our customers and to society if we took things more
00:06:23
seriously right so i don't think we have to do this it's just if you care about quality what are we talking about here so that's what i mean when i say bad code i say we're looking at something that seems like boy we should be able to do a lot
00:06:36
better than this why aren't we right now it's important to distinguish between two things i actually think as an industry we haven't done that
00:06:47
poorly on algorithms algorithms are actually understood in some pretty profound ways i think the people who have done all the work figuring out like order notation and what the complexity classes of things
00:07:00
are and you know they haven't proved whether p equals np yet or whatever but at the end of the day there's a lot of stuff we know like we know how to analyze hash tables and how to think about them we know
00:07:12
uh like what the properties are of a heap or what different sorting algorithms will do like we have a lot of ways of thinking about algorithms and furthermore a lot of the advice you see about algorithms may not be awful like
00:07:25
it's possible that in general you can experience algorithms in a pretty sane way you can be taught algorithms in the same way you can think about them the same way that's actually i don't think all that
00:07:37
unusual so if i was to put a pin you know if i was trying to point a finger and say this is the place that i think that we're going wrong algorithms and like the actual specific
00:07:49
idea of specifically how some piece of a program is going to work algorithmically it just doesn't seem like what we're really talking about when we're talking about the bulk of bad code as we perceive it or bad software as we
00:08:03
perceive it it's usually not like what sorting you know algorithm did you choose usually what we're talking about is the mess of the rest of the code we are having a problem writing all the code
00:08:16
that glues these algorithms together right like when we're talking about what we're actually going to do here the problem that we actually have is not so much that like we couldn't sit down and figure out what the proper algorithm is
00:08:29
here for this the problem seems to be more that we can't figure out how to connect these things or how to manage the infrastructure into which these algorithms are placed that seems to just
00:08:41
not work right it seems to be like that is what's going off the rails and so the question is how did we get there in the old days that really couldn't be the case because there were hard constraints on what you could ship when
00:08:54
a computer only has 64k of ram in it right there's no way for that glue code to spiral out of control there's no way for the infrastructure to be all that big to begin with so there is a natural limit
00:09:08
on what could actually happen there and it seemed to be working to that effect nowadays we don't have that and it seems like we have never developed any replacement for it so the question is like
00:09:21
why and in order to understand why we haven't developed a replacement for it i'm going to have to talk a little bit about how you actually learn to make stuff like on a computer and i realize it's going to sound very
00:09:32
trite maybe to people who are listening to this who aren't programmers it won't but to people who are programmers this is gonna sound uh a little bit silly right but please think about it actually think about this
00:09:45
for a second because if you actually think about it for a second you'll realize that we all take it for granted right we all take for granted that this is going on and nobody talks about it but we kind of need to right
00:09:58
so nobody's born knowing how to program a computer right and and i know this better than anybody because i learned a program at a very early age but before i could learn to program i actually literally sat i was a little tiny child
00:10:11
i sat at a keyboard right that my parents had my dad had i would just type i would type gibberish into the computer right and if you think about it like you first learn to just input characters or
00:10:24
something into a computer and if you're young enough they're literally just garbage but soon what you're doing is your brain right is training itself up to learn that only certain combinations
00:10:37
of letters right only certain syntax will produce a result if you're using a programming language this is why we call them languages right they have grammar they have syntax all this sort of stuff right
00:10:49
and so something in your brain and we're not advanced enough technologically to know like what's actually going on exactly but something in your brain is creating a filter and a generator
00:11:03
something that's able to produce valid syntax for a particular language and also able to like you know throw out ones of those that it wouldn't want or wouldn't need or that don't get closer
00:11:16
to something right it's got a metric and so if you think about this in terms of like ai research or something like that right there's a training process you have to train up some generator to generate
00:11:29
things that are valid in the output domain and then you need some kind of filtering process that's going to take and get you closer to whatever it is that you're trying to achieve with that generative process right and so this
00:11:42
builds and builds over time when you're a programmer right it builds over time and in your head you start to learn that you can make new parts of this right like functions and things like that or get new ones from libraries and you're
00:11:55
starting to think at like a higher level so that generator is now generating things higher up and again filtering things higher up and then finally you look at experienced programmers people in printer a long time not necessarily good or bad just
00:12:07
experienced their code just be very regularized right so that filter has dialed in quite a bit right they're throwing out a lot of possible options that would be legal
00:12:20
in the language they're programming at and only selecting from a very very narrow set so that generator filter process is producing highly regularized very predictable things at that point
00:12:33
which we don't know what that means right and we can't understand it at a deep under like you know uh physiological level but what we do know is it means a huge possibility space has been carved off
00:12:47
of that system we all know that when we first learned to type in babel like you know just the literal syntax of the language anything was possible right you just type anything in that was legal
00:12:59
in the language and you could type it in right and over time you lose the ability to type certain things in and it's not like you couldn't force yourself to it's just you don't right
00:13:12
so you've tuned the generator and the filter in your brain to just do a certain narrow subset of things and what we think when we think of experienced programmer is that that was good that was a good process now they're
00:13:25
producing like good code or something right i know it sounded silly hopefully though when we get to the end there you're not too disagreeing with me about the fact that something like this must be going on in our brains
00:13:38
so our brains have learned this filter process this thing that's going on and we all have a slightly different one right but anyone who's been programming for any appreciation of time has formed this somehow
00:13:51
now i like to think of this as a metaphor uh in my brain i always kind of think of it this way because i don't really know how to think about it and the way i think about it is exploration right i started out in my co-bases in some
00:14:04
sense and i think of that generator process as sort of being like almost like a navigator right like at any point in time when i'm going to figure out like what i'm going to do in the code i'm sort of like thinking like it's like dead reckoning a little bit it's like
00:14:17
well i think the answer is probably this way i'm gonna try some things sometimes i backtrack right um and i'm i'm trying to navigate and over time i'm trying to get to a destination that i believe is somewhere but i don't know exactly where it is
00:14:29
right and maybe you've had this feeling as well like this kind of feeling like you know it's it's sort of a journey right it's not it's not like things the metaphors people normally use don't actually apply that well it's not like
00:14:40
architecture right it's not like other things where we do a lot of solving first and then just kind of put it in there uml diagram people have tried right but it doesn't seem to really go that way it feels more like a
00:14:54
journey where we're not really sure about the end result and we're trying to get there right and maybe the better programmers are kind of better at making that journey and the newer programmers who have a lot to learn that you know it's worse right but it feels that way
00:15:07
to me it feels more like that and we don't have maps right we're navigators that don't know the lay of the land so we're constantly trying to like kind of figure out as we go that's how i normally think
00:15:20
about it and i think about like you know when we're you know setting off on these things and looking for things they could be very like uncharted we could be trying to go somewhere that like no one's ever gone before or we might be just trying to do something we do know pretty well and we
00:15:33
kind of understand the route but we might do a little bit differently this time because we know how the route went last time and we think we could improve it things like that right now sometimes this works great we end up in a place that we you know it's
00:15:46
fantastic it's everything we dreamed of when we thought we were going to go there other times we just like forget it this thing ain't shipping ditch the boat take as much food as you can walk across the iceberg and let's
00:15:58
hope uh that like we encounter another human being before we all die right so you know it it it has sort of the same analogies in a way the way it ends is similar to the way uh journeys end in the real world
00:16:11
too sometimes now the path we took to get there i kind of alluded to this has implications uh we can think of that as how the development process went so you know if if this went really straight and clean um you know we were just like
00:16:25
okay that was great that was easy right if it was sort of like really messy and kind of all the way around like you know sort of uh really circuitous or we had to backtrack a ton of times you know maybe that was a
00:16:36
rougher development process okay the place we end up is kind of how i think of like what we've achieved right it's like the quality like like i did this journey i ended up somewhere and you know when i
00:16:50
get there i know you know this is kind of why it's a navigational process with software it's like i don't necessarily know exactly what the thing will be at the end sometimes i don't even really know at all what the thing will be at the end but i will know like when i get
00:17:03
there or when i get close enough to it right and that's why it's a very navigational process because much like a kind of function where you can only evaluate it at points and you can't predict really what it's going to be very well
00:17:15
we just kind of only know did we you know if we're setting from if we're trying to go from south america to africa right we will probably know when we hit land but before then we may not really know how it's going but we will know when we
00:17:28
get there and when we talk to the people there we'll be like is this africa and they'll be like yes right or something right so we'll kind of know when we get there but we won't necessarily know and even when we actually get there we might not know where we are exactly in that
00:17:40
area either like maybe we were aiming for uh south africa and we end up in you know up in egypt somehow or something like this right so i kind of think of it as this where we end up is sort of the quality of the result
00:17:52
so what we're sort of seeing when we talk about the bad code situation right is in these processes i feel like we're just getting horribly lost like we're just kind of not only are we just like
00:18:04
kind of aimlessly creating these huge routes through things that are very wasteful and take way too much time and all these other sorts of things but also when we end up somewhere it doesn't really seem to be very good like it seems like we're kind of nowhere near
00:18:17
where we wanted to be right and it feels this way sometimes too this is another reason i like this analogy someone's in the middle of a development process or even at the end you're just like oh man we totally lost our way like like we can't even really see how we
00:18:29
would get there and furthermore another reason that i like this analogy is because it feels this way in the moment too sometimes sometimes you're like i just don't know what we would do to get past this like very it's like
00:18:43
it's very like intangible in that way you can't quite put your finger on why the code isn't coming out or what you should do you're doing things that you thought right should get you further and they're
00:18:55
not or they're just knocking you back or it just doesn't seem coming better it's very like it feels like being lost in a lot of ways okay so in order to understand why that
00:19:08
sort of process might be going wrong i want to put the blame because i have an opinion about what is to blame for this process going wrong
00:19:20
i just want to put the blame on how we construct that navigational process that filter process in the brain of like navigating what we're going to do as we go code both institutionally and
00:19:33
individually how we do that building up that part of brains i think we're now doing a horrible job in the old days the lack of resources the 64k of the machine the fact that it
00:19:48
was a 6802 processor which could barely do anything the fact that loads from disc took you know eons meant that that development of that process in anyone's brain who could ever
00:20:00
get a program to work at all they had already gone through the process of actually being very aware of what they were doing everything they did
00:20:11
would either succeed or fail at all based on whether the software was any good right because even a slight bit of being bad meant you couldn't get the thing to work at all in such harsh
00:20:24
environments right it's sort of like if the explorers were trained in the arctic right then all of them died who who weren't really good or didn't learn really fast
00:20:36
right so how are we doing this process now well you know to a certain extent some people are still doing it individually and that tends to also be highly coincident with people who maybe
00:20:50
aren't causing quite so much of the uh the bad code explosion but you know probably everyone to a certain extent does work individually and that's just you naturally experiencing things there isn't like an external force kind of
00:21:02
pushing at you there you're just playing around and learning on your own but the vast majority of these uh the tuning that happens in those processes now doesn't come from that because again the resources are almost limitless there
00:21:16
and there isn't much of a weeding out process that can really happen it's not like on an old home computer that was really difficult to use where you would have to get good automatically because otherwise you'd never be able to do it or you just quit and go do something
00:21:29
else so a lot of times where things come from is like classes universities things like that um it might come from like code reviews or like mentors like there's a programmer who ostensibly knows something
00:21:41
and they're going to tell you that thing or tell you what to do um you know maybe your boss is really mad and you get a bad performance review or maybe he's really happy you need a good one so you're calibrating based on you know that was good that was bad i
00:21:53
don't know you're gonna go read stack overflow something like this right uh and you're gonna look at what people said in there you know what are the answers that are voted up that's kind of like learning what you know supposedly you're supposed
00:22:06
to do you go to lectures this lecture for example right you're gonna listen to someone talk and you know they maybe they change your mind or maybe just accept what they say maybe you're critical of what they say i don't know but you know you get some input that way and it affects what's going on in here
00:22:19
and again when i look at this i don't think we're doing a terrible job when it comes to like algorithms or stuff like that if someone goes online and tries to search for how to sort something
00:22:32
i don't necessarily think that they're going to find like really bad information all the time i don't think that's going to happen you're probably going to be able to find the resources you need to learn how that sort of thing works
00:22:46
so what i'm really talking about is i'm talking about that other style of code right the other the part that's not the algorithm exactly itself it's everything else it's all of the
00:22:57
infrastructure it's all that other stuff that isn't really studied in the same kind of way right we don't have order notation for it or anything like that and pervasively like all throughout
00:23:11
everywhere in the industry what you will see is things that are sort of vague statements about the quality of that code like it's clean right we're gonna we're
00:23:24
really washing the code like it's very clean code if you do these things the code will be clean right this sort of thing and what we see is people are taught things that are ostensibly going to make their
00:23:37
code clean now they're never really taught what clean code is because nobody has a definition for clean code what they have is a series of things
00:23:50
you're supposed to do in order to make the code clean right like in other words we don't have a thing that's like a program you run that says yes clean code no not
00:24:02
right what we have is things you're supposed to do and then the code is clean that's all we know so you see acronyms like solid this is taught a lot right
00:24:16
and if you look at the things on there none of them have any real world definition they're not things that happen inside a computer they're things that happen entirely in
00:24:29
your head they are things that affect what code you think you are allowed to write that filter is being trained to use these metrics
00:24:41
which are largely fictional they're imaginary metrics we came up with they don't correspond to a hard measurable fact of a cpu right so we made them up
00:24:53
you're being trained not to write code that would violate these or to write code that would like evince these right now lest you think i'm joking when i say that this is something that people are
00:25:06
taught to do because some people are like what are you talking about no one teaches that well literally when i went to go grab the screenshot for stack overflow when i was like uh gonna put a slide for that well this was their blog right
00:25:18
so literally the day i happen to grab the screenshot their blog is telling people to do this on stack overflow the place where people go to get programming answers right so
00:25:32
what these things all have in common because solid's not the only one there's plenty of other things like this where we teach clean code or try to convince people to write clean code
00:25:44
what they all share is one very important very bad characteristic and that is they do not attempt to measure anything there is no measurement of anything
00:25:58
that we would actually care about it's simply implied that things we actually care about would happen if you follow these things right
00:26:12
if you take your code and you make sure that it obeys the list off substitution principle for all like classes that could be substituted or something nobody has any argument anywhere that
00:26:24
i've ever seen that suggests that that actually improves some real world metric that we've measured the assumption is that if you do that your development
00:26:37
process will take less time or be smoother or have less bugs or something the code will be cleaner it's just an abstract statement that if you do these things the code
00:26:48
will be cleaner and somehow that will affect something you can actually measure but we're never going to say what that something actually is or try to quantify it now i mean seriously look at these things
00:27:01
right is any of those teaching somebody to actually think about a real effect no they're teaching people something they're supposed to do which is taking that filter and
00:27:14
modifying it but it's not actually giving it any actual guidance about like a metric or something they're trying to accomplish it's just wrote
00:27:24
now to me that's just like a ritual right if you're literally just saying like you do these sets of things and the code is clean it's very much like oh you know like like we're gonna bless the food
00:27:38
before we eat it right and these might make you feel better and you may want to do them but at the end of the day they are not directly tethered to
00:27:51
anything we actually care about rituals may have served a purpose once or they may never have served a purpose and when we do them today what we're largely doing is just doing them because
00:28:03
someone told us to do them they claimed that by doing them we would get some outcome but we're never really told how those rituals were supposed to really accomplish that we're just supposed to assume that they do
00:28:17
now this is troublesome because computers are actual things the model in your mind of what i'm targeting when i'm trying to make my code and i'm trying to do that filter that process the generator filter
00:28:30
process in my brain if what i'm targeting is solid i'm by definition not targeting the actual computer right the thing that i'm supposed to be
00:28:43
worrying about which is a computer that runs this code is nowhere to be found in that acronym right it's not there anywhere furthermore i'm not measuring my development time solid nowhere in it
00:28:57
says hey by the way actually these are all just supposed to save development time so if you end up seeing that you're not saving development time stop doing it right nobody says that right
00:29:11
so i don't want to give you a new acronym because i don't think it's very useful but to underscore the difference between that acronym and what i would have expected to see the trite acronym be
00:29:25
i would expect it to be something like this i even arranged it in a way you can say warmed just like solid and what this is is just say look if we're gonna teach something that goes up in the filter
00:29:37
what it should be is the actual things that programmers need to care about and then if something like solid was actually a good idea you would be able to evaluate that very
00:29:50
effectively by caring about things we actually do and to me those things are writing the code agreeing on code if we have to have more than one person
00:30:02
reading code because not only did we not write all the code usually but even if we did we might forget what we wrote so we have to be able to read it we're still to modify the code the code has to execute on hardware and then we have to be able to debug it
00:30:14
right now if you look at these things maybe you would say argue is better because like coders don't agree on stuff they argue about stuff right but either way whichever one you want to think of it
00:30:27
it's still the same acronym so you know i made sure that would work now each of these things is a cost right that's what i'm talking about each of those things is a cost execution is a cost of the actual
00:30:40
computation it's the most important cost the e right how much does it cost to execute this thing on the end user's computer they're the people who are ostensibly paying us and we are wasting their time if that cost is very high
00:30:53
because we've shipped them something lousy right the rest of the cost or development time right and those affect the customer because if we never get the code done or if it takes us too long to fix problems
00:31:05
in the code or if it takes us too long to add features that affects the customer too so all of those things are costs that we ostensibly care about and while i would say maybe execution should be prioritized they're all important right you can't just focus on one of the
00:31:17
exclusion of the others so what you're trying to do is figure out a way to minimize all those costs and you kind of want to minimize as many of them as you can with maybe different weights on them depending on what you care about most but that's what you're doing
00:31:31
so again pretty simple right i've never seen anything like this you don't go to conferences and have people say like look this is what we should be caring about let's try to evaluate things on these
00:31:43
any you know people maybe throw up their hands and say well you can't possibly measure these things yes you can i mean it's very easy to measure how many github back and forths people have
00:31:55
before they actually fix an issue it's easy to measure how many meetings you're having it's easy to measure how long it took you to write this piece of code right we are an industry that does an infinite amount of a b testing on our
00:32:08
users and yet somehow we don't seem to think it's very important to actually do like a b testing with any kind of metrics on any of the stuff we claim we're supposed to be doing right so let's try to bring it back to
00:32:24
bad code where does it come from well i tried to give you the analogy programmers are explorers they're starting from somewhere and they have a vague destination in mind that they've been told to get to or
00:32:37
that they picked and they have to get there but they don't have any real knowledge of where it is well in this analogy what we've done with all the stuff i just said is effectively instead of giving this
00:32:49
something like a compass we just give them tools that don't make any sense we're even like a hammer and a tape measure or something like that right and we're like here you go set off on this journey here's a hammer
00:33:01
now the worst part about it is it's not even as bad as giving someone a hammer because the real world person would know that the hammer was useless to throw it away we've told them that this hammer is critical for navigation so they're like trying to like hold it up to the
00:33:14
sun or something and figure out like which directs they're going they have no idea that we've given them tools that are not even relevant to the problem that they're solving they're not actually tools that measure anything
00:33:25
they're just arbitrary we just gave them to them and and said here you go right similarly we spent all our time talking about a map that doesn't exist we're talking about things like liskoff
00:33:37
substitution principle as if that has something to do with programming now it has something to do with certain ideas in certain languages that someone hypothetically thought might be important
00:33:48
but it's entirely fictional it's like middle earth right your lord of the rings might be a great story but if you actually need to get from south uh south america to africa it's not gonna help you to be thinking
00:34:01
about like where mortar is on a map right you have a mental model that's been tuned for things that have nothing to do with the actual stuff you're trying to solve so we shouldn't be surprised when like
00:34:14
new programmers come up and they just do ridiculous stuff and these things will not control because they had no metrics they had nothing to tether them back to what they were actually trying to
00:34:26
accomplish we basically made their entire filter process be about things that are different from the actual things we want to achieve what else would we expect right
00:34:39
so i think in modern day when you've gone up through that system and you didn't have the luxury or the hardship depending how you want to look at it of having to do programming in a
00:34:51
constrained environment you end up thinking that things are completely insurmountable you're like you're like i don't know how we would ever do this program any differently than what we're doing right it's got to be a
00:35:04
million lines of code and super slow and buggy and well like like this is just how it's done you can't even envision what the other thing is because you haven't ever been given the tools to get there right and furthermore you're going to do you're
00:35:18
going to have been taught a lot that code reuse is good well the problem is the code that you're going to be reusing right i mean that's like in the narrative the analogy of navigation that's like base
00:35:29
camp right it's like starting out at a camp that someone else made well the problem is they were lost too they had no idea where they are so you're typically taking a library made by somebody who didn't really know what
00:35:42
they were doing and that's your new starting point right so people who failed to get to a destination that we wanted to go to are now also the jumping off point and this gets worse than libraries whole
00:35:55
languages whole platform ecosystems are this way so we're literally starting our navigators off already lost in the wilderness with no
00:36:06
chance of ever getting to the to the actual place making it way harder than it would have been if we just started back in port originally right but they don't know that because we've never been measuring any of this
00:36:19
so can this be fixed i mean sure i think it could obviously be fixed because we have examples in the past of programmers being trained up not to do these things right and so i think the first thing we need
00:36:31
to do is like start talking about the real world whenever we're talking about something conferences programming language constructs all these things
00:36:42
we should be talking about how it actually affects the results what construct a real argument for how a number goes down in the cost category right
00:36:56
we should be giving people tools like the one i suggested that actually measure something we care about not something we just assume that we care about because
00:37:09
that will lock it in right all of these things are very much like the sort of navigation base camp analogy any time we start someone off from a place that we haven't verified is actually really good
00:37:22
we create a huge problem for all the things they will do in the future right and when i talk about things like that what i'm saying is don't just say stuff
00:37:36
right don't just talk about this is clean code actually measure have something we can measure this produced less lines of code for the
00:37:47
same equivalent execution right not it's less lines of code because if it's less lines of code but it runs worse that didn't help anybody this is less lines of code it's easier for people to read why not because we talked
00:38:02
about it and decided it was easier to read but because we actually checked when a new person comes to the company they are now able to read the code faster it used to take a day for them to like read this
00:38:15
part and come up to speed on it now it takes two hours right we can measure this stuff it's real world stuff right and of course start actually putting measuring the
00:38:28
performance of things people actually knowing what the performance of something should be that should have been fundamental the whole time right the acronym solid should never be allowed to exist
00:38:40
if it doesn't have like p solid like performance right like there should have been something about how do any of these things that you're doing affect the actual run time of the program
00:38:54
so again this is just my take on it a lot of these things are very difficult to prove or disprove because we don't have formalisms for them the way we do for
00:39:06
things like algorithms one of the reasons algorithms are probably better in terms of how far they've developed is because we can test them more concretely we have a language to talk about them
00:39:17
but i don't fundamentally think these problems of the code that's not the algorithm are as impenetrable as we're making them out to be we just need to actually focus on
00:39:31
something we can point to something we can measure why does tensorflow take four hours to build or whatever it takes nowadays why
00:39:43
that should not be happening it does not do anything that complicated right so how did we get there we can measure that we know what's going on and we know the kinds of things the
00:39:57
kinds of filter processes that we've been putting in people's heads result in code bases like that we need to start like actually nailing those down and saying no
00:40:08
don't teach people to do these things anymore they're producing obviously bad results that we can measure because it takes for our hearts to build right we can tell
00:40:22
so hopefully that gives a little bit of perspective on how i think about where bad code comes from i wish i had an answer that was more magical
00:40:33
but at the end of the day i really think that bad code just comes from that one simple failure and that is we have stopped measuring and talking about
00:40:45
what we actually want and we are almost exclusively talking about or measuring things that are largely fictional they don't directly connect back
00:40:57
and once you make that jump the next generation never knows about the earlier part right they only see solid they don't know that there's all these other things they
00:41:09
should actually have been thinking about and solid was just someone's random idea about maybe some good rules of thumb but you'd never teach that as your first thing right you'd always teach the
00:41:23
evaluation of real metrics first that was the end of the lecture i hope you enjoyed it uh like i said please check out our kickstarter links in the description below we'd love to send you a graphic novel or two if you get a
00:41:35
chance we only have a few days left because this is the end of our whole promotional thing and the kickstarter wraps up in like five days i think from when this video will be posted so please check it out if you get a chance there will be one more video it's the q a for
00:41:48
this so after the lecture i took questions uh from the actual employees of the company uh to whom i was presenting so i didn't want to put them into the actual video so what it will
00:42:02
actually be is like i will summarize the question like on a card and then i'll answer it so you can see my actual answers but without the actual people who asked the questions but there were some good questions so i wanted to provide those as well so i'll be back
00:42:13
here uh for part two tomorrow until then have fun programming everyone and i'll see you on the internet
End of transcript