How to Learn

About this Episode

In this episode of the Acima Developer Podcast, Dave Brady, along with panelists Eddy, Kyle, Ramses, and Will, discuss the various ways people learn, sharing personal anecdotes and insights. Dave kicks off with a humorous story about learning to swim by being thrown into a lake, which sparks a broader conversation about how some people thrive when thrown into challenging situations, while others prefer a more structured approach. Will identifies with the former, explaining how he learns by setting impossible goals and pushing himself to figure things out, often attributing his approach to an undiagnosed ADHD coping mechanism. Eddy contrasts this with his preference for having safety nets in place when learning, underscoring the diversity in learning styles.

The discussion also touches on the importance of incremental learning, with Will emphasizing the strategy of "debugging from the known to the unknown." He shares advice from his engineer father, explaining how building knowledge step by step can help navigate new problems. They also dive into how experience in multiple programming languages helps make learning new ones easier, but caution against assuming that all programming languages follow the same rules or paradigms. The group explores how learning through experimentation, much like playing music, can lead to deeper understanding, yet each new tool or language requires its own dedicated study.

The conversation wraps up with a reflection on the importance of continuing education for software developers. Will argues that the industry often neglects training, which leads to burnout and inefficiency, as engineers are left to constantly catch up on their own time. Dave adds that knowledge is crucial to a developer's career longevity, stressing the need for ongoing learning even if employers don't invest in it. The episode highlights the parallels between music, programming, and learning in general, emphasizing the importance of both structured and self-driven approaches.

Transcript:

DAVE: Hello and welcome to the Acima Developer Podcast. I'm your host, Dave Brady. Today, we've got Eddy, and Kyle, and Ramses, and Will. We've got a really great panel today. We're talking about learning. And Mike usually likes to start with a story, and I don't have a good...I've got too many stories about learning, and I don't want this to be the David Brady talks about his life story again show.

I’ll just start with one of the stories from my childhood, which is that a lot of times, I learned the hard way. My dad taught me to swim by throwing me in the lake. And the hard part wasn't learning how to dog paddle. The hard part was getting the knot untied from inside the sack.

WILL: [laughs]

DAVE: So --

EDDY: The joke is that you were destined to fail because you weren't given the proper...gotcha.

DAVE: Yeah. Except, a lot of times...for the people listening at home, about 30 seconds before we started this call, I told Eddy that he should host, and he said, “No, no, no, no.” And I was like; I'm this close to just making him do it because the best way somebody [inaudible 01:07] that they can swim is just throw him in the lake. And it feels like you're tied up in a sack because you don't feel like you're maximally competent. You are minimally competent. That's what beginning is. And so, yeah, all right, so we took the joke. We overexplained it, and then we turned it into a metaphor. Why not?

EDDY: I will say, David, it's funny because I've met some people in my life who learn best by being thrown in a bag and tied in a knot, and some of them prefer that. They like to just be tossed in the deep and figure it out, you know? I know that there's very little people in the world that learn that way, but I do know that there's a lot of people who actually excel being in a [inaudible 01:46].

DAVE: And, for those people, skydiving and working with cobras is probably not a good career.

EDDY: Will, I saw you raise your hand. Are you one of those people?

WILL: [laughs] It's me. Like, I am that person. Like, I have tried, like, so many times in my life, you know, so many times in my life, to be like, you don't have to do it that way, do you? Not that way. Not again. Again? But how I learn is I get myself in over my head. I assign myself crazy goals, impossible deadlines, crazy projects. I have no idea what I'm doing, and I don't know; I’ve figured it out. I pull it off [laughs].

EDDY: Is it because you want to tear things open? Like, if they assign you something and they're like, “Hey, Will, get this done,” you prefer to be proactive and undig and, you know, be...

WILL: I think it's, I mean, as I learn more about sort of mental health and, you know, work styles and stuff like that, I think it's just a...I think it's an undiagnosed ADHD coping mechanism that that's the root of it. But, man, I don't know, I mean, like, I think there's a certain level of, like, if I may pat myself on the back a little bit, the breadth of things that I've done pretty successfully over the course of my career is significant.

And I don't know a lot of people that have covered as much ground, and I don't know...it's hard to summon up the requisite psychic energy to really push yourself in a completely non-toxic fashion. Jet fuel is deadly poison, but it'll...you put a big enough pile of it under your butt and set the fuse, and you're going somewhere, you know [laughs]?

DAVE: There's a YouTube guitarist named Rhett Shull, and his slogan is, there is no plan B. Like, he will actively destroy plan B. If he wants Plan A to work, he cannot have a Plan B in his pocket, or he'll fall back on it every time. And so, that's literally his channel slogan is, remember, there is no Plan B.

EDDY: I will say I learn way different than you, Will. Like, if you throw me in the deep end and I don't know how to swim, I expect to have a lifesaver somewhere, like a jacket, or floaties, or whatever. It's like, cool, yeah, like, I'll put you in there, but you at least have a safe haven where you can fall back on in case you can't figure out how to swim. That's my personality. However, if you don't give me floaties and you don't give me a life jacket or a vest or anything, I can at least learn how to float [laughs], you know, stay afloat, you know, like, I won't drown entirely. It's just not the ideal spot you want to be in.

