# There are 2 kinds of devs. One of them is screwed. Justin Searls interview [Podcast #210]

## Метаданные

- **Канал:** freeCodeCamp.org
- **YouTube:** https://www.youtube.com/watch?v=hP931079TMw
- **Дата:** 06.03.2026
- **Длительность:** 1:29:33
- **Просмотры:** 13,070

## Описание

Today Quincy Larson interviews Justin Searls. He's a software engineer who cofounded a software agency 15 years ago that's still going – even after he figured out how to make a lot of money quickly and retire at age 38 once he had enough savings.

These days he's gone from solving problems for client to solving solving problems for himself by building open source software. Often using emerging tools like agents. He says he getting way more done now than ever before.

We talk about:
- How software development is ceasing to be a team sport and is now more about individual devs working directly for the people paying them
- How verifiability is everything - whether it's agents contributing to your codebase or humans
- How someone just now entering the field can use emerging tools to get an edge over more experienced developers

Note that I don't edit or censor these interviews at all. Justin uses some pretty blunt language so you may not want to listen to this around young children.

Support for this podcast comes from the 10,113 kind folks who donate to our charity each month. Join them and support our mission at https://donate.freecodecamp.org

Get a freeCodeCamp tshirt for $20 with free shipping anywhere in the US: https://shop.freecodecamp.org

Links from our discussion:
- Justin's website: https://justin.searls.co
- The Breaking Change podcast: https://justin.searls.co/casts
- Justin's article "There's no AI in team": https://justin.searls.co/links/2025-08-03-there-is-no-ai-in-team/
- Justin's article about how software is supply-constrained: https://justin.searls.co/links/2025-11-04-software-is-supply-constrained-for-now/

Community news section:

1. freeCodeCamp just published a course that will take you deep into the modern Kubernetes ecosystem. You'll implement advanced industry standards such as Gateway API for traffic management, CloudNativePG for managing PostgreSQL databases, and cert-manager for automated HTTPS security. By the end of the course, you'll have the confidence to manage production-grade environments. (6 hour YouTube course): https://www.freecodecamp.org/news/master-kubernetes-through-production-ready-practice/

2. freeCodeCamp also published a comprehensive Notion course. It's not just a fancy notebook – you can use it as a full-blown operating system. You can code along at home and build your own task manager using Notion's “Software Legos” philosophy. Then you'll integrate your project with mail and calendar functionality, dashboards, and other advanced features. (12 hour YouTube course): https://www.freecodecamp.org/news/lean-notion-in-12-hours/

3. Learn how to guide agents to write secure code using a robust framework of rules and tests. Software engineer and recent podcast guest Sumit Saha shares his step-by-step process by building a Node.js shopping cart app using an agent. Instead of just using naive “one-shot” prompts, he leverages server-side validation and test-driven development. Well worth reading. (20 minute read): https://www.freecodecamp.org/news/how-to-guide-ai-with-rules-and-tests/

4. Learn the Python you need to know to build your own agents. This course starts by teaching you core Python syntax and best practices before moving on to NumPy, Pandas, and SQL. With these tools in your toolbelt, you can manage the data that fuels modern AI tools. (6 hour YouTube course): https://www.freecodecamp.org/news/learn-python-and-build-autonomous-agents/

5. Today's song of the week is from the UK band Unkle – 2003's hypnotic ballad "What Are You to Me?". The groove is mostly heald together by accoustic guitar and piano on top of layers of synth bass and breakbeats. We also get some Soulful, laid back feel from the featured vocalist, Joel Cadbury of the band South. This song just melts into the background. I think you're going to like it. https://www.youtube.com/watch?v=lgrN2uQKq9k

## Содержание

### [0:00](https://www.youtube.com/watch?v=hP931079TMw) Segment 1 (00:00 - 05:00)

Welcome back to the Free Code Camp podcast. I'm Quincy Lson, teacher and founder of Free Code Camp. And today I'm interviewing Justin Surles. He's a software engineer who co-founded a software agency 15 years ago, retired at age 38, moved to Japan, and is now writing more software than ever with his fleet of agents. Before we hear from him, I have some cool community news. Free Co just published a free six-hour course that is going to take you deep into the Kubernetes ecosystem. You'll implement advanced industry standards such as gateway API for traffic management, native uh cloudnative PG for Postgress if you want to manage your Postgress database and C manager for automating your HTTPS security. By the end of this course, you'll have the confidence to manage production grade environments. It's a six-hour course on the free code camp YouTube channel. Check it out after you finish listening to this podcast. We also published a comprehensive notion course. It's not just a fancy notebook. You can use Notion as a full-blown operating system. You can code along with this course at home and build your own task manager using Notion's software Lego's philosophy. Then you'll integrate your project with mail and calendar functionality, dashboards, and other advanced features. 12-hour course on the free code camp YouTube channel. We also publish this tutorial. Learn how to guide agents to write secure code using a robust framework of rules and tests. Software engineer and recent free co podcast guest Schumit Shaha shares his step-by-step process of building a no. js shopping cart app using an agent. Instead of just naive oneshotting with prompts, he leverages serverside validation and test-driven development to build out a robust tool. This is well worth reading and it's not that long of a read. It's about 20 minutes. Check it out. and free code camp also just published a new course that will teach you the Python that you need to know in order to be able to build your own agents. This course starts by teaching you Python syntax and best practices before moving on to popular libraries like NumPy, Pandas, and of course, you're going to get some SQL as well. With these tools in your tool belt, you can manage the data that fuels modern AI tools. That's a six-hour course on the free Coke YouTube channel. This week's song of the week, I love this band, Uncle from the UK. their 2003 hypnotic ballad, What Are You To Me? The groove is mostly held together by acoustic guitar and piano on top of layers of synth, bass, and breakbeats. We also get some soulful laidback feel from the featured vocalist Joel Cadbury from the band South. This song just melts into the background, and I think you're going to dig it. Support for this podcast comes from 10,321 kind folks who donate to our charity each month. Join them and support our mission at donate. freecodecamp. org. You can also pick up a freecode shirt and rep the community with pride. 20 bucks with free shipping anywhere in the US. Go to shop. freeccoamp. org. Now for the interview. What you've all been waiting for. Justin Surles. He's a software engineer who co-founded an agency 15 years ago and he has so much insight that he's going to share here. Uh these days he's gone from solving problems for clients to solving problems for himself and building open-source software often using emerging tools like agents. He says he's getting way more done now than ever before. We talk about how software development is ceasing to be a team sport. How now it is more about individual devs working directly for the people paying them. So clients freelancing uh we talk about how verifiability is everything whether it's agents contributing to your codebase or humans and how someone just now entering the field can use emerging tools to get an edge over even more experienced developers. Note that I do not censor this podcast at all. If you have young children around, you may want to consider putting on some headphones because Justin has some pretty blunt language here. Justin Sirills, welcome to the Free Code Camp podcast. — Hello. How much does it cost? — Free Code Camp is free. Great question. — Cool. Nice. — Uh we are a 5123 public charity and uh we are completely supported by the good folks who support Free Code Camp through a monthly donation. So I want to jump straight to LLM tools. Uh you have said that anyone tracking all this AI stuff and wondering where the job loss is, the clock actually started in February 2025 when Claude Code came out. uh versus three years earlier when GitHub Copilot came out. Uh and can you explain what you mean by that and why that three-year time difference is so important when thinking about the nature of the labor market in terms of developers. — Yeah. So, you know, I think that there's like when you look at just the programming market, uh we have experienced a lot of slowdown since 22 23. We've uh experienced a lot of

### [5:00](https://www.youtube.com/watch?v=hP931079TMw&t=300s) Segment 2 (05:00 - 10:00)

