Curated Videos by amir - The Timeless Way of Software - Taylor Troesh

Music, music, music, music, music, music, music, music, music, music, music. You, you, thank you... So, so thank you...

Hello, friends. In my mind, I have this beautiful, beautiful thing: a programming language. Ooh, no good. Well, let's do something simple.

We'll build a very conventional, straight-lined, single-family home. How does it turn out? Ooh, not good. Maybe I should go even simpler. I'll just build an npm library.

Very small JavaScript library. Can I do that? I wonder. My website's on AWS. I wonder if it—oh no. It's strange to me how computers are, in some sense, the most deterministic things that humankind has ever made. And yet, if you type in "frustration" on Google, you get pictures of people with computers.

If you type in "peaceful," you get pictures of nature, right? Very strange. I love this Knuth quote: "We are engineering things, silicon, at the nanometer scale." And, like, literally, I tried it backstage.

Zoom takes 10 seconds to open up on my laptop—just the login screen. That's bananas. I'm not a fan of that. So, today I'm here to talk to you about some of Christopher Alexander's work.

And I actually had to rewrite a lot of my talk because this is the smartest audience I think I've ever encountered. Talking to all of you nice folks before the conference, I realized that I was saying things that you already knew. So, you know, I am not here for solutions. I'm here to confuse you. I'm here to ask some good questions.

And hopefully, that'll be something that you can do. It's good to leave you with that. Before I begin, though, I need some volunteers. My friend here, if I am speaking too fast, can you just raise your hand and get my attention, and I will slow down? You there, when I look really cool, can you take a picture and send it to me on Slack?

So I can send it to myself on Slack? So I can send it to my mom and you, my friend here. If I say something really dumb, just raise two hands. Alright.

PHP. The frustration engines, computers. I got tired of working for clients, so I now channel my frustration in one direction: trying to keep things out of the landfill. Replenish. I love working with them.

What we do at this company is that stadiums produce a lot of cans, as you can imagine—stadiums, theaters, and similar venues. All those cans need to be transported to recycling facilities. Additionally, the recycling facilities have materials that need to be sent somewhere else. We provide apps and software that facilitate this entire process.

I see lots of confused faces. Yes, I'm American. The government doesn't do this for us. They should, but they don't. We have to rely on Silicon Valley.

One of the cool things about our software is that you can see everything and travel seamlessly. Today, I'm going to talk to you about my experience building this system. The recycling centers have items that they want to dispose of; they click the app, and a truck comes to pick it up and take it somewhere else. There is a "Request a Pickup" button, which makes the process easier. That's how I joined the company.

And this is my first idea of how I would build something like this. It's a basic table; you have to start somewhere, right? This is maybe what the data would look like. This process feels familiar to me because I do woodworking and I use these old, unusual tools. When you get one of these hand planes, the blade doesn't quite fit from the manufacturer. You have to take it out, put some charcoal from a pencil on it, and then put it back in. After that, you take it back out, and if there's charcoal left on it, it means it doesn't fit right.

So, you have to shave it away like that so that it's completely level. If you shave too much away, then it's wiggly, and it's no good. It's a long process of trying to get this thing to fit. In the math world, we call this gradient descent. You have this fitness function that you have to test out.

And you can imagine that in the real world, with software, this could be very slow. Wouldn't it be nice if we just had equations? If we could model things symbolically and represent them, so that we didn't have to try them out in the real world? If you read this book, which I highly recommend, you will realize that this idea is a little bit problematic. You see, a lot of things cannot just be theorized and then brought into existence because the real world is complicated.

There’s this asymmetry; there’s this difference between the size of things that can go wrong or misfit and the precise, actual model that is real. You will very rarely find a nice, tidy little equation to take care of all your problems. You have to put the charcoal on, try something out, and then shave away the things that don’t go well. Here’s an example: one of these is Wolfram’s Rule 30.

There's a very tidy equation for it. The other one I used ChatGPT to make, and I can guarantee you there is not a tidy equation. Actually, I can't guarantee that. I can't guarantee anything. There it is, right?

Actually, I can't guarantee that. I can't guarantee anything. And there it is, right? Like, I'm suspicious that the other one has a more complicated equation. Equation.

So, back to my business problem. I've modeled something, and when I present it to the business folks, they immediately start pointing out issues with my mental model. I had included bales in the model, but not everything is baled. We work with different materials.

