Developer Tea

1. Three Default Thinking Modes That Can Screw Up Your Planning and Vision

   November 5, 202617 minEpisode 1315Play next

   Your brain is constantly trying to simplify the world. It takes a snapshot of what it sees, builds a picture that makes sense, and then works from that picture. Most of the time this works well enough. But when …

   Show notes

   Your brain is constantly trying to simplify the world. It takes a snapshot of what it sees, builds a picture that makes sense, and then works from that picture. Most of the time this works well enough. But when we plan projects, set goals, or try to predict where something is headed, these default modes of thinking can lead us in the wrong direction. In today's episode, I cover three of these defaults: linear thinking, static thinking, and infinite or non-discrete thinking. I also talk about how they show up in your career and in the way engineering leaders set vision for their teams.

   • Static Thinking and the Snapshot Problem: We tend to fix our beliefs about people very quickly, which is why first impressions carry so much weight. If someone acts a certain way in one meeting, we assume that's how they act in every meeting. This is closely related to the fundamental attribution error, where we treat a person's behavior in one moment as a permanent part of who they are instead of a response to their environment.
   • Linear Thinking and Exponential Change: When something is changing, we assume it will keep changing at about the same rate. AI agents are a good counterexample. Research suggests their effectiveness roughly doubles on a timescale of a few months, and even if the exact numbers are off, the curve is exponential. That kind of growth is hard to picture intuitively, and it probably won't last forever. At some point it will likely level off into something closer to logarithmic.
   • Where Our Intuition Comes From: Nonlinear patterns are all around us in nature. Think about how quickly heat rises as you move your hand toward a fire, or how loudness changes as you get closer to a speaker. But our social lives mostly involve slow, roughly linear change, and over the course of human history our minds have adapted to that kind of linear model.
   • Your Career Isn't a Straight Line: Many of us expect our salary and growth to rise steadily, in steps, for our whole careers. That expectation often breaks down, especially later on, and it makes exponential income growth hard to even imagine.
   • Infinite Thinking and Missing Endpoints: We aren't naturally good at thinking in discrete stages. We rarely design our careers in phases or plan for how they end until those moments are right in front of us. Cultural habits like contributing to a retirement account do some of that planning for us almost by accident, but most areas of our lives get no such help.
   • Two Traps for Engineering Leaders: When setting direction for a team or department, leaders often fall into one of two traps. The first is a "forever vision," an unbounded picture of perfection that the org is supposed to chase. The second is purely linear planning, where you only do the next thing in front of you and never step back to look further ahead.
   • The Productive Middle: The most useful vision work usually happens on a timescale of months to years. That's harder than it sounds, because it calls for a concrete plan, a lot of saying no, and putting the pieces together in a discrete way that doesn't come naturally to us.
   • Episode Homework: Becoming aware of these defaults is the first step. Add linear, static, and infinite thinking to your planning checklist. Next time you set a goal or a vision, ask yourself which of these defaults might be shaping your picture of reality.

   📮 Ask a Question

   If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

   📮 Join the Discord

   If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

   🗞️ Subscribe to The Tea Break

   We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

   🧡 Leave a Review

   If you're enjoying the show and want to support the content head over to iTunes and leave a review!

2. Signs You May Have a Regressive Mindset

   October 24, 202617 minEpisode 1314Play next

   Keeping up has always been part of the job for software engineers, and with AI it's harder than ever. In this episode, I talk about two signals that you, your coworkers, or the people you manage might have a …

   Show notes

   Keeping up has always been part of the job for software engineers, and with AI it's harder than ever. In this episode, I talk about two signals that you, your coworkers, or the people you manage might have a regressive mindset, which shows up as quietly avoiding the learning you need to stay current.

   Keeping up has always been part of being a software engineer, and right now it's harder than ever. A lot of us are tired, skeptical, or just overwhelmed by the constant stream of AI news, and it's easy to slide into habits that slowly cut us off from new information. In today's episode, I talk about two signals to watch for in yourself, your coworkers, or your reports that point to a regressive mindset. That's a pattern of avoiding progress and learning, often without realizing you're doing it.

   • What a Regressive Mindset Actually Is: A progressive mindset doesn't require jumping on every new tool or throwing out your whole toolset. Constant upheaval isn't progress. What matters is that your understanding of the world keeps growing. The regressive mindset shows up as avoiding learning and leaning on defense mechanisms that shield you from more nuanced information.
   • Signal #1: Avoiding Information by Category: Watch for the moment you click away from an article or video just because it mentions AI or agents. You don't have to read everything, but if you're skipping things purely because of the subject, it's worth figuring out why. Fatigue might mean you need a break. Skepticism or discomfort is a different story.
   • The Ostrich Effect: Avoiding uncomfortable information is a lot like sticking your head in the sand. It feels protective, but over time it leaves you behind and out of touch with what it takes to stay competitive as the industry changes.
   • What Is Your Alternative Path?: If your plan is to keep avoiding this information, ask yourself honestly what that looks like a year or five years from now. I'd argue that avoiding it forever just isn't possible.
   • Signal #2: Tying a Concept to a Person: Many organizations have one or two people carrying the flag for AI adoption. If "the AI enthusiast" has become the whole of what that person means to you, you may be dismissing everything they say, even on topics that have nothing to do with agents.
   • The Flip Side and Fundamental Attribution Error: The same trap works in reverse. If you don't trust someone, you may throw out good information simply because they're the one bringing it. This is closely related to fundamental attribution error, where we explain someone's choices by who they are and judge the information by the messenger.
   • Episode Homework: This week, notice when you skip, dismiss, or tune out information. Ask yourself whether it's because of the topic or the person sharing it, and what your long-term alternative really is.

   📮 Ask a Question

   If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

   📮 Join the Discord

   If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

   🗞️ Subscribe to The Tea Break

   We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

   🧡 Leave a Review

   If you're enjoying the show and want to support the content head over to iTunes and leave a review!

3. How History Can Inform a Dynamic Understanding of Technological Revolutions Mirroring this Moment In Software Engineering

   September 30, 202617 minEpisode 1313Play next

   You're tired of hearing that you need to pick up AI, so today I'm not going to add to that pile. Instead, we'll look back at two moments in history that look a lot like this one: the arrival of Fortran in the …

   Show notes

   You're tired of hearing that you need to pick up AI, so today I'm not going to add to that pile. Instead, we'll look back at two moments in history that look a lot like this one: the arrival of Fortran in the 1950s, and the spread of autopilot in commercial aviation. Both show how new abstractions change the shape of our work without being purely good or purely bad.

   You've heard plenty of engineering leaders tell you to use more AI and more agents, often in a way that seems out of touch with your day-to-day work. I'm not going to add to that today. Instead, I want to share some history. If it feels like our industry is in a completely unique moment, it helps to look at earlier times that had a similar shape. In this episode, I look at the early skepticism around Fortran and the effects of autopilot on pilot skill. Then I explain why a dualistic "good or bad" view of AI leaves out most of what is actually happening.

   • Fortran and the Skeptics: In the 1950s, Fortran became widely known as the first high-level language, generating machine code so programmers didn't have to write it by hand. Skeptics doubted it. John von Neumann reportedly questioned why a serious scientific machine should do "clerical work," and many engineers didn't trust the generated code.
   • The Critics Were Partly Right: Early generated code wasn't very good and needed a lot of massaging. The Fortran team didn't go back to the old way. They put their effort into improving the new abstraction. The criticisms of the new tool became the fuel for making it better.
   • Autopilot and Cognitive Saturation: Commercial aviation is one of the safest forms of travel, and automation is a big reason why. Taking the manual work of flying off the pilot frees up mental capacity for radio calls, navigation math, and diagnosing problems. That adds a safety margin to every flight.
   • Children of the Magenta Line: Automation also brought a new risk. When pilots rely on GPS and autopilot, their manual flying skills can atrophy, and that matters in the rare cases where the automation fails. Something similar can happen to engineers who lean heavily on tools like Claude Code. Some might choose to work in their codebase without AI now and then, or practice LeetCode-style problems, just to keep those skills sharp.
   • Beware Dualistic Thinking: New technology rarely pushes things in only one direction. It brings new easier things and new harder things, more quality and new risks to quality, skill atrophy and room to focus on completely new problems. Whenever you catch yourself framing something as a simple good-or-bad duality, ask whether your brain is just trying to make it easier to understand.
   • A Warning for Team Leaders: It's a mistake to push agents into your existing workflow as if they were a simple accelerant. These tools change who is attracted to the work. They may draw in new people who were never interested in engineering before, and they may push away engineers who loved the job as it was five years ago.
   • Where This Is Probably Headed: If this follows the pattern of past technological revolutions, today's rapid pace will eventually level off. The unreliability we see now is likely to drive future reliability, and wider adoption tends to follow once tools stabilize. In the meantime, the fatigue is real, and it's worth paying attention to what it's doing to your mindset.
   • Episode Homework: Pick one opinion you hold about AI in your work. Ask yourself whether you've framed it as all good or all bad, then list the new risks and new opportunities it creates together.

   📮 Ask a Question

   If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

   📮 Join the Discord

   If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

   🗞️ Subscribe to The Tea Break

   We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

   🧡 Leave a Review

   If you're enjoying the show and want to support the content head over to iTunes and leave a review!

4. Fundamentals Will Help You Survive the Constant Acceleration of Software Engineering

   September 21, 202613 minEpisode 1311Play next

   Fundamentals get talked about constantly, but rarely defined. In this episode I dig into what a fundamental actually is — the building blocks, heuristics, and core characteristics that don't change — and why …

   Show notes

   Fundamentals get talked about constantly, but rarely defined. In this episode I dig into what a fundamental actually is — the building blocks, heuristics, and core characteristics that don't change — and why they matter more than ever in a profession where abstraction moves faster than almost anywhere else. If you feel like you can't keep up with every new framework, model, or tool release, the answer isn't to read faster. It's to step up a level.

   Fundamentals get talked about constantly — in sports, in hobbies, in software — but we rarely stop to define what one actually is. In today's episode, I unpack what makes something fundamental, why software engineering in particular buries its fundamentals under layer after layer of abstraction, and how principles-first thinking gives you a way to keep up with an industry that never stops moving without needing to learn every single new thing that ships.

   • What Actually Counts as a Fundamental: Fundamentals aren't rules — they're building blocks, behaviors, habit patterns, and heuristics. In basketball it's dribbling. In football it's blocking. In software it's readability, reliability, the setup-execute-teardown shape of a test, basic logic structures. In communication it's sender, receiver, feedback, and noise.
   • Why Software Abstracts Faster Than Almost Anything Else: Compare the practice of law, where the fundamentals look largely the same as they did fifty years ago, to software, where the work is symbolic at its core. We build symbols that mean something to humans but map down to a hard physical reality of flipped bits and moving electrons — and that symbolic nature is exactly what lets abstraction pile up so quickly.
   • The Rise of Linguistic Abstraction: Our abstractions have become increasingly language-shaped. Object, function, flow, durable object, mesh, graph — these are primitive ideas expressed as words, and understanding that shift explains a lot about how the industry actually progresses.
   • Abstractions Have Fundamentals Too: This is the key move. If you understand what makes Postgres a good fit — structured, predictable, relational data — you can evaluate any other relational database without learning it from scratch. Understand the primitives of NoSQL, or of an index lookup, and you no longer need to chase every implementation.
   • Decompose, Then Recompose: Principles-first thinking means breaking things down into their underlying characteristics so you can recombine them into solutions you care about. It works on databases, on business offerings, on competitive positioning — anywhere you'd otherwise be tempted to evaluate things as wholly separate.
   • Applying It to LLMs: When a new model drops from one provider or another, you don't need to start over. If you know which characteristics matter, you can see what changed here versus there — and treat them as variations on shared fundamentals rather than two entirely different things.
   • Practice vs. Analysis: There are two flavors here worth separating. Fundamentals in practice are the things you do repeatedly — giving feedback regularly, for example. Fundamentals as analysis is a way of looking at new technology and asking what core characteristics make it up. You want both: composable actions and composable tools.
   • Risk as a Fundamental: A live example from my current role — determining the right level of risk in a given scenario can't be a one-size-fits-all rule. It requires understanding the fundamental characteristics of the risk and reward you're accepting.
   • Episode Homework: Look at your work and ask where you're too deep in the weeds. Where are you thinking too granularly? Where are you missing the abstraction class — the consistent things shared across multiple iterations that you could be watching from a step away? That distance is what gives you leverage to notice when something fundamental actually changes.

   📮 Ask a Question

   If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

   📮 Join the Discord

   If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

   🗞️ Subscribe to The Tea Break

   We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

   🧡 Leave a Review

   If you're enjoying the show and want to support the content head over to iTunes and leave a review!

