The Fundamentals

I am not a big-time sports fan. I love a good hockey game, but I just generally don't get excited about the rest of the sports year. There is, however, one thing that I've learned a great deal about from watching sports: the importance of FUNDAMENTALS.

Every sport has them; key basic skills upon which all of the strategy depends. A receiver on a football team might be taught to "watch the ball all the way into your hands"... Similarly a batter in a baseball game is told from his first swing in Little League to "keep your eye on the ball".

Software engineering has its own set of fundamentals: the quiet, consistent skills that can feel pretty boring to practice, but over time build absolute greatness.

Don't Confuse Fundamentals With Frameworks

We've all met the "armchair quarterback"... who can explain in painful detail all the things their team's captain is doing wrong. The thing about armchair quarterbacks is that they have never been on the field. They make their judgments sound so simple, but they're not making those calls while being chased by huge defensive linemen set on turning them into a greasy spot on the turf!

Similarly, one of the easiest mistakes to make in software engineering is to substitute tool familiarity with skill mastery. Yet we see it constantly: we assign an infrastructure team "ownership" of a CI/CD tool, but they've never built and deployed an application before. Decisions made in these kinds of situations are suspect at best.

We talked recently about how technology teams rely too heavily on frameworks; think of this like a team that continually switches playbooks instead of drilling the basic techniques. It doesn't matter how flawless your strategy and tactics are if your players can't catch the ball... and it won't matter how airtight your revenue plan is if your developers don't handle the basics of testing and clean code.

This leads me to a simple truth:

Sustained excellence in engineering comes from practicing a small set of fundamentals deliberately.

The Fundamentals

Let's look at some basics that every software engineer should practice constantly!

Reading the Field: Problem Decomposition

When a football team lines up for a play, the quarterback "reads the defense": looking at the positioning of each of the defensive players, and what each of them is looking at and communicating to each other, the way they shift their weight as they take their stances... there is an incredible amount of information that he has to process in order to know where his team can strike to be successful.

A great software engineer does the same thing: they break large problems down into smaller ones. They anticipate changes before the customer asks for them. They use intuition and experience just like the quarterback does, only with the goal of delivering better software.

Form and Footwork: Clean Code Habits

A good hockey player doesn't think about skating - they just do it. If they had to attend constantly to the location and position of their feet, the play would completely pass them by.

Software engineers don't have to worry about footwork so much, but the idea of clean code habits: clarity, naming, simplicity? Those have to be practiced until they're automatic. Just like a new skater focuses on their footwork, a new software engineer is going to have some difficulty with clean code at first... but the more they work at it, the more naturally they'll be able to do it.

Drills and Reps: Testing and Feedback Loops

Batting practice is an exercise in focusing on the ball all the way to the moment it hits the bat. Whenever you see a photograph of a player making contact with a home run ball, look where he's looking: directly at the ball. That's not a natural behavior; it's been trained into him with rep after rep after rep. Hundreds, even thousands of swings in the cage taught him never to take his eye off the ball.

For software engineers? Those reps are things like "Building CI/CD Pipelines" or "Test-driven Thinking". They're not natural behaviors, but rep after rep after rep, a good engineer trains good behaviors until they're great.

Team Play: Communication and Review

A sports team can't wait until game day to execute... they practice together. After they're beyond the individual drills, they have to hit the field together. There they learn to anticipate each other's actions, to think as one, to trust their teammates to be where they're needed at every moment, even when they can't see them.

A developer team has to know how to work well together too. They have to establish a way to interact for code reviews, design discussions, and documentation. There are tons of ways to disagree, and technologists love their Holy Wars!

Film Study: Learning from Failures

Every professional team prepares for their next game by watching film. They study their opponent, looking for tendencies or tells that they can exploit to win the match.

In the software engineering world, we aren't usually competing against another team (at least not directly)... but this concept of "game tape" still applies! Think of Incident Postmortems and Sprint Retrospectives: these are the moments where we study to improve.

Practice Over Performance

It probably doesn't surprise you that professional athletes practice, does it? But in one sense, it's a bit absurd! "eh, the tennis player understands how to hit with a topspin." Yet... they practice. Our minds and bodies learn through repetition, and practice provides that. Maybe engineers can learn from this example!

A refactoring kata (remember our adventure in Season 4, where we worked on The Gilded Rose?) is a great way to practice solo... but we can use things like mentoring or pair programming, and writing design docs, to help us practice the parts that aren't isolated.

This might require you to reframe a little bit: is your primary driving force "Velocity", or "Craft"? (Said a little differently, are you focused more on Quality or Speed?)

Wait, Blink: Isn't AI Going To Fix All This?

Ya know, I don't want to be the guy who says "well, ackshually...."

But that's exactly what I'm going to do here.

I have seen firsthand the amount of chaos that a single vibe-coder can make in a production codebase. (Spoiler Alert: there's an upcoming post on this topic, stay tuned!) While I'm all in favor of using LLM assistance to accelerate your work... you still have to keep your hands on the wheel here! Think about it this way: if something bad happens because of some AI-generated code that you pushed... are they going to fire the AI?

The Payoff: Fundamentals Make Freedom Possible

In sports, fundamentals free you to improvise under pressure. In software, they let you adapt to change, scale safely, and innovate confidently.

The championship sports teams aren’t skipping the fundamental steps; they’ve mastered the basics so they can move without thinking. Similarly, the fastest technology teams don't skip their basics - they build off them in order to deliver faster.

What fundamentals do you need to hit the practice field and work on today?