An interview with Ellen Chisa, on programming in prod

I spend my time working with the team, writing code in Dark, and engaging with our community. When I’m not doing that, I love to read and cook.

What does test and learn mean to you?

Test and learn is all about experimenting. You just want to be able to try something out, see if it works, and if it doesn’t try something new. It’s really core to what I do at Dark. If you can have an API up in 5 minutes and try it, that saves all the hassle of setting up a complex toolchain to build it, only to realize you didn’t need that API at all.

Your team built Dark to remove accidental complexity from coding. Can you explain what that means and how your team arrived at solving this problem?

I studied engineering, but always found myself frustrated by the amount of time I spent setting up tooling, and the amount of code I wrote that was just boilerplate. Developers today are only able to spend a small part of their time on actually delivering new value to users. After feeling it myself, and seeing it in all of my product jobs, I decided it was a problem worth solving. Dark is a programming language that allows you to focus on just code, rather than everything else.

A hello world app created with Dark

What metrics do you use to measure the quality of the software you are building?

I love Michael Dearing’s emphasis of modeling company metrics off of “Drake’s Equation” – choosing a set of metrics that takes into account all levers you can change to hit your end goal. At Dark, we’re succeeding when developers are able to build, ship, and operate their applications. 

Your talk is about programming in production. Can you tell us what “programming in production” means and how it differs from “testing in production”?

The fact that we talk about “in production” highlights how different our local dev environments are from the end service. Building locally can add a lot of risk. The more work you do, the more has changed, and the more apt something is to go wrong (no matter how much you try to check it). That’s why you’re always testing in production, no matter what you try to do in advance. Programming in production means you write code on the infrastructure it will run on. It also places an emphasis on making those incremental changes. The smaller a change is, the less apt it is to cause an issue. Programming in production doesn’t mean it immediately goes to users. You might be on production infrastructure with a feature flag that says “only run this code to me” and then gradually work from there.

Hear from Ellen and the rest of our speakers at Test & Learn on May 20. Register here: https://www.optimizely.com/test-and-learn/