Technical Hobbies

About this Episode

This episode unfolds like a long, curious conversation among people who can’t help but see software everywhere—even when they’re not writing code. Mike opens with a story about large language models: how something as simple as guessing the next word, repeated trillions of times, leads to strange and powerful emergent behavior. Models start writing poetry, solving math problems, and following instructions—not because they were explicitly taught those skills, but because mastery in one domain spills into others. That becomes the episode’s core theme: real understanding, whether human or machine, comes from making connections across disciplines.

From there, the panel moves into personal stories. Justin talks about electric vehicles and electric dirt bikes—machines made of frames, motors, batteries, and controllers that must “speak the same language” to work. Tuning power output or regenerative braking feels eerily similar to designing distributed systems or microservices: misaligned interfaces lead to failure, while deep understanding unlocks performance and joy. Kyle shares his experience retrofitting a sound system into a 1994 Ford Ranger, cutting metal and rerouting wiring to modernize old tech. Thomas brings in video games, describing how a decade-old console game breaks when ported to modern PCs because its logic was tied to frame rate—an unintentional lesson in legacy assumptions and technical debt. Each story circles back to the same realization: whether it’s hardware, games, or cars, the same systems thinking applies.

By the end, the conversation becomes more reflective. Mike ties everything to teaching math, music, and writing, arguing that we often strip these disciplines of creativity by overemphasizing rules instead of problem-solving. Math, like programming, is a language for understanding the world; music and writing are languages for expression. The best software engineers, the group agrees, aren’t just chasing paychecks—they’re hooked on the joy of making, tinkering, and solving problems. The episode closes with a gentle challenge: don’t only optimize systems for work. Build something for yourself. Learn a new language, musical or technical. Touch hardware. Make noise. Those side paths, it turns out, are often what make us better at the thing we thought was our “main” craft.

Transcript:

MIKE: Hello and welcome to another episode of the Acima Development Podcast. I'm Mike, and I'm hosting again today. We're happy to have with us today Justin, who has not always been with us lately [chuckles] sometimes.

JUSTIN: [laughs]

MIKE: [inaudible 00:32]. He's not going to probably be here for the whole discussion, so I'm going to kind of pick on him a little bit at the beginning. But it's great to have him joining us. We've got a longstanding panelist, Kyle, and we've got Thomas who's been with us a couple of times now, right?

THOMAS: Yeah, I think the last four times, so...

MIKE: Cool. Cool. And, as usual, I'm going to...and there's actually even more relevance today. I'll [chuckles] come back to... I'm going to start by something a little outside of...well, this one's actually kind of in software, but not in writing software.

So, large language models have been all the big thing in AI over the last few years, and it's just exploded. When I say exploded, they're expecting something like multiple trillions of dollars to be invested in data centers and AI generally over the next five years. That's just unthinkable sums of money. Unthinkable sums of money. By the way, we do have Will Archer joining us [chuckles], who is here a little late. So, unthinkable sums of money. It's a big deal. These large language models are a big deal, and they often display what's known as emergent behavior. 

Now, let me give a little explanation. How they usually train these things is shockingly simple. They have a whole lot of weights that they use that can be moved around to make a guess. And they feed it some text, just a series of words, and they don't even recognize the words. They just know each one of them is a number. They, like, say, "Here's the series of numbers. Which one's next? Guess the next word." And, of course, it's going to be wrong. They'll nudge it a little bit. It's going to be a little closer, and they'll do it again. And they do that trillions of times [chuckles], like, just an unthinkable number of times.

And it turns out, if you guess the next word enough times, weird things start to happen. First of all, you get really good at being able to say plausible natural language. I'll say English because we're speaking English, but they do other languages as well. But, you know, you can give it a starting word, and it'll come up with a sentence that follows that word that's very likely. And that sounds pretty boring, though, right? Guessing likely English that doesn't sound particularly useful, except that there's this emergent behavior, because it turns out that if you get really good at guessing words, you're also kind of good at other things.

For example, it can generate poetry. You say, "Give me a poem." In fact, I saw one yesterday. "Give me a poem about fourth normal form [laughs] and emotional." Well, actually, how was it described? "Emotional lyrics about fourth normal form." 

JUSTIN: [laughs]