We do electronics. We do plastic, right? They all have different aspects. The accounts have different locations, and there are various facilities under each of these accounts.

I got some things wrong. Another part of the optimization process is called annealing. Annealing is what they do with metals. You raise the temperature, then gradually lower it, allowing the molecules to settle into the exact positions you want, because you've slowly cooled the temperature down. In the design process, this translates to keeping a whole bunch of different separate ideas in my mind.

And I'm testing all of them out, and as I'm getting farther in the process, I turn the temperature down. Like, okay, this one’s starting to feel better and better. What I end up with is something like this. It’s a little bit improved, right? These little hypotheses I have, all in parallel, have cooled down and solidified into something that feels kind of nice.

Much of the design process involves iterating to achieve a stable solution for high-dimensional forces. This is a simplified version. This is what it usually feels like, right? You're not just working in a single, neat plane; there are all these knobs you don't understand.

You're ultimately trying to fit a form you don't understand to a context that is somewhat incomprehensible. Not only that, it has a fractal quality, right? Consider a column with pillars. If there is a small crack in the column, what happens is capillary action.

Soaks up the water. It gets cold. It freezes. It cracks more, right? Over time, this thing starts crumbling.

The building falls down. You have people who might be injured, hopefully not. If nobody repairs the building, other buildings in the area will lose their value, right? This whole strange cascading fractal effect comes from a small property of physics. And we feel that when we're working for our rideshare, right?

We send people texts because they don't always have the app, right? So you send them a text. And you think about the thing in the URL, and you're like, "Oh, we have UUIDs." But we might want a little tidy shortcode. In order to understand how that works, you have to understand a lot about how computers work.

You have to understand that, oh, maybe you can code; the UUID is bytes, and then you have some deterministic method to get the short code. But then, what happens if that ID changes? Is that possible in this system? You have this whole fractal structure that extends all the way down as you examine it. But it can also extend up, right?

Instead of worrying about the software level, I could go up, right? Instead of worrying about the software level, I could just go lobby and say that license plates need to be the same. We need a standard because I don't want to have to use a string. I want to be able to use something with a check that I can understand. There are too many license plates out there.

My lobbying will not go very far. The world is very, very complicated. We have a high-dimensional problem space, but we want a simple problem space.

And remember what I told you: I have a lot of questions. I have five systems that do not work, and I will not provide any solutions. I am relying on you all to give me solutions afterward. So, let's dive into these. Tradition.

This hut is really cool. It has built-in scaffolding, so all repairs can be done without putting up additional things. The batter is built in, and that's very important because, in this region, there is no wood left over. The shape of it is pretty close to optimal for minimizing the amount of heat that enters while also conserving the coolness inside.

The rain comes down and it goes into those ribs, making them a little bit deeper and also providing methods for catching water. It's a very good design. Christopher Alexander made this discovery. The person in the photo did not create this hut; it was optimized by tradition over generations.

The culture itself acts as this gradient descent mechanism, but it only works if a few key characteristics are met—characteristics that also make genetic algorithms effective. You need to have some stable memory; that memory has to function correctly. You also need to have a fitness function, and things can't be too chaotic; otherwise, the fitness won't progress in any direction.

So the question is, can software benefit from tradition? "GOTO considered harmful," I think Dijkstra wrote that, and pretty much overnight, GOTO was gone. Noll. Noll is called the "$30 million mistake," or maybe it was $100 million, something like that. And we're still using it.

I think it's unclear whether or not the programming language or the programming industry is learning from its own tradition. There's this concept called Chesterton's Fence. The parable suggests that when you buy a property and there is a fence in place, you might want to build something, but before removing the fence, you should probably check its purpose. After all, there could be lions out there trying to get in.

There could be, you know, a whole bunch of chickens on your property that you didn't know about, trying to get out. It's probably unwise to move it. What's challenging in software is that it's so new, right? They tell me there's this fence, but computers have only been around for about 80 years, and cars for about 100.

When I'm thinking about work and the Chesterton fence, it's like, oh yeah, this thing is new. I can't trust that it was put there for any grand design or purpose. So it's really hard sometimes in software to tell the Chesterton fence from the Chesterton landfill, right? Processing speed has been going up like this, but latency—my experience with computers has not been improving. It smells like trash sometimes, right?

