Casting Lines and Connecting Dots
I grew up fishing the lakes and rivers of Minnesota. As a kid, I didn’t think of it as anything special — it was just something we did. But over the years, as my career in tech evolved — from platform engineering at Target and Icario to launching my own shrimp farming startup — I realized something:
Fishing taught me about systems long before I wrote a line of code.
Whether you’re fishing a stream or deploying a model into production, the core idea is the same: observe, adapt, and react to feedback. Nature is one big loop of cause and effect, input and output, signal and response. And if you learn to pay attention to those loops, you become a better builder — in the woods and in the data center.
Nature Is One Giant Feedback Loop
Think about how an ecosystem works. Every element is in conversation with the others. Fish populations rise or fall based on oxygen levels, temperature, predators, and food supply. You don’t have to control the entire system — you just have to listen and make adjustments.
That’s the foundation of feedback-driven design in tech.
In platform engineering, we design systems to respond to metrics, logs, and events. When CPU spikes, we autoscale. When a model degrades, we retrain. When latency creeps up, we investigate. Every smart move we make comes from the feedback loop — not gut instinct alone.
The best engineers are the ones who listen like fishermen. They don’t panic at every ripple. They observe patterns. They wait for the right signal.
Fishing Teaches Patience with Systems
There’s something deeply humbling about fishing. You cast your line and… wait. You might not get a bite for minutes, hours — or at all. But when you do get a bite, you pay attention. What lure were you using? How deep were you fishing? What time of day was it?
Those questions are no different from debugging production systems.
- “What version was deployed when the bug started?”
- “What user flow triggered the latency?”
- “What changed in the environment before the crash?”
Fishing teaches you not to flail or guess. It teaches you to respect the system and learn from its behavior. That’s exactly how we should treat complex infrastructure or ML models — not with brute force, but with curiosity.
The Shrimp Tank as a DevOps Lab
When I built Homeland Shrimp, my indoor aquaculture system, I realized just how deeply nature and tech were intertwined. The tanks became a living experiment in system stability, automation, and — you guessed it — feedback.
- When oxygen levels drop, shrimp get sluggish. That’s a signal.
- When water temps rise too fast, biofilters react poorly. Another signal.
- If you feed too much too fast, ammonia spikes and throws off the balance. Immediate feedback.
You don’t get second chances in a live tank. And just like in production systems, the only way to stay ahead of problems is to build observability into the design.
I used the same principles I did at Target: metrics collection, threshold alerts, redundancy, graceful failure modes. Nature didn’t fight that structure — it thrived within it.
Machine Learning and the Art of Adaptive Systems
Machine learning is perhaps the most literal example of feedback in tech. You train a model, test its predictions, and fine-tune based on loss or accuracy. It’s trial and error, just like fishing — only faster and more precise.
But the danger in ML is thinking that feedback ends once the model is deployed. It doesn’t. Real-world data shifts. User behavior evolves. And if you’re not listening, your model becomes obsolete.
The best ML ops setups are inspired by biological systems — always adapting, always retraining, always filtering signal from noise. There’s a reason we call it a “learning” model. It’s not a one-time thing. It’s a conversation between data and action.
Just like a lake, a river, or a tank of shrimp.
Building with Feedback in Mind
If I’ve learned anything from nature, it’s this: don’t build static systems in a dynamic world.
Feedback loops should be part of the blueprint from day one. Whether you’re writing infrastructure as code, training a model, or farming shrimp, you need to know:
- What are the signals that matter?
- How will you observe them?
- What’s your threshold for action?
- How will the system adapt without burning down?
It’s not about making perfect systems. It’s about making systems that listen well and recover gracefully.
Why Engineers Should Spend More Time Outdoors
This might sound like a stretch, but I genuinely believe more engineers should fish — or hike, or garden, or observe wildlife. Not just for the stress relief (though that helps), but because nature is the best teacher of systems design.
Out in the wild, you learn to look for signals. You learn not to overcorrect. You learn that sometimes, doing nothing is the smartest move — and other times, a small tweak makes all the difference.
Those are the instincts that make great engineers. And they’re not found in a console log — they’re earned from years of watching the world work without your input.
Listening Is the Most Underrated Skill in Tech
In the end, fishing and engineering are about the same thing: learning to listen.
Not just to data, but to behavior. Not just to failures, but to subtle shifts. Not just to customers, but to the system itself.
Nature taught me that the best builders aren’t the ones with the most control — they’re the ones who design systems that respond well to change.
That’s what I try to do in everything I build — platforms, ML pipelines, shrimp farms, or life itself.
And it all started with a line in the water, waiting for the loop to complete.