MIKE: And it obliged [laughs]. And this particular example I saw yesterday, it was done by our frequent participant, Dave Brady. He then sent it to an AI music generator and had it generate a prog metal song based on it. And [laughter] it was plausible and super cringy. But you can do that by just guessing the next word.

You can do things like knowledge base querying because, guess what? If you know some stuff, right, asking, "Well, what's the answer to this?" Well, if you know the next word, it'll tell you the right answer. And then you get even into more perhaps amazing things like multi-step reasoning, like arithmetic. If you're guessing the next word, you're going to have to learn to handle some basic arithmetic problems, and it learns to do that. And even more, it can do things like instruction following or tool use like, "Go write me some software," or, "Go" as we talked about a few weeks ago, "act as my agent to go take some actions on my behalf." And because it's going to do plausible, you know, believable things next, it'll tend to go do that. So, there's overlap.

Where I'm going with this is there is overlap between fields of expertise, between domains of expertise, and sometimes getting good at one thing can help you in other stuff. I've tried for years in this podcast to connect concepts [chuckles]. It's something I try to do. I think it's useful for discussion generally. I especially try to do that with abstract concepts, you know, things that are hard to think about, try to connect them to very grounded things, very tangible things outside of software development.

I think there's often more overlap than we might think superficially between things. Part of what makes us good at thinking as humans is that we make connections. We make those connections between different domains of expertise. We reuse knowledge. We repurpose knowledge. We take it from one area to another. And finding surprising connections, it's delightful; it's enlightening.

So, AI is starting to show some of those things, some of those emergent properties, but, frankly, it's not very good at it yet. I mean, you have models that have read basically the entire internet, and now they can usually answer your question about the weather right [laughter]. We need to get better at this. But we're going to use our human skills, and we're going to talk about software-adjacent things that we do. This is a chance to go a little outside our normal boundaries and explore where there might be some overlap in things that aren't specifically software.

As I said, I would like to start with Justin and hear about some of the things you're doing outside of specifically the software world, and what you've learned from them, and maybe...well, exactly what have you learned from those? Because I'm guessing it's going to be applicable.

JUSTIN: Yeah. So, a couple of things that I am doing right now that are software adjacent. I don't know if you guys know, but I am a big enthusiast for electric vehicles. I'm inside my, you know, GE Chevy Equinox right now, fully electric. I love driving this thing around. I also like to ride around my electric dirt bikes. And if you haven't been on an electric dirt bike yet, it is a lot of fun. Instant torque. You can ride it in the wilderness without, like, scaring animals or annoying neighbors, all of those things.

And the thing about the electric dirt bike, it is a platform that you can customize to your heart's or to your wallet's content. I particularly like Talarias. There's other ones like Surrons, and, I mean, there's a whole slew of them now. But with my Talaria, I got one of the xXx ones. But you can customize this, the base of this thing. You basically have a frame, a motor, a battery, a controller, and then, you know, a slew of other things, including brakes and other things. And you can swap them out.

The important thing, though, is that your controller has to be able to converse with your battery, with your throttle, with your brakes, because you have regenerative braking. And if you don't have a controller that can talk to these other things and that can, you know, interact with them right, you aren't going to go anywhere. And it certainly is not exactly software, but it is software.

The controller has a kind of a base level of software that you can go in and update and tweak, such that you can tell it to draw more power from the battery. You can tell it to output more amps to the motor, and you can tweak things like those such that you can go faster. You can be more reckless, all of these things. But if you don't understand the language of this controller, you can mess it up.

And back in my development days, you know, when you're setting up a microservice architecture or something like that, or a multi-level architecture, if you don't have, you know, a lot of the same things apply, where you need to be able to communicate with the different pieces of your architecture. And having fun with the electric dirt bikes, you know, is very applicable.

I don't know if it's, like, something that could, you know, ever make me money [laughs], but it is something that's a lot of fun, slightly dangerous. Always wear your helmet, let me tell you, and probably protective clothing too. But, you know, ripping up the side of a mountain all the way to the top and then going down the other side is something that, you know, it just is a lot of fun. And I highly recommend it if you guys haven't had a chance to do that before with the electric dirt bikes.

