Introducing Routines in Day Blocks

Day Blocks was optimised for lightning fast entry of new blocks. But sometimes lightning isn’t fast enough.

For those lists of blocks that you know you’ll make over and over again, now you can save the list as a routine and immediately add a bunch of blocks to your list.

To save a routine, just make a list of blocks and tap the save icon.

GIF image-F02287FFB872-1.gif

To add a routine, simply open the Saved Routines menu and tap the one you want.

GIF image-24B81F3EAE28-1.gif

Since you’re adding routines and not replacing them, you can fill your time with the same routine over and over. Perfect for HIIT Workouts or Pomodoros.

GIF image-A6E3566701CE-1.gif

Introducing Day Blocks

I made another app, and I can almost guarantee that this one isn’t for you. But it’s definitely for me, and if the internet has taught me anything, it’s that I’m never the only one like me. So maybe it’s for you, too.

Day Blocks is about time budgeting

I like to get things done. I also like to watch the best moments from The Wire on YouTube for several hours in a row without realizing it. So I got in the habit of budgeting my time.

I start with the end

First, I set the end of my day, or my work block, or whatever, so I know exactly how much time I have available.

Then I make a list

This is pretty much a todo-list, except I guesstimate how much time I want to spend on each thing. At the top of the screen I can see how much time I have left to spend.

GIF image-9336DBC245E9-1.gif

Then I add some ‘flex time’

Days never go the way we expect. Having some buffer in the budget lets me stay on track overall without having to constantly rearrange the whole day.

GIF image-ABA5BD3F74E3-1.gif


Then I get started

In Day Blocks, I just tap the thing I want to be doing right then. When I want to stop doing that thing, I tap a different block. This let’s me jump around between things I want to do, but helps me see how much time I still want to spend on each thing.

This is a real budget, so the total time in the blocks must equal the time remaining in my session. So when I start a block, any budget or deficit in my “Unassigned time” gets added to the block I tapped.

My watch helps

On my watch, I have a complication showing me what I want to be doing, and how much time I have left, which can help me climb out of that YouTube rabbit hole, even if I’m just about to watch Omar testify again.*

iVBORw0KGgoAAAANSUhEUgAAAgAAAAN6CAYAAAD4tvHpAAAACXBIWXMAAAsTAAALEwEAmpwYAAFW-2.PNG


*Okay, I’ll finish watching this one, but then I’m getting right back to work.

Wow, drawing is super difficult: Mindsets for skill development

I had planned to write this week about how I use Why Choose, but realized that I needed to back up into how I approach developing skills generally. So here’s that!

Untitled_Artwork 4.jpg

Learning to drive

Those of us who know how to drive a car can probably do it while we’re having a conversation with somebody, or while we’re thinking about the things we’re going to do when we get home. The actions of driving a car are totally automatic for us, including checking mirrors, controlling acceleration and steering, and keeping awareness of the locations and speeds of all the cars around us. We’re masters at this, it’s incredible. And it hasn’t always been that way.

Chances are, learning to drive went something like this:

We sat down behind the wheel for the first time, totally confident that we can drive. We’ve seen people doing it every day, how hard can it be? Plus we’ve put in thousands of hours of Mario Kart. We’ve got this.

We don’t got this.

Immediately we find out that we’re terrible at driving. We can’t control our speed, the steering wheel doesn’t respond how we were expecting, there’s a huge list of things we need to be checking all the time and we can’t keep track of them. 

So we get instruction, we work on it, and gradually we get to a place where we can comfortably circle a parking lot. But it’s still so hard. Driving at this point takes every ounce of mental energy we have, and we still haven’t even gotten onto the road yet. 

But then we really start practicing. We put in the hours. Intentionally at first, begging to go drive so we can get better, then unintentionally, putting in hundreds, then thousands of hours of driving in the course of our daily grinds.

Then suddenly we realize it’s unconscious. We’ve got this for real. We’re listening to music, having conversations, all while maintaining full awareness of the cars around us and making thousands of tiny adjustments to speed and steering. 