WILL: I mean, it's not like I won't ask for help. It's not like I won't ask for clarification or anything like that. I just, I don't know; I mean, that's just how I do it. I need a certain amount of fire under my butt to do my best work.

EDDY: That brings up a really interesting point, though. Like, what are some of those techniques that you do then? If you get put in that situation to learn, what are some of the things that you gravitate to that sort of help you?

WILL: When I'm in it? Yeah, it's one of the best pieces of advice I ever got was from my dad, a capital E engineer, and he always said, “Debug from the known to the unknown,” right? And so, what you always want to do is you want to sort of expand what you're doing, expand your knowledge from a functional state, from a working state, and it doesn't matter how petty, and trivial, and stupid. So, if I was like, let's say I'm going to do a brand-new thing, right? I'm going to write a thing in a brand-new language, right?

Like, I've said this on this podcast multiple times, and you haven't heard the last of it after I get this one out, is start as small as you need to get a functional kernel, a nucleus of something that you can do and then expand from there, which is the easy thing to say, but it's a hard thing to do because the space of a new problem, a new technique, a new territory is big. You don't even know where the edge of the map is. You don't know where you are.

And so, you need to collapse down to something functional and then sort of build out from there. And that's, you know, that's the best way that I know to do it. And when you approach it like that, I mean, it really can be a very simple mechanical kind of a thing.

EDDY: I like that.

WILL: I was actually listening to a podcast. It’s the Andrew Huberman Podcast. He was talking about, like, literally, like, a process of learning, right? If I could paraphrase, like, a podcast that I only finished half of, the learning technique, the science that he was sort of describing was saying...he’s like, the key to learning is not so much learning; it's preventing the natural process of forgetting. Your brain is ---

DAVE: Neural pruning.

WILL: Well, your brain's taking in information all the time, right? You're constantly bombarded, flooded with data, and most of it gets thrown out because it's not useful. Your brain is actually really efficient at flushing that cache out. And so, what you want to do is try as hard as you can to establish it, and you build those hooks, tie it in with other things that you already know.

Like, I've gotten really good at picking up languages because I've picked up a lot of languages. And it's just like, you know, somebody who learns seven languages, the eighth one will be easy. Well, if you know seven programming languages, then the eighth one isn't going to be so bad. And so, we're getting new techniques. We’re sort of attaching techniques onto things that you already know how to do.

If you wanted to write...let's say you didn't know Java, but you knew Ruby pretty well, running a web server in Java, you would have a theoretical construct, a matrix to think about things. It's like, oh, well, I know about, you know, routes in Rails. You know, does my Apache Server have routes the same way? It sure does. Or, I mean, Apache is not the right one, but anyway, I forget, Spring Boot server. And so, you can connect things. So, it's like, oh, Ruby has an array. Java's got an array. It's got a vector, right?

So, I mean, like, okay, so we've got this and this. Do we both have a hash? Okay, we both have hashes, right? So, we have maps going back and forth each way. And then, hey, you're actually going, right? Like, the wheels are turning. Things are moving for you. And there's not that many new ideas under the sun. You know, like, once you've gotten your hands deep into something, picking up the next thing's not so bad, you know?

DAVE: You sparked a turning thing to what you just said, which is really interesting. I ran into an interesting thing where I started in Visual Basic, and then I moved into C++, and then into C, and then Assembly. I moved backwards, like, down the tech tree, down to where I was like...literally to the point where I was soldering transistors on a board, and then came back up to a high level and very high-level languages. And as I was coming...like, I got a job moving from PHP into Java, and I'd done C++ and da da da da. And I was just like, just tell me where the braces and semicolons go. All languages are the same.

And I was talking with a grizzled, old hacker, and he said, “Go learn Lisp.” And I'm like, okay, whatever. And I really struggled with it, and I couldn't figure out why. And, honestly, I bounced. I went and looked at Scheme, and I went, okay, yeah, this is like really, really tight versions of, you know, semicolons and whatnot, but okay, fine.

It wasn't until I tried to learn Elixir, which is Ruby on the Erlang BEAM, right? On the Erlang virtual machine, and I struggled and struggled and struggled. And this language just kicked my butt, like, nothing would work. And, finally, somebody sat down and said, “You're thinking bols,” B-O-L-S, block-oriented, lexically scoped languages. C++, Java, Python, Perl, PHP, all of these are block-oriented lexically scoped languages, and Lisp isn't, Closure, Scheme aren't. I mean, those are all Lisps. Erlang and Elixir aren't, Smalltalk as well. They live in completely different paradigms, and block-oriented lexically scoped does not translate.

So, when people say, “What language should I learn?” I'll tell 'em, “You know, go learn...” You know, actually, JavaScript is the perfect example of this because JavaScript is not a block-oriented lexically scoped languages. It looks like people look at it, and they think, oh, this is Java, or this is, you know, C++. It’s not. It’s not even an object-oriented language. It's a prototype-based language, and it will behave like an OO language for, like, 98%. And then, you get this weird bug. Where the heck is this coming from? Well, it's because there's not actually any inheritance in this language. You're just layering a prototype. And there's a key point where the language goes into [inaudible 10:51].