5. You Don't Learn Helplessness - You Learn Control

   September 5, 202616 minEpisode 1310Play next

   In 1967, a study on shock avoidance gave us "learned helplessness," and for nearly fifty years that was the prevailing explanation for why people give up. Then the original authors published a follow-up with …

   Show notes

   In 1967, a study on shock avoidance gave us "learned helplessness," and for nearly fifty years that was the prevailing explanation for why people give up. Then the original authors published a follow-up with brain scan data showing they had it backwards. We don't learn to be helpless — passivity is the default. What we learn is control. In today's episode, I explore what that reversal means for anyone facing a hard problem right now, and why a single small action can shift your entire orientation toward a challenge you haven't solved yet.

   • The Study That Reversed Itself: Understand how the 1967 learned helplessness research was revised roughly a decade ago by its own authors. The brain scan data showed the neurological change wasn't happening in the animals who gave up — it was happening in the ones who discovered their actions relieved the negative experience.
   • Passivity Is the Default, Not the Result: This is a fundamental shift. If helplessness were learned, we'd have a lot to reverse. But if passivity is simply where we start, then exerting control isn't undoing damage — it's activating something that was always available.
   • Your Action Doesn't Have to Match Your Problem: If you're out of work, you don't need to land a job to get the neurological realignment. The brain doesn't measure whether your control input is equal in magnitude to the thing making you feel helpless. A much smaller input does the work.
   • The Effect Persists: The research showed the behavioral change held up a week later, even against a new stressor that didn't pattern match the original. This isn't a momentary mood shift — it changes how you operate in the world.
   • Why "Action Orientation" Shows Up on Every Job Description: These words look like corporate filler until you see the neuroscience underneath them. Being proactive isn't a personality trait some people happen to have; it's a mode you can enter by noticing that your control has an impact.
   • Agency, Not Control: A careful distinction — this isn't about controlling outcomes. It's about your immediate environment. Set the temperature in your office. Clear your desk before you start work. Take back your calendar. Learn one thing you didn't know yesterday. Simple inputs where you can actually see the feedback.
   • Episode Homework: Find the area of your life or work that feels most chaotic right now. Don't try to fix it. Find one 5% improvement — a single step in the right direction — and take it. My bet is you'll feel the realignment before the problem is anywhere close to solved.

   📮 Ask a Question

   If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

   📮 Join the Discord

   If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

   🗞️ Subscribe to The Tea Break

   We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

   🧡 Leave a Review

   If you're enjoying the show and want to support the content head over to iTunes and leave a review!

6. Why Reducing Complexity Is A Sign of Seniority

   August 21, 202615 minEpisode 1308Play next

   As you grow as an engineer, something counterintuitive happens: the systems you build get simpler, not more complex. In this episode, I explore why senior engineers tend to collapse abstractions, accept certain …

   Show notes

   As you grow as an engineer, something counterintuitive happens: the systems you build get simpler, not more complex. In this episode, I explore why senior engineers tend to collapse abstractions, accept certain risks, and reduce the surface area they're responsible for — and what drives that shift underneath the surface. Understanding the reasons behind the trend is what lets you get there on purpose instead of waiting a decade to arrive there accidentally.

   Early in your career, output goes up fast. You're building more than ever, especially with AI in the mix, and a lot of what you build carries real complexity. But watch engineers who have been doing this a long time and you'll notice the opposite of what you'd expect: as their craft improves, their code, their architectures, and their systems get simpler. In today's episode, I dig into why that happens — and why chasing simplicity directly is less useful than understanding the underlying forces that produce it.

   • Simplicity Isn't the Goal — It's the Byproduct: Trying to "make things simpler" as a directive doesn't get you very far. If you can understand the core reasons complexity tends to fall as engineers mature, you can aim at those reasons instead and arrive at simplicity organically.
   • Why Simpler Code Pays Off: Simpler things are easier to understand, which means junior engineers can pick up your code, and future-you can return to a project you've long since left and still make sense of it. Adapting a simple thing is almost always easier than adapting a complex one.
   • The Pain of the Refactor Teaches You: A big part of this shift is scar tissue. Once you've lived through a massive refactor of a complex system, you start making different trade-offs — not from theory, but because you don't want to do that again.
   • Collapsing Vertical Abstractions: One of the most common refactors senior engineers reach for is collapsing long chains of abstraction that only ever get used in one place. It's abstraction without reuse, and it forces you to re-load enormous context just to make a small change.
   • Refining Your Risk Tolerance: Early on, we hedge against every possible risk. Later, we learn some risks are acceptable. Hedging is insurance, and sometimes it's very expensive insurance — paid in velocity, in onboarding difficulty, and in only being able to hire people who can hold all that complexity in their heads.
   • Knowing When to Break Best Practices: Maybe the best practice says abstract this. But if it isn't that hard to understand, and you can get most of the benefit through better naming or tighter scoping, the "correct" move might be the wrong one.
   • The Library Trap (In Both Directions): Seniors often take a trip through "let's not use external packages, we don't know what's in them" — and end up maintaining a shadow version of the thing they avoided. The more experienced call is often to accept the trade-off, adopt the well-documented dependency, and shrink what you are responsible for.
   • Reducing Surface Area Creates Focus: The through-line in all of these trade-offs is a shrinking surface area. Fewer things to maintain means more focus, and more focus means the things you are responsible for get done very well. It's an open question whether those behaviors follow seniority or cause it.
   • Drive to the Fundamentals: Think about a machine built from a ramp, a screw, a rubber band, and a motor. A more senior craftsperson recognizes the problem is fundamentally about conservation of energy, and reconfigures it down to two parts instead of eight. Slightly less efficient, maybe — but far less to teach, maintain, and break.
   • Episode Homework: Ask yourself: what am I responsible for right now that I could simplify? Where can I get away from the tactics and the surface-level stuff, get down to the core of the thing, and focus on doing that core really well?

   📮 Ask a Question

   If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

   📮 Join the Discord

   If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

   🗞️ Subscribe to The Tea Break

   We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

   🧡 Leave a Review

   If you're enjoying the show and want to support the content head over to iTunes and leave a review!

7. A Pragmatic Definition for Accountability

   August 14, 202623 minEpisode 1307Play next

   Accountability is a word you'll hear in your performance reviews, from your manager, and increasingly as you step into leadership. It's also one of the most abused and misunderstood concepts in our industry …

   Show notes

   Accountability is a word you'll hear in your performance reviews, from your manager, and increasingly as you step into leadership. It's also one of the most abused and misunderstood concepts in our industry. Many of us have a visceral, negative reaction to it—not because the concept is broken, but because the companies and people we've worked with have bastardized its meaning. In today's episode, I want to strip away the scary parts and offer you a pragmatic, working definition of accountability: one that a good engineer would actually invite rather than dread.

   What We Cover

   • The Bad Version of Accountability: Recognize the weaponized version of this word—being audited for things you didn't know you were responsible for, having unrealistic goals coerced onto you, and getting surprised at performance review time. This is how leaders shirk their real responsibility to grow people and create clarity, hiding hard performance conversations behind a single loaded term.
   • Accountability as Debugging: Shift the frame to how we think about software. When payroll software overpays your team by $100, you file a bug report—something deviated from the agreement about what should happen. The engineer who investigates is performing an accounting function, tracing a root cause. That's what being "held to account" really means: identifying what happened against a known standard.
   • The Churning Customer Problem: Understand what happens when the bug report never gets filed. A customer who hits something unexpected and just leaves never gives the company a chance to fix it. The same thing happens between you and your manager when the communication lines aren't established—you find out at review time instead of when it could have mattered.
   • Accountability at Every Step: In a healthy team, accountability isn't a once-a-year audit. It's continuous, giving you the ongoing opportunity to notice when something has deviated from the agreement—so you have something concrete to hold to account before it becomes a surprise.
   • Estimates vs. Commitments: Learn to separate the two things you say to a stakeholder. One is a forecast, a guess, a belief. The other is a commitment. Bad accountability coerces the estimate into a commitment it never was; too-soft accountability treats everything as up in the air. The healthiest organizations hold both: a high-confidence forecast, plus a commitment to do whatever is necessary if it looks like it won't get done.
   • Why Good Engineers Invite It: If you want to grow in your career and confront reality, you invite accountability and commitment inspection. Done well, it creates clarity of expectation for exactly how you're doing—which is a gift, not a threat.

   📮 Ask a Question

   If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

   📮 Join the Discord

   If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

   🗞️ Subscribe to The Tea Break

   We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

   🧡 Leave a Review

   If you're enjoying the show and want to support the content head over to iTunes and leave a review!

8. Using Substition to Make Decisions Simpler

   July 22, 202619 minEpisode 1306Play next

   There's a cognitive trick our brains play whenever we face a hard question or a difficult decision: we quietly swap the hard thing for something easier to answer. It's called substitution, and we do it …

   Show notes

   There's a cognitive trick our brains play whenever we face a hard question or a difficult decision: we quietly swap the hard thing for something easier to answer. It's called substitution, and we do it constantly — usually without noticing, and sometimes to our detriment. In today's episode, I make the case that you can take this same shortcut your brain already runs automatically and start using it intentionally to break decision paralysis and get moving.

   • The Substitution Heuristic: Understand the mental move at the heart of this episode — when "How are you?" becomes "Is there anything I urgently need to say?", your brain isn't being lazy, it's compressing. It runs a quick calculation: what's the downside of the substitute? Usually it's low, so the shortcut holds.
   • Code Review as Substitution: See why you almost never review a big PR line by line. "Was it tested? Does it follow our best practices? Does anything look obviously wrong?" are all stand-ins for the harder, mostly-unnecessary work of reading every line — and most of the time, they're enough.
   • Performance Reviews Are a Best Guess: Recognize that your rubrics, metrics, and frameworks are themselves substitutes. You can't deterministically rate a person on a scale, so every measure you use is an approximation of an immeasurable question: how much value is this person really generating, and where are they headed?
   • Turn the Trick Around on Purpose: Learn how to use substitution deliberately to defeat paralysis. Instead of "I'm deciding to leave my job and chase something new," substitute "I'm going to send an email." The weight of sending an email is tiny — and the dream job is just a series of small, iterative steps like that one.
   • Unbundle Your Big Decisions: Notice how we fuse trivial mechanical actions with heavy imagined meaning. Merging a branch isn't "declaring this production-ready and putting my name on the line" — it's moving bits into the cloud. Separate the labeling from the action and the action gets a lot less intimidating.
   • Lower Your Commitment Threshold: Swap "this code is great" for "I believe this code is shippable." Swap "this is the perfect hire" for "this is a good bet we can course-correct." The actions you take are identical — but the internal stakes, and the fear, drop dramatically.
   • Favor Reversible Moves: We consistently overestimate the risk of acting and underestimate the risk of doing nothing. Most decisions aren't permanent — you can roll back the deploy, divert from a bad hire, find an exit path. Look for the way back, and the decision gets easier to make.

   Episode Homework

   Next time you feel a big decision looming, break it into its most fundamental pieces. Ask: what am I actually doing here? What are the physical actions, the words, the mechanical steps? What's the true worst-case downside — and do I really have to attach all of my worth to it? You're likely already substituting easier questions without realizing it. This week, try doing it on purpose.

   📮 Ask a Question

   If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

   📮 Join the Discord

   If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

   🗞️ Subscribe to The Tea Break

   We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

   🧡 Leave a Review

   If you're enjoying the show and want to support the content head over to iTunes and leave a review!

