3 post(s) tagged with "life"

View All Tags

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.

alt text

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.

Interested in working with Elise and the rest of the Commure team? Check out open roles or email Elise to learn more.

Read more
/ 1 min read

Software Engineer Pascal Brandt on How Commure is Hacking Health Care

As the first employee of a global health NGO working in Africa and Asia, Pascal Brandt learned directly how tech innovation can be a game-changer for doctors and their patients. Now, he and his teammates at Commure are giving other developers a platform to create groundbreaking tools and help transform health care. Below, he explains why he joined Commure, what sets the company apart from other startups in the space, and what he values in new team members.

alt text

What does Commure do?

We’re building a platform to help developers more easily create health care apps. We do this by offering a nice API layer to work within and handling all the legacy integrations. Right now, doctors spend a lot of time fighting technology instead of helping patients, in part because most hospital records systems are built to accommodate billing departments rather than health care providers. Developers who want to help fix that are often blocked because the data they need is siloed in individual hospitals. Our team speaks both languages — health care and tech — so we can help engineers and entrepreneurs build better tools, which will ultimately make health care work better for everyone.

What were you doing before Commure?

I spent a couple of years as an engineer building backend systems for a big financial company in South Africa, where I’m from. After that experience, I knew I was not going to be happy unless I worked on a problem I felt was important. So I took a job as the first employee of an NGO that did donor-funded global health projects. We built and installed open-source tools for hospitals and clinics all over sub-Saharan Africa and part of Asia. It was really rewarding work, and it taught me a lot about how doctors think and what they need.

“Our team speaks both languages — health care and tech — so we can help engineers and entrepreneurs build better tools.”

Eventually, I decided to come to the U.S. to study Biomedical and Health Informatics, which is like a crossover between computer science and medicine. While I was waiting to start my Ph.D. program, I participated in Stripe’s open-source retreat, which basically pays engineers to work on projects that Stripe thinks are important. I developed an open-source system for electronic health records. Then John Collison, one of Stripe’s founders, put me in touch with Diede, who was about to leave their team to start Commure.

Why did you want to join the team?

I’d been in health care for 10 years at that point, and I’d seen doctors getting burned out and depressed. They got into medicine because they loved to care for patients, but they were spending hours in front of computers dealing with various compliance requirements. It was kind of a nightmare. I knew Commure could have a positive impact. I wanted to work on something meaningful while I got my Ph.D., something closer to my experience at the NGO, versus working on some new social media app that encourages people to spend more time on their phones.

I could also tell Diede not only understood the problem well, but had surrounded himself with co-founders and advisors and a team who understood it, too. These were people who had been in the health care industry and cared deeply about the problem Commure was solving. We have two doctors on the team, for example. They help us understand providers’ workflows so we can build the tools to match. We also have hospital and health care partners advising us who will be the first to use Commure. That they believe what we’re doing is worthwhile was a big part of the reason I decided to join. They understood the space and said, “Oh, what you’re building is exactly what we need.”

What sets Commure apart from other companies in this space?

A lot of startups pivot and completely change their plan, but we’ve stayed pretty focused on the same product scope and deliverables over time. Our initial vision has been validated, and I think that’s a really good sign. We also have a longer-term strategy than most companies. Selling an app to a hospital can take years, and we knew that up front. We’re well-funded, and we’re looking at least 10 years out. We don’t have to worry about achieving crazy growth, because it’s not part of our strategy.

I think our other big strength is the diversity and commitment of the people on our team. We have doctors and CS grads, but we also have people from boot camps who used to be chefs and accountants. That variety of perspectives is valuable. And everyone here is empathetic and extremely dedicated. We’re all driven to improve the lives of patients and the people who care for them.

Tell us about the challenges you’re facing.

There’s a pace differential that can be frustrating between a startup environment like ours and an established health care system. Hospital CIOs and CMIOs are often conservative about change, whereas we want to move more quickly. But for Diede, that’s a fun challenge. He enjoys convincing people that there’s a better way.

