Category Archives: Writing

Book Title as Visual Metaphor

I’m reading a book called Nonfiction Alchemy [affiliate link] by Jordan Ring that has some advice on finding a voice. A lot of it resonates with what I wrote in Writing as Yourself to Yourself. For example, in a section called Write with Heart, he advises you to “write like you speak” to find your voice, to tell stories because “they bought your book, not someone else’s”. But the part where he talked about his title and his voice was something I had not seen before:

I debated writing a more streamlined “business type” book with an unoriginal title like “Write Your Damn Book!” I thought about using straightforward chapter titles and letting less of my personality shine through. I summarily shut down this line of thinking.

He goes on to talk about how the word “Alchemy” is evocative and that he is using it to find other (more original) words to describe his ideas. He talks about spells and potions and elixirs, and it just makes the prose more enjoyable, original, and memorable.

It reminds me of an exercise from Writing Down the Bones by Natalie Goldberg [affiliate link]. I talked about it in my podcast episode, Finding Nouns and Verbs. Here’s how I described it:

Take out a piece of paper. Divide it into three columns. In the first column, write down any ten nouns. Then, fold back it over so you can’t see those nouns and look at the second column.

At the top of the second column write down an occupation. She gives examples like chef, pilot, or doctor. Then, for the occupation that you chose, list all the verbs related it. In the book, Goldberg picked chef and then wrote down cut, slice, fry, marinate, bake, boil, etc. Write down as many as you can think of. You don’t need to limit yourself to 10. In fact, try to come with a lot more than 10.

Finally, open up the paper. Now you can see both columns. A column of nouns and a column of verbs. Pick a random noun and then find a verb to go with it and complete the sentence.

This will get you thinking of and using concrete and specific nouns and verbs that exert themselves to describe your scene. You won’t need to rely on adjectives and adverbs as much, and when you do, they’ll have more impact.

Thinking along these lines, with my title now Swimming in Tech Debt and the central metaphor being a swimmer trying to go upstream and being thwarted by debt. In my book, I show how to use the existence of tech debt as a way to propel yourself. The payment of the debt gives you energy and joy that puts you in the flow and makes you go faster. Even the word “flow” serendipitously is related to swimming and probably belongs in the subtitle.

Using the Goldberg technique, I could make a list of verbs that describe what a swimmer does: stroke, push-off, flip, wade, coast, kick, etc. This is of course, a good use of ChatGPT, which is a kind of super-thesaurus. It says: Swim, wade, stroke, paddle, dive, float, glide, submerge, surface, tread, splash, flip, scull, plunge, sink, kick, sprint, roll, breathe, and relax.

The idea is to use those words in the text sometimes instead of the obvious one. Enough that it brings some life to the text, but not so much that it seems like a gimmick.

Titling a book

The working title of my book has been Pay Tech Debt to Go Fast Now. I chose this because it’s the short answer about what I think you should do if you have a lot of tech debt, which is to concentrate your payment efforts on short-term developer productivity. The book is the long answer with lots of recommendations of how to do it.

But, I haven’t been satisfied with it as a title. There’s a passage in my book that seems to have resonated with a early readers, and I’m using that as a signal that it would be a source of a good title:

It’s been hard for me to talk about technical debt outside of engineering. The problems we tackle only exist inside the codebase, which is invisible to stakeholders, but it’s the water we swim in.

I don’t know how to explain that to others that don’t live in water. To us, working in a codebase with a lot of debt is like swimming upstream. It resists us moving in the direction we want to go. We eventually get there, but everyone else just sees the result and doesn’t feel the resistance. If we are slowed down, it just looks like we’re slow swimmers.

In the Write Useful Books, Rob Fitzpatrick recommends making a promise to the reader and putting it on the cover of the book. He says that it could be the title or subtitle. I overindexed on how good “Write Useful Books” is as a title, which is how I ended up with mine. But, I think it breaks down when the promise can’t be short. I think you need something easy for someone to remember and recommend. Pithiness is important.

