From Journalism to Code: Why Non-Traditional Backgrounds Make Better Engineers

I didn't write my first line of code until my late twenties. Before that, I was a journalist chasing stories across four continents, a manufacturing engineer building custom surfboards, and someone who thought "API" was a typo.

Today, I build AI-powered systems, architect cloud infrastructure, and run a software company. And here's what I've learned: My "unconventional" path wasn't a detour — it was the foundation.

The skills I developed as a journalist, traveler, and manufacturing engineer translate directly into building better software. And I think the tech industry needs more people who took the scenic route.

The Journalism Years: Learning to Ask the Right Questions

Before I ever opened VS Code, I spent years as an independent journalist traveling the world. Fifteen months in New Zealand. A year in Australia. Six months across Asia. A year in Turkey. My job was simple: talk to people, understand their stories, and communicate them clearly.

I didn't realize it at the time, but I was learning the most important skill in software engineering: how to ask the right questions.

What Journalism Taught Me About Engineering

1. Start with "Why?"

Good journalism isn't about what happened — it's about why it matters. The same is true in software. Before I write any code, I ask: Why does this feature exist? Why does the user need this? Why now?

Most engineers jump straight to "How do I build this?" But if you don't understand the "why," you're solving the wrong problem.

2. Empathy Through Listening

As a journalist, I learned to shut up and listen. Really listen. Not "waiting for my turn to talk" listening, but "trying to understand how this person sees the world" listening.

That skill translates directly to user research. When I talk to customers about BalancingIQ or SOA Assist Pro, I'm not pitching features — I'm listening for pain points, frustrations, and workflows. The best product ideas come from what usersdon't say out loud.

3. Clarity Over Cleverness

In journalism, the goal isn't to impress readers with your vocabulary — it's to communicate clearly. Complex ideas need simple language.

The same applies to code. The best code isn't the cleverest one-liner or the most abstract architecture. It's code that another human can read six months later and understand immediately. Documentation, variable names, API design — it's all about communication.

4. Storytelling Matters

Whether you're pitching to investors, onboarding a customer, or explaining a technical decision to your team, you're telling a story. Engineers who can't explain why their solution matters struggle to get buy-in.

Journalism taught me to frame technical work in human terms. Not "We implemented a Lambda-based event-driven architecture" — but "Now when a customer uploads their financial data, it processes in the background so they don't have to wait."

The Manufacturing Years: Systems Thinking Before Systems Architecture

After journalism, I spent two years at The Shuler Group designing and manufacturing custom surfboards. CAD software, CNC machines, hot-wire foam cutting systems. My job was to turn digital designs into physical products — managing tolerances, materials, and constraints.

I didn't realize it then, but I was learning systems thinking — how everything connects, where bottlenecks emerge, and how small decisions compound.

What Manufacturing Taught Me About Software

1. Constraints Force Creativity

In manufacturing, you can't just wish away physics. Foam has density limits. CNC machines have precision tolerances. Materials have costs. You work within constraints, not around them.

Software has the same constraints: latency, memory, cost, time. The best engineers don't fight constraints — they design around them. I learned to ask "What's actually possible here?" before "What would be ideal?"

2. Everything Is a System

Making a surfboard isn't just shaping foam — it's a system. CAD design → CNC routing → hand-shaping → glassing → finishing. Each step affects the next. Miss a tolerance in step one, and step five is impossible.

Software is the same. Data flows through systems. An architectural decision in week one affects scalability in month six. Manufacturing taught me to think in flows, not features.

3. Measure Twice, Cut Once

In physical manufacturing, mistakes are expensive. You can't Ctrl+Z a piece of foam you just cut wrong. So you plan, you measure, you double-check.

Software gives you the illusion of infinite undo. But in production, mistakes are still expensive — they just cost time, trust, and revenue instead of materials. Manufacturing taught me to think before I ship, not just ship and iterate blindly.

The International Years: Understanding Users Across Cultures

Spending years abroad — New Zealand, Australia, Asia, Turkey — fundamentally changed how I think about users. Not "the user" as an abstract persona, but actual humans with different contexts, assumptions, and mental models.

What Travel Taught Me About Product Design

1. Your Assumptions Are Local

In New Zealand, I learned that "next week" means genuinely next week, not "maybe in a month." In Turkey, I learned that tea isn't a beverage — it's a social ritual. Context shapes everything.