I can't distinguish between what's a fence and what's a bad thing. What's considered trash, you know? That's on the grand scale. On the micro scale, what I didn't tell you about my joining the company is that there was someone who wrote code before me. I had to deal with legacy code.

I missed a whole bunch of stuff. For one, a very important thing that I missed when I made my own solution was quotes. We used shipping third-party providers, and we have to ask them for quotes, but they take time to generate answers, so it's a whole process that you have to manage, and you don't get instant quotes, right? I completely overlooked that. Honestly, if I had looked for the gaps better, I would have been able to prevent some problems.

On the other hand, I removed 10,000 lines of code when I proposed my solution, right? I think next month we'll be able to remove one-fifth of the codebase. When I looked in there, I saw some assumptions that were no longer true. The product had changed, and some libraries had improved, allowing us to do things we couldn't do before. As a result, we ended up being able to remove those 10,000 lines of code.

That felt really good. So, I don't know; it's this whole big mixture of fence and landfill that I'm still not sure how to distinguish. That's what it feels like sometimes. Software folks don't know how to build huts. In one of Christopher Alexander's books, he talks about igloos, and when there's a leak in the igloo, it's pretty direct.

Like, you're doing your thing in the igloo, it starts leaking, and you can still think about something else. You can climb and repair it. And there's not a whole model; you don't have to think back to igloo school and remember what they told you to do in this situation. You just do it because you've been doing it your whole life. This situation, right?

If there's a leak in this building, you need to get an architect involved. You have to understand the concept of money because you need to have money to pay someone to fix it. Additionally, there may be regulations involved. If the leak is in a particular location, you have to fix it, and there may be specific regulations that dictate how it should be repaired. It's super costly!

Complicated. The reason it is complicated is because it was built with abstractions. That is necessarily so. The reason it is necessarily so is that when your only tradition is oral, your systems can only get so complicated. There's a limiting factor.

It is abstractions that enable things to become complex. When you misalign the physics with the mental model you have, things can go awry and become complicated. I often feel this way; it's like you have your assembly code and then all these classes, right? It's fascinating to think that RollerCoaster Tycoon was created by one person in assembly.

I think that was RollerCoaster Tycoon 2. Does anyone know? No, or 1. I don't know.

I don’t know. But, at the same time, I am unsure if we could support all of the wonderful software we have today without some higher-level structures. It's weird. I think sometimes that I'm, you know, I’m architecting a city, and I'm only playing SimCity. I have this beautiful SimCity working, and all the people are healthy and happy, and then I go put it into production, and it is not a good city at all.

The people are very unhappy in the real world. It's a classic engineering problem. I don't think I'm the only person who feels this way. So, you might be asking, "What if you just built igloos and then created blueprints for these igloos?" Keep things simple and make simple abstractions.

It doesn't work. The abstractions start diverging because the moment you have that separation, the people in the igloos can think, "Hmm, what if someone else is doing it? I can make my igloo twice as big because I'm just working for money." And as you create that separation, you realize, "Oh, now that I have money, I can put more stuff in my equipment." Once this loop is broken, you automatically start getting these incentives that can lead to separation.

So, back to my problem. Where do I store this? A text file? Plain text? No database, just put it in a file.

Not a good idea. Thank you. ORM? Oh! Object-oriented or functional?

Depends. Depends. This is my goal, right? All of those things I just talked about—object-oriented, functional—they feel really small to me when I think about my goal. Working at this place, the software I'm making, is to keep things out of a landfill. Once I re-engage that part of me, the purpose of what I'm building, a lot of these questions become easy to remember as distractions.

A lot of you have probably heard of this book, *A Pattern Language*. I recommend it very much. Christopher Alexander spoke at OOPSLA '96, the big object-oriented programming conference, and he seemed a little bit disappointed with how patterns actually turned out. You can listen to the talk, but it sounded to me like there was no real evidence that they did what he intended. If you read his later words, what does he say?

The Nature of Order? Something like that. Very good. It's much longer. Patterns are just another level of abstraction.

They might not do exactly what you want. So, let's get down to the facts: science. One nice thing about science is that it works regardless of whether or not you believe it or trust it. It just works.

And sometimes, it can simplify things. This is how people were charting all the stars and planets before the heliocentric model, before we knew that the sun was at the center. They had these things called epicycles. You can imagine how annoying that math would have been to do—definitely not very fun. Then it just turned into a much nicer model. Bam!