I am also reading Nonfiction Alchemy [affiliate link], and in it Jordan Ring talks about having a central metaphor to use as a source of vocabulary in the book. “Alchemy” is his example, and the chapter titles are drawn from the same metaphor. I’ve been thinking about that idea too.

Yesterday, I was in Barnes & Noble and just staring at the non-fiction bookshelves with my wife and was telling her about this problem. We kept throwing out terms and while we were there, she came up with “Escaping the Tech Debt Trap”. I like “trap” and one of my favorite books is The Pleasure Trap [affiliate link], so I was drawn to it. I tried to think visually about the idea of a trap.

Then, I remembered that “swimming” passage in my book and thought about swimming in a river and going upstream because I needed to get somewhere, and how I could use the obstacles as a handhold, and push off them to propel myself. The visual helped me realize the physicality of my recommendations. Then, I thought of the title Swimming in Tech Debt, and I liked that it had a double meaning. There’s a play on words that sounds like it could mean something similar to “drowning in tech debt” (being overwhelmed), but what I mean is how to get through it, how to swim through it.

So, anyway, that’s the new title.

View Source logo

Announcing View Source

I finally wrote a post for View Source on Substack. I started it back in 2021, but never posted to it, because I didn’t know how it would be different from this blog. When my guest post for The Pragmatic Engineer went out, a lot of people subscribed to it because that’s where the guest post was hosted, and it was linked to my name automatically. This happened even though it had no posts.

So, now I see that the advantage of Substack is discoverability. I’ll use it as a place to publish more thought out, longer pieces probably based on the best posts on this blog, but rewritten to be better (since Old, Flawed Work is the Jumping Off Point). I decided that View Source will be about the causes of developer productivity.

My book, Pay Tech Debt to Go Faster Now, is my argument that some tech debt payments result in immediate developer productivity that pays for itself, so you should do that. The chapters offer practices for individuals, teams, and leaders on how to do that.

But, View Source, will be broader and look at other sources of productivity.

Write Pitches to Test a Book

I started writing a book a year ago, and I just realized something I could have done back then that would have helped me develop it.

I am thinking about 2025 and what I can do to market my book. So, I got the idea to pitch myself to speak at tech conferences. I had done it before, I like it, and I’m always up for some travel.

I found a few, read their application guides, and crafted pitches based on the content of my book. I applied to an automated testing conference and a few software development conferences.

And then I realized something.

I could have done this a year ago. I had an outline for the book—I could have read these guides to see the kind of content they were willing to “buy” and then crafted pitches based on what I planned to write. If I had been accepted, that would have been great signal that I was on the right track. If I had been rejected, I could have used that to try something else.

Anyway, hope this helps someone who is thinking of writing a book—write some pitches instead. Even if you don’t want to speak, you could just turn it down—you would know whether your idea had some resonance with the organizers.

How I Wrote (most of) a Useful Book This Year

A couple of years ago, I read Write Useful Books by Rob Fitzpatrick. This year I applied it to writing a book about tech debt. These five things had the biggest impact.

1. Imagine the conversation where someone recommends your book

This helped me narrow down my topic from many other ideas I had. I know first-hand that software developers talk about tech debt all of the time. Many of my ideas for chapters were from things I said or thought in those conversations. The ideal conversation is one where engineers are complaining that they can’t get support to pay more tech debt — nearly every chapter addresses that.

2. Make a clear promise

My title is Pay Tech Debt to Go Faster Now because I think the long-term benefits are unsure and over estimated, and there’s a way to get benefits immediately if you direct debt payments at developer productivity to deliver the current roadmap faster (which everyone wants). In that conversation above, my title is the short form of the answer I would give (the book is the long answer)

3. Write in public

I started the book in January and posted it in February. Did a rewrite in March. Posted it in April. That version was discovered by Gergely Orosz of The Pragmatic Engineer newsletter who published an excerpt in September (He also graciously gave honest feedback on what did and did not work)

