S15E10 The State of Career Growth in Elixir with Bruce Tate
===

Charles (00:32) Hey everyone, I'm Charles Suggs, staff engineer at Smart Logic.

Emma Whamond (00:36) And I'm Emma Wamond, a software developer at SmartLogic, and we're your hosts for season 15, episode 10. We're joined by Bruce Tate, founder of Groxio, author of Seven Languages in Seven Weeks, and Programming Phoenix LiveView, and one of the most recognizable educators and speakers in the Elixir community. Today we're talking about the state of career growth in Elixir, how AI is changing the work, what it means for developers at different stages of their careers, and how engineers can continue learning and advancing. Welcome, Bruce.

Bruce (01:12) Thanks for such a kind introduction. I'm not sure I'm deserving, but we'll give it a go.

Charles (01:18) Yeah, well welcome back to the podcast, Bruce. It's nice to have you again.

Bruce (01:22) It's been a while.

Charles (01:23) Yeah, yeah, it's been at least a few years I think. I'm I'm sure many of our listeners are are familiar with your work, but could you give us a brief introduction of who you are, your background, what is your Elixir story and and what you've been working on recently?

Bruce (01:37) Yeah, that's actually a long question. let's see how quickly I can get through it. So ⁓ so you asked about first my career.

Charles (01:40) Yeah.

Bruce (01:44) So my career growth, ⁓ I should probably talk about in terms of languages. So I learned basic as a ⁓ I wanna say I was a third grader, maybe maybe a second grader. ⁓ while most people were mowing lawns in the south, that didn't look fun for me. I was writing ⁓ basic games for spending money. So That's a that's a fun fact. My first computer I owned was Radio computer. It had this small keyboard called the Chiclets keyboard, which is kind of famous. And I went from there to IBM. I worked IBM for a while, about 10 years. I kind of maxed out the technical moved on to startups. So at IBM I wrote mostly and then a couple of the older languages like Fortran and COBOL. basically to build interfaces between the the IBM's query manager, which was was our our user interface on top of DB2, is a database, a lot I And then I moved from there to startups. I did startups for a number of years, most of them unsuccessful, had a couple of small successes, and most of that career was moving from Java To Ruby and then eventually And I've written books all along the way and most of it is is kind of fortuitous. I left IBM to join a startup and that startup was called I Can Make It Better. And with a name like that, with a brand like that, you can imagine that it failed pretty quickly. was dead. Right? And so the internet bubble bursts, these things were falling apart. So I told my wife, if I leave IBM, I can come back. Because I mean, I was doing pretty well there. I had maxed out the technical And tried to come back. They said no, you can't. And I told my wife that if I can't go back to IBM, I can always write. And so I wrote a book. And this was the second book that I'd written. And the first was kind of artificially successful because we sold it through. IBM's internal system called Mechanicsburg, right? And this is where you would go to get manuals, but I I got one sold to an external publisher, and so sales were artificially And then I wrote this book that had a great title, but it was a terrible book. It's called Bitter Java. And this was at the time that that Amazon was basically offering books for for sale, there were no online books yet. And so you can imagine that if you got discovered in in the right kind of forum, you could bump up the the Amazon bestseller ranks really And this book got slash dotted. So there was a forum at the time called slashdot, which slash and a period. That's characters, right? And so it got discovered there. And since you couldn't get the book yet, People saw the title and projected whatever they wanted to on the book itself. So they said, Bruce Tate is gonna stick it to the man. I wasn't going to do any such thing. I was basically doing what was effectively a terrible idea, teaching people how to code Java by teaching people how not to code Java. Which is it sounds if it sounds like it doesn't make any sense, it doesn't. If it sounds like it's a bad idea, it is. I basically wrote this book. And it climbed in Amazon. I can remember sitting breakfast room nook because our mother in law was staying with us at the she had cancer and she was dying and she had this this wound sucking machine that would kind of trigger and gurgle and just make all these terrible noises and suck the life out of the house. And we were but we had basically brought the computer so that she could see this thing that we were experiencing. Which was the book climbing from like two million two millionth best selling book on Amazon to one millionth, and then we're saying, ⁓ now we're better than half the books on kept climbing and climbing, you know, to the the the top two hundred in technical

Charles (05:59) Ha ha ha.

Bruce (06:04) the top one hundred of all books, number seven between Grisham and Hawkings for one hour. So that book.

Charles (06:13) Haha That's a win.