Another story in this vein that I really like is about Semmelweis. He is credited as the first physician to realize that washing hands is probably a good idea. In the hospital he worked in, people would be performing autopsies and then delivering babies—autopsies and delivering babies—and that's not a good practice. He was the one who said, "Wash your hands, doctors." However, they did not want to hear that because when you have spent a long time doing something, it's not enjoyable to be told to do things differently, right?

They'll tell you, "This is a craft. This is an art. It's not a science." Whenever I hear that, I think of good old Christopher Alexander, who was trying to say some of the same things: that, no, we can be scientific about design. And when I hear that, I'm like, "Ooh, am I being scientific about design?"

And I look back. No, no, my designs are not good. So how do you do science? Anybody can do science. You just have to be very specific about the questions. You have to make questions that somebody else can verify.

That's it. That's the whole thing. It's not hard. You just need to be specific. Some things I've started to be specific about that I really like.

The first unit is dollars per kilowatt-hour. If you want to compare whether to build or buy, or whether or not to allocate a team to do something, you can try to convert things and do a rough calculation in terms of dollars per kilowatt-hour. The key conversion is that humans use about 100 watts per day to live. This is equivalent to a 100-watt light bulb, right here, guys. My mom would say that I'm like 30 watts, but it's really around 100 watts.

Smiles per watt. I think we don't talk enough about how happy things make people. I did a podcast and, on my blog, I posted a whole bunch of consumption metrics for Netflix and Spotify, as well as other platforms. It turns out that, on average, people pay about $1 per hour of digital entertainment, and that's remained constant for like 10 years.

Weird. $1 per hour for whatever that entertainment is. I'll skip it; however, I do like the time capsule test. You can play a little thought experiment: If all the documentation on this project disappeared, how long would it take for someone to figure out how this works?

That's something that you can actually experiment with, but it's pretty impractical because it can take hundreds of years sometimes. We have to be careful about metrics; remember, this is a multi-dimensional issue. If you focus on just one dimension, you might end up messing everything up by optimizing for the wrong thing. So, always be aware of Goodhart's Law. Now, back to my personal problem: how can I be scientific about this?

How can science help me make this a little bit better? One thing I have found, which I think is type theory, right? Type theory gives you certain guarantees about your system. If you are a little bit methodical, then there are certain classes of errors that you just don't have to worry about. It doesn't turn your problem from 6D down to 1D, but from 6D down to 5D, and that's nice.

There are certain things you just do not have to worry about. There are also certain upfront costs in some situations that you have to pay. But overall, I have found that it is worth it. I wish there were more scientific evidence on this because I go online to try to find out if functional programming has any evidence supporting that it is better. However, I haven't been able to find that evidence.

It feels more like horoscopes sometimes. Programming languages— is there any really stellar proof that any of these languages matter? I haven't seen it. Maybe I'm not reading enough. Again, if I am wrong here, please send me angry messages.

I want to know. Sometimes, all of this science feels a lot like the medical industry, where medical research is precise. It is science, right? It's a little bit fuzzier than physics, though, because you're dealing with epidemiology, right? But this is a real fact about the world, right?

That humans with high blood pressure end up being at risk for health problems. We can measure this statistically. We know based on the physics of your arteries and other factors that high pressure is not good for you. It is clear that having high blood pressure is harmful.

A little tension. And why did I put this in here? Oh! If your doctor says, "No, no, no, medicine is all just opinions; there are no facts," or if your doctor tells you that a blood pressure of zero is debatably bad, and if there's any room for argument, I encourage you to find a new doctor.

But what's weird is that I don't see any of this same thing in software. All I hear is, "It depends." I don't see any really, really hard lines anywhere, and that's strange to me. This is the number of lines of code in the Linux kernel since 1991. I think this is the Linux kernel.

And now it's at around 30 million lines. It's bananas, right? That's a lot! Just a quick slide.

Aside, how big should a program be? Is 30 million lines too big? Let's try using some science, okay? This is Kolmogorov complexity.

It states that the smallest program can be is the compression of it plus the compression algorithm added onto it. That's the smallest theoretical program can be, so we do have a rough lower bound on things. In fact, you can do science at home! I have a little blog post with a script you can use to input any program, and it will give you a rough estimate of at least one type of lower bound for your program. This is not some abstract theory that cannot be tried in the real world; you can do this science at home. Another place where you start seeing the science pop up is Project Euler and the Code Golf Stack Overflow. You should start looking at these resources.

