« All Episodes

Fundamentals Will Help You Survive the Constant Acceleration of Software Engineering

Published 9/21/2026

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!

Transcript (Generated by OpenAI Whisper)

Maybe now more than ever before in our careers, fundamentals matter. You've probably heard this a million times, not just in software engineering, but across all industries, even hobbies, sports, other areas of your life, you're going to hear people talk about fundamentals. Getting back to the fundamentals is the kind of common phrase that you might hear. And I want to talk a little bit about why fundamentals are a useful concept. What even is a fundamental? What are we talking about when we say fundamentals? fundamentals. And how can you frame that in your career and in your career growth? How can you focus on fundamentals in the first place? My name is Jonathan Cottrell, and you're listening to Developer Tea. My goal on the show is to help driven developers like you find clarity, perspective, and purpose in their careers. When we talk about getting back to the fundamentals, a lot of the reason, let's take sports for example, a lot of the reason why we would say get back to is because we learn fundamentals early. We learn what we might call basic skills or the building blocks. These are the starting points. In basketball, it would be dribbling, and in football, it would be blocking. In chess, it might be an opening move. In software engineering, it might be simple things like reliability. It might be the testing, being able to assert the testing pattern for setting up a test, running the executions, tearing down the test and cleanup. These are fundamental concepts. Design patterns might be considered a fundamental. Maybe it's a step beyond fundamentals and really the fundamentals are something like readability. And to be clear, fundamentals are not always rules. They may just be behaviors, habit patterns, heuristics. These are things that tend to be building blocks for other things. Fundamentals in coding may also include logic structures, right? Basic logic structures. Fundamentals in communication might be a basic communication model with a sender and a receiver and feedback and noise, right? These are concepts that are are fundamental to the domain of communication. And so these concepts are fundamental because they are building blocks and because they are kind of the core principle concepts of the domain that are not really going to change. And this is really important for software engineers to understand because in particular in this profession, a lot of the progression that we experience, a lot of the growth that we experience, a lot of the industry movement that we watch is the result of some kind of abstraction. We can see this very heavily in software engineering and perhaps not quite as heavily in a lot lot of other professions. If you think about, for example, the application of law, and we talk about this very often because it is kind of an interesting comparison, the application of law has some fundamentals that tend to be practiced in very similar ways as to how they were practiced, let's say, 50 years ago. Now, there may be some contemporary interpretations or there's parts and pieces of that where there is innovation, right? But in technology and especially in knowledge work and abstract technology, software in particular, abstraction, it can move very quickly. And the reason for this is because a lot of our work is symbolic in its fundamental nature. Again, going back to fundamentals, one of the fundamentals of coding is that it is a very large experiment of symbology. We create symbols that represent some idea to us as humans, but they map to a hard reality in code, and more specifically, a physical reality in chips. Somewhere there is a chip that holds instructions. There's a bit that is flipped. There's electrons that are moving. as a result of this layers and layers and layers of abstraction, right? And so the abstraction over the past, let's say, 50 years has become more and more conceptually attached to language abstraction. And what this means is that instead of working on core fundamentals, in other words, instead of saying, you know, know, we're going to move from one time, one way of adjusting bits to another way of adjusting bits. We're working in a in a linguistic abstraction. All right. So stick with me here for a second. This means that we can start using words like object. We can start using words like like flow, or we can use concepts like durable object. I already said object before, but we can use concepts like function. And we can continue to be more abstract, thinking about mesh and graph. And these are all these kind of primitive ideas that are expressed in abstractions. Okay, so why is this important? How does abstraction relate to fundamentals? There are still fundamentals underneath all of these abstractions and more importantly, you can understand the fundamentals of the abstraction itself. Okay, so what does that mean? Let's take for example the characteristics of two different database technologies. technologies. And one database technology, let's say like a Postgres database, has one set of characteristics. We won't enumerate all of them, but let's say if the structure of your data is, if it's highly structured, if it's, you know, kind of predictable, if it's relational in particular, then Postgres tends to kind of match that from a fundamentals perspective, right? And if you understand the fundamentals underlying, then you can also understand that other relational databases could probably, most likely, if they kind of follow the same abstraction patterns, can probably fit a similar job, right? And very similarly, if you understand the primitives of NoSQL, if you understand the primitives of an index lookup, for example, then you don't necessarily have to worry so much about learning every single abstraction that exists. You can understand the fundamentals of a particular abstraction and compare it to and look for the underlying characteristics, right? This is kind of the thrust of principles-first thinking. We want to understand the underlying characteristics. We're kind of decomposing those characteristics so that that we can better recompose those things into solutions that we care about. We can think about this applied to a lot of different domains. We can think about it applied to business domains, for example. What are the characteristics of a particular offering that make it more competitive than another offering, right? There's some characteristics that we could compare, things that we do or don't care about. Rather than having to understand everything on the market, rather than having to keep up with every single new technology, new framework that comes out. We can understand some of the characteristics of LLM so that when a new model releases from one provider versus another provider, we know what characteristics we can compare. There's a new thing that happens in this provider or in this model that's not happening over here. Then we can have a clearer understanding of the differences between these rather than two wholly different things, right? So they share some fundamentals. There's some underlying structure, underlying structure to what's going on with this. You know, you can kind of think about fundamentals as like categories of characteristics, right? And to be clear, you know, we're kind of mixing the concepts of practice with technique, right? So practice meaning, you know, fundamentals in practice might be, again, going back to sports, dribbling, right? Fundamentals in practice at work might be practicing feedback on a regular basis. That's still a good fundamental concept to carry with you. And then there's also this way of analyzing the world or looking at new technology from the perspective of fundamentals. What are the characteristics, the core characteristics you know, that makes something up. And so, you know, if you're able to break things down in terms of their fundamentals, both in terms of the things that you need to know how to do, right, the characteristics of your action or the characteristics of your behaviors, your habits, your practices, and the characteristics of the tools that you're using so that you can compose your tools and you can compose your actions. now you're understanding how to think fundamentals first. You're thinking principles first, right? And so this is really important because the overload, the overload of abstraction, right? As we continue to abstract more things on top of things, the only way that you can operate in a constantly abstracting environment is to step away from it, right? And to understand how these things can move without you paying close attention to every single one. And really all you're looking for is fundamental changes. LLMs share fundamentals. Dynamic languages share some fundamentals. Good communication and people practices. They're going to have some constant and consistent fundamentals. So this is really critical. and what I would challenge you to do in closing out this episode is look at your your work and try to figure out where are you two in the weeds have you taken a step up to consider what are the fundamental characteristics of the decision that I'm making here right a good example of this we deal with this in my current role all the time the fundamentals of of the risk profile that we're accepting, you know, the risk and reward. This is another, you know, principles first thinking kind of challenge in this specific organization I'm in, but also in the industry at large. How do we determine what is the right level of risk in a given scenario? And we can't, you know, you, we, engineers, we can't approach this with a one size fits all, it's important to understand the fundamental characteristics. So the key for you to understand is where are you too deep? Where are you thinking too granularly? Where are you not paying attention to the abstraction class, right? The class of things or the consistent things across multiple iterations or abstractions that are shared, that you can pay attention to them from a step away. And this is going to give you a higher leverage for being able to understand when things are changing, what should you be paying attention to instead of analyzing every little detail of every little change. Thank you so much for listening to today's episode of Developer Tea. I hope you enjoyed this concept of abstraction and fundamentals and how those relate to each other, how we can keep up in the industry. This is how you can kind of keep a level head, right? You don't have to understand everything. You don't have to know everything about every new language or even follow every release of every new language. What you really care about is, is there a fundamental shift? Is there something changing about the core characteristics of this thing that I'm using? Thank you so much for listening. Until next time, enjoy your tea.