So, knowing...I 100% agree that seven languages makes the 8th language easy, but you have to be careful when you step into that 8th language to go, is this going to be easy because I know 95% of it, or is this going to be easy because there are some huge differences in [inaudible 11:10]? And follow them very, very carefully. With Smalltalk, it's like, send a message to an object. You don't, you know, don't try to...it's rigidly OO. And if you try to write imperatively like you can in C, it will kick your butt. And it's fantastic [crosstalk 11:23]

EDDY: I will [inaudible 11:23], Dave, because you mentioned something that I think is actually kind of interesting. You said that there was a hindrance because you already had prior knowledge to a language or different languages, and it was a whole different dichotomy. So, do you think that had you gone in without any prior knowledge to any language and had to learn, would it have been easier for you to pick up? Because then you weren't translating any bad habits that didn’t --

DAVE: Let me qualify the term easy because I bounced off of Lisp so hard. I would categorize my first two years of Lisp as failing completely, utterly completely, because I was trying to make the language act like Perl, Ruby, Python, Java, C++. And because I refused to see the languages behaving differently than...I mean, I’d come from Assembly language. Everything was ones and zeros. So, obviously, I know how it's going to act at the high level, right? I didn't. I had no concept of this. And it's because I refused...and this will be a thing that we'll probably touch on a lot, but the map is not the terrain.

Sometimes, there's a difference between the map and the terrain. And you can watch people get locked up when the map and the terrain don't match, and they will hammer that terrain until it matches the fricking map. Or they will just circle that part of the map and say, “Here be dragons; don't go there.” And, no, just update the map. That's all you need to do.

And so, random 10-second one-sentence thing. The best parenting advice I ever heard was, take the time to get to know your kid because your kid is a different person than you are. And the idea of treating a child...like, I grew up in a generation where children were meant to be seen and not heard. Children were meant to be input only. You're not a transmit. We don't want to hear anything out of you. Taking the time to actually interact with another human being validates them and turns them into a very different person than...right?

I realize that's a really weird analogy, but it's the same architectural pattern. Listening to something that you think you can just transmit nonstop, to learning that you can listen to that is a huge power-up. Sometimes, pay attention to the terrain rather than the map. Did that make sense? Did any of that make sense?

EDDY: [laughs] I like the analogy where you said all your kids are different, right? And you can't treat them the same. And then, you can probably force them to act a way, but then it's not going to be as fluid. It's not as natural because that's not the way the kid is designed.

WILL: Well, let me ask you this, though, because I think you'll probably agree with me, but we'll see. I still think you would pick it up faster, even, like, having some sort of, like, you know, a little bit of blocks, right? Like, mental blocks around stuff.

DAVE: Yes. Oh, 100%.

WILL: I still think you got there faster than if you started from zero.

DAVE: Yes. Oh, yeah, yeah, because once I figured out that I was bouncing off this language, once I realized, oh, it's the map, and the terrain don't match, I was able to go, oh, and then, all of a sudden, that 95% match was able to apply again. And, yeah, and then other things, like, one of the best things I heard in the twenty-teens was, if you want to be really good at Ruby, go learn Lisp because it will make you a better Ruby programmer. And I've meditated on that a lot, right? It's like, why would you learn this archaic language that nobody uses? Because it'll make you a better programmer.

Because there are things that you will learn that we don't ever use over here, unless you've come from Lisp, if that makes any sense at all. It's kind of like taking a data structures class, you know, or an algorithms class. The first time you learn about Big O Notation, and, all of a sudden, you realize why that database query is taking so long. You don't cover databases in the Big O Notation class, right? You usually are covering algorithms and processing time. And then, all of a sudden, everything around you, like, people lining up at the DMV, you realize this is a Big O Notation problem. And being able to apply the structures to it, yeah, hugely, hugely beneficial.

EDDY: Dave, actually, the reason to my previous question was because I wanted to lead to eventually that final hypothesis, where it's like, yeah, even though a language that you are avid in is completely different on the way it behaves than a new language, you have still trained your brain, you know, to be proactive and resourceful and think like a programmer, to think like a computer, right? And that sort of thing is kind of hard to learn if it's your first time, right?

WILL: I have a only mildly unfair amount of skepticism around programmers that really only know one language well, you know? Like, if you're like, “I'm a Java guy.” I'm like, “Well, do you know, like, Ruby or Python?” “Nah, nah.” “Do you know JavaScript?” “Nah.” “Lisp?” “Nah. Nah, I just do Java or Kotlin, you know, both of them.” And I’m just like, you know, you're not necessarily dumb, but, you know, it's like you open up a toolbox, and it's just hammers, you know what I mean?

DAVE: Yeah. There's two types of seniors that I've seen to do that. First of all, a junior who only knows one language, I'm kind of okay with that, right?

WILL: Yeah, it’s fine.

DAVE: And if you've spent five years without learning another language, that's when I'm going to tap you on the shoulder and say, “You need to go learn another language. You need to get out. You're starting to rut in, right?

But I've seen a programmer with 30 years under his belt who was just C, not even C++, just C. And he was really, really, really good at programming firmware. Like, this man knew his hardware inside and out. So, he was basically using this language to do his career. His career was not programming, if that makes sense.