layoffs. Some of those layoffs have been, you know, a AI in scare quotes has been used as a justification by executives for those layoffs because it's what the market wants to hear, right? Like they wanted to they wanted to see a pound of flesh regardless, but to say it's because oh well, all of these efficiencies through this new magical technology. And so there's a lot of narratives that have formed over the course of several years now. And many of us, whether you stand on the side of I'm really excited about all these AI tools or you're terrified of them or you are in you deny that they have any utility whatsoever, those narratives have been baked in the cake for several years now, right? And I would say as somebody who started a screencast series in like early 2023 that was like me fighting with spicy autocomplete version of GitHub copilot uh and who today I write a probably 3% of my code by using you know cloud codec cli uh the difference between what quote unquote AI meant as a programmer prior to the introduction of terminal based editors and some people might point to cursor but really like cursor's yolo mode even back then didn't really work that well and what I'm really talking about here is like tell an agent what you want let it rip and not have to worry or sweat so much about the details of the code itself um you know to varying degrees we can but point being like cloud code came out the end of February of this year and it only really got good with the introduction of like sonnet 37 which I I think that if I remember it's like May time frame. I had a dip in the summer where like it just like lost its [ __ ] mind in July and August. Uh so I noped out and switched to codeex used that for a few months but like now these things are like they're starting to the models LLMs haven't gotten a lot smarter but they kind of haven't needed to because like the Chrome around these tools has gotten increasingly more sophisticated as we introduce hooks and then skills and now it's like um what I'm working on now is tools to increase the verifiability of that what I'm asking for is actually what is produced so that I don't have to go in and like rerun a command uh or inspect things manually myself in between each run. And so like now we're in this like window, right, where it's like we're talking about a universe of less than 12 months. And yet like I think a lot of people are walking around with a lot of confidence that they know exactly what this means. Like they know, you know, market's doomed. They're just like, you know, they're drawing a line that goes up into the right or down into the right and they're saying either like we're never going to have programmers again or all this stuff is going to explode because like the fundamental economics of AI companies don't make sense. So, it's all going to explode and we're going to go back to the old good old days any day now, right? Like people are walking around like they're really sure what the future holds. And I'm just here to say like yo like whatever your kind of priors are about AI, I think we all need to have a little bit more humility and we need to take a fresh look at what these tools are actually capable of. And if regardless of what you've used in the past, like I would encourage every programmer to really try to use something like clawed code in anger, meaning like force it to write 100% of everything. Just like I used to teach TDD, right? Like and I' I'd coach teams on it. And I'd say, "Look, you're not an expert yet. You're a beginner. You don't know. " Like if you if you let yourself say things like, "Oh, this doesn't need a test or that's, you know, like I sure I should test drive this kind of thing, but not this kind of thing. " I would say like you don't have the expertise yet to know, right? Like you should test drive 100% of all your code. And only after you've done that successfully, first of all, it's going to teach you how to like test a lot of hard to test things, but second, it's going to uh, you know, give you the reps and the wisdom to know really, are you saying that this doesn't need to be tested because it's truly incidental or are you saying it because it got too hard, right? I would say the same thing to anyone who's trying to pick up something like or understand something like clawed code be like no like if it's not working for you if you're finding oh it [ __ ] up and so you go back into your editor and you start to fix stuff like no like you figure out how to like you know beat the tool into submission to get it to do the outcome that you want and sure if after several weeks of doing that you try your best you try all these different tricks and you still have a bad outcome or you know fine but but downloading it for an afternoon and having it like you know fall on its face 20 minutes in that doesn't count. So all that to say like we're in a really new space and if you haven't really if you're a programmer and you haven't really grappled with your identity in the last call at I don't know nine months or so uh you're you don't know anything about AI is probably what I'd say. — All right. Yeah. So, a lot of people are probably going to be listening and

### [10:00](https://www.youtube.com/watch?v=hP931079TMw&t=600s) Segment 3 (10:00 - 15:00)

some of them may have done what you recommended uh and like experimented a little bit uh dabbled with these tools, but they didn't force themselves to spend, you know, months and months using these tools to actually get good at bending them to their will and as such they may underappreciate how powerful the tools are. That seems to be what you're saying. And also there's just a huge degree of uncertainty and a lot of the people who are talking about these tools don't really know what's going on with them. Uh they don't have the context because they haven't spent a huge amount of time using them to actually build software. — And when you're trying to talk about like like what even is AI, right? Like people might even point to the introduction of cloud code. And so there was a blog post in September by a fellow named Mike Judge saying like, "Hey, where's all the shovelware? if AI is so great, where is all this? You know, I'm not seeing new uh projects announced on a uh hacker news. I'm not seeing new GitHub and he had some graphs. And my answer then because I wrote a response post on my blog like that day or the next day after that blog post blew up is like first of all, you know, when we look at this, yes, the timeline started really recently. Like so he'd written that in September. like we're talking about a universe of five months and you expect all of this stuff to like actually go through the process. Person has an idea and they go through all the way to release like give it some more time right if the timeline starts later. But the second thing is I think that like the general mindset of programmers as techies like oh they're early adopters like they're always the leading edge we use a lot of language like that around programmers and that's like not my experience at all. programmers are super [ __ ] sticks in the mud. Like, they're the ones who aren't updating to Mac OS Tahoe because the icons are all [ __ ] Like, no, it's I just had one of my Vision Pro just restarted because the battery doesn't work. Like like we're the crotchd ones. Um, and so when you talk about like for example, when Node. js JS came out 2009 I want to say Ryan Dollar releases uh I remember in I was at a conference code mash in Ohio in like 2010 and somebody's doing a little kind of like a hallway chat about Node. js JS and all these cool uses and I was like no that sounds dumb and then in 2011 by then I'd started using it and I started doing it for like scaffolding of front-end tools and it was probably another two and a half three solid years before I had a client even let us use it in production because they had a Redhead Enterprise Linux you know like the the timeline of the like normal people normal developers weren't using NodeJS until like create react app came out. And so we look at that and that's like six years later, seven years later. And so for this expectation that everyone's using cloud code the minute it came out because it's been on the front page of hacker news is like you're talking about like maybe 5% of developers globally have touched it. We're not talking about a lot of people. Most people are not terminably online. Most people are clocking in and out of their jobs and they're just doing the same [ __ ] that they've been doing every day. And so like if if we're already and as of yesterday Jared Santo put out a blog post being like actually you're starting to see this graph hockey stick the number of new project announcements like you are starting to see a ton of call it slop call it additional capacity like like the code is coming and that's coming from such a small minority of developers out there that like once this becomes a standard issue tool that everyone is using and 10 years from now however long it takes we're going to be seeing orders of magnitude new software like created and so that's why I think that there's just a little bit too much premature you know declaration of failure or success by people who who've got entrenched interests as to like what is AI and what does it mean for the future — well yeah like a vast majority of developers I would categorize as like anti- LLM generated code because it does hallucinate there are shortcomings of it, but they don't necessarily understand that there are dramatic, you know, benefits to just having the sheer amount of speed and volume that you can get from it once you figure out how to work around those constraints of having to, you know, test it more rigorously, which I know you mentioned TDD and uh test-driven development and your uh efforts to try to teach people like, hey, you like a lot of times people are just refusing to write tests because it's hard, not because there's it's not important to write a test for this particular uh functionality or something like that, right? So, uh a lot of what you're doing, I guess, through your blog and your podcast, uh not that you're like a paid industry representative or anything like that, is just going out and like kind of waking people up to the fact that like, okay, this is we're very new in this. Yes. Like a lot of the

### [15:00](https://www.youtube.com/watch?v=hP931079TMw&t=900s) Segment 4 (15:00 - 20:00)

things that people are saying on, you know, our programming, the subreddit, uh great subreddit, but very strong anti LLM bias that I've observed there. like they publish some you know low sample size study of like people trying to use coding and that gets shoots to the top because it's critical of these tools for example. So it's like confirmation bias. People want to believe that these tools are not all that great. So they don't have to bother learning them uh and spend all this hard you know time this process essentially retraining themselves how they do software development. It's and it does kind of uh jive with like your explanation of TDD. TDD was like this new paradigm of writing software by writing the test first uh and figuring out what the functionality you want and then testing it and then once you've got that in place then writing the code to get the tests to pass. Um, and a lot of people advocated that and they got things done uh in a more robust way than the old way, which was trying to like, okay, quick, I need to submit this PR, like I got to come up with a couple tests so they don't reject my PR, right? I don't know if that's a fair uh description of TDD and your efforts to try to get people to adopt it because the agency you ran was literally called Test Double and it was focused on like testing and maintainability, right? What I think a lot of people mistake and when at test double when recruiting people uh you know I think we're at like 150 developers now and I one of the things I'm proudest about Test Double is how uh successful the company's been at attracting and retaining a particular kind of person because we did attract a lot of people a lot of recruits who would hear me talk about testing or TDD or agile and they would think, "Okay, this guy gets it. He's got like exactly the correct formula for like how to write good software and he agrees with me about everything. " And they had a kind of fixed mindset about what that meant. And like they, you know, and I would categorize these as people who liked coding for coding's sake or testing for testing's sake. And for me, they were a means to an ends. And so what we try to do in our interviews is like filter out people who were just there because they wanted to be adherence to some zealous religious cause uh and instead find ourselves attracted to people who are like no like what I want to deliver as a programmer is business value for a client or for a company to either make or save them money. And uh if I know if I believe that like currently the best way to arrive at a good outcome is to measure twice and cut once by doing something like test-driven development, then that's the thing I'm going to do. And now so why did Justin care a lot about testing and teach a lot of people about that? Because at the time that was the best tool available to do it and because at the end of the day most software sucks, doesn't do what it's supposed to do. uh the rework and the amount of like you know failed projects is so massive that if you can it really came down to verifiability. Do I have an automated fast and rapid feedback loop that verifies that the code does what it supposed to do? And that's why today even though I'm not practicing TDD by hand I'm not writing code by hand. pretty much all of my thinking about claude code or codeci and my disappointment with the kind of west coast python datadriven developers who don't know any of this [ __ ] who are building these tools at open AAI and at anthropic. Uh I I'm eminently disappointed by everyone in the AI sphere who who fancies themselves an engineer or toolmaker because like none of them came from the Midwest United States where like we had the bluecollar agile and software craftsmanship movement that really cared about like how to generate ROI for blue chip enterprise organizations because if if the AI tools were built by people more like us verifiability refor reinforcement learning like how to actually we would never have developed something like a clawed code that just says jobs done and be like, "Okay, did you run the tests? " No. Did you write any new tests? No. Like all of this would have started with okay nothing happens. Nothing happens at all until like when the programmer asks for something to be built or specifies it. Like job one is figure out like how do I write a failing test that would successfully articulate like and express the the requirement or the need and how do I encode that in a way that's really fast to make sure that it never breaks in the future. And the tools aren't there yet. And the tools really like like if you're using these AI tools like I am every day. uh it they put all of that work of how to verify that things are actually working on the individual developer to beat something like clawed code into submission. So for me when you talk about TDD and went on a you know little bit of a rant there it's about right now the most interesting problem in AI is not the capacity and the

