Halloween Candy Machine | Part 4 of 8
Real-life origin stories
The human connections behind woodworking, software engineering, and UI/UX
This is a standalone article within a multi-part series.
Whenever I read about other peoples’ success stories, I’m always struck by how much credit women give for the help they received along the way. That’s one of the reasons the myth of solitary inspiration has always felt like someone else’s poorly-fitting jacket. I’ve explained my own circuitous software engineering arc plenty of times, yet people somehow still seem to prefer the fairy godmother version of the story, the one where a magic being taps you on the shoulder with a wand of talent. I’m not completely sure why. Because it’s simpler, perhaps? Or perhaps because we’re too used to the myths?
Either way, I have a couple true origin stories to chew through, which I offer as counterpoint to the fictional ones. The common thread is human connection.
Origins: Woodworking
I want so badly to leap straight into the design twists and turns of building the candy machine, but I need to start with the woodworking. Not too long ago, I too was under the misimpression that woodworking is much more difficult than it actually is. Someone who’s never done woodworking is going to have a very different relationship with the candy machine than someone who has. So let’s start by demystifying woodworking. As with learning how to write code, and as with Cinderella’s mice getting the key up the stairs, there was a step-by-step progression to my own journey that belies the fairy godmother myth.
Rather than walk through every step of every project I’ve ever done, I’m going to highlight a few of the interesting problem areas that led to progress.
My first woodworking project was born out of necessity. Two-year old Nora needed her own handrail for our rather intimidating flight of stairs. The handrail built by the contractors when we first moved into our house looked easy enough to reverse-engineer. A quick Google search led to the same basic design over and over again. This seemed do-able. And it was.
First and foremost, I needed to get comfortable using a drill. We owned one, but I’d always made my husband do all the drilling because I was scared of it. There’s not much to be said on this front because in the end a drill is a pretty simple piece of machinery. Practice led to familiarity. I’ve never come close to injuring myself. There wasn’t any real obstacle to overcome other than my own initial resistance.
Second, I got help when I needed it from a fellow shopper at Home Depot. These early moments of support are important, which is why the story of Interstellar Cinderella studying alone in her room never sat right with me. Perhaps there are true geniuses out there who do it all alone, but most dads don’t need to be solitary geniuses in order to become engineers and neither should their daughters. My fellow Home Depot shopper took the time to steer me to the miter boxes and explain how to use one, and I owe a rather outsize debt to him for this early moment of sociable kindness.
Cutting the oak handrail with a Japanese pull saw and a miter box to guide the diagonal cuts was tedious, but not difficult. I hadn’t yet built the sawhorses in the above picture, but for some reason I owned a few C-clamps and I was able to clamp the whole works to the balcony rail and make the cuts safely.
The project didn’t go perfectly. I used up a lot of wood on tests and still needed to re-do a failed first try at a joint. I also wasted a fair bit of stain and polyurethane. Nonetheless, there’s nothing like a successful finished project to build confidence.
My next big jump in progress happened a year later. Our backyard was tiny, dark, and covered with weeds. We finally decided to revamp it so three-year old Nora could have some play space. I landed on the idea of a giant chalkboard as something that would add visual interest while having very little footprint. And I found a set of instructions on Pinterest that looked do-able without power tools.
Something interesting happened on the way to the project. While I was purchasing materials, the guy at the local hardware store suggested some changes to the plan based on the fact that I would be mounting the chalkboard to existing 4x4 posts. The guy at the paint store made some suggestions about surfacing. Our landscaping contractor lent me his sawhorses for a few days. And most importantly, my next-door neighbor saw that I was cutting boards by hand and loaned me his miter saw and random orbital sander. They’re still on permanent loan in my garage today.
I don’t think I would have made the commitment to buying a power saw if that one hadn’t dropped into my lap. At that point, I was still scared of power tools. But once I had that miter saw in my garage, I used it. And used it. And used it. And that’s the beginning of my woodworking journey. It took a village, and it took some luck. What I learned was that woodworking is a surprisingly accessible hobby. There are a lot of Internet tutorials out there. Ana White’s website is a great place for a beginner to start.
Origins: Imposter Syndrome and UI/UX
I have three stories to share about Imposter Syndrome.
The first is the standard story of feeling like I didn’t belong. As an undergraduate at Princeton, I distinctly remember walking into my favorite college professor’s office hours and confessing that I felt like the duck in a vet’s office that thought it was human. He laughed and reassured me that many people feel that way. I didn’t encounter the term “Imposter Syndrome” until years later, but I experienced a lightbulb flash of recognition when I did.
My second two stories about Imposter Syndrome are about leaning into the pretense.
Armed with a Comparative Literature degree, I was lucky to get my first programming job out of college. Nonetheless, I had more tools in my arsenal than were evident at first glance. I’d done large amounts of tinkering on my own as a high school student, taken AP Computer Science, and taken one intense Princeton course that I would later discover had crammed years’ worth of material in a single semester. The odd thing was that no one really cared about the coursework or the self-study.
At some point, I applied analytical intelligence to my then-shaky social skills and came to a Spock-like conclusion that I needed to play the girl genius persona because it was the only one that people found believable enough to accept. It was a fairly cold-blooded, hyper-rational decision, but to this day I don’t think I had another choice. I needed to play to the stereotype in order to survive. (This wasn’t truly deceptive. It mostly meant being mysterious about how I knew something rather than flipping to some boring page in the manual.)
My third story about Imposter Syndrome takes the pretense even further. There’s a TVTropes entry called Becoming the Mask, which pretty well sums up how I feel about my first job as a user interface developer.
Becoming The Mask: The Mole or the Con Man takes on a fake identity in order to gain something, be it information, money, a safe place or trust. As time progresses, he grows to love his new identity and the way people treat him. His new friends prove reliable and he is struck by the contrast. He might even fall in love with another person whom he is explicitly supposed to be taking advantage of. Either way, he wants to remain in his new identity forever.
I never set out to be a user interface developer. My first-ever GUI was an unhappy accident: a group project member in a software engineering course dropped the ball and I had to re-do the GUI from scratch at the last minute. At the time, I was working full-time while getting my MS in Computer Science part-time, and I was not happy about the extra work.
Having somehow survived that mess, I decided to build my second-ever GUI because I wanted better control over the rendering assignments I was doing for a computer graphics class. I slapped some screenshots of that GUI onto the end of my demo reel, flew across the country to the SIGGRAPH conference in Los Angeles, and emerged with a job at Digital Domain as an extremely under-qualified UI developer. And I wasn’t just any UI developer. I was the UI developer, their first-ever hire with that particular job title.
I’m not going to dwell too much further on the imposter part of this story. The group that hired me knew what they were doing. They needed a computer graphics generalist who could also do UI rather than a true UI specialist, and I was a better fit than I could have known at the time.
The “becoming the mask” is the more interesting story. I can’t say I particularly liked GUI programming at the time I was hired. I would have happily taken a job as a janitor to get my foot in the door of a visual effects studio. Instead, I landed on an amazing team, with people who were passionate about sharing their knowledge and believed I had something unique to contribute. Because I held the job title, people came to me, and because people came to me, I found ways to deliver. UI became not just a job, but an identity, one I carried with me to every subsequent job.
A true UI/UX specialist never really gets to specialize. They inevitably become an evangelist, someone who inspires the people around them to zoom out to see the big-picture relationships between people, processes, tools, and data, and then zoom back in to see the tiny, painstaking coding details that make or break these relationships. They’re a cat herder, cheerleader, and persuader, but also a listener, empath, and endlessly attuned observer.
As a software engineer, I have learned and forgotten more programming languages, platforms, packages, libraries, design patterns, paradigms, idioms, and idiosyncrasies than I care to count. They’re like garments to be worn when new and shed when outdated. But becoming the UI evangelist got baked in bone-deep. I can’t ever remove that part of my identity, nor do I want to.
Origins: Designing for Kids
For a long time, I’ve wanted to write about UI/UX and parenting. Designing for kids is about accessibility and empowerment. Great design gives the little ones agency within a world that usually leaves them dependent on adults.
The problem is that I have five years of backlogged projects to write about. Where do I start? The toddler fingerless gloves? The preschooler clock? The kindergartener treasure hunt maps? I’ll get to these in due course, but here’s a small teaser.
My son, bless his stubborn soul, would rather be carried up the stairs than walk. My knees cannot take any more carrying. So I rigged up some irresistible bait: two battery-powered light switches. (Unfortunately, there isn’t a specific off-the-shelf product I can recommend. I had to jury-rig these with colored cellophane to keep them from being uncomfortably bright, and add a wood backing to make them easily removable.)
In addition to toddler psychology, there are a couple basic UI principles at play here.
First is splitting a monolithic domain into manageable chunks. Elias can usually be cajoled into climbing enough steps to turn on the purple light. Once he reaches the purple light, the orange one is close enough to feel achievable. Once he reaches the orange light, he can see the top of the stairs around the corner and finish that final stretch.
Second is the instant reward. There’s no pause between flicking the switch and seeing the light go on. The environment is responsive.
Third is mounting the lights at toddler eye level. This seems obvious, but it’s a design element I see a lot of parents get wrong. They hang calendars and posters and whiteboards at adult eye level rather than kid eye level.
Fourth is planning for multiple iterations. I never assume a project will work until it’s tested on end users. My goal is always to deliver a first iteration as quickly as possible, but not so quickly that sloppiness invalidates the test. In this case, the light switches did work on the first try. I was prepared to add more lights and fiddle with the placement, but it wasn’t necessary.
Fifth is that undefinable appeal that makes everyone want to keep clicking buttons. The unexpected side effect of mounting light switches by the stairs was that all four family members felt a compulsive need to flip the light switches on and off every time we walked past them. My husband said he expected this jingle to play and a secret passageway to open up.
Origins: The Candy Machine
Having promised my friend that I really would take to Medium and write about UI/UX, I promptly came up with a new project: the candy machine. I’m not sure I would have internally greenlit the candy machine if not for the prospect of writing about it. But once the writing became its raison d’être, I had to make it happen.
And, conveniently, I had a deadline: Halloween. Deadlines are great for getting things done.
Like many pandemic parents, I’ve let my kid experience an enormous amount of screen time. And while I do feel guilty about it, I’m also pretty happy with Nora’s viewing choices. Last Halloween, one of our neighbors built the cauldron from the Wicked Makers Youtube channel. Nora loved our neighbor’s cauldron so much, I eventually found the how-to video and Nora has been devouring the Wicked Makers channel content ever since.
This year, I offered to let Nora pick a project from the Wicked Makers that we could build together. She picked the candy chute, a perfectly reasonable option. Except I didn’t really want to build a candy chute. I wanted to one-up it, though I wasn’t yet sure how.
I’m going to pause here for a confession. I don’t really enjoy following other peoples’ step-by-step instructions. To me, it’s like assembling IKEA furniture: not wholly unrewarding, but also not creative.
I do Kiwi Crates and Youtube tutorials for Nora’s sake. Even though I was always the kid who wanted to run before they could walk, I as an adult see the value of walking first. And Nora happens to be very much a rules-following, a walk-before-running kid. So I try to mix things up three ways:
- The tutorials, where I teach Nora the importance of following through from A to Z and being methodical.
- The free-form projects, where Nora states a desire (for example, a heart stuffie) and I find a way for us to make it happen. I’m trying to teach her that anything she envisions can eventually be brought to life.
- The Mom projects, where the build process is too difficult for a kid to contribute much, but the end product is something the kid can enjoy.
The candy machine falls very much in the third category, something I do for my own enjoyment as much as if not more than the kid’s. Admittedly, it often means leaving the kid alone with an electronic babysitter so I can actually make progress. So there’s always some amount of guilt to factor into the equation, which I’ll also address over the course of the design diaries.
Next in the candy machine series: The journey from defining the problem to finding a conceptual solution for the kid-powered candy machine.