This guy, man, he knew graphics cards, and he knew things about like, “Oh, yeah, the 3D chip is probably going to be in a bad mood when the bit blit comes in off the 2D pipe.” And you're like, “How do you know? Like, they don't have moods.” And he’s like, “If I tell you it's a mood, it's easier than spending a week with you explaining the histories to states on da da da da.” You’re like, “How do you know this?” “Just keep doing the same thing for 30 years.”

But, for him, it was a career, and it was a tool. And if you are a programmer, first and foremost, especially if you're in the tech economy where you're changing jobs every two years, you better be fluent in seven languages because that is your career.

EDDY: So, Dave, let me ask you this then. If someone is saying, “Hey, I'm a senior developer,” what is a fair rule of thumb for that person as far as how much diverse they are in other languages and how fluent they are? Like, what would you think is a proper and fair expectation for someone who considers a senior?

DAVE: I am going to give you an answer that's going to sound like a mystic senior kind of answer, which is no.

WILL: [laughs]

DAVE: When I interview somebody for a programming job, I don't want to know how many languages. It's good to know. If you tell me you know 17 languages, or you know seven languages and you know 3 of them really, really well, that gives me a one-sentence idea of the shape of your mind and your career. If you've gone 15 years and you've only learned one language, that tells me something about who you are.

When I interview a senior developer, I don't care. I expect you to be fluent in some languages, but I don't need you to be fluent in Ruby. I don't even necessarily need...and if you're a junior, I don't even need you to be fluent as...I'm saying this badly. If you come work for me, I need to know if you can think; that's what I'm trying to say. I want to know if you can think. I cannot teach you to think.

But if you've been doing this job for 15 years and you've only learned one language and you don't have a really good reason for only learning one language, you've just told me how you think, which is kind of crusty and, you know, resistant to learning. And for my personality and the way I like to work, that's going to be a problem. For other people, that might be great, I don't know. So, I use language fluency and capacity and facility with language as a proxy for your ability to think and learn over time.

WILL: You know, I don't think I've ever asked or particularly cared about someone's language background. I think it's never really come up for me, past, like, you know what I mean, like, if I have a specific job, I need to know that you could do, you know, that specific job with some facility. But, I mean, generally speaking, I'll talk. I'll ask about projects you've done and things you've done. And, honestly, if you have a sort of a diversity of like, oh, I worked on this for a while, and then they need some help over here, so I did that, and then, they need some over here, so I did that, and I just picked up this thing, then it's almost a natural kind of thing.

And so, if you have kind of, like, a diversity of like, oh, I've worked in a couple of different jobs, a couple of different projects, a couple of different teams, you know, then you'll just get it. I mean, it'll just...you would have to be working pretty hard not to do it. Like, the only way I think you could really reasonably work on a good diversity of projects and not pick up just various languages would be if you were working maybe a long term, like, a long-term employee of a company that was fairly rigid in terms of, like, how they do things, you know.

Like, I could see somebody being good, who's doing good work and taking on diversity of work and is, like, thinking, well, you know, but they just happen to be in this environment. Although I will not lie to you, like, it would factor into my evaluation in that I would need to make a judgment call as to whether this person could, you know, spread their wings and fly outside of this, you know, particular corporate ecosystem.

DAVE: Yeah. And if somebody's had...if they've been in five different places over the last eight years and we ask them, you know, “So, tell me about this...” and you very quickly you start to...they all like, “Well, at this place, the team worked on this, and at this place...” and you start realizing it sounds like you were in the backseat there, and okay, so you're a backseat person who waits for things to happen around you.

And then, you get other people that are just like, “Oh, I did here. Man, we did this, and we went over here, and we did this.” And even if they didn't sound like they were in the front seat, you can tell that they're leaning forward. They're like, I want to know what's coming down the pipe next, and I want to engage. That's a pretty interesting...we've been talking about learning, but we've now kind of diverted into, like, how do you measure somebody's personality? But you get a feel for this. And, honestly, I think your willingness to learn...I'm worried that this is going to –-

WILL: [laughs]

DAVE: Please, please don't let this turn into a political thing. I'm going to say this.

WILL: Uh-oh.

DAVE: I used to operate off of the old-school definitions of conservatives and liberals. Old school conservative is somebody who does not like progress because there are good things in the existing system. And they understand that if you change something, we might lose some of the good things.

Old-school liberals are people who say there are flaws in the existing system, and if we don't change something, we'll never get to the even better things. So, that's the old school of this, whether you're averse to loss or whether you're averse to failure to grow, and they're both really valid, and they do well in this.

And I think a lot of learning falls into that, right? The jump in, get thrown into the lake, you know, light a fire under your butt. That's a very kind of, I mean, lowercase l. These are not political terms. These are attitudinal terms, right? Lowercase l. Progressive-minded people are going to want to just jump in and flail and get to it.

But if you're programming pacemakers, we want somebody that's a little bit conservative-minded. If you're doing SecOps or, you know, other security stuff or stuff where failure can be catastrophic...I don't know if I've told this story here. I've told this story on Ruby Rogues a bunch of times. I once got a bug report that started with the sentence, “Fortunately, no one was killed, but... And that will stop the conversation in a room, right?