9. Your Single Most Important Tool for Managing the Uneven Downsides of Risk

   July 10, 202625 minEpisode 1305Play next

   The skills you build and the tools you master matter, but they aren't your most important asset when things go wrong — and something eventually will. In this episode, I work through why our careers and lives …

   Show notes

   The skills you build and the tools you master matter, but they aren't your most important asset when things go wrong — and something eventually will. In this episode, I work through why our careers and lives are governed more by avoiding catastrophic downside than by chasing upside, and why the single best tool for surviving a bad event isn't testing, insurance, or money — it's genuine trust with the people around you.

   Here's a question to sit with: what is the most important tool you have as a software engineer and as a leader? Most of us reach for something technical, but the answer runs deeper than that. In this episode, I start with the humble premortem — the practice of assuming something has already gone wrong so we can pressure-test our plans — and use it to explore why so much of our work is really about predicting and mitigating risk. From there, I make the case that because we're all exposed to a far larger downside than upside on any given day, the tool that matters most is the one that helps you survive the bad event you couldn't prevent: your relationships with other people, built on real trust.

   • The Premortem as a Risk Lens: Learn why assuming failure ahead of time is such a useful counter to our natural optimism. Our plans quietly assume everything will go right, and a premortem forces us to inspect the gaps our best-laid plans never covered.
   • Life Is Already About Predicting Risk: Nearly every action we take — stepping forward, eating the sushi, merging into traffic — is a small bet on an outcome we can't prove in advance. Much of what we're managing isn't even our own behavior, but the risk other people put us through.
   • Why the Downside Dwarfs the Upside: On a typical Monday, your potential gain is limited, but your potential loss is not. A single catastrophic event — a breached customer, untested code shipped, an injury for an athlete — can undo far more than any single good action could ever build. This is why avoiding failure, not chasing brilliance, quietly shapes most successful careers.
   • Likelihood Times Impact: Even a one-in-a-hundred-days negative event can cost you your job or your company a fortune, while very few actions could produce a commensurate gain like doubling your salary. Our behavioral aversion to risk turns out to be rational.
   • Mitigate the Blast Radius, Not Just the Incidence: You can never be 100% certain a bad event won't happen. Good people who show up, stay reliable, and grow their skills still get laid off. So beyond reducing the likelihood of harm, you have to reduce its impact when it lands.
   • Relationships Are the Real Safety Net: The most important tool in your belt isn't technical — it's your relationships with other human beings. Invested in honestly, they pay you back forever, and they're the thing you fall back on when the negative event you tried to prevent happens anyway.
   • Trust Is the Core Currency: Genuine relationships require reality — real curiosity and care, not performed name-remembering, which people can see through. Trust compounds like an asset, while money spent to buy loyalty is gone the moment it's paid. When you hit a hard deadline or discover something's broken, a reservoir of trust is what lets people extend their best effort without you having to throw more money on the table.
   • Episode Homework: Go invest in your relationships regardless of your current risk profile. Spend extra time in your one-on-ones, with your team, and in your retros — and get curious about what the people around you actually want, instead of assuming you already know.

   📮 Ask a Question

   If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

   📮 Join the Discord

   If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

   🗞️ Subscribe to The Tea Break

   We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

   🧡 Leave a Review

   If you're enjoying the show and want to support the content head over to iTunes and leave a review!

10. Why Can't You Go Faster With AI? Focus on the Friction to Find Out

    June 24, 202619 minEpisode 1304Play next

    If you are a manager, a lead engineer, or anyone growing into more responsibility, this throwback episode is built for you. We keep hearing the same question, now louder than ever: "Why can't this go faster?" …

    Show notes

    If you are a manager, a lead engineer, or anyone growing into more responsibility, this throwback episode is built for you. We keep hearing the same question, now louder than ever: "Why can't this go faster?" AI and agentic coding have made the literal coding step dramatically cheaper, so product leaders reasonably expect the whole pipeline to speed up. But it hasn't—and in today's short, focused episode I explore why. The answer isn't new at all. It's the theory of constraints, and it has everything to do with friction you may not be looking at.

    • Speed Isn't the Story—Friction Is: When a fast component gets introduced into the pipeline, the instinct is to celebrate the velocity. But pay attention to what comes after. The real question is what keeps work from naturally flowing faster, and that lives in the friction, not the energy you're pouring in upfront.
    • The Universal Bottleneck: I rarely claim universal truths on this show, but here's one: anything that looks like a pipeline will have a bottleneck. If you're not paying attention to it, it doesn't matter how fast every other step gets. Faster coding just exposes where the constraint really sits.
    • The Two Places Friction Shows Up: For teams fully adopting agentic coding, the bottlenecks cluster in two spots—requirements gathering at the front, and verification, validation, and testing at the back. Rushed requirements upstream create even more painful rework downstream.
    • Why Agents Punish Vague Specs: Human engineers fill in gaps by being close to the work. Agents fill in gaps too, but sometimes incorrectly. If your requirements aren't detailed, the agent guesses, and you pay for it in review. Spend more time in the planning phase, not less.
    • The Foundation You Build On: Agents glob extra code onto a weak structure—unnecessary models, redundant endpoints, patterns that don't fit. A code base organized with clear conventions, good documentation in your CLAUDE.md or AGENTS.md, and dependable patterns lets the agent discover and extend rather than guess and hope.
    • Specification and Validation Are Bookends: Good requirements translate directly into good tests. Acceptance criteria on one end, changes in the middle, validation on the other end—directly connected. Poor specification sitting on a poor structure guarantees poor execution and poor validation.
    • Reframing Your Objections: Think scope creep is the problem? That's a requirements issue. Think you lack the talent? That's a foundation issue—because the engineer's job now is to cultivate the foundation so generated code enriches it instead of toppling it.

    This is not a new problem. We asked it of the internet, of web frameworks, of CSS. Now it's time to apply the same principles to agentic velocity: look at your requirements, your foundation, and your validation. Somewhere in those three is your bottleneck. I guarantee it.

    📮 Ask a Question

    If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

    📮 Join the Discord

    If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

    🗞️ Subscribe to The Tea Break

    We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

    🧡 Leave a Review

    If you're enjoying the show and want to support the content head over to iTunes and leave a review!

