The software industry spends a lot of time arguing about code quality. This is a talk about the flaws in our collective assumptions about “good code”, and how that flawed reasoning has snowballed to deleterious effect in individuals, on teams, in our community, and throughout the industry. The original, full-length abstract tells a slightly fuller story about the origins of the talk.
The video above was recorded by Confreaks when presented at RailsConf 2015 on April 23. The slides can be viewed on SpeakerDeck.
Transcript of the talk
[00:00:00] So I talked subtle. Sometimes the controller is just a controller. It's a deep dive into action pack. According to everyone who stopped me in the hallway this week, it's actually not, but it's about fancy code versus boring code. The epic battle. Here's some boring code taken from one of my gems, just randomly.
[00:00:28] It's boring. Don't read it. Let's make it fancy. So this isn't fancy. And that looks much more impressive. But, boring code is so much easier to read. And I realized when coming up with a bunch of examples like this, that would have been a really boring talk to be like, look at this obvious code, and it's better than this clever code.
[00:00:48] I refactored the abstract a bit, so I hope you don't all feel hoodwinked. But I'm going to start with a digression. I'm going to talk about slides. So my name is Justin. I do a lot of talks, and I always invest a lot of time into my slides and try to make them artful and illustrate my point well.
[00:01:03] But I'm not an artist by any stretch. I don't know, artiste? I don't know if there's an accent over that or which way it goes. But artists like to say at the end of my talk oh, I loved your slides, and then I'm overwhelmed with joy to hear this. Then they follow up and they say, You just clearly put so much time into your slides.
[00:01:21] Loudly crying face. Those are the actual alt text, by the way, of Apple's emoji. You're gonna recur through the talk. Fundamentally though, slides are about time. For anyone watching a recording of this after today, this is what a wristwatch used to look like. I used a clock there. In fact, actually Apple already ruined that joke because they've updated the emoji to match their products.
[00:01:40] Speaking of the Apple Watch if I get a package notification during this talk, I'm outta here. No offense. So I did my own horological study and I calculated that if you take all of my free time and you subtract away the time I spend doing slides, it equals zero. And so I sat down and I thought, why do I spend time on this?
[00:01:58] And it's because I want to win people over to a certain way of thinking, or I want to invoke them. Some interesting conversations on topics I think are important. And I realize if I don't spend any time, I'm not going to win many people over. But as I spend more time, I'll win more and more people over.
[00:02:10] But even then, I can understand I'm never going to win over 100 percent of people. It's just not possible. I'd die before I got to that point. But luckily because I help manage a business now, I know a lot of project management tricks, like the 80 20 rule. If you're not familiar, the 80 20 rule says, do a job until it's 80 percent done, and then quit.
[00:02:26] I figured I'd stop at around 80%, I found that's about 60 to 80 hours per slide deck, which is a huge investment of time. And so I didn't have quite that much time, or I didn't think I'd have quite that much time to prepare for this talk. So I hope you'll forgive me if my art isn't quite up to up to spec here with 18 fonts per slide.
[00:02:43] Sometimes a slide is just a slide, so we'll just have to take it as is. The reason I care about all this is I want to do a good job. I want to write good talks that, that, that mean something to people. But the thing is, I can't know if it's a good talk until I've conveyed it to see and to test whether or not, I got my points across and you agree or disagree and whether it works.
[00:03:02] It's contextual. It depends on you. And there's really no such thing as universally Good talks, but anyway, this is a talk about good code,
[00:03:15] and I'm going to talk about good code I'm going to lay it down right now First of all, this is going to be really hard to read. I'll read it for you. Good code tiny units like Hilariously tiny as in one public method like I tend to extract the private methods from complex code But for the name not for the abstraction I think units should either hold and describe a value or perform some useful behavior, but never both Those behavior units, they can contain logic, or they can depend on other units, but never both.
[00:03:41] I try to eliminate local variables to an absurd degree. I usually start with functional chains, but then my favorite refactoring tool is composition. I refactor via functional composition. I use tap and each a lot as if to screen side effects in those chains, so that I know to go back and refactor that later.
[00:03:58] I try to minimize third party dependencies and write wrappers around them. I try to pull side effects near the entry point, like Gary's imperative shell functional core. And then I also disagree with whatever my peer does every 10 minutes. And finally, I try to overwhelm people with information so that I get my way.
[00:04:15] So anyway, that's my talk. My name's Justin. I'd love if you followed me on Twitter. So that's my last name, Searles. Or if you've got any long form feedback and want to go ahold of me, hello at testdevil. com. Don't worry, I'm in on it. That's not really the end of my talk. That's just my favorite way to write code.
[00:04:31] And I'm sure that you have your favorite way to write code. And when we get together as teams, we all collectively, we normalize and we develop consensus about our collective favorite way to write code. We all have our framework's favorite way, like it's conventions that set forth how it wants us to write code.
[00:04:47] We're negotiating all these things all the time. The only one in the room who's actually consistent on this is our bosses, right? Because they know that they want it on target, on time, and on budget. Kudos to them. But when I sit in an iteration planning meeting and we talk about how we're going to approach the next feature it's often just an argument of us all getting our favorite way.
[00:05:05] Louis CK talked about this phenomena in one of his stand up routines. Most people don't give a shit what happens as long as they get to do their favorite thing. People don't even want to back off from their favorite thing. They won't even do their second favorite thing. Have you ever seen somebody they're at an intersection, and they want to make a left, but they're in the right, all the way right lane, because they messed up.
[00:05:31] So now they're, okay, here's the guy, he's in the right lane, and there's a whole lot of cars, like 6th Avenue, like a lot of cars. And he wants to make that left. So what does he do? He just does it anyway. He just goes ahead and he just Shumps his car Through everybody's life Without any Everybody's being honking and outraged And you always see the guy go I have to There's no other possible Thing I could do What else can I do?
[00:06:01] What can I do except go up one more block and then go left and take four seconds? It's not my favorite way though! It's 99 percent of my criteria!
[00:06:20] So I don't know if you've been in that planning room before, but I feel like I have, and I've been that guy. So maybe it's just the case that if we combine everybody's favorite way to write code, then maybe that's what good code is? But I suspect, intuition suggests that's not true. In fact, my thesis today is that there's no such thing.
[00:06:37] As good code. I've got some just some Inputs in my life that made me think that First of all, SnakeOil still sells out As fast as Hacker News can stock it. We're all in this clearly, like this void In our souls Chewing up new frameworks and Javascripts. Exhibit B Projects rarely succeed or fail Because of their code quality.
[00:06:59] I've been on, as a consultant, I've been on lots of projects And code quality is rarely the reason they win or fail. The industry sure doesn't seem to produce better code over time. So if it's a like evolution, if natural selection applies to software, whatever it's optimizing for is not code quality.
[00:07:17] I feel like we're just this oscillating fan going back and forth between one meme, maybe it's a capability suitability on one end to the other. If I had to define good code though, here's what I'd come up with. I'd say one, good code performs a function. And two, it communicates intent. Performing a function is really straightforward, right?
[00:07:36] We can look at it, see what it does. We can measure it and do benchmarks and optimize it. And then we can always change it. What it does today is going to be what it does tomorrow, and we can always alter it and go back if we need to. Functionality is very objective. We can evaluate that objectively, and as engineers, we're all really comfortable with that.
[00:07:52] But what about communication intent? We look at it like writing. It's like literary criticism. Our egos get all wrapped up in our favorite way to do stuff. And then it's like a crystal ball. We just have to guess, the person reading it. What are they going to be thinking? What are they going to understand?
[00:08:06] What's the, what are they going to be trying to accomplish? We won't ever really know. So communication that's totally subjectively evaluated. And that makes a lot of us as engineers really uncomfortable. So on one hand, we tend to conflate those objective and subjective goals of code, and which makes the evaluation really hard.
[00:08:22] This is where you hear people like, Code is art, right? It's just, it's impossible. So on one end of the spectrum, you have no idea how to evaluate. But otherwise, we tend to emphasize function because the measurement is easier. Burn up charts. And so on the other hand we just have the wrong idea.
[00:08:38] We only really evaluate half of what's going on. I think that this is the fundamental crux, that this is, this causes a little pit in all of our stomachs, and it has a snowball effect. First on how we practice code as individuals and it rolls down into teams and community and industry. And we're going to talk about all the side effects of that fundamental error that we make.
[00:09:00] So first of all, as individuals. I really wish that we could just have an app that could tell us whether our code was good, right? If only this existed while I wrote it for you. It's called IsMyCodeGood. com and it launches right now. It's a real thing, I really made this, I don't know why. Here's a demo of it working, up on a website, load it.
[00:09:19] You type in your GitHub username, it does some calculations, and then it gives you a report card of your code quality. And you can go back and you can type in, your boss or your friends, see if you're better than them. And so check, done. Finally we have some way to evaluate our code.
[00:09:36] Just don't do this to us. In fact, in the last 30 seconds since it launched it's front page of Hacker News, it's gone so viral that I'm ready to announce version 2's headline feature. It's 10x developer conversion. It'll tell you what ex developer you are. It's a paid upgrade because you're gonna be able to argue for such higher salaries when you say you're an 8.
[00:09:54] 6x developer. But really, there are a lot of sites like this, right? And why do those scoring and ranking and achievement sites comfort us so much? Why do they always go viral? And it's because any quantified measurement can really soothe our self doubt as developers. There's this secret fear that that I think most programmers share, and that's, what if my code sucks?
[00:10:12] I don't really know what if, it's I walk around, everyone else seems to have everything figured out, maybe they know something I don't. Maybe if I use enough big words, I'll fool them into thinking I belong here. And we all cope with this in our own way. Some of us put up big Some of us hide behind other people if you recognize this, you'll know what you do to try to compensate.
[00:10:32] But that amount of fear and insecurity and doubt, it varies from person to person. There's what we might arrive at as a healthy amount. Some people suffer a lot of anxiety about how they fit in, and some people seem to have no care in the world about what other people think of their code. And so on one hand, people might be very introspective, empathetic, persuadable, and on the other end of the spectrum, very self assured, indifferent to what other people think, and unflinching in their convictions.
[00:10:56] So how would you rate yourself on these scales? So let's start by practicing on me. So last week I came back from France, and who's ever filled out one of these forms entering the country, like a customs declaration form? I hate this form. The first time I pulled it out I was freaked out because I was convinced I was going to get arrested because I don't know what I'm doing.
[00:11:13] And every time I do I find a new ambiguous wording in this form. And one of my favorites is this one. I am, we are bringing fruits, vegetables, plants, seeds, food, or insects. And now I know what they're asking for here. The intent is that they don't want biocontaminants from farms and stuff coming into the country.
[00:11:30] But I'm a total technocrat. And I was talking about this with Aaron Patterson and Aaron really likes junk food. So I found this in France, it's like a dairy milk bar with Oreo in the middle. And I bought it for him, so that was my backpack, so I'm filling out this form, and I start by writing, no.
[00:11:47] And then I'm like no, I feel guilty, no, it's technically yes. But not really guys, it's just candy, chocolate. And I underlined the candy, and I was like, oh no, they're gonna think I crossed out food, but that's the thing that it is. Where do I rate on this spectrum? It's pretty obvious I'm a really high anxiety individual.
[00:12:02] Clearly. So if you think of those left right spectrums, when we hold people to subjective, especially flawed evaluation standards, people are really introspective. They tend to feel paralyzed into inaction by their self doubt. People on the other end of the spectrum tend to rate themselves favorably no matter what the popular way to evaluate themselves is.
[00:12:20] This is a really important point. In fact, oh, there's a passing Dunning Kruger reference. Never mind that. Another interesting aspect of that, though, is I think that the people on the left tend to be more effective communicators, because they can empathize with the listener. Whereas on the other side of the spectrum, people tend to be clearer communicators, which means that they're effective communicators, but only to like minded people who are already like them.
[00:12:43] So it starts off with us evaluating code poorly, like the cycle of the industry. And then I find that conscientious coders, they tend to doubt themselves, right? Because of the self doubt. Which allows those more callous and indifferent coders to outperform everybody else around them because they don't have the same inhibitions.
[00:13:01] So then eventually, conscientious coders, they feel marginalized and they quit and they wash out. Which just results in us reinforcing, we evaluate code even more poorly. So if we start with these people in the room, eventually those more feely, touchy people will leave. And what are we left with?
[00:13:16] Guess which group does better at whiteboard interviews? Who are you writing code? Nope, not me. I would still fail all of your whiteboard interviews because I'm so nervous all the time. So if you groaned when you realized that this was a soft talk, this talk's for you! You're who I'm talking to. This talk was rated F for feels by whoever writes talks.
[00:13:44] So don't worry, we're in this together.
[00:13:49] So it's all about good code. A lot of good code talks about, we're like, what's the right way to do this? We're like, write code the right way. And obviously, if you consider that communication aspect, we can only really know that communication is ever correct in a given set of contexts. One of my favorites because Kent Beck is here, is XP's concept of system metaphors.
[00:14:07] This is a tool where if you have a really complicated business domain, you can simplify it by being like this is actually like a boat. And all of our variables are used in a nautical theme or something. As an analogy for something that's very abstract, it's a useful tool. But sometimes it can go awry because it can it requires that we understand the metaphor.
[00:14:25] One time, one of our testable agents Kevin Barabaugh, was on a project And he came to a codebase where everything was based on mystery men. And he talks to the team and they all were very productive in this codebase, but he had no idea what was going on, so they hand him a VHS tape of this movie that's really bad and that we've all forgotten about.
[00:14:42] And the entire codebase was based on memes and references to this movie. Yeah. They were really productive and that's great, but there was like, they were getting paid to write code that literally had a pop culture expiry date on it. And that's a huge business risk that they didn't see coming. Not to mention, who are they pushing away?
[00:15:00] Who don't like mystery men? Maybe people not like them. So know your audience. It's important that you use metaphors and you consider the correctness of your code. Understand that it is a crystal ball, but if your team is on board, then that's great. But if you're writing for the public, you have to consider what What are you saying by the metaphors that we use in our code and how we communicate in and about our code?
[00:15:19] Separately even just believing that there is a right way to solve any given problem in code can really cause problems. I feel like being a Rails developer is a little bit like playing Mad Libs. So as a programmer, I want to convert to PDF and then send it via fax using Rails so that I can remain employed.
[00:15:36] And the first step to anything like this in Rails, plugging things together, is best PDF gem Rails. And the second step is best fax gem Rails. And God forbid if it's no results found, because we're so used to like, knowing the right way that we have, looking over our shoulder like, what if I just missed it and I do this the wrong way?
[00:15:54] It can cause a lot of stress. So when I talk to my Rubyist friends, a lot of them will often say like, Why would anyone prefer writing JavaScript? It's so gross, it's such a nasty language, and the tooling is terrible, and they're right! Here's why. Because if I ask in JavaScript what's the right way to build a snowman?
[00:16:09] Somebody's gonna say, does your code work? Because if so, then that's the right way.
[00:16:13] Wild West can be really liberating. I'm serious. If you suffer from anxiety, being in an ecosystem where there's not a right way to do things is really cool. Really liberating. Like David Cross writing a pizza in outer space liberating. Yeah. Aaron had this quote that I really liked.
[00:16:26] It's fun to complain about bad code, but I have to remember that perfect is the enemy of shipped. So sometimes just getting stuff out there means that we have to overcome that inhibition. Yeah, let's talk how that, that error goes from being just about individuals to being about our teams and how that snowballs a little bit.
[00:16:42] So as teams, if you've been on a team, have you ever tried out some new approach to your code that you were really excited about but your team member shot you down? Or on a team, have you ever had another team member like shoehorn some weird code thing that he learned on a screencast or whatever into your project?
[00:16:57] Yeah, it sucks. Crystal is two sides of the exact same coin. It's the exact same situation, all that changes is our perspective. The difference is fundamental attribution error. Which is just a fancy way to say, we tend to be more than willing to justify our own actions as good, but we tend not to give other people the same amount of slack.
[00:17:16] The way we overcome that typically is empathy. If I can empathize with the other person on my team and why they might be doing things the way that they're doing, then I'll probably be able to get along and justify instead of assuming that it's bad. But the problem is that if we're all expending a lot of emotional energy to mask over our personal insecurity about whether our code's good or not, then we don't have nearly as much willpower remaining to be empathetic to our teammates.
[00:17:40] One of the core tensions on Teams that I think is a really interesting one to discuss is people who are, like, more comfortable with familiar approaches to solving problems versus people who seek out more novel approaches to solving each problem. Now if you're on the familiar end of the spectrum you might see your end of the spectrum as being the proven approach and the other side as being, like, hacker news driven development.
[00:17:59] But if you're on the other side of the spectrum, you don't see things that way. What is, you're, like, practicing modern development and all those Java architects are stubborn and outmoded, right? And we can bridge these divides, but that having personal insecurity and being unwilling to speak up and make ourselves a little bit vulnerable means that we typically don't bridge those divides.
[00:18:18] Speaking about bridging divides, I want to talk about culture fit, but because I know how, you need to ask me scare quotes to culture fit. If you go on Twitter, there's a lot of good criticism about what has been called culture fit. I love this tweet from Marco most dev interviews are like a long ass secret handshake to make sure you belong in the club.
[00:18:37] It's ritual as much as it is evaluation. So that's really we're talking about monoculture fit. I think they are separate things, and so let's talk a little bit about monocultures. First of all, about team's dirty secret number one is that monocultures actually work faster. You might not want to admit it, but it's totally true that if you stack the deck with developers who all agree about the right way to do everything, they don't have to waste any time deliberating or finding consensus.
[00:19:03] They're just going to crank out a bunch of code. But a truth bomb here is that a lot of people who call themselves meritocracies are incidentally reinforcing monocultures. They because there's no universally rigorous way to evaluate our code, what it really means Is that they can really just say this person does our favorite way of doing code really well, and it reinforces for finding people who are just like you.
[00:19:25] That's one reason why I think meritocracies have gotten a bad name in the last few years. And of course, the problem with meritocracies is if you have everyone over in this one side. Any environmental thing changes about the market that they're in, or the users that are using their system they've got these tremendously huge blind spots.
[00:19:40] So if there's a fire over here, it could burn down everything, and then they're all shocked, and it all goes to hell immediately. So dirty secret number two, is that faster, the fact that monocultures go faster in this instance, Doesn't necessarily mean better. The world teaches us that slow equals stupid.
[00:19:58] In fact, in English language, calling someone slow is a tantamount to calling them stupid. But in general, teams that, that have to overcome different perspectives and deliberate and argue yeah, sure, they're slower, but really they build more robust systems because they cover those blind spots.
[00:20:12] So if you had a few people from each side of this spectrum, they'd probably have to get in a lot of arguments to arrive at a solution, but you can see much fewer blind spots. Tangent please everyone stop claiming this. Trust us, some practice, like TDD, or Agile, or Turbolinks, it's gonna make us faster in the long run.
[00:20:32] That's, that subsumes this whole bias, right? When we say eventually this is gonna be faster. It's no, it might just be better. Might not be faster. Dirty secret number three, of course, is that most dichotomies are false. So what I just showed you here is two ends of a spectrum, but there's a whole concofny of like people along in the middle that are also really valuable.
[00:20:51] It's not just about the extremes. So when I think about culture fit, what I think about is these are the pieces of the puzzle that we have connected so far. What are we missing? We don't need the identical piece again, but like, where are we now and what do we need next? And, is this person a good fit for augmenting and expanding what we, covering one of our blind spots?
[00:21:08] A little digression about code. What's to say about code? Functionality, on one end, communication on the other side I'm making up this false dichotomy, right? Wrong. Because fundamentally if all dichotomies are false, then we have to emphasize everything as a spectrum.
[00:21:21] So on one end, I want to talk about communication, as communication to humans, and the functionality side is really communication to computers. If you've ever seen a highly optimized function, like what might be very dense, it might have a lot of compiler or interpreter awareness in there, it's probably very good at communicating to the computer, but very bad at communicating to other humans, and needs a lot of documentation to understand it.
[00:21:41] On the other end of the spectrum, part of the reason Ruby got popular was it's very good at communicating to humans, because the code is very readable and easy to use. But the problem is that all those DSLs that we invented turn out, they're really slow. And all that metaprogramming makes it very difficult for the computer to understand how to make it go fast and how to introspect it.
[00:21:58] Clearly, this is just yet another spectrum. And there's something in the middle that's probably on the mark as a healthy balance between those two extremes. So if we talk about this as one blended topic, and about not just communication to humans, but also communication to computers, it's worth asking, how is our code communicating?
[00:22:13] So I feel like we don't have a good vocabulary for this yet. I've tried a bunch of different ideas, and this is the one I'm going to share with you today, but this is rife with opportunity for coming up with your own. I'm going to call it Indirection Analysis. So in your system, every library or file or method or name represents a kind of an indirection.
[00:22:30] You, a new thing to open or look at or understand. And every macro or reflection or metaprogram is like a super indirection, because it can affect everything that came before it. And I've been curious to see somebody invest the time to find a way to automatically score indirection in your system.
[00:22:46] So for a given code path, how many names, i. e. concepts, are encountered? How many source files contribute code? How many tests redundantly cover that code? What percentage of the code is handled by third party dependencies? All this stuff is useful to both humans and to computers to understand how our code is communicating.
[00:23:03] And this spectrum is really could be conveyed in terms of dry, right? Dry is don't repeat yourself, and the opposite of course is wet for some reason. I don't think it stands for anything. But on the one end of the spectrum, dry is really saying duplicate nothing. And wet isn't saying duplicate everything, it's saying couple nothing.
[00:23:18] So we take those as a spectrum, and we look at both the extremes, both of them are really costly. On the one hand, if you couple nothing, then it's really cheap to change one thing, because you know that it's only referenced in that one place. But changing many things mean you have to change it in all these different places, and that's why dry got popular.
[00:23:36] So if you duplicate nothing, then changing many things all at once, because it's all in one place, is really easy. But if only one of those usages diverges from the rest of the pack, then that's when we get into the dreaded bad abstraction, because then you have to have an if else branch in your code.
[00:23:51] Similarly, it's really easy to learn one piece if you don't couple anything, but learning an entire system is really hard. But if you duplicate nothing, learning one piece means you have to basically learn the entire system. But then once you do, you're just flying because you know how everything in the program works.
[00:24:05] So yay, Nuance! Drives not good and drives not bad, it's just yet another spectrum. Another aspect of indirection that I think is interesting in this regard is explicit versus implicit indirection. So explicit indirection I like to think of like in test driven development, domain driven design, where in your system you have a lot of custom domain objects.
[00:24:21] So your system is a special snowflake, and everyone who has to come to it has to go and understand everything in the system. Whereas with implicit indirection, maybe something like Rails or Ember, you have to study up on what the community does, what the framework does so that you can just have all of this sort of magical negative space in your systems that, that does stuff for free.
[00:24:39] They're both indirection, and they're both wildly different, and we talk about one versus the other a lot. But we don't really understand that the net effect of both is lots and lots of indirection in the systems that we build. I would just like us all to get in the habit of practicing how we communicate about our code's communication.
[00:24:53] Having more of these meta discussions. So yes, this is a great opportunity if you want to be the next thought leader. Think on this. I'd like to see more people discussing this kind of stuff, because I think it's really interesting. Speaking of thought leaders, let's roll down to our community.
[00:25:06] So as a community we have this fantastic group of people who are prolific. They speak at conferences and they publish and they're really like our team's sixth man or woman. Like people like Gary or Sandy or Aaron who contribute to us as thought leaders new ideas that shake up how we do things.
[00:25:25] They give us opinions on this is a good approach, this is a bad approach, this is a short circuit and help us navigate the gigantic waters of what's going on. And then they can also provide us a little bit of CYA. Somebody pokes at my code and says, Oh, I don't like that. I can at least be like that's how Gary does it.
[00:25:38] And now it's totally cool. But when we're writing code for our jobs, who is our code really talking to? Who's gonna read that? So if I'm here programming one day, and I'm thinking about that question the honest answer is I'm usually coding as if Gary's watching. Which means I'm writing all this highfalutin stuff, and I'm really sweating the details and it's really stressful and not just for me, but for the person reading it.
[00:25:59] But in reality, when I'm programming, it's probably just that somebody who's more like me than different from me is going to be the one reading it. If anything, they're going to be a little bit more novice. And I'm disappointed that a famous person's not reading my code, but at least I'm relieved that he I don't have, I'm not on stage.
[00:26:14] Except right now, we're not on stage. So really, if we write code to other people who are just like us, We're going to favor more obvious and clear solutions, which makes me happier, and it certainly makes them happier that they don't have to read all this fancy, clever gobbledygook. Another aspect, and part of the reason for this, is I think that we all suffer from a little bit of hero worship in this the times that we live in.
[00:26:34] Gary actually tweeted this, and I really liked it. He said speakers were so mysterious, but now he's ga he gave his first keynote last year, and now that I know that we're mostly just regular ding dongs. And I gave my first keynote last year too, so I was able to check in, total ding dong, and Aaron confirmed, he's also a ding dong.
[00:26:50] So really, there's nothing fancy, there's no, we're just like, we just got lucky, and here we are, hi. So now that I'm a certified keynote speaker, I'm gonna turn in my speaker card, even though this makes me really uncomfortable. Just to make this one claim, which is that your clever code does not impress me.
[00:27:06] Your clever code makes me feel stupid. It really does. In fact, the more I think about this, I realize that clever code is simply a symptom of poor understanding. I'd be much more impressed if everyone went to the subreddit and explained like I'm 5 and tried to like practicing all the business domain stuff that they're doing there.
[00:27:24] Because that's fundamentally that's a lot harder to do. In fact, obvious is much more impressive than clever. I'd love to read more obvious code in my life. Speaking of the way that thought leaders share stuff they, we have all these design approaches and they're really memes. MVC, DVD, DSLs, view presenters.
[00:27:40] We had a whole bunch in our society, right? Fastfacts, hexagonal rails, DCI, fat models, skin controllers. These are just memes. And by this definition of meme, like the formal one, Memes are ideas that compete for our attention. They feed off our attention and they reproduce via transmission, via our communication, as if by natural selection.
[00:27:57] What's like a meme's life cycle look like in our community? First it starts when somebody has an idea, and then they experiment with that idea. Eventually they start sharing it with early adopters of that idea, and it spreads, it becomes popular. Eventually, like if they're successful, they become ubiquitous.
[00:28:10] And then, finally, that idea is finally worth using. With what? Like, how does it get from the beginning to the end? The reason the endgame is what it is because memes are most valuable once our audience knows them. And if they don't know them, it might cost more for us to use that particular design approach than to have just done things the obvious way.
[00:28:29] So why is it that design memes ever become ubiquitous? And I think that the reason is that there's a symbi symbiotic relationship. Between those early adopters, who tend to oversell the intrinsic benefits. Because we're all looking for a panacea. We're all looking for a magical thing that's gonna fix all those fundamental problems in our code.
[00:28:45] And so we're eager to pull in new ideas. So if you look at this chart the people who share the idea initially with others as early adopters, they, you might call them evangelists or mean salespeople. They will try to convince others that like, this is really good and it's gonna fix all your problems.
[00:28:59] And that convinces the next rung up, The aspirational adopters who think it's going to fix things. And as it gets bigger they realize that it'll be more useful if it's ubiquitous. So they present this puff out their chest a little bit, like it's actually being more used than it really is in order to get it towards ubiquity.
[00:29:15] So keep that in mind whenever you hear about a new design name or read an interesting blog post, is that everyone wants their meme to be successful, and that means they might even pressure you to adopt it. They might not even realize that they are. But again, know your audience. If you're just writing code for yourself and you want to try out DCI, great.
[00:29:31] Thank you. If you're on a team and you're all on board with a given meme, then that's fantastic. Just remember that it might mean people outside your team won't understand it, and you might push them away. Let's talk a little bit about industry. This is what the industry looks like, except some of us work from home now.
[00:29:45] If you think that our inability to evaluate code as developers makes us uncomfortable, try talking to a business person. I'm doing a lot of business sales stuff now in my capacity at Test Double. And so we're gonna talk about business.
[00:30:00] How can a non technical business person be sure that they're hiring good developers? Without knowing. How, like, how to choose. It's really, it's apples and oranges. If a company goes to DevMind, and they also go to TestDouble, and they're trying to evaluate how we're different from each other, I'm an expert, because I own one of the two companies, and I don't know how I would convey that, because we're very similar.
[00:30:20] So how would we expect some total novice to understand the difference, the nuanced difference between us as developers or us as agencies? The answer is that a lot of businesses will put out what's called Request for Proposals, or RFPs. I don't know how many people in the room have ever been part of responding to an RFP, but we're gonna break it down.
[00:30:38] Remember back to that initial spectrum of different types of people. The more conscientious folks versus the people who are a little bit more self assured. On one hand, when you get a request for proposals to give an estimate or an approach for a given system, the more conscientious people tend to identify a lot of risks and assumptions, whereas the other ones will rationalize away risk.
[00:30:56] These folks on the left will emphasize collaboration whereas the more self assured might emphasize their own competence. On the left, they estimate pessimistically, tend to, whereas on the right, they estimate optimistically. It's all gonna go well, because they're great. On the left, they tend to, as a result, come in with higher bids, and so they rarely win the work.
[00:31:13] But on the right, they come in at lower bids, they often win the work. And whether we're talking about the bid or the project itself, on the left, they tend to blame failures on themselves, at least partially, whereas on the right, they blame failures on others. So the left self selects to get out of there, and the right keeps winning and growing and winning more work.
[00:31:29] So businesses if I'm giving a pitch to a business, and then at the very end of the conversation, they're like, we think we're gonna put this out to bid. They don't realize that just simply asking for proposals drastically biases their decision towards bad software agencies. And that's terrible, but that's just exactly how it is.
[00:31:45] I don't know how to fix that. But I do think that the fact that we as developers really enjoy these comforting myths, that our code is tangible and quantifiable and fungible and easy to evaluate, it just perpetuates this bias. And that's the reason we've educated business people that code is this concrete thing.
[00:32:03] And so it's totally fair of them to have this flawed metaphor in their minds. So instead, I'd really love it if us as developers were much more vulnerable and willing to admit and educate others that software is full of uncertainty. It's defined as, some net total amount of uncertainty.
[00:32:17] And when we talk about metaphors, the predominant metaphor for software development in business is construction. We're building stuff. We're makers. We're craftspeople. And that can be useful to a point, but it only goes so far. Another metaphor that I like a lot is surgery. In that like our software is here to solve a problem and we can either rush in and rip out your appendix and then you're in, like the hospital for three months because of how invasive that was.
[00:32:43] Or we could plan very carefully and make it outpatient to to take care of you so that it's not so painful or not so risky. That's why I got that metaphor from Dan North, look out for a book or something where he's gonna use that. I like that metaphor, simply 'cause it teed me up to talk about my very favorite thing estimates.
[00:33:00] On the left, the construction metaphor really brings us to say how much time will it take to build this thing with good code? Whereas the surgery metaphor leads us to ask a different question, which is, how much uncertainty and or risk does this project pose, does this feature pose? How much net uncertainty is there here to deal with?
[00:33:17] Now, neither of these questions are wrong in and of themselves. The problem is with their follow up. The natural follow up to the construction metaphor when you're trying to figure out how long something's gonna take is really what you want to ask, but you're not willing to ask it. How bad of my good code are you willing to accept?
[00:33:36] But on the right, the question, and on the left these are business people, they're not code experts, so how are they supposed to know? They don't want to buy something shoddy, right? Bravado will win here every time. But whereas on the right, the surgery metaphor will ask, force us to ask, so how much uncertainty and risk are you willing to tolerate?
[00:33:52] Why do these people go to MBA school? It's all about risk tolerance. This is a question they're really good at answering, so we should try to pull more of the conversation to the right. Under this model the way to work on your backlog would be to start by picking the most uncertain feature, identify all the risks and unknowns, executing Agile spikes to reduce the uncertainty until everyone's comfortable, and then finally, if there's no uncertainty left, it's really easy to implement it with boring code.
[00:34:15] We don't need clever code anymore because there's nothing interesting there. And then finally, you can pick the next most uncertain feature and continue and work against your backlog. Paying down all that uncertainty. I gave a name for this. I call this the Boring Code Discovery Model. There's a certification program coming soon, so just email us at testdouble if you're interested in paying for a certification.
[00:34:38] But when we talk about boring code, how will we know it when we see it? How will we evaluate it from project to project? What even is boring code? And I think that, fundamentally, it's about having enough shared context that we don't have to reinvent all the wheels. Minimizing the number of novel, technical concepts in our codebase so that our application just does what it needs to do.
[00:34:55] Clear, clearly named domain concepts, but not necessarily to the point of being really artsy. And then finally, lots and lots of empathy for each other on our team and for whoever is going to adopt the code later. So if you take those four things, and you just view them like audio sliders, audio mixers.
[00:35:12] It would be interesting as an experiment to go back into your own project experience and rate all of those different categories and see how that project went for you. An average Omikase Rails project has a good amount of shared concept shared context and it really, especially in 2005, got us really thinking about domain concepts in a way that we hadn't before and how we model stuff.
[00:35:31] A Prime Rails project, where you're using stuff like more DSLs, like maybe RSpec and Cucumber and Draper and stuff, the shared context is higher, we get to learn more up front. But the empathy might also be higher because it's more focused on communicating with others and business. Node. js projects tend to be anti framework, and so the shared context is lower, but it's more social.
[00:35:51] Like the module interface and stuff is pretty consistent across Node projects. Java projects typically have this, concofny of custom domain objects. But maybe have very else little in common. In EmberJS projects, one of the reasons I've been following Ember closely, I really love Ember, is we have this tremendously high barrier of entry.
[00:36:10] I, that, that sounds negative, sorry. It's a very steep learning curve, but once you reach the top of that mountain, You can do almost anything you want really fast. And that public API, once you learn it, look at what they're doing with Glimmer and all this stuff. They're building all these really advanced stuff at the implementation level.
[00:36:24] And so you learn it once, but once you do, it's a very high empathy community. They're all really great and friendly. So that's just one idea. Your mileage may vary, but that's one way that I'm trying to think about thinking about barn code. So what can we start doing tomorrow? Gotta wrap up. So we're gonna drop some truth bombs on our way out.
[00:36:42] First of all we obviously should all relax our conception that there is such a thing as universally good code. That how we evaluate code is subjective and flawed, and therefore, fearing that your code sucks is both totally natural and totally pointless. So acknowledge it and let it go. Claiming the right way exists.
[00:36:58] That might pull some people for you, might be a good shortcut, but it might just as well push other people who aren't like you away. And people who aren't like you are very useful. So we should be seeking opportunities to deliberate kindly and respectfully with people who think differently. If your team never disagrees, or if you never have to find consensus in your approach on your team, probably means you need new types of people, new blood in your team to check your corners.
[00:37:20] Also, upon exercise, whenever you see the word clever, just replace it with the word self indulgent. It's taken from Don Marley's book. Metaphors and memes are powerful, but again, they limit your audience to whoever already understands them. And finally, when someone doesn't understand your code, assume some of the responsibility.
[00:37:41] Don't assume it's their fault for not understanding your code. Kip Thorne, he's a famous physicist. He was the guy who came up with the idea for the movie Interstellar. He had this quote from his book about the science in the book. In the movie, some segments of this book may be rough going, though that's the nature of real science.
[00:37:55] It requires thought, sometimes deep thought, but thinking can be rewarding. Spoiler alert. You can just skip the rough parts, or you can struggle to understand. And he concludes, if your struggle is fruitless, then that's my fault, not yours, and I apologize. This is the guy who discovered wormholes, and he's apologizing to me for not understanding the physics in his book.
[00:38:16] And maybe that means that at least I could apologize to the next person when they don't understand my JavaScript. Maybe. My message is really just something, be courageous. more boring code. That's the end again. My name is Justin. Love if you got in touch with me, followed me gave me some feedback.
[00:38:34] I come from Test Double, we're a software agency, we build code with companies, and if your team needs extra engineers or extra help, please let us know. If you'd like to join us, if you think that we might be a good group of people to work with, we're always hiring, we're always interviewing join at Test Double.
[00:38:48] And I have stickers, they are not of Aaron's cats. They're a little bit more abstract. But if you'd like a sticker of our logo, I'd be happy to give you one and chat with you today at lunch. So everyone, thank you so much for your time. I really appreciate it.
Related Insights
New Stanford research shows 9.5% of engineers contribute almost no visible work—but blame won’t solve the problem. Here’s how leaders can fix the root cause.
