Getting into robotics as a software engineer

Most of my career has been working on web services and mobile apps but at some point this got old for me—in high school I was part of a soldering club and I had this lingering feeling that I wanted to get into ‘harder’ problems. Two years ago I started looking around for companies in Amsterdam and came across Monumental where I’m now working to automate construction using robots, starting with masonry. And let me tell you: it’s super satisfying to see a physical result like a wall get built when the system works. And when I see people working on some crypto or fintech nonsense I can’t help but feel I would be extremely bored working on something like that.

You can have much higher impact getting out of the world of bits and bytes and into that of atoms and electrons. An app is not going to house people, feed them or put them on Mars. We can’t solve climate change with smarter software, we’ll also need massive amounts of solar panels and energy storage. We need to change how we feed ourselves, how we heat our houses and how will we build housing when half the people will be retired because of our aging population.

The solutions for these problems will require software. Control system, data analysis and vision are how we can make hardware come alive. Software is where a whole system comes together.

When working on hardware you get to work with engineers specialized in other disciplines, in my case mechanical and electrical engineers. It’s super fun and inspiring to collaborate with people who are extremely capable, and exposure to other worlds will make you a better software engineer. Something you’ll realize while working with mechanical engineers is that they look at the world differently. The world around you is malleable, to a much higher degree than you realize. That’s something I found while doing home improvement—even if you punch a hole in your wall you can always fix it.

As you start working with other engineers you’ll first be intimidated by them: they will be talking about twenty twenty and percussive maintenance and EMI and you’ll have no idea what they’re talking about. Over time you’ll know enough about how they work to communicate across domains and contribute to the discussion. The kinds of programming you’ll be doing is different, more like game programming with 3D trigonometry and scene graphs.

In the end however, software for robots is just software. You’ll have to do data munging, figure out backups, all that stuff. However, with hardware, there’s new kinds of bugs you’ll have to deal with. I’ve never had to consider a cable being loose before, but now that’s something to look for when debugging a system. People who can work across disciplines are key, someone needs to make sure everything comes together.

Things will be harder because you’re dealing with physical objects. Managing what version of a service you have running in the cloud was figured out during the DevOps/GitOps era: you always deploy the latest version you have on git and do a rolling or phased rollout. You don’t worry about state staying around on your running system because you throw away your container/VM on every deployment. This is the cattle, not pets approach to software development.

Now imagine you have 3 robots in the office, each running multiple services with different colleagues working on them at the same time. And there’s software running on the operator’s computer that needs to be up-to-date. And you have robots working on-site that you want to keep stable and up-to-date while all these changes are happening. How do you manage all this? You can’t throw away your robot every time you want to update the software!

These are problems we can engineer ourselves out of! One indispensable tool in my own toolkit is Nix, which allows me to manage the whole system config in our git repository and have the system automatically pull and apply that. This gives us the benefits of throwaway VMs on top of a stateful system. Because of problems like this there will be days where you wish you were working on a simple CRUD app, however.

You’ll want to learn C or C++ because microcontrollers are programmed using it, you can’t get around it. And honestly, modern C++ is not that bad, but it does require discipline. You’ll have to brace yourself for any code written by embedded engineers, because it’s going to be piles of macro-filled C. Some straightforward OOP with classes and separation of concerns will instantly make you an S-tier great embedded software engineer. Get yourself a Raspberry Pi Pico, a breadboard, servos and LEDs and start messing around with it.

Also, if you’re not already, you should get into writing Rust. The powerful type system and safety is incredible. The build tooling and ecosystem is much better than C++ et al. Rust for embedded is not there yet, but improving all the time.

As you start branching out, you’ll want to learn CAD and 3D printing. Because it’s cool to make physical objects and learn a new skill. But also because you’ll understand your colleague’s hair pulling when Fusion 360 crashes better. Then learn soldering as well, because then you can do simple fixes and learn about how electronics are developed. Know that prototyping hardware is easier than ever. CAD tooling is approachable with lots of YouTube tutorials available. Consumer-level 3D printers are becoming easier and better all the time.

Go do it! Go build robots! Send me pictures of the robots you’re making! Life is too short to build another Candy Crush clone!

And if the idea of working on construction robots excites you, come work with me!

Thanks to Xavier and Phatho for reading drafts of this.

Feb 2024