The Gospel of Evan: a not true dao of development

2021-11-18

These are a few meditations– parables, precepts– I’m collecting– snipping, stealing– to capture the vague & provisional learnings I’ve had working in the software industry. It’s a “gospel” because, well, everyone is either preaching or selling you snake-oil– lean into it, write your own gospel, what’s the worst that could happen?

Have a mission.
Respect & learn from your ancestors.
Aim for utmost minimalism at your public interface. Aim for minimalism in everything, especially this one.
Learn to design both bottom-up and top-down, and when which is more appropriate.
Stateless > Stateful, but at EOD someone has to own that state. Who/what it is matters. Related to Tesler’s law.
Algorithms > Micro-optimizations, but this is easy to forget because…
… It’s hard to visualize the whole scope of the algorithm or system. Use (& build your own!) tools which increase observability.
Keep digging until you find the small kernel which makes the entire thing work. Wind and time may have scattered it far & wide.
DRY, yes, but it’s ok to repeat yourself a couple times until you’re sure it’s the same. When you have three examples of the same thing, try extracting the same part, & pay attention to naming in this extraction. Do the names fit? Why/why not? Just because it has the same shape doesn’t mean it has the same semantics.
Usually there is an underlying logic to even the worst code. Understanding that veiled intent may be the key to not repeating its mistakes. There may not be tho! Look for naming consistency & authorial drift. If you’re pretty sure there isn’t, rewrite that crap ASAP.
Getting shot in the foot is the best way to learn someone is holding a foot-gun. Maintenance is a great way to learn. Prefer shooting yourself to other people, if possible.
HN & StackOverflow are not great resources for learning about systems. Work on a variety of different code bases & types of systems.
Learn a Lisp. There are other ways to get the same thing, but in one fell stroke you can:

a. Get a better understanding of code-as-data-as-code

b. Learn how wonderful true in-editor REPL, bottom-up development is

c. Be able to read a ton of foundational CS papers in their source language

It’s also very rare to see long functions in Lisp code — this is the kindof minimalism I’m striving for.
Naming is, of course, the most important thing. But why is it important? So the reader and writer— you and your reviewer, you and future you— can be as sure as possible you are sharing the right metaphors. It’s always dialectic.
Software is communal. Introducing a new paradigm involves education, and you should consider trade-offs inherent in whether the new paradigm will sufficiently supplant the old. Consistency and coherence have to be balanced against the need to have the newest & shiniest.
Programming is an aesthetic act. You are an extravagantly well-paid artist. Have fun with it! Make it beautiful. Or don’t! It’s your art.
Don’t be an asshole. It’s hard not to get attached to ones’ art. So far, tho, only humans maintain code.
We’re always choosing the metaphors we live by, & our career is writing executable metaphors. We need a more and better variety of them, ideally compatible ones, a whole society of functional metaphors. We employ the industrial ones too often— builder, adaptor, factory. We need more pre/post-industrial ones— they’re more powerful. The company is named “Oracle” for a reason.
Try to maximize optionality. (h/t Heinz von Foerster, Nassim Taleb)
Code the shortest path thru the hardest problem first.