We had things that could shake big, heavy things. Toyota was using it to shake cars to try and rattle the welds to see where the resonances were to find out if the car was going to rattle apart on the road. And we had a bug, and we punched one of the thrusters maximum, from zero to maximum instantly. And we launched a Camry across their fab. And everyone wore their brown pants that day. Yeah, so when you send the frame of a car, it’s scary.

EDDY: I will say that you got my attention immediately when you started your sentence [laughs] [inaudible 24:04].

DAVE: Yeah, yeah, fortunately, no one was killed.

EDDY: [laughs]

DAVE: But, yeah, yeah, that's...right? So, if you're programming a pacemaker, that's an issue. My neighbor just bought a Tesla, and I am boggled by the fact that the cars that don't have the auto drive still have all of the servos and linkages and stuff like this, to, you know...And oh, it’s so that you can purchase this upgrade, you know, right from the dash of your car. And I'm like, yeah, but they put 20,000 worth of servos in the motors that if there was an SE Model that never was going to have auto drive, they could have saved half the price on manufacturing the vehicle. Why would you do that? And he said something that scared me. He says, “I'm not actually certain there's a linkage mechanically from the steering wheel to the steering column,” And I’m like --

WILL: There isn’t.

DAVE: What happens if the computer crashes on the road? Like, safety engineering is like, if you brick this car at 70 miles an hour, you have to be able to get stopped without dying. And I'm sure the smarter people than me have an answer for this that there's probably some way that the car will keep you from, you know, dying in a fireball, but you have to think of that. Pacemakers have the same problem.

WILL: Listen, I don't want to take the podcast for a turn, but all I will say is Tesla has a different risk management envelope than the large automakers. And if you want to see the level of operational risk that they're comfortable with, you could type in “Autopilot fails” in YouTube.

DAVE: [chuckles]

WILL: And you're going to see some things that Toyota would not ship, and that is a decision that they make for themselves and also me, who is driving next to them with my children.

DAVE: Yeah. And there's some issues with that, yeah. It's like when the Ford Pinto...just Google, “Ford Pinto class action lawsuit,” or whatever it was, $4 part. They had a memo. Somebody said, “We can save 10 million by not upgrading this part with a recall. We'll just pay out the class action suits because if they get rear-ended, they will burst into flames, and people will burn to death. But we'll just pay. We'll just settle them.” They figured it would be cheaper. And that's a poor...I would have rather had a conservative or a pessimist, there we go, optimist pessimist that's probably a better word than liberal conservative.

So, we get somebody who is risk-loss averse because there's times when you want that, right? Marty Seligman's book, “Authentic Happiness,” he talks about there's times when you want a pessimist because a pilot who is an optimist will try to take off when the wings might be still icy. A pessimist will stop. Your plane is going to be late. Everyone's going to be...it's going to cost all kinds of extra operational costs, but they won't crash and burn and kill everyone aboard. And that's kind of a feature that we actually kind of want. So, sometimes you want a pessimist in those places. If you're programming pacemakers, you want somebody who's like, okay, number one, we have to not kill you, and then anything we do has to build on that. We can't violate that constraint.

EDDY: Gotcha. And that's how we learn, right, Dave [laughs]?

DAVE: Well, okay, so, how does this apply to learning? The optimist learns by getting thrown in the lake, and, you know, as long as they're not tied up in a sack, then they're going to learn to swim. Music. Pick up a guitar and just start banging on it. Find the music that's within you. That's a fantastic, optimistic way to do it.

I was, as a kid, trained by a conservative/pessimist who basically said, “That's not the way Bach wrote it, and you must [vocalization]. You must do it exactly.” And they sucked all the joy out of music. But anybody who's going to go to Carnegie Hall needs that teacher because somebody who learns optimistically they might be the most soulful blues player in the world, but they're never going to have the articulation and the perfectionism necessary for a specific type of performance recital.

So, how do you want to learn? Some people want that way to learn. Some people want to be taught, you know, sit down, do this, do this, do this, lead me by the nose, and don't do this. Don't do that. If you deviate from perfection, right? You want both, right? In the end, the way you learn to play music is to have 30,000 hours of just banging on the instrument, and you –-

EDDY: Well, Dave, you kind of hit on music, and I think that's kind of interesting because I wanted to add to that and say, I'm the kind of person that learns but based on just grabbing a guitar, right? Strum a couple of things until something sounds all right, and I'm like, oh, that sounds pretty good. Let me see if I can replicate that, right? And I'll try it again, and I'll try to add to that. And I'm like, cool, I think this is awesome. I think this sounds great. You know, I have no basis on it, on why it sounds great. It just sounds good, right? But it's fun. It's fun to learn that way because you get to experiment, right? Get your hands dirty.

I've also played with musicians where they learn by learning the craft, like, the roots, like, the internals of like, oh, I've got to know what notes are. I got to know how composition works because I have to dissect it before I even begin to touch it. And I'm like, God, that's so boring. Like, why are you doing all this research? Just play. That's, like, the fun. The harmony of it is just the experiment, not the research and development, right?

