Hardware is Hard
A publication focused on the physical
Toward the end of my freshman year of college, I was faced with the difficult choice all students face — I had to choose my major.
My guiding light was that I knew that I wanted to work in robotics, but, robotics, by nature, is interdisciplinary. It was entirely conceivable that I could choose any among electrical engineering & computer science (EECS), mechanical engineering, material science, or even industrial design, and still be well prepared for a career in robotics as long as I chose the right path. In fact, before college, I took part in the MOSTEC summer program (a summer program at MIT for minority students) and I had an interest in Course 6 (EECS). I even took an intro EECS class my freshman spring rather than an intro mechanical engineering class. My freshman year advisor was a professor in Course 6 too.
But in the end I felt pulled to Course 2, the field of mechanical engineering. I thought a lot about what I wanted to pursue. There were many different ways to achieve my goals, so instead, it came down to my intellectual interests, my principles, the things I wanted to know about the world.
I had this abstract, philosophical epiphany, something that might seem a little too dreamy for a college freshman. I realized that I wanted to study and understand the real, natural, physical world. I didn’t like problems that were abstracted away from reality — rather, I wanted to work on the problems that were the stuff of reality. I loved things I could touch and hold, things I could build and break and fix.
The real world is harsh and imperfect — or rather it is perfect, but we can’t see the whole picture. We do our best with the hints that humanity has collected. Of course, for CS fields, underneath layers of software and firmware is that very same real world too, but a computer scientist operates much higher above that plane. I loved the idea of learning the world’s secrets, of being able to think critically about all the things I see around me. I recognized software engineering as a powerful discipline, but ultimately, I saw it as applied mathematics, a tool to be mastered and important in its own right, but different from a science, a frontier of discovery (don’t come after me, many CS fields are more science-y, particularly quantum computing and artificial intelligence). Ultimately I knew I would be an engineer, so I would be building rather than discovering. But I wanted that theoretical framework to ground me throughout my life, and therefore to be a major part of my undergraduate degree.
I still liked software and still respected it, and I actually ended up being 1–2 classes short of a minor. There was some complex requirements change, and then senior year I just didn’t think the piece of paper was worth it when I could simply tell people my courses and skills. In my work in robotics, this would lead me to that funny intersection of mechanical engineering and software, where, knowing the rules of reality myself, I try to get robots to understand those same rules, or we take advantage of them to create new ways to sense and interact with the world.
The reflection of light, the weight of materials, torque, speed, power — I investigate how to encode these real things, how to paint a picture of the world on the canvas of my machines, and I look through them to see the world differently.
I could talk about software in a way that’s equally poetic — software people build worlds that are entirely detached, places where anything is possible. Where I spend time earthbound, trying to figure out the rules and the answers of this place, they create their own rules, their own answers, their own code. Of course, as underneath all those software layers is really hardware in the end, sometimes software engineers bump against the rough edges of reality again, particularly in cases like low-latency video streaming or anything requiring intense processing power.
But I think there’s enough people out there waxing poetic about software. Hardware is underappreciated, and as the name implies, hard. You can’t get away with just anything in this world of ours, and like Greek tragedies, design-stage prophecies that you ignored explode spectacularly when you go to production. I realized there was a gap in how we talk about technology — “software” and “tech” have felt interchangeable lately, where hardware is a very different beast. We lose that nuance when we talk about tech and default to the software perspective.
The set of problems that people working in hardware face, from electrical circuits to mechanical parts, from cell phones to skyscrapers, from medical devices to construction equipment, require slower-but-more-powerful processes. Testing is more expensive and more difficult. Planning is vital. The dreams you have in your head look very different when you start building them in the real world. And if this earth does one thing only, it keeps you honest. There is no floating along until you bump into processing and throughput issues at scale. Gravity, humidity, and temperature are always there, passing out judgment. Going too far out on a limb will break you easily. Asking for too much, too fast will lead to burnout.
At the end of the day, this work is between you and the universe, which will reward you if you’ll only listen.