Software Engineers on a Robot Project? Yes!
Who Builds Robots Series
Editor’s note: For this post on who builds robots, we’ve got two of our software engineers speaking up — Lauren Baker and Erin Connolly. Robots are not just about hardware, electrical, mechanical, and electronic components. They’re about the software (and firmware) that takes all the hardware and sensors and makes them smart and usable. If you’re into coding, robots are a software platform that’s only going to get bigger.
Both engineers are new to the field. Each got their start in software development through a coding apprenticeship offered by a Boulder software company, Techtonic Group. It was there that they were each assigned contracts at Misty Robotics that turned into full-time roles.
Erin Connolly
I’m fairly new to programming, but I’m quite sure I’ll stick with it, because compared to other career paths I’ve tried, I really love it. I may have many hard lessons yet to learn, and those lessons may invalidate some of my beginner’s optimism, but these are the things that I love most about being a developer so far.
Building things is satisfying
When I was a kid, almost all the movies opened with some sort of breakfast machine malfunctioning. The lovable mad scientist had rigged up a series of chain reactions using household items — twine, a stray golf ball, the waffle iron, the hands on the alarm clock — to automate the process of making breakfast. According to convention, the toast always ended up burned, and the eggs landed on the dog’s face.
It never once occurred to me that I’d enjoy making a breakfast machine — or any machine for that matter — until I learned to code. The prospect of coding sounded like tedium. Then, I finally gave it a try and found that setting up little chain reactions to make things happen is not just incredibly satisfying — it’s addictive.
Heather Terenzio, the CEO of Techtonic Group, where I apprenticed as a developer, put it well. She started her career as a civil and environmental engineer and felt like she spent all day doing paperwork. When she gave software engineering a try, she loved it, because she was actually building something, and she could see the results of her work right away.
The time flies by
I once was a financial analyst. That would have been a nice enough career if it only lasted until 11am, at which point I always wanted to leave and make some progress on something. Anything. I couldn’t feel the excitement in just reporting numbers accurately. I got an MBA and learned CapEx and discounted cash flows, but to me, it always felt like someone else’s money and my wasted time.
When I was in sales, that did make the time pass quickly. Given a 1% conversion rate, there was never enough time in the day to build a list, make the calls, send the emails. In sales, the equation is clear: Time + Effort = Success. The problem was with the future. I could see that I’d make money, but I wouldn’t have done anything other than just continue to chip away at that equation.
As a developer, I’ve never once looked at the clock and felt there were too many hours left in the day. In fact, I wish the day were 16 hours long — that way I could really learn everything I want to learn. I look at the years ahead, and I wonder how I’ll learn all of the things I want to know. And, as a developer, it feels very clear that Time + Effort = Progress.
It’s art, only easier
Reading a brilliant short story or seeing a great painting makes me feel like I want to create something that perfect. When someone takes the time to communicate something in an exquisite way, it makes me want to do the same thing. I’ve tried clearing my schedule and sitting down to create art, but I’ve never found a way to make progress. The ambiguousness of the task usually ends up destroying the creative impulse for me. What’ll the story be about? Who’ll read it? Would Photoshop® be a better medium than paint?
I was thrilled to discover that good code can be inspiring in the same way as good art. When you read it, you get a sense of the person who wrote it. You’re ingesting what someone has to say when they sit down and spend time quietly solving creative problems. A key difference for me, though, is that there’s no writer’s block. Let me be clear: it’s no easier to write good code than it is to write a good novel, but it’s somehow easier to get going. There’s always a defined problem to solve. And if you’re scared by the blank page, you can just copy somebody else’s code and start fiddling with it.
Lauren Baker
Unlike many of my colleagues at Misty, I don’t have decades of software or hardware experience under my belt. In fact, it’s just been a year since I made the leap from retail management to a career in software development.
With this rare opportunity, I have the unique perspective of what it’s like to work at a robot startup as a software newbie. I spend my days researching (either coding techniques for writing my own code or the Misty codebase when testing and preparing code for release), debugging (my code, other people’s code, hardware, and builds), and testing. Here are some things I’ve learned since beginning my journey.
It isn’t handed to you
“You’ve been in this industry for less than a year?” Yes. “And you got a job at a robotics company?” Yes. “Dang, you’re lucky!” Correct… But!
While it’s true that luck played a huge part in landing this opportunity, it doesn’t mean that I didn’t have to, and still have to, work hard to earn it. To be a beginner in software and to have no experience in hardware, proved to be a real challenge in my first months working at Misty.
For instance, I had to work hard to convert unfamiliar tech speak into my own vocabulary before even tackling a “user story”. I also realized that I’m not so much an auditory learner as a visual one. So, whenever we were in group situations where concepts and acronyms that I hadn’t heard of were talked about, it was a struggle for me to keep up. I learned to take in everything that I could during these times and try to convert these topics to pictures / diagrams in my mind, so they’d stick better. I’d also log unfamiliar vocabulary in my mind to look up later or dive into more thoroughly with my supervisor.
The retail crowd is different from the tech crowd
When getting into the tech industry, I didn’t believe that women and minorities were as under-represented as they are. The show “Silicon Valley” portrays this gender discrepancy in an extreme yet comical way. I assumed that much like everything else on this show, this under-representation of women was a caricature that didn’t accurately reflect reality. It turns out that, even at our company, where our leadership is making serious efforts to support diversity, the show’s portrayal is closer to reality than I thought. Do I believe that this discrepancy indicates sexism in the industry? No, at least not around here. Was it a culture shock for me? Heck, yes.
Admittedly, in the retail space, the gender proportions were often equally disproportionate, but in reverse. Still, I was used to knowing every detail of my coworker’s lives. I took pride in crafting the perfect insights into their personal relationships or giving my well-thought-out opinion of what color couch they should get. This doesn’t quite work with the tech crowd. They’re more interested in making witty remarks and chatting about all things tech, and less interested in personal life talk.
Software is a team sport
To those of you who think that a career in software is an answer to your prayers of a life of solitude, safe from messy humans (gross, right?), you’re sorely mistaken. When working on something like a robot, you need a whole team working together to produce a single product. A mission can’t be successful without all its moving parts working together.
This is especially true for something as complex as a robot. Since one person can’t know everything, he or she depends on others to gain the needed information to complete his / her tasks. In addition, many problems such as architectural decisions are too big to be made by one person and require collaboration. Therefore, teamwork and constant communication across teams is very necessary to be successful.