WILL: That was the problem. That was the problem with me and Ruby, right? I struggled with Ruby for a couple of years because I had a mental block around not the functional parts of it, right? Because I came from ML, like, you know what I mean? This was no big deal. I could do functional programming, which is fine.

The problem was the loosey-goosey, funky syntax and all the magic pixie dust sprinkled throughout it because I came from C, you know what I mean? Where like, if you wanted to know how that sausage got made, it would tell you in excruciating detail every single thing. And ML, ML had a nasty type system, but your types were right, or you weren't doing nothing. You know, there was no ambiguity.

There was no like, ah, you know, it just kind of works. It's like, if it looks like a duck, quack, quack, baby, you know, like, uh-uh, none of that, none of that. Like, is it a duck? What kind of duck? What is the species? What is the gender? What's its age? These were all...and so, I struggled with that. Like, I needed to know how things were going.

DAVE: I struggled coming into Ruby and Java from C++ because destructors fire the instant the object goes out of scope. Like, the way the compiler does it when that object is going to be...when we're done with it, the compiler executes the finalized code. And so, I had written a class called, you know, clogger that would say, “I've entered this scope, and I'm going to do this thing.” And its destructor would log the exit message.

And I ported that to Ruby, and it didn't work. I had things that were exiting, and then nothing. And then, my program exited, and I got 15 out of my 20, and then 5 of them just never happened. And it's because finalize happens on garbage collection, not when the object exits scope. And, like, yeah, that sucked.

WILL: Yeah, but your [inaudible 31:44] can happen anytime, you know what I mean? Like, your access after free, that can happen anytime, today, tomorrow, in a week, a year, like, oops, you're [inaudible 31:58]

DAVE: Yeah. So, in C++, the destructor is something that the system does for you at a specific point in time that you can then leverage for your operational details. In Java and garbage-collected languages, the destructor happens for the resource. It's going to free that thing up so that somebody else can use it, or it's going to, you know, if you've got a handle that you have to dispose of correctly, it's for that resource. It's not for you. It's for you in that we don't let your hard drive fill up or that we don't let you run out of memory. But it's not for you. It's not synchronous, where in C++, it was very deterministic, yeah.

WILL: Yeah, destructors, C++. Lots of fancy lies up there with your destructors.

EDDY: I want to add to something just because I want to take advantage that we have Mike on this call; by the way, Mike joined us.

DAVE: Yeah, Mike just joined the call. Welcome.

EDDY: I kind of want to dive in a little bit. I want to circle back a little bit to music because Mike is a musician, right Mike? Like, you compose music, right?

MIKE: Sure.

EDDY: So, if someone were to ask you, “Hey, Mike, you're a musician. We need someone to write music for us. Here's an instrument that you have no knowledge or context about how to write.” How do you learn? Knowing that you do understand how composition works, right? Just not the instrument. Like, what is your take?

MIKE: Well, as talking before about how you've been with musicians who want to understand structure and that [inaudible 33:26]. I think it goes the other way. You give a kid...you have a toolbox, you know, they get the hammer, and they'll hammer everything. They'll just be joyful hammering on everything. And there's nothing wrong with that, right? I mean, there's a lot you can do with a hammer. It's a useful tool.

But after a while, sometimes, you want something that is more nuanced, more specific, a special-purpose tool. Maybe you need a chisel, for example. It's hard to do with a hammer what you can do with a chisel. In fact, you need a hammer to use a chisel. You kind of need them both. It's a collaborative sort of thing.

WILL: Hammer's all the way down.

MIKE: Having more tools in your toolbox is really useful. And I think the people who pursue music longer when they discover the broader toolbox, I’m thinking about Dave saying, oh, yeah, it's just a hammer. That's not a box sounds like. And he plays guitar, like, hey, I can do this differently. But, man, having a bigger toolbox, whether that's being able to do more improvisation or being able to think, well, maybe a, you know, five, seven chords, is going to resolve really well down to my root, and that sounds really nice, you know, is really useful to know because it allows you to kind of visualize the structure, have some bigger, more...I say bigger, more specialized tools so you know what you might use in that spot.

I would say that if I had to do something for a new instrument, and I've thought about this before, you know, what would I do with some random instrument? I would have to go and study what the range of that music is, or the instrument, right? What's possible. Because you probably still have a sense of what's...you certainly know what's possible with harmony, right? With how pitches are going to sound together. But you might not know what's possible to do with that instrument.

So, you're going to have to study and from a very technical perspective, you know, all the dull parts [laughs]. What is the range of this instrument? But you still have the joy of the music creating because you're like, well, I know how it sounds, that, I get, and I can put these two together. And you actually can, I think, get some pleasure out of discovering what this new tool can do.

Hey, I just gave you a new, I think, plumb bob. If anybody's ever used a plumb bob...I think it's my favorite name [laughs] of a useful tool. But, you know, you have this very specific tool that maybe most people haven't even heard of. And what does it do? What could I use this for? And you start envisioning, well, what could I do with this? And so, just the way of thinking about it changes. It's not that you're not still enjoying that process of creation, whether that be music or whatever it is, but you're thinking about it from a different part, you know, from a different area, coming at it from a different direction and, you know, working on the other side.