MIKE: That's interesting. A few years ago, I took a class through Udacity where we did self-driving vehicles. And as kind of a capstone project, they put your software on a real car, and it drove around [laughter]. It's fun. Like, that's a lot of fun to be able to put those pieces together.

JUSTIN: Yeah, I'm sure, slightly dangerous, and, you know, trying to figure everything out just goes to show, actually, how hard it is. You look at the Tesla, you know, full self-driving thing that they've been trying to get off the ground for ages, and, you know, they certainly aren't perfect yet. You look at Waymo and how many cities they're operating in now and the iterations that they've gone through.

And it almost looks like, you know, in another, either right now, or in another couple of years, this is going to be a solved problem, where, you know, vehicles can drive themselves. And your commute will...basically, if you have to go into the office, heaven forbid, you could just hop in your car, say, you know, "Take me to the office," and then you can listen to your podcast, or play your game, or work on the way into the office, and it'll just work.

MIKE: You could record a podcast while [laughs] driving.

JUSTIN: Record a podcast. I am not moving right now [laughs], but I wish I were. I'm looking forward to the day when I don't have to worry about driving because I actually enjoy driving. But if I could, you know, if I could reserve the times where I can enjoy driving for those times when I can really enjoy driving and separate that from the times where I don't want to drive, and I could do other things, that's going to be a good day to me.

MIKE: So, you'll drive the dirt bike, but let the car drive you to work.

JUSTIN: Exactly [laughs].

MIKE: So, who else got something interesting, software adjacent that they're working on they'd like to talk about? I know, Kyle, you mentioned something that you had in mind.

KYLE: Yeah, mine is, I guess, somewhat similar to what Justin was bringing up. The thing that I've been working on the most lately has been a sound system in my '94 Ranger. Where that's kind of software adjacent to me is just all the different components that you'd be interacting with.

I've replaced the head unit, ripped out all the old speakers and the old wiring, and re-ran everything, you know, put in new subs and speakers, and yeah, just got everything working. Especially with an older vehicle like that, the room that you have, you have to be creative with where you're putting things. I guess that's true with a newer vehicle, too, but yeah, just the different components that you're dealing with there, the older tech, too, because you're not wiring it with the same headers and stuff that you would with a newer vehicle with the alarms and stuff that you'd have in those.

Other projects might just be...I don't personally have a 3D printer, but I've been working with some fans and some controllers, and just tinkering around with some 3D printed projects with my spare case fans, and just working on a desk cooler. It's nothing extravagant, of course, but just working with the plans and the files that you need for putting that into your 3D printer. It's kind of the projects I've been working on [inaudible 13:08] really.

MIKE: So, I'm curious about the sound system. Does it fit the same as the old sound system?

KYLE: Does it fit? No, no. There was cutting involved. 

MIKE: [laughs]

KYLE: You had to retrofit it to fit in there, new screw holes, new frames. Built a custom box to keep my amplifier in because nowhere for that to be kept, of course. And I used to say I don't have a back seat in that now. It was only a half cab anyways. But a lot of what I had in there ended up in the toolbox.

MIKE: So, when you're retrofitting a legacy system, you have to move some stuff around. You have to make sure that you've got things discreetly componentized, so you don't end up with a horrible mess [laughs] of spaghetti. Hopefully, you didn't end up with that with your [inaudible 14:04] [laughs]. And you have to think about interfaces that maybe aren't the ones that you'd choose.

KYLE: And there's, you know, with the relation of the speaker wire specifically, looking at that, I was just like, this is just too old of tech, you know. I've got to rip this out and put in new. I think that would be pertinent, too. Sometimes you've even got to look at the wiring in your application and decide, well, maybe this just isn't going to work. And you need to rewrite stuff that's existing, you know, not even just retrofitting. You might have to just rewrite the glue between your components.

MIKE: Were there safety or security concerns that you had [chuckles] to modernize to work around?

KYLE: Probably should have [laughter]. But I made it work the way that, you know, there weren't grounds in the places that I wanted them, so I put grounds where I needed them, and put holes in the frame where I needed to get the wires through that weren't originally there.

MIKE: [laughs] Sounds like grounding was a good thing. The holes in the frame, maybe not so much.

