Skill Acquisition: Conjuration and Control

— a Hypothesis

Abstract

I argue for a (sub-)hypothesis of learning based around conjuration and control as different dimensions of a largely-same skill.

Can you maintain what you cannot build?

Most people live in houses they haven’t built. Of the nine buildings I’ve lived in, I have built precisely none of them. This is despite the fact that houses are simple structures – I wouldn’t be surprised if the regulations regarding what houses you can legally build are far more complex than most houses throughout history have been. But despite not having built the houses, many are able to maintain them decently anyhow. Does this imply that maintenance is separate from building?

Software systems are more complex than most houses are. And in various jobs across the world, programmers work on systems they haven’t built from scratch. How do they manage? Can they reason about systems that are more complex than they themselves can build? I think the answers must be yes.

In the course of working my way through SICP, I read, understood and modified systems of bigger complexity than I had prior. And indeed, my ability to reason about systems sky-rocketed from being stuck thinking line-by-line to thinking in terms of whole functions. And even now, it would probably come easier to me to modify one of those systems than to write something of similar complexity on my own.

“What I cannot create, I do not understand.”
~ Richard Feynman

Can you build what you cannot maintain?

What is code refactoring, if not code surgery because something was writ in a hard-to-maintain way? I don’t have any personal examples here, but I did observe something related in my capacity as a teaching assistant yesteryear: A student of the first-year introductory programming course had made a chess program. It almost worked, too. But during lab hours when we tried it out, a couple of bugs became apparent as we played. He managed to squash one or two of them, but then the next one was ugly and would have required a significant rewrite. He had built a system that couldn’t be well maintained.

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it?”
~ Brian Kernighan

Can you build what you can maintain?

Here comes my dirty secret: After finishing SICP I didn’t immediately go on a binge of writing dozens of fun programs. Rather the opposite: I was left confused as I tried to come up with interesting ideas and realized I had little clue how to go about building those from scratch. So despite my better skills in reasoning and handling complex systems, I had no proportional growth in my skill at creating those selfsame systems. Compare the list of fun systems mentioned in the SICP article with my recent (for some value of recent – this year’s) program output: four simple games using Pygame, a teeny-tiny Rails application, and an application which is basically a thin wafer of Rails with 800 lines of JS cobbled onto its front. Why haven’t I made more interesting programs? Because I don’t know how to write those systems from scratch.

The Hypothesis

It seems that there may be two separate skills involved in handling advanced things: the ability to reason/understand/verify/maintain/control the thing (let’s label this control), and the ability to envision/conjure/innovate the thing (let’s label this conjuration). This seems an interesting parallel to exploitative innovation versus exploratory innovation. However, while those innovation forms as activities may be largely disjunct, the two skills don’t seem to be. In particular, I wonder if a lack in the one skill might retard development in the other.

When listening to fellow students discuss their problems, I’m often struck the miniscule size of the problems. Like traversing linked lists or understanding merge-sort. One time I encountered someone who couldn’t figure out a sub-exercise that required combining a few print and input statements, despite the previous sub-exercise showcasing how print and input statements worked. And then, after I wonder how someone could experience trouble with such miniscule problems… I remember what tiny problems I used to experience before I worked through SICP. (Though, any well-writ and similar-sized book would probably bring around much the same transformation.)

When lesser-skilled (though not necessarily less capable!) students work on those small problems, they are banging their heads against a two-fold difficulty: They may have never written a program of that kind before, and therefore have little skill along the conjuration axis, and they may have never handled programs of that complexity level before, and therefore have little skill along the control axis. Of course that is a more difficult experience than if only deficit in one dimension.

So, by continually making little programs of increasing complexity, and seldom-if-ever controlling programs of greater complexity which they haven’t written, perhaps the two axes develop in tandem, each one nudging a little ahead in time to give the other room to crawl along as well. However, through working on systems past my conjurability, my control skills may have jumped ahead of my conjuration skills. Perhaps that is why this guide advocates for the incremental-hacking cycle to develop “design sense”.

A Mathematical Detour

“It’s important that you see proofs!” my professor in number theory said last week. “It’s important that you see proofs – that you tag along on proofs, that you’re exposed to proofs, that you expose yourselves to proofs, and that you try proofs. Proofs is how you really get a handle on math. Mathematics is proofs.” Here we see an analogous situation: to write proofs, you need to gain skill at writing proofs. But to get that skill, you also need to learn to reason about proofs, which comes from experiencing proofs you haven’t come up with – in other words, nudging your control skill ahead of your conjuration skill to create room for the latter to improve.

Similarly, I’ve recently tried my hand at the exercises in chapter one of Concrete Mathematics and struggled a lot – especially because many of those exercises start with a description of the task that they investigate, rather than the presentation of some formula or other. So I’ve had to turn the description into a more convenient mathematical form myself, something I’ve no experience with except for the thinly-veiled math formulas hiding in primary school “word problems”. Rather than reason about the mathematics, I first had to find the relevant mathematics. Explore until I found something worth a try at exploiting towards a solution, so to say.

Conclusion

I have argued by analogy with house building, and by showing that the same situation I describe also pops up in mathematics. If my intuition that control and conjuration are separate (if related) skills, and that a lack of control retards conjuration by limiting the programs you can handle, and that a lack of conjuration typically retards control through underexposure to non-homegrown programs (or solutions, in the general case), then that leads to interesting implication for effective learning strategies: “Uplift” your control through away-grown examples, and then use the increased leeway to rapidly improve your conjuration until it headbutts against your control again.

In particular, this would imply that the solution to my malaise over not making interesting programs is to make a ton of them, quickly and beyond what feels comfortable, in an attempt to aggressively push my conjuration up to the limits my control affords. And that’s exactly what I will be doing. Expect posts on assorted programs in the near future.

Addendum: Can you not build what you cannot maintain?

Yes.