I have a soft spot for poetry.
That is what poems are for - sentimental musings and meditative cogitation. These are perennial features of humanity, and well worth the time.
As we find ourselves in interesting times, the gap between reality and the narrative of progress is growing, and applied human intelligence (aka “technology”) is “disrupting” (aka changing without full context) many things. Where does this leave the poet?
You’ve likely heard some variant of the morality story where someone justifies their (commercial) worth as mostly a matter of knowledge, and not just labor.
A typical version is as follows - a handyperson is hired to fix a failing heater. They spend a few minutes investigating and listening to it from a variety of locations, and then tap a particular spot with a hammer and fix it.
They bill the owner of the heater $300 - the owner objects, saying that it was a simple tap of the hammer. So the worker remakes the invoice:
As with most concise-yet-resonant stories, it belies a more complex issue.
Conventional wisdom in modern software development generally endorses the use of an ORM.
“Any project that doesn’t use an ORM will end up with a poorly implemented partial ORM.”
Most developers are familiar with the dreaded SQL injection attack - an ORM provides solid protection, while exposing a comfortable OOP interface for application developers:
from blog.models import Blog, Entry entry = Entry.objects.get(pk=1) cheese_blog = Blog.objects.get(name="Cheddar Talk") entry.blog = cheese_blog entry.save()
Example from the Django framework
But ORMs have a dark side - they hide (but do not reduce) complexity, and the interface they expose doesn’t correspond particularly well to the actual work done by the database. SQL is declarative, already obfuscating execution - ORMs hide even more of the computational work behind class abstractions.
I originally envisioned writing this post some time back - in early 2022, Twitter escalated its dark patterns, requiring accounts (or viewing on a phone) to see certain content.
My draft sat long enough (though less than a year) for that to become quaint, but the point I intend to make is increasingly relevant - that we are witnessing a blurring of the public square and the megaphone, and that this blurring has a number of worrying side-effects.
“Aaaaarrrrggggh!”
What does that mean?
It could mean I stubbed my toe - or it could mean I dropped something. Somebody may be in mortal danger - or maybe they just read a disagreeable headline.
For understanding life, language is a magnificent - yet wholly inadequate - tool.
Design patterns are reusable approaches to common problems - anti-patterns are the same, but ineffective (and even counterproductive).
An example of a design pattern is the singleton - we often want to allow access to a resource, without incurring the cost of building it over and over. Computationally, this means restricting the instantiation of a class to a singleton, and then coordinating access to it where needed.
Anti-patterns can include code smells (like the infamous “spaghetti”), but are often less technical. Any process that inhibits effective development is cast as an anti-pattern. Long meetings, analysis paralysis, planning too much and planning too little - all this and more is categorized and enumerated as reasons for poor engineering outcomes.
Generalizing failures from producers to their ecosystem is a good thing. Yet this approach has a blind spot - nontechnical failures can also occur in purely technical contexts. And so I introduce a new engineering anti-pattern - superstition.
The Elements of Style urges us to “omit needless words”:
Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all their sentences short, or that they avoid all detail and treat their subjects only in outline, but that they make every word tell.1
This principle has become a core part of how I think about writing. I often fall short, but striving (and editing) are both healthy and helpful.
But I am often communicating in mediums and contexts not envisioned by Professor Strunk. Sometimes I am writing asynchronous communiques (emails), and other times synchronous chats. I may be presenting slides to a general audience, or discussing implementation details with a technical one. When writing posts such as this, I am balancing brevity with my desire to think through something and express myself fully.
“Omit needless words” is still a sound principle, but it doen’t fully capture these scenarios. So I humbly offer an analogue - exclude unnecessary information.
“You’ve got to hustle. Have a side-gig. Do personal projects. Build a personal brand.”
Such tips are frequently offered, commonly aspired to, and irregularly achieved. It is not entirely poor advice - but it is unduly simplistic.
The general idea is that you’ve got to somehow achieve concurrency - both multitask, and execute well and with focus. And, for a human, this isn’t really possible.
So what is possible?
“Yes, and…” is a concept from improv comedy that means to affirm and build on what others do. Beyond improv, it has been popularized as a pragmatic approach to positivity - say “yes” to validate and encourage others to engage, and say “and” to be sure to engage yourself.
But what about “yes people” who blindly endorse poor decisions? And what about the need to say no to manage your time?
To handle these cases, “yes, and…” could use a philosophical twist. What would happen if we combine improv comedy and the Socratic method?
#!/usr/bin/env python steps = 0 def f(x): global steps for i in range(x * x | 42, x | 42, -42): steps += 1 yield i def g(y): global steps z1 = f(y) z2 = f(y*y) z1l = [z for z in z1] steps += len(z1l) xyz = 0 for z1, z2 in zip(z1l, z2): steps += 1 if z1 == z2: pass xyz += (z1 + z2) return xyz def h(z): global steps tots = 0 for i in range(z): steps += 1 if not i % 3: tots += g(i) elif not i % 2: tots += sum(f(i)) else: pass return tots print(h(1)) print(steps) print(h(10)) print(steps) print(h(100)) print(steps) print(h(1000)) print(steps)