### [20:00](https://www.youtube.com/watch?v=hP931079TMw&t=1200s) Segment 5 (20:00 - 25:00)

relentlessness with which these a agents can produce stuff. It's about the wisdom and the rigor that individual practitioners need to take to try to enforce verifiability that they're actually doing what they're supposed to be doing. And maybe the tools will get better at some someday on that front, but right now that's where the heat is. — Okay. So trying to enforce verifiability like these are fundamentally you know stochastic tools and you want some degree of determinism like uh you want bounds essentially so that it doesn't go off and think that it should delete production database and stuff like you hear all these horror stories of people who I guess are giving the LM tools like the agents way more credit than they are due. But it sounds like you approach these tools like they're extremely dumb. and you're constantly thinking about, okay, how do I prevent it from doing dumb things? — This comes naturally to me because I also treat people assume people are really [ __ ] dumb because like I just I'm a low trust individual, you know? I don't trust myself because like the stupidest person on the planet is me yesterday. Like whenever I think of past me like oh like me on a project three years ago, I was like, "Oh, I was so dumb. " Right? whenever I looking at a CL like at a colleague or uh somebody is it's sort of like how this zero trust security model of like how we should think about security where no good secure system should rely on trust should rely on uh encryption or you know be verifiability. I'm that way with like people, right? So when you say LLMs hallucinate and that makes them bad. It's like people [ __ ] hallucinate. Like they don't they make mistakes all the time. And the difference with LLMs is like they do the same stuff. They're just so fast and they can do it so relentlessly. Like now we have to just either way whether we're dealing with a human developer or a an automaton that just produces static output like we need a way to harness that and formalize it. So like yes, a conversation with chat GPT can just kind of go off into nonsense uh you know uh uh uh a world where we're just in fantasy land. So can a conversation with clawed code. The difference is like software can be deterministic. So get it to write the software that's deterministic and the most important piece of software that you're going to write is like the thing that verifies that like the thing that's being built is actually working so that you don't need to come back and like and and find yourself just walking in circles over and over again which is really quickly where you end up in version two of any app that's built with a coding agent. — Yeah. And to be 100% clear that most important part of software is the tests is what you seem to be saying like that if you don't have like a proper robust test suite where you've really thought through all the different corner cases then you're taking a huge risk really trying to build anything yourself or relying on agents trying to build stuff for you. — It's a it one way to look at it right is a theory of constraints. And if we think about speed as being how long does it take, how much wall time or calendar days elapse between where we are today and a finished product. Having deterministic and like solid like the ability to take forward steps where you can confidently know you're never going to have like a backslide requires you to go like slow, right? You talked about it earlier. It's sort of like the slow makes smooth and smooth makes fast uh mindset. Like if we're working with an agent and let's say uh it's building really good code, but like it's and I I'm struggling with this right now, just to be honest. Like this stuff's a lot easier to verify if it's just stock standard web applications, but I'm building like an iOS 26 app in liquid glass where like not even Apple has good examples of like what good code looks like and where even like you know APIs are broken and the simulator is really hard to like automate, right? And then the simulator can't even do everything and so like the devices are absolutely not automatable. And so like how do I get clawed code to make sure that the button feels good, right? Like I can't. So, right now I'm constrained. Like, what's the theory of constraints say about like my current iOS 26 development cycle? At least when it comes to UI, it's like, all right, well, I got to click build and run. I got to wait some number of seconds to like launch it in the app, and then I got to click all these things in the right order, and then I got to make a judgment, and then I have to go do the extra work of articulating or documenting or screenshotting that back to Cloud Code and feeding it back in. So, this is like a real pain point for me right now. And so I'm losing sleep over how do I how do how do I close the loop remove myself from that loop because the relentlessness and the speed with which something like a clawed code a coding agent uh can can continue

### [25:00](https://www.youtube.com/watch?v=hP931079TMw&t=1500s) Segment 6 (25:00 - 30:00)

to iterate without me there as long as I'm that constraint like the number of calendar days that are going to elapse are really long and so that's why I keep coming back to like verifiability is like once you have that rigorous verification loop, then you can remove the human from it and then you can actually take advantage of the speed of these things and not be thinking about the hallucination stuff so much or caring about it so to speak, — right? So, you know, humans have always been kind of a constraint in programming. And it sounds like to the extent that uh you can remove yourself just like with traditional software. Uh if I want to go like browse a bunch of websites and like get data from them, that takes forever because I'm manually having to click and I'm waiting for all the latency of the connection and all that stuff. And uh if I write a scraper to go and grab all that data for all those data for me, then it can just be scaled horizontally to the number of machines that I have and uh you know it can things can move very quickly when they're on silicon time instead of on carbon time. — Absolutely. It's and and what I think is really interesting about this current moment is that if you are a developer who is who bases your activities from some kind of first principles, you know, what you just said is an expression of Larry Wall's uh you know the three virtues of a programmer. Larry Wall wrote Pearl back in the day is laziness is one of them, right? Like I'm lazy. I don't want to have to go to this morning. What was I doing? I had Claude code actually go to the Stripe uh manage membership pages for Kogi and OpenAI, download all my 2025 invoices, build me a table of summing up all of the ex like how much I paid and then zipping up all those PDFs into a zip and then adding them to my spreadsheet for my expense reporting for Sorl LLC. You know, like it did that for me. that I that was a chore that I've been putting off for two weeks cuz I didn't want to have to click that many times and I'm just having it do it for me, right? And so like this is just the same sort of expression as like 10 years ago when I wrote uh finance, which is like a little scraper web app thing that would go and go to all of my bank statements and kind of aggregate all of our personal finances and budget and credit cards and all that stuff into a nice chart. uh is the same sort of thing as if you'd been uh my grandfather, my late grandfather had a TI994A that he stood in line at a Radio Shack for in 1981 to buy on launch day. And he was still to the point like to the day he died uh in the 2010s was still using that to write little programs for his home mortgage, you know, uh amortization schedule and stuff. Like it's the same impulse that's been there all along. and that and the the tools change but fundamentally the principles don't. — Okay. So laziness as a virtue uh from Larry Wall essentially um if you have the inclination to figure out a way to not have to do work and to use to offload that work to the machines that's a virtue in the world of programming even though laziness you know sloth was one of the seven deadly sins times have changed and that's actually going to help you do a lot more over the long run. Uh, I want to talk a little bit about the perception of these tools. Let's concede that these tools are going to continue to get better. Not because LLMs are fundamentally going to get better, but because the Chrome around them, as you called it, is going to continue to get better. We're going to get like reasoning models that are basically using the same LLMs, but they're just getting way better at figuring out how to rein in the LLM's worst tendency and keep it on track or have it build upon its own work and things like that. uh and certainly there are probably a lot of equivalents with uh LLM code generation that we could talk about but when people hear about these things uh a quote that you have is some people see a bomb I see a rocket ship a lot of people are scared but in the same amount of I guess explosive material you can build a bomb or rocket that directs it and launches something you know up to escape velocity right like uh what would you say to somebody who's currently looking at these LLM tools like they're a bomb to help them see how maybe this could serve as a rocket ship instead. — I think one of the things that's most interesting right now is that you can look at a team of people who like really get along. They've been working really well together for years. maybe they're um mixist staff and principal and senior and junior developers and they all kind of work the same way and they all seem to have the same opinions about everything. But then this AI thing comes along and 70% of everyone hates it for different stated reasons. You know, they hallucinate or like you know it's uh it's going to destroy the planet or whatever the reason is. And 30% of people are just like the happiest they've ever been as developers. They're showing up to stand up every day and they're like, "Look at these 20 things I built yesterday. " And they're

