Author Archives: Lou Franco

Applying My Book Selling Content Strategy on Sites I Control

As I wrote yesterday, the core belief that drives my marketing strategy for Swimming in Tech Debt is that I truly think the book will help software developers get things done in codebases with tech debt. Given that conviction, and the fact that I care about software developers, I don’t feel shy in asking you to read my book.

On sites that I own, I just overtly write about the book and the processes that I used to develop it. This content goes out to my email list, this blog, and my podcast. Each place is slightly different.

The subscribers to my email list are expecting updates about the book. That’s the specific reason I give for signing up, so sending those updates is not only expected, but I would be not meeting my obligation if I didn’t send that update. That being said, I usually try to send something along with the update that would be interesting to people who signed up.

Similarly, readers of this blog are ostensibly expecting me to write about what I am working on because all of the advice I give on this site is based on my experience. If you are subscribed to this blog (and read it and like it), then I am sure that you’ll like the book—about 1/3 of the content is based on posts here. So, I don’t think you’ll mind me mentioning it.

The podcast is a little different because it’s only about writing and not software development. In season 4 of my podcast, I am going through the steps that I took to write the book. If you are a software developer with a blog, I think I have tips for you to turn your posts into a book. If you don’t have a blog (or even private writing) yet, then the first three seasons are about developing a writing habit that results in a corpus of work to draw from. I talk about my own book in order to explain the process of writing it, but content from the book isn’t appropriate for the podcast.

So, for places I own and that are tied to my identity, I feel free to just write and talk about the book. For all other places, I just want to be a good citizen. The way I do that is to try to use a 0-click strategy. I don’t know if this is the most effective, but it’s what I personally value.

I’ll write about that tomorrow.

My Content Strategy for Selling a Book

I am hoping to be done with Swimming in Tech Debt in a few months. Most of the work between now and then will be getting the book through three editing passes, which gives me a lot of down time. I’m using that time to market the book via content creation. This blog post is part of that.

I don’t mind just saying that overtly because I am following the advice of Zig Ziglar in Selling 101 [affiliate link]. If you don’t know him, Ziglar was one of the selling gurus and motivational speakers of a half-century ago. I would say that it’s the exact kind of person I wouldn’t read, but he’s often mentioned by Seth Godin, so I bought the book and read it years ago. He’s not at all what I imagined—a core part of his philosophy is integrity.

This line has always stuck with me:

If what you are selling is not good enough for your friends and family, then why are you selling it? If it is good, then why would you want to keep it from those you care about most? […] The key is your conviction that you really are offering something that will strengthen the friendship.

Here’s another:

Here is the most important step [to] take when it comes to helping others. If you truly have a desire to help other people; if you truly believe in your product or service; if you truly want the prospect to benefit […] always ask for the order.

It is with this conviction that I am writing these posts to tell you about my book. I think that most of the people that read this site got here because they are software developers, and if you have come back after reading, then my way of thinking at least resonates with your way of thinking. But, I don’t just want to post an advertisement (or even an addvertisement). I want each thing I write to be useful on its own, not a pitch for the book.

So, that’s my strategy—I am telling people something I think will benefit them. To do this, I am posting on Mastodon, LinkedIn, Reddit, here on this blog and in my podcast, to my email list, and other places. I have different criteria for what I post where, which I’ll go into soon.

Can non-programmers make applications with AI?

Of course! Non-programmers have been making applications for decades, well before there was anything like AI helping them. In my experience, the people who really want to make applications learn what they need to learn. AI closes that gap. No-code tools do that too. So does having things like npm, htmx, React, Pandas, SQLite, AWS, etc. But, the motivated can close bigger gaps if they have to.

My first job was in 1992, working for a company that made FX Options Pricing software. That company was founded by an FX Options trader who was a “non-programmer” until he wasn’t. He taught himself enough C to make simple programs to help him price options at work, and just kept making them better until he was able to sell copies to FX Options brokers and traders. And then he used the money to hire programmers, but he still worked on it for at least the first five years of the company.