This is a literal program that prints "Hare Krishna" a whole bunch of times in a certain pattern. I'm not joking; it's 22 bytes. This is where I found it. This is how it works. When you start seeing things like this, I also think that programs can be a lot smaller.

I don't know whether or not it's useful; I'm not sure. This guy—look up a reference term, R-E-F-T-E-R-M—wrote an alternative to the Windows terminal that, according to him, has feature parity and runs about 10,000 times faster. It can stream between 10,000 and 100,000 characters to the stream per second.

And just one guy in a few weeks wrote about 500 lines of code. When you compare that to the entire Windows team that has been working on Windows Terminal for decades, it feels strange. Something seems wrong there. It feels like there's a blood pressure problem to me.

And it's weird that the science is not working here. Something is wrong with our science. I'll skip this, but no, I'm not going to skip it. It's good. It's so good.

Will this work? I'm going to skip it. Look up croquet: C-r-o-q-u-e-t. Alan Kay made a whole operating system in 15 megabytes, and it can roughly do everything that a Windows computer can do.

That's weird. Isn't that weird? Like, look up the demo! He's got this whole virtual reality thing going on. It's got this AI feature where he draws a fish, and the fish swims off.

You draw it in 2D. It's strange. It's strange that I see some lower bounds here, and nobody is willing to say that 30 million lines might be a blood pressure problem. This is the average age over time. It's been getting better.

Medicine has been working, right? Sometimes it doesn't feel that way because you read dietary research documents and think, "Oh, none of this seems correct." However, overall, they are improving. The hardware is getting better, but I'm unsure if the software is improving as well.

I'm unsure which parts of software are getting better because latency seems to be the same, and the number of bugs seems to be the same. I don't know where the science is, and that might just be me. I might be looking in the wrong spots or with the wrong communities.

One other thing is that software seems to be contributing to some unhappiness, and that's not good. That adds a sense of urgency to the situation. We are seeing real-world side effects, such as the rising rates of teen suicides. If we have any role in this, we should address it quickly. I attempted to read the research, but I'm not sure I fully understand it.

What's the ratio of industry professionals to academics? It's very small. I can't read these research papers; they're not written for people like me. They're written for smart people.

There's a paywall on almost all of them, too. It's like, why does research require money? If science doesn't work, maybe we should just rely on intuition. We have a six-dimensional problem, and you are equipped—everyone is equipped—with a very, very fast neural network. Neural networks are very good at high dimensions.

What you need to do is match. Focus your neural network on finding things that seem stable in high dimensions. It should be predictable. It must be scientific; otherwise, you can't really share it. Personal opinions are not very useful.

So, if you're neural networking at full speed to find things like this, where do you find them? You end up finding them pretty much everywhere. Anything that feels alive is necessarily one of these systems. It's living, stable, and harmonious. This cloud of words captures this experience.

Your pattern matcher has already recognized these experiences. This is the gist of Christopher Alexander's book, *The Timeless Way of Building*. You end up feeling alive when you interact with systems that feel alive. And you can recursively design systems that feel more or less alive. When I'm programming, it's strange.

Some days, it feels like it's all the best parts of a Zelda puzzle, where I feel so smart that I was able to figure out this thing. I'm like, "Yes, yes! I get that key, I don't know, whatever." Other days, it is misery because I am working with Python, and some package broke, taking me two days to figure out how to clear my entire machine. It's frustrating, right? Sometimes it feels alive, and sometimes it feels dead.

And like that, everyone I talk to happens to have that same feeling sometimes. It's weird because people tend to report the same feelings about the same things. If you read Christopher Alexander's work, he makes a very good case for this. There’s something objective here; this is not just a matter of opinion, even though it involves people's opinions. At a statistical level, you can measure and make predictions about people's opinions.

That's a fact: facts about feelings. Another smell I have is documentation. Does everyone here hate documentation? Yeah, okay.

Does everyone here hate documentation? To me, it suggests that something wasn't designed correctly. The best programs are the ones where you look at the API and think, "Oh, I got this." You implement it, and if something goes wrong, the error message tells you exactly what went wrong. Then you say, "Oh," and just tweak it.

But you don't have to learn to learn to learn, right? There aren't a whole bunch of levels of indirection. It's like this natural feeling where you just interact with what's happening. Christopher Alexander has explained this as different forces that you need to be able to resolve yourself. People like being next to nice windows, but people also like to sit.

