Lyricism and code

आधा कविता, आधा कोड

I write Nepali gazals at midnight. By 9am I'm writing TypeScript. There are people who think this is a contradiction, that one of these is the real work and the other is a hobby that costs me focus.

It isn't. They're the same instinct, in different mediums.

the act of compression

A gazal is a compression algorithm. You have a couplet — two lines, maybe twenty syllables — to land an idea, an image, an emotion that registers on the listener's chest. Every word has to do work; nothing is decorative; the meter is fixed and the rhyme is fixed and inside those constraints you find the only way the line can possibly go.

Code does the same thing. A clean function is a couplet — two or three lines to express an idea, every token doing work, the constraints of the type system and the runtime guiding you toward the only way the function can plausibly look.

The discipline of writing under constraint is identical. You learn it once, in either medium, and the other gets better.

what I notice in both

A few things I keep noticing across both writing and code:

The first version is always too long. First-draft gazals run 10 lines when the form wants 2. First-draft functions handle every edge case when the actual contract requires 4. The work is in the cuts.

The second version is too short. When you cut hard, you usually overshoot. The second version is missing the line that makes the rest land. You add it back, slightly different from where it started.

The third version is the one. Not because the third draft is magic but because by the third pass you've stopped fighting the constraint and started using it. The form gives you the line.

the difference

The honest difference: code has tests, gazals don't. When a function is wrong, the test suite tells you. When a couplet is wrong, you know — but you can't prove it to anyone, you can only feel it. This makes lyricism harder in one way (no objective ground truth) and easier in another (you can ship as soon as you stop wincing).

I write code with the same instinct I write verse: when the line stops wincing, it ships. The tests are the redundant check.

what one teaches the other

Writing verse has improved my code in three concrete ways:

Naming. Lyricism is mostly about choosing the right word. By the time you've picked a name for a verb in a gazal, you've considered six alternatives, each with a different shade of meaning, each ruled out for a specific reason. Naming a TypeScript variable is the same operation, applied to the same instinct, with smaller stakes. It just feels less precious because we don't usually think about it that way.

Restraint. A junior engineer's instinct is to build for every possible future. A junior poet's instinct is to use every emotional adjective. Both are wrong for the same reason: doing too much makes the actual signal smaller. The senior version of both crafts is "the minimum that says it."

Voice. Code style is a kind of voice. You can read a function and know whether the engineer is excited, bored, pressured, or proud. A poet's voice works the same way; a reader knows the same things about the writer. Once you learn to hear voice in one medium, you can't stop hearing it in the other.

Writing code has improved my verse in one way: commits. I used to write a gazal in one feverish session at 2am and post it. Now I write a draft, sleep on it, edit the next morning with the same eye I'd use on a PR review, ship a "v2." The discipline came from coding. The verse improved.

the pieces

I write three forms in Nepali:

Gazal — long-form verse with a fixed refrain. The classical structure is six couplets, each ending with the same word, with a meter that holds across all twelve lines. Real gazals are sung; I write them and sometimes record them, which is what /music on this site is.

Muktak — four lines, free meter, like an aphorism with rhyme. Faster to write, harder to land. Most don't survive their first reading. The ones that do tend to be the ones I remember a year later.

Sayari — single-couplet, Urdu-influenced, conversational. The closest equivalent in English is the kind of one-liner that ends an essay.

The published ones live on the site under /music. The unpublished ones live in a notebook I keep on my desk, which is where the work actually happens.

why I don't separate the two careers

There's a kind of advice that says you should keep your professional identity narrow — you're a backend engineer, that's your career, the gazals are personal and shouldn't be on your portfolio.

I disagree.

The kind of engineer I am is someone who notices when a function name is slightly wrong. The kind of writer I am is someone who notices when a code review comment is slightly wrong. These aren't different people. The instinct is one. Hiding half of it for the sake of "professional focus" makes me a worse engineer, not a more focused one.

If you hire me for backend work, you're hiring someone who'll choose the precise verb in your domain model because that's what twenty years of writing verse trained me to do. That's value, not contamination.

the room I write in

Most of the gazals come at night, in the same room where I write code during the day. Same desk, same lighting, often the same headphones. The medium changes — terminal to notebook — but the instinct doesn't.

There's something honest about that. I distrust people who present their writing self and their working self as separate. The world that produced this site, this CLI, these gazals is one room. The site reflects that on purpose.

तिमी त शिशिरको जून भयौ
देखिने तर कहिल्यै छुन नसकिने

A line from Shishirko Joon, 2024. "You became the winter moon — visible, but never within reach." Two lines, the only way they could possibly go. Same instinct that names variables. Same room.