“We’re well-funded, and we’re looking at least 10 years out. We don’t have to worry about achieving crazy growth, because it’s not part of our strategy.”

What’s fun for me is the nitty-gritty technical problems we get to solve. There are lots of interesting deployment and DevOps challenges, because we’re balancing the need to make data access simple for developers with the need to make the platform ultra-secure. For example, you have to be able to record and audit every event, like when someone logs in or updates a patient’s record. But at the same time, you can’t store protected health information on public servers. Plus, health care privacy regulations like HIPAA are notoriously vague and inconsistent. So we implement solutions that go far beyond their minimum requirements, to make sure patients’ information is safe.

Data exchange is another interesting engineering problem, because we’re integrating all these non-standardized legacy APIs. It’s way more complicated than simple data-mapping, because medicine itself is super complicated. You have tens of thousands of codes that hospitals use to charge insurers, and different health systems often interpret the same codes in different ways. That makes mapping between hospitals really difficult, but figuring it out is how we’ll make it possible for engineers to build new apps.

What do you look for in new hires?

Everyone who joins should be willing to at least be exposed to every part of the system. That may change as we scale, but right now I think it’s important for our engineers to have the entire context before they start working on a specific piece. That said, people do gravitate toward individual areas of interest, and we do have clearly defined buckets of work. There’s a lot of UI and UX to be done, for example. Or a systems engineer can focus on our core API server, which we’re writing in Rust. Rust is a relatively new language and comes with quite a learning curve. But it’s increasingly popular and pretty sweet, so we decided it was worth the investment.

We also want people who can collaborate with a variety of stakeholders in health care and in tech. You have to be able to talk with a doctor, an IT person, and someone in billing, and then synthesize that information to help build something that will work for the entire hospital system. You have to empathize with the developers who will build on top of our platform, and understand the frustration they feel in the current environment when they can’t get answers to basic questions. Our job is to understand both worlds and be the bridge between them.

Interested in working with Pascal and the rest of the Commure team? Check out open roles or email Pascal to learn more.

Read more
/ 1 min read

Software Engineer Esteban Küber on the Challenges and Opportunities of Rust and Commure

Many software engineers pick up new programming languages when they start a new job. But for Esteban Küber, learning Rust first is what led him to Commure. Below, he explains why he decided to join the company, weighs the pros and cons of writing the platform in a relatively young language, and shares details on the team’s upcoming projects.

alt text

What problem does Commure solve?

Like most legacy industries, health care is bogged down by entrenched processes. There’s a gap between what companies see as state-of-the-art and the actual state of the art, and there are a lot of regulatory requirements. That adds up to an extremely high barrier to entry for someone who wants to innovate in this space. Commure takes care of all the data integration and offers a simple, elegant API, which allows developers to focus on what they want to build.

But we’re also solving a problem on the provider side, where we facilitate access to their data. The people who typically purchase health care software aren’t the ones who actually use it, which means it’s optimized for reporting rather than to help doctors care for their patients. Doctors often have to enter the same information multiple times into multiple systems, for example, which is a waste of time and increases the risk of errors. Part of what we’re doing is minimizing that clerical work and making it easier for doctors to do their jobs.

What were you doing before Commure, and why did you decide to join the team?

Prior to Commure, I was at Twitter for five years, working on the infrastructure side. I built tools for other developers to use, including administrative tools for a key-value distributed database called Manhattan, and I generally tried to keep people from getting paged at 2 a.m. Before that I spent several years as a contractor for Google in Buenos Aires. I found Commure through the Rust community, which I got involved with a couple of years ago. I’d been hearing about Rust for a while, and when 1.0 came out in 2015, I decided it was as good a time as any to learn. It was painful at first — I didn’t get anywhere. But I picked it up again a few months later, and that time I started contributing right away.

“We’re building something from scratch, which is exciting, but we also know exactly how it’s going to help our customers.”

