Monday, June 27, 2022

aphoristic noodling

I read this post by Baldur Bjarnason, listing "Everything I’ve learned about web development in the almost twenty-five years I’ve been practising", and this followup, which says:

Some of the aphorisms ended up not-so-pithy, but it was overall a fun little experiment that I recommend: note down everything relevant about the craft that you can think of over the space of a week.

I thought about this, and then I thought: Ok, what exactly is my craft? I do computer shit. So I started a list about that, challenging myself to be descriptive about things and not veer too far into pure advice.

A year or so passed, and I noticed this post was still sitting in my "work in progress" directory. I tried picking it back up and noticed how much overlap it would have with other posts like these:

This style of writing is basically catnip to people like me, whether it's of much use to anyone else or not. This post ultimately felt like a dead end, because instead of a blog post, it really wants to be some long document where I collect all sorts of aphorisms, pithy quotes, eponymous laws, and so forth about technical work and maybe just work generally. Maybe I'll start that document one of these days.

Anyway, that very partial and uneven list:

  1. Caching is hard to think about and breaks often.
  2. Cleverness in code is generally a sign of danger.
  3. Business ruins everything.
  4. Some forms of interoperability are a trap.
  5. Bad ideas aren't limited to bad people.
  6. Good people aren't limited to good ideas.
  7. An aesthetic is not an ethic.
  8. The customer is usually wrong.
  9. If it's written in:
    • C: It'll work, but I should remember there's a buffer overflow or something.
    • PHP: It'll probably work, but there's an SQL injection vulnerability somewhere and the cool kids will be shitty about it being PHP.
    • Python: 50/50 whether it'll just barf stack traces into my terminal for non-obvious reasons.
    • Ruby: Decent chance I'll wind up reading the source code and cursing at clever Ruby programmers.
    • Haskell: It works, but I'm not smart enough to understand it.
    • Rust: Probably works, if they finished writing it. I'm not smart enough to understand the code.
    • Go: Total crapshoot, but either way I bet the CLI has a bunch of infuriatingly nested subcommands.
    • JavaScript: Life is too short to deal with whatever package management and runtime I'm supposed to use for this now.
    • Java: If I have to find out it's Java, I'm probably in trouble.
  10. Lightweight markup languages are fundamentally in tension with the range of structures that their users will inevitably want to express.
  11. Design, marketing, and management are all real undertakings, but they are also aggressively self-reproducing ideological systems and political projects.
  12. Environments within which small tools can be combined to operate on simple abstractions are powerful. An environment might be what you think of as an operating system, a programming language, a database, or an application. All else being equal, the ones that can bridge to other environments are more powerful.
  13. There are few abstractions in computing more stable than filesystems, standard IO, text files, and the shell. Boring relational databases aren't too far behind, but the barriers to entry and data transfer are higher.
  14. Technology is at least as fashion-oriented as the sartorial choices of highschoolers, actors, and musicians. Changes are driven as much by a desire for difference from the perceived status quo as anything else.
  15. Technical politics are also organizational, labor, and identity politics. The currents of power they involve are illegible without taking those factors into account.
  16. There's no guarantee that your technical preferences will match up with the ideas, people, or power structures you find agreeable in other domains. (Or vice versa.)

tags: topics/technical, topics/work

p1k3 / 2022 / 6 / 27