KYLE: Maybe not. I mean, '94, it's full metal. I don't have too many concerns there. But, you know, you don't want to be putting holes in your...what do they call that? Your firewall right there for your driver's side.

MIKE: That's great.

WILL: I mean, the '94 Ford Ranger, like, I stopped caring about a lot of issues when I was like, '94 Ford Ranger, okay, upgrading the audio? 

MIKE: [laughs]

WILL: What's the audio? What are you trying to accomplish in a 1994 Ford Ranger audio-wise?

KYLE: If you can get the sound loud enough, you can't hear everything that's wrong with it.

[laughter]

WILL: Okay, all right, I'm sold [laughter]. Yeah, sold.

WILL: Now you're talking. I mean, you know.

KYLE: [laughs] It's a play toy. It's just a play toy. So, it's, you know, I'm not getting out of it what I put into it, but it's fun to tinker.

WILL: I'm going to stop you again. What you put into it, a '94 Ford Ranger, I mean, like, gas to the pick-n-pull like... [laughter]

KYLE: You don't understand the love that some of us have for our old Ford Rangers. There's communities around this, man.

WILL: Listen, man. I love a Ford Ranger. Like, hands down, like, I love me a Ford Ranger. But, like, as I'm going to go on, right, like, why just one? At this point, right? Like, it's just, how many are going to fit in the back of the tow truck, right [laughter]? Where it's just like, hey, listen, you have a fleet, you know what I mean [laughter]?

KYLE: They are pulling the tow truck. That's the thing about a Ford Ranger.

WILL: That's right. Like, yeah, it's the Ford Ranger Theseus, right? How many colors is it [laughter]?

MIKE: I mean, there's, like, no part of that that's not applicable to software [laughter].

WILL: That's right.

MIKE: If you went into a codebase that's over 10 years old, [laughs] there are many pieces coming from many years.

THOMAS: Yeah, actually, I have something to add to that. It was really interesting, and it kind of goes back to the old technology. Now, I always tie a lot of stuff to video games, but this one was very interesting in particular.

So, my friend, the other day, he was trying to get into Fallout 4, and there was a PC port on a Fallout 4, right? And so, originally, it launched on console 10 years ago, in 2015. But it was really, really interesting because he was bringing up a problem to me that he was experiencing in the game. And he's like, "For some reason, everything feels four times quicker than it's supposed to, you know?" He's like, "I don't know why, but it's hard to play the game because everything's, like, just fast-paced."

And so, I was telling him, I was like, "You know what? I bet I know exactly what it is." And it's because older games like that, when they were on a console port originally, they were locked to a certain FPS cap, you know, 45 FPS, 60 FPS, and that cap kind of interlocks alongside, associates it with the time in the game. So, if you have a higher FPS, stuff is going to move so much quicker. If you have a lower FPS, stuff is going to move so much slower, you know.

But that's the interesting thing, and it's kind of mind-boggling that they didn't think of that when they ported it to PC. Because when you have PCs, you know, you have these really expensive gaming rigs that are running much higher FPS. So, he's getting 240 FPS, so that explains why it's about four times quicker, you know.

So, having to go into the files and everything and interact and kind of change the cap settings and change how VSync works because if you don't, and you try to play that at 240 FPS, your game is going to be running, like, you know, yeah, four times quicker than normal. And I remember that was a big thing I read about when emulators were starting to come out on the PC for, like, Pokémon games. People were experiencing that like crazy, where you're getting 900 FPS, you know, in a Pokémon game on PC, and the time is accelerated like crazy. Just really interesting, like, even just 10 years ago, a game released 10 years ago, and I think it got a PC port in, like, 2018, just even how archaic that technology is compared to what it is now, and how just the smallest thing as FPS can make such a drastic difference. And it's very interesting.

MIKE: It's been a longstanding thing for the community of people who try to keep games going. A lot of the early games they ran at the speed of the hardware [laughs]. And you might be able to get a port that, you know, displays at your screen. You've got to slow that way down; you're going [chuckles] to have to add a whole bunch of cycles.

THOMAS: Yeah, it's so fascinating.

KYLE: I'm wondering how many of us are sitting here thinking about the turbo button, or is that just me [laughter]?

WILL: Like, it's like turning the air conditioner off on your Ford Ranger [laughter].