Bruce (06:16) That book established me on the technical speaking circuit. And then people read the book and it kind of fell immediately fell off of those lists, said this thing is actually still the worst the highest ranked, worst reviewed feud book I've ever so then I joined a speaker circuit where I met people like Dave Thomas, who is my mentor, who got me into Ruby. I met Stu Halloway, who I learned so much from just basically it was a who's who of people who eventually left Java, right? And then ⁓ you know, there were still some some great minds that stayed around, but a a lot of my great mentors were moving on to other programming languages Java was just a little bit too ceremonial, if that's a if that's a word.

Charles (07:01) Mm-hmm.

Bruce (07:03) And so I I adopted Ruby, which was very simple and it spoke to me at the time. And then I went from there to Elixir basically one of the startups. So I wrote a book called Seven Languages in Seven Weeks. And that book was written out of fear, but because I could see cool kids leaving the room for the Ruby programming language because wouldn't scale, it wasn't immutable, and the chip designs were changing. I kind of understood that that was going to change a lot in the programming industry. So yeah, my Elixir story is I got to Elixir because it wasn't Ruby, because I I had tracked José, loved his career, and ⁓ I wrote seven languages in seven weeks, effectively looking for Elixir. I was looking for a language that resonated with me. And that was the probably the best selling book I've ever had, and maybe the most decorated in terms of awards and things like that. And I think it's true because so many people were walking the same path that I was. And I just invited them along. That's all I did. And so I wrote a little bit about languages like Lisp. And you recognized a lot of Lisp in the Elixir language. I mean it's it's ⁓ essentially tagged tuples under the hood just like

Charles (08:31) Yeah.

Bruce (08:33) Elixir is lists under the hood. It's code is data. Elixir has a macro system that's very much the was in the book, and you probably recognize ideas the monadic systems, which is kind of the imperative shell and the functional core. And you know, we write our Elixir applications that way with the context and schemas, which are, know, basically pure probably recognize The Erlang, of course, and and the beam and and you know supervision, which is the management of life cycles, once again wrapped around a functional core. And it's so all these ideas were my walk from this is my intuition that took me from object-oriented languages dynamically typed languages to Elixir that was concurrent, and then to which is a different kind of functional language in the math, heavier in the types. José read that and he was also leaving the Ruby quite know where he was going. And that book might have informed some ideas for for the Elixir And we met in in London as Jose was giving a And I asked José, what do you need? What what kind of help do you need to establish this language? Because it had, mean, my goodness, it had Ruby syntax, it had all the things that I needed in terms of of languages to speak to me without kind of breaking my brain from I'm I have dyslexia, right? So Lisp is a non starter, right? You know, everything's parentheses, all the order of the functions is different and everything reads backwards and and you know, just walls of parentheses. I mean that just wasn't gonna go.

Charles (10:16) Yeah.

Bruce (10:20) And ⁓ I loved Erlang. I couldn't make sense of the syntax.

Charles (10:25) Mm-hmm.

Bruce (10:26) And so I was looking for something else and I was looking for more modern concepts. So Jose was some of these ideas were resonating with him. he tweeted about it back at the And we met and I asked him what he needed. He said, you know, we're starting to get some traction, but I can't lose Eric Meadows-Johnson. graduated from university and obviously there are no Elixir jobs yet, right? Because the the language was pre-1-0. We didn't have maps yet, everything was keyword list and Jose was waiting for the maps to to finalize and and Erlang to kind of move on. And so I

Charles (10:57) Right.

Bruce (11:03) Meadows Johnson and gave him a day a week to to work on to work on Elixir. And that's that's how I got started in in then ⁓ Dave asked me to kind of champion a the the books in the Elixir line. I did that for many years kind of the lens. So conferences mentoring in the Elixir in the Elixir ecosystem and writing and interacting with authors. That's that's kind of my view of Elixir. Not really haven't written a lot of libraries, really done a lot of contribution in terms of Elixir's core libraries. My work is through the community and investing in youth and in teaching.

Charles (11:48) that was your first book that I ever read with Seven Languages in Seven Weeks, which was part of like a shared learning thing at a shop I was working at at the time where we all were taking we were reading the book together and then talking about it together. It was a really cool experience. and I I didn't realize the connection. I was gonna ask, you know The book didn't include Elixir, it included I didn't realize the timing of where that fit in the chronology of the development of Elixir in the first place. Yeah.

Bruce (12:14) Two thousand ten. Two thousand ten. You check out the early commits and the Elixir right in that zone. So we were ⁓ both thinking about the same things mean I'm sure the project was started and just some of these ideas resonated. or maybe it was he was working on Lego at the time and was flipping stuff over to more something more If you there's there's a conference talk way back Jose looks the first wave of commits and he says, Aha, Eureka, and then you know, all the commits fall off and called it the Valley of And then he stopped trying to build the beam from scratch and started building onto the beam and then everything took off. ⁓ but yeah, it's like we were thinking about the same things, the same issues. And my goodness, he has made made a lot of good decisions in a

