Fluency before ingenuity

Introduction

I recently hit a slump that resulted in me taking two or three weeks off from mathematics. I encountered several problems with which I struggled. I felt that, given some difficult-to-solve problem, the core difficulty I faced was not being able to determine whether I was missing a tool required to solve that problem, or whether I needed to use my existing tools in some novel way.

This diagnosis is probably at least somewhat accurate, but I think it’s a surface-level view of a deeper problem. After a great deal of thought, I have come to believe that the more robust explanation is that I was burning significant time, energy, and morale during the creative parts of the problem-solving process, to the point that it was seriously hindering my ability to enjoy mathematics.

Fortunately, I believe I have found a solution to my woes—a solution that comes in the form of a paradigm shift that has changed how I think about creativity and learning.

Two thorns

Let me share two of the simpler problems that vexed me.

Prove that $\sqrt{3}$ is irrational.

For the sake of contradiction, we assume that $\sqrt{3}$ is rational. This means there exist integers $a$ and $b$ with $b \neq 0$ such that $\frac{a}{b} = \sqrt{3}$ and the fraction $\frac{a}{b}$ is in lowest terms. Squaring both sides of the equation gives $\frac{a^2}{b^2} = 3$, hence $a^{2} = 3b^{2}$. This is where I got jammed up. There wasn’t much I could think to do with this equation.

I was missing Euclid’s lemma, a beautiful statement about primes and divisibility. It states that if $p$ is prime and $p \mid ab$, then $p \mid a$ or $p \mid b$. The corollary for our problem is $p \mid a^{n} \implies p \mid a$.

That’s not something I could have intuited within any reasonable period of time. It was simply a tool I did not own. The rest of the proof isn’t important to our discussion, so let’s move on to the next problem.

Prove the following or find a counterexample. If $A_{1} \supseteq A_{2} \supseteq A_{3} \supseteq A_{4} \supseteq \dots$ are all sets containing an infinite number of elements, then the intersection $\bigcap_{n = 1}^{\infty}A_{n}$ is infinite as well.

This statement turns out to be false, so we’ll find a counterexample. Perhaps the simplest way to proceed is to let $A_{1} = \{1, 2, 3, \dots \}$, $A_{2} = \{2, 3, 4, \dots \}$, $A_{3} = \{3, 4, 5, \dots \}$, and so on. More generally, $A_{n} = \{n, n + 1, n + 2, \dots \}$. Then the intersection of all of these sets is empty, as there is no element that belongs to all of them.

While this construction feels painfully obvious in hindsight, it was not obvious to me at the time. I was exploring more complex subsets, but the natural numbers turned out to be all I needed. And when iteration is the ask, natural numbers should be one of the first levers pulled—a lesson I will never forget!

Proving that $\sqrt{3}$ is irrational required a tool not in my toolkit. Constructing the counterexample required me to use a tool already in my possession.

I wondered how to know which of those two buckets any given problem might fall into. That felt like the blocking step.

A red herring

However, the idea that I needed to be able to categorize problems in this way was, at best, a symptom of the underlying problem. At worst, it was a red herring.

The fact is that I’m still a beginner! My intuition hasn’t been trained well enough to readily distinguish between the two.

Even if it were somehow possible for me to categorize problems in this way, I expected of myself bottomless, useful, and efficient creativity. Not only is this expectation unrealistic for a beginner, it’s unproductive.

There is very much a sweet spot for creative struggle. Too little struggle, and one learns little from the solution. Too much struggle, and one is burning time that could be used to fuel growth.

What is a learner to do?

The role of creativity in software engineering

I was talking to a fellow engineer at work, sharing how I feel creativity fits into engineering. I started my explanation with, “We put creativity on a pedestal, but up to a surprisingly high level of seniority, 80% of this job can be done without much creativity.”

In practice, good engineering often constrains or eliminates the need for creativity. That’s part of what makes it good. The initial work of laying down a system’s patterns is creative. Then when more business requirements come down the pipe—provided that the design of the software is good—the process of adding to that system should be fairly mechanical.

In fact, if you are forced into a position of being creative within an already-established system, almost invariably, you will be met with healthy resistance, usually from that system’s authors. I have joked that “novel” means “Whether or not I am correct, I am going to have to fight for this idea.” Sometimes the litigation is worth it and sometimes it is not. But the point remains: good engineering by its very nature attempts to keep the need for creativity capped.

I continued my explanation, “I believe that creativity in the hands of the early practitioner is expensive and rarely useful. In the hands of the experienced practitioner, it is less expensive and often profoundly impactful.”

Still, creativity is a skill that must be trained. Moreover, as one climbs the engineering ladder, the expectation increasingly shifts toward productive creativity, commonly under tight constraints.

