Writing Science Fiction with a Technical Background: From Navy and IT Tech to Speculative Fiction

I spent about 11 years in the U.S. Navy working on electronics, helicopter avionics, and advanced computer systems. Then I spent a long stretch in IT, technical writing, and teaching. All of that ended up in my fiction, whether I planned it or not.

If you are writing science fiction with a technical background, you already own something most writers have to research from scratch: you know how systems actually break. As a veteran speculative fiction author, I can tell you that knowledge is an advantage. It is also a trap if you let it run the story.

This post covers what “write what you know” really means for STEM folks and vets, how a technical background helps SF, a case study from my own work on Interface Zero 2.0 and Solar Singularity, and the mistakes I see (and made) when translating tech into fiction.

Writing science fiction with a technical background: what “write what you know” really means

“Write what you know” gets misread as “only write about your job.” Nobody wants a novel about a help desk ticket queue. I know. I have lived it.

For writers with technical backgrounds, the phrase means something more useful. You know:

• How systems fail. Not the movie version. The real version, where a single bad cable or a mistyped setting takes down a whole floor.
• How people behave around systems. Who ignores the warning light. Who reboots it and hopes. Who reads the manual.
• How procedures feel. Checklists, maintenance logs, the boredom of routine right up until it is not routine.
• How jargon works. Real professionals use shorthand. They do not explain it to each other.

That is what you know. Then you invent the rest. The faster-than-light drive, the neural implant, the AI with an agenda. Your real knowledge becomes the foundation that makes the invented parts believable.

Readers can smell when a writer has never touched the thing they are describing. They can also tell when someone has. The goal is not accuracy for its own sake. The goal is texture.

The veteran speculative fiction author path: Navy, IT, then fiction

My path was not a straight line. After the Navy, I worked in IT and technical writing, and I taught. That included a year in Thailand instructing component-level repairs for computerized systems. If you want to learn how to explain a system clearly, try teaching it to a room of people who need it to work tomorrow and whose native language is not the same as yours.

All told, I have roughly 35 years in technology and related fields. Along the way I picked up degrees in Information Technology, a BA in English, and an MFA in Creative Writing (2018). The tech side also produced some decidedly non-fiction writing: a Unix IP addressing primer back in 2002 and a Cisco UCS deployment guide in 2012. Those are not page-turners. They did teach me how to make a network make sense on paper.

Being a veteran speculative fiction author shaped my work in a few specific ways:

• Respect for consequences. In avionics, a shortcut can kill someone. In fiction, a shortcut kills reader trust.
• Comfort with chain of command and procedure. Military and corporate structures give characters something to obey, bend, or break.
• A feel for failure under pressure. Equipment does not fail at convenient times. Neither should it in your story.

Now I write horror, science fiction, fantasy, and cyberpunk across short fiction, novels, poetry, comics, and games. The tech background shows up most clearly in the cyberpunk. You can read the longer version on my bio page.

Case study: creating tech and IP addressing for Interface Zero 2.0 and Solar Singularity

This is where “write what you know (and invent)” got very literal for me.

Creating tech and IP addressing for the Interface Zero 2.0 game manuals

I wrote on the core team for Interface Zero 2.0, a cyberpunk RPG from Gun Metal Games. My credits include the Savage Worlds core rules (writer and design team, 2014), the Game Master Handbook (2014), the Player’s Handbook (2015), and the Fate Core edition (2017).

Part of my job was creating bits of tech and IP addressing so the setting’s networks felt real. Cyberpunk lives or dies on its networks. Hacking, data theft, and surveillance all assume there is an actual structure underneath. If the network is just magic with neon, players notice.

So I applied what I knew from networking and IP addressing. How do devices find each other? What gets an address, and who assigns it? What happens when a segment goes down or gets spoofed? Real networks have rules, and rules create opportunities for hackers and headaches for defenders.

Not all of it made its way onto the page. My IP addressing included the Lunar and Mars networks and how the timing impacted things. A lot of it was useful as worldbuilding background, but it didn’t need to be in front of the reader. I knew how things worked on the Wired. Others on the team did too. That knowledge helped pull everything together into a cohesive cyberpunk world that made sense.

Game manuals add a twist. Players poke at everything. A novel reader accepts what you show them. A game master’s table will ask, “Okay, but how does the system know it’s me?” Your tech needs to hold up under that kind of questioning.

Creating tech and IP addressing for Solar Singularity

Solar Singularity (WordFire Press, 2017) is an Interface Zero 2.0 novel I co-wrote with Josh Vogt and P. Wacks. It was a 2018 IAMTW Scribe Award finalist in the Original Speculative category.

The setup runs on a piece of tech called the Tendril Access Processor, or TAP. It downloads the Global DataNet and Hyper Reality straight into users’ minds. That brings malware, hackers, and identity theft into the Deep. Then, in 2088, a solar flare disrupts the satellite network. TAPs malfunction. Hyper Reality overlays become indistinguishable from the physical world, and two AIs at war use humanity as pawns.

That premise only works if the reader believes the network is a real network. So I did the same thing I did for the game manuals: I helped shape tech and the IP addressing logic behind the TAP and the DataNet. If a satellite network goes down, what loses its connection first? What keeps running locally? What happens to identity when the systems that verify it stop talking to each other?

Those are networking questions. Answering them like a network engineer made the disaster feel like infrastructure failing, not a plot device switching off. The solar flare is the invented part. The way the failure cascades is the part I knew.

Media tie-ins add one more layer: you are building inside someone else’s established world, with co-authors. Shared tech rules keep everyone writing the same universe. That is technical documentation in disguise. You can find the book and the game line on my bookstore page.

Common mistakes STEM and veteran writers make translating tech into fiction

I have made most of these. Learn from my scars.

• The info dump. You know how the system works, so you explain all of it. Readers need enough to follow the stakes, not a certification exam. I have so many certifications that it would look like I spilled a bucket of alphabet soup on the page.
• Characters who explain jargon to each other. Two engineers do not define “subnet” in conversation. Let context carry it, or give the explanation to a character who would actually need it.
• Accuracy over story. Real procedures are often slow and boring. Compress them. Keep the feel, cut the steps.
• Dated tech presented as future tech. What you worked on 20 years ago may not survive a jump to 2088. Extrapolate. Ask what the principle becomes, not what the hardware was. I was working on another cyberpunk novel that had an assassin trying to kill someone who had already hacked into the killer’s brain and was feeding fake data. Then a dev editor friend asked why were they still using lead bullets instead of miniature guided devices.
• Forgetting people. Systems are interesting because of who uses, abuses, and fixes them. The tech is the stage. The characters are the show.
• Invented tech with no rules. If your made-up system can do anything, it can do nothing dramatic. Set limits and keep them. My post on world-building tools for authors and game masters can help you track them.

Invent where you must, verify what you can

That is the whole method. Use your real knowledge to build the foundation: how things connect, fail, and get fixed. Invent the parts the future needs. Then check that your inventions obey the rules you set.

Your service record or your career in tech is not a resume to paste into a story. It is a toolbox. Use the right tools and leave the rest in the box.

If you want to see where all this landed, my bibliography lists the game books, novels, and the old tech writing too. Media and interview requests go through my press kit.