A couple of jobs later, I got a job at a startup where the first versions were written by the founder, a mechanical engineer, who probably took programming courses, but was not a “professional programmer”. His first two hires were also self-taught. They went from hacking around with scanners and simple websites to building the web-based scanning and Ajax document viewers that were the basis of our acquisition.

At both places, programmers (like me) were brought in. We added some “professionalism” to the codebase and processes. We helped the teams scale, the products be more reliable, and the delivery be more predictable. But bringing us in was just another tool they used to close the gap.

Write While True Episode 44: Write In Public

Podcast: Play in new window | Download

My intention after episode 43 was to follow along the process of writing the book and share what I learned along the way. But, a few things happened that derailed me (in a good way).

transcript

Write Test Plans for Every PR (and do them)

On the ticket/issue/item attached to your PR, write out the steps to see the change in the application your PR introduces. Even better, record yourself doing them. Not just the happy path, but also show the types of errors that can happen and how the application shows them.

I wish I did this more when I worked on a team, but when I did, everything went smoother through code review and QA. Not because it helped the reviewer or QA engineer—I’m sure it did.

Mostly it helped because I made sure I did all of the steps in the test plan before I posted the PR. Also, writing down a test plan put me more in a tester’s mindset where I was trying to think of things to check and finding problems before I submitted my work.

With all of those things out of the way, the reviewer and QA engineer could concentrate on bigger picture things to check.

How to Find Bugs in a Code Review

I have written that the primary reason to review code is knowledge sharing, not finding bugs, and that the way to use code reviews to prevent bugs is to reject PRs that aren’t obviously correct. But what should you do if you really want to try to find bugs during review?

Run the code—preferably in a debugger from a test.

The best tip I got from Steve Maguire’s Writing Solid Code [affiliate link] was to step through my code in a debugger as I was writing it. The original version of this book (1993) came out before xUnit based unit-testing took off, so I don’t remember him mentioning them. But, I think a unit-test is a better way to do this.

If you don’t have a test that puts you at the line of code you want to inspect, then driving the code manually while stepping through the code in a debugger is a good-enough option. Of course, not having appropriate tests is probably a good enough reason to send the PR back, but if that’s not your team’s culture, and you want to find the problems manually during review, at least use a debugger.

It’s more likely you’ll see problems if you are actively engaging with running code. You will be anticipating what is going to happen as you step through, and if the code behaves differently, you’ll notice. You’ll either find a problem or learn something.

How to use Code Reviews to Prevent Bugs from Getting Into Production

When code has a bug in it, that is way more of an author problem than a reviewer problem. I don’t think it’s right to expect reviewers to find bugs (or to rely on it). It’s way harder to do that unless you actually run the code.

So, I would suggest that to fix the problem of buggy code making it into production, you do more things at the author level, since the author should be running the code a lot through tests and in the debugger. If you have a code reviews checklist, give it to the author, who should be reviewing their own code before PR’ing it.

Then, the reviewer should be verifying that there is evidence that the author actually did thorough work. The review checklist should be verifying the author provided evidence that the author did the pre-PR checklist. Check the tests, check their coverage, check UI screenshots, check that code is doing “something” with edgecases and that those are tested. Instead of looking for bugs, the reviewer should be learning the code and looking for higher level issues.

The author should be providing code that is correct and easy to see that it’s correct. If the reviewer doesn’t think it’s obviously correct, they should reject the PR. The presence of such a review will make the author do more thorough work.

Books That Propelled Me in 2024

These three books did the most to help me make progress in 2024

1. Nonfiction Alchemy [affiliate link] by Jordan Ring

I already finished a draft of my book before I read Nonfiction Alchemy, so I learned some of his lessons the hard way. The biggest change I made after reading it was to my title. I had been using a more literal “promise” based title, but wished it was pithier. His description of how he came up with his title and why helped me come up with Swimming in Tech Debt, which I think works a lot better. The subtitle will do the work of conveying my promise.

The new title is more visual and communicates my main metaphor of using your encounters with tech debt as a trigger to make progress—“swimming” rather than “drowning” in tech debt.

I wrote more about this in Titling a book and Book Title as Visual Metaphor.

2. A Philosophy of Software Design [affiliate link] by John Ousterhout

