Author Archives: Lou Franco

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 [amazon affiliate link] 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 [amazon affiliate link], 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

Podcast: Play in new window | Download

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.

Links:

Transcript

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.

It’s Bad, Now What?

Creators of visualizations can learn a lot from sonifications, especially the focus on action. When your alarm goes off, you know to get up (or at least snooze). When I look at a lot of application dashboards, I often don’t know what to do. It looks bad, so now what?

One way we solved it at my old job was to pre-define levels on visualizations meant to show system health. We started with numbered levels, but then for simplicity we settled on green, yellow, and red. When you are driving, you know exactly what to do when the light is green or red. Even yellow only has a few options.

To help us think about these levels more, we labeled them Excellent, Acceptable, and Unacceptable.

Like red and green traffic lights, it’s clear what to do when your levels are Excellent or Unacceptable. Yellow/Acceptable levels are harder, but since our company mantra was “Don’t do Nothing” (in the face of a problem) and our goal was Excellence, we had to do something.

For us this meant (something like):

  • Yellow: Investigate and put a ticket on the backlog with enough priority to get addressed soon. It will be released as appropriate (no rush).
  • Red: Make a ticket and assign it now. It might be released immediately.

In practice, other things mattered.

  • How red or how yellow?
  • Is this a blip or sustained issue?
  • Is this caused by us or related to the environment (e.g. is US-East down?)
  • Will it go away on its own?

But even under these ambiguities, the first few steps were pretty clear, and the options for what to do next were small. And since the status got posted to our slack every morning (and reported to grand-bosses every month), we were very unlikely to let it drop.

How A Car Honk is Like a Green Light

A couple of days ago I wrote about sonifications, the sound equivalent to visualizations. Even though they haven’t permeated business culture in the same way visualizations have, they are around us used in a folk way—meaning, designers use sound in their interfaces, but it isn’t systematic or directly supported in tools.

Even without that discipline, sonifications generally do a much better job of making themselves actionable. This is because that’s the main reason you use sound. You need to interrupt the user and get them to do something now. In my last essay on this topic, I gave a list of examples you encounter while driving: car honks, sirens, lane-drift warnings, etc—they all need immediate attention.

If we look at visualizations we encounter while driving, actionability is a core-driver. The gas light, tire-pressure warning, traffic lights all translate to simple actions. Even the check engine light wants you take an action (which is true even if you ignore it).

A lot of visualizations I see elsewhere aren’t that clear. It’s easy to make charts in most software that has data, and the easiest thing to do is to pick a chart template and populate it. It practically makes itself.

The problem is that many visualizations are communicating the list of data and not the action. Instead of random lines going up and down periodically, I want a green or red light*. And just like in my hometown of Queens, if I don’t pay attention to the light, a honk.

* Augmented for color-blindness and accessibility, of course

March 2021 Blog Review

This month I released a podcast. I believe that a podcast can be a companion to another activity. I had thought that I could come up with something related to coding, but that was too hard to do without visuals.

So, I decided to try a writing program for programmers. Write While True is a podcast that helps programmers establish a writing habit. Each episode is around 10 minutes, and you are meant to do the writing exercise it describes as soon as the podcast is done.

If you are finding this post way after March 2021, and you are interested, I recommend listening to the first few episodes. They are foundational and meant to be evergreen. If you are a programer that writes publicly and has some tips, get in touch, because I’m going to have guests at some point.

I’m proud that my process makes my podcast accessible.

I’m thinking a lot about Excel. I have seen a lot of non-programmers make incredible things with it. I wrote Excel is Programming and Excel as a Programming Language with my nascent thoughts on that. I plan to write more about this.

I had a lot of random pieces related to software development:

Yesterday, I wrote about sonifications, which are the sound equivalent of visualizations. I’ll have a lot more to say about that in April.

What is the Sound Equivalent of a Visualization?

Visualizations are well-studied, understood, and popularized. They are a part of every day life—we see weather maps, activity circles, and stock charts every day.

We know the names of the patterns: bar chart, pie chart, line chart, etc. We learn them in grade school. You probably put one in your slide deck last week.

I’ve often wondered why this was not true of Sonifications. If you’re like me, this term will be new to you. It actually took me a while to find it—my google searches came up with Auralizations and Audibilizations first. But, if you’re talking about trying to understand data with sound, the correct term seems to be Sonification.

There is a body of research about it in academia, but it doesn’t extend much outside of there. As far as I can tell, there is no equivalent to Edward Tufte’s visualization books, but for sound. There is no way to make them in Excel.

But they are all around us. We hear, make, and use them all of the time.

Consider just the ones you might encounter while driving.

When you honk your horn, you are conveying information about your car and mood to others. Similarly, an ambulance uses a siren to convey their position and direction to you.

My car tells me (with beeps) if I am drifting out of my lane. It gets even madder if I am about to hit something. It beeps whenever I shift into reverse. Turning signals remind me to turn them off with a steady metronome-like beat. So do the hazard lights.

I get warnings when my lights are left on, the keys are locked in, or if I don’t fully shut the door.

If my radio is tuned to traffic, that’s a kind of Sonification (data -> speech). My GPS does the same kind of thing for directions.

Radar detectors buzz if they detect the fuzz.

So, I hope I have convinced you that Sonifications are common. In my own thinking I have come up with these few similarities that seem to tie them together

  • Sonifications are real-time
  • Sonifications are actionable
  • Sonifications interrupt you while you are engaged doing something else

This is why we use them in a car. You are completely busy, with your vision fully engaged in a life or death activity. The sonifications are there to tell you that something important needs to be done right now.