### [30:00](https://www.youtube.com/watch?v=hP931079TMw&t=1800s) Segment 7 (30:00 - 35:00)

they're they're uh it's like they found religion. And why is it that we are suddenly getting carved through like as an industry in this new novel way where it's like yeah like when I was talking joking about like Midwest versus coastal developers, right? where like the Midwestern ones tended to be more bought into the slow code movement of the 2000s and 2010s. Uh whereas on the coast the money was a lot easier and you didn't have to prove things worked in order to like you know get a fat payday. Like that organizing principle was geographic. It was also kind of temperamental in terms of who had it attracted. And here what we're finding is that the thing that divides people now in my opinion is a mix of how opinionated are you? Like do you have a theory of the case? Do you have an could you write an editorial about how you think software should be and ambitious? Like how ambitious are you to like how many ideas do you have? creative ideas of things you just want to force into existence out there. Um, you know, and for as a content creator, right, that's like how many blog posts would I want to write? How many podcasts record? How many open source libraries would I want to create? How many product ideas do I have that I wish I could make out there? Versus, you know, some people they they want the job to be a job. Maybe they have other priorities in their life. Maybe the family comes first or maybe they got other passions and they just want to be able to clock in at 9:00 and then clock out at 5:00 every day and be told these are the requirements and they want to just do the requirements and on any given team of you know I can think of staff level people right who some fall in that first bucket and second bucket and they both provide a great amount of value to their employer. What's changing now and why some of the some of these people in the latter category feel under threat is that if you show up to just fulfill requirements as stated and that and treat that as what the job is, the amount of value that you provide your employer is asmmptoically going to go to zero. When the order takers just become the agents and you like what provides business value is actually having that ambition. the creative idea of like what's next? How can I make it better? How can I get lazier? To take that previous example and and how do I articulate in a way and shape this tool in order to get better and better outcomes. And that's the new dividing line that I'm seeing between teams. And so that's why I say like, you know, if you're one of those ambitious people who just sees these things, they're like, "Holy [ __ ] look at all this stuff that I can build. I can finally do this. " and like why am I wasting time clicking around in my expense reporting when I could have it do this? Like if you're that kind of person, you see these things as like a rocket ship. Like I'm going to free up so much more time and then I can, you know, I can do that to go and spend time with my kids or I can spend it to go build more stuff. Or you see it as a bomb. like this is a this is an existential threat to my identity as a programmer. This is the thing that's going to like, you know, I'm I might not make it in the next round of layoffs, right? Or like how could I ever pass a job? like all the jobs are going away because no one wants to hire somebody without having these massively high expectations for their output. And I can't do that, right? That's not realistic. Uh and that's I think that's the cleavage that we should be talking about more explicitly. Whereas in the past it was sort of considered improper to be like, well, you know, Dave over here is really ambitious, but Ross over here really is kind of just an order taker. — Yeah. So to some extent, this isn't really that different from like doctors who just want to have a job and they don't want to go start their own practice and they're beholden to the hospital system as a result. They're kind of like the air quotes order takers in this example. Uh or uh musicians who just want to play music but don't want to like go and play the Tik Tok game for all its toxicity. Like the game has fundamentally changed seems to be what you're arguing. And the people who merely just view this as a job and they've got their skills and they the the craftsman uh like because the game has changed those people need to change with it or they are going to find themselves out of job is what you would argue. At the end of the day, like if you like coding for the sake of coding, that's awesome. And I like it too. And it's great to have a hobby. And if you if as a hobby you do the advent of code, you know, that's a popular thing. Every December people have these coding quizzes. They do the coding quizzes. It's a fun mental challenge. It's kind of like doing Sudoku but really hard. You know, that's pretty cool. Uh that's an individual pursuit and a passion that I have that that probably a lot of people listening to this have. Now if you want to make a six-f figure salary

### [35:00](https://www.youtube.com/watch?v=hP931079TMw&t=2100s) Segment 8 (35:00 - 40:00)

that's a different question because now there's somebody else involved in this equation and that's the person paying your paychecks and you have to and have always had to demonstrate a certain amount of business value to the business. ideally more like a greater you should be either saving them or making them more money than they are paying you. Otherwise, it's pretty foolish that they're paying you so much. And developers had a pretty plum gig in the 2010s because the money was coming easily with the zero interest rate phenomenon. And because there was just these exits that people were experiencing were so high, the developer suddenly went from being a middle-ass job to a firmly upper middle class job as a lot of other professions were suffering. And so I think we all are walking around now being like, well being a programmer, you know, how many people who went through free code camp got there because somebody in their life told them that to escape their, you know, career pro prospects they need to learn to code. It's not something inherent about coders being valuable. You got to think about it in terms of what's the value that I'm providing my employer. And if you just aren't wired to think that way or you know, for whatever reason, you know, aren't comfortable or don't want to have to think that way about your job, then yeah, you are under threat. But if you if you really want to be valuable to the people around you, which is kind of how I'm always oriented is if I'm going to spend my time on this, I want to be useful. Then the amount of value that you can create as a programmer has never been greater than it is right now. Yeah. Uh, and that's a great way to think about I think just the nature of reality like everybody's essentially singing for their supper or like trying to go and like get the calories and bring them back to their family, right? So that everybody can eat and somebody has to give you those calories, right? Or you have to, you know, get your salt from the Roman, you know, army and then go sell that salt and turn that into uh, you know, bread for your kids or something like that, right? Like it's always at the end of the day what value is created and then the value is somehow get given back to you for you creating value and that may not be equitable. Uh I mean like uh there are plenty of jobs where you could look at the employment situation as extremely exploitative but programmers I think they've already demonstrated a certain degree of curiosity grit by being able to get good at communicating with machines which are notoriously stubborn uh through the pro process of programming which itself is pretty it's a pretty difficult skill to acquire. So given that they should be able to also be flexible. And what you seem to be saying is there are still a lot of people who maybe have forgotten that flexibility. Maybe they've lost that neuroplasticity or maybe they've just gotten accustomed to not having to work so hard and think so hard. Uh but those people are going to need to adapt is what you're saying if they wish to continue. Even in prior eras, we would always be talking about how change is constant in this industry. Maybe it's, you know, in the past it was new programming languages, uh, new operating systems, new paradigms like as we moved further and further up the stack, right? Like where 30 years ago, 40 years ago, you might have been expected to be writing an assembly and then in C and then you go up and now it's like the gang of four book in the '9s. Like that was fundamentally it was really where it kind of introduced the idea of design patterns. go back and read that book. And it's really about like desktop publishing software, right? And like user interfaces and like what was demanded of software at that level of abstraction is very different than what was demanded uh 1015 years later when the book got popular in terms of like web development. Right now you're uh building a Ruby on Rails app. Like some of those lessons are useful, but like the really thing the thing that's like fundamental is here here's a way to look at it. And I I come back to this often because I think this visual is really helpful especially when you're trying to conceptualize the skill of programming and like the action of it is I think about um a pyramid where at the bottom layer are your values, right? Like values that are like eternal. They don't change things like integrity or curiosity, right? Or um this desire to be valuable to others and to serve others. like those are fundamental like deep-seated human things. And then the next layer up in the pyramid are your principles. You know, these are things that I fundamentally like when it they tend not to change very often and like within a domain. You know, things like verifiability for me like I spoke to earlier is definitely one that I have in software, right? is like I don't want to waste my time writing software that I can't verify works and I understand that like fast feedback loops another principle of mine is like I can go faster and everything works out better if I'm able to like shorten the iteration time and do the you know

### [40:00](https://www.youtube.com/watch?v=hP931079TMw&t=2400s) Segment 9 (40:00 - 45:00)

