(A brief aside from my scheduled programme)
At an early age, around 4-6, we develop a Theory of Mind: we become aware that perception of the world is a simulation in others as well as ourselves. (See Theory of Mind, Simulation Theory, Sally-Anne Test – if you have subscriptions to Nature or New Scientist you can find much better articles there)
Indeed, the failure of mirror-neurons, that are currently understood to be a key part of this process, has been linked to the development of autism. (The nova segment is actually surprisingly good and may fire off some lightbulbs for a game dev or two)
It’s my speculation that programming is one of many disciplines that requires us to apply our theory of mind to a conceptual entity. To use those parts of the brain designed for simulating a model of how another person thinks to instead simulate how an inanimate series of objects or a conceptual system operates and works. Librarians do it, medical translators do it, mechanics do it, engineers do it, etc, etc. But within each of these disciplines there are different stratum of specialization, levels of interaction outside and beyond the conceptual entity.
Really, really, really good, AAA programmers are able to focus their theory of mind and their parenting systems onto the entity and raise it into adulthood. I’ve noticed that quite a few programmers are, like myself, actually pretty good with kids. Or, I should say, “a child”. And I say “actually” because we’re not nearly so good with other adults.
When you are modelling the operation of a computer system it is intrinsically simple but superficially complex. At its very heart, all silicon functionality is one massive Yes/No game. Is I > 8? No. Is I > 4? No. Is I > 2? No. Is I > 1? No. Is I > 0? No. Then I = 0.
Progressive layers of complexity are built up from that, but most non-programmers are surprized to discover that something as “complex” as programming in C is based on a mere 32 keywords! (C++ has 62)
Just as silicon can turn patterns of 1s and 0s into, programmers turn patterns of if, while and for into web browsers and biometric thumprint readers.
What escapes most people is that there are specialities – sub-disciplines – within the field. Just as an artist might excel at portraits but be terrible at casting the nuance of light and shadow across a landscape (and presumably for similar physiological reasons) not every programmer can apply their theory of mind to different depths or branches of programming.
To develop good tools, you must have one or more individual well modelled in your theory of mind while simultaneously modelling your own application (tool) and superficially the entity you are providing access to.
Why do I feel so qualified to speak on the subject while professing not to be the tool-writing Michael Angelo? I think what distinguishes me is my awareness of the existence of these boundaries.
I learned to program to write games, multiplayer games. But software houses gave me solid reasons for not being interested. I had a friend who ran a nation-wide bespoke business software house, I’d noticed that he frequently had bits of hardware lying around his home/car that I had only seen or heard of in movies.
To keep a long adjunct brief, I saw business development as a way into the fields I wanted to get into and onto the kind of hardware I wanted access to. Far more so than British Universities at the time.
My career started by working for a nationwide bespoke business system development house. I very, very quickly realized that I did not communicate on the same level as the people it was essential for me to communicate with within our clients. But, if we sat down and they showed me what they were trying to describe, I could quickly pick up the process and intent, and the “dialect”.
If you like, I learned to micro-specialize. I spent many, many months writing code at one of our client’s premises — a tour operator. A significant amount of my time was spent observing the staff processing orders.
Perhaps it was my interest in communications, but what I came to see amongst all these customers was that business operation is the intelligent execution of a series of protocols. Just like in computing, every protocol stack has its own jargon, often conflicting with that in others.
Of neccessity, I developed a talent for visualising an implementation that facilitated existing processes and protocols and spotting the repetetive tasks that would gain most benefit from automation. I can’t claim a talent for communicating these, I often had to fall back to our analsyts or “sales programmers” to translate my concepts back into English. I also caused some frustration because I started to realize our other analysts and programmers didn’t communicate thoroughly enough and what they were producing was software that met the customer’s need at only a very, very high level.
Analyst: They take the call, they get the customer’s name and address, desired date of flight and return, etc. When its all done, you have to print out an standard ISO form to be copied to the airport, the airline, etc.
Coder: This is the screen for inputting customer’s name. This screen lets you input the address. This one is for flights and this one for destination. Hans here can re-organize the form to suit our needs while still complying fairly closely with the ISO standard.
That’s what they implemented, and it was so incongruous – with their business practices, their filing systems, the needs of their customers, the methodology of the airlines, airports and reps – that they carried on taking orders onto their old form, entering the data into the computer, and using the computer’s forms solely as a cross-reference.
Me: They’ve already designed a form layout which could be used for a single dynamic input screen that would be flexible enough to cope with the quirks of how they process an order, and we could then print to the same form they already use, which the airports, airlines, reps, customers and staff are already familiar with.
Analyst/Coder: WTF? That’s going to be unreadable, unworkable.
So I made a screen that combined all 9 input screens into one crowded representation of the form. The team used all kinds of TLAs and abbreviations, so I also created a series of screens for managing these. Simple indexing. Instead of having to type “Menorcan Tennants Association” to look up a property, they could type “MTA”.
My bosses nearly cracked ribs when I showed them my screen. Infact, out of concern for any last shreds of respect the customer might have for me, I was denied permission to show the customer.
Some of the agency staff had caught wind of my idea, and had confronted the owner with a very negative reaction to clinically presented separate input screens. During our next visit, a mutiny occured which very nearly gave the owner of the agency a coronary. In the end, the screen wound up being shown.
There was a long, deadpan pause. The analyst smacked me in the back of the head, picked up his cigarettes and began a farewell walk to the door.
“But, erh”, said Bob, the owner. “That’s exactly what we want”.
Collin, our analyst, wandered back. I can’t describe his expression or posture. “That, Bob, is a mess. Nobody can read that. The current system is designed so that information is clearly presented and all it takes is a few keypresses to bring up critical information as its needed”.
“That … is Mrs Clayton’s reservation for four to Menorca for next week flying from Gatwick, staying at Son Parc, but it doesn’t list any car hire”, said Angella, “Sue, did you add Mrs Clayton’s car hire yet? It’s not listed here”
Sue walks over, pulls out a form from a folder she’s carrying, scans it once, scans the screen once, looks to Angella and replies “Oh, there was an error in the pricing we gave her (points at the screen) on the phone (points at the form). I’ve tried calling her a couple of times to confirm the correct price but haven’t got through yet”
As I wandered off with the lovely Sue and Angela to make sure the price on screen wasn’t a computer error, I heard Bob saying something about “didn’t press any keys at all”.
In the future months, our early morning rides to Mansfield somehow always seemed to need to leave before 6am and end up taking the route that went nowhere near anyplace I liked the breakfast offering… But Promax quickly discovered that putting me on-site rapidly turned contracts around, and the rides went back to 8am and the occasional stop at a Little Chef.
Sadly, all a bit too late, and I was having to learn everything I knew about accounting systems on the fly so that while I was making systems more usable I was slower at making them more useful.
Communicating with programmers isn’t that difficult. The Matrix resonated with a lot of people because, in their particular field, in their particular way, we have all had a Matrix moment – of some varying degree of profoundness – where we suddenly clicked together the final piece of a puzzle of how something worked. That is the application of Theory of Mind. Each speciality represented amongst a team of people working on the same project has their own Matrix code, or perhaps codes it a different color. The knack is learning to bridge them.
All you have to realize is that when a programmer is in their “zone”, when they have their theory of mind focused on the product/project/entity they are developing, that they are running on very simple rules. Concepts like “the team” or “the management” or “the user” are in a different grab-bag. Its not an easy transition to make, but most programmers can actually do it.
When you corner a programmer in a meeting, don’t try to expect them to be able to remember what Project::SubProcject::SubModule::SomeFile:Line192 contains and think realistically about userspace issues at the same time. A coder operating in low-level-land thinks they can still understand users, because in our heads the simple rules of coding still work and its not to notice you are trying to apply the same rules to people.
In my time at CRS I’ve often had one Rat or another come into my office and try to engage me on some topic of high-level play of our game – something I love talking about and trying to find coding solutions to; but they get met with angry-bear-with-a-wasp-up-his-snout, and very terse, curt responses. It’s as though I don’t have a clue what they are talking about.
They’re talking people-talk to me while my brain is interpreting the universe in terms of 62 keywords, and it doesn’t make sense. Later on, I’ll probably walk into their office and try to engage them in exactly the same discussion as a result of some perspective I gained while running through the high-level appearance of some system or other.
I’ve written a lot about how important I think tools, tooling, instrumentation and reporting are. It’s about time to put my money where my keyboard is, and try and shore it up with some examples.
That might take a little while :)