Why a Rugby Obsessed Developer is Writing This Series

Timothy Opango — Sat, 16 May 2026 13:45:57 +0000

Hey dev.to community,
My name is Timothy. I am a software developer by day and a rugby fanatic by... well, every other available moment. I've spent some time building systems and debugging and I've also spent just as many hours getting smashed in rucks, chasing breakdowns and screaming at referees(sorry, refs).
For a long time I kept this two worlds separate. Then one day it hit me, rugby and software engineering are weirdly similar. Both are chaotic, high stakes, team-based, require important decisions, constant iteration and a strange mix of brute force and beautiful strategy.
The realisation became the spark of this series: Rugby and Code: Tackling Tech Like a Foward.

What to Expect in This Series

Over the next 10 posts, I'm going to explore the beautiful game through the eyes of a developer (and occasionally the other way around). We'll cover:

How rugby concept map directly to software architecture and team practices
Real tech being used in professional rugby
Building rugby-related applications
Emerging tech in the sport
Leadership, resilience and culture lessons that translate between the pitch and the sprint board

Whether you play rugby, only know it from Rugby 7's or Rugby World Cup or are completely new to the sport, this series is for you. If you love analogies that actually make sense and practical takeaways you can use in your work, you're in the right place.

My Rugby and Tech Background (Quick Version)

I started playing rugby in school. I was never the biggest or fastest guy on the pitch, so I had to rely on positioning, reading the game and technical understanding. That mindset transferred straight into coding.
Over the years I've analysed match data just for fun, coached junior players while thinking about feedback loops and iteration and watched how professional teams use technology to get marginal gains.
Rugby taught me more about system thinking, resilience under pressure and true teamwork than many stand-ups and retrospectives ever did.

The Beautiful Chaos We'll Explore

Think about it:

A scrum is literally a self-organising team fighting for possession, sounds familiar to any agile team?
A ruck is resource contention and quick decision making
Phases of play are like deployment pipelines. You want clean ball, quick recycling and forward momentum.
One moment of individual brilliance can change everything, but it only works because of the other 14 other people doing their jobs.

Sounds like any successful software project you've worked on?

Why This Matters Now

Rugby is going through its own digital transformation just like our industry. GPS trackers, AI referee assistance(TMO), performance analytics, fan engagement platforms and many more. The sport is becoming a living laboratory for many technologies we work with daily.
In this series we'll look under the hood at what's actually happening and extract lessons we can apply as builders.

How Real Growth Happens in Software Development

Timothy Opango — Tue, 12 May 2026 14:25:09 +0000

Most learning resources focus on clean examples and ideal outcomes. You follow steps, write some code and everything works. It feels productive but it rarely reflects how real development actually happens. Real growth starts when things stop working.

Constraints change everything

It’s easy to write code when there are no rules. You can always pick the fastest or simplest approach and move on. But introduce operation limitations, performance requirements, strict rule and everything changes. You’re forced to:

Think before coding
Evaluate alternatives
Optimize intentionally instead of accidentally

Constraints push you out of autopilot and into problem-solving mode.

The gap between “working” and “robust”

There’s a big difference between code that works once and code that works consistently.At first, you might:

Assume inputs are always valid
Ignore edge cases
Skip error handling

Then reality hits:

Paths break
Inputs vary
Environments behave differently

That’s when you start learning what robustness really means:

Writing defensive code
Handling failure gracefully
Designing for unpredictability

Structure is not optional

As systems grow, unstructured code quickly becomes a problem.Without clear boundaries, you end up with:

Logic scattered everywhere
Hard-to-test components
Tight coupling between parts

With structure, everything improves:

Code becomes easier to reason about
Changes become safer
Bugs become easier to isolate

Good structure isn’t about perfection, it’s about control.

The importance of environment awareness

A piece of code doesn’t run in isolation. It runs in an environment and that environment matters more than most people expect. Differences in file systems, dependencies and runtime configurations can completely change behavior. Understanding this forces you to think beyond your local setup and consider portability and consistency across systems.

Debugging is where learning happens

Writing code feels productive. Debugging feels frustrating. But debugging is where the real understanding comes from. When something breaks, you’re forced to:

Trace execution step by step
Question assumptions
Understand how components interact

Over time, this builds intuition—the kind you can’t get from tutorials.

Iteration beats perfection

One of the biggest shifts in mindset is moving away from trying to get everything right the first time. Real progress looks like this:

Build something simple
Break it
Understand why it broke
Improve it

Repeat that cycle enough times and your skill level compounds.

Final Thoughts

If you want to grow as a developer, focus less on getting things right immediately and more on understanding why things go wrong.Because in practice:

Code will fail
Assumptions will break
Systems will behave unexpectedly

Your ability to navigate that uncertainty is what truly defines your skill. Not what you can build when everything works, but what you can fix when it doesn’t.

Forem: Timothy Opango