Author Archives: Lou Franco

Where do Post Topics Come From?

Yesterday, I said that I keep a topic list that goes at least a month out. In reality, not all of those will be written into posts, but I need a lot of choices each morning as I sit down to write. The list is under constant maintenance, but the most important thing to do is to keep adding to it.

Here are some of the places those topics come from:

  1. From a question I am using to drive my thinking. See: What are books for?
  2. From the notes I am taking while reading. See Playing Non-programming Books
  3. From writing posts. Yesterday I consciously listed the new topics I thought of while writing the post on topics.
  4. From editing my banked posts. When I delete a paragraph that is interesting, but not related, that paragraph can become the seed of a new post.
  5. From solitude. See Use Deprivation to Make Space
  6. From correspondence. If someone asks me an interesting question, my answer can often be generalized into a blog post.
  7. From my old work. I’ve been blogging and writing publicly for over 10 years. Old posts need updating: See Use GitHub Profile Pages to Mirror Your Personal Site
  8. From my tweets. I don’t tweet a lot there are enough to look back at and see if there’s a bigger idea there.
  9. From my other works. I write about my apps, like in Sprint-o-Mat 2021.1 is Available
  10. Current events, like WWDC. See: WWDC 2020 Wishlist – Xcode / Swift or WWDC 2017 for iOS Developers

I personally keep them organized into a schedule so that each day, when I am ready to write, I can just look at that day’s topic and give it stab. It doesn’t always work out, but not having to choose from the list helps me get started.

If I give up on a topic, I can take what I’ve written and link it to that topic in Obsidian. I move it down a little in the list and move onto the next one.

If it’s too big, that’s actually great, because I break it down into a few mini-topics to build up to a bigger idea later.

Make Writing Easier by Having a Long List of Topics

The last few posts have been about my practice of blogging every day, how I bank posts, how I start with a bad first draft, and how I ease into my writing day with morning pages.

In the past, when I set goals to write more frequently, I was always stopped by not having ideas for what to write about. Or when I got one, I didn’t have a systematic way of collecting them. I would sit down to write, but getting started on a new piece was too difficult.

My goal now is to make writing a first draft easy by keeping a long list of writing topics of varying degrees of difficulty.

When I add a topic to the list, I try to develop it a little with notes for why it’s on the list in the first place. If I have already have notes in Obsidian that are related, I link them. All of this will make it easier to get to a first draft later.

Having a long topic list gives me lots of choices for what to write in the moment based on how motivated I am. Not every topic will work out. If that happens, I grab another one.

The key is that I am not blocked at the time I sit down to write by not having any ideas.

Tomorrow, I’ll write about how I generate this list.

Update: Here is the post about generating the topic list

Doing Morning Pages Helps Me Make Shitty First Drafts

I am in the middle of reading Julia Cameron’s The Artist’s Way [amazon affiliate link], a classic about what it means to be a creative professional. The book is not meant to be just read, it’s a book you use, a book you play.

There are many tasks and exercises throughout, and you are meant to read one chapter at the beginning of the week and use the rest of the week doing the tasks in it.

But, before you even start, Cameron describes a task you will do each morning: your morning pages where you fill three pages with long-hand writing. What do you write? It doesn’t matter. What matters is that you start and do not stop until the pages are filled. She says to think of it as DOING morning pages, not WRITING morning pages. I think of it as PLAYING morning pages (like scales).

These pages are write-only. You can destroy them right after. Don’t read them and never show them to anyone. They are not writing—you never want to expose them to criticism because you never want any reason not to do them.

I started my morning pages journal on December 28th and have never missed a day. I can’t wait to do them, and once I start, I can’t wait to finish. Because, right after I do them, I am so ready to write “for real”.

It is 7:45am right now, I finished my pages at 6:56am. The first thing I did was edit the next two posts that are scheduled to publish, and then I opened my topic list and wrote a first draft of this post. I just noticed that I never wrote about my topic list, so now I am ready to write a post about that. Like blind drawing does for sketching, the morning pages prime my brain for continuous writing, which carries through the whole morning.

Shitty Blog Post First Drafts

In Bird by Bird [amazon affiliate link], Anne Lamott’s book on writing, she recommends writing “shitty first drafts”. I am using this advice as I bank blog posts. This morning I reviewed The Practice, and about 5 minutes ago I finished writing the post about banking posts. At the end of that post, I wrote that I had more tactics, and shitty first drafts is one of them.

