Robert Delwood Interview Review: The Programmer Writer

Welcome to the technical writing success podcast from Kurt Robbins, where we help you get

smarter than your competition.

Higher Kurt to coach you or your employees in AI to avoid a pink slip or having your

competition eat your lunch.

This is episode 192 and I am Fred Jones.

And I'm definitely Blake.

Imagine stepping into a new role and you're just handed this massive, highly technical

software manual.

Oh, yeah.

The dreaded giant binder.

Right.

You're trying to figure out a critical system integration that your entire project depends

on.

You're reading the steps following the logic and slowly this creeping realization washes

over you.

That the person who wrote the manual has clearly never actually used the software.

Exactly.

I mean, they're using the right nouns and verbs, but the sequence is just totally divorced

from the reality of the interface.

It reads like a translation of a translation.

You can almost feel the writer guessing at how the system behaves under load, you know,

just hoping the engineering specs they copied actually map onto the real world.

It's the worst.

So this episode reviews a March 16 interview with senior technical writer Robert Delwood

by show producer Kurt Robbins.

We are exploring exactly why that happens and how the tech industry is trying to fix it.

Right.

Because Delwood represents a highly specialized and honestly somewhat rare solution to

this problem of disconnected documentation.

He operates under a title that wasn't designed in a boardroom but evolved out of pure necessity.

The program writer.

The program writer.

Yeah.

Our goal today is to really unpack this hybrid role for you listening.

We'll look at how it functions day to day, synthesize Delwood's five rules for bulletproof

documentation, and look at how AI is actually being used in the trenches right now.

Yeah.

Cutting through a lot of the executive hype and to understand the program writer, we really

have to start with Delwood's origin story because it perfectly shows why this dual skill

set is so vital.

He brings this fascinating collision of backgrounds.

He's been a hobbyist programmer since the seventh grade.

Wow.

Seventh grade.

Yeah.

Someone who fundamentally enjoys the logic of coding.

But his formal academic education is actually in journalism.

He was trained to investigate and report.

Which is such a rare combo.

Usually the industry just completely silos those two mindsets.

Oh, entirely.

You either have the hardcore developer who resents translating their elegant code into plain

English, or you have the eloquent writer who, you know, breaks out in a cold sweat.

The moment a command line interface throws an error.

Right.

But right out of school, Delwood lands a job as a technical writer at NASA down in Houston.

But the environment was apparently just total chaos.

Yeah.

The building he was assigned to wasn't even finished yet.

They lacked basic equipment, administrative tools, just any sort of established workflow.

So faced with that gridlock, he essentially hacks his own environment.

He sits down at his MS-DOS PC, fires up basic, and codes a custom scheduling tool just

to manage his own workflow.

Right.

He literally built the infrastructure he needed to survive the job.

And his manager notices this proactive approach within six months.

He's promoted from technical writer to developer.

But he never abandons his journalism instinct.

Even as a developer, he relentlessly writes the documentation for his own apps.

And that combination caught the attention of the broader industry.

A friend at Microsoft eventually recruited him for a brand new rare position they desperately

needed to fill a writer who could read and write code.

The programmer writer, which he says is still his favorite title because there's zero ambiguity.

To make this tangible for you listening, think of a purely non-technical writer documenting

code as like a restaurant critic who has never cooked a meal.

Oh, that's a great way to look at it.

Right.

They can tell you the sauce broke, but they have no idea why the sauce broke in the kitchen.

Delwood is the chef who stepped off the line to write the review.

He knows the underlying mechanics.

And the tech industry pays a premium for that chef's perspective because it solves a massive

logistical bottleneck, which is the empathy gap between writers and engineers.

They speed the jargon.

Exactly.

When Delwood works in an office, he intentional requests the desk seated right with the

developers to dissolve any separation.

As he reads source code directly, he doesn't have to constantly interrupt a developer's

flow state to ask questions.

He just opens the repository and finds the answer himself.

Boy, I have a pushback here.

Okay, shoot.

If he's hired to write, isn't spending time coding custom tools just, well, doubling

his workload and wasting time?

It sounds counterintuitive, I know.

But writing those tools is the ultimate efficiency hack.

Think about the alternative.

If writers need a custom script to automate formatting, they have to submit a ticket to

engineering.

Oh, right.

The endless juror backlog.

Exactly.

It gets prioritized behind critical bugs.

They might wait six weeks for a simple tool.

By coding it himself in an afternoon, Delwood completely unblocks his team.

That's why he insists all tech writers today should learn some programming, even just Python

or JavaScript.

Let's take a brief break for a special message from our producer, Kurt Robbins.

Hi.

This is Kurt Robbins.

Thanks for listening.

I truly appreciate your support.

I want to let you know that I'm currently accepting new clients.

My rates are affordable and I have more than 25 years of experience working for enterprise

companies like Microsoft, Northrop Grumman, Oracle, PNC Bank, FedEx, USA and Wells Fargo,

among many others.

If you want to improve your IT documentation and communications, hire me.

