DEV Community: Ben Link

The Adventures of Blink S5e7: Winning is Everything

Ben Link — Thu, 16 Apr 2026 11:05:00 +0000

Hey friends! Season 5 of The Adventures of Blink continues - we have a game that works, but we're missing something pretty important: the Win screen! Come join me today as we make it possible to win our game.

Leave me a 👍🏻 and a 💬 to help the channel, and subscribe so you won't miss future episodes!

The Adventures of Blink S5e6: On So Many Levels

Ben Link — Thu, 09 Apr 2026 11:00:00 +0000

Hey friends! Today on The Adventures of Blink, we're making our game last longer... by adding different levels. In order to make them work, we're going to need a level loader...

Come along and let's build together! Leave me a 👍🏻 and a 💬 to help the channel!

The Adventures of Blink S5e5: Collisions!

Ben Link — Thu, 02 Apr 2026 11:30:00 +0000

Hey friends, welcome to The Adventures of Blink! Today we continue our breakout clone build with some work on one of the key mechanics in the game: the ability for objects to collide with each other.

Make sure you leave a 👍🏻 and a 💬, and subscribe so you'll stay connected!

The Adventures of Blink S5e4: The Paddle and the Ball

Ben Link — Thu, 26 Mar 2026 11:45:00 +0000

Hey friends! Today on The Adventures of Blink, we've finally got the foundation we need, and it's time to start working on some gameplay features! We'll start with two key features: the Paddle and the Ball.

Make sure you leave a 👍🏻 and a 💬, and subscribe!

The Adventures of Blink S5e3: A Menu in Pygame

Ben Link — Thu, 19 Mar 2026 11:30:00 +0000

Hey friends! Today on The Adventures of Blink, we're building a main menu for our Breakout clone using Pygame. I know, I know... we don't have a game yet, but we're building a foundation here, gameplay's coming soon!

Make sure you leave a 👍🏻 and a 💬, and subscribe!

The Adventures of Blink S5e2: Logs and Configs

Ben Link — Thu, 12 Mar 2026 11:30:00 +0000

Hey friends! Today we continue building our Breakout clone with a look at how to set up logging, and how to build a configuration file for our game to use.

Come hang out, leave me a 👍🏻 and a 💬, and subscribe to the channel so you'll get notifications when new episodes drop!

The Adventures of Blink S5e1: Kicking off the Build

Ben Link — Thu, 05 Mar 2026 12:25:00 +0000

Hey friends, welcome to Season 5 of The Adventures of Blink! Today we kick off the new season of Youtube videos with the setup work for a retro gaming build: We're writing Breakout in Python!

Make sure to leave me a Like 👍🏻, a Comment 💬, and Subscribe to the channel. It's free for you, but it helps me reach more people who can learn from our adventures together!

Journal of a Half-Committed Vibe Coder

Ben Link — Thu, 26 Feb 2026 12:15:00 +0000

As I'm prepping Season 5 of The Adventures of Blink, I've been building the code for our Adventure ahead of time.

SIDE NOTE: Season 5 starts NEXT WEEK!!!! Episodes drop on Thursdays just like our Adventures here - make sure you come by the Youtube channel and leave me a like, a comment, even just an emoji... and click subscribe. It's free and it helps more people find our Adventures together!

In the process of building our app, I've been using AI as a companion. It's readily available, usually faster than me wading through the docs for whatever random thing I need to remember how to do, and, well, most of all... I'm curious about it. There's tons upon tons of hype out there, and folks who've sold out to the idea that software engineers are going to be replaced next week. Is it true? One way to find out is to try it out and see... so the fact that I'm regularly building something for an education project is a really handy tool for experimentation. (Ooh, we should talk sometime about the value of building in public and learning in this fashion...💡💡💡)

Anyway... as I'm doing this, I thought I'd write down some things I learned from the process. What follows are some observations from several weeks of coding work.

You'll note that I call myself a "half-committed" Vibe Coder. What I mean by this is that I'm not necessarily meeting the definition of VibeCoding - I don't just yeet my requirements in there and tell the model to generate the code. I'm working alongside it, writing as much code myself as I'm asking it to write, and using it for sounding board and exploration.

Also, I do software work for a day job in addition to The Adventures of Blink. Some of my observations come from that work, too.

