Bicycle is an open-source framework that I’ve been working on with a couple of friends. One way to think about it is to compare it to a spreadsheet.

In a spreadsheet, we are building a directed, acyclical graph of cells, where cells are nodes and each formula in the cell defines the edges and direction.

If A1=B1+C1, then both B1 and C1 point to A1. The graph cannot contain cycles, so, in a spreadsheet, you can’t then say that B1=A1-C1 even though that is true, because it would cause a cycle in the graph.

Bicycle defines a data-structure and algorithm that gives meaning to a graph of formulas that does contain cycles where dependencies between nodes can be bidirectional (hence, Bicycle).

In Bicycle, you can define both of the formulas above and also complete the network with A1=C1-B1. In more complex networks, an individual field may have several different formulas, using different dependencies that can set its value.

Once you define a network, you can seed it with values. These are kept outside of the formula data-structure in a kind of priority queue. The highest priority values are seeded first, and each value is only accepted into the network if the network can remain consistent.

Meaning, I could define A1 as 2, B1 as 3, but if I then say C1 is 7, I have created an inconsistency. When you attach this to a UI, you would want the oldest value to be discarded.

We are also providing some help building SwiftUI based UIs with it. The network is meant to be hosted in an @ObservableObject and we provide a TextField Initializer that will bind to fields in it. Here’s a demo of a network that can convert between yards, feet, and inches.

Try to imagine replicating that in Excel. You’d have to pick one of the fields to be user-provided and put formulas in the other two. In Bicycle, you can provide as many formulas as you want (as long as they are consistent with each other) and seed-values are used as long as they are consistent.

It’s in very early stages and the API will probably change a lot, but if you want to take a look, see SwiftBicycle in GitHub.

We can apply principles of visual design to designing audio. In visual design, we can manipulate “visual variables” to get different communication effects. The variables are are:

• Size
• Value/Brightness
• Hue/Color
• Orientation/Rotation
• Texture
• Shape
• Position

Continuing along with sonifications, here are some analogous audio variables:

• Frequency / pitch
• Beat
• Amplitude / volume
• Envelope / Waveform: e.g. a beep vs. a buzz
• Source Location

We have different ways of perceiving visual variables. For example, for some of them, we have an order—size goes from small to big, but shapes are not ordered.

We also have different ideas about how many variations we can tell apart on the same canvas. We can distinguish between a huge number of shapes, but probably only a few levels of brightness.

These kinds of perception apply to audio variables as well. Waveform seems to be related to shape in that there can be many types (instruments), but they are not really ordered.

Amplitude is similarly related to size, pitch is like brightness, and source location is like position.

Using what we know about combining and contrasting visual variables is probably a good start for doing the same with audio.

A few days ago a proposed a short-list of great software works. A couple of them are associated with the great works of software writing, and so I started to think about what the top five pieces of great software writing were.

This was a lot harder for me to narrow down, so in the end, I decided to make it personal. What had influenced me the most? This means I have to leave off The Art of Computer Programming, which is undoubtedly a great work, because I haven’t read it.

These works were chosen because they shape how I think about programming anything. They are language and framework independent. I chose three that are more about process and three that were more technical.

This is in the order I read the books or papers.

Process

• Peopleware [amazon affiliate link] by DeMarco and Lister
• eXtreme Programming [amazon affiliate link] by Beck and Andres
• Joel on Software blog

Technical/Coding

• Design Patterns [amazon affiliate link] by Gamma, et al (The gang of four)
• A behavioral notion of subtyping (Liskov Substitutability) by Liskov and Wing
• Purely functional data structures by Chris Okasaki

For me, these are works that still affect how I program today. My main lessons:

From Peopleware, that the biggest factors in programming productivity were access to quiet and long blocks of time, and that this explained correlations of productivity within a workplace.

From eXtreme Programming, unit testing, continuous integration, pair programming, small releases, and refactoring which are all part of how I have worked from the day I finished reading it.

From Joel on Software, don’t rewrite software, UI design for programmers, tons of software business. Also, one of the main reasons I applied to (and worked for) Trello.

From Design Patterns, that it’s useful to look for common solutions and give them a good name and description (not the specific patterns, although I obviously had learned from them).

From A behavioral notion of subtyping, I learned about how to progress software. I think about substitutability for almost every line of code I write inside of deployed software. I wrote about this in my blog post on Substitutable Versioning.

From Purely functional data structures, I learned that functional programming was technically possible. I had read about FP (and even wrote about it) in college (~1990), but at the time, it wasn’t conceivable to me that this could work—granted, I was just a student. After clojure came out, and introduced me to Okasaki’s work, I was convinced that FP had a place in my toolset. I wrote about that revelation back in 2008 in my 20 days of clojure series, where I tried to learn clojure quickly because I was helping to host a Rich Hickey talk.

Some notable things that I read but didn’t include are Decline and Fall of the American Programmer (this was interesting but turned out to be mostly wrong), Writing Solid Code, and Code Complete (great, but read it too late in my career to be influential).

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

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.

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 [amazon affiliate link]. If you want a good breakdown of it, Badass [amazon affiliate link] 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.

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.

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.