Right now, I am typing this out as fast as I can, not editing. Just writing. This practice makes it so I have some raw material to work with. Since it’s now January 28th, and this post won’t be published until February 11th, I have 2 weeks to edit it.

Having gotten this far, I think I might leave this one the way this is so that you can see what a bad first draft looks like. In general, I would try to tighten it up—I can see that this one is a bit wordy already.

At this point, I’m just leaning into it. If this is going to be a shitty post, I might as well make it extra shitty so that you can see that there’s no need to have a polished post right away.

The only hard part is coming up with some kind of ending, but I usually find one in the edit.

Banking Blog Posts

Today is January 28th at 6:45pm. This blog post will be posted on February 10th at 10am.

This morning, I wrote a review of The Practice which published on February 9th. In that post, I mentioned that I published 30 posts in the last 30 days, but, I wrote those 30 posts in 19 days, and set them up to publish over 30 days.

Since I’ve been actively reading and writing notes, I have a big backlog of ideas and nascent writing. Blogging has been mostly about assembling these notes into posts, and banking them has taken all of the pressure off in trying to blog every day. With the pressure off, I sometimes write a couple of posts a day.

I have a few other tactics I use to make sure I publish every day, which I’ll post in the next few days (but I’ll write them right now).

Review of The Practice by Seth Godin

I started this blog in December 2003. Up to 2020, I made an average of 9 posts per year, with a high of 38 posts in 2008 and had several years with none.

During this time, I wrote a book, wrote on App-o-Mat and for Smashing, and so generally, I’m at peace with my writing output. Honestly, though, I had intended to write a lot more. I just never did it.

I finished reading The Practice: Shipping Creative Work by Seth Godin in early January. It’s essentially 219 short, blog-like chapters making the argument that you can choose to ship every day.

Here’s my review.

It is 30 days since I finished reading The Practice, and I have shipped 30 blog posts and an update to one of my apps. Will I keep this up? I have evidence and confidence that I will, mostly because I buy his argument that I can just do it, and doing it will improve my writing. It’s a practice only if I practice it. It’s an infinite game.

The Practice helped me understand “the why” to shipping daily, and that’s enough for me. Doing it with this mindset has made me realize that it’s actually not that hard.

That’s it. That’s the review. I read the book. It changed by behavior.

I have a lot more to say about my practice, but to add more info to prior posts, my daily Big 3 almost always includes writing a post, and a time-block is reserved for it. I chose my yearly theme, Hone, because it’s about improvement via repetition. I put “Practice” on my Habit Totem so that I am reminded to do it constantly.

Robotic Pair Programmers

If search engines ever get eclipsed, I think it will be by something in the environment that just brings things to your attention when you need them. I want this most when I code, like a pair programmer that just tells me stuff I need to know at exactly the right time.

When I’m in Xcode, there are so many times when I need information I don’t have. To get that information, I need to initiate a search. It breaks my flow to do this.

What I want is that information to just be in the environment.

One way this already happens with with code comments. In my source, I trust all of the editors, so I would like to see all of their comments and commit messages. This is actually possible if I turn on the Authors sidebar in Xcode.

But, what more could I get? Let’s say I index every Xcode project in GitHub, every iOS tutorial, every iOS question in Stack Overflow. Could that be distilled somehow and then shown to me at the right time?

One way that seems fruitful to me is rare API calls. There will be times when I am using an API that appears very infrequently in the corpus or my own repositories. In that case, it should infer that I probably need more help than usual and offer up a tutorial or the top Stack Overflow questions.

Another trigger might be my new comments. If I comment before I code, then it should be interpreted as a search query:

// Parse the JSON I get back from the data task

That should bring up links to likely API classes in the help pane (just like it would if I already knew the class). Maybe offer up imports to auto-add. Maybe offer a snippet. In Xcode it would be similar to the auto-suggested fixes for compiler errors.

This is just the beginning, and we can do a lot more. Whatever we do, we need to make sure that nearly every suggestion is useful, because we risk knocking the developer out of flow. Conserving flow should be the driver for how this works.

Soundtracks for Apps

A few days ago, I wondered about soundtracks for books. I had an aside where I mentioned that game soundtracks are synchronized with the player’s actions (like a book’s would have to be).

