Skip to main content

Knowing Where To Tap

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:

  • Tapping a hammer: $1
  • Knowing where to tap: $299

As with most concise-yet-resonant stories, it belies a more complex issue.

Read more…

A Consideration of SQL ORMs

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.

Read more…

The Blurring of the Public Square and the Megaphone

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.

Read more…

Life is Context - Language is Specificity

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.

Read more…

Superstition - an engineering anti-pattern

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.

Read more…

Exclude Unnecessary Information

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.

Read more…

Slack Tasks

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?

Read more…

Yes, yet…

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?

Read more…

Big O(Weird)

#!/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)

Better Left Unsaid

Saying something is “better left unsaid” implies distaste - that the thought behind the words was inappropriate, and self-moderation would be wise.

I offer you an alternative meaning - considering what or what not to say is not inherently self-censorship. Instead, it is expressive power.

Read more…