So many gems—it should be required reading in any CS program. Ousterhout’s target is complexity in software, which is very related to technical debt. My book is more about any code that resists change, which includes well-written, simple, easy to understand code that just can’t be changed in the way you need it to be. This book is about understanding the sources of complexity and fixing them.

3. Slow Productivity [affiliate link] by Cal Newport

This is Newport’s latest book in a continuing series about his approach to work and life. If you haven’t read Deep Work [affiliate link], I would start there and move onto Digital Minimalism [affiliate link]. This book shows how to make big things at a slow pace. I worked on my book in my marginal time: a hour or two a day. But writing hundreds of words a day, a thousand every week, builds up. There were edits, restarts, rewrites, etc. But the pace was sustainable, and I owe a lot of that strategy to this book. (Also see The Four Disciplines of Execution [affiliate link] — which is referenced in Deep Work)

Make Spaces for Things to Track In Your Journal

In Make a Space For Each Day in Your Journal, I wrote that I was more likely to journal every day when there were pages pre-printed with the date on top of them. If I missed a day, I would see the blank space and want to fill it by recreating the day from whatever other sources I had.

This also works on the daily page itself. If there’s something you want to do every day, then pre-printing that on the journal page will keep reminding you to do it. This is one of the reasons I think you should make your own custom journals, because it will be hard to find one that is pre-printed in the way you want.

In 2025, my pages are blank, but I split them in half. The top is meant to be used like a bullet journal. The bottom is a food log. I have found that the biggest impediment to me reaching my fitness goals is not eating as well as I could. In 2022 and 2023 I scribbled my food log in the margin. There wasn’t a lot of room, so I only put the major meals, but it’s the snacking and details that are causing problems for me.

So, by keeping a thorough food log I hope to make it more likely that I will be more intentional in what I eat. Back in 2012, I wrote that you should Take a Picture of What You Eat because just that simple act will influence you—I know from personal experience that having to write down that I ate junk food stopped me from eating it.

Of course, you can do this even if you have something that you want to track weekly or on specific days. In The Four Disciplines of Execution [affiliate link], the third discipline is to make a scoreboard that tells you if you are winning. One way to do that is to pre-print it on your weekly retro page.

In general though, I think it’s more important to have a labeled space than a specific template. Over a year, you might change your mind on what to track. I’d rather have a blank “Scoreboard” area that I am compelled to draw than a rigid one that might go out of date.

Aspirational Plans for 2025

On this blog, when I talk about my annual plans, I am talking about aspirations. The vast majority of my time is spent on living my normal life: work, home, cooking, travel, time with wife, family, and friends, etc. When I look back at 2024, I see what I can do with my marginal time—an hour for fitness and a couple of hours a day to either write or work on my own software added up to a lot.

So, this year I hope to apply that lesson to marketing my finished work better. My strategy is to create content that supports it. I will toot, blog, post on LinkedIn, and email my list — but try to make the content useful in of itself (not promotional). I also want to podcast and YouTube too, but that’s a stretch goal. The written posts don’t take very long—but podcasting and videos are much harder for me.

For fitness, I am going to swim at least twice a week. My apartment has a pool, but I rarely take advantage of it. I need low-impact cardio alternatives anyway, but this will also remind me of my book (Swimming in Tech Debt) and my general 2025 theme to “Just Keep Swimming”. Another advantage to swimming is that it’s very hard to listen to something while doing it, so I have 30 minutes with just my own thoughts—it’s very meditative. It’s an analog hobby that affords solitude (like in Digital Minimalism by Cal Newport [affiliate link]).

My work since the late nineties has been mostly in developer tools or tools for productivity, and even the startup I’ve been working on is in this general area (personal productivity). I want to expand on this. I have ideas for tools that support the themes I write about, and I want to explore those in 2025. To play on my book title and theme, the ideas are fins (to help you go faster) and goggles (to help you see debt better)—I wrote about Tech Debt Detectors on this site and in my book, and these ideas are variations on that.

I’m going to apply The Four Disciplines of Execution [affiliate link] like I did last year, which I’ll write about later this week.