DEV Community

Cover image for The Skill I Am Not Sure I Still Have
Remus Lazar
Remus Lazar

Posted on Originally published at Medium

The Skill I Am Not Sure I Still Have

When I was about fourteen I spent my days in a computer club in Romania. Anyone could walk in. CP/M was the new thing, most of us were on 8-bit machines, Sinclair Spectrums and their local clones, and we were there because that was where the computers were.

One of the older members could read machine code. Not assembly, not the mnemonics — the hex. He would look at a dump and tell you what it did. When the club got a new printer we studied the specification and wrote a driver for it, he in Z80 machine code, straight into a hex editor. It worked the first time.

I had not thought about him in thirty years. Lately I think about him a lot, because I have a thought I keep having, usually late in the evening, and it is not a comfortable one. I think I am losing my coding skills.

I want to be precise about which ones, because the obvious version of this worry is wrong. My judgment is not decaying. It is getting more exercise than at any point in my career: what to build, whether the design holds, whether a test protects anything, what can be deleted. That part of me is in better shape than it has ever been.

It is the hands I am worried about.

What I have not done lately

I have not written a controller from an empty file since the spring. I have not spent an evening with a difficult bug and nothing but a debugger and my own head. I have not typed out a migration, a test suite, a client for somebody else's API.

These were things I was good at. Not remarkable, but good, in the way you are good at something you have done several thousand times. And I am fairly sure they decay. Not the knowledge of how, which stays. The fluency: the speed, the sense of what the next line is before you have thought about it, the feel for when something is wrong before you can say why.

In the twelve months of my own history I examined for Two Agents, Not Five, the share of my commits carrying an AI co-author line went from zero in May to over eighty percent in August. That number is a floor, not a measurement, because it only counts the commits where the tool signed its name. The real figure is higher.

Whatever I am, I am no longer the person who types the code.

Why should I keep doing it?

Then the counter-question, which I cannot answer cleanly.

Why should I keep doing something the machine does better? I do not hand-optimise assembly. I do not write my own JSON parser or my own HTTP stack. I have never once regretted not being able to do those things at speed, and I would think it strange if a colleague insisted on keeping the skill up.

Every generation of developers has given up a layer of craft that the previous generation thought was the job. Memory management. Build scripts. Hand-written SQL for every query. In almost every case the trade was worth making, and the people who resisted it were not preserving something important. They were just slower.

Nobody reads hex any more. Nobody needs to. The skill that made him the most impressive person in that room has left the profession entirely, and the profession is fine.

Maybe this is simply that, one layer up. Maybe writing a controller by hand belongs on the list next to manual memory management, a skill it is fine to have mostly forgotten.

Not the mnemonics. The hex.

Why this time might be different

Here is the version of the worry I cannot dismiss.

The thing I would be trading away is the thing I use to judge the output.

I can review AI-written code well precisely because I spent years writing it myself, badly and then better. When I read a generated change and something feels off, that feeling is not analysis. It is pattern recognition, built from thousands of hours of having been the one who wrote it. I know what a wrong abstraction looks like because I have written wrong abstractions and lived with them.

But I have been thinking about what he was actually doing at that club, and it was not typing. He was reading the machine's output directly and reasoning about what it would do, with no mnemonics and no abstraction in between. That is not the skill that became obsolete. That is the skill I use every day now, one layer up, when I open the diff instead of trusting the summary.

The layer he read is gone. The act of reading beneath the layer is the whole job.

But in The Test Data I Did Not Write, even a careful reading of the diff would not have been enough. I also had to question the assumptions against real data. Both kinds of review draw on experience I built while doing the work myself.

So if the skill that makes me a good reviewer is the skill that only writing keeps alive, then letting it go is not giving up a layer of craft. It is giving up the thing that makes the new arrangement safe.

I do not know how fast it decays. Judgment stays sharp for a while after the hands stop. Nobody I have asked knows how long a while is.

What I am trying

I have no rule for this one, and I am suspicious of anyone who says they do. But I have two experiments running.

The first is to write something by hand every so often. Not as a productivity measure, since it is not one, but as a calibration. A small feature, start to finish, no agent. Partly to keep the fluency. Mostly to notice whether the fluency is still there, which I would not otherwise find out until it mattered.

The second is to watch my own reviews. If I start approving changes faster, if the number of things I rename or delete starts falling, if I find myself accepting the summary more often than opening the diff, that is the signal. Not that the code got better. That I stopped being able to tell.

The question I am left with

It is possible that in five years this worry will read like someone at that club insisting everyone should still be able to read hex. It is possible it will read like the last generation that could check the machine's work, wondering out loud whether anyone would replace them.

I do not know which. I know that the second version is the one I would rather be wrong about, and that being wrong about it requires doing something now, while I still have the skill to notice.

If you have an answer, I would like to hear it. This is the one question in this series I could not close.


Originally published on Medium.

Top comments (0)