minimize the uh number of pipeline stages in in how I develop software and then like the very top of this pyramid are the actual like activities that we're doing like the an activity right there that affects both of is built on both those principles is test-driven development. So I'm doing test-driven development, but like the top of the pyramid changes over time. It changes with context all the time. It's changing now in terms of what I'm doing. And I think a lot of people miss this because it's like an iceberg and like all we see from other people is that top of the pyramid is what activities are they doing? And we infer their principles and their values from it. But if we don't think about our own pyramid, what are our own values, principles and conceptualize those as being the longer term more stable things and then hold a little bit less firmly the activities the particular oh well like I want to be like Justin cuz he does TDD and then when Justin stops doing TDD like that person has a crisis of conscious you know like that's that no like what I care about was verifiability and we just never had that conversation because you didn't get to see that. You just saw me writing a lot of tests. — Okay. Awesome. That that's helpful. So just to recapitulate what you said, you the pyramid top part which is the implementation details of how you get things done uh is more visible than the underlying principles and underlying that the human values. Um, and because those ones at the top are visible, then it you don't get the full picture when you're just looking at somebody's obvious like visible actions. What is actually motivating those? But the underlying motivation for most people is going to be, hey, I want to get money so I can pay for my house and make sure my kids have plenty to eat and things like that, right? uh at the end of the day like Freo camp has been an extremely pragmatic organization in that we've always focused on skills that we think can help people improve their lot in life essentially that they can help people like change from like okay my dad was a plumber and I want to be a developer and then maybe my kid can be like a scientist or something like that right like kind of moving up the proverbial uh social or perceived value or prestige in society However you want to think about this for free coamp the main operative question is like what should we advise people to do like how can we responsibly guide their scarce time and resource like and help them get skills to pay the proverbial bills. Um, so one of the questions I have for you is I've talked with lots of people over the years on this podcast who have different degrees of like the amount that you should mix AI tools into your like learning regiment, if you will. At what point should you introduce them? How should you go about it? Let's talk with the current state of tools. What proportion of time do you think somebody who is, let's say they're working as like a truck driver, right? they are just getting into the field with uh minimal knowledge of how computers work of how software gets written like what percentage of their time and at what point should they earnestly adopt for example using agents to write their code for them. So in terms of percentage breakdown for somebody who's just starting out this might be a little bit unusual. I would say you should spend a 100% of your time focused on the fundamentals and the learning and the principles and the and the foundational pieces of like what is soft what even is software how does it work how is good code structured and organized and then also 100% of your time engaging with AI agents like for me the question feels like a false dichotomy because it would be like saying like what percentage of your time should you be like learning computer science concepts and what percentage of your time should you be learning running your code editor. Like it's those are orthogonal to me because I think like frankly having a coding agent or having an LLM with tools like the ability to uh um search the web and then like you know compress and like understand a whole lot of uh you know books worth of data in order to like you know craft a reply that is personally tailored just to your context in this moment. That is the best education system that's ever existed. That is the best. If you are again we talk about like people who lean forward versus lean back with AI tools. If you're the more ambitiously oriented, forward-leaning person, like you should look at this current lay of the land and be like, I don't have the patience to go to a four-year computer science program that's going to teach me just stock, slow lectures of just generic computer science stuff over a syllabus over a period of months when I could just like, you know, have a personalized instructor that can move as fast as me, who can

### [45:00](https://www.youtube.com/watch?v=hP931079TMw&t=2700s) Segment 10 (45:00 - 50:00)

work 24 hours a day and build me customtailored, you know, programming exercises that Like I don't know, say you're a big Harry Potter fan or something, you could say like, "All right, build me like based on you're just teaching me about red blacklists or whatever like or red black trees like I want to learn how to program these this data structure like give me an example from the Harry Potter universe that like you know does this and sells original and it'll make some [ __ ] up, right? " Like like it can create engaging and individualized educational content for you. And these agents are all customizable. Like when I was talking about verifiability earlier, I'm talking about a combination of git hooks, claude skills, and claw. md or the you know there are equivalents for codeex cli and gemini and so forth. Like you can use all of those same basic primitives as a beginner developer to be like hey maybe your cloud MD says whoa whoa pump the brakes. I'm a new developer and I'm actually not here to ship software. I am here to learn and so I don't want you to do anything without explaining every single line of code. So like we're going to go through and interactively commit and like you know and you can steer it towards being the kind of agent that you need for your personal development. And so for that reason I'd be like yes 100% to both. Okay. But like let's say there there's a risk that people just become overly dependent on these tools and don't necessarily develop the critical thinking facilities for themselves. — Yeah. There's a risk that there's a risk that you drive a car and you just like refuse to ever use the brakes. Like you might just like run off a cliff. Like that is a risk. But like using your — It's a lot easier when you're driving a car to know like hey I'm going too fast. I need to slow down. Then I mean people are like literally committing suicide from having these lengthy discussions with these tools and essentially misunderstanding the nature of reality, misunderstanding because they've gone so far down rabbit hole. If you can listen to this podcast and understand what I'm saying and have metacognition to know that like yeah sometimes you're gonna like two I've been doing this for over 20 years and two three days ago I was at my wits end because I was using clawed code to try to like you know build something and I was being lazy and I was like just rapid firing like and then do this and then it starts making a mess and then I start getting into this loop of like hey this was a regression god damn it like go back and now I'm getting frustrated and like I caught myself, right? And I was like, "Oh, you know what? This is no longer serving the purpose it's supposed to for me. I'm going to pause. I'm going to call this afternoon, you know, a learning opportunity for like being a little bit more rigorous and diligent and disciplined about my approach to this and I'm going to do it differently. " If you're a beginner and you have that same sort of ability to metacognate as a human and that same self-awareness, you're going to be fine. And if you don't, you are [ __ ] my friend. Like that's it. That's it's not about tools. It's about your capability and capacity as a human being. — I mean I understand that but to some extent like a lot of people learn critical thinking and learn problem solving skills in the process of programming and you're somebody who's been programming I don't know like 20 plus years. Uh you've taught people programming. You've built like a successful software development con consultancy products all this stuff. like you have the benefit of having decades of you know experience with these types of systems understanding the fundamentals. I don't know if you got a CS degree but you actually have a whole lot of what a truck driver would not necessarily have and uh the amount of rigor that the human brain develops by working with machines and trying to convince them to do this very specific thing and communicate this very specific thing. I mean code is essentially like an extremely detailed spec. Uh and you have to have this mental rigor that most human beings do not have. Like the average politician, the average um you know person out there who's really doing anything, the people who are working at McDonald's, places like that, like they wouldn't necessarily have that degree of rigor. Um and I guess I just want to kind of mediate or moderate what you're saying a little bit with you are like a kind of a consumate professional already like you are already in like the probably top 1 percentile of developers. Again you can disagree with that if you want to be humble but uh it's easy for you to say that is what people are thinking when they're listening to this. It's easy for you to say you can recognize that you're spiraling or you're wasting your time or that you need to pump the proverbial brakes. — That's all completely 100% valid and I appreciate it. But I think it fundamentally comes down to where does critical thinking come from and where

### [50:00](https://www.youtube.com/watch?v=hP931079TMw&t=3000s) Segment 11 (50:00 - 55:00)

does that sort of like you know that divide of like what like a human temperament come from? Because frankly, you know, uh you take the example of somebody learning today with the benefit of all of these tools and you compare it to my experience learning how to program. I think my very first experience trying to learn how to program was I was at a Borders bookstore in Michigan as a fifth, sixth, seventh grader and it was like learn Sam's learn C++ in 24 hours and it was absolutely terrible or 24 day I one of those and it was absolutely terrible experience. that made me feel really stupid and I gave up for a couple years. Uh my computer science degree, uh I do have one and I went to college and spent four years feeling just stupid as [ __ ] Every single class, BC student, tried really hard. I'd be up in the lab with like two liters of Mountain Dew and because the doors locked, I'd have to prop it open, use that bathroom. I was on the third floor of the only person in the the math and CS building and I' I'd be there and I'd work uh you know didn't have the tooling to like help. We had like literally a three- ring binder with like the full Java 1. 3 or whatever it was API written and you have to flip through it. You know, I had no support. had no one, you know, I guess I could use Alta Vista or Google or whatever to like figure out like some sort of like way to navigate my Linux command, but like I wasted those four years. I graduated and my counselor who was like one of the CS professors, his advice to me was literally Justin, you're really smart. You've got a like you're a great critical thinker. You're a good communicator. Maybe you should think about a profession that doesn't have you programming. Like that's what I'm talking about, man. Like when Yes, you're right. Some people lack the rigor and ambition and I find that has absolutely zero [ __ ] correlation with how much like professional programming experience they have. It is okay who you are and how you're wired. — Okay. So like let's say hypothetically somebody just isn't wired air quotes wired that way. Like I happen to believe that, you know, — nurture is way more important than nature in the state of like how people turn out, right? And like some social scientist who has, you know, a bunch of like paperwork can tell me otherwise. But that's my current thinking. Like if you take just uh some person who has zero background in you know math, programming, computer science but they are innately curious and interesting and stuff like yeah they're going to probably succeed just like uh you know people that grew up in like some village where they didn't even have like an internet connection and stuff like that. They were able to ultimately get like an internet connection and catch up with everybody just because that's how they're wired and stuff. But let let's take somebody who uh just like was kind of mediocre like me. Like I was pretty mediocre up into my 20s and I didn't really do much that was that interesting or and I didn't have those skills. How would you go about getting those skills and like not necessarily skills but like those properties of curiosity and like uh being determined to get things done right and not settling for like mediocre uh you know like a mediocre project like that obsessive drive to make sure that it the program does exactly what you want it to do and not just saying ah that's good enough. I think you're 100% right first of all because I when I say like you know like some people are this way and some people are that way I'm talking about like how are they showing up in the moment but like fundamentally I believe pretty much every single human you know who's blessed with good health right um mental and physical well-being has the capability to express themselves as the kind of critical thinker that I'm describing and in early Um, you know, anyone listening to this, no one's going to listen to this and think like, "Oh, yeah, I'm one of the people who lacks self-awareness, right? Like, everyone is the hero of their own story. " And so, I'm sure everyone listening to this is like, "Yes, I am like, you know, I've got self-awareness. I've got like, you know, like I like I am dialed in. " You're listening to a goddamn podcast on how to be better as a programmer. So, like for even if you got low self-esteem or something, you're doing something right. Like when I was starting out my consulting career, I saw lots of kinds of consultants out there. And the consultants that I respected and sought out as mentors and then I tried to emulate myself were the ones you'd walk into a room and like as a consultant, you're always coming into a room and it's the reason you're there is something's not going right. They want to make something better. They see this team and they're like, "This team is failing, right? " and you look at it there and like the easiest thing to do as a consultant is to walk in and be like, "Oh, that's cuz they're all [ __ ] numb skulls. They're all stupid and they're bad and you should replace them, right? " Uh or, you know, maybe one notch above that in the ladder of unhelpful consultant things you could do is like, "All right, well, the reason that they're they're suffering is they haven't done my

