eykd on Nostr: I've been thinking a lot about code as communication as I've worked with a small team ...

I've been thinking a lot about code as communication as I've worked with a small team on upgrading a very challenging codebase.

I, like most people, used to think of programming as telling the computer what to do. If it works, great! Ship it!

The "It works!" mentality will get you pretty far in your career. Telling computers what to do is hard, and in demand.

But if you stick around in one place long enough to have to live with "working" code, it stops working so well. You have to make changes. Sometimes you forget what you were thinking when you wrote that function. Some days you're simply not as clever as others.

An old aphorism among engineers goes something like this: "Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live." To which some anonymous wit on the venerable c2 wiki once replied, "I usually maintain my own code, so the as-if is true."

The insight of Domain-Driven Design is that a domain model is a special-case extension of a technical language. Conversation *about* a model is a working prototype *of* that model.

Code implementing a model is a message to the future about that model.

Enlightened engineers write code to instruct future maintainers in stewarding the model, and only incidentally to tell a computer what to do.

#ddd #programming #grownostr