If the chairs are not next to the light, you will be uncomfortable. And these forces kind of exist everywhere. For instance, I am wearing a jacket right now. I'm extremely hot, but I’m still wearing it. I’m sweating a lot under here, and if I take it off, then I will be embarrassed.

So these forces are colliding. It's very, very sweaty. When you look at these forces, they also become recursive over time, and they get worse. If you have a guest bedroom where the window isn't next to the chair, and there's no way to resolve those forces, then you won't go in there.

If you don't go in there, then you will never know it needs to be cleaned. And if you don't know it needs to be cleaned, then you're going to want to go in there even less because you're going to be like, "Ooh, I haven't cleaned there." Then your friends come over, and they're like, "Oh, we're in town." And you're like, "Oh, how about we come over?" "Oh, yes, you can stay in the guest bedroom." Then they stay in there and say, "We're not friends anymore," and then you have no friends because the chair was not next to the window. Same thing for legacy code, right?

Oh, we'll refactor it at some point. The longer your team avoids that module in your codebase, the worse it will become. You'll continue to find every excuse, and the problem will only get worse until your company is bankrupt, right? Eventually, there may come a time when you simply can't fix that issue.

My own heuristic is to only refactor the things that you can't. Even if your system is stable, right? Your house has every chair next to the right window. Everything is precisely where it should be. Everybody's happy.

Your house is vibrant. That doesn't mean it's not part of a dead system. Suburbs are a key part of this. Everyone in the suburb might be happy, but suburbs have forces; they create forces that cannot be settled within people, right? Parents have to go to work, but they want to be with their children, right?

That's a conflict. Children now have to go to school, but they don't want to because they want to learn what their parents do. Isn't it fun to go to work with your parents? However, due to the structure of their lives, the parents and children often don't understand each other. The parents come home from work tired, and the children don’t understand what their parents do. As a result, there's no common ground, and the children may misbehave out of a lack of respect, which further complicates the relationship between parents and their children.

My one problem with intuition is that I hear a lot of people talk about elegance in software, and that always scares me. I'm like, oh, elegance lives in software. It can become this thing that is a false idol. In the same way that during the Industrial Revolution in England, the main word everyone said was "efficient." This must be efficient.

And of course, it led to a lot of good things, but it also resulted in a great deal of pollution and issues that we are still dealing with. The pursuit of efficiency often comes with similar consequences. I believe that the pursuit of elegance can yield the same results. Therefore, you must be very careful in how you engage with living systems and strive to broaden your perspective as much as possible. The last section is heuristics.

A whole bunch of things don't work, as I said before, but I like them. So I'm going to share some things that have worked for me. Let's go back to my original example. Remember, these are the structures for requesting pickups in our system. One thing that felt very alive that happened recently is that the designer at our company kept giving me Figma designs—the mock-ups—and I would create them, and then you would go, "This is trash; the corners are not right, the elements are twisted, it's not responsive, no good."

And I'm like, the designer knows CSS; why is the designer giving me Figma files for me to mess them up, right? And try to implement them. I was like, "Hey, do you want to just contribute to the codebase directly?" He’s like, "Yeah, sounds great." But am I smart enough?

Like, yeah, you're playing smart. Now he's just committing. That saves us both a lot of time and headaches. This is a pattern you will see all over the place. My first job, I sat next to the head of customer support, and he kept asking me for things.

I'm like, I invited him over for a weekend, taught him S&P, and he just started solving all the problems. Instead of saying, "Hey, we're having customers do this," he'll just be like, "Hey, your module over here is incorrectly adding stuff into this column." It was such a nicer experience for us, and he was happier too. There was less frustration all around.

You have to give people the tools to resolve those inner forces. That's a living system. Another thing that I like is Masanobu Fukuoka. He is famous for being anti-science, but also for his do-nothing agriculture.

He is able to grow three times the amount of produce per acre by doing literally nothing. His books are wild. It's a whole thing. Because nature does, you know, know what it's doing, and sometimes we think we know better than nature, but we don't. One area I try to practice do-nothing development is where I just kind of write code, and I write lots of it, keeping it all in a single file.

And it gets 2,000 to 3,000 lines. No modules, no other files. I call it the Great Wall of Code. Some people don't know, but I don't like this. It's uncomfortable at first, but it's strange because all my coworkers see it and they're like, "I'm not dealing with this."

