William Jen ‘18 has built a career at the intersection of software and robotics, creating the foundational systems that allow humanoid robots to move, perceive, and act safely. In this interview, he shares how his undergraduate experiences shaped his path and what it’s like to build the software that brings Agility Robotics’ Digit to life.
What are you up to these days professionally? What do you love about it?
I am a software engineer on the Robot Platform team in the Infrastructure organization at Agility Robotics. I’ve always loved working on software that directly impacts the physical world. Robotics and mechatronics sit at the intersection of mechanical engineering, electrical engineering, and computer science, and together they accomplish something useful in the world.
Even though I write code much of the time, I know that my work will be deployed directly onto robot hardware and effect positive change. That direct link between software and physical impact is something I think is really cool.
That’s fascinating! Can you walk us through what a typical project looks like in your current role?
As part of the Robot Platform team, I work on the supporting software that runs directly on the robot — as opposed to software for Agility’s cloud-based platform, Arc. Other teams may write code to plan paths, control firmware, or manipulate objects, but they all use the frameworks my team builds.
Some examples of my work include our core middleware [software that acts as a bridge between an operating system or database and applications] for safely and efficiently passing data, the robot’s behavior-tree and safety framework, visualization tools for robot developers, and supporting build systems and third-party library management. Robotics software often targets multiple platforms at once, so my team helps maintain the toolchains [software development tools used in a specific sequence to create a software product from source code] needed to build everything — from Linux systems to microcontroller firmware —without too much of a headache.
You mentioned build systems and library management. Can you tell us more?
Yes! Many compiled languages require transforming human-written code into something a
machine can execute. For small programs, that’s easy. But with large, complex systems worked on by many engineers, coordinating all those files becomes challenging. Build systems automate this process and ensure everything compiles correctly.
Modern build systems like Bazel or Buck also make builds reproducible. They allow for remote caching, so if only one file changes, only that file gets rebuilt. This saves a huge amount of time and prevents problems caused when developers’ computers have different versions of tools or libraries.
Third-party libraries — external packages that provide useful functionality — are critical, but they introduce complexity. They can depend on many other libraries, they may require extra work to build, and they can introduce security risks if compromised or outdated. Vetting and managing these libraries is an important part of software supply chain security.
How would you describe your job to someone without a computer science background?
I like to say that my job is to build the foundation that allows the “cooler” robotics engineers to make our robot do something awesome. When Digit—the robot I work on—walks around, many components are working together: blinking eyes, motors and actuators moving legs and arms, and even sounds.
Underneath those visible behaviors, something has to connect everything reliably. All those behaviors plug into the framework that my team develops. We make sure everything on the robot can talk to each other and work together safely and consistently.
What kinds of real-world tasks are these robots actually doing?
Agility Robotics’ Digit is a general-purpose humanoid robot currently targeting bulk material handling tasks in warehouses. This includes unloading and loading totes, recycling totes, and palletizing or depalletizing.
You also mentioned working on a behavior-tree and safety framework. What does that involve?
A behavior is an abstract task the robot can perform — like walking, sitting, or picking up an object. Behaviors can also be combined into more complex sequences, such as “walk over there and then pick up this object.”
The behavior-tree framework manages these behaviors, deciding which ones can run and overriding behaviors in the event of failures. This is crucial for safety because if something goes wrong — like a hardware issue — the robot can react gracefully and safely.
Looking back, what first got you interested in computer science — and robotics in particular?
Studying computer science was actually a coincidence. I originally entered UW–Madison to study mechanical engineering because I wanted to work in renewable energy. I had taken some computer science in high school but wasn’t sure I’d continue with it.
That changed when I saw Wisconsin Robotics at Engineering Bash. Their robot, Singularity, immediately caught my attention with its shiny lights and visible circuitry. I joined the software team and spent most of my undergraduate years developing core middleware for our robots — networking, serialization, and communication between firmware, the onboard computer, and the operator’s computer. That experience sparked my desire to study computer science with a focus on systems.
What made UW–Madison the right choice for you?
I grew up in Glendale, Wisconsin, and like many Wisconsin students, applied to UW–Madison and got in. It was a nice balance of being close yet far enough away from home but also able to go home as needed as well as still being around many of my high school peers.
Beyond classes, what were some of the most valuable experiences you had at UW?
I spent most of my time on Wisconsin Robotics, including serving as Software Team Lead. We built robots for competitions such as the University Rover Challenge. This work taught me skills that often aren’t covered until later in CS coursework — like networking, middleware, and concurrency — and also required working with other teams (e.g. electrical) and thus emphasized the importance of communication to build a functional robot.
I also worked as a programmer and tutor at the Undergraduate Learning Center (ULC). My team developed and maintained both Tutoring-by-Request — which provides one-on-one tutoring to students in underrepresented groups — and the Drop-In tutoring system, which provides group tutoring in the evenings. We had some technical limitations that made the work particularly challenging, but which also taught me a lot about database design and backend development. That knowledge continues to be useful today; even robots use databases and webservers internally.
Do you have advice for current CS students?
Don’t be afraid to ask for help. Try on your own first, but set a cutoff point and then go to office hours or reach out. This is a new one, but don’t rely on GenAI tools to learn for you. As a student, you are at a critical time where your job is to learn, and you can’t shortcut your learning by having your GenAI write code for you. You can use it like a glorified search engine to complement your learning, but don’t have it do everything. Even in the real world where we have these agents available, we still have it complement our workflows. It’s great when you need a quick example of how to use some tech that’s unfamiliar, but you have to verify it and use it as an opportunity to learn and surpass the tool.
And don’t neglect soft skills like technical writing, presentations, and communication. These become important differentiators in hiring and promotion. Technical communication doesn’t have to be daunting — often it’s just about writing clear sections with context, problems, goals, proposals, tradeoffs, and a recommendation.
Finally, when you’re not building robot infrastructure, how do you like to spend your time?
I enjoy looking for good eats around the Bay Area, playing video games, and spending time with my fiancée and cat.