Those steps are the template for learning nearly any skill. And remembering that it works, that growth is inevitable with consistent practice, has been the core of how I’ve approached maintaining a mindset for skill development. It’s really about paying attention as we move through four stages of competence:

Stage 1 - Unconscious Incompetence

“I think I can do that.”

Unconscious Incompetence in action

Unconscious Incompetence in action

Most of us are living just fine at this stage with most skills. We haven’t tried building a Large Hadron Collider or making a soufflé or writing a novel, so we have no idea just how incompetent we are at those things. Since we’re never tested, we can tell ourselves that we might be able to do them. The tougher version of this stage is when we’re at unconscious incompetence with something we do all the time and think that we’re good at. Maybe we’ve actually always cooked eggs terribly, or we’ve never listened to a recording of ourselves singing. In so many areas of our lives we never find out that we’re bad at stuff. There’s a comfort here, and we don’t always want to move on from that blissful ignorance.

But there are tons of activities and experiences that push us out of unconscious incompetence. From seeing someone perform at a level we thought was impossible, to failing in front of a co-worker or manager, to bombing at a comedy open-mic. Each one of these experiences is truly humbling, showing us a weakness in ourselves that we didn’t know existed. 

YAY!!! 

When we see this transition not as a failure, but as a normal stage in skill development it becomes something to be celebrated. Not from a shallow, “I should enjoy my failures because that’s what I keep hearing,” perspective, but from a deep understanding that getting out of unconscious incompetence is a critical step in the journey of skill development.

Stage 2 - Conscious Incompetence

“I know what quality looks like, and this isn’t it."

Conscious Incompetence in action

Conscious Incompetence in action

With a fixed mindset, conscious incompetence is where many people give up. The story we tell ourselves is, “I’m not good at this,” so we don’t try again. But with a growth mindset, there is no expectation that we should be good at stuff we’ve never practiced. Instead of feeling bad, we need to keep acknowledging that we’ve already made progress. In fact, we’ve already achieved one of the most difficult steps, which was moving out of unconscious incompetence. We’re doing great.

That said, working our way out of conscious incompetence can be tough. Usually during this transition we’re doing research, finding coaches, defining success criteria, and making attempts that don’t meet our own standards. There’s no formula for figuring out how long we’ll be here, but believing that we can learn is critical for getting through it. Moving quickly usually means finding methods of honest self-evaluation.

Stage 3 - Conscious Competence

“I can do it, but I still have to think really hard about it."

Continuing to represent for Conscious Incompetence

Continuing to represent for Conscious Incompetence

Conscious competence means that we’ve been learning and learning, and we think we can do the thing now. Identifying that we’re at this stage usually comes in one of two ways: (1) We’re meeting our performance criteria but it’s still so hard to do or (2) we’re performing well but we’re mostly thinking about ourselves while we’re doing it. That second one’s a big deal in something like improvised music, because we can’t listen to what everyone else is playing while we’re still thinking about how to play our own instruments. The same issue comes up in teaching or facilitating, where we might be competently executing our lesson plans, but we don’t have any additional mental space to think about how the people in the room are actually doing. We’ve got to get better at the skill if we want to perform in a meaningful way in those spaces.

The nice thing, though, is that now that we can do the thing, we can start practicing. 

Wait, what do you mean “start” practicing? What have I been doing?

One of the points of confusion when you’re developing a skill is what “practicing” means. There’s an old musician aphorism that, “A good musician practices until they get it right, a great musician practices until they can’t get it wrong,” but I found that it was actually more like, “Practicing starts after you can do it right.” The process of getting to conscious competence probably wasn’t practicing, it was learning, full of mistakes and bad habits and poor performance. Real practicing is executing correctly over and over and over, gradually needing less mental energy to perform the skill each time. 

