• A Sustainable Mobile Testing Strategy

    Every engineer I’ve worked with has had strong opinions about testing. And regardless of their take, there’s one recurring theme: setting up the infrastructure around these tests is hard.

  • First Person: Whither the Developer Veil?

    At my last workplace, it was uncommon for engineers to communicate with our clients. We collectively referred to this concept as the “developer veil”. As an engineer, I could hide behind an imaginary wall: all I had to do was write code and perform the tasks expected of me, and I didn’t need to worry about having to talk to anyone outside of our organization: an introvert’s dream! On the surface, this actually makes a lot of sense. Developer hours are expensive, and if you bog engineers down with user meetings, long email chains, or taking phone calls, they’ll never actually have time to write code for you. This is Scrum 101: get a PM who handles all customer communication and let your person who writes code write code.

  • First Person: On Creating a Desirable Workplace

    I believe a workplace is only as attractive as its culture. If the remote workplace is a city, then the workplace culture is its zoning laws.

  • Why We Use Models in Python

    If you’ve ever written a server-side service before, you’ve probably realized you have to repeat certain patterns a lot. On every route, maybe you need to pull a user ID or validate that records exist, and return a specific response if any of that fails.

  • Building a Remote Work Culture

    Since 2020, working remotely has become the norm for many companies, and Proton is not an exception. Over the past year and a half, we’ve successfully transitioned from a small on-site startup into a global remote company. Along the way we’ve had to overcome many challenges.

  • Accelerating Integrations with Workato

    In the distribution business we are constantly encountering different clients, each with different needs. Modern companies of all kinds have multiple systems where they produce and store data they could use to improve their business.

  • Your First 30 Days at Proton

    Candidates often ask what the first weeks will be like at Proton. And that’s understandable. I can imagine how a company’s onboarding can seem like a black box. Every workplace has its own way of operating, educating and orienting new folks. Plus, that period is critical for someone going from a novice to a full contributor. The good news is we too want you to succeed and get up to speed in the most transparent way possible, so with this in mind, I’ll take you through the key milestones of what joining the Proton team looks like.

  • React Components: Simplifying with Composition

    One of my first projects after coming to Proton was to create a reusable card component. A relatively simple task, but with one catch. The card needed to dynamically hide certain UI elements based on the type of data provided. Not a problem, I thought: you can conditionally render those elements as needed. Unfortunately, this approach did not stand the test of time. As we added more card variations, the component got bigger and bigger, and more and more difficult to maintain and extend.

  • Patching Security Vulnerabilities with Yarn Dependency Resolution

    We recently ran into a minor problem that got me frustrated. Everything we run happens inside containers built with Docker, including our frontend. For security, we use Aqua’s Trivy tool to scan any outgoing containers before they’re pushed to our repository, where they could then be deployed. Typically, these are easy enough to fix. We read the scan report, up the version with a patch, update our package configuration, and the build passes the security scan. This time, though, I ran into a problem with our frontend that wasn’t so easy to resolve.

  • Acing the Proton Interview

    When I joined Proton I didn’t anticipate spending a lot of time focusing on hiring other engineers. Six months in, I’ve managed a few different job postings, and I feel like I’ve learned a lot from being on both sides of the interview. Given the number of questions we get about our interviews, I thought I’d share. Initially one of those lessons was a revitalized sense of impostor syndrome as I came to see how high a standard we hold our interviewees to in order to proceed; however upon closer inspection I’ve come to the conclusion that a lot of talented individuals have the skills to succeed, but may be failing at communicating them.

  • A Data Journey

    At Proton, data are our bread and butter. The core of using Proton for our distribution clients is to allow us to make sense of their data. As we grow with both new clients and exciting new features for current clients, we gain access to more data from various sources. With this, it is imperative that we have an established process of receiving, processing and storing the data so that it can power our systems and AI models.

  • First Person: On My First Day, the Company Went All-Remote

    Before I joined Proton, I was someway into a PhD in Biomedical Engineering. After many nights in the lab, I had realized this path wasn’t for me. When I got a call from Benj, our CEO, one evening and he told me I was being offered the data scientist position at Proton, I didn’t have to think twice. I took one week, which also coincided with spring break at my university, to figure out the logistics of leaving a PhD program and set my start date for the coming Monday. Little did I know that day would also be in the middle of a global pandemic, and the company’s very first day of work from home.

  • Scaling Kubernetes Configuration with Jsonnet and ArgoCD

    If you’ve worked with Kubernetes, odds are you’ve seen YAML manifest files that can be thousands of lines long. At Proton, we’re heavy Kubernetes users, and at one point relied on static resource definitions for all of our services. Because we don’t change these often — and never as part of a regular deployment cycle — it was clear these long YAML files would easily become outdated.

  • We Hire Differently

    While I know this is our engineering blog, we get many questions about our hiring process, especially when it comes to technical roles. I thought it would be good to write everything down in one place and share a bit of philosophy in the process.

subscribe via RSS