Author Archives: Lou Franco

Seven Years of Slow and Steady Progress Towards 30×500

I just looked it up—I enrolled in Amy Hoy and Alex Hillman’s 30×500 course in 2017. The course teaches their technique for starting a small subscription-based business that gets $30/month from 500 customers. 2017 was also the year that Atlassian acquired (my employer) Trello. Since I was locked into a 4-year vesting period, and I wanted to work at Atlassian for at least that long anyway, I was never going to start a business right away. But I thought it would be a good idea to lay some groundwork so I could be ready whenever I decided to leave Atlassian.

The first step in 30×500 is to pick an audience—ideally one that you are a part of or that hires you. I picked iOS developers. So I started adding educational content to App-o-Mat, a site I started a few years earlier to build on my book, Hello! iOS Development, but that I had neglected. With this newfound focus, the posts I wrote in 2017 helped me become a more frequent contributor (and editor) of the mobile section for Smashing Magazine. The money I made from Smashing paid for the 30×500 course several times over, but it was hard to keep writing and also excel at my day job, and so I let the writing wane over the next few years.

In 2021, after I resigned from Atlassian to go independent, I decided to get more serious about applying 30×500 techniques. I concentrated on WatchKit and Workout tutorials because I could repurpose what I had learned writing Sprint-o-Mat. But my consulting business became more software business coaching and less programming, and I realized I wasn’t really in the iOS developer audience any more. So, I started searching for a new one.

I got serious about writing educational content along a lot of different dimensions including software (of course, but more like what I was consulting about), but also job searching, personal finance, and writing. Over the next couple of years, I wrote hundreds of posts. Looking them over at the end of 2023, I realized that I had a lot to say about technical debt.

At the beginning of 2024, my goal was to write a small (50 page/10k words) e-book—more of a pamphlet—on technical debt. This led to a guest article on The Pragmatic Engineer (so I was continuing to get paid to write). Mostly, I treated this as signal that that the content was useful. But the article helped me build an email list and led to podcast invites and webinars, and the content grew based on what I was being asked about. Last week, I sent a document with 40k words to my editor—my hope is that it will be ready to publish by Q1 next year.

So, here I sit, seven plus years after I took the 30×500 course—I still don’t have even 1 of the 500 paying me $30/month. However, the course long ago paid for itself in direct dollars for my writing and easily 100x in terms of the consulting work the writing helped me land and service. The secret sauce of their method leads to finding an endless supply of topics to write about. Honestly, I barely do it right, but just going in the right direction has been good enough.

It helped me develop enough content for a book and the seeds for a few more. I do think there’s a subscription business here. Or maybe a YouTube channel? Or maybe just what it is so far: a blog, a podcast, a book, a source of leads, and proof to myself that I’m a writer.

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.

If code reviews take too long, do this first

Short feedback loops are one of the drivers of productivity according to the DevEx model. On my team at Trello, we had a goal of all reviews being done inside 24 hours. Having that goal drove behaviors that made most reviews complete in a few hours. So, to start, collect data and get on the same page.

If your reviews are taking too long, try these enabling steps first:

  1. Gather metrics: If you use GitHub, try this repository metrics script to get a baseline.
  2. Get consensus: Nothing will happen unless the whole team is on board with this being a problem and that it can be fixed.
  3. Set a goal: I know from experience that 100% of reviews in less than 24 (work) hours is possible. If that seems out of reach, set something that you could accomplish in a quarter.
  4. Inspect outliers: Treat outliers like you would treat an outage incident.
  5. Compare reviews that met the goal to ones that didn’t: Gather statistics about PR’s and see if you can find differences between the ones that did and didn’t. For example: number of lines changed, the author, the reviewer, the number of commits, the part of the codebase, etc.
  6. Put real-time monitoring in place: If you are the lead, just do this manually to start. At the beginning of the day, make sure all of yesterday’s PRs are going to be reviewed soon.

Tomorrow, I’ll write about some common problems and what to do about them.

Network with Alums Just Ahead of You

Yesterday, I wrote about using your alumni network to make you more lucky. In most of my stories, the alumni network that was most helpful were in my year or just a bit older. They are the ones that just got a job and know what works in the current job market. They are also the most like you, so their advice is relevant. And, they know you, and like you, and so they will want to help you.

When I talk to my mentees, I keep warning them that my information is way out of date. I got my first job by looking in the classified ads in a newspaper. That ad led to a recruiter that placed junior software developers. Those parts of my story are from olden times.

But, networking with your college classmates is evergreen. The easiest way to do this is to just be a good classmate, study partner, and extra diligent when working in groups.

Alumni Networks Increase Your Luck Surface Area

When I walked into the second interview at my first job, one of the developers said: “Hi, I think you know my husband.” It turned out that her husband was a college classmate of mine. I didn’t get the lead from him (that would have been smart of me), but at least he must have said nice things when she asked (or I’m guessing I wouldn’t have been hired). It was pure luck, but I’m a big believer that Randomness is the Great Creator.

