Developer Tea

Afleveringen

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

   5 november 2026 · 17 min

   Afspelen
   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. Lees meer

   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. Tha…

2. Signs You May Have a Regressive Mindset

   24 oktober 2026 · 17 min

   Afspelen
   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. Lees meer

   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: …

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

   30 september 2026 · 17 min

   Afspelen
   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. Lees meer

   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 atro…

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

   21 september 2026 · 13 min

   Afspelen
   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. Lees meer

   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 F…

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

   5 september 2026 · 16 min

   Afspelen
   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. Lees meer

   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 — …

6. Why Reducing Complexity Is A Sign of Seniority

   21 augustus 2026 · 15 min

   Afspelen
   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. Lees meer

   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 re…

7. A Pragmatic Definition for Accountability

   14 augustus 2026 · 23 min

   Afspelen
   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. Lees meer

   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 …

8. Using Substition to Make Decisions Simpler

   22 juli 2026 · 18 min

   Afspelen
   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. Lees meer

   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…

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

   10 juli 2026 · 25 min

   Afspelen
   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. Lees meer

   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 brill…

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

    24 juni 2026 · 19 min

    Afspelen
    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. Lees meer

    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…

Alle 1.317 afleveringen →