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

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!

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!

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 QuestionIf 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 DiscordIf 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 BreakWe 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 ReviewIf you're enjoying the show and want to support the content head over to iTunes and leave a review!

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!

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!

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!

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!

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!

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!

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!