And then after literally 20 minutes, they're like, "Oh, I understand the entire thing because I didn't have to jump around from file to file." So, in practice, it seems like it's working. I'm not sure what the limits are on that yet. If I were to be scientific about it, my guess—here's Taylor's conjecture: I think code bases, when you have a whole bunch of model modules, right?

Things that point to each other—this is Object-Oriented Programming (OOP) or functional programming, right? You have components that resemble a network. You will encounter structures that look like this. However, if you store things in a linear file, it becomes more cumbersome, leading to logarithmic complexities.

That's my conjecture. I think you could search for that or conduct some statistical studies on GitHub, and my conjecture is that you'll find results supporting it. Here's another heuristic: every system is characterized by the events that occur within it. The codebase I inherited took two hours to complete the CI checks.

That means we only had four opportunities a day to be told that we were wrong. That is very slow. So, one of the first things I did when I joined the company was to make it faster. It's now two minutes—two hours reduced to two minutes.

Huge difference. Because the computers can tell me I'm wrong way faster now, and that's a huge benefit. Another thing I like is IKEA-oriented design. That's a heuristic I have.

Make semi-disposable structures, right? Ikea furniture—it's like you can do whatever you want with it. It's not like there's a grand master plan; it's not an emblematic piece, right? You feel comfortable doing what you want with it. If you need to cut it in half to fit your dimensions, good. As soon as I feel like I've built something very grand, I start getting suspicious because it needs to feel like Ikea. One example of this was when I realized that on the front end, when people were trying to get these pickups, they had to do lots of estimates, right? They would come back and say, "No, I don't want this." We actually needed to separate the estimate from the delivery; the pickup was not a shape that mattered at all.

You have an estimate that is provided to you, and if you like that estimate, you can go ahead and request a delivery. Another interesting thing to look up is the Gossamer project. We have human-powered flight, and not much science was necessary. The only reason these individuals were able to fly was that they focused on attempts and created systems with duct tape and very inexpensive materials, continuously iterating, iterating, and iterating. There was no groundbreaking science involved here.

The first people to ever fly by human power experienced a significant process difference. In my case, I kept things lean, which allowed me to realize that, okay, you don't always... They give you a quote ID, these third-party providers, sometimes, and it could be a very long time before you receive it, so I had to redo a whole bunch of stuff. However, it was nice because I could just throw things away and iterate quickly since everything was made with duct tape anyway. One thing that's been very conspicuously missing from this is that many people request pickups, and those pickups might be near each other. I tried building that the first time around, and it did not work.

I did not understand the problem well enough, so I went to the product team and asked, "Hey, is it okay if we don't share trips?" They replied, "Yeah, that's fine." Now, we have a solution that works, and we can grow a complex system out of a simple one. It feels like a much nicer experience for me, at least.

Jigs. I use hand woodworking tools. In woodworking, you often end up building many of the tools that you work with. For example, you build your workbench and create items that require precise right angles and repetition. I don't see this concept applied in software as often as I would like.

People don't create things out of the tools they are using. I work a lot with SQL and write numerous scripts in SQL. It's not always a pleasant experience, but it can be a great one. It's hard to explain, but if you're heavily involved with SQL, be cautious about relying too much on JavaScript or Python scripts because they are not SQL, and you'll encounter some discrepancies.

Like, create tools from the tools you are already developing. There are these things called "desire paths." That's another heuristic I have. If there's some recurring issue in the company, especially with customer support, where you keep encountering the same problems, go and address those problems.

It's some force that the universe is telling you is problematic, causing conflict. I've also realized in my code that sometimes the trucks do not make it to their destination. It's very rare, but it happens. The question is, do you add an edge case, or do you play by your own rules? That's something I haven't figured out yet, right?

I could allow some weird zeros in there, but then that's a foot gun waiting to happen. So, you could add a very, very specific edge case column in the database, but because it's rarely used, it's rarely tested. I haven't found any answers for this, but it’s something I think about a lot. Ah, protocols versus platforms—one other thing I like to ponder frequently.

If you are creating something that is very proprietary and specific, sometimes it's easier to just think about what existing tools you can use. Software has been around for a while, and the protocols are quite nice at times. Anyway.

I have people walking back there. That was my talk. Thank you.