In the language of Daniel Kahneman’s Thinking Fast and Slow, we’re moving a task from the processing-intensive System 2 part of our mind, where we’re almost entirely consumed with effort, into the automatic System 1, where we’re performing without really thinking about it at all. In my own language, It’s hard to stay bad at something you do every day.

Practice can take many forms, but the one most of us are familiar with is doing one job consistently over a long period of time, whether it’s writing performance evaluations, scheduling meetings, making coffee, or riding a bike to work. The "daily grind” is very often a process of practice, where we reinforce habits and make our tasks automatic. This is another place where there’s an opportunity to rethink our experiences. Rather than feeling “mindless” at work, we can celebrate our ability to move ever more complex tasks into our unconscious minds, freeing up space to think more deeply about something else.

The transition out of this stage is where the hours and the years come in. The move from conscious competence to unconscious competence can be tedious, but when we pay attention to it, it is one of the most satisfying human experiences there is. We’re gradually, through consistent effort, moving a skill from conscious effort to unconscious execution. We’re truly making the skill a part of ourselves.

Stage 4 - Unconscious Competence 

“I can do it and do other stuff.”

F&%* drawing

F&%* drawing

A good sign that we’re at unconscious competence is that we suddenly have “headroom”, or the ability to pay attention to other things beyond the thing that we’re doing. This is when we can have a conversation while we’re driving, or read whole sections of books while thinking about something else, or react to other actors while we’re on stage. My favorite example, though, came from a friend who worked as a bartender:

“After about three years of making drinks, I had this moment where I looked down and realized that I had three Spanish coffees on fire, I was in the middle of mixing two other drinks, and I wasn’t thinking about those things at all. Instead, I was tracking where every server was in the restaurant, I knew what everyone sitting at the bar needed, and I could respond to anything that was going wrong that night.”


He couldn’t do that on day 1, or even day 60. It took years to develop headroom. Hearing that story was one of the things that helped me move away from playing music and into the professional world. I realized that what I loved wasn’t playing drums, it was the feeling of moving skills into unconscious competence, and that if I paid attention, I could have that feeling while doing anything, from rollerblading, to programming, to designing strategies, to illustrating blog posts, to whatever comes next. 


Up next: Developing practice systems


Why Choose - Part 2: Not five minutes metaphorically

"You never called any question impossible", said Harry, "until you had taken an actual clock and thought it about it for five minutes by the motion of the minute hand. Not five minutes metaphorically, five minutes by a physical clock.”

- Harry Potter and the Methods of Rationality


Last week I wrote about why I built Why Choose, this week will be about how. Since this was my first programming project, much of this will be about learning to code, but the approach was similar to how I try to learn most things. Spoiler: I had help.


Resources (the easy part)

I learned the basic concepts of coding in the fun ways, by playing with Human Resource Machine and Swift Playgrounds on my iPad. These got me comfortable enough with concepts like Control Flow and Functions that I could start imagining how my app might run.

After that, I took the Programming for non-programmers course on Lynda.com, and Beginning Table Views on raywenderlich.com, which got me over the hurdle of “code that works in a playground” to “code that actually does something on a device”.

From there, I started developing more skills using codewars.com, and moving to searching for things using Google, Stack Overflow, and so many blogs. There’s a ton of easy to absorb information out there, but most of it is useless until you know what you need.

Sidebar on codewars.com: If you’ve never used this before and you’re at all interested in programming, go try it. It uses a brilliant mechanism of giving you a puzzle to solve, then showing you everyone else’s solutions once you’ve solved it, with the best solutions upvoted. I haven’t seen anything more effective for learning advanced functions, since you’re exposed to them right at the moment that you most understand what they’re for.

I also came to love a bunch of iOS-development-specific podcasts, especially Swift over Coffee, Swift by Sundell, The Swift Community Podcast, and Under the Radar.


Having a puzzle to solve

I didn’t say they were good sketches.

I didn’t say they were good sketches.

