Fundamentals come up in every field, from sports to chess to software, but we rarely stop to define what a fundamental is. In this episode of Developer Tea, I look at why fundamentals matter now more than ever for software engineers, and why a profession built on layer after layer of abstraction makes that understanding so important.

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.

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.

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.

A 1967 study gave us the concept of learned helplessness — but the same researchers later reversed it. Passivity is our default state; control is what we learn. In this episode, I unpack what that neuroscience means for how you face hard things in your career, and why the action you take doesn't have to match the size of your problem.

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.

Accountability is one of the most important concepts in your career—and one of the most frequently weaponized. In this episode, I unpack why so many of us have a visceral reaction to the word, and offer a pragmatic, functional definition that reframes accountability as something a good engineer actually invites. Drawing a parallel to software bug reports and root-cause analysis, I explain how healthy accountability creates clarity of expectation rather than surprise punishment.

The skills you've built for reading people, reviewing code, and making calls under uncertainty all rely on the same brain shortcut: substituting an easier question for a hard one. In this episode, Jonathan explores how to take that automatic mental trick and use it on purpose — shrinking weighty, paralysis-inducing decisions down to the small, low-stakes actions they're actually made of.

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.

The skills you spent years building are getting cheaper to replicate—but that's not where the friction lives. In this throwback episode, I unpack why agentic coding hasn't made your team faster, and why the answer is the oldest model in the book: the theory of constraints. If you're a manager or a senior engineer being asked "why can't this go faster," this one's for you.

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.

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.

Feedback is one of the hardest skills in any career, and most of us have only experienced a handful of moments where it actually drove positive change. In this episode, Jonathan explores how to give and receive feedback that leads to real growth — starting with setting your ego aside, getting clear on your goal, and using behavior-based models like SBI and Netflix's Four A's. It's a durable skill that turns a contentious, dreaded conversation into a genuine pathway to career development.

If you're a software engineer right now, the questions you're asking about your career probably feel existential. We've been spending a lot of time on this show preparing for the changing industry—what skills matter, what mindset works—and one answer keeps surfacing: your ability to update your mental models is itself the critical skill. In today's episode, I push on that idea directly. Some of the thinking models that defined good software engineering for the last decade deserve real scrutiny now, and a few of them may deserve to be thrown out entirely. This is an uncomfortable ask, especially for those of you who earned your wisdom the hard way—but the engineers who can hold their hard-won models loosely are the ones who won't hit a ceiling.

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.

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.

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.

If you've felt like the show has leaned hard into agentic coding lately, today's episode opens with why: the realistic future of software engineering includes these tools, and pretending otherwise makes this show less useful to you. From there, I want to give you something practical — a transferable skill that will compound in value as LLMs get more capable, and that also makes you a stronger communicator with humans. The skill is learning to speak in **meaning-rich, high-specificity abstractions**.

Many engineers have built their careers on the belief that coding is their primary value — the flagship skill, the gate opener, the reason they get paid. But if AI can do a large slice of that implementation work, then coding-as-your-core-value leaves you in a very narrow place. In today's episode, I want to reframe how you think about your skills, and give you a simple three-part framework for deciding which skills are actually worth investing in as the industry shifts.

Your job is changing faster than ever, and it might be tempting to believe that chaos is simply the new norm. In today's episode, I want to push back on that idea. Part of your role as a senior engineer or leader is to make sure chaos doesn't win — not just to rein it in reactively, but to go on the offense and create order. We'll talk about one important way to do this: protecting the ceremonies on your team.