Watching a Bubble Pop In Real Time

The longer I use it, the less I trust AI tooling to take on big things. This is weird to me, because as I listen to the Hype Machine, they're recommending the exact opposite approach. "You need to give it more freedom! You need to write less code yourself and get the bot to do more for you!"

But literally every time I do this, it gets in over its head almost right away! The project we're building for Season 5 is a game... so it has a couple basic patterns to consider:

The game Event Loop
Screen painting logic
Loading & Saving

It's important to note that I'm not thoroughly designing every requirement and building a full project plan... because that's not usually how a hobbyist works. We like to build some basics, get a couple things working, and then try to add features. This isn't like a Waterfall shop where we have a couple of weeks of design phase to document every capability before anyone touches a keyboard.

This brings me to my first point:

Your Copilot will absolutely lead you down the Primrose Path

When I said "I'm thinking about building a Breakout clone game"... the LLM started in the middle. It began responding to the idea of building a Pygame-based application and constructed a main loop that initialized the game right in the window.

I had to stop it and say, "Hey, wouldn't the game's user experience be better if we had a main menu before just dropping you into the game?"

record scratch

It immediately built out the main menu code in our chat. But then I had to stop it again, and point out that I had an empty project structure - how am I going to organize the code files? Where will my art assets live? What about the app's configuration file, so that I'm not hard-coding all my variables into it? Automated tests?

My point in all of this is that you can't eliminate the human developer from this conversation. In its eagerness to please, AI completely bypasses the design thinking and decisions that make the project maintainable. It doesn't stop to ask questions about the big picture, it just builds...

...Like a brand-new junior developer.

Would you just turn a fresh-out-of-school new hire loose on your company's mission-critical applications with minimal guidance? If not... why would you ever do it with an AI?

The Token Consumption Loop

I gave my copilot a task to build a function with a very simple calculation in it that I didn't feel like doing (fight me, Trigonometry class was 2 decades ago 😏).

SIX ITERATIONS LATER, we have something that I'm still not completely happy with, but it's kinda functional. My copilot and I have argued over how this works for a couple hours at this point, and I'd be embarrassed to find out how many tokens I burned on the problem. I'm frustrated with it and at the point where I'm most likely going to pitch the whole thing out and rewrite from scratch. My "time-saving" vibe-coding prompt has cost me more time than stopping to figure it out by hand.

That wasn't a one-off situation, either; I've had the same experience repeatedly.

Another observation I've had in this space is that when I ask it to do something, it... talks. A LOT. I can ask a question that should resolve to a one-liner, and it feels the need to explain the whole history of the process of getting that to a one-liner. Even when I ask it to be terse, it still tries to explain itself more.

In a world where tokens-per-invocation is highly monetized (and therefore, tightly controlled by budget), it's just not cost-effective... and even borderline suspicious. If you're selling tokens, it certainly makes sense that you'd squeeze as many as you can out of every invocation...

Ensloppification

At work, I picked up a story to do some refactoring on a 1,000-line python module. The signs of vibe-coding are there:

One file, a thousand lines long.
Three different classes declared in it.
The core functionality in the module wasn't even part of any of the classes, it was just riding along in the file.
No organization to the code - just a plate of 🍝 to try to trace my way through.
Circular import logic.
Minimal documentation / comments, and what was there didn't really explain anything.
Files were opened and read and their content was never used before the variable was used to open a different file and read it in.
Our static analysis tool had a stroke - one method scored 211 on the cognitive complexity calculator.

Now, it's important to realize:

