An Inside Look: Laura Frank, senior engineer at Codeship

Laura Frank is a senior engineer here at Codeship and the first Codeship employee to be interviewed in our Inside Look series. This week, we had the chance to sit down with Laura to talk about why she feels a responsibility to speak about tech, why she's a huge advocate for Docker, and why technologists have an obligation to society.

An Inside Look with Codeship is a regular series providing an insider’s perspective on the tech industry. Each session, we chat with some of the most exciting voices in tech and ask them where they’ve been, where they’re going, and what we could all be doing together. You can read all Inside Look interviews here.

I joined Codeship a little over a month ago. I met some of the team at DockerCon and was really impressed with the focus they put on the quality of their work and creating a collaborative environment for developers.

I’ve got a few speaking events lined up for the next month, most notably DockerCon EU, which I’m incredibly humbled and excited to be speaking at. Aside from speaking, I really value the time when I can get heads-down on both the web interface as well as the new infrastructure that uses Docker. Right now we’re working on some massive improvements to the way resources for our builds are allocated. Codeship is working on some really hard problems, so it’s a really challenging environment to be in.

I love working on tools for other developers -- in fact, for the last five years, that’s all I’ve worked on -- so it seemed like a natural fit for me.

I’ve been working with Docker for about two years, since the project was pretty new. Codeship is heading in a really great direction with the new Docker infrastructure, but of course there are pain points and things we could do better. Docker and the entire suite of Docker-supporting tools are changing so quickly that it’s a really unique challenge to choose the right thing at the right time. You basically have to make a bet that your implementation is going to grow as the supporting ecosystem grows and as the size of Codeship’s userbase increases.

Some people find this insanely frustrating, but I love the opportunity to learn so much new stuff all the time. And in terms of little bugs that I notice when I use Codeship for my own projects -- it’s so gratifying to just be able to file a ticket or submit a PR with the fix.

I’m really impressed by the way Codeship views our team as being humans first and employees second. Of course, we have a product to ship and customers to keep happy, but the founders, along with our engineering manager, really do believe that we can get more work done -- better work done -- if we take care of ourselves first.

This goes beyond encouraging us to be healthy, exercise, and sleep enough; it also applies to fostering a development culture that houses truly open and respectful discussions. Within my first week, I was surprised at how seriously everyone’s opinion mattered and how all of the engineers truly do have a voice when it comes to making technical decisions.

I’m really struck by the way Codeship avoids what I sometimes call the ‘implementation by default’ problem. All of the technical choices we make are the result of productive conversation and debate, not just because the loudest person on the team made a suggestion and people were too busy or apathetic to compare the other options. Making deliberate, team-backed decisions about the way your software grows can really help avoid a lot of technical debt, and it also increases the sense of shared ownership over the codebase.

I will repeat over and over that Docker lets you spend less time provisioning, rebooting, and fighting with dependencies, and more time building what you want. Combined with other devops practices like CI, using Docker can greatly reduce the amount of time, space, and money your application needs, even types of applications that we consider to be ‘highly available’ (meaning optimal performance even during huge spikes in traffic).

For developers, using Docker in your development workflow can completely change the way you work. Docker, especially paired with Docker Compose, makes firing up development and testing environments really easy.

My uncle was (and still is) a sysadmin, and I looked up to him a lot when I was younger. I was pretty dorky and awkward as a child (surprise!) and didn’t have a lot of friends. I went to science camp; typical nerd stuff. My uncle made it seem cool to be smart and dorky, and I remember when my family got our first computer with WordPerfect -- and my uncle handed me a stack of disks with DOS games on them and basically just told me to figure it out.

From there I spent a lot of time tinkering, did some LOGO, taught myself HTML and later CSS, then ActionScript and JavaScript, and eventually Ruby and Golang, which is what a lot of Codeship’s software is written in. Most of the work I do for Codeship all stems from on-the-job experience and from personal curiosity.

I’m about two semesters away from finishing my controller’s in computer science, which has definitely taught me a lot about how to design software. My bachelor’s degree is in history and communication arts, so working on a controller’s has helped me fill in a lot of gaps that I missed being self-taught.