KYLE: You're stuck on that, aren't you?

WILL: I drive a Tacoma. Like, they graduate. They evolve, right, to like, you know, 250, 300K. You know, like, they're on the exact same trajectory.

MIKE: I had a 2003 Prius that just two years ago I sold to a neighbor, and they still got it running [laughs]. And, you know, they knew a guy who would go and rebuild the battery. The battery was going after 18 years. But they found somebody who rebuilt the battery, and they still got it going strong, like the car [inaudible 21:23]

WILL: Yeah, it can be done. It can be done. Like, I was watching on YouTube. There's a guy who will rebuild a battery. And, basically, you just go through. You just test the cells, which can be done relatively simply, you know. So, you just pull the thing out, you know, strip it down, test the cells, replace the bad ones, and back in business.

THOMAS: Yeah, I have a Subaru BRZ, and it's at, like, about 65,000 miles. And I was going through, like, the idea of, oh, like, you know, it's kind of expensive. I want to sell it, you know, get something a little bit more versatile, you know, an SUV or something.

But then I was also kind of thinking, I was like, this thing only has 60,000 miles on it, you know, and it's like, really good condition. It's a 2015 model, and 60K, you know, I was like, that was really difficult for me to find in the first place. And I'm like, to sell this, I feel like, would be a shame because I could get years out of this thing, you know. Like, the Japanese cars, and, like, Subarus and all, they go, like, yeah, 300,000 miles. I'm like, this could be almost a lifetime car I have here so... [laughs].

WILL: Yeah, I don't know. I mean, like, I feel like a lot of those electric cars...it's a shame that Justin's left. But, I mean, I feel like, like, mechanically, they're dead simple, right? And so, it's just, like, the wear and tear on the battery. But those batteries go longer than you think.

MIKE: They go a long time. And it's not like they usually fail catastrophically. They usually just gradually, you know, lose a percent or two each year, or whatever it is, you know. And so, even if you lost half the battery, you know, over time, it's still perfect. It's just like your phone, right? Like, oh yeah, well, I have to charge it more often, but it works [laughs]. And you keep it going for a long time.

To bring that back to, you know, to software, all of us are maintaining legacy systems. Once it's built, it's not new anymore, right? It's only new once. And, you know, we keep those things going. And there are systems out there that have been in use for 50 years. I'm not working on one of those currently, but they exist, right? Like, usually big systems that'll just be so expensive to rebuild. Big banking or air flight and stuff, you know, they're written in COBOL, or [chuckles] something that was popular however long ago, and people just keep them going. And if you look at the same logic that you're talking about, Thomas, you look at the return on investment, yeah, it costs you money to keep it going, but it's less than it'd be to replace it.

WILL: How many miles do you drive in a day, really? You know, just, like, oh man, the range is only 80 miles. And I'm like, that's, you know what I mean, that's 30 days out of my month. And then I'm just saying, like, I might have a hundred-mile day, like, you know, every so often but not all that often. I also don't like to drive, you know, so that's just whatever.

MIKE: [laughs] So, Will, you haven't brought up any software adjacent things that you work on. I've got some, but I'm curious. Or, if you want me to go first, I'll go first.

WILL: Well, I mean, I'm going to blow it up, right, like usual, because I'm going to refer to the granddaddy of them all, and I'm not going to explain why because I have no idea why but, like, music. Music, for whatever reason, like, if there is a thing, if there's a thing that correlates with software people, like, if I had to pick anything, like, it could be PCB layout...no, music. I don't know why. I have no idea. Doesn't make any sense at all.

But every software, you know, shop is absolutely rotten, just completely full to the brim with musicians, and I have no idea what that is about. It doesn't make any sense. There's no logical chaining that can get you from here to there. It's like, "Oh, I'm really interested in the violin, and I have a musical performance major." "What do you do right now?" "Software engineer," you know [laughter].

You don't just walk into Mordor, and you don't just trot yourself into, like, a technical field that's, like, a very high-paying job from a completely unrelated area of study, a completely unrelated, high-demand area of study, and you're just like, oh, and I'll just do software, you know. Oh, okay. How many do we have? How many do we have, Mike? I know you're thinking in names right now [laughs].