Charles (12:54) Mm.

Bruce (13:04) and hasn't stopped yet, right?

Charles (13:06) It really seemed like the right language at the right time with the internet and the way that things were distributed and like it just it just seemed like such a fit for the time. ⁓ and still does.

Bruce (13:20) And the right language for Internet of Things and Nerves, right? And then then people did that for a while. And then the right language for web development and LiveView and Channels then the right language. I mean, it's like the shepherding of this language through all of this chaos

Charles (13:32) Ha ha.

Bruce (13:36) is absolutely amazing. ⁓ I mean, even can never imagine that a functional language would have any kind of a machine learning background, right? But Jose is fearless, And so this when Sean, I had left the ⁓ kind of the pragmatic bookshelf position when Sean Moriarty published his book about ⁓ machine learning in Elixir. And José had not read that book and didn't know anything about it and picked up that book and said, This is cool, but we need to do this. I mean, if you're working with Elixir, it's list and you can't. Do random access of lists and hope to have any kind of performance at all. Right? And then you nest those things arbitrarily deep, and then you make those things millions, millions long, you just can't do that. So he said, Well, wait a minute. What if I swap out all of Elixir's basic data types, wrap this with some type of a limited scope, and then and then plug it, swap it out with?

Charles (14:22) No.

Bruce (14:44) with, you know, all these Google engines and all these other machine learning engines. I mean, that is nuts. That's it's crazy to even try to pull something like that off, And he did. And you'll fast forward a couple of years and Elixir is among the most accurate, maybe the most accurate language for machine learning or for for agentic coding. It's it's it's And this happens over and over. Over and over with Jose. He just his decisions And when you combine it with his his curiosity and his just steadfast I don't know, his guidance to to what's what's right, to to just ⁓ building the right the right kinds of of systems and making decisions that over and over that are not too much but have the potential for growth and ⁓ and taking care of users along the way. I mean, over and over and over and I mean I used to doubt Jose. don't I I never doubt Jose anymore.

Charles (15:46) Yeah, right.

Emma Whamond (15:47) Absolutely. So with Elixir's growth as a language, what's the career growth look like in the Elixir space right now? I know so much has changed. I know

Bruce (15:59) ⁓ that's a that's a great question. I mean maybe maybe the most important question right now. your question is coming at a pretty pivotal time to me. I've had a mentoring program for 10 years that I just shut down because I I have not believed in bringing people into a career path that is dead or dying or limited. Yeah. So yeah, it's a scary question. And the the it's it's scary, of course, because so many people are coding with agents. And over and over I walk into a programming shop and not just Elixir, probably less Elixir than other languages, because the agents are are pretty accurate with Elixir, but even with Elixir shops, I see the same story playing out, and that's that Seniors are absolutely frazzled and and buried under walls and walls of pull requests to review. Right? And it doesn't matter if you have like Code Rabbit or whatever looking over the code, looking over your shoulder. It doesn't matter. They're buried under these walls and walls of review code. Because basically,

Charles (17:11) Yeah, you're still ultimately responsible.

Bruce (17:13) yeah, yeah, yeah, yeah. It's ⁓ and the juniors, the juniors intermediate programmers. Haven't been trained to use this new kind of tooling. And ⁓ so so what we're seeing over and over is, hey, wait a minute. I I tried doing this with juniors, it didn't work. And then I thought, well, why can't I fire the juniors just cut off the middleman and use the seni let the seniors use the agents directly? And it sounds like I mean it's it's a seductive argument, It's a lot of people think in this way. But I believe that the career path should be the same in 2006 as it was way back in I don't know, ninety n ninety something, eighty something. Eighty something, my goodness, I'm old. So in in eighty seven when I graduated from college, right? And so It's it's still the same. We s we still have to We still have to apply tools. It's I mean, now we're we're essentially metaprogramming in right? It's we're writing code that writes code, prompts that write prompts, and then those prompts are are writing are writing ⁓ Elixir. But there are a couple of differences that we'll get to a little bit later. So ⁓ the career path I would say is fragile. And I believe it's fragile because we've made a conscious decision. To take the the gains from this AI revolution and push them back into our companies, into our pockets, anywhere but reinvesting in our juniors. Right? And I think that's a problem. I think that's a problem that we have to talk about. Said another way, I think that we are eating our seed And ⁓ I think that there are some some bright spots on the horizon and mostly well sometimes you can look at the at AI agents as something that can build more quickly but it's also an atomic shovel it can dig pretty quickly too right so we're starting to recognize that we have to invest in the skills to make this work. And what do those skills look like?