11. Software Engineering Principles That Still Hold Up in an Agentic World - Old Lessons Made New

    June 18, 202631 minEpisode 1303Play next

    The skills problem isn't going anywhere — it's just wearing new clothes. In this episode, I unpack how the lessons we learned decades ago (limiting work in progress, the theory of constraints, test-driven …

    Show notes

    The skills problem isn't going anywhere — it's just wearing new clothes. In this episode, I unpack how the lessons we learned decades ago (limiting work in progress, the theory of constraints, test-driven development) are coming roaring back as the fundamentals that will carry you through the agentic shift. The bottleneck has moved, and knowing where it went changes how you should work.

    A lot of what we're learning about building with agentic tooling isn't new at all — it's a re-emphasis on lessons software engineers learned twenty years ago, just arriving in a new form. In today's episode, I walk through why the fundamentals are becoming more important than ever, why so many of us feel scattered despite having the most powerful tooling we've ever had, and where the real bottleneck in software delivery has quietly moved. My goal isn't to convince you that your job is now babysitting AI — it's to show you which parts of the work are still squarely yours, and how older principles can make you faster and more confident right now.

    • Limiting Work in Progress Is Back: Just because you can spin up fifty agents doesn't mean you should split your focus across fifty things. Orchestrated fan-outs are powerful, but a human juggling agents across hiring, on-call, and a project all at once still pays the same old context-switching tax — and the quality drops while the speed never improves.
    • Work Deeper, Not Wider: Instead of spreading yourself shallowly across more tickets, run multiple sessions on the same domain. Write a competing or adversarial version that critiques your assumptions, develop better documentation, or capture what you're learning as a reusable skill. Depth beats breadth.
    • The Scattered-Engineer Epidemic: Engineers are burning out faster, not slower. We have the capacity to push more through the pipeline, so we're getting handed (or choosing) more than we can carry. Reducing parallelism often holds your delivery speed steady while dropping your cycle time and raising quality.
    • The Theory of Constraints, Revisited: Treat your software development lifecycle as a pipeline with a bottleneck — and if you can't find one, you've optimized one part too far. Writing code used to be the choke point, so we spent enormous energy de-risking work before it ever reached an engineer.
    • The Bottleneck Has Moved: When production gets cheap, it's no longer worth heavily de-risking upstream — which is why engineers are picking up more experimental, proof-of-concept, discovery work, and product folks are prototyping with these tools too. The new constraint isn't writing the code; it's verifying the agent didn't ship something broken.
    • Verification Scales With Your Effort: The more an agent produces, the bigger the pile of PRs, MRs, and outputs waiting on human review. That backlog is the new bottleneck — and skepticism is creeping in because we're not even sure our tests are sufficient to verify what the agent built.
    • Why TDD Fits This Moment: The honest question isn't "Can I trust the agent?" — it's "What verification loop do I need to build so I can trust it more?" Clear requirements feed a clear testing loop: write the failing test, let the agent write the code to turn it green, and you bridge the gap between requirements gathered and requirements met. It's not as simple as "go write a test," but it's a strong fit for where we are right now.
    • Episode Homework: Go dig into the fundamentals — limiting WIP, the theory of constraints, test-driven development. Find the old lesson that still applies to your workflow today, bring it to your team's flow, and email me about what you discover.

    🙏 Today's Episode is Brought To you by: Unblocked

    Your coding agents probably have access to your codebase — and maybe your tools and MCPs too — but access doesn't mean context. Agents don't know your architectural decisions, your team's patterns, or why your API is shaped the way it is, so Claude ends up building a new model when it should have changed an existing one, and you're left clawing back bad outputs and burning tokens on correction loops. Unblocked is the smart context layer your agents are missing. Instead of dumping everything into a giant context window, it builds reasoning over shared context — turning code, docs, tickets, and conversations into actionable context so engineers move faster, agents make better plans, write higher quality code, use fewer tokens, and need fewer corrections. If you're running Claude Code, Cursor, or any agentic workflow, go check it out. Free three-week trial at getunblocked.com/developertea.

    📮 Ask a Question

    If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

    📮 Join the Discord

    If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

    🗞️ Subscribe to The Tea Break

    We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

    🧡 Leave a Review

    If you're enjoying the show and want to support the content head over to iTunes and leave a review!

12. Principles Oriented Thinking as a Durable Skill in an AI First World

    June 10, 202628 minEpisode 1302Play next

    The skills that survive every industry shakeup aren't the ones you can Google — they're softer, harder to name, and far more durable. In this episode, Jonathan explores principle-oriented thinking: the practice …

    Show notes

    The skills that survive every industry shakeup aren't the ones you can Google — they're softer, harder to name, and far more durable. In this episode, Jonathan explores principle-oriented thinking: the practice of stripping away the labels we attach to tools, roles, and even ourselves to see what something actually does at its core. It's the difference between handing your coding off to an agent and rethinking your entire workflow around what these new materials are truly capable of.

    If you've been following along with our recent focus on durable skills, you know we've been hunting for the abilities that translate beyond this month, this year, or whatever AI does to our industry next. Today's skill doesn't have a tidy name you can search for — it's softer than that. Jonathan calls it "principle-oriented thinking": the habit of deconstructing the labels we put on things to understand their core components, properties, and capabilities. It's how NASA engineers turned a sock into a water filter on Apollo 13, and it's how forward-thinking engineers are reframing what AI can actually do rather than jamming it into a predetermined slot.

    • Labels Are Useful Shortcuts — Until They Aren't: Every label, from "software engineer" to "sock," carries baggage, heuristics, and presupposition. That's not a flaw — labels are how we move through the world quickly. But when a label is the only lens you have, it quietly caps how much value you can get out of the thing you're looking at.
    • The Apollo 13 Sock: When the crew needed to fix a life-threatening problem with mismatched parts, the engineers on the ground had to forget what a sock was for and ask what it actually is — a piece of cloth with tensile strength, flexibility, and filtering properties. Strip the assumption that it goes on a foot, and a whole new set of uses opens up.
    • Stop Slotting AI Into Old Roles: The common move is to take one responsibility — coding, debugging, refactoring — hand it to an agent, and keep everything else the same. That works, but it's low-leverage. The more powerful approach starts by asking what the agent is fundamentally capable of, then rebuilding the workflow around those raw materials.
    • See Things as Materials, Not Fixed Functions: When you deconstruct out from under a label, tools and concepts start to look like craftable raw materials. You can then combine them in new, valuable ways they haven't been combined before — alloying old methods with new capabilities to create properties neither had on its own.
    • Reason From Properties, Not Personas: Ask what the actual properties of an LLM are. Non-determinism isn't a bug to apologize for — it's a property you can exploit. The existence of many different models is a property too, which is exactly what makes adversarial review possible. That's principle-oriented thinking applied to agents.
    • Extend the Latticework: Charlie Munger talked about a latticework of mental models that weave together rather than sit in isolation. The durable skill isn't quarantining your concept of "AI" off to the side — it's grafting a new section onto the existing tapestry and letting it reshape everything you already understood.
    • Episode Takeaway: Look at how you spend your time and ask new questions of it. What is the material here? What kind of thinking does the agent actually do? What can a human do that an LLM can't — and the other way around? That's how you avoid believing a sock is only ever good for a foot.

    🙏 Today's Episode is Brought To you by: Unblocked

    Your coding agents have access to your code, your repos, and probably a pile of connected MCPs filling up their context — but access isn't the same as good context, and a bloated context window can actually degrade the very reasoning you're relying on. Agents don't know your architectural decisions, your team's patterns, or why an API was shaped the way it was, so they look in the wrong place and deliver bad outputs you then spend time and tokens correcting. ● Unblocked is the smart context layer your agents are missing. ● Instead of ingesting everything and getting lost, it builds reasoning over shared context. ● It turns code, docs, tickets, and conversations into actionable context — so engineers move faster, agents make better plans and write higher-quality code, and you burn fewer tokens and fewer correction loops. If you're running Claude Code, Cursor, or any agentic workflow, it's worth a look. A free three-week trial is available at getunblocked.com/developertea.

    📮 Ask a Question

    If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

    📮 Join the Discord

    If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

    🗞️ Subscribe to The Tea Break

    We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

    🧡 Leave a Review

    If you're enjoying the show and want to support the content head over to iTunes and leave a review!

13. What the Science Actually Says About Effective Feedback

    June 3, 202628 minEpisode 1301Play next

    A lot of what we've been talking about lately is durable skills — the abilities that last regardless of how our tools and tech environment change. In today's episode, I want to step back from the AI …

    Show notes

    A lot of what we've been talking about lately is durable skills — the abilities that last regardless of how our tools and tech environment change. In today's episode, I want to step back from the AI conversation and focus on one of the most durable skills of all: feedback. We've all been on both the giving and receiving side, and we can probably count on one hand the times someone gave us feedback that genuinely drove a good change — that left us wanting to do better without feeling torn down. So how do we accomplish that kind of feedback, on both sides of the table? That's what this episode is all about.

    • Start With Your Goal, Not Your Frustration: Before you give feedback, recognize that your gut impulse often comes from a negative emotion — frustration, feeling slighted, feeling disrespected. Those feelings are valid signals that something is off, but they aren't a sufficient reason to give feedback. Effective feedback is goal-oriented: ask yourself what you actually want to change before you say a word.
    • Premature vs. Mature Feedback: Premature feedback is really about making sure someone knows how you feel — which can quietly turn into an attack so they share your pain. Mature feedback is forward-looking and aimed at improvement. Venting may give you catharsis in the moment, but if the behavior worsens or the relationship is damaged, the net outcome is negative.
    • Why Asking for Feedback Changes Everything: Even hearing "can we meet for ten minutes, I have some feedback" measurably raises your heart rate and pushes you into a defensive state. But when you ask for feedback, your mind and body register that you're in control — same information, completely different physiological response.
    • Make It Behavior-Based and Specific: Good feedback is about observable behavior — what a camera would have caught — not someone's core identity. If your feedback violates a person's self-concept (painting a competent engineer as incompetent), they have to change who they believe they are to accept it, and that gap rarely gets bridged in a 30-minute call.
    • Use a Model — But Add the Intervention: The popular SBI model (Situation, Behavior, Impact) is a strong backbone, but it stops short. Don't just describe the past — partner with the person on what comes next. Think of it as SBI + Intervention: what can you commit to trying differently so the impact changes? That's where feedback becomes coaching.
    • The Netflix Four A's: Aim to assist, make it actionable, show appreciation, and accept or discard. Lead with the intent to help, get specific about the behavior, appreciate the person's willingness and intent, and recognize that not every piece of feedback will be useful — both sides get to keep what's valuable and let the rest go.
    • Receiving Feedback Well: When someone hands you messy, un-modeled feedback, you can walk them through the framework — "help me understand the situation, what behavior did you see, what was the impact?" People respect that you're engaging, shift into problem-solving mode, and give you more actionable feedback as a result.
    • Episode Homework: Pay attention to patterns over time. One piece of feedback shouldn't be attached to your identity — but three or four that point in the same direction are worth introspecting on. Career development and feedback are two sides of the same door; walk through it and you grow.

    🙏 Today's Episode is Brought To you by: SerpApi

    No matter what you're building, SerpApi is the web search API for your needs. If you're building an application that needs real-time search data—whether that's an AI agent, an SEO tool, or a price tracker—SerpApi handles it for you. ● Make an API call and get back clean JSON. ● They handle the proxies, CAPTCHAs, parsing, and all the scraping so you don't have to. ● They support dozens of search engines and platforms, and are trusted by companies like NVIDIA, Adobe, and Shopify. ● If you're building with AI, they even have an official MCP to make getting up and running a simple task. Get started with a free tier to build and test your application before you commit. Go to serpapi.com.

    📮 Ask a Question

    If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

    📮 Join the Discord

    If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

    🗞️ Subscribe to The Tea Break

    We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

    🧡 Leave a Review

    If you're enjoying the show and want to support the content head over to iTunes and leave a review!

14. Rebuilding Your Mental Models In the Midst Of an AI Tech Revolution

    May 27, 202627 minEpisode 1300Play next

    Right now, the questions we have about our careers feel existential. We keep coming back to the same theme: how do you prepare for an industry that's changing this fast, and what mindset actually works in this …

    Show notes

    Right now, the questions we have about our careers feel existential. We keep coming back to the same theme: how do you prepare for an industry that's changing this fast, and what mindset actually works in this new reality? One skill keeps surfacing as the answer — your ability to update your own mental models. In today's episode, I want to push on that further and put some of software engineering's most beloved thinking models under scrutiny. Some of these models served you well for years. Some of them now deserve to be challenged, replaced, or thrown out entirely — and learning how to tell the difference is itself the skill that will determine whether you hit a ceiling.

    • Move Past "So What" Questions: The typical engineering objection to agentic coding is that it produces quality issues. But the people deciding to adopt these tools already accept that. Our job is to stop arguing the surface-level point and start asking the real one: so what do we actually do about this new economic reality?
    • The Economics of Acceptable Loss: Abstraction always leaves something to be desired. An agent's code may not match what a staff engineer produces by hand over months — but that gap is usually an acceptable trade against shipping something two, three, or four times faster. Understand the cost-benefit picture instead of pretending the cost doesn't exist.
    • Abstraction Has Always Done This: This isn't new. The calculator dissolved the specialization once required for complex math. Spreadsheets commoditized ledgering and accounting. Agentic coding is the same pattern arriving for our work — making something that required deep specialization suddenly far more accessible.
    • Roles Are Blurring: As these generic tools raise everyone's ability to abstract, the boundaries soften. You're already seeing product managers open pull requests and engineers making product decisions. The neat lines around "what an engineer is" are not as fixed as they used to feel.
    • Why Your Hard-Won Wisdom Is the Target: If you've spent years in this industry, your models were bought with blood, sweat, and failed projects. That experience is real wisdom — and it's exactly what I'm asking you to be willing to challenge, because the thing that always worked for you is the thing most likely to become a ceiling.
    • This Skill Survives Either Way: Even if you think AI is mostly hype and I've been infected by it — fine. The ability to challenge your pre-existing models is a critical skill regardless. It's how you keep growing as you get more senior instead of repeating what used to work.
    • Models Are Approximations: The whole point of a model is to approximate the reality around us. That's their value and their limitation. When the underlying reality shifts this dramatically, holding tightly to an old approximation stops being wisdom and starts being a liability.

    🙏 Today's Episode is Brought To you by: Unblocked

    Your coding agents have access to your codebase and probably a lot more — tools connected through MCPs, skills, and more. But access isn't the same as context. Agents aren't great at reasoning across MCPs, and they don't know your architectural decisions, your team's patterns, or why your API is shaped the way it is. So they look in the wrong place and deliver bad outputs, and you burn time and tokens correcting them. ● Unblocked is the smart context layer your agents are missing. ● Instead of dumping tons of data into a giant context window and getting lost, it builds reasoning over shared context. ● It turns code, docs, tickets, and conversations into actionable context, so engineers move faster and agents make better plans, write higher quality code, use fewer tokens, and need fewer correction loops. ● If you're running Claude Code, Cursor, or any other agentic workflow, it's worth a look. Get a free three-week trial at getunblocked.com/developer-tea.

    📮 Ask a Question

    If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

    📮 Join the Discord

    If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

    🗞️ Subscribe to The Tea Break

    We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

    🧡 Leave a Review If you're enjoying the show and want to support the content head over to iTunes and leave a review!

15. Practice Isn't Enough for Senior Engineers - Adaptation Is a Key Skill in an AI-First Industry

    May 24, 202620 minEpisode 1299Play next

    If you're a software engineer right now, you likely feel like your world is changing overnight. We are writing half or less the amount of code that we wrote even a year ago, which represents a seismic …

    Show notes

    If you're a software engineer right now, you likely feel like your world is changing overnight. We are writing half or less the amount of code that we wrote even a year ago, which represents a seismic, groundbreaking shift in our industry. For many of us, this career has always been engaging for deeply creative and intellectual reasons—and that excitement is still here. But our mental models of what it means to be a good engineer, and what it means to keep improving, have gone a little stale. In today's episode, I want to talk about a distinction that I believe will become the cornerstone mistake for seasoned engineers: confusing _practice_ with _adaptation_, and leaning on the wrong one at the worst possible moment.

    • Two Surfaces Coming Into Contact: Picture your knowledge, skills, and toolset as one surface, and the actual state of the art as another. We've always known the surface area we could learn far exceeds what we can learn, which forces us to place bets on a learning strategy. What's changing is how fast that second surface is moving underneath us.
    • Improvement by Practice vs. Improvement by Change: Practice is wielding what you've already adopted—smoothing out errors, building muscle memory, refining what you already know. Adaptation is fundamentally folding something new into your repertoire. Both are real forms of improvement, but they are not interchangeable.
    • The Cornerstone Mistake for Senior Engineers: Later in your career, the time you spend adapting naturally goes down as you settle into practice. The biggest error I'm already watching engineers make is moving too quickly toward practice when the industry is loudly calling for adaptation instead.
    • Inspect and Adapt—at the Right Altitude: Sprint retros were never really about getting marginally better at the thing you already do. The intent of "inspect and adapt" is to step up one level and examine the system. The trap is treating adaptation like a minor refinement—getting a little better at prompting—when it should mean asking whether you're thinking about prompting in the wrong way entirely.
    • Question the Ratio, Not Just the Output: Real adaptation looks like asking whether you have the right mix of human and agent on a problem. Are you leaning on the agent for things you shouldn't, or failing to lean on it for the things you should? Have you genuinely thought about how sub-agents or an agent team are working the problem you're producing?
    • A Spectrum, Not a Binary: On one end, you make micro-adjustments to your refinement process. On the other end of experimentation, you ask whether refinement—or even having engineers plan the work—is the right thing at all. The point isn't that practice is dead; it's that the industry is changing fast enough that the adaptive end of that spectrum deserves far more of your attention than it used to.
    • Episode Homework: Take something you currently treat as a practice problem—"how do I refine tickets faster?"—and step up a level. Ask the adaptive version of the question instead: "Is refinement even the right thing anymore?"

    🙏 Today's Episode is Brought To you by: SerpApi

    No matter what you're building, SerpApi is the web search API for your needs. If you're building an application that needs real-time search data—whether that's an AI agent, an SEO tool, or a price tracker—SerpApi handles it for you. ● Make an API call and get back clean JSON. ● They handle the proxies, CAPTCHAs, parsing, and all the scraping so you don't have to. ● They support dozens of search engines and platforms, and are trusted by companies like NVIDIA, Adobe, and Shopify. ● If you're building with AI, they even have an official MCP to make getting up and running a simple task. Get started with a free tier to build and test your application before you commit. Go to serpapi.com.

    📮 Ask a Question

    If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

    📮 Join the Discord

    If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

    🗞️ Subscribe to The Tea Break

    We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

    🧡 Leave a Review If you're enjoying the show and want to support the content head over to iTunes and leave a review!

16. Senior Skills to Maintain Employment Through the AI Wave

    May 14, 202629 minEpisode 1298Play next

    If you've heard that your job in the agentic coding era is to "become a manager of agents," you may have noticed something doesn't quite fit. Most of us never trained to be managers, and frankly, that's not the …

    Show notes

    If you've heard that your job in the agentic coding era is to "become a manager of agents," you may have noticed something doesn't quite fit. Most of us never trained to be managers, and frankly, that's not the role most engineers want. In today's episode, I unpack what that shift _actually_ means — it's closer to a tech lead or architect mindset — and zoom in on a specific interviewing and on-the-job skill that will help you stay employable: how you think about, talk about, and take ownership of failure.

    • Don't Just Bring Star Stories — Bring Failure Stories: Interviewers don't only want to hear how you succeeded. They want to know what you do when the pressure's on and things fall apart. If every story you tell is a highlight reel, there's a built-in social signal that you're hiding something. Get comfortable telling the other kind of story.
    • Identify the Real Problem, Not the Proximal One: The most common failure story I hear in interviews is "the knowledge transfer was bad" or "the docs weren't good." That's not wrong — it's just incomplete. The senior mindset asks why that happened. Why didn't we have docs? Why was context insufficient? Walk it back until you hit something actionable but not too abstract.
    • The Systemic Diagnosis is the Leveled-Up Answer: Fixing the proximal cause fixes this instance. Fixing the root cause fixes the system that keeps producing instances like this. When you connect what you learned to a systemic adjustment, you stop sounding like someone who survived a bad project and start sounding like someone who improves the organization around them.
    • Ownership Means Owning the Outcome, Not the Task: Use the homeowner metaphor. A homeowner doesn't personally fix every leaking pipe — but the outcome of the home is theirs. As an engineer, your scope of ownership has expanded dramatically in the agentic era. You're now responsible for outcomes of code you may not have even read, and the deciding skill is how you carry that responsibility.
    • The Word to Pair With Ownership is Relentlessness: Not in an anxious, burn-yourself-out way. Relentlessness means following a thread to its natural end — through escalation, through asking the next question, through finding the right person if it's not you. It's the antidote to "I'll let someone else handle it" syndrome.
    • You Don't Have to Do It All Yourself: Relentless ownership is not "carry every task across the finish line personally." If you're not qualified, the owner's job is to find who is, communicate risk to stakeholders, and keep the trail alive until the outcome is resolved. That's the differentiator between a senior thinking engineer and a junior one working through assigned tickets.
    • Failure Is Usually a Lapse in Ownership: If you make a list of five things you've failed at (and you should), you'll often find the through-line isn't lack of skill — it's that you stopped escalating, stopped following up, stopped staying with the thing until it was actually resolved.
    • Episode Homework: Write down five real failures. For each one, ask: where did I stop being relentless? What system produced this outcome — and what would I change upstream next time?

    🙏 Today's Episode is Brought To you by: SerpApi

    No matter what you're building, SerpApi is the web search API for your needs. If you're building an application that needs real-time search data—whether that's an AI agent, an SEO tool, or a price tracker—SerpApi handles it for you. ● Make an API call and get back clean JSON. ● They handle the proxies, CAPTCHAs, parsing, and all the scraping so you don't have to. ● They support dozens of search engines and platforms, and are trusted by companies like NVIDIA, Adobe, and Shopify. ● If you're building with AI, they even have an official MCP to make getting up and running a simple task. Get started with a free tier to build and test your application before you commit. Go to serpapi.com.

    📮 Ask a Question

    If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

    📮 Join the Discord

    If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

    🗞️ Subscribe to The Tea Break

    We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

    🧡 Leave a Review If you're enjoying the show and want to support the content head over to iTunes and leave a review!

17. You're Wrong All the Time, But All You Need Are Better Explanations

    May 6, 202626 minEpisode 1297Play next

    What happens when you discover that a book that fundamentally changed how you think is built on a shaky foundation? In today's episode, I share my own struggle with the replication crisis surrounding Daniel …

    Show notes

    What happens when you discover that a book that fundamentally changed how you think is built on a shaky foundation? In today's episode, I share my own struggle with the replication crisis surrounding Daniel Kahneman's *Thinking Fast and Slow*, and I use it as a springboard to talk about a much bigger skill: knowing how to update your beliefs when reality shifts underneath you. This isn't about throwing out science or losing trust in your heroes. It's about developing the muscle to replace old explanations with better ones — a skill that has never been more important for software engineers.

    • The Replication Crisis, Briefly Explained: Understand the difference between reproducing a study (re-running the analysis on the original data) and replicating one (recreating the study from the ground up), and why a surprisingly large portion of well-respected psychology research, including studies cited in Thinking Fast and Slow, doesn't hold up under scrutiny.
    • Base Rates Matter: Kahneman didn't pick uniquely bad studies. If you randomly sampled from the broader academic literature, you'd hit the same failure rate. The lesson isn't about one author — it's about how we evaluate any body of knowledge.
    • The Beginning of Infinity Framework: Drawing from David Deutsch's book, explore the idea that all progress is rooted in the assumption that we are fundamentally incorrect, and that improvement comes from continually building better explanations on top of incomplete ones.
    • Beliefs as Calibration, Not Truth: Your beliefs about what makes a good engineer, what makes good code, or what makes a good career move are not eternal truths. They are calibrations to your current reality, and that reality is changing fast.
    • The Ego Trap of Old Beliefs: Notice the very human, very subtle pull to defend things you previously argued for — not because they're still right, but because admitting otherwise creates a discontinuity with your former self. This is one of the biggest blockers to learning.
    • Two Competing Explanations of AI Adoption: Walk through a worked example of holding two predictions about AI in tension and asking honestly which one better explains the reality you're seeing — at both a macro industry level and the micro level of debugging a system.
    • Moving Goalposts Aren't a Conspiracy: A lot of what feels like shifting goalposts in our industry is just goalposts moving on their own. A big part of our job as engineers is figuring out where they are now and predicting where they're heading next.
    • Episode Homework: Pick one belief you hold strongly about your work — about what makes a good engineer, about a tool, about a process. Try to deconstruct it into its parts and ask whether a better explanation exists for what you're actually seeing.

    🙏 Today's Episode is Brought To you by: SerpApi

    No matter what you're building, SerpApi is the web search API for your needs. If you're building an application that needs real-time search data—whether that's an AI agent, an SEO tool, or a price tracker—SerpApi handles it for you. ● Make an API call and get back clean JSON. ● They handle the proxies, CAPTCHAs, parsing, and all the scraping so you don't have to. ● They support dozens of search engines and platforms, and are trusted by companies like NVIDIA, Adobe, and Shopify. ● If you're building with AI, they even have an official MCP to make getting up and running a simple task. Get started with a free tier to build and test your application before you commit. Go to serpapi.com.

    📮 Ask a Question

    If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

    📮 Join the Discord

    If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

    🗞️ Subscribe to The Tea Break

    We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

    🧡 Leave a Review If you're enjoying the show and want to support the content head over to iTunes and leave a review!

18. AI-Proofing Your Skillset - High-Meaning, High-Specifity Vocabulary is the Path to Growth

    April 29, 202631 minEpisode 1296Play next

    Why I'm Not "Picking a Fight" on AI: A listener asked if I'm intentionally stoking a flame war by treating agentic coding as a foregone conclusion. The honest answer is that I've used it, the data points one …

    Show notes

    • Why I'm Not "Picking a Fight" on AI: A listener asked if I'm intentionally stoking a flame war by treating agentic coding as a foregone conclusion. The honest answer is that I've used it, the data points one direction, and a show built around pretending otherwise would slowly drift away from reality — and away from being useful to you.
    • Respecting the Misgivings, Without Getting Stuck in Them: Ethical concerns, skill atrophy worries, and questions about long-term effects are all legitimate. But the goal of this show is practical applicability, so we focus on mental models you can use Monday morning rather than litigating every angle of the debate.
    • The "Minecraft" Principle: If I ask you to "build Minecraft," I've handed you several chapters of specification in a single word. That's meaning-rich abstraction — language that points at a huge amount of shared context with very little token cost.
    • Meaning-Rich AND Specific: "Human history" is meaning-rich but uselessly broad. "Block-building game" is specific but loses fidelity. The sweet spot is vocabulary that is both compact and unambiguous — sitting in the top right of the meaning-density / specificity graph.
    • A Real Example — Strategy Pattern: When working on authorization rules, I didn't want a pipeline. Instead of describing base classes, shared interfaces, and parallel execution to the LLM, I used the words "strategy pattern." Three words did the work of three paragraphs, and the output landed where I wanted it.
    • Vocabulary as Leverage: Named patterns, named algorithms (Monte Carlo, etc.), named architectural concepts — these act like compressed pointers. The more of them you genuinely understand, the higher the leverage of every prompt you write and every conversation you have with another engineer.
    • How to Build This Vocabulary: Have conversations with senior engineers. Ask an LLM what patterns are at play in a codebase, which ones you're using incorrectly, and which ones you're tricked into thinking you're using. Learn the abstraction layer that sits one step above your day-to-day implementation work.
    • The Asterisk — Shared Context Required: This only works when both sides know the term. Public, well-documented concepts (patterns, papers, algorithms) translate immediately to LLMs. Private or organization-specific concepts need to be loaded into context — via CLAUDE.md, AGENTS.md, or skills — before that compression kicks in.
    • Episode Homework: Pick one area of your current codebase. Ask an LLM to name the patterns in play, the patterns you're using incorrectly, and the ones you might be missing. Use that conversation to add at least one new piece of meaning-rich vocabulary to your working set.

    🙏 Today's Episode is Brought To You by: Unblocked

    Your coding agents have access to your code base — and probably more — but access isn't the same as context. Agents can't reason well across MCPs on their own, they don't know your architecture decisions, and they don't know which docs are reliable versus written by someone in their free time two years ago. ● Unblocked is the context layer your agents are missing. ● It synthesizes your PRs, docs, Slack messages, and Jira issues into organizational context that agents actually understand. ● That means better plans, higher quality code, fewer tokens, and fewer correction loops. ● Whether you're running Claude Code, Cursor, Codex, or any agentic workflow, it's worth a look. Get a free three-week trial at getunblocked.com/developertea.

    📮 Ask a Question

    If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

    📮 Join the Discord

    If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

    🗞️ Subscribe to The Tea Break

    We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

    🧡 Leave a Review If you're enjoying the show and want to support the content head over to iTunes and leave a review!

19. Building Real Skills During the AI Boom - No, Not That Kind of Skill

    April 22, 202630 minEpisode 1295Play next

    The Coding-Is-My-Value Trap: For years, we've treated the ability to write code as the flagship skill of software engineering. It's concrete, it's teachable, it's the thing big box stores sell kits for. But …

    Show notes

    • The Coding-Is-My-Value Trap: For years, we've treated the ability to write code as the flagship skill of software engineering. It's concrete, it's teachable, it's the thing big box stores sell kits for. But conflating "what I enjoy about the job" with "what I'm actually valuable for" is dangerously reductive — and AI is now exposing that gap.
    • The Skills You've Been Discounting: Domain expertise, systems thinking, risk and bottleneck analysis, organizational design, tech-lead-level sequencing of work, relational skills that unblock hard moments in a company's life. These have always been where a lot of your real value lived. You probably just weren't writing them down.
    • The Three-Part Framework — Valuable, Durable, Transferable: A skill worth investing in hits as many of these as possible. Valuable means it meets a clear business need. Durable means it survives industry shifts. Transferable means it applies across domains and scales up as you grow more senior.
    • What "Durable" Actually Means: Ask yourself: what would have to change for this skill to become obsolete? Coding, on its own, has a lower durability answer than it used to. Relationship building, architectural thinking, and the ability to reason about complexity require much bigger shifts before they stop mattering.
    • Transferability Is Vertical, Not Just Lateral: Don't just ask whether a skill moves across industries. Ask whether it keeps paying off as you move into more senior, higher-leverage roles. Soft skills, systems thinking, and mental models like compound interest compound themselves the further up you go.
    • Episode Homework: Make your own list. Which of your skills are valuable, durable, and transferable? Every engineer's list looks different — and the ones you've been quietly discounting are often the ones that matter most going forward.

    🙏 Today's Episode is Brought To you by: Unblocked

    Your coding agents have access to your codebase — but access isn't context. They don't know your architectural decisions, your team's patterns, or why the API was shaped the way it was. So they look in the wrong places and deliver bad outputs, and you burn time and tokens correcting them.
    ● Unblocked is the context layer your agents are missing.
    ● It synthesizes your PRs, docs, Slack messages, Jira issues, and more into organizational context agents actually understand.
    ● Better plans, higher quality code, fewer correction loops, fewer tokens spent.
    ● Works with Claude Code, Cursor, and any agentic workflow. Get a free three-week trial at getunblocked.com/developertea.

    📮 Ask a Question

    If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

    📮 Join the Discord

    If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

    🗞️ Subscribe to The Tea Break

    We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

    🧡 Leave a Review

    If you're enjoying the show and want to support the content head over to iTunes and leave a review!

20. Chaos Doesn't Have to Win - Maintaining Order in the Midst of AI Change

    April 15, 202621 minEpisode 1294Play next

    If you're an engineering leader right now, everything around you feels like it's changing at once — new tools, new processes, new expectations. It's tempting to accept chaos as the new normal, but in today's …

    Show notes

    If you're an engineering leader right now, everything around you feels like it's changing at once — new tools, new processes, new expectations. It's tempting to accept chaos as the new normal, but in today's episode, I make the case that your job is to go on the offense and *create* order. Not by clinging to old processes, but by becoming the groundskeeper of your team's ceremonies — the regular, repeated actions that give your team a foundation to actually improve from.

    • Humans Are the Limiting Factor (And That's Okay): Our fundamental cognitive capabilities haven't changed in tens of thousands of years. Progress is collective — better tools, better documentation, better knowledge systems — but individually, our brains work the same way they always have. Any process that involves humans has to account for this.
    • Why Ceremony Matters More Than Ever: Whether you call them scrum ceremonies, team rituals, or just "the way we work," regular and repeated team actions aren't bureaucratic overhead. They're how humans learn, build comfort, and reduce cognitive load. Just like sitting in the same seat at your coffee shop or driving the same route to work, repeated patterns free up mental energy for the things that actually require your attention.
    • Regularity of Action Over Specific Process: This isn't a prescription for scrum or kanban or any particular framework. The point is that your team has some determined, repeated way of doing things — whether that's a weekly planning session, a daily standup, or a trigger-based refinement process. The specific process matters less than the consistency.
    • Ceremony Enables Experimentation: If you want to get better, you need to be able to change one variable at a time and measure the result. That's impossible when everything is changing at once. Holding your core processes steady gives you the controlled environment you need to actually learn what's working and what isn't.
    • Spot the Anomalies: When you maintain regularity, deviations become visible. If productivity dips but your ceremonies stayed constant, you have a much better shot at diagnosing what actually changed. Without that baseline, every signal gets lost in the noise.
    • Episode Homework: Sit down with your team this week and talk about what your ceremonies are. What do you want to hold constant? What do you want to be true on a regular basis? Name them, write them down, and commit to tending them — even as everything else shifts around you.

    🙏 Today's Episode is Brought To you by: SerpApi

    No matter what you're building, SerpApi is the web search API for your needs. If you're building an application that needs real-time search data—whether that's an AI agent, an SEO tool, or a price tracker—SerpApi handles it for you. ● Make an API call and get back clean JSON. ● They handle the proxies, CAPTCHAs, parsing, and all the scraping so you don't have to. ● They support dozens of search engines and platforms, and are trusted by companies like NVIDIA, Adobe, and Shopify. ● If you're building with AI, they even have an official MCP to make getting up and running a simple task. Get started with a free tier to build and test your application before you commit. Go to serpapi.com.

    📮 Ask a Question

    If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

    📮 Join the Discord

    If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

    🗞️ Subscribe to The Tea Break

    We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

    🧡 Leave a Review If you're enjoying the show and want to support the content head over to iTunes and leave a review!

21. Mourning the Loss of Coding, Senior Tooling Mindset, and Shaping Your Environment

    April 8, 202634 minEpisode 1293Play next

    Your tool set isn't just a collection of utilities — it's the environment you live in every day, and it's shaping you whether you realize it or not. In today's episode, I explore two principles that senior …

    Show notes

    Your tool set isn't just a collection of utilities — it's the environment you live in every day, and it's shaping you whether you realize it or not. In today's episode, I explore two principles that senior engineers consistently apply to their workflows, regardless of which specific tools they're using. As our industry goes through one of the most rapid periods of change in the last 20 years, the engineers who thrive won't be the ones chasing every new tool — they'll be the ones who obsess over reducing friction in the work they do most often.

    • Honor the Grief: Many engineers are experiencing a real sense of loss as the deep cultural connections to languages, communities, and hand-written code begin to shift. Recognizing and processing that grief — rather than letting it turn into reflexive rejection of new tools — is essential to thinking clearly about what comes next.
    • "We Shape Our Tools, Then Our Tools Shape Us": Your tools aren't neutral. A bad monitor height, a faulty keycap, or a clunky deployment process all shape you back — draining focus, breaking flow, and compounding over time. The most senior engineers treat this relationship as a first-class concern.
    • Principle 1 — Tools Are Your Environment: There's a spectrum from "tool" to "environment," and most of what you work with sits somewhere in between. Your terminal, your desk, your claude.md file — all of these are environment. Sharpening your tools means shaping your environment, and shaping your environment is sharpening your tools.
    • Friction Is the Lever: You don't need a dramatic overhaul to change your behavior. Tiny reductions in friction — a two-letter alias, a key binding to run tests, setting your shoes out the night before — have an outsized effect on how often you actually do the things you want to do. James Clear's Atomic Habits framework applies directly to engineering workflows.
    • Principle 2 — First Order Thinking: Borrowed from Adam Savage's concept of "first order retrievability," the idea is simple: identify what you do most often and invest in making that better. Not faster, not just automated — better. If you do something a hundred times a day, even a small improvement compounds dramatically.
    • Invest in the Fundamentals: Your standups, your one-on-ones, your specifications, your prompting skills — these are the repetitive, high-frequency activities where your biggest growth opportunities live. Stop assuming you've "arrived" on the basics just because nobody is giving you negative feedback.
    • Episode Homework: Look around your workspace right now — physical and digital. Identify one thing you do repeatedly where friction is slowing you down or discouraging follow-through, and make one small change to reduce that friction today.

    🙏 Today's Episode is Brought To you by: SerpApi

    No matter what you're building, SerpApi is the web search API for your needs. If you're building an application that needs real-time search data—whether that's an AI agent, an SEO tool, or a price tracker—SerpApi handles it for you. ● Make an API call and get back clean JSON. ● They handle the proxies, CAPTCHAs, parsing, and all the scraping so you don't have to. ● They support dozens of search engines and platforms, and are trusted by companies like NVIDIA, Adobe, and Shopify. ● If you're building with AI, they even have an official MCP to make getting up and running a simple task. Get started with a free tier to build and test your application before you commit. Go to serpapi.com.

    📮 Ask a Question

    If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

    📮 Join the Discord

    If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

    🗞️ Subscribe to The Tea Break

    We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

    🧡 Leave a Review

    If you're enjoying the show and want to support the content head over to iTunes and leave a review!

22. Useful Illusions and Exploiting Heuristics

    April 1, 202627 minEpisode 1292Play next

    When Good Thinking Becomes Overthinking: Discover why the pursuit of perfect analysis often undermines good decision-making. Loading every caveat, every exception, and every alternative into your working memory …

    Show notes

    • When Good Thinking Becomes Overthinking: Discover why the pursuit of perfect analysis often undermines good decision-making. Loading every caveat, every exception, and every alternative into your working memory doesn't produce better outcomes — it produces paralysis.
    • Heuristics as a Feature, Not a Bug: Your brain is an efficiency machine that creates shortcuts — cached concepts, stored routines, snap judgments. These heuristics are always incomplete, but they let you move through complex problems quickly. The opportunity is to deliberately choose which heuristics to exploit.
    • "All Models Are Wrong, Some Models Are Useful": Useful illusions don't need to be perfectly true. They need to be true enough that acting on them produces better outcomes than endlessly debating their accuracy.
    • Useful Illusion: Coding by Hand Is Going Away: Whether or not this is literally true in every case, the engineer who acts as if it is will invest in agentic workflows, LLMs, and new tooling — while the engineer who picks the argument apart risks being labeled a skeptic and falling behind.
    • Useful Illusion: Hard Work Pays Off: You can poke holes in this all day — wrong direction, burnout, culture-dependent — but people who follow this heuristic tend to build reputations as reliable and capable. Few of us want to be known for the opposite.
    • Useful Illusion: As Long As I'm Learning, I'm Growing: Learning becomes less directly correlated with career advancement over time, but continuing to act on this belief keeps you flexible, curious, and in a growth mindset.
    • More Useful Illusions for Your List: Clean code is better. Always think about the user's experience. Go with the tool you know. Volume of delivered work correlates with career success — especially during performance review season.
    • The Key Insight: You don't have to believe any of these things literally. You're exploiting your own heuristic system to drive efficient action and avoid wasting time on low-utility debates. The result is a more decisive, action-oriented version of yourself.

    🙏 Today's Episode is Brought To you by: Unblocked

    Your coding agents have access to your codebase, but access doesn't mean good context. Agents can't easily reason across MCPs without guidance — they don't know your architectural decisions, your team patterns, or what that acronym actually means. Unblocked is the context layer your agents are missing. It synthesizes your PRs, docs, Slack messages, and JIRA issues into organizational context so agents make better plans, write higher quality code, use fewer tokens, and require fewer correction loops. Get a free three-week trial at getunblocked.com.

    📮 Ask a Question

    If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

    📮 Join the Discord

    If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

    🗞️ Subscribe to The Tea Break

    We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

    🧡 Leave a Review If you're enjoying the show and want to support the content head over to iTunes and leave a review!

23. Decision Making is Your New Core Skill, So it's Critical to Avoid These Two Traps of Collaborative Decision-Making

    March 24, 202639 minEpisode 1291Play next

    The Bottleneck Is Moving: Borrowing from traditional manufacturing theory, the coding step used to define your team's total throughput. AI tooling hasn't incrementally improved that bottleneck — it has …

    Show notes

    • The Bottleneck Is Moving: Borrowing from traditional manufacturing theory, the coding step used to define your team's total throughput. AI tooling hasn't incrementally improved that bottleneck — it has drastically shrunk it, which means the constraint is now upstream in product decisions, specifications, and prioritization. Engineers who recognize this shift early will redirect their energy accordingly.
    • Sharing Your Opinion Is Not a Free Action: Every time you weigh in on a decision, you're making a transaction. You're asking others to consider your input, and in return, they will update their beliefs about your judgment based on whether you turn out to be right. This means your credibility is a finite resource that appreciates or depreciates over time.
    • Trap #1 — Arguing About Things You Don't Care About: Engineers often feel an intellectual itch to engage when they hear an argument they disagree with, even when the outcome doesn't matter to them. If the only utility of sharing your opinion is your own self-satisfaction, the risk to your social capital almost never justifies the reward. Pick your battles so that when something does matter to you, people actually listen.
    • The Watchful Waiting Approach: If you predict a decision will lead to a bad outcome, sometimes the most effective move is to wait and let the result speak for itself. You get the learning for free without putting your reputation on the line — especially for decisions outside your core responsibilities.
    • Trap #2 — Arguing on the Wrong Axis: When you do engage, make sure your argument is aligned with what the decision-maker actually cares about. A product manager asking engineers to delay optimization work is not going to be moved by arguments about on-call load. An engineering manager introducing a systems design interview won't be swayed by the fact that you personally dislike them. If your reasoning doesn't connect to their criteria, it lands as noise.
    • Naive Realism and the Alignment Fix: We all default to believing our perspective is the balanced, unbiased one. This tendency causes us to assume anyone who disagrees must be missing information. The fix is to start by understanding what the other person is optimizing for. Once you know their criteria, you can either recognize their decision is perfectly reasonable — or reframe your argument in terms they actually care about.
    • The One Takeaway: Understand what the other person wants, what they care about, and why. Decision-making in a collaborative environment is fundamentally negotiation, and the best negotiators optimize for multiple axes rather than treating every disagreement as zero-sum.

    🙏 Today's Episode is Brought To you by: Unblocked

    Your coding agents have access to your codebase, but access doesn't equal context. Agents can't reason across MCPs — they don't know your architectural decisions or why the API is shaped the way it is — so they look in the wrong place and deliver bad outputs. Unblocked is the context layer your agents are missing. It synthesizes your code, PRs, docs, Slack messages, and Jira issues into organizational context that agents actually understand, so they make better plans, write higher quality code, and use fewer tokens. Get a free three-week trial at getunblocked.com/developertea.

    📮 Ask a Question

    If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

    📮 Join the Discord

    If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

    🗞️ Subscribe to The Tea Break

    We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

    🧡 Leave a Review If you're enjoying the show and want to support the content head over to iTunes and leave a review!

24. What's Brewing, Edition 1 - What Jonathan is Learning, Using, and Thinking

    March 18, 20261 h 6 minEpisode 1290Play next

    The Power of Physical Checklists: Inspired by aviation, Atul Gawande's The Checklist Manifesto, and Daniel Kahneman's Noise, I've been experimenting with printed, physical checklists for repetitive tasks — from …

    Show notes

    • The Power of Physical Checklists: Inspired by aviation, Atul Gawande's The Checklist Manifesto, and Daniel Kahneman's Noise, I've been experimenting with printed, physical checklists for repetitive tasks — from producing this show to running one-on-ones. The rigor of writing precise procedures carries over into clearer communication with both humans and AI agents.
    • Small Interventions, Big Returns: A Brother P-Touch label maker. Reorganizing scattered hobby gear. 3D printing organizational tools with a new Bambu Labs P1S. None of these are revolutionary on their own, but the compounding effect of better organization — essentially building a fast index for your physical life — pays back over and over.
    • Context Shapes Focus: Switching from a home gym to working out at Planet Fitness with my brother-in-law was one of the best focus interventions I've made. The change in environment eliminated the procrastination and context-blending that came from being steps away from my computer. If you're struggling with a habit, sometimes the environment is the variable to change, not your willpower.
    • The Reading List: Good Strategy, Bad Strategy by Richard Rumelt (and its follow-up The Crux), The Art of Action by Stephen Bungay (a great framework for thinking about agentic workflows), How to Know a Person by David Brooks, and my top recommendation: 4,000 Weeks by Oliver Burkeman — a book that will help you stop looking for the productivity hack that fixes everything and start thinking about what actually matters.
    • Learning as a Habit: Right now I'm learning to drive a stick shift on a 1983 Bronco. The point isn't the skill itself — it's staying in the beginner's seat. Intentional practice, setting small goals, refining through repetition. Keeping this habit alive is more important than ever when the industry demands rapid adaptation.
    • How I'm Actually Using AI: Claude Code for one-shotting tools with clear boundaries, local environment improvements, and terminal troubleshooting. OpenClaw for experimental agents like a personalized trip planner and Home Assistant automations via YAML. Claude Co-Work for file system management and screenshot organization. Obsidian as the connective tissue — a markdown knowledge base that gives AI agents personal context to work with. And at work, spec-driven development is showing real promise for shaping agent output quality.
    • A Framework for Thinking About AI's Role: I break AI use cases into categories: automating existing workflows (where most gains are today), operational restructuring (what happens when you free humans from a task), execution of complex technical work (agents on the front lines), iterative consulting on intent and goals, and the emerging frontier of exploratory connections and strategic synthesis.
    • What You Should Actually Do: Be action-oriented — the cat is out of the bag. Invest heavily in planning and specification before sending agents off to work. But more importantly, invest in mindful change: understand your own values, figure out who you want to be when you look back on this moment in 10 years, and let that guide your decisions about adoption, learning, and career direction.

    🙏 Today's Episode is Brought To you by: SerpApi

    If you're building an application that needs real-time search data — whether that's an AI agent, an SEO tool, or a price tracker — SerpApi handles it for you. Make an API call, get back clean JSON. They handle the proxies, CAPTCHAs, parsing, and all the scraping so you don't have to. They support dozens of search engines and platforms, and are trusted by companies like NVIDIA, Adobe, and Shopify. If you're building with AI, they even have an official MCP to make getting up and running a simple task. Get started with a free tier at serpapi.com.

    📮 Ask a Question

    If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

    📮 Join the Discord

    If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

    🗞️ Subscribe to The Tea Break

    We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

    🧡 Leave a Review

    If you're enjoying the show and want to support the content head over to iTunes and leave a review!

25. From Software Engineer to Agent Manager - How Work is Changing in A New Software Development Paradigm

    March 10, 202621 minEpisode 1289Play next

    If you're a software engineer right now, you likely feel like your world is changing overnight. We are writing half or less the amount of code that we wrote even a year ago, which represents a seismic …

    Show notes

    If you're a software engineer right now, you likely feel like your world is changing overnight. We are writing half or less the amount of code that we wrote even a year ago, which represents a seismic, groundbreaking shift in our industry. However, the rapid introduction of new tools can slide quickly from exciting to purely chaotic, leaving you feeling like you are falling behind. In today's episode, I explore how this changes the nature of our day-to-day work, and why the key to surviving this transition is shifting your mindset from a traditional "Software Engineer" to an "Agent Manager".

    • The Illusion of Velocity vs. Actual Chaos: While the big-picture promise of AI is that the software development pipeline will move exponentially faster, the reality on the ground often feels like unadulterated chaos. Trying to adopt every new tool while spinning up multiple agents to work on parallel tickets introduces a massive new cognitive burden.
    • The Context-Switching Trap: Understand why parallelizing agent workflows fundamentally changes your context-switching overhead. You are no longer just reloading context to build something yourself; you are reloading it to manage, review, and validate a building agent, which rapidly drains your cognitive ability and leads to burnout.
    • The "Agent Manager" Mindset: Treating AI as just a "smart autocomplete" while you try to do the same old job will not work. You need to start viewing your role more like assembly line or process management, focusing on facilitating the system rather than typing every line of syntax.
    • Adopt Old-School Quality Control Tactics: Discover how traditional management methods are becoming essential for individual contributors. Just like a factory manager doesn't inspect every single item off the line, you must develop methods for spot checks, anomaly detection, and standardizing outputs to evaluate the quality and quantity of your agents' work.
    • Shift Your Work Upfront: Recognize that your core effort must move to the specification and planning phases. Your job is increasingly about setting the context, defining the prompt, and establishing strict guardrails before the agent begins its work.
    • Redefining Your Work in Progress (WIP): Proven principles like limiting WIP and focusing on finishing rather than starting are more important than ever to reduce cognitive burden. However, you must adapt these principles to fit a workflow where you are managing processes rather than manually coding.
    • Episode Homework: Take a step back and ask yourself: "What is my true work in progress? Am I actually manually doing these tickets, or am I managing the processes that produce quality ticket work?".

    🙏 Today's Episode is Brought To you by: SerpApi

    No matter what you're building, SerpApi is the web search API for your needs. If you're building an application that needs real-time search data—whether that's an AI agent, an SEO tool, or a price tracker—SerpApi handles it for you. ● Make an API call and get back clean JSON. ● They handle the proxies, CAPTCHAs, parsing, and all the scraping so you don't have to. ● They support dozens of search engines and platforms, and are trusted by companies like NVIDIA, Adobe, and Shopify. ● If you're building with AI, they even have an official MCP to make getting up and running a simple task. Get started with a free tier to build and test your application before you commit. Go to serpapi.com.

    📮 Ask a Question

    If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

    📮 Join the Discord

    If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

    🗞️ Subscribe to The Tea Break

    We are developing a brand new newsletter called The Tea Break! You can be the first in line to receive it by entering your email directly over at developertea.com.

    🧡 Leave a Review

    If you're enjoying the show and want to support the content head over to iTunes and leave a review!

26. AI Moves the Bottleneck - Are You Ready for What That Means For Your Career?

    March 3, 202630 minEpisode 1288Play next

    AI is bringing massive changes to our industry, but it's not just about how fast you can write code or use agentic flows. In this episode, I explore how AI is fundamentally shifting the economic bottleneck of …

    Show notes

    AI is bringing massive changes to our industry, but it's not just about how fast you can write code or use agentic flows. In this episode, I explore how AI is fundamentally shifting the economic bottleneck of software development, and how you can use your systems-thinking engineering mindset to adapt and thrive in this new era.

    🎧 Episode Notes: The Engineering Bottleneck Shift

    For years, the software development pipeline was designed around one core assumption: engineering is the most expensive and restrictive bottleneck. Because of this, organizations optimized heavily for upstream risk mitigation to ensure we only built what was absolutely necessary. But AI is changing that math, making the act of coding significantly cheaper and faster. Here is what happens when that bottleneck breaks:

    • The Historical Cost of Bugs: I look back at the Windows 95 era, where physical software delivery meant post-release bugs were incredibly expensive, demanding massive upfront QA.
    • The Continuous Delivery Precedent: Discover how the internet made software updates cheap, which fundamentally changed the ROI of risk mitigation and enabled fast, iterative soft releases.
    • The Upstream Shift: Understand why, as engineering throughput increases by 50% to 100% due to AI, the new organizational bottlenecks will rapidly shift upstream to product, design, and decision-making.
    • Optimizing for Speed Over Risk: Learn why companies will likely begin to lessen their focus on risk mitigation (outside of catastrophic data breaches) to prioritize higher volume throughput and decision speed.
    • The New Iterative Workflows: Explore the potential for consolidated roles where engineers, PMs, and designers use AI to make rapid, on-the-fly product decisions together without traditional hand-offs.
    • Your Core Engineering Value: Remember that punching cards or manually managing memory didn't define engineers in the past, and manually typing code doesn't define you now. Your true value is your ability to approach problems with a systems-thinking mindset.

    🙏 Today's Episode is Brought To you by: Unblocked

    Your coding agents have access to your codebase, but access doesn't directly translate into context. Agents often lack the reasoning to understand your architectural decisions, team patterns, or why an API is shaped the way it is—leading to bad outputs and wasted tokens. Unblocked is the context layer your agents are missing. It synthesizes your PRs, docs, Slack messages, and Jira issues into organizational context that agents actually understand so they write higher-quality code with fewer correction loops. Get a free three-week trial at getunblocked.com/developertea.

    📮 Ask a Question

    If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

    📮 Join the Discord

    If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community by visiting https://developertea.com/discord today!

    🧡 Leave a Review

    If you're enjoying the show and want to support the content, head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.

27. Listener Question - Abdul Asks About How to Balance Career Strategy Between Money, Meaning, and Skill Transitions

    February 24, 202635 minEpisode 1287Play next

    Today, we are tackling the natural tension between the desire to make more money—getting a raise, finding financial stability—and the desire to have meaningful, purpose-driven work. We are diving into a …

    Show notes

    Today, we are tackling the natural tension between the desire to make more money—getting a raise, finding financial stability—and the desire to have meaningful, purpose-driven work.

    We are diving into a fantastic listener question from Abdul, a front-end engineer with 10 years of experience who has hit a salary ceiling. He is trying to figure out how to pivot into higher-paying domains like backend or AI without making a risky leap that forces him to start over at the bottom rung.

    🎧 Episode Notes: Balancing Money, Meaning, and Skill Transitions

    When you hit a wall in your career, it often feels like you have to trade away the work you love just to achieve your financial goals. In this coaching-style episode, we break down Abdul's situation to help you rethink how you navigate financial constraints and career transitions.

    • Question Your Assumptions About Money: Discover why "making more money" isn't inherently a bad or vague goal. If your intent is to provide for your family, help elderly parents, and build a risk-mitigating financial buffer, your goal is actually highly instructive and values-driven.

    • The Illusion of Static Roles: Learn why job descriptions exist primarily as "skill buckets" to help companies hire. Once you are inside the company, your role is not concrete—it is a fluid spectrum that can shift as you adapt to new technologies.

    • Grow Where You Are Planted: Instead of making a massive, unrealistic leap to a completely new role, learn how to organically expand your skill set. Talk to your manager about taking on backend or AI tickets, or trading tasks with coworkers to build new skills without uprooting your career.

    • Redefining Financial Necessity: Understand how to evaluate the timeline and "shape" of your financial constraints. If financial necessity is your absolute dominant constraint, you must optimize your strategy specifically for stability and risk mitigation.

    📮 Ask a Question

    If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

    📮 Join the

    If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community by visiting developertea.com/discord today!.

    🧡 Leave a Review

    If you're enjoying the show and want to support the content, head over to iTunes and leave a review! It helps other developers discover the show and keeps us focused on what matters to you.

28. AI-Era Employability and Job Security for Software Engineers - Mental Models for Finding a Competitive Advantage Without Selling Out

    February 18, 202641 minEpisode 1286Play next

    I've been delaying this episode for a long time because the topic is genuinely difficult and, for many of us, scary. AI is threatening not just to our livelihood, but to our sense of self-worth as creators.In …

    Show notes

    I've been delaying this episode for a long time because the topic is genuinely difficult and, for many of us, scary. AI is threatening not just to our livelihood, but to our sense of self-worth as creators.

    In this episode, I don't offer false guarantees about job security. Instead, I frame the problem through the lens of microeconomics and rational incentives to help you understand how to remain employable. We discuss why you must separate your ego from your current skill set and how to position yourself not as a competitor to AI, but as a force multiplier.

    • The Hard Truth: I explain why the "abstinence" approach—hoping the industry rejects AI or that it turns out to be a bubble—is a high-risk gamble that is unlikely to succeed.

    • Ego vs. Employability: We discuss the difficult mental shift required to disconnect your self-worth from the act of writing code manually, allowing you to adopt new tools without feeling like you are losing your identity.

    • The Microeconomics of Your Job: Understand the cold reality that a rational market only pays you if you generate more value than you cost; if AI can do the same task with less risk or cost, the market will choose AI.

    • The Non-Zero Sum Game: Learn why the economy isn't a fixed pie. The goal isn't just to survive, but to recognize that the combination of Human + AI can generate more total value than either can alone.

    • Multiplicative Value: I challenge you to stop thinking about linear skill acquisition and start thinking like a manager: how can you use AI to multiply your output and become indispensable?

    • Accepting Atrophy: We confront the reality that your core coding skills may degrade over time as you rely on AI, and why accepting this trade-off might be necessary for your career survival.

    🙏 Today's Episode is Brought To you by:

    If you are building an application that needs real-time search results—especially if you are working with LLMs—you know that stale data is a problem. SerpApi is the live web search API for your application.

    • Get real-time search results fast, directly in your app as JSON.

    • Bridge the gap for LLMs that are locked to a training date.

    • Trusted by companies like NVIDIA, Adobe, and Shopify. Get started with a free tier to build your full integration before you commit. Go to serpapi.com

    📮 Ask a Question

    If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

    📮 Join the

    If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

    🧡 Leave a Review

    If you're enjoying the show and want to support the content, head over to iTunes and leave a review!

29. Why Getting Paid Stole Your Drive and How to Get Into the Flow Again (Career Growth Accelerator)

    February 11, 202622 minEpisode 1285Play next

    Do you remember the early days of your career? You likely spent hours coding late into the night, fueled not by a paycheck, but by the sheer joy of building. But somewhere along the way, that intrinsic fire …

    Show notes

    Do you remember the early days of your career? You likely spent hours coding late into the night, fueled not by a paycheck, but by the sheer joy of building. But somewhere along the way, that intrinsic fire faded, replaced by the extrinsic motivators of Jira tickets, performance reviews, and ultimately the almighty dollar.

    In this episode of the Career Growth Accelerator, I explore why this shift happens and how it might be the very thing keeping you stuck. We discuss the "Overjustification Effect"—how getting paid for your passion can actually degrade your performance—and how to reclaim the autotelic personality required to enter a flow state and accelerate your career.

    • The Overjustification Effect: Learn why introducing extrinsic rewards (like a salary) for a task you inherently enjoy can weaken or completely replace your intrinsic motivation, eventually making the work feel like a chore.

    • The Loss of Flow: Discover how moving from hobbyist to professional changes your relationship with the work, often stripping away the conditions necessary for "flow state," such as risk-taking and immediate feedback.

    • Autotelic Personality: Understand the concept of being "autotelic"—doing something for its own sake—and why this trait is critical for high-quality, creative work that pushes your career forward.

    • The Stagnation Trap: Recognize that if your only motivation is doing what is required to get paid, you are unlikely to take on the voluntary challenges necessary to grow to the next level.

    • Reclaiming Your Drive: I discuss how finding pockets of intrinsic motivation—even if they are ancillary to your main job—can reignite your ability to enter flow, improve your work quality, and break through career plateaus.

    🙏 Today's Episode is Brought To you by:

    If you are building an application that needs real-time search results—especially if you are working with LLMs—you know that stale data is a problem. SerpApi is the live web search API for your application.

    • Get real-time search results fast, directly in your app as JSON.

    • Bridge the gap for LLMs that are locked to a training date.

    • Trusted by companies like NVIDIA, Adobe, and Shopify. Get started with a free tier to build your full integration before you commit. Go to serpapi.com

    📮 Ask a Question

    If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

    📮 Join the

    If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community today!

    🧡 Leave a Review

    If you're enjoying the show and want to support the content, head over to iTunes and leave a review!

30. The Meta-Habit of High Performers: How Outer Loops Unlock Growth (Career Growth Accelerator)

    February 3, 202626 minEpisode 1284Play next

    🎧 Episode Notes: The Meta-Habit of High Performers: How Outer Loops Unlock GrowthIn today's episode, we are discussing one of the most common habits I see in high-performing managers and senior engineers. It …

    Show notes

    🎧 Episode Notes: The Meta-Habit of High Performers: How Outer Loops Unlock Growth

    In today's episode, we are discussing one of the most common habits I see in high-performing managers and senior engineers. It isn't a single trick, a morning routine, or a specific productivity hack—it is a meta-habit. It is a specific way of thinking about how you spend your energy and time to avoid the burnout that comes from working hard without seeing commensurate gains,.

    • The Burnout Trap: Understand that if you keep putting more energy in without getting equal or greater results out (sub-linear returns), you are heading for a wall. You cannot simply "grind" your way to the next level,.
    • Recognize Your Default Loops: Whether you know it or not, you are already running "loops"—automatic heuristics and behaviors that define your decisions, like "while happy at job, stay at job",.
    • The Inner vs. Outer Loop: Learn the difference between the Inner Loop (your execution, habits, and daily protocols) and the Outer Loop (the meta-observation that evaluates the system).
    • Governing the Experiment: Discover how to use an Outer Loop to set longer-term conditionals for your career experiments (e.g., "I will try this until X"), preventing you from reacting emotionally to single data points,.
    • Systematic Evaluation: Move from making random changes to making informed adjustments by stepping out of the daily grind to evaluate the trajectory of your habits,.

    🙏 Today's Episode is Brought To you by: Unblocked

    There’s a good chance you’ve already tried a few AI code review tools — and you’re probably ignoring most of their comments.

    Not because AI can’t review code, but because it’s missing context. Most AI reviewers focus on surface-level issues: style nits, obvious refactors, or restating what’s already clear from the diff. Meanwhile, the things you actually care about, like whether a change violates an earlier architectural decision or quietly duplicates existing logic, go unnoticed.

    That’s the problem Unblocked is built to solve.

    Unblocked’s AI code review is grounded in decision-grade context, prior PRs, design discussions, documentation, and system-level constraints—the same context senior engineers rely on when reviewing code.

    Teams using Unblocked report fewer comments, higher signal, and automated reviews they actually trust — enough that many have turned off other AI review tools entirely.

    Even if you’ve already written off AI code review, Unblocked is worth a look.

    Get a free three-week trial at getunblocked.com/developertea.

    📮 Ask a Question

    If you enjoyed this episode and would like me to discuss a question that you have on the show, drop it over at: developertea.com.

    📮 Join the Discord

    If you want to be a part of a supportive community of engineers (non-engineers welcome!) working to improve their lives and careers, join us on the Developer Tea Discord community by visiting https://developertea.com/discord today!

    🧡 Leave a Review

    If you're enjoying the show and want to support the content head over to iTunes and leave a review! It helps other developers discover the show and keep us focused on what matters to you.

These are the latest 40 of 1,317 episodes. You’ll find older episodes in the podcast’s feed.