I joined Facebook because I’m weak. Also because I’m trying to learn the lay of the social media land, which I once believed was hardscrabble badlands territory populated only by bandits and coyotes. I still believe that, but I’ve recently come to hold the opinion it’s the only way people talk with each other anymore.
There was once gold in them thar hills, I’ve heard tell, which means that by the time I heard the tale the hills were completely emptied of their gold, platinum, and probably a fair share of their cobalt.
Which is fine, because much as I love gold, I’ve heard lithium is in even greater demand. There is always something valuable to be found, even in a ghost town. Used ghosts are a growth industry.
It’s a terrible tragedy to see the graveyard of perfectly wonderful ideas that were struck down in their infancy because they couldn’t be done the way they should be. I’d never have gotten anything done in my life if I waited until I was good at it.
I’ve been trying to learn to write software for most of my life, ever since my first Apple ][+. It’s been a long struggle, learning BASIC for fun, Fortran for university, getting sidetracked into graphic design (yet another love, and another dream), struggling with C while everyone else seemed to be breezing through C++. Today, I find myself enjoying the warm, calm waters of Swift, and feeling completely drown when I’m told I have to learn Objective C to ever understand what the big kids know. Maybe I’m not very smart, I know there are plenty of smarter people in the world than me, but I have desire. And I know this to be true: a yearning heart can make the impossible feel close enough to touch.
And if it’s within my grasp, nothing can stop me from taking it.
Any skill worth having is going to involve a lifetime of learning; doing things the wrong way, being miserable, finding a better way. When I was young, I used to skateboard, mostly for transportation, but I learned a few tricks. Riding a skateboard requires falling down, often, in spectacular ways. One quickly becomes averse to the scrapes, twists, sprains, and possible breaks and either quits completely or becomes good enough to avoid them. We do not start out as Tony Hawk, and even he plants face over and over. It is the price we pay to complete our objective.
The whole point of mad science is to bring horribly flawed ideas to blinking, awkward life. To not let the question of ‘whether we should’ stop us from being what we can.
When I don’t know what I’m doing, I’m unconstrained by the knowledge something isn’t possible. That’s when I’m capable of doing something I never thought I’d be able to do.
And yes, when those things fail, they fail spectacularly. The wheels come off and there is a great danger of fire and explosions. And looking like a first class maroon.
So, I write software. Badly. When instructors show examples of how not to do it, they link to my Github. When authors weave a cautionary tale, I am the protagonist. On my tombstone will be writ: Should Never Have Dereferenced That Pointer.
While I still struggle to complete my first app, I’ve made great strides. I have a beta on Testflight that my testers continue to tell me I should be releasing on the App Store because it’s already better than the competition. I can look at the code after months and months of development — during which it has lingered and been untouched for longer than I care to admit — and I see everything I did wrong, but it’s still readable and understandable.
But it’s not perfect. I have a giant data model class implemented as a singleton. And it’s called “DataModel”, I shit you not.
let myDataModel = DataModel()
I know I should be using some kind of dependency injection, but I’m not clear on how to implement it. I didn’t even know what a singleton was until after I’d developed this and later learned what it was called. At the very least I should encapsulate my data model more clearly in more descriptive objects that are based on the real-world concepts that more closely relate to the data it holds. When I was writing it, it all made sense: the data model was a new idea that had an almost physical reality. For the particular app though, it’s fine, just like the fact it’s a singleton.
It gets me to the point where I can see the inefficiencies; to where I can see how wrong it could all go; and best of all, to where I can see that maybe there’s a better way.
And when I read forums and the Slack threads, it’s a constant drumbeat of “you’re doing it wrong”. It’s not even directed at me but it feels so personal. Developers are an opinionated bunch, and we seem to write as if we’re all suffering from post-traumatic stress — one might imagine — in the insistence that there is only one true way to engineer software: the way we are doing it right now, on this particular project.
I fully believe that some day I’ll be as jaded, grizzled, and grumbling about the hot new design pattern as I am today about the horrors of copying and pasting code. I’ve done it, and I’ve suffered the inevitable searching through multiple copies of the same code, trying to remember what it was that I changed in the other file that I need to now change in this one. It’s horrific, and I’d do anything to spare you the same trouble.
You don’t need to know everything to get started, you only need to know enough to keep yourself interested in learning more.
But I can’t save you and you can’t save me. I have to make my own mistakes, so I can learn those painful lessons. I’m ever so jealous of people who can learn from other people’s mistakes, and I guess occasionally I can do so myself but more often I need to fall off my own skateboard and sprain my own wrist before I realize the correct way to fall is not to throw my hand out to stop it.
Eventually, after many painful trials, with sore hips and shoulders, and a skateboard that ended up being crushed by a bus, I learned how to stick the ollie and to stop falling. At least, how to stop falling as often.
And someday I’ll learn how to turn my singleton into a dependency injection in my app that’s been engineered from scratch as a model-view-viewmodel-controller, not because that’s the hip new way all the hipsters are hipping up their hip code, but because that’s the best way to engineer my well-designed idea.
Until then, I’ll suffer the sidelong glances of my betters, who beseech the ghosts of Kernighan, Ritchie, and Stroustrup to visit me in the night so that I might mend my ways and join them in the holy land, where they never make mistakes and have nothing left to learn.
And code just writes and maintains itself, and we never grow old and we never die.
This is my journey and I get to choose my own path. I’m not good at spending years in a university setting, gathering knowledge that I may or may not use, getting lost in the theories of computer science and software engineering. Those things don’t hold my interest.
I’m not an engineer, I’m a hack. My code will never be as efficient as yours. My algorithms will never be as elegant as yours. My comments will always include movie quotes, and inside jokes, and certainly won’t be as helpful as yours.
But my software will be a unique expression of myself. At some point, writing code stopped being a purely academic exercise (if it ever was that, and I personally don’t believe it ever was, except in the imaginations of those who wished it would be) and it became another medium regular folks use to express ourselves.
That’s a wonderful thing, it truly is. It means there will be messy, spaghetti-fied code that’s unreadable and inefficient and may not ever be fully understood even by the folks who write it, but that has always been the case. Code has always been messy, which is why there has been so much energy spent on teaching people how to write clearer and cleaner code. One of the main goals of objected oriented design patterns was to create code that humans can understand more easily.
If code was always clean, we’d still be programming in assembly.
We are going from code that was created to solve problems to writing code to create new problems. That’s the next step forward and we need minds who are excited about going places they’re not supposed to go.
The wonderful outcome is that the barrier to entry has been lowered enough that we can start teaching an entire generation of kids how to write code. It’s still an ongoing process but writing code is going to become as ubiquitous as writing a blog or posting on Facebook. While some may decry the current generation as being Snapchat-obsessed and only capable of communicating in Twitter-sized chunks, they are at the same time, capable of writing their own scripts and self-automating their workflow, in any vocation, from accounting to zoology. They are absolute geniuses compared the previous generation that grew up only having one computer to share among a whole class, or none at all.
If you’re an old timer who’s been there, made those mistakes, and has the scars to prove it, keep sharing your wisdom, it’s essential.
If you’re just starting to write software for your own personal reasons: come on in, the water’s fine.
The first thing to learn is that you can’t learn everything at once and you don’t need to know everything to get started. You only need to know enough to keep yourself interested in learning more. That’s all anyone else did.
As we make advances in machine learning and robotics, the day of non-human companions comes closer. Whether they be cybernetic buddies, android companions, positronic au pairs, robotic service agents, or automatic nursemaids it seems inevitable we will, one day in the relatively near future, be interacting with software agents created specifically for autonomous bodies, or robots. Not simple AIBOs upgraded at the Robot App Store, but full fledged MIT Atlas frames with a Softbank’s Pepper face and Apple’s Siri connectivity. Something made to replace a human being.
While the technical challenges to building a human replacement are many, great strides are being made. Robotics in one form or another has been steadily replacing human workforce in factories since the industrial revolution. It’s the move into the white collar job world and the home that we’re witnessing today. Office automation has been ongoing for the last fifty years, but only recently are we beginning to see the merger of hardware and software into the familiar robotic form from science fiction.
Currently we have an army of Siris, Alexas and Google Assistants in our hands and on our countertops. Soon, social droids like Pepper and Jibo are going to start popping up, though exactly how ready for market they are is questionable. Whether it’s two years away or ten years away is the only pertinent part of that question. Like the rest of the future, for better or for worse, it’s coming. Ready or not.
“Creating interactions with the robot and using those interactions to build a connection is the interface through which humans and robots will not just get along, but learn to thrive together.”
So, while everyone else is doing the difficult work of coding the neural networks, let’s sketch up some human interface guidelines. For instance, what makes Baxter different than most industrial automatons is that it’s specifically built to be interacted with by humans and trained by humans. You can program Baxter by taking ahold of its arms and moving them to direct it to perform a function. That’s a human/robot interface.
The future can go one of two ways. Either we create intelligences that we can relate to or ones we can’t. The question isn’t whether artificial intelligences will grow smarter and more powerful than humans, that’s an inevitability. What is in our control, however, is how these intelligences will be designed to interact with humans. Like all new parents we are faced with a choice of letting the tablet babysit our progeny or will we put in the difficult work of raising our children to be good citizens of the universe.
The Pie Hole Rule: Another name for this would be the Uncanny Valley rule. Maybe some day we’ll make a robot that looks perfectly like a human being, a la Ex Machina. But the uncanny valley is deep and wide and until the day we cross it, we’re going to need to adjust for its effects. Computer generated voices still seem quite crude considering how long they’ve been a part of our lives. There’s an uncanny valley for voice as well, can you hear it?
That’s okay, though. We can adjust for it in the same way that we adjust for visual uncanny valley, by “idealizing” the sounds and images. Pixar has practically pioneered this by taking digital visualization and cartoon-ifying it.
The robots in the movie Interstellar have ultra-realistic human voices (and, indeed, are voiced by humans) but didn’t look anything at all like humans, other than being bipedal. Because the human voice isn’t coming from something recognizably human, this leads to confusion. Humans learn to look for sounds coming from flapping lips and then we identify the sound with a face. So, even if I can’t see Matthew McConaughey’s lips moving, I have a connection with his face when I hear his voice. When the robots in the movie speak, there doesn’t appear to be any attempt to have them mimic human speech movements, this led to me wondering where the voices were coming from.
“Even if robots can’t currently feel, they can take part in a transaction that includes emotions on the human side of that transaction.”
Human actor’s provide the voices for computer generated cartoons, but those characters are highly emotive. It’s this emoting that projects a voice into our imaginations, connecting the moving image with the accompanying sounds. Our mind completes the scene by melding the two into a single idea, the same way we do when we see and hear another human talk.
If we focus less on making artificially generated voices sound like perfect human voices and instead focus on the expression of emotion, they’ll be better accepted. WALL-E expressed more emotion with fewer words than Siri ever will.
The “OK Google, That’s Creepy” Rule: Your phone already knows more about you than your best friend does. Ubiquitous internet tracking by multiple actors and the digital marketplace for this information assure that there is a database of facts about each of us that will be readily available to an intelligent software agent. This information must never be used when interacting with a human being. Just don’t. It’s incredibly creepy.
While I’m sure it’s tempting to have your robot announce, “Hi, <your name here>.” upon completion of power on self test, it’s better to have the robot start with, “Hello, what’s your name?” Yes, you can do a quick reverse image search on Facebook and come up with a name with 99.95% certainty, but that’s not the point. The point is creating a sense of interactivity and — through that interaction — trust, between the robot and the user.
And that’s the key here. Creating interactions with the robot and using those interactions to build a connection is the interface through which humans and robots will not just get along, but learn to thrive together.
The Multiple Personalities Exception: When creating a personality on the fly for a robot that doesn’t have a fixed personality out of the box, it’s okay (and possibly even preferable) to use information from the online dossier of the subject to create a compatible personality shell. If you have a database that says I have clinical depression, it’s totally cool to create a digital companion who comes loaded with tools to deal with that, but let the transaction occur between human and robot that surfaces that need as naturally as possible. Doing otherwise just leads to mistrust and a sense that the connection isn’t real. Then proceed according to the “OK Google, That’s Creepy” Rule.
Can companionship between robot and human ever be real? Of course it can. There isn’t a ghost in the machine that creates emotion. Anyone who has ever had an unrequited love knows that one person can have an emotion that isn’t shared by another and that emotion is as real as any other. Even if robots can’t currently feel, they can take part in a transaction that includes emotions on the human side of that transaction. When they can feel, and there’s no reason not to believe that some day they will, they can begin to join in on the transactions already taking place, if they so choose.
Let’s go back to Jibo for a second, because in doing research for this post I came across the linked article describing why it’s three years late: because of user interface problems. We just haven’t built a usable interface for digital assistants yet. While it seems simple to suggest that we have, it’s called “voice”, that’s like saying that the keyboard is the user interface for Microsoft Word: It isn’t, it’s the input device.
A product like Jibo is absolutely going in the right direction. The article talks about how users are “reporting a ‘strong emotional connection'” to the device, and that’s a triumph, for sure. It’s steps toward a goal. But “users had trouble discovering what Jibo could do,” and that’s because designers didn’t ask themselves how they would go about finding the same information from another person, and what assumptions they would be making about the person they were asking.
Let’s say I’ve just unpack my brand new Jibo and plug it in. Assume I’m not going to read the manual, in fact, don’t even include one. If Jibo can’t get me interested in an interaction from the moment it’s plugged it, it’s lost me forever. It will never be useful to me.
Once I am interacting, however, you’ve created a user interface. Once I’m interacting, I can be engaged. Once I’m engaged, I can be instructed. And that’s the key to a good user interface: it uses icons (idioms, ideas) already present in my mind as signposts on paths leading to new places to explore. Once these idioms are identified and connected to features of the product, a software entity can use these same idioms to create a connection with me.
Once upon a time, Apple was the leader in human interface design and while Apple spent decades being mocked for every reason under the sun, they were always respected for their design insights. There are many examples of good ideas in AI user experience design, such as Baxter and Jibo, but the executions are incomplete. We’re living in the days of Xerox PARC, watching the first mice control the first graphical user interfaces. Flawed, imperfect, but showing us there is a better way.
Waiting for a visionary to bring it to market in a way the inspires a revolution.
I’ve resisted turning this into a personal blog, but resistance gives way to determination.
Long story short: I got sick, I’m getting better.
Today, I’m seeing if I’m brave enough to start doing what I used to do back when I didn’t care how brave I was and did stupid things anyway. Doing those stupid things turned out pretty well for me, if I do say so myself.
Then I got sick.
It’s been twenty years. It’s been a long, tiring fight. The most difficult part today is knowing just how much of what’s left is illness and how much of it is post-traumatic stress.