The code works. The outputs match the inputs. If someone who's never done coding work before picked this up, they'd be excited by it (and that's kinda the story-- the business execs saw it run and were thrilled with how fast we delivered).

But this module is the first use case in what we anticipate will be a family of use cases... each of which will need a customized version of this module that plugs into the overall application frame.

In its current state, this code can't be an example to another developer of how to build your use case.

Think about it: the new requirement comes in to build the second use case, and what's the developer going to do? LOOK at the first one! And he'll spend days unraveling the spaghetti.

And now the arguers appear

A lot of you reading this will probably want to correct me, to explain why I'm being unfair to our new AI overlords, why my opinions are invalid.

That's totally cool. We should be debating these kinds of things, and we should do it in a civil manner. So here are some of the things I've already thought of as counterarguments to this post:

The "Junior Dev" Analogy is a Feature, Not a Bug

Blink, you should be scaling up so you have a collection of a hundred Junior Devs doing your bidding, while you're the Architect!

This feels compelling, and on the surface it seems like it should be empowering... but it doesn't reconcile with what we hear in the hype, does it? I just refreshed my LinkedIn feed and the first 3 posts were people telling me how AI Agents have ended software engineering, we just don't know it yet... how the AI-pocalypse is upon us and our entire profession is on the chopping block. So which is it? Are we being empowered or destroyed? Can't really be both.

The "Vibe Coding" vs. "Agentic Workflows" Gap

Blink, you're just doing it wrong. These problems exist because you aren't using $SOME_FRAMEWORK, or $SOME_MODEL.

I find it highly suspicious when anyone promises that I'll get all the benefits, as long as I just add this one other thing... because it becomes a perpetual "you need one more thing". I feel the ick, like when a pyramid marketing scheme person comes after me.

"Ensloppification" is a Human Discipline Issue.

Blink, you could actually cure ensloppification with AI if you just prompt it to produce clean code...

Here's the problem with this line of reasoning: AI is being marketed as a way to make it possible for ANYONE to build an app. And it's being used by ANYONE, regardless of their knowledge level, to build apps.

You're not wrong: the human is absolutely responsible for the quality of their code. But many of them probably don't know that yet. And they're going to put things out into the world that look like good apps... that work... that might even generate revenue... yet they're buggy and full of security holes and dangerous to use but there's no way to tell them apart from well-engineered production-quality systems.

We saw this just a couple weeks ago, when someone vibe-coded a platform that hit 1.5M users in 4 days. And then 3 days after that, the entire production database was accessed and leaked - API keys, emails, private messages.

Y'all. We have enough trouble keeping the bad guys out in traditional software engineering, and this vibe-into-production model is over here leaving the key in the doorknob.

Wrapping Up

I'm excited about new tech... it's a major reason why I'm in the field. What I'm not excited for is irresponsible uses of new tech. Our planet has enough problems already without us destroying the software that runs it.

All I'm asking for is a little caution and thoughtfulness. Is that too much?

You Don't Need Anyone's Permission To Make Life Better: A Blink Fairy Tale

Ben Link — Thu, 19 Feb 2026 12:30:00 +0000

REMINDER: We're TWO weeks away from Season 5 on The Adventures of Blink over on Youtube! If you haven't done it yet, stop by the channel and click subscribe so you'll get alerts when new episodes drop each week - I'd love for you to come on an adventure with me! This season is going to hit you right in the nostalgia with a retro game build - just something fun to work on to keep those coding skills sharp!

Once upon a Time, there was a magical kingdom that produced the best software known to all mankind. When villagers requested things, their needs were fulfilled quickly and generously. When things went wrong, the King's Guard (and often even the King himself) would come and set things right. Everyone lived in harmony.

But the kingdom had grown to the point that it was no longer possible for the king to manage it on his own.

He decided to appoint his two most senior noblemen, each of whom would administer half the kingdom on his behalf: The Duke of Development and the Earl of Operations. Unfortunately, these two noblemen were at odds with each other, and the king's meetings with the nobles were contentious and stressful. In his desire to have a little peace and quiet, the king built a wall right down the middle of the castle - the western tower was for Development and the eastern tower was for Operations. Now he could have some quiet... the two nobles couldn't interact any longer!

Interestingly enough, the villagers weren't moved around at all. When you left the castle, you'd find developer teams and operations teams living near each other and traveling freely through each other's lands.

The Kingdom Was Very Serious About Rules, though

When the castle was split, the king was adamant that the nobles would not encroach on each other's responsibilities, and he issued an edict titled "A Separation of Duties":

The Duke was responsible for ALL Development; no one in Operations could do that.
The Earl was responsible for ALL Operations; no one in Development could do that.

The two sides began to bicker and argue constantly over whether some specific task belonged to one side or the other... and large contractual agreements -- "Memoranda of Understanding", if you will -- were created to ensure that everyone in the realm KNEW unequivocally whose role any given task was. Entire Departments of the lesser nobility were ordered to manage all of these agreements and maintain them meticulously.

Changing anything required extensive permissions and approvals from people who lived in faraway villages. Entire committees had to convene, bringing in nobles from across the whole realm, any time anything needed to get done.

And if something went wrong, a special committee would gather to rewrite the rules "so this will never happen again".

And... nothing got better.

The rules were meant to prevent mistakes, but they mostly just prevented improvement.

The Subtlety That Was Destroying the Kingdom

The King wasn't some evil fiend. The Duke and Earl were well-meaning nobles. Yet everything went wildly off the rails. How did things become so argumentative?

The Process became a substitute for critical thinking.

A common trap of designing large organizations is that we believe we can codify everything. "Write a manual that explains everything that happens in our Company, and then just use that." This seems logical enough on the surface, but as the philosopher 😏 Mike Tyson famously said,

"Everybody has a plan until they get punched in the mouth."

Our need to control every outcome will always prove our undoing... because while you might be able to make your Process comprehensive, it will only succeed at enforcing obedience. Creativity, thinking on-the-fly, and making adjustments will be labeled negatively: first, as "out of Process", but then "noncompliant" or even "dangerous".

The act of improving things will be reserved for a few... and that will be perceived as 'privilege' rather than 'responsibility'. Don't you want everyone to feel responsible to make things better???

The Mysterious Traveler

One day a traveler from a faraway land arrived at the gates of the realm. He set up his shop in the market and became part of the community. As a newcomer, he listened intently to the kingdom's rules - not that he had to do anything to hear them, as they were shouted from the parapets of the castle every day:

"Follow the Process!"
"Separate the Duties!"
"That's Development Work! Send it to them!"

The voices were loud, and they were insistent. But the Earldom of Operations was suffering:

The Duke of Development was constantly making changes that no one in the other Duchy understood, and he was constantly pushing for changes to be made even faster and more frequently, beyond what anyone in Operations could do. There were never enough villagers in Operations.
Every time something broke, someone from an Operations village had to reach out for a senior nobleman from Development to come and assist. That meant things were broken for a lot longer, since the travel time was long between the two villages.

The traveler also heard that things weren't going well for the Duke of Development, either:

"The Kingdom's Treasury will be empty unless we make this change by next week!"
"Villagers are suffering; we can help them but things move too slowly through Operations!"
"We have a way to alert the King's Guard to problems faster, but we can't make the change until next summer according to the Roadmap!"

Something in particular gnawed at the traveler, however: in all his visiting and interacting with both sides of the kingdom, he never once heard anyone say, “You are forbidden from making this better.”

The only thing holding either side back from success was the wall that ran through the castle.

The difference between permission denied and permission never requested

The traveler, who had lived in both development and operations villages in other kingdoms, recognized that many of the problems faced in both villages could easily be solved by the other. So he decided to do something about it.

The First Small, Unapproved Good Deed

Late one night in his small house on the outskirts of the Operations village, he ran into someone who had been assigned a task. The person was planning to be up all night, because that's how long this task usually took. But this time, the traveler opened his Development toolbox and used the tools to solve it.

It wasn't much - a tiny fix, a small script that automated the task. It cut the time from hours down to seconds. He gave his fix to the villager and disappeared into the night.

The next night, he did it again - he wasn't rewriting all the Company's software, just connecting a couple of dots in a small, reversible, safe, and (most importantly) helpful manner.

He wasn't holding meetings. He didn't have a project on the Duke of Development's ledger. Nobody was signing off on these small fixes. Just empathy and skill, intersecting in an Operations village.

Amazingly, the world... didn't end.

The Quiet Magic of Small Improvements

Usually we refer to this kind of work as "Shadow Development"... but maybe that's giving it too "spooky" a name.

What if instead we decided to call this "stewardship"? Or "empathy"?

One small improvement makes another possible. And then another. And then another. Pain decreases, confidence increases.

Over time, we'll see others begin copying this behavior... just looking out for their brethren in Development and Operations... and even more interestingly, they're now treating BOTH Development AND Operations as brethren!

"Shadow Tooling" conjures a mental image of "The Resistance"... "The Rebellion"... but nothing could be further from the reality. When we engage in these kinds of improvements, we're trying to make it better.

The Fate of the Traveler

Gradually, the Operations village came to understand the Development village... and Development came to understand Operations. Through small acts of kindness (and dare I say, love?) the villages partnered again, each bringing their individual skills and talents to bear solving problems for the other.

At first, the Nobles didn't even know it happened.

But eventually, the change in posture was so striking that everything came to light. All the rule-bending, all the work done in the shadows... everything.

Leadership didn’t reward the change. But they also didn’t punish it.

What This Fairy Tale Is (And Is Not) Saying

First, let me tell you what this is NOT:

“Ignore security”
“Break production”
“Disrespect your teammates”

What it IS, though:

"Make small things better"
"Reduce suffering where you stand"
"Act within your competence"
"Leave things better than you found them"

Final Note: The Cost of Waiting for Permission

Collectively, we seem to think that "waiting for approvals" (waiting for permission) is a means of safety. Let's think about what it means in reality, though:

Broken systems stay broken
People disengage as their attention span expires
Good engineers become caretakers of misery
Organizations confuse compliance with safety

They get so caught up in following the rules that they don't stop to think about whether the rules make sense.

The Wrap-up

You don’t need anyone’s permission to make life better.

You just need to start small,
act carefully,
and care more about outcomes
than appearances.

The New Manager's Playbook

Ben Link — Thu, 12 Feb 2026 12:30:00 +0000

Congrats on Your Promotion! ...Now What?

If you're taking your first role as a manager, this post is for you. It's a collection of observations and thoughts to help you navigate this awesome transition. Your promotion is a big career win, but it can be a little bit fraught - let's talk about what you need to have in your pocket.

Full Disclosure: I’m not a manager

It might feel a little disingenuous for me to give opinions... but here's why I think I should:

As a manager, the dynamic between you and your team changes instantly. I have watched it be absolutely jarring to first-time managers, and I want to provide some honesty and encouragement. So my playbook is about staying grounded - you'll feel pressures to change, but most of your team wishes that you were still one of them! These are the reminders that will keep you connected to your team.

The First-Time Manager Trapdoors

Let's rip the bandage off: what are some things that are going to mess with your brain as you make the change?

You can’t “just do it yourself” anymore. When you were one of us in the Individual Contributor (IC) community, your instincts were to jump in and get stuff done. “It’s faster if I just fix it.”

As a manager, though, doing that will steal growth from your team! You developed those instincts from time on the front lines - you need to consciously allow your team to have that experience-building time rather than jumping in to save the day.

You’re now judged on team outcomes, not personal output. I'm not telling you anything you don't know, but I've seen lots of managers struggle without the occasional reminder:

Your performance review is suddenly about other people’s work.

You win when they win. Plan accordingly.

The job is now mostly… conversation. You're not being left alone to build the next big whiz-bang feature... your focus has changed. Instead of living in your code editor, you're doing...

1:1s
Alignment meetings
Negotiation
Coaching

Managing people is a completely different set of skills. What got you here isn't going to get you there.

You're now the emotional shock absorber. Get ready for the fun...

Team fear, frustration, burnout, conflict? They bring it to you now. You have to stay calm even when you don’t feel calm... because your team will feed off your energy. I've seen an angry manager wreck the whole team's day... just by doing the perfectly natural thing and expressing themselves. As a manager, you provide the poise.

Things Nobody Tells You (But You Really Need to Know)

You must create clarity that doesn’t exist.

Managers often assume “leadership tells me what to do”. Because as ICs, we've all been used to that. Think about it though: unless your leadership is a bunch of micromanagers (and we surely hope they aren't, that's the worst!), the higher you go, the fuzzier the directions. "Add a save-and-reload feature to the main menu" becomes "Encourage more signups". Your job as a manager is to translate between the two levels of detail... your team is relying on you to set tone and align them to the big lofty organizational fluff they hear in the all-hands meeting.

You can’t keep all your IC work.

You've been the guy with hands-on-keyboard. You've probably even been really good at it... you attracted enough attention to get promoted. You'll immediately feel the pull to keep some technical work alongside your new managerial responsibilities. If you try to juggle both, the result is just "doing two jobs poorly".

If you've been in a super-technical role, and if you're managing a group of super-technical folks, it's wise to keep some technical work in mind though! You need to keep your skills... well, maybe not razor-sharp, but at least with an edge and polished! I'd suggest letting your technical work take the form of "side projects": build something in your free time. Nothing that touches "production".

Feedback is a skill, not an instinct

Humans on the whole tend to prefer a low-conflict environment, especially when there's a lot of "new" involved. So you can imagine that a new manager is likely to be particularly avoidant.

But Feedback is Conflict.

We don't learn from things that go perfectly; we learn when they go 'bump'. And that 'bump'... can be uncomfortable! Missed communication, unrealized expectations... many of the 'bump' causes are sources of conflict. We need to learn to be comfortable with addressing conflict and resolving it well.

You are now a multiplier—or a bottleneck

As the manager, decisions and approvals flow through you... and what you choose to do determines whether they flow right on past or you stop them. What do you pick?

Your habits will directly shape the culture of your team. Are you a little nervous? They're going to learn to bring everything to you before executing on it. Are you confident and calm? They'll derive a sense of security from you and get stuff done.

The Quiet Superpowers That Make Great First-Time Managers

Deep curiosity.

Being the kind of person who wants to know (without interfering) encourages good communication from your team and gives you the tools to run interference with higher management while your team does their magic.

It's important to realize that this isn't only about technical knowledge - when you take time to understand motivations behind the actions, you'll be able to make faster decisions of your own... because you'll understand what you're really trying to accomplish.

Listening without fixing.

This one's tough for ex-ICs: sometimes your team just wants to be heard rather than getting you to solve the problem for them. But you're used to wearing the FIX-IT-NOW hat, and you'll jump right into problem-solving mode.

Step back, take a breath. Ask them whether they need you to help fix it or if they're just sharing... and respect their answer.

Shielding your team from chaos.

And friend... there will be chaos. Competing priorities, unexpected problems... chaos in technology abounds, and your job is to chart a course through it. As we discussed earlier, the team is going to take cultural cues from you; if you handle the chaos with poise, the team will follow you through it. If you get rattled by it, though, it's going to rattle them, too.

Making invisible work visible.

In most organizations (maybe all of them!), senior leadership doesn't actually understand when heroics occur. They just assume that because the project was delivered under budget / on time, everything is running smoothly. They don't see the folks who work the long/late hours, who sacrifice time and comfort to deliver that project.

Your role is to bubble that up. When they see a success, you celebrate it differently: by recognizing the folks who went above and beyond.

Similarly when they see a failure, senior leadership may be tempted to assign blame... their plan was good, but the team wasn't capable of executing it. Help them see otherwise - show them the gaps, the missed design elements, the systemic reasons for the shortfall.

A Simple Starter Kit for New Managers

Here's a checklist you can put on your desk for your first few months:

Block regular 1:1s and never cancel them. Your team deserves this, it's how you build their respect. Are you telling them that you're too busy for them, or that they're important to you?
Define your “top 3 responsibilities” and drop everything else that doesn’t fit. The easiest thing in the world is overcommitting... "biting off more than you can chew". You need to be ruthless about prioritization; if you are, your team will pick up that habit too!
Ask each team member how they prefer feedback. Don't make any assumptions. You'll want to shortcut it... resist the urge. Customizing your approach to each team member (and to your new boss) will help you build relationship quickly.
Practice giving small, frequent, low-stakes feedback. Following up that last point, practice makes perfect. Find ways to give feedback when it doesn't matter so much, learn what works and what doesn't, and you'll be ready when the chips are down.
Establish clear decision boundaries. By this I mean showing the team when it's the right call to assert themselves... (“I decide,” “we decide,” “you decide”). Just like with the feedback, this is about empowering your team during the calm everyday routine so that when decisions become urgent and high-stakes, your team will be used to making the right call.

Wrapping Up

Think of this less as a "promotion" than a "career change". As you shift from IC to manager, your focus is shifting... at first it might feel subtle but it's going to catch up with you fast.

Just remember: You're not there for hands-on-keyboard heroics anymore, you're there to keep the heroes ready for action. Your team's success is the new measure of your own. Good luck!

The Fundamentals

Ben Link — Thu, 05 Feb 2026 12:30:00 +0000

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?

Why Your Team Doesn't Believe Your Dashboards

Ben Link — Thu, 29 Jan 2026 12:00:00 +0000

Long ago I worked on a team that was the quintessential story: understaffed, overassigned, always on the verge of completely flying apart at the seams. Our backlog continually grew despite the heroic efforts of this super-dedicated little crew.

Management, however, didn't see it that way.

Our director’s analytics team began sending shiny dashboards to our manager: charts full of trends and deltas. According to the data, our “velocity” was dropping and our “defect rate” was rising. But we weren’t slacking off; we were deep in the trenches untangling years of organization-wide technical debt.

That’s when I learned something important: the data wasn’t wrong, it was just disconnected.

When the Numbers Don't Match the Reality

Metrics don’t lie; they just don’t know the truth. Without context, they become stories told by strangers about work they’ve never seen. If you’ve ever watched a team of engineers react to a dashboard review, you’ve seen it happen: the quiet eye-roll, the sideways glance, the unspoken “that’s not what’s actually happening.”

It’s not cynicism... It’s pattern recognition.

Engineers live close to the work. They see the merge conflicts, the on-call pages, the half-finished migrations. When a slide full of metrics claims something wildly different, like “velocity is down 20%" or “PR throughput is up 50%”, it signals that the measurement system and the reality system are out of sync. The data isn’t necessarily wrong, it’s just been abstracted past the point of usefulness. Somewhere between the build logs and the boardroom, the story got summarized into numbers that no longer mean what they used to mean. And that’s where trust breaks.

*Because when engineers can’t connect the numbers on the screen to the work in their hands, those numbers stop being information and start feeling like judgment. *

What Engineers Really Want from Metrics

Metrics are credible when they:

Reflect what’s actually happening. They have clear definitions. They're collected consistently. Everybody knows what they mean and what's expected.
Connect to goals the team values. By this I mean Quality, Reliability, Impact... not "optics"! If the team relates to the reason for the metric, they'll move heaven and earth to hit it!
Have drill-down paths. It might be impressive that you've condensed all your productivity data to a single scorecard, but... if nobody can follow up and debug when things seem "off", you'll engender zero trust in your mighty dashboard. You might say: “Metrics should feel inspectable, like source code.”

It seems simple; maybe even a no-brainer... so how is it so easy to end up so far off the mark?

The Three Metric Traps

Here's when metrics become problematic:

The Vanity Trap

Your metrics look amazing... but mean nothing. These are usually the easy ones to measure, but they're useless. Think "lines of code written" or "commits per week".

The Volume Trap

You've instrumented every aspect of your system and you're measuring everything “just in case”. "More" is not "better"! This is problematic in a couple ways: for one, you're going to spend more time and money managing the deluge of measurements. You'll also have to sift all those measurements constantly, slowing down the time to insight. It's much better to simply pick a few key points and focus on those.

The Proxy Trap

We fall into the Proxy Trap when things get complicated to measure. Say you wanted to know about Code Quality... you might be tempted to pick something simple to measure, like "Pull Request Count" or "Unit Test Coverage", and stop there. In the words of John Cutler, "Powerful Ideas Imperfectly Measured > Perfect Measures For Not as Powerful Ideas". You'll learn more from measuring the right things, even if the measurement isn't as exact.

Notice anything about these traps? Each of the traps erode trust because they signal measurement for management, not measurement for learning. Be honest about your goals... why are you actually measuring this?

Building a Trustable Metric Set

What makes your metrics trustworthy?

Few, meaningful metrics aligned to goals (quality, delivery, learning, user value).
Clear provenance: It's well-known where the data comes from and what it excludes.
Leading and lagging pairs: e.g., “lead time” (delivery) vs. “user satisfaction” (outcome).
Ability to question or explore: anyone should be able to trace how the number is made.

The Real Message: Measure Less, Understand More

Once I saw the metrics used to measure our team, I transferred to the analytics group and worked to change those reports. I used my firsthand experience to design metrics that told our story more accurately: ones that aligned what management saw with what the team actually lived.

It didn’t take long for things to improve. Once we reached agreement on what the numbers meant, the tension disappeared. We didn’t fix the team by optimizing the metrics, we fixed it by rebuilding trust through shared understanding.

Metrics don’t create alignment: Conversations do.

The numbers only help when they’re an invitation to talk, not a substitute for it.

The moment your dashboard becomes a shared language, one where everyone knows what the numbers include, exclude, and imply, that’s when the eye-rolls stop. That’s when engineers start nodding instead.

Maybe that’s the real secret to a good dashboard:
it doesn’t prove you’re doing well.
It reminds you that you’re on the same team.