The article led to hundreds of software engineers signing up to get updates. I just sent them six chapters to read and am getting more useful feedback. I was approached to give a private webinar and shared a different four chapters with them. All of this is honing and shaping the book — the book that I would have written in private would have been very different (and not as good).

4. Market the book by sharing behind the scenes information

For example, this post :)

5. (not in the book): Join an Accountability Group

Rob runs the Useful Books community — https://www.usefulbooks.com/ — I meet with community members three hours per week where we spend 45 minutes of it just writing. A lot of my book got written in those sessions (~70%)

Quote from “On Writing Well”, which is in the text of the blog post

Writing as Yourself to Yourself

Last April, I was invited to submit a proposal to write an article for Gergely Orosz’s The Pragmatic Engineer. He directed me to write for the newsletter’s audience of software engineering managers and senior engineers at larger companies and to write from my personal experiences. I wrote a proposal and outline, which he accepted, and went on to write a first draft.

I felt very confident that I understood what Gergely wanted and then proceeded to write 7,000 words that he hated. That sounds strong, but he read a few paragraphs and got so frustrated that he stopped and asked me to start over (or give up—but, in a nice way). It took me months to figure out that even though I was writing for myself, I wasn’t writing as myself.

Right after the rejection, I talked to a friend and told her what happened. I told her that that I was anxious about writing in a personal style so publicly—that I would embarrass myself. First, she reminded me that I often try to get points across with stories from my career, and that this was just like that. Then she said: “If you don’t write the book that only you can write, then why do it at all?”

Soon after, I reread “On Writing Well” by William Zinsser. This excerpt cemented what she was telling me (emphasis mine).

Writers are obviously at their most natural when they write in the first person. Writing is an intimate transaction between two people, conducted on paper, and it will go well to the extent that it retains its humanity. Therefore I urge people to write in the first person: to use “I” and “me” and “we” and “us.” They put up a fight.

“Who am I to say what I think?” they ask. “Or what I feel?”

“Who are you not to say what you think?” I tell them. “There’s only one you. Nobody else thinks or feels in exactly the same way.”

“But nobody cares about my opinions,” they say. “It would make me feel conspicuous.”

“They’ll care if you tell them something interesting,” I say, “and tell them in words that come naturally.”

It’s weird, because on this blog, I do write as myself (and my podcast is also my point-of-view on what I am learning about writing). But this blog and my podcast are mostly for self-development. I am trying to transform myself into someone that writes. I hope that my readers learn something, but mostly, this is practice for bigger things.

But, in my article first draft (and in early drafts of my book) I stopped writing as myself. It made it harder to write, and (based on feedback) harder to read. The irony is that I used this blog to practice writing, and almost all of that practice was writing in first-person with my point of view, and then as soon as I tried to write something longer, I abandoned it.

So, I gave in, and it’s gone a lot better. I can still say what I want to say (the tips and practices I think will help people), but wrapping them in stories makes the book easier to understand. Even now, as I am finishing up the book, I can see that my final section isn’t me, and so, I need to rewrite it.

Follow-up on my Tech Debt Article in The Pragmatic Engineer Newsletter

About two weeks ago, The Pragmatic Engineer published an early excerpt from a book I’m writing on Tech Debt. This week, he published a follow-up that’s available for free. Read it here:

https://newsletter.pragmaticengineer.com/p/paying-down-tech-debt-further-learnings

If you missed the original article, it’s here: 

https://newsletter.pragmaticengineer.com/p/paying-down-tech-debt

After that article came out, there were a few LinkedIn posts with good conversations about tech debt. This one by Ellery Jose has an interesting table that breaks down how to treat technical debt as a financing decision:

​https://www.linkedin.com/posts/ejose_tpm-pmo-engineering-activity-7237750795348164610-5mKq/​

Also, Guillaume Renoult sent me this post he wrote:

​https://medium.com/elmo-software/how-to-sort-out-tech-debt-and-speed-up-development-9a1d27fdd39e​