MIKE: Yeah, well, Justin, who was on the call, he said before that he's on, like, a touring amateur choir. I don't know much more than that. So, like, he does it almost semi-professionally. I was actually...when I come up, I'm going to talk about music, too [laughs], not quite as directly as you. But, no, like, there's enough space between that I'm curious about that, or, you know, that I think that we've got plenty of room to go in different directions there.

Yeah, absolutely. I'm thinking of a well-trained pianist who works on our DevOps team [chuckles], Kyle's nodding, who's, you know, exceptional. We had a delivery manager who...he actually recently left, but he's looking into moving just doing professional music [chuckles]. It's all over the place, just a few of them right off the top of my head. If you're not going to go any further with that right now, Will, then I'm going to take that as a segue, and then we can go kind of go back around.

WILL: No, just go right ahead, yeah.

MIKE: Yeah, so --

WILL: No, like, it's just weird.

MIKE: Yeah, no. Has anybody here read A Mathematician's Lament essay by Paul Lockhart? I looked it back up in preparation here. I think it was published over 20 years ago. I'm recommending it. There's an essay version; I guess he made it into a book. I have not read the book. I've read the essay, but the essay has made me think differently ever since. I probably read it 15 years ago originally, and I think about it regularly.

It's by a professional mathematician. He was a mathematician at university, went on to teach math, I think, at, like, pre-college school, you know, some context other than his university career. So, longstanding educator, and he suggests this idea. He said, "Can you imagine if, when we taught music, we started by just having people learn to read notes?" Not to listen to it, but just say, okay, that's an A; that's a B. This is a quarter note; that's a 16th note. And then after a few years, maybe you could start listening to it, but that's advanced. You have to make sure you learn how to read it first because if you can't read the music, then there's no way you can appreciate music.

And, you know, he takes that absurd argument to its extreme, and then talks about how we teach mathematics as a discipline of rote memorization, completely divorced from practical application many times. Or, like, you know, you just got story problems, and think like, oh, that's the annoying part I have to do [laughs] that's really hard before my test. And then we can go back to memorizing again because that's the easy part, you know.

And I'm actually going to take his idea a little bit further. I think that we already do kind of badly in teaching music because, particularly in classical music, you know, they teach people to read music, but they don't teach people to write music nearly to the degree that the reading of music is taught. I'm not saying that reading music is a bad thing, but I think it's hugely problematic that we're taking...

So, I'm going to say, what's more natural than making noise? We do it from birth, and we express ourselves. We use pitch. We use the timbre, you know, we use dissonance to express ourselves. We're natural musicians from birth. But as adults, most of us hesitate because it's presented as something separate from us. You know, music that's something that professionals do. I'm not a musician. And we make this weird separation because we have to learn all the mechanics of it. And I find that hugely problematic [chuckles]. I strongly think that people should be making music early. That's music, specifically.

I've done a lot of teaching [chuckles] outside of work; music, I've taught math; I've taught English. I'm going to mostly focus on math because I've done a lot of that. That's probably what I spent most of my time. Some context, I spend a lot of time teaching my own kids math. I've done summer programs where I did, like, video conferencing and taught kids math. I've done it for years, and I enjoy it. It's something I always wanted to do, and I'm glad that I've had a chance to do it. And I've seen it make a difference in people's lives.

My oldest child graduated with his first mathematics degree. He's going to pursue more at age 20. A couple of other kids I taught during the summer, I think, were valedictorians of their high schools, and have gone on into technical fields. So, I think I have seen people be very successful at this.

And math is the art of problem solving. It's typically, not always, but typically focused on problems that can be solved numerically. But what's more natural and human than solving problems? That's what we do, in many cases. But in mathematics teaching, we focus so much on algorithms, on rules, instead of creativity, and teaching tactics as tools to help solve interesting problems.

And then problem solving, it loses its joy, and it also loses utility because if it's completely divorced from the practical application, like learning to read notes without hearing music, you know, there's no creativity there. There's no meaning to it. And many people grow up without having, you know, having learned some things in math that they'd never apply in life whatsoever because there is no connection to the problem solving.