I had tried to learn coding a couple of times in the past, but it was always with a desire to learn how computers work, not a desire to make something, so it never really took. If you’re considering learning to code, I would strongly recommend having a project in mind when you start. It’ll be much easier to pick a language, ask for help, and keep moving when you’re inevitably frustrated.

For Why Choose, I started with some sketches of the interface. Most of the logic of how a user would move through the app was decidable before I had written a line of code, plus once I had the sketches I wanted to make them real.


Kanban boards

With my problem in hand, I started breaking it down into very small todo items.

This step was one of the toughest.

This step was one of the toughest.

Using a Kanban method, I prioritized those actions into a To Do list, which I re-arranged every day as priorities shifted. I moved one action at a time into a “Doing” board, then moved it into “Done” when it was completed.

With the complexity of any software, even something as simple as this project, I found that keeping focus on a single task was essential to keeping up momentum and working on the highest value tasks first. With very few exceptions, any time that I left this system I would bounce around aimlessly, or work on something easy but unnecessary.

Asking for help

When learning just about anything, it’s valuable to ask for help early and often. With programming specifically, there’s an amazing culture of sharing knowledge (mostly because everyone’s learning, too). If you know anyone who does any kind of programming, they’ll probably be happy to help if you ask (and if you’re already friends, they’ll probably be excited that they can talk about this stuff with you).

For me, once I had my basic problems laid out I would ask for help anytime that I was stuck for more than a few hours. Almost invariably the problem would be that there was a concept that I didn’t know the name for, and once I had that name I could find what I needed with standard searching. But the biggest leaps forward happened when I could meet in person with somebody. Seeing someone type revealed more about coding processes than any blog post or video I found (part of the trouble is that most of those tutorials show someone doing everything right the first time, so you never see someone doing even simple debugging, like using print statements to test where their code is breaking).

Sidebar on asking for help: It’s sometimes hard to admit that you don’t know something basic to an expert. To fight this tendency in myself, I often think back to a clinic I saw by renowned drum instructor Ed Soph, who taught some of the greatest drummers alive at the University of North Texas. He said something to the effect of, “when you see one of the greats doing something inhuman, remind yourself that at some point they didn’t know which end of the sticks to hold”.

Asking for more help

When I’m excited about something, I get hooked on talking to people about it, and it turns out that people who don’t write code don’t love talking about writing code, so I needed to make more friends.

First, I started attending programming events in Portland, especially making time for the Mob Programming workshop through AgilePDX. This also introduced me to the bigger AgilePDX world, including their fantastic Slack.

Then, taking the example of the hosts of The Swift Community Podcast, I wanted to find or start a Learn Swift community in Portland. I reached out to the hosts of PDX Cocoaheads to see about organizing Swift specific events where I could get to know other people who were figuring out how to make apps. Again, folks were eager to help, and these happy hour events have gone better than I could have dreamed. They’ve introduced me to fantastic developers, and given everyone who attends a window into how other people are approaching their own work.

Testing with real people

Version 0. I can’t even begin to tell you how proud of this I was.

Version 0. I can’t even begin to tell you how proud of this I was.

As soon as I had anything to show people on this project I did. Friends got (probably way too many) texts of screenshots and short videos of functionality. This step accomplished two big things: I got rapid feedback on things like appearance and user experience while the project was still very malleable and I created some accountability for myself, since I wanted to get to the next thing I could show them as quickly as possible.

Once I had a version of the app that didn’t break as soon as anybody looked at it wrong, I started a public beta with Apple’s TestFlight. This was where development really accelerated, because I got meaningful feedback on how the app felt in people’s hands and what they wanted to use it for. The idea of the “mute” feature came straight out of hearing how people were using the app in their daily life, and seeing their annoyances with my first interface inspired a full redesign that consolidated three screens into one.

Plus, SOFTWARE I HAD WRITTEN WAS RUNNING ON OTHER PEOPLE’S PHONES!!!

Thinking for five minutes

Drawing an icon was my favorite way to procrastinate.

Drawing an icon was my favorite way to procrastinate.

