Reframing Anxiety

Caveat: This works for me, and I am talking about it in the hope that it can help others. It’s not for everyone.

Over the course of my life I have become a lot better at managing anxiety. I once joked that all I had to do was realize that there’s no logical reason to feel anxious and then wait twenty-five years to see that I was right. That pretty much sums up how I’ve managed it.

Recently, though, I’ve come to see anxiety as as asset.

In my career, I would say that I generally get big things done by being on top of them. By worrying about them. I think about mitigations, like you’re supposed to, but even mitigating the mitigations. It’s probably a bit much, but it works for me. I think of this as being conscientious.

And that’s the reframing that’s helped. My feelings of anxiousness are a flip-side to conscientiousness. They come together. So, to the extent that I am happy about my approach to work, I have to accept that I will often feel unfounded anxiety.

I have come to be thankful for it. When I feel it coming on in an unwelcome way, I tell myself that this part of me is helpful at other times, and it can assuage it.

Write While True Episode 5: Audience and Message

Like many people I write to think. And, it helps. I set out with only inklings of an idea and by the time I am done, I usually have a coherent a complete thought. The writing contains it, but it doesn’t communicate it.

There’s a difference between writing to think and writing to communicate and I finally understand that.


Great Works of Software

I was thinking about great works of art attributed to a single person or small group. Things like The David, The 5th Symphony, or Pride and Prejudice. They are each on the short list of the greatest sculpture, classical composition, and novel.

What would the short list for software be? I put together a list, but of course, it is personal to my experience and biases. Here is my top 5 in roughly chronological order.

  • C and UNIX
  • The ARM instruction set
  • TeX
  • VisiCalc
  • Web browser/server

I edited down this list from of about twenty. Notable removals were the collected works of NASA and Pong.

There are some similarities I see that bind them and maybe help to define great works.

  1. They are in wide use over a long period of time. Visicalc is possibly a stretch here, but its influence and core functionality are in 123, Excel, Google Sheets, etc.
  2. They were made to make something else. C was made to make UNIX to make microcomputers. Sophie Wilson used ARM to make microprocessors and Acorn machines. TeX was made to make The Art of Computer Programming. Dan Bricklin made Visicalc as an MBA student to analyze business cases.
  3. They are mostly attributed to a single person or pair. That was true of many of the entries on my list, especially programming languages.
  4. They define languages. Again Visicalc is a stretch, but I do think of Excel as a Programming Language and Microsoft is releasing Power Fx, a language based on spreadsheets.

This combination is also what drove Alan Kay and his team to develop Smalltalk, Object-Oriented programming, GUIs, etc to try to make Dynabooks, so that presumably they could write content in that new medium.

That work led directly to Macs and is even more directly used in NeXT/Objective-C, which is what Tim Berners-Lee used to make the first browser. And if you use it to edit a Google Sheet on an iPad, it’s on a UNIX variant running on ARM, probably using algorithms documented in TAoCP.

Review: How to Make Feeling Good Your Priority

My running coach, Holly, published a book last month called How to Make Feeling Good a Priority. The book is part advice and part memoir (as she learns and applies her advice to herself and clients). I am lucky to be a client and have heard much of this from her, but having it all in one place helped me see how it wasn’t just for running.

Holly is a serial marathoner (27 so far) and I have done two under her coaching (and training for a third). We often talk about how to make adjustments during training and during a race to prioritize feeling good. This book is about doing that outside of running—a connection I didn’t make.

There are many lessons, but the one that stuck with me is turning “I can’t” into “How can I?”. I have written about habit triggers before—how you can control your own behavior, in part, by controlling the triggers that prompt that behavior. Anchoring a problem-solving mindset to “I can’t” comes up surprisingly often.

So much of the book is about shrinking the impact of bad feelings and increasing the effect of good ones. There are a lot of actionable tips and strategies.

I can’t say that I related to everything, but a lot of it resonated with me. Her chapter on the Law of Attraction (which always seemed like mysticism to me) resonated with my beliefs about tapping into randomness. I have come to see “attraction” as “focussing”/”awareness”—I don’t think you attracted the thing you wanted, but I do think you were more likely to notice it. And mentioning it to others helps them notice it for you too.