Going back to software, I think that there's tremendous overlap there between people who, you know, go and try to learn something because, oh yeah, this will pay my bills, and people who discover that joy of problem solving and are hooked and just want to keep doing it because it's a joyful activity. And most of the best software engineers out there, they like it, you know [laughs]. We get hooked on it, and we can't help but want to solve those problems. And if we can cultivate that joy, I think that's a big deal.

So, talking about math, you know, and writing has a lot of correlation, too. I think...Was it you, Will, who talked about taking technical writing and that being an amazing thing that you received? I don't remember if it was you or not. I remember somebody mentioning it. I think, once, you know, writing, I'm going to argue that a lot of writing, most of writing, is understanding [chuckles]. Once you understand the topic, you can tell a story with structure about that topic. You can forge a coherent narrative and bring the reader along. That's not so far from understanding a problem, writing procedures and algorithms to solve that problem. There's my take of software adjacent things. I can talk about teaching. Any thoughts on that?

THOMAS: Yeah, actually, one thing, I really like that you tie it to mathematics. Recently, I came across a video of someone talking about how they were a computer science major, and they were talking about, "Why do I have to understand and learn all these math, you know, languages and everything, and learn so much about mathematics?"

And it, like, put me into a very deep thought mode where I was thinking, it makes total sense from what I've kind of experienced in terms of just query languages. It all looks like math, right? Like, the format of it is exactly like math, to me, where seeing how things are broken apart, seeing how things connect to each other, joined to each other, and everything, is almost identical to how I interpreted math, you know.

And it makes total sense, like, understanding why calculus and physics are so important to understand, you know, especially when you kind of get into, like, engine design and everything. It's literally just the universal language, you know. And they say that math is the universal language, and it makes just total sense because it's applicable to almost everything in life. Even if you're not using that particular subject of math, you are still using the format that it has everywhere. I mean, it's super unique, because when you think of everything a human's been able to explain, or describe, or theorize, it's done through the format of math. You look at genetics, you look at software engineering, you look at, you know, astrophysics, it is all done through the idea of math, and the format sequencing it's very interesting.

And so, that was a really unique kind of revelation that I was thinking of, and I was glad you brought that up, Mike, because being able to identify that and seeing how math incorporates in everything is truly magnificent. It's honestly very beautiful. You know, it's a language in itself. And learning all the different factors of math is like learning dialects of another language. It's really pretty.

MIKE: Well, it's a language for describing the universe around us. And it turns out that there are patterns in the universe around us, and so having an unambiguous language that is designed around problem-solving can accomplish crazy things. It's the foundation for pretty much all of our modern technology.

KYLE: Interesting that it's being related back to language like that because, of course, in programming, everything's a different language, right? You're proficient in one or two or three. I always go back to one of the best engineers I've ever been around. He had nothing to do with engineering. He was a dual English and Spanish lit major, and he got into programming. And I was talking to him one day about what his favorite language was, and, you know, how he picked up C++ at the time, how he was picking that up so easy. And, to him, it's just another language. All these things are just another language. And it kind of does seem that way.

And there's two boats. But I do see a lot...either you go really deep into a language, or you start learning a lot of languages, right, in programming. And it's just that same thing, like, why would we like music? Well, music's another language. Mathematics, like you're saying, it's another language. All these things are just other languages that we're fascinated by to solve either an interest or a problem that we're running into.

They all have different end goals, right? Otherwise, everybody would use Java, right? If we weren't opinionated [laughter], we would all just use Java or something of the like, right? But we're opinionated. So, we've got Ruby. We've got Python. We've got all these different languages to solve whatever situation that we're wanting to solve, in that category of whatever we're dealing with.

WILL: And you can pick any language you want, as long as it's JavaScript.

KYLE: As long as it's JavaScript, yeah [laughter]. You're talking [inaudible 37:21], especially.

MIKE: I thought you meant TypeScript, Will. I thought you meant TypeScript [laughs].

WILL: It's all JavaScript. It's all JavaScript in the end, man.

MIKE: That's true [laughs].

WILL: It's all JavaScript all the way down.

MIKE: I don't remember the exact story, but JavaScript was thrown together quickly in, like, what, a weekend or something [laughs], initially, and has ended up taking over the world.

KYLE: And it goes back to your analogy, right? I mean, not analogy, but what you brought up. What was it for? It was a teaching tool and then became a language [laughs].

