Space is cool again, thanks in large part to companies like SpaceX and Blue Origin launching spacecraft into Earth’s orbit and beyond. Thanks to all that buzz, a growing number of startups are investing in rockets, satellites, and much more. One of those startups is True Anomaly, which is focused on space-based security and sustainability—and Dice’s ‘Tech Connects’ podcast recently spoke with Ben Marx, True Anomaly’s Director of Software.
The audio version of the episode is available on Dice Career Advice, along with podcast channels such as Acast and Spotify. Here’s the video:
We’ve also included some transcript excerpts (edited slightly for conciseness and clarity). Follow along as we break down space, startups, programming, and more!
You spent a decade involved intensely with the Elixir programming Language, and now you're with True Anomaly and you're using Elixir in the context of space. What’s your story with Elixir and how does that intersect with True Anomaly and space?
I don't have a degree in computer sciences. I studied philosophy and economics, but when I was young, I liked playing with old Commodore 64s and those kinds of things. It wasn't until after I graduated that I found that neither philosophy nor economics would be substantially paying as a job, and programming sort of combines a lot of those elements [in those fields]. So, I started working at different startups. The first one was a small startup in San Francisco, and like a lot of other companies at the time, they were using Ruby on Rails. I started getting interested in functional programming and I started learning Clojure and I was starting to look for jobs with Clojure, and my boss at the time said, ‘Have you ever heard of this language Elixir?’
[Elixir] was written by Jose Valim, who is heavily involved in the Ruby on Rails community, and it was built on top of this language called Erlang, and Erlang has this prologue syntax which is very strange, at least compared to most modern programming languages. But the fact that it was familiar and easy to work with meant that it was an appealing language to start with, because it had the functional background and it had the approachable syntax of Ruby, so it was very easy to get into.
How did you get into True Anomaly and space? What was the next step of your journey?
It's been an interesting few years in terms of different jobs that I've had. Right after I started learning Elixir, I started working at Bleacher Report, and that was during this time when they were rewriting their platform in Elixir, and so that was a great experience because, yeah, Bleacher Report has millions of users. We sent out hundreds of millions of push notifications and content is delivered on-demand to the user. There’s lots of interesting technical challenges to scale there. And then after that I joined a startup called Subspace, and the goal of that startup was to have a way to see a global network. Didn't quite pan out, but my boss for part of the time there was a guy named Dan. He was VP of software engineering at SpaceX, and so we talked about space quite a bit. And then he was an advisor for True Anomaly, and then he said, ‘Hey, this could be interesting.’ And so, Evan the CEO at True Anomaly and I had a first conversation and then everything went well from there and then I joined.
When it comes to space, I imagine there’s a steep learning curve, especially for people who aren’t coming from an aeronautical background.
It’s been a higher learning curve than other jobs that I've been a part of, just because there’s so much to understand, not the least of which are the number of acronyms that are used in both the space domain and the government domains. But we tried to structure the work in such a way that we put people in a slightly uncomfortable position. Not [thrown into] the deep end without any support, but there's a little bit. You have this understanding from your previous role; therefore, we hired you and so now we’re gonna give you this little bit of this part, or this feature that we’re going to build, so you're going to start to learn and get an intuition for some of these things that you will be building, because again, especially on the software side—I think this is less so on the hardware side, on the spacecraft side, because you have to have the building knowledge in order to be successful—but from the software side, if you can sort of abstract away the details of what you're doing—because we're just basically we're building APIs to connect things to send data back and forth—if you have a good understanding of those connections, you can build on the rest of the space on the knowledge that you need over time.
It sounds like a complex engineering culture. How do you create a culture where you’re moving at a certain speed, within these narrow tolerances, and you’re getting everything done?
I think two big important things are: one, don't be afraid to say how you feel; we need to be expressive. Two is a culture of saying ‘no,’ in the sense that we have very ambitious goals, and we need to say ‘no’ to stay on the narrow path we need to be successful. Because we can spend any number of hours or days or weeks improving this or that part of the system that isn’t strictly speaking necessary for our goals. We have many years to build up this system and to build out the way we want it to be. And the way that you do that is by bringing the right people in the room talking about something, and then ultimately say, ‘No, I can't do this because if I do this, then we can't do that.’ And part of that is we’ve grown quite a lot over the last year, but again, given the wide breadth of things that we want to do, we're still a small company and so we need to be very rigorous and analytical about the things that we do and why we do them and when, so that we can continue to be a successful company.