Charles (19:23) Mm-hmm.

Bruce (19:33) we'll we'll have that conversation as we go.

Emma Whamond (19:38) So on the Goroxio website, you described your approach as anti-vibe coding. it it is a shovel. I mean, this is the first time we're experiencing this kind of tool and ⁓ how quickly code is being produced. With your anti-vibe coding approach, what does that mean to you? Are you against people using AI tools, or is it something more specific?

Bruce (20:01) So I believe vibe coding is I'm I'm using that in a very specific in a very specific sense. So me tell you a little bit of a story on that So I walked into this this group called the AI Collective, and it's the first time we've been there, and it's the first time most of the people in in the room had been there, and there were probably 35 people, right? And all these people were using AI more than half the time in their job. Every single one of them. And ⁓ so I I threw out a one-liner. I'm trying to teach people to code without vibing. And from the rest of the time that anybody said anything, ⁓ whenever they said anything negative about AI, they would nod to me. Right? So I'm not saying so so ⁓ thank you for the question. I am not saying that I'm against coding with agents, I believe that vibe coding. Is coding with agents without guidance. coding with agents without guidance. And I mean I think I think I'm not alone in that. I think that probably early in the game, people would call vibe coding letting what was it? Copilot. Is that was that the first editor most of us used? so VS Code with Copilot and and the code ⁓ you could vibe with completion or then then you have like the cursor agents. you could vibe vibe out ⁓ a whole module. Now probably the if you have a pretty decent user of AI, what they're probably doing is they're thinking about the the lines and the APIs in their application, and they're probably guiding the of an application. So let me give you an if I have a junior who's asking to build a feature end to end with Phoenix LiveView And maybe it's just a feature. And they create the code. So one of the things that they can do is we we talked about the idea of an imperative shell and functional core a while back when I was talking languages in seven weeks. So the idea about that is that not only is that where most of the pure functions live, it's also the idea about embracing certainty. Right? This is not where you want to process user input. Because if you're processing user input, there's a lot of if-thens or cases or cons. Right? If it's valid, do this. If it's not, do this. So we try to push those decisions elsewhere and we try to make so that your code in the functional core can, when you compose, you can compose with pipes. And when you use pipes with Elixir, if you're using them right. Everybody's smiling just a little bit more. Everybody likes their job a little bit more. You would take a little bit less money to do the same thing. Because it's easy and it's smooth. But the thing about it is at some point in your architecture, things start to break. And so you have to say, hey, I need to wrap that code with an idea. In C it used to be a value, or in C it used to be a value. It used to return like a negative one or a ninety-nine or whatever, a bad return In Elixir, you wrap it with a tuple called a tag tuple. It's either okay or error, or the wrapping might be something like a chain set. Because I need more information about not just that it succeeded or failed, how it succeeded or failed. So if I'm a beginner and I see an application That maybe implementing some of the ideas but in Elixir, it's not going to look like an idiomatic Elixir application. You're going to have nested cases and cons, right? Because a lot of that composition that should have been done in the core is been being done in a massive central that is the body of a gen server or a controller or a live view, If you have a student that is taught. red green indicators, you could say one of the red-green indicators is you should not see composition that has to care about tag tuples or about any other kind of wrapping in the core. Pipes in the core, widths in the boundary. Right? It's an easy red-green indicator. It's something that we can It's not something that we had to teach early maybe even like two years ago. Right? But this is a red-green indicator that this code is okay to commit or not okay to commit. This is a red-green indicator that this agent is spending tokens. It doesn't need to spend because I already know this is wrong. Right? Or I mean other red green indicators, the the indotation of the left margin. Really easy to tell, right? This is right track, wrong, wrong Nested cases. Right track, wrong try. Right? Nested cases, the the the agent has missed something important in Elixir, and that's width. Right? So width also has composition of composition through failure is the the width statement rather than nesting these these concepts and with comes with this this idea that you can stay above the fold, above that else, as long as things are successful. And as soon as things are unsuccessful, you drop to the else and now you you'll ne you can never kick back up. And those ideas are important. And in Haskell this was done with with monads like the the just monad And with with Elixir, it's done with tag tuples, but the the pattern is called functional core imperative And with a little bit of training, you can see how that works. we can invest in our our our juniors. And another thing that we have to teach our juniors portion control, right? we need to teach portion control. We need to how much code that you can produce, but how much you should. So modern juniors intermediates haven't ever had to navigate the can should, right? Because Fingers only moved so fast. Their vocabulary was only so only do knew so much And there were were basically guidelines, there were guardrails in place and the git process to make a commit where seniors would review my work and catch errors early before we come too much off the path, off the rails. Yeah. I'm not even if I answered your question. Huh.