I had an engineering manager at HP Cloud that pushed me really hard. I think it might be partly because I was afraid of him but probably also that he was an ex-Marine. I grew up in a huge military family, so to say the least, discipline and getting my work done correctly and punctually is something I’ve practiced from a very young age. Having a manager who also reinforced those principles, even as an adult, was invaluable.

Being a developer is intensely challenging, and it’s really easy to give up. But you just have to struggle through it and keep going, keep learning, keep making mistakes. It gets easier. I’ve also had the pleasure of working with some amazingly talented coworkers, and I learned a lot from them through pair programming. I would encourage even the most senior engineers to program with someone, even if it seems like a waste of time at first blush. Watching the way someone else solves a complex problem is really useful.

I think it’s common for engineers to become very specialized in a certain area, rather than knowing a little bit about a lot of stuff across the board. I think the term ‘generalist’ can be read with the same negativity as ‘jack of all trades; controller of none.’

I started as a front-end developer and wanted to get lower and lower on the stack as my career progressed. I still carry a strong focus on user experience with me no matter what I’m working on, because software, whether a CLI, API, or web interface, should be intuitive and easy to use. My varied background is especially helpful when it comes to things like customer success and support and when I’m helping out other developers. I can help you figure out why your Docker image isn’t building properly, but I can also help you fix your responsive CSS.

I like jumping on different areas of an application because there’s always new stuff to learn, and I think understanding applications from front to back really helps you make the best choices when implementing new features.

In a past life, before I switched to development full-time, I was an elementary school teacher. When I look at really complex technical concepts, it’s almost an automatic reaction to analyze how someone would learn it and then to construct a sort of curriculum.

It’s all about planning backward and then having multiple ways that someone could understand the content you’re delivering. I find speaking at conferences and meetups to be really rewarding and almost an obligation. I learned so much from so many people, and it’s the least I can do to teach what I know to others as well.

I use my technology powers for good (not evil) by volunteering as a technical consultant for 826CHI, a literacy nonprofit that provides services to students in Chicago (where I lived for many years). I think my official title is Technology Princess, but maybe someday I’ll be coronated as queen.

It’s really rewarding to see how even a couple hours a month of my technical expertise can have such a profound impact on community services, especially when it comes to connecting students, parents, and teachers with the information they need via 826CHI’s site. I think it’s really important to reach outside the ‘tech bubble’ that we often find ourselves nestled into and work on something whose audience isn’t just other technologists.

It’s pretty simple for me: if I make someone’s day suck less. I’m not trying to save the world through software or make sweeping changes to best practices as we know them today. But if someone uses a tool that I’ve worked on and says, “Wow, that used to suck, but this tool made it way better,” that’s a mark in the win column for me.

I think it’s a lot of the usual stuff -- people in technology are pretty privileged, and even though I’m a woman in tech, I recognize that I have an immense amount of privilege to have been able to get this far in my career (access to education, employment opportunities, mentors).

I think that people who write software have a tremendous responsibility. Software controls so much of our lives. We communicate with technology. We use it for education, healthcare, and even to drive cars and make ice come out of my refrigerator. I have a tremendous responsibility as someone who works on software to make sure that I’m designing systems that are secure, well-performing, inclusive, and easy to use.

But sometimes problems don’t keep me up -- I have coding nightmares a lot. I’ll be trapped in some control flow statement, or in HTML, and can only escape if I physically move the blocks around. It’s so amazing how many times I’ve come to the correct conclusion in my dreams, awoken in a cold sweat, and quickly typed something out.

I wish that someone had emphasized that it’s okay to fail. Especially in the USA, kids are taught that failure is bad, and we have things like participation ribbons so everyone feels like they won.

The truth is that engineering is hard. You’re going to make mistakes. You’ll introduce a bug that will have PagerDuty light up at 3:00 a.m. It’s okay. You need to make mistakes so you can learn from them. Most of the reason why I got really interested in computers as a child was because I saw it as a mechanism for solving problems, but I didn’t always have the right answer. Even as an experienced developer, I still screw up and do the wrong thing.

But all of those little failures eventually lead to successes. Tinker and break stuff; it’s the only way you’ll learn how to build something the right way.