This is an exciting week for Mac and iOS developers - it’s Apple’s WWDC (Worldwide Developers Conference).
For the next few days, Apple will release a ton of content telling developers how to adopt new coding practices to support asynchronous coding and embrace some of the new features they’re rolling out to consumers in September.
The idea of asynchronous coding is that you need to decide how to handle multiple tasks.
Imagine you are a manager and you have people helping you.
Some tasks must be performed sequentially. You can delegate them but the person performing the second task needs the results of the first task before they begin. Suppose the first person is determining where we will order lunch for our next team meeting and the second person is tasked with taking the orders.
The second person needs to wait until the first person tells them where before they set off to determine what.
That seems inefficient - maybe the second person can do other things and just come back to this ordering task when the first person finishes determining the where.
Another possibility is that there are tasks that don’t depend on each other.
The first person may be tasked with choosing where we’re going to order the food and the second person may be tasked with ordering the team building t-shirts.
Neither person needs to wait on the other, but the person in charge of the budget who is going to use the remaining money on commemorative mugs may need to wait on both.
Another possibility is that there’s only one person reporting to the manager who has to do all of the tasks.
This person is very good at what they do but easily distracted - we only want to give them one task at a time.
Although our examples are over-simplified, they are the crux at what developers will be struggling to understand in the context of programming in the Swift programming language.
In programming many things can go wrong with asynchronous code.
If you want to work efficiently, then you want your calculations to run in the background somewhere. Often we forget to tell the code to come back to the foreground to display the results. This means that our worker can be done with the task but our screen never updates so we have no idea.
Another thing that can go wrong is we get our dependencies wrong and two things are each waiting on the other to complete and so nothing ends up happening.
In short, it turns out that this sort of thing is hard in programming.
It also turns out that it’s hard in real life.
Last year I shipped two books and ended the year doing a lot of training online. The training continued into this year but at the beginning of March it came to an end.
I don’t tend to panic. Something else comes up.
But I went into a kind of funk where I wasn’t getting much done.
Not the good kind of “make my funk the P. Funk”, but the sitting scrolling aimlessly on my phone kind.
I recently said this to a friend who said, “yeah but you drafted another book, shipped an app, wrote the weekly newsletter…”
“Sure,” I cut them off, “but I spent a lot of time watching tv and looking at my phone or computer not doing much of anything.”
I’d be working on something and I’d pick up my phone and start looking at twitter - perhaps you can see the problem already.
I was checking twitter on the main thread - the same thread that I’d been using to do my work.
So the work stopped and I looked at twitter.
Oh, someone is talking about this article that sounds interesting I’ll follow the link and check it out.
Still on the main thread.
The next thing I knew, Annabelle (my aging puppy) is pushing my hand to get my attention. It’s her dinner time.
So I feed her but while I’m up I start to make my dinner.
Now it’s hours since I left whatever I was working on and I’m too tired to focus anymore so I turn on the tv and catch up with email.
That’s what a funk does - it keeps you from managing your tasks in an efficient way.
As I learn about asynchronous programming in Swift, I’m considering what it will mean in my own life.
I don’t think this funk is serious - but it is something I need to snap out of.
Essay from Dim Sum Thinking Newsletter 63. Read the rest of the Newsletter or subscribe