Emma Whamond (26:45) No, no, I I think it's you've also written that this isn't just a junior talent problem. It's a training So how does framing it that way change what teams should do?

Bruce (26:58) Yeah, so and I'm not saying that you you need to that everybody needs to hire Groxio. what I'm saying is that you frame the problem around learning to to code with agents instead my juniors are are failing, my intermediates are my seniors are failing, ⁓ then everything gets easier. So here's what I mean. So if you're a senior and the expectation is that first work should be finished, right? So we we don't submit these these pull that have patterns outside the patterns elsewhere in my code don't submit pull requests that have three new introductions of the the create user test fixture. We don't submit pull requests with with two different new types of utility modules. Right? We produce code that fits into the into the That's a trainable thing. It's a new problem. And it's a new problem because basically you have an exceptionally gifted gifted junior called Claude who's working on the system without without exceptional judgment.

Charles (28:07) Mm-hmm. Mm-hmm.

Bruce (28:11) And we've got to learn to provide the judgment. a problem that we need to teach, that we can that we need to and can train juniors to can also train the portion control. And we can also train the seniors. Hey, when you see this problem, the problem is not that the code is is slightly off. The problem that the code is wrong. And it's inexpensive to build the code now, and the right response is to throw it away. Is to throw it away and say, this is what I need, here's my red-green indicators, here's how I know it's wrong. or here's how I know that the job's not finished, we can reject it very quickly before we've gone over and reviewed the whole thing. Right? So the senior is trainable because you know we can Well, mostly with this with the seniors, it's it's making sure they understand ⁓ not just how to use how to use their their Elixir tools, but also how they need to use agents and that their agents that that we can do that we could we can layer our code in agents the same way that we layer code in Elixir macros, right? We build skills that that understand how to how to recognize and build functional core. That recognize that we need not to use live components and what to do instead. Right? Intermediates we can train to use LLMs as part of a team so that we're fitting into a greater framework and we build code that that matches that fits into our system. And juniors we can train these very same things that we've Been talking about the portion control, red-green indicators, also we need to train juniors less on individual function vocabulary. So that's taking something off the palette. Actually, the biggest part of learning to be a programmer in 2026, we take off that that off the palette because we can use agents to help do that work. But we spend more time on API design. And Behaviors because behaviors in a version of control, this is what's hard to get in Elixir. your live views, your you know, your Broadway, your gen servers, all these things are behaviors, and it doesn't always snap into place the way a function call in this case, the function is calling my code rather than than the other way around, and I need to have the context for when that happens and how that happens. So yeah, those are those are some of the ways that that we can change. portion control, kind of acceptance tactics, layering of of agentic work, practicing agenc work, and ⁓ and changing the order that we teach some of the core concepts. we're we're focusing on more of what an intermediate developer would API design. Behaviors, protocols, things like that.

Charles (31:26) Some of this reminds me of your book Designing Elixir Systems with OTP talking about the functional core and how we structure the different parts of our applications and ⁓ keep certain responsibilities in certain places and separate those from other responsibilities within the larger it seems like you know that that book kind of keeps coming back up as things change. It seems still so core and functional. pardon the pun, to to understanding how to write good Elixir applications, even as all this other stuff is changing. it almost seems more relevant to a degree to juniors now to be reading this book that I think initially was targeted not at people who are brand new to software per se. so as as you have a junior who's learning, how do how do you then see that there's progress being made and ways to help direct if The LLM is a large part of what's going on. Is it based on now these pull requests are looking more digestible? ⁓ there's there's fewer re-implementations of things that already exist elsewhere in the code base. What how how do you kind of make those judgment calls as a mentor, but then also ensure that the junior is is getting the right kind of like leveling up?

