From Professional Chef to Software Engineer: Elise Olivares on Starting Fresh at Commure
--
Just a few years ago, Elise Olivares never imagined she’d be working in tech. She’d spent her career in kitchens — working as a manager and a freelance chef — and didn’t even own a computer. Then a stint at an online coding school opened the door to a role at Commure. Below, Elise explains what stood out about the company among the 400(!) she applied to, what it’s been like to adjust to a completely new work environment, and how she’s turning challenges into new projects.
What is Commure, and what’s your role on the team?
Our platform is designed to break down barriers to developing health care software — we want to enable innovations that will help doctors give better, more affordable care to their patients. You can think of Commure as the tech that lets developers quickly build and deploy health-related apps for use in hospitals. The backend is written in Rust, and the frontend, which is basically an access portal for administrators, is written in React and JavaScript.
We’re also developing some individual apps that will run on our platform, and I’m working on the first of those right now. It will help doctors with note-taking, and it will also serve as a model to help people understand how Commure works. The note-taking app has mobile and desktop versions, and I’m building the frontend side for desktop.
What were you doing before Commure, and why did you join?
This is my first job as an engineer; I was a chef two years ago. I loved cooking, but I was physically exhausted at the end of every day, and I wasn’t getting where I needed to be financially, especially as a single mom. I’d done some programming in middle school, and I was good at it — I even gave a presentation on object-oriented programming at a Sun Microsystems conference, back when that was a thing — but then I had a negative experience with a teacher that kind of steered me away from the field. I studied neuroscience in college, but I never did anything with it, and I never considered a career in engineering. Then boot camps started to get more popular, and a few years ago I decided to check out Launch School. I took the pre-course on my smartphone, because I hadn’t even owned a computer in years! But I ended up enrolling. After graduation, I think I applied to more than 400 companies. I’d been prepared for the job hunt, and I knew it was a numbers game.
“In any other job I’ve had, I would have hated the idea of still being there in 10 years. Here, it was exciting.”
I found Commure on Hacker News, and I liked that it was small and new. I wanted to be somewhere where I could make a real impact. I also liked the idea of working on something that matters, helping doctors care for their patients. My biggest concern with a company of this size was job security, but Commure is unusual in that we’re in a very good position financially. And then my first phone call with the CTO was immediately the most comfortable conversation of any of the interviews I had, and I could tell on my first visit to the office this was a more mature, serious kind of startup. I love ping-pong and beer as much as the next person, but I was definitely turned off by companies that seemed to see those perks as their major selling points. We have fun, but it was clear right away that people are here to work. So I had a good feeling about it from the start.
Tell us about the transition from being a chef to being an engineer.
I had to slow myself down a bit at first. The first time I got sick, I kept trying to come in and they’d have to send me home. After that, I sat down with our CEO, Diede, and explained that in the world I was coming from, if you’re not running to the bathroom every five minutes, you’d better be at work — and if you don’t show up, you might get fired. Being paid to stay home or take a vacation was new to me. But he told me, “I don’t want you burning out in a year. I want you happy and healthy for the next decade.” In any other job I’ve had, I would have hated the idea of still being there in 10 years. Here, it was exciting. It made me think about how many people we’ll have on the team then, and how much I’ll have learned.
I’ve had to accept that I’m a different kind of engineer. I haven’t been coding since I was 11 like a lot of my colleagues. But I feel like my bosses see my nontraditional background as an asset rather than a liability. Not only can I grow into a better engineer here, but I’m valued for all the other things I bring to the table.
What other challenges do you face at Commure?
Learning can be uncomfortable. That state of “not knowing” is tough for me, and I’m working on how to separate my intellectual frustration from my emotional reaction. It’s been especially challenging because I’ve always learned in more structured environments — and like most young startups, we don’t have a lot of formal mentorship. But Eugene and Diede have been so receptive to feedback about that. I brought a whole list of ideas to our one-on-ones, and they were genuinely interested in finding ways to improve. Diede canceled two calls while we were meeting so we could keep talking, and Eugene kept pulling me aside the rest of that week, because he’d been thinking and had more questions. They really made me feel heard, and we’re already implementing some of my ideas.
“You always see people gathered around whiteboards all over the office having great, spontaneous conversations. Discussion is definitely encouraged.”
One example is a change to the way we select people for code reviews. I wanted to make sure we don’t end up with a divide between more- and less-experienced members of our team as we grow. So I suggested I set up a script that allows us to select reviewers, like we do now, but also randomly assigns one team member to each review. I think it will encourage people to read parts of the code they might not be familiar with, and to get more comfortable offering feedback. It will also be an opportunity for me to get more experience with Rust. I’ve learned a little, but frontend work has been my focus so far, and I think it’s time for me to branch out.
What’s the process for choosing new projects to work on?
We’re developing processes as we go, but we try not to have too many. We want to focus on what we actually need, not just enforce process arbitrarily. Our sprint board keeps track of what everyone is working on for the week, but there’s a lot of research and experimentation built in. Some tickets are small and easy to solve. Others, like “explore new database options,” could take weeks.
I got to experiment recently with a new language, Reason ML, when we started working on the note-taking app. It’s based on OCaml, but it’s compatible with React, so it can tie into what we already have. I took a few days to do research and learn enough to write a few hundred lines of code, a basic skeleton of the app. Then I presented it to the team. We talked through the pros and cons and decided to stick with React for now, but we may use Reason ML in the future, and it was a fun experiment. That’s very much the culture here. You always see people gathered around whiteboards all over the office having great, spontaneous conversations. Discussion is definitely encouraged.