The same is true in software. What feels "intuitive" to you is often just familiar to you. Travel taught me to question my assumptions: Does this workflow make sense to someone who's never used software like this? Does this UI work for someone in a different timezone, on a different device, with a different workflow?

2. Humility in the Face of Complexity

Living abroad is humbling. You don't speak the language. You don't understand the customs. You're constantly a beginner, asking "dumb" questions and learning obvious things.

That humility is essential in engineering. Every user is coming to your product as a beginner. If you design for experts (yourself), you alienate 90% of potential users. Travel taught me to embrace the beginner's perspective.

3. Adaptability Over Perfection

When you're traveling, nothing goes according to plan. Trains are late. Hostels are full. Plans change. You adapt.

Building software is the same. Requirements change. APIs break. Users do unexpected things. The engineers who succeed aren't the ones with perfect plans — they're the ones who adapt quickly and keep moving forward.

The "Beginner's Mind" Advantage

When I started learning to code in my late twenties, I was surrounded by people who'd been programming since they were twelve. I felt behind. I was behind, technically.

But I had something they didn't: fresh eyes.

When you learn to code early, you absorb the culture, the assumptions, the "right way" to do things. When you learn later, you question everything. Why is this API so confusing? Why does this error message make no sense? Why does this workflow feel so clunky?

Those frustrations aren't weaknesses — they're insights. Every time I struggled to understand something, I remembered: If this is hard for me, it's probably hard for users too.

That beginner's mind led me to:

• Build simpler UIs (because I know what confusion feels like)
• Write better documentation (because I remember not understanding the docs)
• Design more intuitive workflows (because I've been the frustrated user)
• Prioritize user empathy over technical elegance (because I know software is for humans, not compilers)

Why Tech Needs More Non-Traditional Engineers

The tech industry has a monoculture problem. Most engineers follow a similar path: CS degree, internship, junior role, senior role. That path works, and those engineers are great.

But when everyone takes the same path, you get similar thinking. Similar products. Similar blind spots.

The industry needs more people who:

• Understand humans first, code second. Former teachers, journalists, healthcare workers — they know how to communicate, empathize, and simplify.
• Bring domain expertise. Building fintech? You want someone who understands accounting. Building healthcare tools? You want someone who's worked in a clinic.
• Think in systems, not just features. Manufacturing, logistics, operations — these fields teach systems thinking that translates directly to software architecture.
• Challenge assumptions. Career switchers ask "Why do we do it this way?" instead of accepting "This is how it's always been done."

What I'd Tell My Younger Self

If I could go back to 2018 — when I was learning Python basics while friends were already senior engineers — here's what I'd say:

Your "detour" wasn't a detour. The years you spent interviewing people, building physical products, living abroad — those weren't wasted. They gave you perspective that most engineers never develop.

You'll never catch up technically — and that's okay. There will always be someone who knows algorithms better, who can code faster, who's read more books. But there aren't many engineers who can also interview customers, write documentation that doesn't suck, and design workflows that normal humans understand.

Your difference is your advantage. Don't try to be like the engineers who started at eighteen. Be the engineer who brings something they can't: empathy, communication, systems thinking, and a perspective shaped by the real world.

Building Products That Actually Matter

Today, I build software that solves real problems. BalancingIQ helps small business owners understand their finances. SOA Assist Pro automates Medicare compliance for healthcare workers. Language Lab reached the Top 3 on the Meta Quest Store before being acquired.

None of these products would exist if I'd taken the traditional path. They exist becauseI didn't.

BalancingIQ exists because I understand how to talk to non-technical business owners (journalism). SOA Assist Pro exists because I understand regulatory constraints and workflows (manufacturing systems thinking). Language Lab exists because I know what it's like to struggle with language barriers abroad (travel).

Your background isn't baggage. It's your unfair advantage.

Key Takeaways

• Non-traditional backgrounds aren't detours — they're foundations. The skills you learned in other fields translate directly to better engineering.
• Journalism teaches you to ask the right questions, listen deeply, and communicate clearly — all critical for product development.
• Manufacturing teaches systems thinking, working within constraints, and understanding how everything connects.
• International experience teaches cultural awareness, adaptability, and humility — essential for designing products that work for diverse users.
• The "beginner's mind" is an advantage, not a weakness. Fresh eyes spot problems that veterans have stopped noticing.
• Tech needs more diversity of experience, not just diversity of demographics. Different paths create different perspectives, which create better products.
• Your difference is your advantage. Don't try to be like everyone else — lean into what makes you unique.