The Interview with Armin Ronacher, the Creator of Flask
Armin Ronacher is a contributor to the Python software ecosystem. He has created such widely used projects as Flask and Jinja2. Over the last 10 years, he had worked on various open-source and commercial projects, and we were honoured to talk with him about his life and career! During the interview, Armin talks about his work at Sentry, shares his thoughts on handling errors, speaks about the differences between Rust and Python, the “gradual typing” approach, and shares a couple of secrets of his work-life balance.
Evrone: Your job title is Director of Engineering. What does your everyday work seem like at Sentry?
Armin: From a scheduling point of view my day is typically split into two parts. I work from 9 to around 3 pm/4 pm when I pick up the kids from daycare. Then I have a second slot late in the evening/night for meetings across timezones. That segmentation works well for me because that way I have time with the kids when it’s light outside. In terms of what I do in many ways, my role is to make sure that all the people that work with me are aligned on the things that matter. This is particularly important because Sentry is a company with multiple locations across timezones. Really it’s a mix of hiring, solving people problems, assisting in system architecture, shaping or communicating product vision to the actual projects and then a lot of assisting with odd engineering issues.
Evrone: The popular “full-stack” approach promotes developers to write both frontend and backend code. As a developer who knows plenty of programming languages and technology stacks, do you approve such a practice?
Armin: It’s a complex question because what’s full stack on a complex project really? Sure for a trivial application it only really consists of a CRUD backend and some React frontend, and you can comprehend the entire thing. But that process does not at all work for us, because Sentry is a much more complex endeavor. The simplified description of what Sentry is, is a service to take crash and performance reports and show them to the user. However, from a technical perspective Sentry is a very complex processing pipeline with multiple databases, multiple services to process the reports before they are persisted. The idea that a single individual could be tasked with working on all these components to ship a feature is not just unrealistic, it’s also very inefficient. So my answer to if I approve on this practice would very much depend on the type of project.
Head over to our website to read the full interview.