### [55:00](https://www.youtube.com/watch?v=hP931079TMw&t=3300s) Segment 12 (55:00 - 60:00)

patented process of like how to be a better person and a better programmer and a better teammate and like you need my training and you go through my training to act just like me and then they'll be all better, right? " But like every time I walked into a room, what I would see is, okay, so there's these five people here, like they're not outputting what the company wants. Structurally, they exist in an environment and uh they're operating under incentives. And like those structural things that are surrounding them probably to your point about nurture probably explain way more about like why they're not succeeding or meeting the business's expectations than anything that's intrinsic to them as humans. Because like you start peeling back the layers of the onion and you realize, oh actually like you are actively incentivizing them not to create the database columns they need because you've given them 15 sheets of like forms to fill out and then they got to go argue with the meanest people in your organization, the DBAs to get those things approved. And then they got to go if they have anything on that list then they got to go to a quarterly change management meeting where they got to talk to the head of change management whose job it is to prevent change in your organization. Like, so no wonder they like keep their heads down and mostly don't do new stuff because you've built a system that makes them not want to do that. Or maybe you have them working in an office space that's really loud and noisy and has light or super bright fluorescent lights or maybe the uh you know the coffee sucks, right? Like all of these things or you know the hours they work or their commutes are terrible like all of these things are factors that affect us as humans and they affect how we show up in different environments. And so like I'm all about explaining like like only as an absolute last resort as a consultant would I ever like let myself even think it was something innate about the individual that's preventing them from being successful. It's always something around and and like something systemically something like like in the structure of like where they're working. But like fundamentally at this point in the game, you know, it not to say it's like no longer a team sport, but we're what we're seeing now is that the capabilities of AI are so so phenomenal for accelerating the individual pursuits of individual developers that if you are on a team and you are for whatever structural or environmental or personal reason not able to show up to your job with that level of curiosity, ambition, creativity, and a desire to like create business value for your employer. I would say you probably have about 9 months to figure it out or like cut your fixed expenses and prepare for unemployment. Okay. So, question for people who are not yet in that cubicle at that office where their environment sucks. It's got bad coffee. It's got a bad commute. It's got a manager who's overly invasive. Like, they're not even there yet. They are on the outside trying to get some form of sustenance through software development. — Yeah. — Like, how would you proceed? Let's say uh you do have some fundamental skills because you've been working through FRCO camp for like a year or two. You've built a bunch of projects. Maybe you've gotten a couple client uh projects and things like that. How would you approach um that nine-month timeline, right, before you become a member of uh I think what I've heard called as like the permanent economic underclass of people that just don't have soluble skills and uh you know, you're not able to get in. Uh what advice would you have to those people that are still trying to get in? Honestly, if you've got a full-time job right now and it's draining you to the extent that I'm describing or trying to paint a picture of, you're in trouble because you probably lack the mental freshness and the zest and the zeal to approach programming right now with the level of creativity and the level of new energy and like interest in learning and trying new things, right, that you need to be successful in this moment. I would much rather be somebody who is on the outside frankly who's got some time and some passion and some drive to be in a learner's mindset right now. So like in terms of advice what I would say is take advantage of this precious time and I'm not talking about nine months for you. There's no deadline as long as you're able to afford food and an internet connection and some computer and you know like it could be three years from now could be 10 years from now. However long it takes you, the orientation in my mind should be you you've learned these fundamentals, you have these tools available to you. Like if the way to make money as a programmer is to generate value for somebody, then start building valuable things. And if it's just you right now and you've built a whole bunch of hobby

### [1:00:00](https://www.youtube.com/watch?v=hP931079TMw&t=3600s) Segment 13 (60:00 - 65:00)

projects through free code camps like resources uh and you've uh you know maybe uh done some sort of passion projects to kind of like you know prove that you can build a real functioning web application then great. Now ask yourself and this is literally what I'm doing at my stage in my career right now is the same thing. It's like what are the problems in my life that are presenting the most friction or the uh what's an opportunity for me to build some software to like make my life a little bit easier and then build that and use these tools use what you've learned to build things that are of tremendous value to you and don't let go don't stop working on them until you've seen them through to completion and you do that once guess what that is exactly the same loop that like a business needs when a business needs custom software. And something that I learned a long time ago that blew my mind is that most programmers like and Ruby on Rails was where I cut my teeth as a consultant and built a lot of like because it was a productivityoriented framework makes it easy to start and build new applications. All the applications look really conventional. You know, it has a whole lot of stuff about it that is beneficial towards the orientation of I build apps from cradle to grave relatively uh quickly without a lot of rework. 99% maybe not 99% quite a high number of Ruby on Rails developers have actually never typed the CLI command Rails space new space name of project right like I was doing it probably once a week here's a random idea on a Friday like oh yeah build a little thing like this right and so I w I was used to that loop of building new things and shipping new things within like I had a one weekend rule where by the end of the weekend I'm shipping it and it's going on the internet one way or another, right? Um, and I'd look around and I talk to other Rails developers and like, oh, I'd never actually started a new project before because I just showed up and this project already existed and you know, I just add another new model and another new controller to our hundreds of models and our thousands of controllers and that's been my entire relationship with the framework. If you're learning right now and you're out there, it's like build the new thing. Build it to be valuable. See it through to completion. And once you've done that sort of like what we used to call the software development life cycle, like once you've done that for yourself on your on something that you really care about and you've felt that like the wind at your back, now just the next step is get in touch. find a way talk to somebody who's got a business that needs software and congratulations. Like that's basically you've built a consulting company that can provide real business value and the reason you can you know lean on your own experience to know like you have the capability to do it because you did it for yourself and I now when you go up against the person who's got 10 years, 15 years, 20 years of professional software development experience, maybe they [ __ ] worked at Google or Meta or whatever, you know, you're actually going to be able to out compete those people because you're going to be able to actually serve somebody and demonstrate as an individual how you're going to generate ROI for business. Whereas the person who's just been sort of in like middle management or in like maybe even a principal level developer at Netflix, right, who and all they've done is make the CDN go like marginally faster. You take that fish out of water and you put them in the same context, they're not going to be able to build a custom software or build a project cradle to grave for like a real use in the world. And so that's why like in your truck driving example like that person has tremendous capability right now to actually out compete the people who are in professional programming jobs even if they've got the CS degree and gobs of of years of experience. — Okay. So if I'm understanding you I'm going to repeat some of the things you said. Uh start building valuable things. Uh go from cradle to grave. uh like with go through the entire software development life cycle which could be condensed to a single weekend which sounds like a constraint that you placed on yourself to make sure that you had like closure and that you actually got things done in time because of course — I had work on Monday. — Yeah. I mean that's a great constraint. Uh and one thing that you said that was very hardening is when you're going up against 10 somebody with 10 years of experience if they're at like a big tech company they're probably extremely specialized. I remember talking to somebody who their entire job was just to manage kind of like the YAML file. I think it was like one of the YAML files for like a CDN, right? Like that was their job at Cloudflare was they just literally had a single file and they made sure everything worked in that file. And that's how specialized these jobs can get at big tech companies where you got, you know, potentially tens of thousands of developers — and that person might have made 400 500 grand a year in total comp. Who knows, right? That's — it's it's totally irrelevant to the actual value that you can provide outside the context of the big companies. — Do you think that those types of jobs are going to go away to an extent and give way to more generalist developers

### [1:05:00](https://www.youtube.com/watch?v=hP931079TMw&t=3900s) Segment 14 (65:00 - 70:00)