WILL: JavaScript?

KYLE: Yeah.

WILL: No, no, no. It was just, like, a weekend project in the battle days when somebody was just like, "We need a scripting language for these websites, right, so they can do things, so they can, you know, manipulate the DOM and stuff like that." And some guy just, like, blazed it out.

KYLE: Oh, I thought, for some reason, I thought in my mind it was for teaching.

MIKE: Python...you may be thinking about Python.

KYLE: Oh okay.

MIKE: Python absolutely was created to look like pseudocode. It was designed to look like somebody was just writing out their thoughts on the board. They're like, "Can I have a language that looks like that?" And they created Python.

KYLE: [inaudible 38:33]

MIKE: Yeah. So, that absolutely was kind of the origination of Python. And, of course, if you're learning it in school, you might want to use it. And all those people learning in school started doing it, and now it's the language of AI, and even more popular than JavaScript, although mostly in certain domains, right? JavaScript is [inaudible 38:57] for development.

WILL: JavaScript is...sadly, that's the end. It's like everything is crab. Everything is JavaScript. Evolution's the perfect animal [laughter].

MIKE: The crab story is fascinating, but I'm not going to dig in [laughs].

Well, we've covered, you know, we've gone around, and we've made some connections. And that's really what I wanted to accomplish today is talk about some things outside of our normal work and connect them and show, you know, these do have overlap.

Andrew Ng is a popular educator and technologist who has been involved in Google Brain, I think, in the past. You know, he's been involved in a number of prominent tech things. He often encourages people who are not in software to be, like, be the doctor who can write code, you know, or be the...you name your field. Be the textile, you know, somebody who sews things together, who understands code. And he says that will drive your career. And I think that there's a lot of truth to that.

But I think that we don't always think about the flip side. You shouldn't just be a software engineer because these other things will enrich your life and actually push your software career further. You'll find some of these emergent properties from learning this other thing that have correlation, that will improve what you do.

I think it's a dangerous thing to do only one thing, and you get better by doing more than one. Learning a new programming language expands your mind, especially if you're using a very different paradigm. Go and learn Haskell. You'll never use it, but you'll think differently [laughs] or Lisp, or, you know, whatever the language might be, something that forces you to think differently. Have those hobbies. It's worth it.

WILL: There's never been a cooler time to get into, like, sort of, like, hardware touch stuff, you know, like, because there's a lot of, like, incredible, like, very hobbyist-friendly devices and stuff like that. And the LLMs that exist right now are very, very effective at explaining and facilitating, like, you know, dealing with very low-level instruction and code and stuff like that. None of which is particularly complicated, but all of which is user-unfriendly to the point of outright hostility. 

MIKE: [laughs]

WILL: Because we don't have the RAM for all that, you know what I mean, like [laughs], I'm slinging bits on memory-mapped I/O buses. But you could do that stuff now. You don't have to, like, you know, you don't have to go through the stations to cross, to, like, read these buses, and then you could make, like, just cool, nifty stuff. Sorry, tangent. I think you were trying to play us out, Mike [laughs].

MIKE: But it's exactly right. There are cool things that we can do. You want to go put on a drone show with some art? You know, knock yourself out. And those skills are going to overlap amazingly. And it's worth it. I think it's worth it.

WILL: I'd say one thing that I can't encourage people enough is actually going out and making something that you want, right? I mean, so much of our jobs as professionals is shaving basis points off the efficiency of these mega, super, giant pipelines. You know, everything I worked on today is going to generate millions for the bottom line of the mega corp that I am currently servicing. And it was the stupidest thing that you could possibly imagine. Like, no one would go to school if they knew this is what was waiting for them off the end of the assembly line.

MIKE: [laughs]

WILL: It's very necessary that I do this stupidity, and I'm going to make so much money for so many shareholders. I generated so much shareholder value today. But you could take these skills, like, you can make things just for you. You could just make stuff. You could make a whole thing and hold it in your hands, and it does whatever you want. It's incredible. Anyway, finding the joy of creation, you know, in your work is, I think, drastically underrated.

MIKE: Amen. And with that, I think it's a perfect close. Until next time on the Acima Development Podcast.