A while back an editor pulled me up on a tech piece I'd written. There were a bunch of sentences like "Google are changing the way they do business", which he'd corrected to "Google is changing the way it does business". He said, "it's weird that you keep doing that. A company is a singular; an 'it', not a 'they'". I wondered where I'd picked up such a strange deviation from standard English, because it definitely didn't feel incorrect.
I was reminded of this recently when I saw an article on the SourceForge fiasco that quoted a source like this: "SourceForge are (sic) abusing the trust that we and our users had put into their service in the past." Obviously I'm not the only one who can't sneak that particular formulation past a wary editor!
On reflection I think the "they" vs "it" question goes deeper than syntax, and speaks to an important point about the nature of corporations, especially in the context of SourceForge-style malfeasance. We use the plural when we're speaking about a group as a collection of individuals, and the singular to refer to the group as a distinct entity deserving a separate identity. This becomes particularly apparent in business, where a company represents the transition from one to the other: the "they" quite literally becomes an "it" by incorporating.
But there are a lot of issues with creating a magical person. If two people get together and poison a river, they committed a crime. But if they incorporate first, it committed a crime. The dangerous power of being able to create a legal whipping boy as a liability shield is part of the reason why there have been consistent efforts to weaken those protections in recent years.
Legality aside, there's no reason for us to adopt the idea of corporate personhood in our thoughts or conversations. Up until the point where Google's self-driving technology starts directing the company, it's not an "it". Trying to discern Google's character, speak to Google's motivations, or appeal to Google's morality is only a path to confused thinking. It doesn't have those things, rather they are just a bunch of people who do things together. Those actions add up to systematic behaviour, but they don't add up to a new person. Google is a "they", not an "it".
Though I still don't think I'm going to be able to get that in print.
This is a project I've been working on with Laura Jade, a friend and local artist. Much like the earlier Brain Ball, it lights up different colours depending on your brain activity as measured by an EEG headset. I had to fairly dramatically depart from the ball, though, because what shows up well on a screen is totally different from what shows up on a projector.
It still shows Alpha, Beta and Theta waves as blue, red, and green, but the colours are all full-saturation so that they show up well on the perspex brain. The flickering patterns are generated by the cellular automata I wrote, so I'm pretty pleased about that. That said, in the end it looked better with a much smaller pixel grid than I expected. I made the GPU rendering powerful enough to drive 1280x1024 pixels and in the end we only used 32x24.
I started off wanting to make a particle system using magic shader magic, but I ended up making a Game of Life simulator instead. I'm pretty impressed with all the crazy stuff you can do using shaders and vector math. On a Raspberry PI GPU I can get pretty close to 60fps at 1920x1080 cells, which is not bad considering how terribly optimised the code is.
The pictured automata is actually something a bit different from regular Game of Life. I tweaked the numbers a bit because I wanted something noisier. It kinda has this strange quality where it feels like it's moving in lots of different directions at once. I'll try to make a WebGL version of it sometime soon, because it's very mesmerising.
I've been trying to do some stuff with OpenGL lately and, uh, wow. I don't know if it technically qualifies as the worst API I've ever seen - there's some fairly robust contenders in the "enterprise web services" category - but it's definitely got a straight run at the title. I remember it being a bit gross when I used it a few years ago but if anything it's managed to get even worse. It's layer upon layer of new features melted over a terrifying spongey core of half-arsed backwards compatibility.
Anyway, it got me to thinking about that funny thing that happens with code, where it sticks around long past its use-by date. I'm fairly certain an old mailing list system I wrote in an afternoon in Python nearly a decade ago is still kicking around in production somewhere (sorry). But every time I still manage to convince myself that this time it really is temporary, and someone totally will come along and fix it later. Unfortunately, nobody ever does.
I've wondered sometimes if the right answer is just to always write code as if it's going to last ten thousand years. I don't mean write it so it could cover every eventuality into the far future, that would be awful. But maybe, if you were diligent, you could always write code with a certain essential craftsmanship. Code that you wouldn't be ashamed to see dug up in ten thousand years.
Have you ever noticed that thing where you're really in the zone – you're writing, or playing a game or a sport, and you have that magical flow feeling where it all just seems to be happening effortlessly – and then you become aware of that fact and suddenly lose it. Daniel Kahneman talks about the fast and the slow systems of thought, and to me it seems obvious that flow is rooted firmly in the fast system, until it gets bogged down in slow-system meta thoughts.
The best analogy I can think of is the Linux system utility strace, which allows you to inspect what a program is doing by tracing system calls that the program makes to the operating system. It's super useful, but it doesn't come for free. If I do something like copy 100GB of zeroes around:
$ dd if=/dev/zero of=/dev/null bs=1M count=100k
102400+0 records in
102400+0 records out
107374182400 bytes (107 GB) copied, 6.43048 s, 16.7 GB/s
And then I run it with strace:
$ strace -co/dev/null dd if=/dev/zero of=/dev/null bs=1M count=100k
102400+0 records in
102400+0 records out
107374182400 bytes (107 GB) copied, 10.5155 s, 10.2 GB/s
You can see it takes over one and a half times longer! We can run ps to make sure:
$ ps 21278
PID TTY STAT TIME COMMAND
21278 pts/0 t+ 0:12 dd if=/dev/zero of=/dev/null bs=1M count=100k
That STAT t+ means it's currently being interrupted for tracing. In fact, it's being interrupted on every single attempt to read and write data which, since that's all it's doing, is a lot of the time. Obviously this is a pathological case, but if there's anything we know about biology it tends to be pretty pathological! Strace was designed to be as efficient as possible, whereas the same is definitely not true for our own introspective abilities. Even so, it's usually considered a bad idea to use strace in production.
And I think we lose a lot when we can't turn off our own introspection for production. A simple exercise in speaking to a group of people becomes an endless cascade of "did I really just say that? Oh god I'm doing this all wrong". A simple game of tennis becomes an exercise in simultaneously trying to move a racket while being aware of every minor rule of good playing form. A simple writing exercise becomes a game of writer-vs-editor where you get bogged down in stylistic questions when you really should be just letting the words flow.
Introspection is important, of course. Judging and evaluating what you do is the only way you get better at it. However, to do your best work at something you have to be completely immersed in it, and that means leaving the introspection until later.