Bruce (32:41) Yeah, that's a really good question. So ⁓ first let me tip my hat my hat to James So all of the good ideas in the book are James's. And I'm not kidding at all. ⁓ he's he's really brilliant. my contribution to that book was packaging, voice, and pace. Kind of the writing things. In fact, I had not put together that Elixir was a reducing engine. until we wrote that book. It's kind of embarrassing to say. when I was working with with Chris and Jose on ⁓ you know on that that first programming Phoenix book, we had a Gen server in it. I didn't know how any any of that stuff worked. And so James put together this idea of the layers of the system, the different components. I put together the mental mnemonic do fun things with big loud worker bees. was Will to Beast, but we couldn't get a cover with Will to Beast 'cause O'Reilly the distributor for the plugs or for for the ⁓ the pragmatic press. But anyway, yeah, so this book is is really important. And in fact that's a lot of what I do today. And you mentioned the concept of mentoring, right? So I would say that more of my job is is mentoring relationships. with external customers around these ideas. And yes, it is around that Elixir is about reduce, about how how to structure your code so that first the LLMs can find these concepts and second when they do, it can wrap the concepts And can talk about the way things fail and how the fail percolates through the system. These are all trendable I do think that we need to do Most of our teaching, we almost were able to get away with most of our teaching within the pull request and kind of feature request flow. I don't think we can do that anymore. I think we have to be much, much more aggressive with our mentoring. And people need to see the ⁓ agentic coding done in the right way and in pieces. Right? ⁓ so and I would say vibing features is really using agentic programming with guidance. It's not really vibing anymore. Right? so getting the right size pieces and getting the right guidance in the so that it understands these pieces. when it works, it's really a beautiful thing. And when it doesn't, it can come off the rails so quickly that you can't wait for your pull request process. You have to be much more aggressive with with mentoring and taking care of your younger developers. And when you do, it's we we have this this perception that our our junior developers won't contribute right out of the gate. And they can. They can. We just have to put the right kind of framing on on the task that we give them and give them the tools that they need to succeed. It's no different than it was before.

Charles (35:44) For sure.

Bruce (35:54) Right. It's just that the the the cadence has picked up. it's much more urgent to get that that kind of help and in career growth earlier.

Charles (36:04) So if if the pull request is less useful of a venue for doing this kind of mentoring and sharing of knowledge and kind of reinforcing maybe how things are done with that within that organization or within that application, what does it look like instead? Is this like much more like focused, intentional time around, you know, you talked about showing agentic coding being done correctly. ⁓ but I y it Seems like it's more than that, right? It's more than just how do you do this with the agents, because it's also about how you're thinking about this, how you're planning and doing that ahead of time before writing your prompts. So is this like intentional time where people are like actively working together on learning stuff and talking about how to do things before they're planning and prompting and submitting?

Bruce (36:54) I would say four ways that things are different. You can tell I've I've talked about this, the first way is that we can't give up on the idea of people, right? Relationships matter. So as you're spending more time with agents, relationships, you know, actually meeting with somebody, solving a problem together, whether it's virtual or in person, is super important. and it's it's even more critical in twenty twenty six than it was in twenty twenty five because We have this new perception that if we succeed with with doing something incredible with AI, AI is what gets a pat on the back. Right? Nice job, Claude. ⁓ you two. And then if we fail, we get the blame. We get the blame. We didn't guide it the right way. So we can't give up on the relationships and the people part. We can't give up on the idea that we have have to fix the problem.

Charles (37:34) Mm-hmm.

Bruce (37:51) Not to blame. So the first is the Second, I believe, is the packaging of the way we train. So rather than sending sending our in in the LinkedIn article series, Predi is is our kind of our our model junior. But we can't send Predi away half a week or a week to learn OTP and then another week, week and a half to to learn live view. Can't do it. Right? What you have to do is do these in smaller increments. So smaller regular increments for a I get a chance to try a skill and have it break. Third, there has to be enough time where I practice skills and fail with the skills. And fourth, there has to be follow-through after I practice and play with those skills. So it's not just use these skills to do your job and let's pair through or three sessions together. That's not it. It's you have to have focused time to make an investment. But think about it. Once you've invested in that junior and once they understand kind of the intermediate design concepts and with with the agent they're able to so so imagine if your job is coding the function heads and getting the function heads Your job is getting the architecture is working with the customer, getting those relationships is getting the prompt right so that you you work on a prompt until it it is going to build what you exactly what you it doesn't build exactly what you want, you throw it away and you try again, you prompt All of these things are trainable skills. But then what you have is not a junior anymore because that combination of the junior and the agent gives you something that looks much more like an intermediate programmer that can be a a fundamentally a a strong citizen in this new world, right? it just it takes the takes earlier investment and it takes investment. It's what looks more like a mentoring investment than the old school training that all Groxio customers used to get.

Charles (40:06) What role does AI serve then in a junior's learning? When is it helpful? When is it harmful? You know, sometimes it will tell you things that are just not true, that don't exist in the spec you're asking about. where does that fit in?