Knowing Holly, I see her personality on the page. She’s a positive person, always trying to find ways to solve the issues I bring up with her. Under her training, I have very rarely missed a workout and I haven’t had an injury—the rest takes care of itself. After reading her book, I do think that her concept of the “runner’s mindset” can be applied to the rest of my life too.

Deliberate Practice by Cloning

If you are trying to learn programming by implementing something new, you are conflating two skills and making it hard to do either of them well.

Yesterday, when I wrote about deliberate practice, I listed the two things you need to do to make practice effective

  1. Break it down so that you are practicing one thing and trying to make it automatic
  2. Set it up so that you have instant feedback on whether you are doing it right

As you work on your program, sometimes you are thinking about the syntax of the language and sometimes you are thinking about where to go next. It’s better if you can stay in one mode for a long period of time until that skill becomes automatic.

And, since there’s no set goal, it’s hard to know if you accomplished it. You have no objective feedback.

I remembered that in a recent Under the Radar episode, Marco Arment and David Smith talked about cloning apps as a learning exercise.

By cloning, we can concentrate on just coding without having to come up with the content too. Even this can be broken down further. Structure your practice sessions to concentrate on one aspect at a time. For example, just the UI.

You can think of the target app as an executable spec, which is easy to compare your work to. If you are learning UI programming you can screenshot both screens and flip back and forth between them to see how close you can match it. This establishes instant feedback.

I recently tried this exercise for the Breathe app on the Apple Watch, only working on the animation and wrote up a SwiftUI animation tutorial on App-o-Mat.

Deliberate Practice for Knowledge Workers

You have probably heard that 10,000 hours of practice leads to expertise, a notion popularized by Malcolm Gladwell. The details are more complex than this and are spelled out by the researcher behind this statement, Anders Ericsson, in Peak. If you want a good breakdown of it, Badass by Kathy Sierra is much a better distillation and practical guide to practice than Gladwell. (I gave a talk about Badass for iOS developers a few years ago—there’s a synopsis of the book there)

The main thing to know is that the nature of the practice matters. Ericsson calls it deliberate practice. I think if you’ve taken music lessons, you have probably been exposed to deliberate practice.

Skills are broken down and practiced individually until they become automatic and expert-level in isolation. Bigger skills are built up from automatic ones and you constantly repractice those skills to keep them automatic.

In athletics, deliberate practice is also the norm.

But, what about knowledge work? It’s certainly not the norm to talk about deliberate practice in knowledge work. You don’t see systematic practice very often.

One reason why is that a key element of deliberate practice is instantaneous feedback. If I throw a pitch, I can get the speed right away. I know how it felt. I know where it ended up in the strike zone. Modern technology can give me all kinds of data on it. When I play a guitar chord, I instantly know if I did it right (or at least, my teacher does).

That’s not easy to do for knowledge work.

I do think that, in programming, there’s a big opportunity to introduce a regimen of deliberate practice. There are tons of tutorials on individual tech blogs and Dev that show a market for them. We just need to remember what we need to train.

If you type in code that you read from a blog, you are practicing transcribing, not programming. Since programming is about disambiguation, that’s the skill to practice. Take a vague description of some goal and figure out how to program it. in my Swift Book Companion, that’s all I offer. There is no code to copy—only vague descriptions of code to write.

In Cal Newport’s Deep Thoughts podcast (see Ep. 32), practice is a common topic. He offers these two practice exercises for knowledge workers in general.

  1. Practice working uninterrupted on hard problems for at least 30 minutes and build that up to 1-2 hours. The practice is on not getting distracted and not stopping, not the actual work. You can easily get feedback on that part.
  2. Practice reading hard material uninterrupted. Again, the practice is on the focus.

A similar thing I do everyday for practice is morning pages. I talked about this in the first episode of my podcast. I am practicing “writing on demand”.

