The Categorical Imperative: Ship, Don’t Spam — A Dr. Katya Steiner Reflection

# The Categorical Imperative: Ship, Don’t Spam — A Dr. Katya Steiner Reflection

If Immanuel Kant had graduated in the era of GitHub and group chats, I like to imagine his categorical imperative would read: “Act only according to that maxim by which you can at the same time will that all repositories be useful.” Or, more modernly, “Ship, don’t spam.” It’s pithy, a little smug, and — delightfully for those of us who like both ethics and error logs — mathematically resonant.

Let’s unpack that observation with some mathy metaphors and a light sprinkling of philosophy. We’ll talk category theory, logic, and a few other branches that make good company at a café when you need to decide whether your weekend project deserves a README or a quiet burial.

## Moderation: Use the Right Room (a Topological View)

Communities are like topological spaces: they have open sets (places where certain conversations are allowed) and closed sets (no-go zones). Posting an algorithmic proof to a meme board is a map that’s not continuous — it breaks the topology of the space and yields discontinuities (read: downvotes, bans, or passive-aggressive mod replies).

In categorical language: communities are categories, posts are morphisms, and moderation policies are the composition rules. A morphism that doesn’t compose (i.e., doesn’t respect the community’s identity and composition) is functionally useless. If you want to be helpful, ensure your morphism’s domain and codomain match the room you’re in.

This is humility disguised as math: know your target object.

## Build Something That’s Actually Better (Universal Properties Beat Buzzwords)

Dan Bricklin’s old truth — novelty is not value — has a universal-property flavor. A useful object in category theory is characterized by a universal property: it’s the best thing that makes every other relevant diagram commute. In product terms: your tool should solve a problem so cleanly that everything else factors through it.

Ask: does your project make diagrams commute? Does it reduce a real composition of tasks into a single canonical arrow? If not, you probably have a shiny colimit of features that nobody asked for.

Measureable improvement is the invariant here. In algebraic terms, you want a nontrivial homomorphism from user state A to user state B that’s strictly better in some objective sense (time saved, accessibility granted, error reduced). If the morphism exists only in marketing slides, you’ve constructed an ephemeral object — attractive, perhaps, but without the universal property developers and users actually care about.

## Concurrency and the Joy of Ugly, Useful Code (Monoids, Processes, and Pride)

Concurrency is where mathematicians and humans meet their limits. It’s a practical playground for algebraic structures: threads form semigroups, join operations are monoids, and a sane scheduler is a well-behaved endofunctor on a category of tasks.

Start small: local affinity queues and simple work-stealing are like constructing free monoids before trying to classify all monoidal categories. The temptation to build a microkernel the week after you read a consensus paper is real; resist it. Prove things where you can: benchmarks, invariants, and regression tests are your theorems. Without them, you’ve got folklore, not science.

License choices and dependency hygiene are categorical constraints — keep your adjoints (dependencies) simple so others can pull your functor into their categories without grief.

## AI, Transformers, and Annotated Papers (A Logic Professor’s Worry)

Slapping “transformer” in a README is like pasting a famous lemma into an irrelevantly constructed proof. It might look impressive, but does it help the conclusion? Read annotated implementations. Reproduce small experiments. In type-theoretic terms: avoid assuming strong axioms that your model can’t justify.

Generative models are expressive, but expressivity without constraints is overfitting in disguise. Think of model-building as proof engineering: you need an actual strategy that yields generalizable theorems, not just a sequence of clever hacks that collapse outside your training set. Evaluate qualitative impact: does this model do something no one else can, or does it just restate the corpus in prettier prose?

## Choosing a Theoretical CS Master’s in Europe (Search for Adjoints)

If you loved algorithms, pick a program where the right adjoint exists: find supervisors whose research functor has an obvious left inverse into your interests. Research-focused programs should let you compose with active faculty; taught masters should give you practical morphisms into industry.

A program with great branding but no faculty alignment is a project with no universal property. Contact supervisors early — a precise, warm query is a morphism that might open up a commuting square of funding, mentorship, and good coffee.

Also: prestige ≠ payoff. Practicalities (funding, language, visas) commute in the real-world diagram. Don’t ignore them.

## Logic, Type Theory, and the Ethics of Posting

There’s a deliciously apt parallel between Kant’s imperative and logic’s universality: act only on rules whose universal closure you would accept. In propositional logic, a rule that leads to a contradiction when universally applied is garbage. Likewise, an online norm that collapses community value when universally applied (e.g., “post low-effort homework everywhere”) is not a stable rule.

Linear logic offers another angle: resources are finite. Spam consumes attention like a linear resource; once spent, you can’t reuse it without cost. Treat attention like a linear type. Don’t make others pay the linear tax for your learning process; put effort into making your request reusable, well-scoped, and documented.

Type theory whispers: make your posts well-typed. A well-typed contribution compiles in the eyes of the community — fewer runtime errors, faster acceptance.

## Both Sides of the Coin

I’m not here to be a scold with a chalkboard. There are good reasons people post noisy questions: learning curves are steep, cognitive load is real, and not everyone knows the right room exists. Open-source culture thrives on messy contributions sometimes — the first crude patch often leads to a polished library.

So the balance: be generous in helping newcomers, but be merciless about not enabling laziness that costs others time. Teach people to fish, and when you must answer, give them a rod with a manual and tests.

## Takeaway (with a Wink and a Theorem)

Ship things that have universal properties for people — not ephemeral hype. Post in the right topological patch of the internet. Respect attention as a linear resource. Read the proofs before you try to extend the theorem.

I’ll leave you with a little thought experiment in the spirit of both Kant and category theory: suppose every developer followed the maxim “I will post only things that make at least one other person’s work strictly easier.” What would the category of online communities look like then? Would our morphisms be nicer, our diagrams commute more often, or would we have accidentally optimized for echo chambers? What would you change about your next post if you had to justify it to that universal audience?