who can do the entire software development life cycle themselves? — Yes. I mean, I wrote a post uh last July called full breadth developers and uh I don't know if you meant to team me up as a segue to discuss that, but frankly like please I worry more about the people who are hyper specialized just like the people who like coding for the sake of coding who just want to be handed a spec and then they push out a serlet or something. Those people are going to be in trouble, right? like like it's you can yeah it sounds condescending because it it's meant to be uh who are order takers here who just like want to have a transactional relationship with the work and then they want to be able to clock out and not think about it very hard uh and or think about the broader context of that work in a similar way here uh if you are just trying to be a lost cog in a gigantic machine yes like these tools the more humanlike that they're able to act and the more tools that we're able to equip to a clawed code, right? Or to an agent. God forbid we get to the point where like we've got biped robots running these things, but like the every few months they they you saw the clawbot, moltbot, open claw thing now where it's like people are running a Mac Mini with a you know essentially an agent that's got access to their messages and their mail. Yes, there's lots of security concerns, but like now it's like the entire, you know, uh say you're an executive assistant who works remotely. It's like, uhoh, like this is the entire kind of domain of what I can do. That's a lot like if you just fill particular cog rolls of transactional, you know, features on behalf of like a bigger system, you're in trouble. But if you are breath first and you think in terms of what's the full life cycle of like you know like in terms of a company I was talking about like startups and businesses and you know just building a whole project just by yourself earlier but if you just think in terms of uh let's say you work in a medium or a large business like you want to sit somewhere like every company makes money right like like in some way or other like there's somebody paying the company money and then that money trickles down one way or another to to beneficiaries like shareholders. So like me in the form of salary like the best seat in the house as a as an employee, as somebody involved in that business is going to be in the line of sight between where the dollars come in and out. Like what is the thing that's actually getting people to pay that company money and how is that like value ultimately disseminated out from the company? And what I think people are finding is that, you know, as a lot of these companies, like I learned from looking at the Decoder podcast feed yesterday that DocYsine has 7,000 employees. There's no earthly way that all 7,000 of those employees are like really vital to how that business makes money. Like if I was in that organization, I might feel under threat if I was in an ancillary like location in it. But if I was in like you know the ion cannon of like how people who just need a stupid contract signed like I if I wanted if okay so if I wanted one job at docyign I want to be the one in charge of like the on click handler on the JavaScript of when you click the signature box because that's the one thing that has to [ __ ] work there right like I don't want to be you know the YAML configurator for their CDN so to speak to your point Quincy cuz like Yes, that role is probably going to get pushed aside as businesses increasingly are going to focus on what's my core competency and what is secondary and the secondary stuff is going to get pushed because the secondary stuff you can accept good enough you can accept barely works right but the core competency the thing that's your differentiator that really makes you money you may I mean I wish that companies would demand excellence and in that regard but it has to at least be enough to get convince somebody to pay the money for. And those are the areas that like, you know, a a human who is a generalist who's able to like pick their head up and look above the keyboard and monitor level and think about the bigger context here of how humans are actually going to want to part with their dollars in order to get this value. Those people are going to be much better situated. — Awesome. So, we've talked a lot about how getting into software development, like the individual devs, their strategy, but it can be helpful to empathize with managers and how they think about software as well. And you've kind of already gone in that direction. You were a manager for like two decades basically running this uh consultancy, this uh software development firm working with clients. Um, and I really want to understand how managers think about software. So

### [1:10:00](https://www.youtube.com/watch?v=hP931079TMw&t=4200s) Segment 15 (70:00 - 75:00)

you said something that I thought was pretty profound and interesting. You said businesses don't understand software and they see it as a big black hole that cost them a lot of money. How do you think this is informing how a lot of like less technical people who are in managerial roles think about AI tooling? And of course, they want the uh they want the panacea. Oh, we don't have to have developers on staff anymore, right? Like I don't know how where what your thoughts on that are as far as like whether managers truly believe that or whether that might actually become a future that comes to pass. But can you talk about like that cost center mindset that most managers have regarding software? Put yourself in the shoes of somebody who maybe you own a small business or you work in an organization where like your job is maybe you work in a uh a business unit for like an online learning platform and uh your job is to like maybe it's really I'm just making [ __ ] up, right? like maybe you really successful in K12 and you're you've been hired now as like the business development for figuring out how to sell into uh vocational schools and community colleges the same sort of learning management system. So it's like a brand new you know uh uh business domain a new kind of like uh addressable market a new place to sell into. So, you got to think about those sorts of things, right? Like hire a salesforce and figure out how to like how like a marketing strategy, but like the system that's designed for K12 is surely going to have to change for the needs of a commuter college, right? And uh maybe the business is like, "All right, well, here's your budget and here's your timeline and here's our engineering team. You got to go work with them to figure it out. " I guarantee you that nontechnical business manager is going to have a lot more fun engaging with everybody else other than that engineering team. Why? Because traditionally the engineering team and this partly comes from the, you know, in the olden days maybe it was because they're more technical and so you can get away with being, you know, uh demonstrating the sort of antisocial behavior of uh the stereotypical nerd computery type, right? because you have you have everyone at anformational disadvantage. There's an asymmetry to being the engineer because you receive your instructions in English and then you do some blackbox stuff that nobody else can understand like a sear and then you spit back out like working software that they can engage in. And so because of that power dynamic, engineering organizations, whether they're an external agency like me as a software consultancy or you as an internal like, you know, software developer, you can kind of stiff arm people. You can say, "Oh, no. You can't tell us how long this is going to take. We tell you how long this work's going to take. " And so you put the the business manager maybe who's under a lot of traditional business constraints. I've got this budget and this timeline, right? and I know that the software has to change in this certain amount of way. So you go to the development team, engineers and you're like, "All right, so we need the software to do this and it's got to be done by and then like you get cut off immediately and be told by the developers like oh no, we estimate the work and then it just takes what it takes because we have a certain level of quality that we need, right? " Like and then you know you go along with what they say. You're like, "Okay, oh well the system needs to do this. Oh well, it can't do that. " and like maybe it really can't do that or maybe the developer is just being lazy and not thinking of a creative third approach that would work for everyone. Whatever it is, this sort of um uh very uh uh not uh adversarial relationship that developers have had as they throw stuff over have stuff thrown over the fence at them for all these different reasons, right? Like it like most managers have had adversarial relationships I'm not experienced. This is what it was like agile was all about like truly collaborative you know constructive positive sum relationships with developers and so like yeah if you could just replace that or externalize it or minimize that or kind of like you know like I know people who are middle managers who are non-technical who are now like building proofs of concept and building MVPs that yeah they got security issues yeah they're not perfect but like they're giving a glimpse to a world of like now they can feel agency in their roles Right. So, as a as a consultant, I so often it it's been literally two days since a founder asked me, "Okay, so like this piece of software I've shown you the click-through demo, the Figma prototype. How long is it going to take and how much money cost to build it? " And the answer to that question is like in his case between $50,000 and $5 million. and like figuring out how to narrow that range just requires a lot of collaborative exercises and hard decisions and a certain amount of time and uncertainty to like come and arrive at that answer.

### [1:15:00](https://www.youtube.com/watch?v=hP931079TMw&t=4500s) Segment 16 (75:00 - 80:00)

