I was sitting down with a couple of my fellow programmers after a long day of testing our new online shopping cart, and we asked ourselves a very important question:
Why don’t most science fiction books get the feel of programming right?
If you’re not a programmer, you’ll doubtlessly protest: “There’s a lot of programming in speculative fiction!” But there isn’t, actually. What there is is a lot of is hacking, which is to say breaking into established systems, usually with a lot of muttered techno mumbo-jumbo like “I’m in the mainframe!” while hopelessly-inept thugs spray the area with bullets.
Now, there’s nothing wrong with hacking. (One of my favorite series, The Murderbot Diaries, features a cyborg killing machine who loves both soap operas and hacking into cameras, so Murderbot is certainly well-balanced.) But programming involves the act of creation, of fine-tuning, of project management—none of which traditionally lend itself to an captivating narrative.
So I asked: What are the core activities of programming, and which stories come closest to getting it right?
Maintenance
What Happens When You’re Maintaining A Project: Every day you arrive at work to look at a list of bugs that your customers have discovered, sorted by priority. You go down the list, from most important to least important, and try to fix each of them in turn.
These are usually not terribly exciting bugs. Which is good. You don’t want the exciting bugs, which tend to be things like “You know that salary information our program was supposed to keep confidential? Well, it didn’t.” And you get to hunt through code trying to find the error while the vice president of your company (salary $140k annually, plus three weeks vacation) calls up and screams in your ear.
No, most bugs are mild, obscure things like “User is logged out every Thursday at 10:13 pm.” If you’re lucky, you patch a widespread inconvenience with a two-line fix and look like a genius. If you’re not, you’ll be sitting there on Thursday at 10:13 pm, hoping you can see the bug so you can fix it—which is known as “the dreaded repro,” short for “Cannot reproduce the bug,” which is programmer-speak for “That doesn’t happen when I do it, so who knows what’s happening?”
Maintenance is, generally, tedium. The code is well known. The problems are low-key. Not exactly high stakes stuff.
So what novel best feels like maintaining code?
Max Gladstone’s Three Parts Dead
Buy the Book
Three Parts Dead
Three Parts Dead is technically about magical law—but it turns out that “magically-enforced laws” turn out to have a lot of overlap with “programming,” even if the protagonists think of themselves as contract negotiators.
The novel starts out with the exciting kind of bug—Kos Everburning has been found dead by his priesthood for no reason that anyone can understand, and the junior partner and the new developer are sent in to investigate. It turns out that what’s happened to Kos Everburning is very much a bug in every (computerized) sense of the term, and much of the novel concerns itself with forms of data recovery—or, more accurately, retrieving the contracts that fuel a god’s power.
Three Parts Dead isn’t about the mild kind of maintenance—but then again, slow bug-fixing would probably make a lousy book. And there’s a lot more horrible gargoyles and soul-sucking shadows and vampires than you’re likely to encounter in troubleshooting your Apache stack.
But close enough.
Legacy Code
What Happens When You’re Working On Legacy Code: This code has been around longer than you’ve been alive, and it will be around long after you’re dead. And like all ancient things—including cars, plumbing, and people—legacy code has quirks you have to work around lest you encounter its ire.
The trick to legacy code is that it is, by definition, the most vital code in your program. People use it every day, and they can’t not use it, so altering legacy code is like doing heart surgery. On a jogger. Who refuses to stop jogging while you’re doing heart surgery on them.
Everyone knows the legacy code is bad. Half your job consists of facing teams of management who brightly say, “Well, it should be easy to…” while you explain—without looking like you’re stonewalling them—that in fact, that this trivial fix will require eighteen months of resources minimum because some obscure limitation of the legacy code (the portion of code nicknamed “the dream crusher”) is the entire reason we can’t have nice things.
What you don’t tell them is that even if they approve the eighteen-month project, their fix will in fact probably never get implemented, because the legacy code has outlasted previous teams of management, and will outlast them, and will probably outlast the heat death of the universe.
So what novel best feels like working on legacy code?
Vernor Vinge’s A Deepness in the Sky
Buy the Book
A Deepness in the Sky
Honestly, most of A Deepness In The Sky doesn’t involve legacy coding—it’s a sprawling space opera about first contact and a culture of Spiders in the throes of their own scientific revolution, and a great big juicy hatesink of a villain.
But when I talked to other programmers, what they remembered was Vinge’s profession of the programmer-archaeologist, whose whole job was sifting through aeons-old code to try to understand what all of this mysterious infrastructure does, hunting through the archives to extract and resettle useful programs.
There’s even a hidden wink to Unix timestamps in there—indicating that long after humanity has spread across to the stars, we’ll still be marking our time (as many computers today) as the seconds elapsed since midnight on January 1st, 1970.
All the way to the heat death of the universe.
Building Long-Term Projects
What Happens When You’re Building Long-Term Projects: At one point, the projected failure rate of massive IT projects was around 50%; now, with much better management structures and development skills in place, that failure rate is down to around 15%.
Still. Those Russian roulette odds means signing onto a long-term project is an act of faith.
There’s a good chance that you will pour your best programming art into this project, only for it to fail for reasons that were by no means your own. Maybe management figures out halfway through that what you built isn’t actually what they needed. (Non-programmers are astonishingly incoherent when it comes to explaining what they want, and often demand you to do the exact opposite of what they need.) Maybe another manager takes over and doesn’t believe in your project, so he starves it of resources until you dwindle to dust. Maybe some other company devises a better solution, and they abandon you to buy that.
Every line of code you write is a hope. (Quite often, that hope is that you will slay the dreaded Legacy Code.) But you don’t write a lot of code; instead, you hold endless meetings with other programmers, debating weighty theories as to how this complex thing should function, getting bogged down in minutiae that actually do matter, but every moment spent in these necessary arguments is running out the clock.
Some days you feel like you’re programming a dream—that you’re wrestling with more of an idea than an outcome.
So what novel best feels like building long-term projects?
Kij Johnson’s The Man Who Bridged the Mist
Buy the Book
The Man Who Bridged the Mist
There is a vast river of mist that separates an empire. A man wants to build a great bridge to join the two halves.
That’s pretty much the story.
Kij Johnson’s prose is always dazzling and sparse, and her mastery has never been more on form than in this novella, which isn’t so much about code as it is that sense of immensity you feel, looking straight on at something that is so monumentally difficult that you might never finish it. And Kij is very precise in describing the elements of building, the huge influx of resources it will take to accomplish this task.
It’s not about programming in the physical sense; despite the title of “software engineer,” building a bridge isn’t much like creating a program at all. But The Man Who Bridged The Mist is very much about that sense of wonder, of sweat, of politics—all the things that must come together to create the impossible.
Being Dazzled By New Interactions
What Happens When You’re Joining Things Together: Wanna know the trick about programming? No individual part is all that difficult.
Don’t understand how one website calls another to get information? You could learn that in an afternoon. Want to know how a database stores your password safely? That’s like two hours. How to get words in a browser to render in bold, italic, or superscript?
Fifteen minutes. Seriously.
But programming does require expertise, because while no individual portion tends to be indecipherable, it’s putting them all together that requires many overlapping knowledge bases. Putting together a website that allows you to log in requires knowledge of how websites talk to each other, and storing passwords, and getting words to render the login form—but there’s so much more you need on top of that to get it to function.
What’s happening is that you are assembling a Justice League together from your own skillsets, piling on all the little aptitudes you’ve gained along the way until you can create something magnificent by fusing these modular skills into one project.
And then—if you’re lucky—some hotshot programmer comes along and shows you how you can spin three plates in tandem to make your code do something you never thought it could do before, something more powerful and intoxicating and whoa we are flying high on the narcotic of our own tech.
So what novel feels most like being dazzled by new interactions?
Robert Jackson Bennett’s Foundryside
Buy the Book
Foundryside
As is usual with fantasy books that evoke programming, there’s a lot more magical ninjas involved than you’re likely to see scanning Stack Overflow. But the flourishing tech start-up economy of Bennett’s steampunk city of Tevanne is fueled by scrivings—magical instructions that alter reality. And a plucky kid is tasked with stealing an important artifact that, of course, is more than it appears.
But what Bennett nails in this book is that feeling of technology stacking upon itself. The magic follows rules, and the rules are clear, but the ramifications are not fully thought through. And there’s multiple times when the characters face down impossible uses of scriving that, when broken down, not only seem plausible, but almost downright inevitable in how they got used.
Plus, you know, there’s a whole criticism of the merchant houses that rule the city, and what that refined capitalism-as-cult does to the power structure. So if you want a little critique with your intrigue, well, here y’go.
Terrible Documentation
What Happens When The Documentation Sucks: It feels like there should be a fantasy series that handles this, because you never feel more like a D&D Wizard learning a new spell than when you’re poring over someone else’s half-assed documentation.
Except the wizards in books all have this admirable commitment to documenting every aspect of their spells so others can learn them safely. Whereas the code that actual programmers write tend to be like 18th century cookbooks, where they assume with a frightening confidence that you already understand how much suet goes in a blood pudding so we’re just not gonna talk about that.
Or the documentation is about that pie you desperately need to bake, except that they’re not making the pie using an oven or a pie tin, no, these people have a kitchen that only uses an air fryer that you’ve never heard of and they bake their pies in a pile of natural coal, but you sort of hope it’s the same principles so it’s pie time, mofos.
Or you follow the documentation note-for-note, levelling up your baking skills until you understand this Bakewell tart so thoroughly that you’re sure Paul Hollywood himself would give you a handshake over it, only to discover that they’ve discontinued that brand of Bakewell tart and the new children 3.0 won’t eat it.
Plus, wizards in stories are smart. They generally don’t type in inscrutable commands we found on our servers in the hopes that this doesn’t actually summon a demon (or, in our case, install a malicious daemon on our hard drive). They’re never pretty sure they understood most of what’s happening here, and what they understood fixed the code so far, so time to do the old cut-and-copy and call response code YOLO.
Which is not to say there’s not some attention paid to bad documentation in magic, but the books tend to be “The wizard goofed up the spell,” not “This spellbook was written by disinterested wizards who just wanted to get the bare minimum down before they went off for some pipeweed.”
So what novel feels most like when the documentation sucks?
No winner.
I’m not saying there isn’t one—I’m merely saying that I haven’t read it. I’m sure you all have suggestions in the comments.
But those books need to look a lot like this XKCD homage to DenverCoder9.
Technology Changing Society
What Happens When Your Technology Takes New Root: Technology is like memes; the greatest sign of success is that people start messing with it.
And when they mess with your technology, if you’re lucky, your users will find uses for it that you never considered. Twitter was originally seen as a glorified group chat—nobody thought that it’d become the main method for Black Lives Matter groups to propagate evidence of police brutality. Flickr (a photo website sadly waning in influence now) started off as a way to share screenshots on a MMORPG. Heck, in its early stages, the Internet was basically seen as a way to store documentation.
Every technology that takes root evolves in unpredictable ways. And when truly life-changing technology hits, it transforms society. That’s a responsibility that every programmer needs to face up to—the same code that makes it easy to check in on your kids can become a way for an abusive partner to lock their spouse into misery. And let us not forget the astounding cruelty that can take place when an unthinking coder decides that “User engagement” is the same thing as “Happiest post of the year!” and decides to drag out a father’s dead daughter as the top post in their year in review.
(RIP, Rebecca Alison Meyer, forever embedded in the Internet as #rebeccapurple.)
So what novel feels most like technology changing society?
Ramez Naam’s Nexus
Buy the Book
Nexus
Nexus is the first in a trilogy, but trust me, you’ll want to read the whole thing. Because it deals what happens when programmers perfect the Nexus OS—an operating system that ties directly into your brain.
This is not a unique take. But what makes Nexus so relentlessly unique is the way that the brain-hacking keeps spiraling into new hands, and those hands in turn change what the Nexus OS is for. Governments want to use it for both surveillance and control, obviously, but they see it as a threat to freedom. The hackers—or at least the Burning Man-flavored hackers presented here—see it as an opportunity, or a drug, or the possibility for unique forms of psychotherapy.
None of them are wrong.
What Naam does in this book is astounding, in a science-fiction book: he doesn’t really seem to have an opinion. Is Nexus good? Bad? Neutral? That all strictly depends on who’s using it, and even the characters change their opinions on Nexus as the world begins to shape and adapt to it.
When you look at something like the Internet, it’s been both a force for unalloyed good and an enabler of seething evils. Nexus would be exactly the same. And here, in the Nexus trilogy, technology is allowed to be a reflection of human growth, not the seed-bed for a moralizing author tract.
The Group Chat Experience
What Happens When You Have To Deal With Patch Notes: In an ideal world, your fellow programmer would be your ally. But often, your fellow programmers are the opposition—adding trivial bugs they should have caught, rewriting perfectly good code to fit their own pedantic standards, ignoring the big warning sign that says “PLEASE DO NOT OPEN THE CAGE WITH THE FACE-EATING LEOPARDS” shortly before filing a ticket that says “Face eaten, pls help.”
So you have long threads devoted to What Not To Do, and then people argue about What Should Be Done, and it’s tedious and bureaucratic and yet somehow necessary.
So what novel feels most like dealing with patch notes?
Desmond Warzel’s “Wikihistory”
Gonna be honest; I made this category just because I still love this story.
It’s not a novel. It’s about, what, 2,000 words max? But it honestly does feel like this. Promise. And it’s amusing as all hell.
Users Forming Cargo Cults
What It’s Like To Find Your Users Contorting Themselves Into Pretzels Over A UI Bug You Could Have Fixed In Twenty Minutes: Remember when I said that non-programmers are routinely very bad at knowing what they want, and ask for massive solutions that don’t actually fix their problem?
Welp, there’s a flip side to that: people who treat anything computerized as though it were set in stone.
Now, this generally doesn’t apply to customers; they’re an odd mix of continually demanding and dead-as-the-void silent. But if you develop software for an office, the people at that office will often assume that this is all management will allow them to have.
Your software will become the thing they have to work around, and they’ll never tell you.
If you’re not careful, you’ll find entire cultures warped around a feature you could have knocked off in an afternoon. Secretaries will mail each other spreadsheets of invoice numbers that they looked up, painfully, one by one, when you could have literally added one control to the search bar. Clerks will enter in forty-digit gift certificates on a keypad because nobody thought to ask for a scanner.
And you will walk in to stammer, “That—no. You don’t have to—we could—“ And somewhere in the back of your mind you will be tallying all the hours lost to this worship of The Software, and wonder how soon you can rescue these poor, benighted souls from their own faith.
So what novel feels most like finding your users contorting themselves into pretzels over a UI bug you could have fixed in twenty minutes?
No winner.
Again, I’m not saying nobody’s written this book, I’m merely saying that I haven’t found it. Please, sound off.
But personally, I’d love to read some behemoth of a novel detailing an oppressed civilization rebelling against a malicious AI, and at the end of it some dude from QA comes in and says, “Oh, yeah, we can patch that” and fixes it in a weekend.
Optimization
What It’s Like To Optimize Your Computers: If you’ve ever spun up a computer with Linux installed, you know there’s an overwhelming amount of options that you can tweak. You can go blind staring at a thirty-page manual that documents the options for a single command… let alone the options on the four hundred or so other commands.
Sure, the defaults are probably good. And maybe even secure, if you’ve found a Linux distro that’s user-friendly.
But what if you really need to fine-tune that server until it sings? What if you’re spinning up a web server that needs to handle 50,000 users connecting all at once? What if you’ve got a ton of complex data, and you need to make sure your data storehouse is optimized to return answers to any query under 15 milliseconds?
Well, then you’re gonna take such a deep dive into the documentation that you risk getting compression sickness. You’re gonna trawl forums, check Stack Overflow, drop into Slacks and Discords to ask the experts. There are people who are paid to do nothing but make computers run sleeker, harder, better, faster—and if you want to get there, you’re going to have to have a fundamental understanding of the keepalive timeouts and the proxy caches.
So what novel feels most like dealing with optimizing your computers?
Ferrett Steinmetz’s Automatic Reload
Buy the Book
Automatic Reload
Full disclosure: I wrote this book, so, you know, take my recommendation with the mandated grain of salt.
That said, I wrote this book as a programmer who was very curious about what cybercombat would be like in the future—because eventually, when real-time computer image processing gets to be quick and reliable enough, there will come a day when the computer can outdraw and fire our slow, tired human reflexes.
At which point, everything will come down to optimization. Because once you remove the human element from warfare, well, what’s that mean for programmers when your default settings were lax enough to accidentally fire upon an innocent child?
That’s where Mat, the hero of Automatic Reload, is right now: he’s a hulking cyborg with prosthetic armaments, and he has emerged from a blink-of-an-eye combat to realize that his guns have killed the wrong person. As such, he’s become obsessed with fine-tuning, ensuring all the maintenance he does will never again harm a bystander no matter what firefights might erupt, and that mechanized PTSD is slowly killing him.
Fortunately, he finds the right girl to help talk him out of his trauma.
Unfortunately, she’s also a genetically engineered killing machine.
Bad management
What It’s Like To Have Bad Management As A Programmer: Want to know one of the nicest things a good manager can say to you?
“I know this is a terrible solution. It’s tech debt, and we’ll regret it later. But our CEO needs a fix this week, not in six months, so get to it.”
That sounds weird—you’d rather have a manager who could stop you from rolling out terrible solutions, right? And you do. But that’s not always possible; sometimes outside forces require sub-par hotfixes, and sometimes the solution you really want is too expensive (in terms of man-hours or hardware) to accomplish.
When that happens, good managers bite the bullet and acknowledge the troubles.
Bad managers gaslight you.
Bad managers will tell you whatever upper management wants is an ideal solution, why would you argue, you’re overreacting. Bad managers will come down with mysterious cases of amnesia when, after you’ve told them time and time again that this duct-tape-and-glue fix is unstable, then they blame you for not warning them when that hotfix collapses.
Bad management is shortsighted. Bad management undermines you, because your very realistic complaints are an impediment to the fantasy view of reality they’re desperately trying to peddle to their superiors. Bad management views your spare time as their time.
And despite all that, sometimes bad management gets it done. Because other people will work their asses off for love of the dream.
So what novel feels most like dealing with having bad management as a programmer?
Not Charlie Stross’ The Atrocity Archives.
I’ve heard you champing at the bit. Every time anytime mentions “programming” and “speculative fiction,” the words “CHARLIE STROSS’ ATROCITY ARCHIVES” erupts from their mouths like the Deep Ones crying out to their undersea master C’thulhu.
And I mean, who doesn’t like the idea of hackers working in a government bureaucracy, fighting Lovecraftian monsters? Charlie Stross does an excellent job capturing the detail of finely scientific explorations of gorgon stares, otherworldly dimensions, and—gack—unicorns.
(You really don’t want to know what perfidity can be wreaked with a Strossian unicorn.)
That said, I’d argue that the Atrocity Archives is more akin to hacking. There’s a lot of programming thought going into it, but even though Bob Howard’s bosses are notably bad (including some literally inhumanly awful management), I think there’s a slightly better choice for this:
Mary Robinette Kowal’s The Calculating Stars
Buy the Book
The Calculating Stars
The Calculating Stars—the first in the Lady Astronaut series—starts off with a bang.
More specifically, the bang that ends the Earth.
But of course it’s not quite that simple—the meteorite that hit us in this alt-history 1950s story has destroyed our ecosystem, but it’s a slow burn. Eventually, Earth will become uninhabitable, and as such the world has to come together to establish a spacebound colony.
Elma York is a prodigy: a master mathematician, an experienced pilot, dedicated and competent. But Elma York is also a Jewish woman, in the 1950s, participating in a space program that only values her because she’s a good photo op. She’s trying hard to work past her panic attacks to get a working space program up and running… But her upper management is undermining her at every opportunity, and actively working against the integration of Elma’s friends and coworkers.
The Calculating Stars is a good example of what happens when a manager is devoted to the project, but not necessarily to you. There’s plenty of dressing-downs, of sidelining the most talented people for political reasons, of wasting resources to prioritize the “good” solutions they know of.
(Good solutions that usually turn out to be overwhelmingly white and cismale. Go figure.)
As I said, bad management doesn’t always destroy a project. Sometimes they succeed regardless. And in The Calculating Stars, you can see some very human managers—people who care very deeply about their project, but they have some blind spots, and they have some things they’re absolutely unwilling to hear.
Which honestly, seems about the truest depiction of tech I can imagine.
Ferrett Steinmetz is a graduate of both the Clarion Writers’ Workshop and Viable Paradise, and was nominated for the Nebula Award in 2012, for his novelette Sauerkraut Station. He is the author of the novels The Sol Majestic from Tor Books, as well as the ‘Mancer trilogy and The Uploaded. His short fiction has been featured in Asimov’s Science Fiction, Beneath Ceaseless Skies, Shimmer, and Andromeda Spaceways Inflight Magazine. Ferrett lives in Cleveland with his wife.
The XKCD link is bad. Try this one: https://m.xkcd.com/979/
@1 – Fixed, thanks!
“A Deepness in the Sky” was the first to come to my mind when I saw the title, happy to see it made the list.
Not sure where it fits, but I loved the scene with the soldiers forming a Turing Machine in “The Three-Body Problem”.
This is probably the best list I’ve seen on Tor.com. Almost every book I’ve read or sounds excellent. Plus the classic and the author’s book, which I”m willing to take on faith at this point.
I feel like I’ve read something that fits bad documentation. Ancient magic usually suffers from that problem, so “modern” spell casters can use their magic but have no real clue what it does. A lot of abandoned tech just has no documentation at all.
I can’t help but think “The Wizardry Compiled” by Rick Cook may fit the Terrible Documentation heading, but given that the entire series premise is about what happens if a programmer finds himself in a magical universe… Well. It’s probably a little bit too on the nose.
I am now imagining a grimoire with a marginal note reading “You are not expected to understand this.”.
Speaking of Vinge, A Fire Upon the Deep features an extreme case of Terrible Documentation, although perhaps intentionally misleading documentation is a different category.
I was surprised that “We are legion, we are Bob” wasn’t on this list.
How about one of my all time favorites, Jurassic Park? The novel is entirely centered around an OS that was deliberately crippled by its own programmer and the novel is spent trying to get it back up and running. Oh yeah, there are dinosaurs too.
@9
That’s sysadmin, not programming (though programming may be a part of sysadmin).
I’m currently working on a project that has modules written in C in the early 90’s that have comments that basically say:
//If you don’t have a doctorate in this field, don’t mess with this code.
I know almost nothing about programming, so I enjoyed learning a bit about the job with this article. Thanks!
Thank you for this reminder of “Wikihistory”
I find it hard to believe that it has been nearly 9 years since I read that for the first time. But then again, it was 9 days before the birth of my second daughter and I TRULY find it hard to wrap my head around that displacement of time.
For terrible documentation, maybe we might mention (sub-category?) every misunderstood prophecy in a fantasy novel ever.
Vernor Vinge’s A Deepness in the Sky
Well done. Also, the previous A fire upon the deep. There he mentions some truths about programming (including half-assed programming). Vernor Vinge knew programming and it shows.
Terrible documentation: there’s a reason why one of Iain Banks’ AI ships was named the Just Read The Instructions.
Users forming cargo cults: every fantasy novel where it’s later discovered that they’re a lost space colony. Also the tabletop roleplaying game Paranoia.
Very interesting topic :)
Programming is writing. Really. You have to have an idea of what you’re doing when you start, and if you’re working on something that has to work with other programs, you need to know how they work. And converting a program from one language to another means you have to figure out what that language does, too.
(BTDT. With a program that counted votes for the Hugos. Talk about pressure to get it *right*.)
@14, well, yes, of course Vinge knows programming. He wrote these novels in Emacs (back in the days when making it usable *required* programming because there were no things like Doom Emacs to do the work for you) and was a CS prof at SDSU :)
There is some Deepness fanfic out there trying to figure out what it’s actually like being a programmer-archaeologist. How many millennia old are some of these bugs? How many layers upon horrifying layers of kludges are built up atop an original bad decision which is almost impossible to undo? (Actually… we have a real-world example of this in molecular biology. More evolutionarily ancient pathways in the cell can change less and less as more and more things get layered on top of them and come to rely on them working: the only way to change them seems to be to go parasitic and rip out whole layers of machinery because your host is now doing the jobs that machinery once did for you… but now you might have less ancient kludgery but you’re an obligate parasite, and your *host* has all that kludgery instead. But even that is rather cool to me: the persistence of ancient mature spaghetti code turns out to be a fundamental principle which has led to the survival of some information-bearing molecules almost unchanged for three billion years or more.)
Oh, man! As a software tester who has been in way too many meetings about what color a button needs to be, experienced so much bad management, so many failed projects — and a dabble in programming, too, so all that — this list is like a birthday, Christmas and Halloween gift all wrapped up in one! I’ll be working my way through your whole list!
Minor spoiler — _Midshipman’s Hope_ by Feintuch has a computer bug as the central “what went wrong” event. And it has a delightful name for the programmers onboard the ship who are responsible for the computer systems — the Dosmen! In fact, I think there’s a moment of Nightmare Documentation in there, too. Well worth a read (skip the rest of the series, though, sadly).
Thank you for this!
My favorite programing-based metaphor magical fiction is Scott Meyer’s “Off to Be the Wizard”. The series has an implausible start but the programming metaphor and abilities remain consistent. It’s firm magical scifi and they’re fun reads.
In terms of “real” programming Daniel Suarez’s “Daemon” series about an autonomous distributed social system with gamified real world incentives has impressive IT plots that show real understanding of the gritty details, programming included.
@1
I had a bug. The only reference online was a question behind a paywall at a programmer site that required $ to see the details. I gave it my credit card. The response was (I kid you not), ‘You can’t do that’.
I fixed the bug on my own.
This was a good article.
@15 About cargo cults, please ellaborate if you wish so. Do you really think that it applies to every one of those novels? Would you provide an example? Do you really think it applies to Darkover?
@19 Have fun!. A suggestion: reading A fire upon the deep before A deepness in the sky. You will get much more from the second that way.
@17, oh yes. But then again programming is also like musical composition or like doing mathematical proofs or like… everyone seems to compare it to something different. But regardless, one can definitely get writer’s block. For *months*. (Getting writer’s block is a sign that you’re getting experienced enough to see what can go wrong and the space of options available and it’s paralysing you. Learning how to overcome it is a sign that you’ve got *real* experience, and can pick between those choices with some degree of reliability.)
The PL analogies in Foundryside go pretty deep. In the sequel the big invention to make lexicons more portable is effectively dynamic linking.
The Priesthood of Kos are not even close to coders. They are explicitly mechanical engineers, with a supernatural bent. We don’t see much like coding in any of the Max Gladwell books. We do see arcane lawyers (craftsmen), investment bankers (priests), engineers (monks of Kos), and assorted other modern professions mapped onto a world of magic and creepiness.
Infinite by Jeremy Robinson, when you need to program your way out of the mess you were put in by the insane master coder who recently stabbed you in the chest.
And now I want to watch ‘Sneakers.’
Fun article: I have experienced many of these conundrums and sympathize (that comic is far too real: I too have discussion forum posters I wish I could track down and get answers from, still). Thanks for the book suggestions, I definitely dig the concept of coding archeologists.
Has anyone else read Zendegi, by Greg Egan? That book really showed a good understanding of what it might take to create AI and the real challenges involved in development, not just for future tech but just technology period. Despite some current events messing with the setting a bit (it’s no longer as near future as when it was written) I think it holds up fairly well.
On the other end of the spectrum is Android’s Dream by Scalzi. There are many references to old tech/hardware and as I recall major plot points to keeping up legacy code/tech (I think COBALT is even mentioned). The whole story winds down to tracking down an anamoly (feature or bug depends on your POV) in a population, which very much mimics the needle-in-a-haystack (in both the exciting and prosaic) of troubleshooting code. The AI is more typical scifi just-accept-it-and-move-on but there are many great bits about how technology works.
I also recommend the character Sandfly in the Deeptrench series, an enslaved coder who “sings” to machines through neural implants. I remember when reading the first novel that the author had a fairly good grasp on what it meant to try to bughunt, and was not surprised to learn he’s a developer himself.
Even more interesting, I suppose, is the fact that much of the stories discussed are no longer science fiction and permeate all present-day genres now, with technology such a major factor in people’s lives. It’s less Nueromancer and more code monkey, but the fact that what once would have been an out there plot of The Twilight Zone is now just another episode of a regular police procedural or even sitcom is kind of wild to think about.
I enjoy Murderbot’s coding skills, all while complaining about humans, and watching media.
Was hoping to find Foundryside here and was not disappointed.
For an amusing look at the importance of documentation, although not in a programming context, Ken Liu’s short story “The Message” is loosely based off the (surprisingly gripping reading) US government reports on long-term storage of the nuclear waste site in Yucca Mountain.
Terrible Documentation – Lyndon Hardy’s Master of the Five Magics.
Alodar is continuously piecing together obscure instructions into new magics.
Ironically this is deliberate, as the plot later reveals.
Hellburner by C.J. Cherryh. Management thinks it knowns what it needs, so it writes specs that are killing pilots.
@27, everything Greg Egan writes has the programming nature — but not the same sort Ferrett is talking about in this article. It seems to me that Ferrett’s original post is all about the sort of programming which is putting lots of already-existing bits together in novel ways (which is the vast majority of the field because these days there are so many pre-existing bits, and why re-invent the wheel?). Egan’s more about Knuthian or perhaps, er, Dijkstrasian programming, the hard stuff, the invention of new algorithms (a thing I suspect I’m not quite smart enough to do well but is so much fun I never want to do anything else). In this, there *is* an aspect of putting bits together that others have written, but much of it is hard grind thinking and wrestling with various sorts of graph and other data structures inside your head and flashes of inspiration lighting up your mental landscape, and there’s no point trying to ask about this stuff on forums (or mailing lists) because you’re doing things nobody has ever done before: the most you can do is try to suck other people into your growing mass of ideas and try to see if they can extend it too without making it into a disjointed mess (which will probably fail: almost all new algorithms come from one person or a very small team that worked in concert from the start).
From my conversations with other people who do this sort of thing there is also a lot more not visibly doing anything, listening to music, and going on long walks or cycle rides, and almost all your real insights happen then. There is the strong impression that what you are doing is too hard for human beings, and that your insights come from… somewhere else. (The “somewhere else” being your own unconscious mind. I hope.)
If you had to pick one work of Egan’s which exemplified the programming nature more than any other, it would have to be Permutation City, in which it turns out that building huge complex systems you don’t quite understand and then finding more out about them once you’re living in them and can’t get out is quite disconcerting. I am very happy that when I have a bug I just get a crash or misbehaviour of something neatly contained in some computer, not the walls dissolving or — picking examples from real neurology — a sudden inability to see or imagine the colour blue or the concept of leftness.
The Neverness series by David Zindell, while it has nothing whatsoever overtly about programming or algorithm development, does describe the rather weird mental state you get into when doing this sort of thing rather well, and its invasive nature: I’ve had months when I dreamed only about what I was working on (it does not make for restful sleep).
@32: I actually had Greg Egan’s Permutation City on this list for the exact reason you mentioned, then took it off because a) this was getting too long, and b) I’ve never done those deep dives into algorithmic headspaces, so I didn’t feel like guessing it was right.
But I suppose I could have listed all of Greg Egan’s novels as being like programming, because you really have to digest the concepts to get the plot.
@15: If people counted RPG modules as novellas (and I wish they could), yes, John M. Ford’s Yellow Clearance Black Box Blues would definitely could as one of the greats.
@32 Have to admit I’ve only read one Egan novel but it made a lasting impression on me. Thanks for the detailed reply/comment, good food for thought regarding the differences in approach. I’m far more of the adapt-what-exists-to-the-client-needs or perform-tasks-as-specified-by-team-leader dev than invent-new-framework genius, so definitely appreciate the distinction. Based on your and the author’s rec I’m going to have to give Permuation City a go, sounds intriguing.
Also agree on the weird zone you can lock into when things are firing on a project, but it’s not just coding. It’s a similar feeling when I dive deep into writing: time can blur and my brain seems to be working on multiple levels at once.
For me, Seventy-Two Letters by Ted Chiang is the SFF story that best captures programming. Really like how it shows the utter joy of tinkering away on a project, the importance of noticing when something confuses you, the elegance of a clever solution. Great story.
I just finished Network Effect and I think it’s a much better example of the programming experience than you’re giving it credit for. Programming, unlike hacking, is about creation. The spoiler-free version of my point is that Murderbot creates in Network Effect. And what is created is sublime (and a little heartbreaking).
Also, Wells uses camel case when naming files, systems, and functions and that just warms my heart to no end.
For the project management side of things, the short story Instruments of Destruction by Alexander Wales, about the construction of the second Death Star, is pretty great (audio version).
The cute thing in Deepness is that everyone assumes their calendar is from the first moon landing — a historical event they vaguely remember 8000 years later, unlike the writing of Unix — but with a mysterious six-month offset.
I used to use Ubuntu Linux; it was nice and friendly UI like a Mac, but when things went wrong it was hard to figure out what was under the hood. So I switched to Arch Linux, where you have to install everything by command line but excellent documentation helps you out, so it’s more likely that when something goes wrong you’ve actually done The Thing once before. Or can find it in docs.
Taking personal notes helps too.
‘COBALT’ = COBOL, I assume.
The Nanoha anime franchise isn’t really about math or programming, despite alleged math-based magic and the presence of magical AIs, but the second series has a massive conflict, entire planets at stake, with plausibly not a single malicious entity around, just some ancient software modification that went horribly wrong.
Rudy Rucker does some nice descriptions of programming – particularly in “The Hacker and the Ants”:
Don’t forget my very favorite “The Moon is a Harsh Mistress” by Robert Anson Heinlein. Book starts right out explaining how programmers are not so social and perhaps would wish to leave the Earth move to the Moon less bureaucracy and no competition…
Another thought re: cargo cults, Max Gladstone’s Empress of Forever features a technologically advanced cargo cult very prominently, long after the creator of the technology had stopped pushing through updates. Likewise, WH40k’s Adeptus Mechanicum literally worships scraps of technology it doesn’t understand, and has turned routine maintenance into bizarre religious rituals.
Thanks for a most interesting article. Lots of books to check out. I am no techie at all, but I have a question about The MurderBot Diaries – how does the “feed” work ,? An augmented human I get it, but otherwise I can’t figure it out… Love the books….Thanks
I think the issue with cargo cults is most if us end-users don’t know what we don’t know. If we get time and management support to find out what we really need to do, and someone to get us that through programming, great!
However, most of us get either- sorry, that can’t be changed– or- yes, we will change it, but not listen to what you really need– so we will stick with our old crappy stuff that we can make work.
@37, I agree- I love the naming conventions. I also didn’t catch until a re-read that the ‘large and bulky device’ used by the baddies was smaller than a cellphone.
@43,
I think of ‘the feed’ as having the Internet available in your head at all times.
Clark Ashton Smith’s short story The Double Shadow is pretty much a Documentation cautionary tale. “So it’s written by creatures I’ve only just heard of, does something it’s vague about, and doesn’t say how to control it? No problem, bigshot Wizard here!”
Mostly posting to thank @18 Nullnix for the evolution analogy – I hadn’t thought of that connection before but it really is the same thing, isn’t it.
To stay on-topic, something that’s stuck with me since I read it more than 10 years ago is a section from “I don’t know, Timmy, being God is a big responsibility”, a short story by Sam Hughes.
The main plot is a fairly standard simulation hypothesis story but the initial invention it’s based on is a quantum computer that can execute any algorithm in O(1). The story has this wonderful paragraph that is still stuck in my head 10+ years later:
> But it was still pretty exciting stuff. Holy Zarquon, they said to one another, an infinitely powerful computer? It was like a thousand Christmases rolled into one. Program going to loop forever? You knew for a fact: this thing could execute an infinite loop in less than ten seconds. Brute force primality testing of every single integer in existence? Easy. Pi to the last digit? Piece of cake. Halting Problem? Sa-holved.
@39: Yes, grr, that shows what happens when you’re only half paying attention to any one window you have open at a given time.
And I am always insanenly grateful to my past self when I pull up an old client’s files and find comments I made to help future me remember how my customization worked.
@38: Thank you so much for this link. I have now listened to it several times and shared it with several friends. It is brilliant.
For terrible documentation, I nominate
The Misenchanted Sword by Lawrence Watt-Evans
The hermit does a half ass job. To be fair, he just had his work space burned down. But none of the Army wizards can figure out how the hermit got all the spells to work together or even what are some of the spells.
Also, Wells uses camel case when naming files, systems, and functions and that just warms my heart to no end.
Wells uses camel case when naming EVERYTHING (except, oddly, Murderbot itself) and it is getting to the point where (attention, publishers!) I would be prepared to pay a significant premium for the NoCamel SpecialEdition.
“The Lifecycle of Software Objects” by Ted Chiang, about code decay and maintenance.
I was surprised Kelly McCullough’s Webmage series wasn’t mentioned. First books I read that really integrated Fantasy and Programming as the core premise of the book. I was really hoping he’d continue this series further as I loved the way programing, coding, bugs etc were such an integral part.
A lot has changed since I started programming. The modern internet completely revolutionized and democratized programming. No more do you have to have tons of reference books to learn a language. Now if you don’t know how to do something, the odds are someone has already asked the question on StackExchange and someone put up a well thought out answer that says what to do and goes into detail as to why you do it that way and other ways that would be better. I’d say that anyone with a desire could learn to be a decent programmer without a single class, whereas originally it was a small percentage that could get there. As mentioned there are a lot of books that focus on older understanding for earlier ages. If you pick up an early enough Aasimov or Heinlein novel you’ll be faced with “a computer” being a person who does the computing.
There was a book written about magic and computers in the early 80s by John De Chance called Magic Net. I don’t remember much about it but it gave me a chuckle. I don’t know how it fits into the article either. Shameless plug: John is a friend. He played piano at my wedding.
I know about programming because that’s what I do. Somewhere out there, a script I wrote is still running on a fleet of cruise ships.
Sad that there’s no mention of Dr. Donald E. Knuth and his concept of Literate Programming:
http://literateprogramming.com/
(there’s a wonderful mention of his The Art of Computer Programming in R.A. MacAvoy’s Tea with the Black Dragon)
Great article! Twenty-five years of programming experience here, and for the books you suggested that I’ve read (which is most of them), I totally agree. Gonna go out and read the others now.
For the “Terrible Documentation” category, Jonathan Strange and Mr. Norrell comes to mind — all those ancient books with obscure spell descriptions that never seem to work quite as advertised.
And since you did it… I also recommend my own Three Laws Lethal (Pyr, 2019), which features programmer characters who actually know what it’s like to write programs, including trying to sort through hundreds of thousands of obfuscated lines of another company’s code base. :)
Mr. Steinmetz mentions that he’s not familiar with any story about wizardly poor documentation. How about Lovecraft’s “The Strange Case of Charles Dexter Ward,” where the villains are continually refining and transcribing the words of their spells that will animate the essential salts of the dead? The hero, blindly following the phonetic transcriptions, eventually animates an unknown but immensely powerful magic wielder. Incidentally, I always thought the unknown and unnamed re-animated individual was hinted to be Merlin.
Adrian Tchaikovsky’s Children of Time
For the search for missing documentation, this terraforming gone wrong series is implicitly about recreating documentation and it becomes explicit in the second novel, Children of Ruin.
Users Forming Cargo Cults:
Elantris. One little precondition failure, and everything goes pear-shaped.
Terrible Documentation:
Also Elantris, but that scene from the Fellowship of the Ring: “Speak friend and enter…”
Stand on zanzibar! Bugs, bad docs…
I have specialized in finding and reading books about artificial intelligence. Not surprisingly, the better ones dive somewhat into programming.
The Adolescence of P1, by Thomas Ryan, 1977, was one of the early ones that got it right. The technology is quite dated, but if you ever played with an IBM 370, it will bring back memories.
The Two Faces of Tomorrow, by James Hogan, 1979, delves into the development of a global AI.
Both can be found on Amazon, although they have been out of print for decades.
Second a recommendation above for Rick Cook’s Wizardry series; where a programmer codifies a world’s magic in a magical operating system. Of course, he does this in a fairly hacky manner; a later book has a crew that has to come in, figure out what he did, and put professional programming practices to work and put a usable UI on it… I think the series cover a number of the mentioned categories! Been quite a while since I read it, so don’t know if it holds up now… need to pull it off my shelf and give it a reread.
This is a great article! Thanks for all the books mentioned. Some read, and some going into the ‘TBR’ pile.
For the Users & Cargo Cults, Marjorie B. Kellogg’s ‘Lear’s Daughters’. This is a 2009 update version of a duology originally published as ‘The Wave and the Flame’ and ‘Reign of Fire’. (1980s) I have the original two in paperback and really, really wish they’d publish Lear’s Daughters as an ebook. I liked it so much, I keep checking! I can’t tell you how it fits the category without spoilers….but I do believe you’d enjoy the ending.
@30: Thank you! I sometimes wonder if I were the only person who ever read Lyndon Hardy.
I also feel that Asimov’s Three Laws of Robotics stories would have a place here, possibly under Bad Documentation, because of all the loopholes. Of course, Asimov didn’t write the code, just the “pseudocode,” for the three laws.
Indeed, programming has only been feasible in SF for a short (comparatively) period of time, since most writers in the ’50s and ’60s knew nothing about the subject, and their robots and computers just worked the way they were supposed to. Androids, intelligent computers, and other AIs weren’t written with the subtleties of code in mind, as far as I can tell, just written to fill up the plot.
What kind of coding problem would HAL from 2001: A Space Odyssey represent? It’s not obvious, at least not to me.
Hmm, you mention Stross, but only the unreliable narrator Laundry stories.
But “Halting State” and “Rule 34”, don’t get a mention.
Terrible Documentation : I would offer the “Rivers of London” series by Ben Aaronovitch, in which the main character, who is learning magic, repeatedly states that the documentation is not helpful and tries to write better for the people who will follow.
An ancient example relating to your non-programmers asking for the opposite of what they need or really want: “Gadget vs. Trend” (1962), which begins with a sociologist complaining about how everybody is too conformist; after massive disruptions caused by the invention of a pocket-sized stasis generator, the story closes with the same sociologist complaining that society is too fragmented. Surprisingly thoughtful piece considering it was by Christopher Anvil, who was a sort of second-rate Eric Frank Russell (same dumb aliens bamboozled by smart Earthlings, only not funny even at the time).
OTOH, this could also be taken as a story about engineer responsibility (which I learned about over 20 years): a simple uninterrogated solution tends to multiply problems.
That’s because a lot of management doesn’t want to spend programmer hours on something not even vaguely connectable to revenue; ISTM the users are likely to be making a correct assumption.
re “being dazzled” — I remember when SW engineers talked about cyberpunk as a bright new tomorrow: sure, people were doing horrible things to other people, but their systems talked to each other!
@31: ISTM that’s mechanical engineering — and Cherryh was probably thinking of real-world examples, such as the demand for an unrealistic muzzle velocity that mean early AR-15’s frequently jammed.
@32:
Oh yes — the number of times I woke up in the middle of the night with a solution…. But that’s not limited to SWE; one of the famous examples is August Kekulé waking up from a drowse with the realization that benzene was a ring instead of a chain. It may be that staring at a problem inhibits the parts of the mind that can think more loosely and so come up with non-obvious solutions.
@57: IIRC, the spells were ~consistent; the problem was knowing whose dust it was you were reanimating. (This is specifically mentioned in a letter from one spellcaster to another.)
@60: more detail? The big issue I remember was the same sort of GIGO that is breaking (e.g.) facial recognition these days; the people who programmed Shalmanesar had a limited view of the world.
@61: as a licensed pilot, P1 irritated the hell out of me because there was no way a ground controller could snatch an airplane out of a clear sky. Interesting to hear that it’s a good presentation of IBM; I remember arguments when it came out whether an IBM system had the flexibility for the job. (I was living in the heart of DEC country.)
@64: ISTM that 2001 is Bad Management; the computer is given incompatible goals. Or one could analogize to the 737-MAX mess, saying that the programmers should have had better handling of edge conditions (although management’s unwillingness to provide multiple inputs would also be a factor).
I’m an application software developer for a legacy (30+ year old) suite of integrated systems used in hospitals (so, there are consequences to getting things wrong) and oh goodness do I relate to some of this. The sections on Legacy Code,
Although as we work with continually trying to update/push forward and unifiy/standardize our functionality, but continue to support our live customers across various versions (some of whom have customized the system in unique ways) this is a frequent comic that gets shared:
https://xkcd.com/1172/
@17 – you know, I’ve thought about this before. I’m actually not great at math (and don’t ask me to leetcode because I actually suck at those kind of algorithm problems) so it’s funny in a way that I enjoy my job so much. But to me writing code is communication. It’s about distilling concepts and transfer of information/data flow and attempting to do it in an efficient/elegant (and correct) way. I like getting all the pieces to work together. I’m not sure what that makes me; I came into software development by a non-traditional path (I’m not a CS major although I did take CS classes to get a post-grad certification as part of my job transition) so I sometimes feel like I’m not really a developer; I’m not one of those people that can whiteboard the fastest path through a BST in 30 seconds, and I also have a lot of gaps in my knowledge (like, I know next to nothing about network/internet type stuff, and I’m not a hardware person either). In fact, my knowledge is in a lot of ways confined to our specific product (but what I know, I know very well). But I like making everything work together and accounting for the edge cases, and I’m good at troubleshooting and (usually) tracking down estoeric/weird bugs (possibly because I started out in tech support) and recognizing patterns/where the bug probably originated based on the type of bug it is.
This one made me laugh: “Your software will become the thing they have to work around, and they’ll never tell you.”
My perspective from the other side of the coin is: “They will complain about it for years and be told ‘It’s not a priority.'”
<3 my devs, their gatekeepers not as much