What coding by hand was actually teaching you

(Japanese translation follows / 日本語は以下に続きます)

Something I hear a lot these days is a riff on the same theme: it's harder to learn how to be a good engineer now. And it makes a kind of sense. If you never actually write the code anymore, how are you supposed to get good at it? It pokes at one of those fundamental beliefs we carry — practice makes perfect, you learn by doing. Stop practicing a thing and you'll never master it.

It's true, because it's a truism. But what tends to drop out of that conversation is the follow-up: good at what, exactly?

About twenty years ago now, I used to start my mornings with katas — little code exercises where you'd pick up and finish some trivial task. "In PHP, use TDD to write a function that adds two numbers." "Build a scorer for a hotdog-eating competition." (I genuinely can't remember the exact ones anymore, but you get the shape of it.) The idea was a task small enough that you wouldn't lose a day to it, but involved enough to warm up the muscles you'd lean on for the rest of it.

The intention was good. But after a while I noticed that what I was actually exercising wasn't my programming. It was my editor-driving.

I get the same feeling from the "you have to code to be a good coder" argument. What we're really defending isn't practice of the thing that makes someone a good engineer. It's practice at driving the vehicle they happen to use to do it. Put it plainly: spend all day studying how Scala works and you'll get very quick at writing Scala, but that is not the same as being an excellent engineer. Knowing a language doesn't map cleanly onto knowing a domain.

The counterargument is, of course: well, how else are you going to learn? Fair enough, but in the same breath: how did we do it before? This isn't some problem the adoption of coding agents invented. I've worked with plenty of programmers from the pre-AI days who did nothing but hand-write code and still knew next to nothing.

The real point is that we've misidentified what was carrying the learning. Coding by hand was a fantastic teacher, but not because typing out lines magically levels up everything else. It was because working at a low level forced you to go and find out how things worked. That extra layer of research — the part you had to do just to get the thing to compile — was where you stumbled into the adjacent skills that actually moved you forward as an engineer.

Even then, there was always a visible gap between the coders who researched only when they were cornered into it and the ones who went digging well past whatever the compiler was demanding of them.

Now, if you hand a coding agent the job of writing those lines, most of that forced research quietly evaporates. If you aren't actively looking for things to learn, getting better becomes a lot harder.

The places we go to improve are shifting, too. There was a time when simply knowing how C# and LINQ worked, really understanding the concepts underneath, made you faster and better at the job. The concepts still carry their weight. But the returns on knowing the exact syntax are thinning out. I'm not going to tell you that you don't need to know your language; I argued the opposite in an earlier post. But I also can't pretend that, beyond a certain point, it matters as much as it used to.

So no, I don't buy that we can no longer learn how to be good engineers. But without a doubt the way we go about it has to change. The opportunities to improve that used to come built into the work, the research you couldn't avoid, are being absorbed by the agents. Which means the gap is about to widen: between the engineers who know what they're doing, and the ones who vibe it until it breaks.

最近よく耳にするのが、同じ趣旨の話です。今は優れたエンジニアになるための学び方が難しくなった、というものです。たしかに一理あります。自分でコードを書かなくなったのなら、どうやって上達すればいいのか、と。これは私たちが抱く根本的な信念のひとつ——習うより慣れろ、実践してこそ身につく——を突いてきます。何かを練習しなければ、決して上達することはない、というわけです。

それは本当のことです。なぜなら、ただの自明の理だからです。ただ、この話でいつも抜け落ちてしまうのが、その次の問いです。いったい何が得意になりたいのか、ということです。

もう二十年ほど前になりますが、私は朝の時間をコードカタから始めていました。ちょっとした課題を取り上げて完成させる、小さな練習問題です。「PHPで、TDDを使って2つの数を足す関数を書く」「ホットドッグ早食い大会の採点プログラムを作る」といったものです。（正直なところ、具体的な課題はもう思い出せませんが、雰囲気は伝わると思います。）一日を費やすほどではないけれど、その日ずっと使うことになる筋肉をほぐすには十分な、そんな手頃な課題というのが狙いでした。

意図そのものは良いものでした。ですが、しばらく続けるうちに気づいたのです。私が実際に鍛えていたのは、プログラミングではありませんでした。エディタを操る腕でした。

「優れたコーダーになるにはコードを書かなければならない」という主張からも、同じ感触を受けます。私たちが本当に守ろうとしているのは、優れたエンジニアをつくる当のものの練習ではありません。エンジニアリングをするために使う乗り物を、運転する練習なのです。平たく言えば、Scalaの仕組みを一日中勉強すれば、Scalaはすぐにすらすら書けるようになるでしょう。けれども、それは優れたエンジニアであることとは別物です。言語を知っていることが、そのままドメインを知っていることに結びつくわけではありません。

もちろん、こんな反論が返ってきます。では、ほかにどうやって学べというのか、と。もっともです。ですが、同じ口で問い返したいのです。これまではどうやってきたのか、と。これはコーディングエージェントの普及が生み出した問題ではありません。AI以前の時代にも、ただひたすら手でコードを書くだけで、それでもほとんど何も分かっていないプログラマーに、私は何人も出会ってきました。

肝心なのは、私たちが「学びを運んでいたもの」を取り違えていた、という点です。手書きのコーディングは素晴らしい教師でした。ですがそれは、コードを打つこと自体がほかのすべてを魔法のように底上げするからではありません。低いレイヤーで作業せざるを得なかったからこそ、物事の仕組みを否応なく調べに行かされたからです。その追加の調べもの——ただ動かすためだけに必要だった部分——こそが、エンジニアとして本当に前進させてくれる周辺スキルに、偶然たどり着く場所だったのです。

それでも、追い込まれたときだけ調べる人と、コンパイラに要求された範囲をはるかに越えて掘り下げていく人との間には、いつだってはっきりとした差がありました。

そして今、その行を書く仕事をコーディングエージェントに任せれば、その否応のない調べものの多くは、静かに消えてなくなります。自分から進んで学ぶものを探しにいかなければ、上達はぐっと難しくなるのです。

私たちが上達のために向かう場所も、変わりつつあります。かつては、C#やLINQの仕組みをただ知っていること——その下にある概念を本当に理解していること——が、仕事を速く、うまくこなす力になった時代がありました。概念は今も重みを持ち続けています。ですが、正確な構文を知っていることの見返りは、だんだん薄くなってきています。言語を知る必要などない、と言うつもりはありません。以前の投稿では、むしろ逆のことを主張しました。それでも、ある一線を越えれば、かつてほど重要ではなくなっている、という事実も否定はできません。

ですから、私たちはもう優れたエンジニアになる学び方を失った、とは思いません。ただ、その学び方そのものは間違いなく変わらざるを得ません。かつて仕事のなかに組み込まれていた上達の機会——避けようのなかった調べもの——は、エージェントに吸い取られつつあります。つまり、差はこれから広がっていくということです。自分が何をしているのか分かっているエンジニアと、なんとなくの勢いで動かして、壊れて初めて気づくような人たちとの間で。