WILL: So, I mean, like, I like the music analogy in terms of learning because it's a little bit decoupled from the day-to-day nuts and bolts of what we do. And so, if I was going to sit down and I was going to teach somebody an instrument, because, first, I've got kids, and I also am a musician, and I would love it if they were musicians, too. And I'm not going to, like, you know what I mean? Because they’re my kids, right? My oldest is just barely getting old enough, so whether it's a possibility for him.

So, what would I do? Number one, I would find something that he had some interest in, like a musical instrument that he gravitated to on some level, whether it's the flute, or the saxophone, or the drums, or the guitar, or the bass, whatever. Find something that he likes the sound of, like, he's drawn to on some way. Two, I would get one for him, right? I mean, which, you know, okay, it sounds obvious, but it can't be overstated, some platform with which he could practice on. Three, I would find them some instruction, some in-person instruction.

I know, Eddy, you mentioned, like, you know, playing guitar and learning guitar and stuff like that. And, man, I’ll tell you, like, the biggest piece of advice that I give to beginning musicians, that is almost universally ignored in this day and age, it's like, it takes some lessons, man. It takes some lessons. You'll get so much better, so much faster.

And then, the last one is I would put him in an ensemble, right? An ensemble so that they can play music in a group to get the fun, the joy of, like –-

DAVE: Together, to jam.

WILL: Hanging out and not just playing music yourself, playing music within the context of other people to get that joy. It's much like, hmm, I'm not going to make that dirty joke, but [chuckles] think about stuff that’s fun you can do by yourself and how much funner it could be --

DAVE: With people, yes.

WILL: And so, like, how do you analogize that to, you know, learning engineering, software development, stuff like that, you know? You could get all those things in together, and any sort of formalized method of training, be it a bootcamp or a bachelor's degree or, you know what I mean, anything, is going to incorporate all of that in, right? But it's a lot harder to do by yourself.

EDDY: I'm actually kind of curious; if someone were to ask you like, they give you the directions, says, “Hey, I know you know how to play guitar, but I need you to learn to play bass.” And the response is, “I can make my guitar sound like a bass. I don't need to learn bass [laughs].”

WILL: You can't, and that's only spoken. Only somebody who doesn't know what they're talking about would say that.

EDDY: [laughs]

DAVE: There's more [inaudible 39:18] to that, right? There’s --

EDDY: So, it’s like, we need to build this feature, and someone says, “Oh yeah, I'll do this in Ruby,” and you're like, “No, no, no, no, but Ruby isn't the equipped language to do this, what we need to do.” And he's like, “Oh, but I can make it do that. Like, I can make it bend the way it's not meant or designed to,” right?

DAVE: There's a beautiful distinction between Turing completeness and the idea of a Turing tar-pit. A Turing tar-pit is where everything is possible, but everything is a pain, right? You can play bass on a guitar. The White Stripes, the big song, Seven Nation Army, everyone thinks it's on a...no, he's playing on the guitar, on the low E string with an octave drop pedal, right? Okay, yeah, you can do it.

There's two sides to this; one is, music comes from the musician, not from the instrument. So, if you take somebody who's an excellent bassist and you hand them a three-string guitar, they're going to be okay. It's not going to sound like a bass guitar. And if you tell them, “Sit in on this ensemble as the bassist,” and you hand them, you know, a soprano ukulele, it's not going to work.

So, there's the idea of, like, I can make anything fit here because that's who I am. And then, there's the converse idea, which is, can you make anything fit into this round hole? Not necessarily. Sometimes, you’re going to have to find the right thing. Mike was talking about the tools. And something I wrote on a blog years and years ago is always use the right tool for the job. I was standing there, hammering screws into a board with a wrench, and my dad came over and smacked me and said, “Use the right tool for the job. Use a hammer to pound screws into a board.” And it's like, wait, it's still the wrong tool, right? It's the right tool.

We keep talking about music, and I love that because the conservatory nerds are going to say, you know, it's like, there's only 12 notes and, you know, on a heptatonic scale, there's only 7. And you have to be perfectly inbound this. And then, you could talk to the jazz musicians, and they will tell you there are no wrong notes. You're just not confident enough. And I'm like, wait, but surely not everybody can think that way.

And then, you go back, and you listen to country music, and you realize the twang of, you know, [vocalization], that [vocalization], that they're literally bending the string into a half sharp minor note, or a half flat, whatever it is. But they're literally bending the string to a note way halfway between. It is not on any out of key, out of tune, out of everything. And it's on purpose, and it sounds perfect because it belongs there. It's this ugly, sour note. And you need it to make the rest of the consonant notes sound great.

WILL: Sure. Sure. I mean, like, non-western music uses a lot of microtones that are not...they're not even in the 12-note scale, you know, and, like, they're not accidental, and they don't sound bad either. I mean, it's just a different way of thinking about music. But I do want to pull it back to engineering. And what I would say is I talked about this sort of like, you know, this baseline, get an instrument. Get a teacher. Get an ensemble. And then, make sure you're making it fun. Make sure it's structured. Like, all that stuff that's great. And, like I said, like, anybody who's given any thought to teaching how to do a thing is going to have all of those aspects.