The woman who would become my wife started at that same company two years later. She was smart enough to get a referral from her alumni network, who had also gotten the job through an alum connection from a third person who had worked her alumni network to get the job through the wife of one of our executives. It was a triple-bank shot, with absolutely no chance of working, but without it, I would never have met my wife.

My luck continued. At my next job, I helped find one of our early customers, who was a prominent alum I had met because he hired a few of my friends (fellow alums of both of us). The work we did for them eventually led to a patent and getting VC money to pivot to a startup. This was more than 25 years ago, and I am still on the board and participating in their successes. More than 90% of my 2024 income came from connections I made there.

From the outside, it looks like randomness, and it is, but there are things you can do to move the odds, and networking with alums is an easy one.

Four Ways to Augment Code Coverage

Code Coverage by itself is a hard metric to use because it can be gamed, and so it will suffer more from Goodhart’s Law, which is summarized as “When a measure becomes a target, it ceases to be a good measure.” Goodhart’s Law observes that if you put pressure on people to hit a target, they will, but maybe not in the way you wanted.

And this would happen with code coverage because we can always increase coverage with either useless tests, tests of trivial functions, or tests of less valuable code.

I use these metrics in combination with coverage to make it harder to game:

  • Code Complexity: The simplest way to do this is to count the branches in a function. I use extensions in my code editor to help bring complex code to my attention. If coverage of the function is also low, I know that I can make the code less risky to change if I test it (or refactor it).
  • Usage analytics: If you tag your user analytics with the folder that the code generating it is in, you can later build reports that you can tie back to your coverage reports. See Use Heatmaps for iOS Beta Test Coverage. In that post, I used it to direct manual testing, but it would work for code coverage as well.
  • Recency of the code: To make sure that my PRs have high coverage, I use diff_cover. This makes it more likely that my tests are finding bugs in code that is going to be QA’d soon and has already been deemed valuable to write. Very old code is more likely to be working fine, so adding tests to it might not be worth it. If you find a bug in old code worth fixing, it will generate a PR (and become recent code).
  • Mutations: I am still trying to find a good tool for this, but this lets you test the quality of your assertions in addition to your coverage. I do it manually now.

Generally, the way to make a metric harder to game is to combine it with a metric that would be worse if it was gamed in ways you can predict (or have seen).

Invaders game screenshot

Play Invaders on Glitch

My nephew and I are meeting once a week to make video games. We are using Phaser (and Javascript) as our game engine and Glitch as our coding IDE.

Here’s one of our game: Invaders. Since it’s on Glitch, you can see all of the code and “remix” it into another game. In the constructor of the Invaders class there are a lot of member variables that you can can to tweak the game to your taste.

I’m sharing this because I think that to learn programming, you should Start with a Working System, not use tutorials. This is more like what real programming jobs are anyway. Once you are comfortable with what the code does, then build a new game from scratch by copying over pieces a little at a time as you need them. That’s what I did to learn Phaser. The game I used is out of date, but I’ll share my fork and update soon.

In this game, we use

  • Sprites
  • Animations
  • Sounds
  • Keyboard controls
  • Collision detection
  • The physics engine: so that we can use velocity instead of updating the positions manually

You can make a lot of games with just those basic tools.

November 2024 Blog Roundup

Whenever I am near the end of a year, I start planning for the next one. This has made me blog more than I had been in the early fall.

I wrote about planning for 2025

I’m also going to start podcasting soon, and I’m trying to find a way to bring them to YouTube

One of my major activities this year was working on my book on tech debt. I am wrapping that up and starting to think about marketing.

My next draft of the book is due on December 4, and so I will be spending most of December finding things to do while waiting for it. I hope to have some new podcasts with my major lessons learned writing it.

Practicing Doodling

I want to add videos to each my podcast episodes, so that I can post them on YouTube. One option I’m exploring is trying to sketchnote them while listening to them. This is a lot harder than I thought.

I have two problems. The first one is that I can’t do it fast enough. That’s easy to solve: I can just do it at any pace and fix it in my editor. The second is that I don’t draw well. Slowing down helps, but I just need to get better at doodling and coming up with objects to draw that represent the concept I am talking about in the podcast.

To practice, I saw Quick, Draw! on the Verbal to Visual YouTube channel. Google is training a neural net to interpret doodles, and it’s already good enough for this simple game. It gives you an object to draw, and you have 20 seconds to draw something the net recognizes as that object. When you are done, if it didn’t get your drawing, you can explore other drawings that the neural net did recognize as that object. They even let you explore the dataset of simple doodles. If you see one you like, you can tap it to see it being drawn, stroke by stroke.

I try to do it without thinking first because I want to get better at doing it live. I’m especially bad at animals. One drawback is that every prompt is an object, but I want to get better at translating verbs and concepts to visuals. I’d also love to see what people would draw for words like confusion, hunger, defiant, or tired.

Even playing for a half hour, I got much better. Not at animals, though.