I deliver fast, know how to use AI to improve efficiency and accuracy and love going the

extra mile to satisfy my clients.

Thank you for subscribing and listening.

Back to you, Daphne and Fred.

Welcome back to the Technical Writing Success Podcast, where we help you get smarter than

your competition by coaching you in AI.

So on the flip side of that, if it's so helpful to know how to code, why doesn't the industry

just have the developers write the manuals?

They wrote the code, right?

Well, Delwood is adamant that relying on developers for docs is a total recipe for disaster.

Why is that?

The biggest issue is the curse of knowledge.

Developers have such an intricate mental model of the system that they are often fundamentally

incapable of explaining it to a novice.

They skip steps because those steps are invisible to them.

Like trying to explain to a relative how to change a Wi-Fi password over the phone, you

say, type the IP address.

Forgetting they don't even know what an IP address is.

Right.

Now, multiply that blind spot by 10,000 lines of enterprise code.

Plus, there's a brutal economic reality.

Developers are expensive.

Making a senior engineer wrestle with a user manual is just a profound misallocation

of resources.

It distracts them from their primary mandate, which is writing and optimizing code.

Delwood even references this classic Three Stooges routine, where Mohan's curly a hammer

and says, when I nod my head, you hit it.

And curly hits Mo's head.

Exactly.

But an API documentation, that kind of ambiguity crashes client servers.

Which brings us to his operational philosophy.

Since he started specializing in API docs in 2003, he's formulated five rules for bullet

proof documentation.

First, learn a language, broaden how you learned videos, trial, and error to understand

how developers consume info.

And rule two is make each call.

You have to personally test the documentation.

He actually shared this brilliant anecdote where he found a process ID value was missing

from an API's return call.

And QA had totally missed it.

Yes.

The in-house devs just knew was supposed to be there so they hallucinated the correct

output.

Delwood only caught it because he actually executed the call himself as an outsider.

Which leads to rule three, document it for yourself.

If he doesn't understand it, he stops and figures it out.

He acts as an experienced developer who just happens to be ignorant of this specific

product.

It's a defensive mechanism, really.

If you document the pain points, you don't have to figure them out again in six months.

And that transitions right into rule four, which is dog fooding, using your own documentation

constantly.

Right.

Persistent editing is a virtue for writers, not a weakness.

It's like an architect being forced to live in the house they just designed for a month.

It's the only way you'll notice where the drafts are, where if a door opens the wrong

way.

Exactly.

And his final rule, rule five, don't focus on tools, focus on content.

Not waste time arguing about Windows versus Mac or Markdown editors, write apps, make

calls and postman obsessively, and extract maximum detail.

That deep extraction of truth is the perfect lens for our final topic.

Because we're in 2026, and we have to talk about artificial intelligence.

If you read the executive summaries, you'd think AI has completely automated the programmer

writer role.

But Delwood provides a massive reality check here.

He really does.

He actively uses AI for generating complex algorithms, grammar checking, mapping out

workflows.

He said AI was nearly spot on for a recent workflow.

But there is a massive line he will not cross.

He never uses AI to write the actual content of the documentation.

Never.

Because the reality of AI coding is that it rarely compiles on the first try.

It uses the wrong libraries, it misses values, it saves typing, but it absolutely requires

a human touch to actually get it working.

If an AI is generating a routine but getting the libraries wrong, aren't we just shifting

the technical writer's job?

From being a creator to being a glorified AI babysitter and debugger.

That tension is a huge issue in the industry right now.

We're seeing CEOs laying off thousands of team members to save money, explicitly citing

AI as the reason.

And in partially reporting Delwood's perspective here, he believes the real threat to documentation

quality isn't the AI tech itself, it's those executive cost-cutting decisions.

Yeah, he had a funny quip about that.

He said true equality will be reached when CEOs are laid off because of AI, noting he's

seen instances where a magic eight ball could basically do a CEO's job.

That's hilarious, but it highlights a structural reality.

AI only knows what has already happened, but technical writers operate at the bleeding

edge.

They're documenting quirks that were invented hours ago.

The AI literally doesn't have the context yet.

Maybe a human with empathy and a testing environment can translate that behavior.

Which brings us full circle.

We went from a makeshift DOS tool at NASA to the empathy of the programmer writer through

the five pillars of API docs and finally to a grounded view of AI.

The big takeaway for you listening, whether you're learning Python or managing a team,

is the principle of dog fooding.

Testing your own explanations is universally applicable.

Empathy requires friction.

Exactly.

And here's a final thought to mull over.

As tools get better at generating massive amounts of information, maybe the most valuable

human skill of the future won't be creating content.

It might be the ability to deeply understand a complex system and explain it simply to

another human being.

Acting is the ultimate empathetic barrier between human intent and machine execution.

Thank you for listening to the technical writing success podcast from Kurt Robbins,

where we help you get smarter than your competition.

Hire us to coach you and your employees in AI to future-proof your career or company.

Subscribe now to never miss a career-saving episode.