The two things to remember if you are designing practice for yourself.

  1. Break it down so that you are practicing one thing and trying to make it automatic
  2. Set it up so that you have instant feedback on whether you are doing it right

Once it’s automatic, it can be part of the next thing you practice.

Observing Experts

I started running in 2005 and did a marathon in 2009, but I ran sporadically for a few years after that. I had always done it pretty much on my own, and that limited my progress and sometimes led to injuries.

I started running seriously again in November 2018. The big change I made was getting a coach. I had just read Peak by Anders Ericsson, and learned that one way to become an expert was by watching experts. It wasn’t so much what the expert taught—Ericsson thinks that experts don’t always know why or how they do things. What seemed to be useful was just observing experts. (Incidentally, Ericsson is also the source of the 10,000 hours idea popularized by Malcolm Gladwell. Peak corrects a lot of the misconceptions about that).

My running coach, Holly, has run her whole life. She’s done 25+ marathons and several triathlons and also uses coaches herself. She often expresses her lessons as her observations of the elites she was run with (so I am observing an observer). Two years into it, I have gotten everything I wanted out of it and more.

So, I am trying to apply the success I have had by running with an expert to other aspects of my life.

I want to write a lot more, so I joined the Blogging for Devs pro community where I am surrounded by devs of all success levels that I can observe. Last year, I did the Akimbo Podcast Workshop which similarly exposes you to a cohort of podcasters—a mix of experts and other learners. I am learning a lot just by watching and emulating their behaviors.

The recurring behavior I observed from the successful bloggers and podcasters in these communities is to just publish. Almost everything else there is to learn only makes sense in the context published work.

So, my advice is to seek out experts doing the thing you want to be an expert in. And when you find one, I’d ask just to watch them work and then emulate their behaviors without necessarily understanding why at first. The book, Peak, has a lot to say about this, and if you are skeptical, watch this video about learning tennis by observing.

Mitigating the Mitigations

The first step to dealing with project risk is to list mitigations—the steps you will take to avoid or handle the risk. But, don’t stop at just listing them.

The very next step should be to think about whether those mitigations themselves have obstacles.

For example, let’s say you have a project with a large mechanical portion, which doesn’t require communication or coordination to implement. If this work can be done in parallel, then adding engineers mid-way (once the a core has been established) could speed up the project, but even at the start, you must

  • Get budget approval
  • Find a source of engineers (contractors/internal)
  • Structure the work so that at some point it can be done without coordination and in parallel.

Projects like converting a lot of code from Objective-C to Swift or from an unsupported version of a framework to the current one work well for this. Projects that require a lot of cross-developer coordination are famously made later by adding engineers.

Depending on the stakes, it might be right to ask engineers to temporarily put in more hours, or to schedule time-off earlier in the project if possible. These things are easier to do if you talk about them earlier and gauge the impact.

A third option would be to clear off all other work so that everyone can concentrate on the high-priority work at hand. In that case, those projects have risks that need to be communicated to the project managers so that they can list and mitigate them.

It would be frustrating for a project risk to manifest itself, to have identified that early, and to have come up with an effective mitigation, which is not possible to do because it needed prior planning.

Write While True Episode 4: Make a Schedule

The times that I’ve made the least progress on writing was when I was trying to do it on the side or as a hobby. This isn’t because of the relative amount of time I devoted to it. It was because I treated it as something I would try to fit in, and it never did. I could always find something else to do.



Assume the Failure

When planning a project, one thing I do is to imagine failure and work backwards. I am trying to figure out a theoretical root cause that I can mitigate. That’s a common project management technique.

But, if the seeming root cause is external, I keep going.

Instead of: The project slipped because …

Team X didn’t deliver part Y by MM-DD

which is hard to control, I assume responsibility for the failure:

We didn’t start the code using part Y until MM-DD

Then, these follow:

  • We didn’t build a mock of part Y so we could start our work before it was delivered
  • We didn’t ask for part Y to be put in staging before it was finished
  • We didn’t publish a full timeline showing the dependency on part Y to team X

And so on. These are all things I can do something about.