When Diede and Eugene told me about the platform they were building, my first reaction was, “You guys are insane.” I knew health care had a lot of entrenched players, and the problem they wanted to solve seemed insurmountable. But as they explained more, I realized they weren’t just picking a random industry to try to disrupt, like a lot of startups do. The people on this team have real experience in health care, and so do the advisers. They were making very informed decisions about how to approach the product. I was also interested in moving to a startup after spending so much time at larger companies. In a big organization, it’s easy to get in the habit of seeing issues as someone else’s problem, and I liked the idea of being on a team where everyone is passionate about finding solutions. What set Commure apart from other small companies, though, was the clear vision and objective. We’re building something from scratch, which is exciting, but we also know exactly how it’s going to help our customers. It’s very different from most startups in the Valley.

Tell us more about why Commure uses Rust.

The founders made a bet on Rust, but it was an informed, strategic bet. The risks are obvious — it’s a very young language, so it doesn’t have the same breadth or depth of resources as Java or Python or Ruby. Rust does have good bindings to C, so you can get some existing libraries that way, but the lack of existing resources is still a potential downside. And while the compiler itself is very solid, the surrounding tooling is less polished than what you might be used to with something like Visual Studio or Xcode.

But there are elements of Rust that really appealed to us. It basically applies 30 years of industry best practices and collective wisdom to a very low-level programming language. You’re writing code that could be at home in a very high-level language like Scala, but without any of the performance issues created by interpreting that language on a virtual machine. There’s also an emphasis on speed and ergonomics — and on accuracy, which will help us sleep at night when our platform is running in hospitals.

The other big benefit is the Rust community, which is really welcoming and open. It’s easy to get help with even the most difficult problems, and people are very passionate, which shows in the technologies they’re developing. Some of the software we write at Commure is eventually going to be open-sourced, because we’ve gained so much from this community and we want to be able to give back.

Can you share a recent project you’ve enjoyed?

In my first couple of months, I’ve spent the most time on the authorization layer, which is obviously critical for a health care platform. There are specific legal requirements around what we do for authentication and login. One of my projects in that space was implementing a new library to parse and evaluate XACML policies. XACML has been battle-tested in multiple industries, but it’s not common in startups because it relies on XML. It’s more of an enterprise technology, almost like a very small programming language. It was fun to work on, and I’m pretty happy with the results — we’re passing 430 of the 450 conformance tests, including all of the ones that are relevant for us. I think it’s going to be important for Commure going forward.

What kinds of challenges can a new Commure team member expect?

Because I hadn’t worked in health care before, one challenge for me was getting acquainted with the FHIR, or Fast Healthcare Interoperability Resources, protocol. I spent quite a bit of time reading up, to make sure I had the context I needed to understand its technical decisions and features, so I could properly implement it.

For someone new to Rust, I think it would also be difficult to lose the baggage of your experience with higher-level languages. There are patterns you can apply in Python or Java that flat-out won’t work in Rust. What’s really happening is that Rust is revealing cases where that pattern won’t work; it was just silent before. Still, that can be frustrating at first.

“We have a high-level roadmap, and we know which four or five things need to happen in the next month or two. From there, it’s just a matter of who’s most interested in what.”

As far as the specific projects you can work on here, we’re at the stage right now where we have the basic building blocks in place, and there’s a lot of variety in terms of what we do next and where you can focus. We have frontend work to do, performance-intensive code and libraries to write, and metrics to get in place to make sure our platform is easy to monitor and maintains a high level of uptime. We want it to be robust, from how we handle changing configuration files in a running service to how we deal with our storage layer. We do think it’s important for team members to get to know all the different parts of the platform, but there’s a lot of flexibility in terms of individual projects. We have a high-level roadmap, and we know which four or five things need to happen in the next month or two. From there, it’s just a matter of who’s most interested in what.

Interested in working with Esteban and the rest of the Commure team? Check out open roles or email Esteban to learn more.

Read more
/ 1 min read