There is a section of my book that has similar ideas to these two posts, particularly team management of debt using evidence and data. I’m hoping to have a draft done of that part in a few weeks. If you want to see an early version, sign up to receive updates.

LLMs Can’t Turn You Into a Writer

In Art & Fear, the authors write:

To all viewers but yourself, what matters is the product, the finished artwork. To you and you alone, what matters is the process, the experience of shaping that artwork. The viewers’ concerns are not your concerns. Their job is whatever it is, to be moved by art, to be entertained by it, whatever.

Your job is to learn to work on your work.

If you use LLMs to write for you, you will end up with writing. You’ll pass your class, get by at work, or get some likes on a post. But you will not become a better writer.

It might even be hard to become a better judge of writing. If you do, it won’t be by reading what LLMs bleat out. It won’t be by reading their summaries of great work. “Your job is to learn to work on your work” and to do that you need to do your own writing and limit your reading to those that do the same.

Identity is a Powerful Habit Totem

In my post, Environment Hacking, I wrote about a problem I ran into with BJ Fogg’s Behavior Model:

One of BJ Fogg’s insights is that you already have habits that are completely automatic, so he suggests using those as prompts for a new habit you are trying to build. You repeat to yourself, “After I do [some automatic habit], I will do [some tiny version of a new habit]”. For example, “after I brush my teeth, I will floss one tooth”. In this case, the environment is your existing habit.

This works great, but I have some habits that I can’t easily tie to existing one (or at least I haven’t been successful at it yet). For these kinds of habits, I have been thinking of “habit totems” I can put into the environment to prompt me.

In that article, the idea was to place objects in the world that remind you to do things when you see them. I called those objects “Habit Totems”. A Habit Totem works because it’s always present at the place where you want to do the habit, and it prompts you to do it.

Your identity can be a powerful Habit Totem because it is always present, and it changes how you perceive the environment such that it turns everything into a prompt.

I have an identity as a programmer. I program all of the time without prompts, because everything reminds me about programming. I also have an identity as someone that eats plant-based food—no prompt needed at the grocery store or restaurant because it’s just a part of who I am.

But I struggle with my aspirational identities. I want to be a writer, but I still haven’t assumed that identity enough for it to be a driver on its own. I want to make my plant-based identity more specific by becoming “whole-food plant-based”, but I haven’t made a lot of progress.

What I am trying now is to try to internalize that I have already become the identity I aspire to be. I walked through the grocery store last weekend just repeating “I only eat whole plant-based food” and managed to leave with a cart more aligned to that identity. I am writing this blog because “I am a writer” and a writer writes. When I thought about my experience at the grocery store, I was more compelled to write about it.

It’s only been a few days, but it feels very powerful so far.

Static Site Generation from Django

I created App-o-Mat in 2014 using Django (pre-1.0) and Python 2, and for all that time it was deployed on relatively cheap hosting that supported Python backends. Unfortunately, my host recently decided to stop supporting Passenger and Django had long ago abandoned fastcgi. My options were to upgrade my hosting or look for an alternative host.

I had been wanting to look at AWS’s App Runner service, so I started reading through the docs and doing a trial port of my site. Since I also use MySQL, I had to also learn RDS. At some point I knew enough to try to figure out what this was going to cost to host and it turned out to be more expensive than just upgrading my hosting platform, so I abandoned AWS.

App-o-Mat is a content-driven Django app. It doesn’t have any interactivity in the public pages—most of the advantage of Django to me is in its CMS admin interface where I can author new articles. The public site is essentially static.

So, rather than upgrade my host, I decided that I now just run the site locally on my laptop and use wget to crawl it to get a static site that I scp to my host. I had to manually cause issues to get my 404 and other error pages to be part of the crawl. I see that there’s a project, https://django-distill.com, that purports to turn any Django project into a static site generator, but it also doesn’t automatically handle your error pages.

I might use django-distill in the future, but I write new content very infrequently, so we’ll see.