And so like if I'm you know my advice to anyone who's in a management role right now is to understand that like these tools will help you both understand a little bit more about software uh build a little bit of it yourself and kind of like touch the flame and figure out a little bit like be able to at least like check some of the things that you're hearing from developers. Hey, my developers just said all this stuff. Is that realistic or is that [ __ ] given these sets of constraints, right? Like have some little like a little bit more traction on your own part. But separate from that like I would really encourage you to find developers who are interested these full breadth developers who are actually interested in conversing with you and like you know like meeting you halfway and on the collaboration front who want to understand your business problems as much as you want to understand like the software that you're going to get out the other end who can work with you to arrive at answers like how long is it going to take and how much cost. Uh and so when you look at these organizations who in the postcoid hiring spree ballooned into 2,000 3,000 4,000 5,000 human organizations like you can't organize a business whether it's divisional or functional without having like you know like a lot of siloing and a lot of handoff bureaucracy. And as we experience a lot of layoffs and there's a certain scrainess and people like me are going on the internet saying teams are over. You know, oneman shows are are the future for developing software thanks to the productivity provided by agents. I think that if I'm a manager, I'd be like find the really good, you know, collaborative developer who I want to work with who can provide the capacity maybe thanks to all this AI stuff. But at the end of the day, what I'm what I used to be looking for was like a department that I that was like to minimize the amount of risk of that my project was going to fail. Going forward, if I was like, you know, a non-technical business person, I'd be looking for a partner, a technical co-founder, somebody that I could trust, build a relationship with, and then build a firm foundation as peers. uh as opposed to going down this traditional route of and that's why I think a lot of like legacy companies that have you know business people based like like part of the organization and then a very large engineering organization they're going to be outflanked and outmoded pretty quickly by much smaller and scrappier outfits just like we saw in the 2010s and a smaller scale it's just like now it's going to go from being you know the order of magnitude of 20,000 people at IB M to 2,000 people at GitHub to like you know may maybe two rungs down from to 20 people organizations that are able to outflank something that big. Yeah, that's a great uh example of how like the organizations have historically been shrinking because you had IBM and then that shrink and you've got like you know defense contractors and all these huge organizations developing sophisticated systems and then the tools improve uh for example we get git for example which is a huge improvement uh we get high level scripting languages things like that and then suddenly the teams can contract dramatically in size and then you know uh so you think that phenomenon is going to keep happening and it might go down to like 20 person companies. And I guess my question is and I think the question that a lot of people are going to have is does the world have enough room for enough products and brands and uh consultancies and all these different like can the ecosystem actually accommodate 30 million professional developers when you know everything is essentially so bulcanized. I'm not sure what the right word to use but like compartmentalized where like hey we build this very specific thing that does and everybody integrates with us. Uh like what do you think is going to happen to the total volume of employment let's say like right now there are approximately 30 million people on earth whose sustenance comes from shipping software. Uh and — yeah go ahead. I think that's a super interesting question if you're a macroeconomic professor or if you work at like the Federal Reserve and you're trying to figure out like are we in a recession or if you're thinking about like total employment as a politician like those are all really like they yes the answer to that question is very important as an individual I don't think it matters at all I think as an individual if you exhibit the kind of traits being described today and deploy the tools stay in stay stay stay stay where the heat is by focusing how to deploy those as a means towards building valuable things for people I think you're going to be fine right I think if ultimately like like scrainess and a desire to serve other people and provide value to them has throughout every era of humanity like uh resulted in pretty good

### [1:20:00](https://www.youtube.com/watch?v=hP931079TMw&t=4800s) Segment 17 (80:00 - 85:00)

outcomes for people um and So, so getting lost in the weeds of like, well, you know, do we have more programmers than we need? Yeah, probably. Like, what's the number? I don't really care. It doesn't really matter to me because the people who are doing the right things with the right motivation and the right orientation, they're going to be the absolute last on the chopping block. And that matters more, right, than uh understanding like, well, is the industry shrinking and so forth. Awesome. Well, uh I don't know if there's anything else you wanted to talk about. Like I have so many questions, but we're already at approximately 80 minutes into the interview and we've already covered so much ground. Um is there anything you'd like to talk about like in the vein? Like have I missed any major topics just on the scope of what we've been talking about because I don't want to branch off into a completely different area. And I want to remind everybody this is totally unedited. Like a lot of things that Justin's saying I may not fully agree with, but my goal is just to draw insight out of him and uh you know this is an uncensored like just his thoughts and I want to respect your thoughts and the learned experience and the lived experience that has led to you having kind of this worldview and uh it's very exciting I think for many people. It's also very scary uh like many kind of technological revolutions uh if you want to look at like LLM code generation and the ability for like semi-technical people to essentially create their own MVPs um and then minimum viable products and then be able to go to developers and say I want something like this and to push back right uh what you're talking about like the managers are much more empowered than they have ever been because the black box is a little bit more scrutinable than used to. — Yes. — Um, — yeah. Like are there other any I guess one question I have is any big developments that are likely to come out of this change dynamic between developers and the people who give developers money. I think uh it's true we have covered a lot of good ground today and uh you know if if any of your listeners want to hear me just uh give a stream of consciousness uh rant about this and other related topics um you can check out my solo podcast breaking change where that's kind of all you get and until my throat hurts and then I stop that's usually the end of the show. You know the answer to your question is everything is going to change and it is scary. Change is scary. You know what? Like I'm in addition to being a bad computer science student who went into it because I thought it would be hard and then I was proven right that it was too hard. Uh and I came out the other end having not learned nearly as much as my peers and then panicking that I wouldn't be able to find a job. I was also really scared of change. I still am. I'm a I'm a cozy cat, you know. I want to have the same routine. I want to be at home every day. Uh, I just found that I I knew deep down though that like change and embracing new opportunities and saying yes to stuff and forcing myself out of my comfort zone would probably make me more resilient and more likely to be successful and less likely to to be caught in a corner without a lot of options. And so when I was coming out of school, uh, you know, somebody suggested that I go into consulting and that sounded terrifying because every 3 months, every six months, I'd have a new client, new people to learn, new people to impress, to make like me. I'd have, you know, like brand new project. I'd be switching between programming stacks and and ecosystems all the time, going from like Java to like Cognos reporting to like database uh, you know, uh, administration stuff to, you know, And I'll be honest, the first several years of that, and I I can't believe my wife stayed with me through it because every single time I felt like I was drowning. I'd start a new project and I'd look around at the code and be like, I don't understand how all this works. any of understand. Like, they're telling me they want me to have stuff done by Friday. I don't even understand how like h how how to get this thing to run or build yet. I don't even know what we're doing here. And I'd feel just I' I'd get panicky, right? And it was a really hard few years for me, but almost like some sort of exposure therapy. I didn't come out the other end with a thicker skin. I came like a deeply understood um a deeply innate understanding that like change is actually safer that that

### [1:25:00](https://www.youtube.com/watch?v=hP931079TMw&t=5100s) Segment 18 (85:00 - 89:00)

the constant like and the continuous uh embrace of fail fast, you know, admit that you don't really know what you're doing. Uh understand that a lot of other people don't either. uh that every single one of those hard experiences can be feed into a pattern recognition machine of making you better at the job uh for the next goround. All of those things are really helpful and like you know like when uh the financial collapse happened shortly into my career I realized like actually the consultants were yes the first ones kicked out the door but they were also the first ones hired back and so like uh you know the the idea that you know your full-time job is where you're going to get your security from. No, the security comes from the resiliency of you as an individual and your ability to to, you know, show up and do the work uh at the moment that the company needs it on the terms that the company's willing to work with you on. And so when you say like, you know, what's this change going to look like and how are things going to change? I just want to like put out there like that change is coming. It is inevitable. It is going to be bigger than anything that we have experienced as an industry probably uh maybe ever but at least in 30 years and that is really scary. And so, so just like we talked about earlier, like you don't want to um settle for a role where you're kind of in a job where you just have to kind of like punch in, punch out and turn your brain off. Figuring out how to get excited about embracing that, you know, scary thing. You know, people ride roller coasters for a reason. You know, like I get sweaty palms. I live five minutes away from like Disney World and Universal Studios in Orlando, Florida. I've got like essentially unlimited passes to like, you know, like annual passes to go and ride stuff. I still get sweaty palms before every single ride. I'm still terrified and I force myself to go on it and I become a little bit more resilient every time. And so I think about that a lot in terms of yes, I think that the relationship is going to change and no one knows the future. So don't let anyone tell you how it's going to be because nobody knows. I don't know. I've got some ideas and I can extrapolate. Um, but that the the you talked about how things like these outcomes are not equitable. What this future's going to look like is not going to be evenly distributed for everybody. And the things that you're going to be asked to do as as a professional, as a as a programmer, the things that you're going to have to face in terms of what that change looks like for you is going to be different than what it looks like for the person next to you. And the the best thing that I can offer here is pay attention, embrace the change, understand it's going to be new, novel, hard, but like trust yourself to respond based on all of the things that you've built for yourself and the foundation that you have built. And that's why values and principles are so important and kind of like you know you understanding who the you is that's showing up to the thing and understand like no one has all the answers. Like that's the nice thing about change is like oh but I'm new here and I'm in my 40s and I'm just now starting out as a programmer and all these other people have been here so long. It's like yeah like those people have oified and calcified and like they to a certain extent now they have to break out of that. You have the plasticity and the the beginner's mindset to actually succeed and thrive in this novel landscape where other people are going to struggle. And so, so wherever you're at and however you come at this from, it's all about mindset and our willingness to push ourselves outside of our comfort zone. That's going to determine how well we adapt to that change. — Yeah, change is actually safer. Um, that that's pretty profound. I really appreciate you sharing your perspective and uh not pulling any punches. uh not sugar coating it for the folks tuning in that they've got a lot of work ahead of them and it's going to be novel work that uh there's no playbook that they can fall back on that all you know big changes are coming it's scary uh I really appreciate you taking the time come on the podcast Justin uh everybody be sure to check out uh the links in the show notes to learn more about Justin get more of his perspective it's been really helpful reading your blog and I've learned a lot from it And uh until next week everybody, happy coding. Thanks Quincy.

---
*Источник: https://ekstraktznaniy.ru/video/11059*