People who have been writing code for years or decades will probably laugh at this understatement, but there are obstacles everywhere in programming. From planning out your approaches, to trying to different methods, to figuring out the mistakes you made that are breaking everything, to fighting bugs in your development environment, you’re just constantly running into walls that you have to figure out how to get over.

Besides asking for help, the most productive habit I developed was noting that I was stuck, then getting out a clock and really thinking about the problem for five full minutes before giving up or moving on to something else. This was my way of fighting substitution bias, or the habit of replacing a difficult question with one that's easier to answer. If you’ve never done a focusing exercise like this, you might be surprised to learn how quickly your mind wants to look away from things that are challenging, or how solvable many seemingly unsolvable problems are when you really think about them for five non-metaphorical minutes.


Paying it forward

This blog is one of the ways I’ve been trying to pay back all the help I’ve received over the last few months in getting my first app published. If you’d like to learn more, or want some help getting started yourself, feel free to reach out!

Up next: How I use Why Choose in my own life

Why Choose - Part 1: 82.8 days

iTunes said that I had 82.8 days of music. That’s 1,987 hours. If I listened to an hour a day, it would take me more than five years just to hear everything once.

Screen Shot 2019-10-11 at 11.32.57 AM.png

This was crippling.

The year was 2006, I had decided to become a professional musician, and I knew that I needed to study great recordings to make progress. iPods and music sharing had opened up a world of possibility that no musician had ever experienced before. We could all study everywhere we went, and study more broadly than ever.

So how could I possibly choose what to listen to? I was wasting a ton of time deciding, then I would always feel like I was listening to the wrong thing, and I knew that I was disproportionately spending time with Aaron Goldberg, Aaron Parks, and Ahmad Jamal.

Thankfully, there was the shuffle button. Shuffle eased my anxiety by removing the burden of choice. I could just leave the decision making to fate and keep on listening.

And this worked like a charm. Since I always knew what to do next, I wasted no time in decision making and spent way more time listening.

But I still had to make choices throughout the rest of my day.

Where should we go for lunch?

What should we make for dinner?

What book should I read?

What TV show should I watch?

What podcast should I listen to?

What exercises should I do in my workout?

What song should I practice next?

Which skatepark should I go to?

Each one of these decisions met the same criteria as music listening.

I know I want to do something in this category.

There are a lot of choices available.

I’m not passionate about any one particular choice at the moment.

I could easily waste a lot of time deciding.

So I started experimenting with putting more of my life on shuffle. I would keep a numbered list of options, then use a random number generator to pick which thing to do next. Just like with music, I found that this accomplished a bunch of things at once.

• I had less anxiety about the things I wasn’t doing.

• I spent much less time deciding what to do.

• I could make sure I was getting both repetition and variety.

And it turned out that I wasn’t alone in this anxiety. I found the work of Barry Schwartz, as well as behavioral economists like Dan Ariely and Daniel Kahneman, and saw that, paradoxically, we all want variety, but choice often makes us less happy.

Yet many folks I speak to about this have only heard the “choice often makes us less happy” part, so they end up removing both choice and variety (see Steve Jobs’s turtlenecks). The systems that I’ve been developing remove choice, but still deliver a variety of experiences.

It was this thinking that led me to build Why Choose. A dead simple app that lets you store options, then put those options on shuffle when it comes time to make a decision. I hope it helps you as much as it has helped me. And if you do use it, I would love to hear about it.

iVBORw0KGgoAAAANSUhEUgAABS0AAAo4CAYAAAC8JoK+AAABgmlDQ1BzUkdCIElFQzYxOTY2LTIu MQAAKJF1kbtLA0EQhz8TJb5-3.png
iVBORw0KGgoAAAANSUhEUgAABS0AAAo4CAYAAAC8JoK+AAABgmlDQ1BzUkdCIElFQzYxOTY2LTIu MQAAKJF1kbtLA0EQhz8TJb5-4.png

Up next: How I built it