What Cancer Taught Me About Documentation and Legacy in Software Development

"My good friend, when I wrote that passage, God and I knew what it meant. It is possible that God knows it still; but as for me, I have totally forgotten."

This quote - often attributed to various authors trying to decipher their own old writing - resonates deeply with me as both a software developer and a cancer patient.

Because here's the truth: if I got hit by a bus tomorrow (or, more relevantly, if cancer takes me before treatment works), would anyone be able to understand the code I've written? The systems I've built? The solutions I've implemented?

The Sole Developer Problem

In software development, I see it time and time again: one person becomes the backbone of an entire company. The sole developer who knows how everything works, where all the bodies are buried, why that one function has to be called in that specific order or everything breaks.

We call this the "bus factor" - as in, how many people on your team would need to get hit by a bus before your project is completely derailed? If the answer is "one," you have a serious problem.

And cancer has a way of making theoretical problems very, very real.

A Fellow Developer's Perspective

I recently read an article by Douglas Riley, a cancer-surviving software developer, titled "Coming Out as a Cancer Survivor: A Guide for Software Developers." Riley explains something I've been grappling with throughout my own treatment: the responsibility we have to ensure that no matter what happens to us personally, our clients and employers can continue to function.

It's not morbid to think about - it's professional. It's caring for the people who depend on your work.

Riley's article addresses the practical and emotional challenges of being a software developer with cancer. The fear of being seen as unreliable. The physical limitations of treatment. The cognitive effects of chemo brain. The reality that you might not be able to finish what you started.

But most importantly, he emphasizes our responsibility to leave things in a state where others can continue our work.

My Wake-Up Call

When I was diagnosed with classical Hodgkin lymphoma, one of my first thoughts - after the terror and the grief and the logistical nightmare of treatment planning - was: What happens to my projects if I can't finish them?

I'd been the sole developer on several key systems. I knew how everything worked because I'd built it. But had I documented it? Had I made it possible for someone else to step in if I couldn't continue?

Honestly? Not nearly enough.

I'd done what so many developers do: I prioritized building over documenting. Shipping features over explaining how they work. Moving fast over leaving breadcrumbs for whoever comes next.

Cancer gave me a harsh reminder: I am not irreplaceable, but my knowledge could be. And if I take that knowledge to the grave without sharing it, I'm failing the people who depend on my work.

The Contingency Plan: Documentation

If you don't have more than one developer on your team - and let's be real, many small companies and startups don't - your contingency plan is this: write incredible documentation.

The good news? It's easier than ever to write documentation in our codebases. Tools like:

Inline code comments that explain the "why," not just the "what"

README files that give high-level overviews

Architecture decision records (ADRs) that capture why you made specific choices

Automated documentation generators

Wiki pages for complex systems

Video walkthroughs for particularly tricky processes

None of these take as long as you think, and all of them could save your team (or your replacement) weeks or months of reverse-engineering your work.

It's Not Just About Cancer

Here's the thing: you don't need to have cancer to make documentation a priority.

You could:

Get a better job offer and leave

Burn out and need to step away

Have a family emergency that requires extended leave

Get hit by the proverbial (or literal) bus

Simply forget how your own code works six months from now

Documentation isn't pessimistic - it's realistic. It's professional. It's an act of care for your teammates, your clients, and your future self.

Software development is my career, but people are my passion. And part of caring for people is making sure they're not left stranded if something happens to you.

What I'm Doing Now

Since my diagnosis, I've made documentation a priority in a way I never did before. Between treatment cycles, when I have energy and mental clarity, I'm:

Writing comprehensive READMEs for all my projects

Adding inline comments that explain complex logic

Creating video walkthroughs of key systems

Documenting deployment processes step-by-step

Making sure at least one other person knows how to access critical systems

Is it slowing down my feature development? Yes. Is it worth it? Absolutely.

Because if chemo brain gets worse, or if I need extended medical leave, or if - God forbid - treatment doesn't work, I don't want my colleagues scrambling to figure out what I built.

I want to leave things in a state where my work can continue without me.

A Challenge for Fellow Developers

If you're a software developer reading this, I want to challenge you:

Pick one project you're the sole expert on. Spend an hour this week documenting it.

Not perfectly. Not comprehensively. Just better than it is now.

Explain the high-level architecture. List the gotchas. Document the deployment process. Write down the things that only exist in your head right now.

Future you will thank you. Your teammates will thank you. And if something unexpected happens - cancer, burnout, a new opportunity, life - you'll have given the people depending on your work a fighting chance to continue without you.

God and I Know What It Means

That opening quote resonates because it's funny and tragic at the same time. We write code (or prose, or anything) that makes perfect sense in the moment. Six months later, we look at it and think, "What was I thinking? Why did I do it this way?"

If we can't remember our own reasoning, how can we expect anyone else to understand it?

Documentation is the bridge between what made sense when you wrote it and what will make sense to whoever comes next - whether that's a colleague, a replacement, or future you trying to debug something at 2am.

Cancer has taught me many things. One of them is this: leave things better than you found them, and leave things in a state where others can continue your work.

It's not just good engineering. It's an act of love.

For Non-Developers Reading This

If you're not a software developer, the principle still applies:

What knowledge do you hold that only exists in your head? What processes at work would fall apart if you suddenly couldn't be there? What would your family need to know if something happened to you?

Write it down. Share it. Make sure you're not a single point of failure for the people who depend on you.

Because life is fragile, and the kindest thing we can do is make sure our absence - temporary or permanent - doesn't leave chaos in its wake.

Software development is my career. People are my passion.

And taking care of people means making sure they're okay even if I'm not.

💜 Kayla

P.S. If you'd like to check out my work as a developer, please feel free to visit my GitHub.

Read Douglas Riley's full article: "Coming Out as a Cancer Survivor: A Guide for Software Developers"