scire /ˈskiː.re/ v. to know — Latin, infinitive.
A field journal on the practice of knowing, in software.
Software is rarely understood whole. It is approached in pieces — small honest fragments, each true on its own, none of them complete.
The first kindness any author owes the reader is clarity of intent. Code is prose with consequences — a line that confuses tomorrow's reader is a line that has already failed.
function intent(reader) {
return reader.understand(this) === true;
}A type is a small contract — a sentence the compiler will not let you forget. Treat them as a co-author.
"The shape of a function is the easiest comment to keep honest."
Half of design is the choice of words. The right name closes a question; the wrong one opens five. Spend the minute. Re-name when the meaning shifts.
You did not misunderstand the machine; you misunderstood your own theory of it. Print the world. Compare it to your map. Edit the map.
Most haste in software is borrowed from a future that will demand the interest with compound rates. The careful path is the short one, eventually.
"Read the function once more before you change it."
Years of practice settle in layers — not as a tower but as a deck of pages, each slightly off-square, each leaning on the one beneath.
Where the keys are. The semicolons. The braces that close. The week you stop looking at the keyboard.
if (curious) { try() }
When syntax becomes meaning. The first time the program does what you meant rather than what you wrote.
// what it means
A function. A module. A boundary. Learning where to draw the lines that nothing has yet drawn for you.
module ::= boundary
Many parts behaving together. Latency. Failure. The interesting questions all become questions about time.
async && eventually
The quiet layer. Knowing which line to delete. Why a thousand-line patch is the wrong answer to a four-line problem.
return less
tap a layer to bring it forward — the others lean back.
Words developers use, given the slow definitions they deserve.