Software, security, and fitness

Cross-Discipline · Dev Edition

Three Systems,
One Architecture

Cybersecurity, software engineering, and physical training look like completely different worlds. Spend enough time in all three and you realize they're running the exact same source code.

---

// the realization

Different domains, same underlying system

It's strange how disconnected these three fields feel on the surface. One is about defending systems from attackers. One is about building software that works. One is about moving weight and recovering from it. Different vocabularies, different communities, different career paths entirely.

But spend real time in all three — grinding CTF boxes, shipping code, and training in the gym — and a pattern emerges that's hard to unsee. All three are, at their core, the same discipline wearing different clothes: build a system, stress test it against reality, find where it breaks, patch it, repeat. The domain changes. The loop doesn't.

The shared kernel: every one of these fields rewards the same trait — the willingness to fail repeatedly, log what happened, and iterate without ego. That's not a coincidence. It's the only strategy that actually works on any complex system.

---

// the loop

The iteration loop is identical

Look at how progress actually happens in each field, stripped of jargon:

Stage	Security	Software	Fitness
Probe	Scan, enumerate, try the exploit	Write the function, run the test	Attempt the lift, run the set
Fail	Payload rejected, port closed	Test fails, exception thrown	Bar doesn't move, form breaks
Log	Note what was tried, what response came back	Read the stack trace, check the diff	Track the weight, note the failure point
Adjust	Try a different vector or payload	Refactor, fix the bug, re-test	Adjust load, volume, or technique
Repeat	Until shell access, or report submitted	Until tests pass, ship it	Until the next PR, next cycle

Same five steps. Every time. The only thing that changes is what "failure" looks like — a 403 response, a red test, or a missed rep.

---

// adversarial thinking

All three require breaking something first

Here's a parallel that gets less attention: in every one of these fields, you can't truly build something resilient until you've broken it — or something like it — yourself.

A security researcher doesn't understand defense until they understand attack. You can't write a secure auth system until you've seen how broken auth systems get exploited. A software engineer doesn't write resilient code until they've shipped something that crashed in production at 2am. And in the gym, you don't build real strength without occasionally pushing to failure — finding the exact point where the system gives out, then training just under that line next time.

# the pattern, generalized across all three fields

def build_resilient_system(domain):
  baseline = current_state(domain)
  while not acceptable(baseline):
    stress_result = apply_stress(baseline)  # attack, test, train
    if stress_result.failed:
      log(stress_result.failure_point)
      baseline = patch(baseline, stress_result)
    else:
      baseline = raise_threshold(baseline)  # harder box, bigger weight
  return baseline                    # the resilient system you ended up with

---

// what's actually amazing

Why this is worth paying attention to

The genuinely remarkable part isn't that these fields share a pattern — plenty of things share surface-level similarities if you squint. It's that the pattern is load-bearing. It's not decorative. The loop of probe, fail, log, adjust, repeat is the actual mechanism by which all three produce results. Skip a step in any of them and progress stalls in exactly the same way.

Skip logging in a CTF and you'll retry the same dead-end vector five times. Skip logging in the gym and you'll plateau without knowing why. Skip writing tests in software and you'll reintroduce the same bug after every refactor. The failure mode is identical across domains because the underlying system — complex, adversarial in some sense, resistant to shortcuts — behaves the same way regardless of whether it's made of code, muscle, or network infrastructure.

Same failure modes

Skip logging or reflection in any domain and you repeat the same mistake indefinitely.

Same growth curve

Long invisible plateau, then a sudden visible jump. Every time, every field.

Same ego trap

Defending a broken approach instead of patching it stalls all three identically.

---

// the takeaway

One skill, three applications

If you're someone who's spent time in CTFs, shipped software, and trained seriously, you're not actually three separate people with three separate skill sets. You've built one core competency — the ability to interrogate a complex system honestly, including your own limitations — and you're applying it in three different contexts. That competency transfers in both directions. Discipline built in the gym shows up in how patiently you debug. Patience built debugging shows up in how you handle a stalled lift. It's the same muscle, doing reps in different gyms.

Brenden · 2026 while(true) { iterate(); }

brenden nichols

Brenden Nichols is a traumatic brain injury survivor, coach, and corrective exercise specialist.  He's also an author and entrepreneur. He is an Eagle Scout and Evangelist who shares his story to uplift and inspire others.

He's helped dozens of veterans and parents with disabilities achieve a work/life balance perfect for them and their families! He may not be a father himself, at least not yet, but he has helped numerous parents achieve their perfect work/life balance and spend more time with their families without having to worry about money and getting stuck in an infinite loop!

He's been featured on a number of podcasts including The Elite where he was offered a media contract but turned it down to continue his work with veterans and parents with disabilities.