It’s for all of these reasons that my recommendation to early-to-mid level engineers is to practice bounded creativity. When confronted with a tricky problem, spend some amount of time—usually not long—thinking of a solution. Then take your solution to an engineer whose judgment you trust. If the solution is accepted, great! Perhaps it’s time to widen the bounds. If the solution is rejected, great! It’s one of thousands of repetitions that must occur to hone one’s design sense.

Instead of prematurely focusing too much on the creativity lever, I recommend that growing engineers focus on mechanical fluency. That’s the 80%.

Defining mechanical fluency

In software engineering, mechanical fluency is made up of many skills, which are themselves made up of sub-skills, and so on. Unsurprisingly, there is more to this list than can be enumerated here. However, I will include a few examples for illustration.

• Understanding problems
  • Grokking the business value of solving a problem.
  • Quickly identifying and understanding the code you must change.
• Coding
  • Familiarity with linguistic and company idioms.
  • Comfort with a framework’s abstractions.
  • General knowledge of “the details.”
  • Increasingly, comfort with AI tooling.
• Coordination
  • Ensuring work is parallelized.
  • Sequencing work to deliver business value sooner.
• Communication
  • Communicating in a way that conveys competence and ownership and inspires confidence.
  • Leveraging appropriate tools to provide visibility of progress to stakeholders.
  • Surfacing blockers and sharp edges.
  • Being proactive—answering questions before they are asked.
• Moving work
  • Being thoughtful about inviting feedback—people will stick their fists in your porridge if you invite them.
  • Knowing when feedback is worth addressing immediately and when it can wait.
  • Knowing when and how to say no.
  • Leveraging people with influence to help move work outside your sphere of control.

My definition of mechanical fluency in mathematics is necessarily more naive and a moving target, but it’s still a useful starting point. Here’s how I would define it today.

• Proof writing
  • Unpacking the logical form of a problem is low-effort, if not automatic.
  • Justifications are fleshed out.
  • Arguments are direct—no unnecessary details create indirection.
  • Constructions are sensible and clean.
  • Using mathematical language idiomatically.
• Breadth
  • Familiarity with ideas from algebra, real analysis, number theory, and topology.
  • A vast catalog of solved problems from which to pull inspiration.
• Thinking
  • An ability to hold and use progressively higher-level abstractions without needing to dive back into base layers.
  • Moving fluidly between informal and rigorous reasoning.
• Problem solving
  • Identifying the “hinges” of a problem.
  • Knowing when to struggle versus knowing when to move on.

Mechanical fluency precedes creativity

Perhaps the most important point is that mechanical fluency precedes creativity. It is not some prerequisite punishment for the uninitiated.

Creative thinking without constraints is useless. Without constraints, the search space for a problem is effectively unbounded. Mechanical fluency provides those constraints.

To illustrate, consider my earlier attempt to prove that $\sqrt{3}$ is irrational. No reasonable amount of creativity from me would’ve produced Euclid’s lemma, or any other tool that may have stood in its stead. Because that fact wasn’t in my toolkit, the search space would have been far too broad for me to comb through. Distinguishing “missing a tool” from “missing a use of a tool” isn’t the skill that solves the problem. The answer is to have seen enough dots to be able to make connections.

As for the set intersection problem, I tried complicated subsets because I was too overwhelmed by the mechanics of the problem to see the straightforward solution. Someone fluent in the material wouldn’t spend much time searching the space. Iteration points at the natural numbers as one of the first levers to pull, and the counterexample’s construction follows soon after. Constraints provide an idea of where to look first.

When one’s mental faculties are no longer occupied with the 80%, the mind frees up resources to be able to wrestle with higher-level and more difficult problems without getting stuck in the weeds.

Thinking does not occur in a vacuum. Mechanical fluency is the harness that makes it possible for creative thinking to actually mean something.

In practice

What we’ve discussed will alter the way I pursue mathematics. Perhaps the biggest difference is that the standard to which I hold myself will no longer be ingenuity. It will be fluency. The mandate will no longer be “just figure it out.”

More tangibly, I plan to allow myself to struggle with problems without angst. And once I’ve hit a point where the struggle no longer feels productive, I’ll either seek an answer or file the problem away for later.

My focus will shift more toward breadth. When I run into problems that direct me toward unfamiliar concepts, I won’t consider a long detour to be a distraction; I’ll think of it as part of the journey.

I’ll work to turn concepts with which I am familiar into concepts with which I am fluent.

And I’ll continue to work to make sure that my proofs are correct, idiomatic, and clean.

I’ll circle back after a while to let you know if it’s working.