You're going to have a theory. You're going to have personal projects, and then you're going to have group projects, you know, have the whole thing. However, once you get thrown out into the industry, you get nothing. It's just like, “Hey, man, like, it'd be cool if this...hey, our Go servers crashed, and the guy quit, so you know Go now.” “I don't know, Go.” “Like, yeah, you do. Get to work,” you know? And that's the gig.

Or, you know, even worse than that, you're scraping together hours in your free time where it's just like, yeah, man, I don't know if, like, I don't know if, what is it, .NET? I don't know if .NET programming is for me. Maybe I'd like to learn Ruby. And now you're sort of trying to claw together nights and weekends and stuff like that. And I think that is a substantial driver of burnout and sort of like, I don't know, it uses engineers up. And so, how do you engineer that stuff for yourself when there's nobody who's going to do it for you? But it doesn't become less, you know, less relevant to maintaining a career.

DAVE: Yeah. There's a thing that...we keep bouncing off these contrasts between overprescription and under-leading insufficiently. Like, sometimes you pick up the guitar, and you're like...or you stand on the panel, and you don't know what to do. You can't jam in a group if you don't know the key that we're going to play in, right?

And I wanted to circle back to this a little bit. One of the things that was super powerful to me early on my career was the discovery of a concept of mentoring, where a mentor is somebody who knows many, many, many, many, many things. They’ve forgotten seven ways to solve any problem that you're going to deal with, but they won't overprescribe. They will show you one way to do it, or they'll say...ah, my guitar teacher, I could not get this chord change, and he said, “Maybe try switching to this finger.” And all of a sudden, I could go from this chord to that chord, and I would just pivot. And it was easy and ergonomic.

And finding a mentor can help you really accelerate both because the mentor can say, “I'm not going to tell you the 73 ways you can do this and force you to learn all 73 of them before I let you do any of them. I'm just going to give you one to try, and I'm going to debug...oh, you're struggling here because of this. And there's this problem that you don't know that, you know, do this and, all of a sudden, your program just works.” And the first few times, you don't know why, right? Because your mentor knows [inaudible 45:25]

WILL: I wish we had time to get into the continuing education aspect of this thing. Because I think this is where, like, in my opinion, this is one of the great sins of the industry, in that, like, technology is moving so fast, all the time, so fast all the time. I do feel like it's slowing down a little bit, which is nice for me. But --

DAVE: Is it slowing down, or has the frenzied, fresh, cutting-edge moved away from where you're focusing? I'm running into that. There's as many forest fires to fight every single day. I just don't see them. And I walked into, like, the AI stuff, and I got to run so hard just to stay at the back of the pack.

WILL: I'm not sure. I'm not sure. I'm not sure. I don't know. You know, I just don't know enough about AI to really know, like, what all is going on. Although, I mean, I will say that, like, it doesn't seem like, I don't know, who knows? That's a different, separate tangent. But --

DAVE: Yeah, the idea is the sigmoid pattern, right? Things that are on fire tend to taper off over time. Yeah, yeah.

WILL: Well, exactly. So, the question, I don't know, I mean, the one thing that I wish we could have gotten into a little bit deeper is continuing education for engineers and how to keep things going, you know, because, like, it isn't...the problem with, you know, engineering education isn't so much that we don't know how to do it, you know, when we can be bothered to.

The issue we run into is, can we be bothered, you know, can we be troubled to keep these things going? And I think it's shockingly wasteful. We burn a lot of engineers, they're perfectly good engineers, just because we can't bother to be training them on the new stuff. And, I mean, if you compare that to other industries, other professions, other career development stuff, nobody does it like this. It's really crazy the way things are going. But it's still incumbent on us as practitioners, as craftsmen to keep that stuff going. And if your boss won't do it, if it isn't part of the industry, then you just have to work it out yourself.

DAVE: Yeah, your knowledge portfolio [inaudible 47:45] career, and if your boss isn't investing in it, you're dying. You need to invest in it.

WILL: Yeah. Yeah, precisely. I mean, you know, I mean, they'd be happy to get rid of all of us and replace us with new grads for half the money.

DAVE: Yeah, until they find out that what they needed for that server fire last week was an engineer who has forgotten 19 different ways to solve that problem. All right. It's great to have a team full of people that can solve any problem first principles, but it's kind of a pain when your entire team has to solve everything from first principles.

EDDY: I think basically just coming back and having a [inaudible 48:25] is basically is there's different ways to learn, and it just depends on the personality of the individual. And it's funny how we keep coming back to music, unironically, from other sessions. Like, there's a parallel between music and programming. It's great.

DAVE: Music, linguistics, and programming has one of the most creepily off-the-charts, oddly specific overlaps. Get a musician, a linguist [inaudible 48:58], a programmer, just every time. Yep.

WILL: Interesting.

EDDY: Yeah, it's awesome. I'd like to see that study. It'd be great.

WILL: All right, well.

DAVE: It was just anecdotal, so... But so, now we've got our next...this is turning into the podcast where we tell people, let's do a part two of this, and then we never do the part two of this. Someday, we'll get around to part two, so...we hope.

WILL: Well, thanks, y'all.

DAVE: I think this has been a really good chat. Yeah, thanks for coming. Thanks for listening if you're at home. And if you're not at home, go home, and then, thanks for listening at home.