Author Archives: Lou Franco

Edit in Sweeps

A few years ago I saw Joanna Wiebe talk about her 7 sweeps editing technique at the Business of Software conference.

The basic idea is that you edit a work in successive sweeps where each sweep only tries to improve one kind of thing. For example, her first sweep is to improve clarity. Her sweeps are designed for advertising and marketing copy, but the basic idea of editing for one thing at a time is working for me.

Since I bank posts, I have a lot of time to edit them before they get posted. Right after I write my first draft of the next post, I go to the upcoming posts and edit the ones that would publish next.

Here are my current sweeps

Clarity as Joanna describes: Who is it for and what is the message? Is that clear?
Grammar, spelling, punctuation
Remove unnecessary parts – these may be the start of another post.

I don’t yet do these sweeps, but I should

Make the post actionable. What can I challenge the reader to do right now?
Edit for voice and tone. Joanna has a video about that too. I am struggling with finding my voice.
Make the post valuable to the reader. (I’m sorry, but I am trying)

So, do this now:

Watch Joanna’s Clarity Video.
Pick a piece of recent or upcoming writing you have.
Think about who your audience is (a key part of how you make things clear).
Do a clarity sweep on that piece.
Think about what sweeps would make your writing better and figure out what you will actually do in that sweep. As I develop mine further, I’ll share.

Alcoa’s 1958 Plan to Make Programmers

In 2019, I went out to dinner with my father-in-law and his retired friends. I met someone who became a UNIVAC I programmer in 1958.

I asked him how he became a programmer. He said he was in Alcoa’s accounting department for a few years right after college. HR came to him and asked if he wanted to take an aptitude test for a different job.

He passed the test, and so they trained him to be a programmer—he went on to have a decades long career in industrial control software.

He described some of the work to me. A lot of it sounded like data engineering—he said he became an expert in “preparing inputs”. He worked on early projects to computer-control aluminum production.

If you don’t know Alcoa, in the 50’s, they were inventing ways to sheathe skyscrapers in aluminum. They invented pull-top cans.

Kudos to Alcoa for training new programmers—if you are finding it hard to recruit, you might want to follow their lead.

Review: Building a Princess Saving App

Having a driving question helps me find interesting, less-mainstream content that can help shape my thinking. One question I am exploring is how game-design can drive app-design (not via gamification). The presentation, Building a Princess Saving App, describes it perfectly.

This talk is about building learning and fun into your applications. If you’ve ever wondered how games work and how they can help you build better apps, this is the talk for you. Along the way, we’ll discuss a new philosophy of interaction design that is already creating a major competitive advantage for innovative application developers.

The slides describe how typical enterprise and Web 2.0 application designers might approach the problem of saving a princess vs. how Super Mario Brothers does it.

Along the way you learn the language of game-design and the STARS model. Well worth a read if you are interested in this topic.

Professional Performances

I’m not a huge fan of technical interviews because I think they are closer to auditions than programming work simulation. I wrote:

A typical tech job is not a performance. For one, there is no audience. And, unlike a performance, we make tons of small mistakes and corrections along the way. Imagine a band performing a song like we usually program—it’d be a mess and not very entertaining (or very entertaining if you think of it as avant-garde).

But, there are times where the work is a performance. For example, presentations or talks. For that, I recommend treating them exactly how performers do—with lots of practice: solo and in front of audiences.

When I recommend this, the push-back I get is that the person doesn’t want to sound like they memorized their presentation.

I agree.

Actors and musicians completely memorize what they are going to perform, but then give a natural performance. Stand-up comedians practice being flustered and reaching for words. The more you practice, the more natural the performance will look. When you do it, you will be in a flow-state.

If you want to see this in action, look at any TED talk—they are highly polished performances. Steve Jobs was also famous for practicing intensively.

But, practice has a much more important effect—it drives self-esteem. If you put the work in, you will see it. You will see that you are doing rehearsals and you will judge that you are likely to succeed. You will feel pride and you will want to do it more.

That sense of pride may turn us from dreading speaking in public to actually looking forward to it. After your successful performance, you will have the confidence that comes from success, which will drive you to practice more and start a virtuous cycle.

Incidentally, this works for interviews too.

Writing While Reading

In a Cortex podcast episode about their favorite apps, CGP Grey singled out Obsidian. The recommendation was so over the top that I had to try it immediately. Obsidian is a note taking app. I wrote a little about how I use it to make reading a game.

When I say note-taking, I mean original writing, not copied notes/quotes. To fully understand this, I highly recommend How to Take Smart Notes, which is the most important book I have read in years in terms of impact on my reading/thinking/writing.

The goal of notes, according to the book, is to be pieces that can be readily assembled into publishable work. Given that, a note must be original writing somewhat ready to be published. They aren’t long, though. Most of my notes are a paragraph or two. I frequently refactor long ones into smaller ones. They are supposed to be free-standing building blocks, linked together.

What do you write? You could digest and re-explain what you have read. This kind of note will prove to you that you understand what you are reading. It is also a useful building block later if you reference the book.

A better note is driven by your own questions. I have many questions that I think about.

What does it mean for game-design to drive non-game app design (but, not gamification)?
What is the sound equivalent of visualizations?
What are programming books trying to do and is there a better medium to deliver that (is it games?, does it have sound?)
What is the right format for a programming tutorial? Is it something more vague?

I read books with these questions in mind, and sometimes I have ideas about them. If this happens, I stop reading and immediately write a couple of paragraphs in Obsidian.

After developing a note, I link it to as many relevant other notes as I can. Sometimes it’s clear that there are holes that need further thinking. I make and link to place-holder notes and tag them as needing development.

This continues like an infinite game: generate questions -> read -> write -> generate more questions -> read -> write.

When I am not reading, I sometimes just engage with the notes. I pick a starting point, follow links, remind myself of my past ideas. This will also generate notes, refactorings, questions. Most often it shows me that I have a topic that is ready for publication, so I add it to my schedule.

When it comes time to write for publication, it is much more like assembly and editing than writing, which was the goal of these notes.

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:

From a question I am using to drive my thinking. See: What are books for?
From the notes I am taking while reading. See Playing Non-programming Books
From writing posts. Yesterday I consciously listed the new topics I thought of while writing the post on topics.
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.
From solitude. See Use Deprivation to Make Space
From correspondence. If someone asks me an interesting question, my answer can often be generalized into a blog post.
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
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.
From my other works. I write about my apps, like in Sprint-o-Mat 2021.1 is Available
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).