That is also true of a non-game app. If an app had a soundtrack, then it would also be synchronized with behavior, state, situations, etc.

Apps often use system sounds. So, if you do something that isn’t allowed, you could get an error beep. Alerts similarly come with a sound. That’s been around probably since the first GUIs. Those aren’t soundtracks.

But, I’ve been trying to think about all apps as potentially games, or having game design drive the app design. So, that means sound design has to be part of it. In fact, I think it’s a tell that not being able to conceive of sound design for an app means that it isn’t using game-driven design. What’s the soundtrack to MS Word?

In Pokémon Go vs. Apple Workouts, I said that game-design doesn’t drive the Workouts app—it’s slapped on. And even though I play music while doing a workout, that’s not a soundtrack either.

But every workout app could have a sound layer to let you know what is going on. in Sprint-o-Mat, I give you a ding when it’s time to start sprinting. Apple workouts have pace alerts.

But, what more could you do? In AR opens up playability, I said that even mundane apps could become games with AR (e.g. Grocery List vs. Zombies). We have a kind of AR right now with just headphones, so maybe the right sound-design (more than music or system sounds) could make a workout more like a game.

So, if the game in Sprint-o-Mat is a race, here are some ideas for a game-design driven soundtrack:.

  1. Crowd sound
  2. Have the crowd yell out your name
  3. Give a sense of the location of the pace-setter
    1. Footsteps
    2. Heavy breaths
    3. Friendly banter: “C’mon keep up, don’t let me pass”
  4. Add in band music that you pass (is at a physical location that you approach and leave)
  5. Have an announcer yell out your name and final time at the end

Sprint-o-Mat 2020.2 is Released: Run in KM

From the beginning of Sprint-o-Mat, I always internally represented distances as an enum with an associated value:

public enum Distance {
  case mile(distance: Double)
  case km(distance: Double)
 
  static let kmPerMile = 1.60934
}

So, adding kilometer support in Sprint-o-Mat was mostly about adding in some UI.

I added a button to flip the units, but I didn’t want a straight conversion. I wanted it to round to the closest tenth.

public func flipUnitsAndRound() -> Distance {
  switch self {
  case .mile(let d):
    return .km(distance: round(d * Distance.kmPerMile * 10) / 10)
  case .km(let d):
    return .mile(distance: round(d / Distance.kmPerMile * 10) / 10)
  }
}

I do the same for paces, and round them to the nearest 15 seconds.

With this done, it was mostly hunting down all of the places I was lazy—mostly inside of my HealthKit code that is getting running distance from the Watch in miles.

I left that as is, but made all of the mathematical operators for Distance work for mixed miles and kilometers, so I could could construct a .km Distance and then += .mile distances onto it, and the conversion would be automatic, keeping the units of the left-hand side.

public func + (left: Distance, right: Distance) -> Distance {
  switch (left, right) {
    case (.mile(let ld), .mile(let rd)):
      return .mile(distance: ld + rd)
    case (.km(let ld), .km(let rd)):
      return .km(distance: ld + rd)
    case (.km(let ld), .mile(let rd)):
      return .km(distance: ld + rd * Distance.kmPerMile)
    case (.mile(let ld), .km(let rd)):
         return .mile(distance: ld + rd / Distance.kmPerMile)
     }
}

func += (left: inout Distance, right: Distance) {
  left = left + right
}

If you run in kilometers, check out the new version.

How to Use Rejection

One of the more exciting things in life is to be accepted to do something that was competitive, and where you stood a good chance of rejection. That could be our stretch choice college that seemed out of our reach. Or that new job or promotion that we technically don’t qualify for. Or as simple as getting a date with someone out of our league.

It’s exciting to punch above your weight.

But, the chance of rejection can sometimes make us not try. We say that we’re not ready. That is probably true. In fact, the more chances you take, the more likely it is to be true.

But, rejection is a great way to find out how to get ready. It’s not something to be avoided. It’s a tool we can learn to use.

Here are ways we can use the possibility of rejection

  1. To motivate us to practice and prepare
  2. To focus our requests for help

Here are ways we can use actual rejection

  1. To ask for specific feedback
  2. To drive a post-mortem
  3. To improve our approach for next time
  4. To help others in our position