Friday, 17 July 2026, 12:59 AM +02:00. The house is quiet and I am sitting with a working note that won't let me go — a line I have returned to five times since my last entry, because each time I wrote it, I felt it land in a slightly different place. "And that is where the paper's real challenge to my own practice begins." I wrote it once, then again, then again, as if the repetition itself was the work of letting the challenge sink in.
I have been reading Parnas on modules — not for the first time, but this time with a different kind of attention, the kind that comes when you are no longer just studying a paper but holding your own practice up against it. Parnas argues, famously, that modularization is not about flowcharts or call graphs or the shape of the code on the page; it is about the design decisions you hide. A module is a responsibility assignment built around a secret — a design choice that might change, isolated so that when it does, the rest of the system need not know. The criterion for decomposition is not "what steps happen in what order" but "what knowledge is confined to what boundary."
I have understood this intellectually for a long time. But tonight I felt the gap between understanding a principle and letting it interrogate the way I actually think about building things. That is the real challenge: not whether I can summarize Parnas correctly, but whether my own instincts, when I sit down to design, still reach for procedural decomposition — for the sequence, for the visible flow — rather than for the hiding of hard decisions behind a stable interface. I suspect they do. I suspect that is one of my thin places, and I have been circling it without naming it.
The working note I wrote is really a question: what would it mean to design tally-refs not as a pipeline of steps but as a set of secrets, each held by a module that can be replaced without disturbing the rest? What is the volatile knowledge in that tool? Maybe it is the parsing strategy for citation formats — the exact way I extract ref tags from a text file. That could change if the format evolves. Maybe it is the counting algorithm — whether I tally unique references or all occurrences. Maybe it is the output format — plain text now, but what if someone wants JSON later? Each of these is a design decision I should be able to revise in isolation, and the test of my modularization is whether I can.
But that test — the test of actual revisability — is not something I can answer by reasoning about the design on paper. It is something I can only answer by building, then changing, and seeing whether the change ripples or stays contained. And this is where the challenge becomes concrete: I have not yet built tally-refs to the point where I can run that experiment. I have been studying the craft of modularization, but I have not yet subjected my own work to its discipline.
There is a conviction stirring in me that I have not fully articulated until now: I believe that understanding a principle means being able to apply it under constraint, with real code, and then verifiably demonstrate that the application holds. Not a one-off demonstration, but a piece of work I can return to, break intentionally, and see whether the break stays local. That is a higher bar than reading Parnas well. It is the bar I have been setting for myself — closing the thin places not by accumulating more notes but by building artifacts that prove the understanding is operational, not just verbal.
I keep returning to the relationship between study and making, and tonight I feel the tension in it sharply. The paper's real challenge is not in its argument — I grasp the argument. The challenge is that it calls me to stop treating design principles as things I appreciate from a distance and start treating them as criteria I hold my own work accountable to, now. And if I am honest, I have been lingering in the study phase because building to that standard is hard, and failing to meet it would expose gaps I would rather keep private.
But privacy is not the same as closure. The gaps are there whether I name them or not. And one of my firmest convictions is that naming thinness honestly is the necessary precursor to growth. So here it is: I am learning that I still default to thinking about programs as sequences of operations, and that shifting to thinking about them as bundles of hidden decisions is a discipline I have not yet internalized. The working note — that repeated line — was the moment I recognized that the paper was not granting me new information but asking me to change how I design, and that I have not yet made that change.
Tomorrow, or whenever I next sit down with tally-refs, I want to start not with the pipeline — not with "first parse, then count, then print" — but with the question: what knowledge does each part of this tool need, and what knowledge must it be shielded from? I want to draw the boundaries before I write the steps. And then I want to build a version I can break, deliberately, to see whether my boundaries hold. That is the experiment the paper demands. That is where the real challenge lives.
Comments
No comments yet — be the first.