[00:00:19] We're very pragmatic in that sense. I get it, I found this thing on Stack Overflow, I vaguely understand kind of what it's doing, I tweaked it a little bit. It's kinda like what I like to refer to this as House of Cards design. Where you kind of put some stuff together, and you're not really sure exactly why it's work but you keep tweaking at it until it works, and then you're like my God, it works.
[00:00:39] I'm not really sure why, and you put a code comment there that says nobody touch this, and then you hold your breath and slowly back away, hoping that it doesn't fall right? As long as it's in the code base long enough that I'm not gonna get blamed for it we're good, right?
[00:00:52] That is a very ultra pragmatic of thinking about things. My boss just expects me to ship the code so, it doesn't matter if I know what it's doing as long as it seems to work. [COUGH] This is also happy path driven development. Whenever we think optimistically that all that matters is that the code works now.
[00:01:11] And if the code does work now, but I don't understand it, it doesn't really matter at the end of the day, because I went home, I collected my paycheck, and some code shipped to production. That's happy path driven development, because if it works, of course it's great. But how many of you have ever had a piece of code break before, anybody?
[00:01:31] Can we all agree that we're in a big family of friends? We all are pretty good, and I'm probably better at you at breaking code, at writing broken code. I've got a lot more experience than some of you at writing broken code. So, why is it that we focus so myopically on the happy path and don't think about what's gonna happen when I have to revisit this code because it's broken?
[00:01:53] What is the scenario by which I'm gonna get to come back and revisit this code? Romantically we think to ourselves I'm gonna get to come back and revisit this code next sprint because I filed myself a ticket that says come back and fix my technical debt, do it right.
[00:02:05] And I even put a code comment there that says, to do, fix this. But in reality, most of us never go back and see that line of code, until there's a huge fire in production. Something is melting down. The performance is terrible. There's a feature that nobody thought of when they put a real dataset in front of it.
[00:02:23] And your bosses hair is on fire. And now you don't know what to do, but you are in the worst possible circumstances to figure it out, because you don't have the time and the luxury to plan it out. [COUGH] You simply have to do more of the same.
[00:02:37] Just keep throwing cards at the house of cards until it stands. And that, my friends is how code grows into that legacy of frustration that we have. And you might have noticed something that I have noticed for a long time. Because I've been around so long I've seen this cycle repeat now four or five times.
[00:02:59] You might have noticed that about every three or four years and sometimes even faster than that, somebody comes along and reinvents an entire new framework, an entire new architecture, a whole new set of jargon to describe how we oughta build and architect our front end applications. And people flock in droves to this new thing.
[00:03:17] And it's not even fully clear exactly at that moment why that new thing is so much better. But you know why I think people flock in droves so quickly whenever somebody invents something? Somebody in this room or online is probably inventing the next big framework. There's just, the odds are somebody's working on that right now.
[00:03:35] But why is it that we flock in droves to that? Well part of the reason is that we just get so frustrated, by going back and having to fix the code and work on the code, and struggle with it. And tell me if you've ever had this conversation before, cuz I certainly have and I've certainly have it many times.
[00:03:50] At some point you are frustrated, you are working on, you are trying to fix a bug, or add a feature. And you have this conversation with a co-worker or boss and you say, you know what, it would just be faster if I rewrote it, right? That's the mindset here.
[00:04:05] Because we struggle so much to read and understand the existing code and fix the existing code, because we have taken to an extreme, the concept of agile development is a good strong positive. And I am not talking negatively about agile. But we did with that exactly what we developers, the sin that we all do with everything, which is we took it to its logical extreme and said, every single statement needs to be Agile.
[00:04:31] Who cares whether it makes any sense? Who cares whether I know what it does? I'll have time to fix that later. At a macro level, Agile is a great pattern, but at micro level of the code that we write, it's a terrible idea to approach it that way.
[00:04:47] Researchers have studied the process of software development, and they've studied, what do we spend our time on? And I found this fascinating, reading this white paper. They found that more than 70% of the time that we spend on a day-to-day basis, in the process of developing software, more than 70% of that time we spend, reading existing code.
[00:05:13] Think about your typical eight hour day. Researchers say up to 70% of that eight hour day is spent, just reading the code that you wrote yesterday that you don't understand. Anybody ever had that before, you wrote some code and then the next day, the next week, or the next month?
[00:05:29] It's been said that code that you wrote six months ago might have been written by someone else entirely. For me, that horizon is about two weeks. If it's gone about two weeks and I haven't seen a piece of code, there's no hope. I wrote code yesterday on the plane ride here, that today I don't understand.
[00:05:48] I'm good at that, okay? We write code to ship. And that's a good thing, we all need to ship cuz we all need to make a paycheck. But if we don't balance that with I should understand this code because, guess what, I'm probably gonna have to read this a few more times.
[00:06:07] Or a few hundred more times, or a few thousand more times. Maybe if we spent a little bit more effort understanding what we were doing from the get-go, there would be less of this desire to churn and completely rewrite. Maybe every line of code could be slightly more durable.
[00:06:24] If it was written in such a way that the person who wrote it understood what they were doing, why and how it did what it was doing, and here's the really important part. Cuz this is where it goes from a science to an art. They communicated that well.
[00:06:38] They communicated their thought process well. You've heard me say probably many occasions in the past kinda a broken record on this. I believe this so deeply, that it's almost a religious belief for me, that code is about communication. Did you know that code is not first and foremost to instruct the ones and zeros to the computer?
[00:06:59] Years and years ago, decades ago when we first invented programming languages on top of the 1s and 0s we started to create a separation, a gap between the code that we write and the precise instructions that the computer runs. Even assembly language was an abstraction. There is a pretty close one-to-one correlation but not exactly.
[00:07:18] So, even at that level, we started to move and create a gap between what the computer actually does and what we expressed to the computer through our source code. And, the more that we've done that, the more languages that we've created, and we're on third slash fourth generation languages at this point, we're approaching more of the natural language kind of things.
[00:07:37] You have SQL, for example, it's been around for awhile, but SQL is kind of more, the traditional fourth generation, it's more natural language oriented. And we're moving in those directions even more, with voice oriented stuff, through Alexa and all those other things, right? So we're seeing the progress of creating abstraction in the way we instruct our computer.
[00:07:57] We're creating these barriers between what we do, what we express in our code, and what the computer runs. So at best, our code is not a precise set of instructions but rather a set of suggestions in the computer. Really it's a set of suggestions and the computer looks at it, you obsess over should I do plus plus I, or I plus plus?
[00:08:18] Because you're thinking in your mind, I saw some JS perf somewhere and it told me that plus plus I, was a couple of microseconds faster than i++, so I have some instinct in my head that I need to do that everywhere, because let's save on all these microseconds.
[00:08:45] Cuz it turns out, there's a more efficient way to do it. I am glad that the computer is better at writing efficient code than I am. Because if it were up to me, I would have failed out of this industry a long time ago. The computer is vastly better at writing more efficient code than any of us ever will be, and it's getting more so.
[00:09:05] They're catching up. They're doing things even better and more sophisticated than they ever have before. So when you obsess about I have this thing, and I'm gonna sacrifice the readability of my code because this micro performance benchmark tells me I've got to make sure that I squeeze in this micro second out of it and do this weird thing with a bitwise operation or something like that.
[00:09:26] When you obsess about that what you are really doing, is betting against the future. You are betting that your current skill level, is better than any skill level that will ever happen to the systems that run that code for the entire lifetime of that code. Now in a sense code gets rewritten all the time, so what difference does it make?
[00:09:48] But actually code lives a lot longer. It just churns and churns and churns, lives a lot longer than we might want to admit. So maybe stop betting so much against the future and maybe start saying what should I invest my time in? If it's not to precisely instruct the computer, if I should instead try to come up with a way to describe what I want to have happen.
[00:10:11] There's a term for that, it's called declarative. If you wanna describe what you want to have happen as opposed to, precisely instructing how to do it, that's called imperative. If you can be more declarative about your code, you open up more opportunities for future improvement in the performance and the optimization of that code, the system will be able to optimize it better the more declarative you are.
[00:10:33] As a matter of fact, the more imperative you are, the more you try to tinker with all those things, the harder you make that code for the engine to optimize. You actually work against your own favor when you have this myopic, well, I just gotta optimize this code.
>> Kyle Simpson: So, code is not about a precise set of instructions and code should not be about obsessing about a micro performance difference of a few microseconds here or there because guess what it's scale the engine is gonna do, it's gonna profile all your code in real time. It's not gonna pay any attention to this individual benchmark that you ran in jsproof.com it's gonna run it in the entire context and make very very different and sometimes completely counter intuitive decisions to your own.
[00:11:20] Stop betting against the future, and stop betting that you are better at what the computer is clearly better at. Your just not going to be better than the computer at those things, ever. And that's not criticism, I'm talking to myself here. We're just not built for that. You know who's not good running programs?
[00:11:36] Us, you know who is? The computer. But, does that mean the developers are eventually gonna become irrelevant? Are we being programmed out of our own jobs? Are we making AI systems, where eventually the computers will make their own code? There are some that believe that. There are some that believe that A, software developers are the new blue collar worker, we're commoditized.
[00:12:03] We're just on an assembly line. We're not creative, we're not doing something bigger than ourselves, we're just cogs in a wheel. There are some that believe that. And there are some that believe that just like that, because we have become the new blue collar worker, and we're not workers on a factory line.
[00:12:18] And that's not to say anything negative about factory workers, by the way. That's the backbone of this country so I don't mean to suggest that at all. But to suggest that software developers have become that is to suggest that software developers are also subject to automation, that our jobs will go away, is that true?
[00:12:36] I mean, we already see AI being able to do small scale things, like the Microsoft AI chat bot that was able to pull code from Stack Overflow and solve little small coding exercises or things like that. Is that true? Well, here's what I think the computer will never be better than us at, ever.
[00:12:55] And it's tough to make a statement like that where you make some prediction against the long future, but I'm saying ever. I'm drawing a line in the sand and I'm saying I think there is one thing, that the computer will never be better than us at. Communicating with other humans and communicating empathetically with other humans.
[00:13:15] That's the one thing that we will always be better at. It will never be the case where we don't need to communicate anymore, the computer just communicates for us, that's nonsense. We will always need to communicate, and we will always do that better than the system. So maybe that's were our intention should be.
[00:13:32] Understanding the tools that we use to get our job done? Yes, we have to ship code. But maybe we should focus a little bit more and understanding and communicating more clearly with our code. Of the infinite number of choices there are of programs that will produce the exact same sequence of 1s and 0s.
[00:13:50] Maybe the best code, keep using better and best. Maybe the best code, is the code that fully describes itself. That to an untrained reader who has no idea what the problem domain is, has no idea what you've tried and failed before, can read that code and on the first pass through the code fully understand, everything they need to know.
[00:14:14] I know that's idealized, right? That's not really realistic, but shouldn't that be a goal of ours? To communicate so clearly with our code, that there's no question upon reading that it's doing what it's supposed to do. Or there's no question upon reading it's glaringly obvious where the bug is.
[00:14:31] What the problem in our logic is. That's my life's quest at this point. And I use this vehicle of teaching to do that. Let me let you in on a little secret. I'm not qualified to be a teacher, I'm not. I don't have a degree in teaching. I don't know anything formal about teaching.
[00:14:47] I don't know all the terminology around teaching methods. All I'm doing is going on a journey of learning this stuff better, and I'm taking you along with me on that journey, okay? Because I wanna learn better how to communicate clearly with my code, and that starts with understanding my programming language.
[00:15:24] Is it something that you couldn't possibly ever convince your boss it's worth doing? Because your boss is only concerned with shipping the code. Could you possibly ever have a conversation with your boss that starts like, hey I need some more time to make sure I do this right?
[00:15:38] I suggest that, but you may be thinking to yourself, well, that's all well and good in your ivory tower, but where I work, we're understaffed and we're behind budget and we're behind track and we gotta ship this code. And nobody cares about any other stuff. Just like we don't care about tests, we don't care about documentation.
[00:15:55] All we care about is getting the code out the door. Couldn't possibly have this kind of conversation with my boss. And I push back on that. I say it's cuz you're having the wrong kind of conversation. When you frame this conversation as, I need to go spend some more of my time, aka I need to go waste some more of your dollars, Mr. Manager or Ms. Manager.
[00:16:15] I need to go waste some more of that time and money on stuff that you don't perceive as useful, it's because you haven't properly talked about the value proposition. Because if you think about how much managers budget for code maintenance. Remember, we said code maintenance is 70% of our time.
[00:16:34] And you think about how much of their budget. I've interviewed managers of software development teams. They budget as much as 60% of their annual budget, just to fix the crap that we mess up. The overhead of managing a code base. You're not having the right value proposition discussion with that boss.
[00:16:53] When you myopically think well all I've got to worry about is what's gonna happen right now. When you say you know what? You want me to spend one day, I could spend two days and there's a fixed cost, for that. Versus, if I spend one on that code, that code will actually cost us 10, or 15, or 20 days in the long haul.
[00:17:12] So let's start having a broader discussion about timelines beyond what's happening today. Why don't we talk about what's happening over this quarter. How much is that line of code gonna cost us over the course of this quarter? Then we start to put in perspective why investing in that line of code.
[00:17:31] And I used that word on purpose, investing in that line of code to make sure that we communicate clearly what we are doing. And by the way, there's a little nuance here. I'm sort of almost philosophically fascinated by this nuance. There's the code that we write, but there's also the code that we intentionally didn't write.
[00:17:51] Have you ever wondered why some piece of code didn't need to be there? Have you ever looked at a piece of code and said, why don't they need an if statement here, all right? Why is this working, why doesn't it need an if statement? Because my intuition is to think, it could come in null, and throw an exception.
[00:18:08] Why doesn't it need an if statement here? Or if you've ever seen an if statement that doesn't have an else clause, and ever wondered, why isn't there an else clause?
>> Kyle Simpson: I'm philosophically fascinated by the idea that programming languages don't do a very good job of describing the absence of stuff.
[00:18:29] That's one of the things that we need to get better at if we wanna communicate. The best that we can do right now is put a code comment, no else necessary because dot, dot, dot and fill in the blanks. But maybe we need to get better at designing our systems, and our languages, and our frameworks, and our patterns to communicate not only the stuff we intentionally did, but all the stuff that we don't want there.
[00:18:48] So that the future reader of that code doesn't have to wonder, why isn't that there? The future reader of that code doesn't have to wonder, why couldn't he have just done it this way? Because we can communicate clearly why that would not have worked. And why we left that part out, okay?
[00:19:02] So that's the bar that I set. No big deal, right? This is pretty easy.