Hi, I’m Lou Franco, and this is episode 47 of Write While True. Write While True is an infinite loop, and that’s because I think of writing as an infinite game, a game I’m playing for fun and to get better at it, like a game of catch.
So in each episode, I’ll tell you something I learned about writing, and then I’ll throw you the ball with a writing challenge or a prompt.
Episode
It’s been a while. Episode 46 came out in late January of 2025 and I’m recording this now in mid-December, so it’s been about 10 or 11 months. When I last left off, we were in the middle of season 4, and I was telling you about all the things I was learning as I was writing my book, Swimming in Tech Debt.
Well, I’m happy to say that I finally finished Swimming in Tech Debt, and it came out in September of 2025, a couple of months ago. And then the print book came out about a month and a half or so later, and I’ve learned so much about the book publishing process that I want to share with you.
So the rest of season 4 will be about all of those things I learned, and then I’ve got something special planned for season 5.
So as a recap, season 4 started in episode 40, and I told you about how I set out to write a very small book, a pamphlet, 10,000 words. And then I went on to tell you in the other episodes about some of the ways in which that ended up growing. Swimming in Tech Debt is a 250-page book about 50,000 words.
And you can go back through episodes 40 to 46 to see that journey.
As a reminder, at the end of 2023, I decided that I would make it a goal that in 2024, I would write a book based on the topics in my blog. So to write it, to find an idea, I read all of my blog posts. That’s what episode 45 was about, gathering my work. And when I did that, I saw that I had written a lot of posts about technical debt and then other posts about developer productivity, but I hadn’t related them to each other.
I think it’s obvious that tech debt lowers productivity. That’s the main thing that it does. But I had more to say about how it does that and how you could reverse that effect.
And while I was thinking about that, I was reminded of the book, Write Useful Books [affiliate] by Rob Fitzpatrick. I had read it a year or so before then, but I stopped around the part where he was getting to the lessons where you actually needed to be working on a book to put it into practice.
But now I was getting serious, so I reread Write Useful Books, and I applied all the lessons I learned for the past two years all the way through finishing the book, and I’m still following its advice while marketing the book.
But in retrospect, having gone through all of this, there are five things that I learned in the book that made the biggest difference.
Imagine Conversations
The first was to imagine conversations in your target audience where people are discussing a problem, and someone in that conversation has read your book, and they recommend it in the conversation.
This helped me narrow down my topic from all the other ideas that I had.
I know firsthand that software developers talk about tech debt all the time. Many of my ideas for chapters were things that I had personally said in those conversations when I had them, or things I thought of later to say.
When you’re doing this, the ideal conversation to look for is one where someone is complaining about a problem they have, and then the other person knows the solution, and that it’s in your book, and then recommends the book.
So for me, one of the biggest complaints that engineers have is they can’t get support to pay more tech debt. Nearly every chapter in my book addresses this problem in some way.
Make a Promise
The second lesson is to make a clear promise and to put it on the cover of the book.
The title of my book is Swimming in Tech Debt, which is meant to oppose the idea of drowning in tech debt. In the book, I make the analogy that programming in a code base with a lot of debt is like swimming upstream. You feel the resistance as a programmer, but to everyone else, it just looks like you’re a slow swimmer.
Ideally, though, my title would be more clear. I played around with titles like that. For example, How to Fix Tech Debt. I just didn’t like them.
So I’m using the subtitle to communicate the promise of the book. The subtitle is Practical Techniques to Keep Your Team from Drowning in Its Code Base.
Write in Public
The third big lesson was to write in public. I talked a lot about that in episode 44. I’m used to doing this on my blog and my podcast. I definitely have no problem sharing my work in public.
This was even more radical, though, because you’re going to share works in progress, not completed work.
I started the book in January 2024. And at the end of January, I had a few thousand words, but I posted them in February, just a month after I started. I got some feedback, mostly from friends who were software developers and software engineering managers, people in my target audience.
Based on what they said, I did a rewrite in March, and I posted that in April.
That version I only shared in communities where I didn’t know people so closely. I really wanted to get more frank feedback.
And I was lucky that that version was discovered by Gergely Orosz of the Pragmatic Engineer newsletter. He asked me to write a guest article in his newsletter, which was published in September of 2024. And along the way, he also gave me really honest feedback on what did and did not work in the article.
That article led to hundreds of software engineers signing up to get updates about the book.
I sent them chapters to read as they were finished and got even more useful feedback. The questions people asked led me to writing more chapters. All of this activity honed and shaped the book. And honestly, the book I would have written in private without sharing any of it in progress, it would have been very different.
It would have been much shorter and frankly, just not as good.
Share Behind the Scenes Information
The fourth thing I learned was that one of the ways that you could market a book was to share behind-the-scenes information as you were writing it. A big example is this podcast and this specific episode where I’m telling you about what happened when I was sharing the book.
Very meta.
But this has also driven a lot of what I’ve been writing about on LinkedIn.
I share about what I’m learning in writing the book and some of the research that I found.
And that has helped me get email subscribers who I can market the book more directly to.
Find Accountability
And the fifth lesson I got from Rob is not actually in the book.
But after he wrote Write Useful Books, he established an online community, the Useful Books community. I’ll put a link in the show notes.
I met a lot of other writers that were writing nonfiction books. Some were for similar audiences to mine and some for very different audiences. But they were all nonfiction, useful books meant to be problem solvers. And I got a ton of advice.
We meet a few times a week and we spend 45 minutes of that time just writing. And then we share what we did and the things that we’re learning. 70% of my book was written in those sessions.
Define Your Audience
In the next few episodes of Write While True, I’m going to go into more depth about some of these lessons. The takeaway I want you to have from this episode, though, and it’s really the first thing you need to do, is to think about who your target audience is going to be.
For a lot of people, it makes sense that they pick an audience that they’re a part of. That’s what I did. I’ve been an engineer and engineering manager for over 30 years. So I targeted people like me.
I tried to write the book that I would want.
If you want some ideas, go back to episode 5, where I talked much more in depth about how to pick an audience. In that episode, I recommended picking a single person. Or you could follow what Amy Hoy of 30×500 says. She recommends to pick either someone like you, someone who wants to be like you, or someone who would hire you.
In episode 46, the last episode, I told you why I decided to pick an audience that was like me.
Thanks for listening.
This has been Write While True, a podcast where we love infinite loops as long as they’re fun.