Bruce (40:22) Yeah, so l let me give you two two stories, right? So one, Predi is new in an organization and Predi is given Claude, a GitHub password, and a feature request and said, Hey, knock this feature request out. And Predi knocks it out and knocks out the next one and the next one and the next one. What's Predi learning? Really, not much, right? not getting any kind of guidance on what's wrong or what's right with the code that's not getting any guidance about the idea how important it is to throw away the code from a conversation that's gone off the Because the only thing that you can do when a conversation goes off the rails is reinforce the problems. Right? I mean that's that's a fact. That the way that these are only thing that you can do is reinforce your problems. Predi is not learning portion control. Predi is is not advancing in her career, right? So you take the same person and you have a few mentoring sessions so that Predi can see how agentic programming works, see when it's important to to drop into into the ⁓ code editor and and actually some can see what what things are supposed to look like and then after an hour after two is asked hey go build this feature and when Predi comes back you can talk about it Maybe it's right. If it's right, hey, pat on the let's take on take on a bigger challenge next time. If it's wrong, can say, Hey, this is wrong, this is why it's wrong, and you throw it away and you prompt better, right? And so you have to be teaching Predi not just the agentic flow, but also, my goodness, it's it's if you plop plop somebody down in the middle of some OTP and they see this gen server and you see this handle call. Don't know what's behind it, and you don't know that this is just one reduction, you don't know what a reducer is, you're lost, and you'll stay lost. Right? So that's that's kind of the so what role does the agent play? It it plays a role in killing Predi's career if we don't invest in her, it plays the role of the ability to explore if if we make her curio curious. And if we equip her to to learn the right things and give her the right problems as she's growing. Right? So it is it is I have a not just a a programming a teaching agent with me all the time. So it's either a the great multiplier or the great divider. Pun intended.

Emma Whamond (43:12) You've mentioned in work that I've read of yours something called the dividend. The idea that AI has given engineers real time but right now a lot of organizations are spending it on producing more code instead of reinvesting it in growing their So how should mentors balance that pressure, delivery pressure with developers' growth?

Bruce (43:37) Yeah, that's hard, right? So that's that's where the conversation between us developers stops we start talking to management. We should say, Hey, ⁓ this is this AI has been pretty good to us in these ways. It's been pretty harmful in these. And here's what we need. Right? And ⁓ we need an investment in some of the returns, not all the returns, right? We know what that your boss is hearing the same things that we are. That coding now is easy. You just ask for it. You just wave the magic Claude wand and the code appears. Right? We need you to invest some of those gains in training and in time. We need time to to finish our jobs, to support the people we've already to invest in our future, right? I love the the the idea of an AI dividend that we can choose to invest the way that we want to. So that's not the way that that the dividend is kind of presented today. Today it's presented as just a multiplier, right? As a force multiplier. It's a dividend, and we can choose how to reinvest it. Yeah. Yeah.

Emma Whamond (44:53) I like that idea, yeah. and with the path from junior to senior, I know this this is something that ⁓ should be a bigger conversation, and I think that you've been able to ⁓ to speak to that. Could you just give us a little bit about your thoughts on that? How we're able to still create a clear path from junior to senior in the age of AI.

Bruce (45:19) Yeah, so I think that the path from junior to senior looks very much the way the path used to if we're making investments, right? If we're not making investments, the path to from junior to senior is going to apply to Claude and not the person sitting in the chair, which is the way that we're thinking about the problem now, hey, the model is gonna get better. It's like it's like Moore's law for for people but in reverse, right? You can do the same job with half the staff and half the staff and half the staff. That's that's like that's a backwards way to look at the world, right? So using that view, way back when when we started when when when Moore's Law was we said, wait a minute, we're going to kind of eat all the demand of computers in the world, right? When programming languages got got so much better We said, we're gonna be make people so we're not gonna need programmers anymore. same thing happened with with ⁓ with the and the industrial revolution when we make all these engines. we don't need ⁓ all these other things. But what's happened is when we have proven that we could write more and better code, we've We've invented reasons to use it to do some pretty wonderful and magical things. And that's that's what I hope things turn into, right? So if we're investing in the career basically it's it's going to sound trite, but the decision that we need to make is to make the investment, right? It's not how to make the investment. We already know how to make the investment. We know we need to train, we know we need to mentor. We know all of these things and there are all kinds of wonderful people that do what I do. a lot of people do it better. ⁓ I think I'm I'm one of the best in the elixir space, but if we make those investments, the juniors will grow the same way that they used to. ⁓ we'll be able to give them larger and larger jobs, we'll be able to give them more and more autonomy in projects, we'll be able to trust more and more judgment. And what we need to think about. Is not junior versus the AI, but what about the junior that's wielding the AI? So that's that's a much more powerful because then you have you have a much more powerful unit. ⁓ and that's that's the way I think that we need to think about it. We need to build those skills so that the junior gets better and the junior can manage more and more resources and do more with them.

Charles (47:57) Is there Yeah, I I think we're without directly asking the question, I think we're hearing a bit about the kinds of things that will distinguish talented both junior and senior engineers in this era. ⁓ you kind of the conversation as it's been so far has really kind of hit it on hit on a lot of I think aspects of that. ⁓ but are there are there things that we haven't mentioned yet that you think are the kinds of things that would distinguish talented engineers in this era, and what do people need to be focusing on?

Bruce (48:32) Yeah, so I'm gonna brag about Paulo. Paulo is Jose's brother. He works with works with us at And I I I I don't know if I should say it, but he's not a great Elixir developer. He's an Elixir developer, but you put the ⁓ agents in his hands and he works wonders, right? the agents become a multiplier in his hands. And the reason is that he is talking to to his customers. The reason is that he is looking at the output. He's looking for ways to automate. He's he's thinking about How to push beyond the idea of programming and into the world. He's thinking about what his customers need to do. thinking about how to how to not build things that his customers have asked them to build. It's it's a it's kind of a magical thing. And I am not sure where our where our career path is gonna go, right? I'm not sure how much of this is bubble. ⁓ I know that people are already deciding to to hire less, recruit less. but if I look at Paulo, I mean that's that's the model for me. It's like he is he's grown so much at at his time at and he's very much grown into from from a junior into a senior in in his impact on the business and in his his impact on the greater community.

Charles (50:02) Is there anything that would eschew or that would distinguish AI eschewing engineers in this era? People who say, no, I don't want to use that for, you know, reason A, B, or C, like, not gonna do it. What would distinguish them in this era?

Bruce (50:18) Yeah, that's great. That's a that's a really good question. And there are some places where we don't want to use And there are a lot of different reasons. one of the reasons is is regulatory. in Canada visited ⁓ visited the conference there in Vancouver, wonderful conference. And several of the banks have ⁓ regulatory they can't use AI in those types of problems. There are other types of problems that are related to to security where ⁓ know the sharing of but there are teams in the United States that have said hey our our product the the the way that we write elixir the way that we manage elixir is so different from the way the from the code bases ⁓ that that the technology has actually been trained on that we do better coding this stuff by hand those are the things that come to mind right regulatory and the problem space. also there are increasingly going to be people that are conscientious objectors, hey, I love the idea of AI. I'm not sure about one more data center and its impact on on the quality of our rivers, on on, you know, on the the people in the town who are competing from the same electricity on their electric bill. Yeah. I think that increasingly there will be more people that will say, hey, we are going to use AI, we're going to choose who we do business with. At least I hope so. So those those things come to mind. ⁓ Groxio has taken the position. We thought about not even playing in this space. Thought really seriously about Then over time we came to the conclusion we needed to touch if there were going to be juniors. We needed to prepare juniors for this world. And that's that's what we decided to do. I is it the most lucrative thing that that we could be doing? No. But we think it's the most impactful for the community. So, ⁓ and feeds my And you know, I'm 61 and ⁓ I've set my technical legacy with Elixir and now I kind of would like to work on my social work.

Charles (52:34) I was just in Utah and folks there were very concerned about a large data center that would use more electricity than the entire state and use a lot of water in a place that's already dealing with ⁓ s acute water shortage. ⁓ it'd be interesting to see how this plays out. ⁓ Well any other are there other like

Bruce (52:52) Yeah, yeah.

Charles (52:59) Words of advice ⁓ or things that you think Elixir developers need to be focusing on as we move forward.

Bruce (53:06) You've been very so very kind to let me talk about what I want to talk about, and that's the role of of ⁓ juniors, seniors, about the idea, the importance of making this investment. So let's stay on that topic. I do have a couple of links that I'll share with your readers. So we could attach those to to the podcast. One of them is the LinkedIn article series that we've been talking about.

Charles (53:25) Course.

Bruce (53:30) And one is ⁓

Charles (53:29) Mm-hmm. The AI coding crisis.

Bruce (53:31) yep, yep, that's it. The agentic coding crisis. And the first one is the sludge on the wall. ⁓ And the second one is we're doing Groxio Lives. So Groxio Live is something where the community gets together, talk about a ⁓ a topic. maybe we do some live Maybe we we look at some red green indicators. it's a new thing, but ⁓ but yeah, increasingly we're talking about Issues like this one.

Charles (53:59) Excellent, thank you.

Bruce (54:01) Okay.

Emma Whamond (54:02) Awesome. For all of our listeners, Bruce is a keynote speaker at ElixirConf in Chicago this September, 10th through can catch him there. And while you're at it, you can come say hi to Charles and If you haven't grabbed a ticket yet, we have a 10% off promo code in the show notes for our excited to be at ElixirConf this year and meet you you so much, Bruce, for having this wonderful discussion with us.

Bruce (54:27) Emma, you're very kind. Thank you so much for for spending this time with me.