What is the state of Alan’s Developer Experience and what we are working on?

Photo by Shubham Dhage on Unsplash

At Alan, we cherish the autonomy of our engineers, and want them to be empowered to craft, deploy, and test new features or products independently. This autonomy is crucial in our decentralized setup, ensuring every engineer can deploy new services and monitors and set up tools swiftly and confidently.

To support this, a part of our engineering community (which I’m part of) is dedicated to enhancing the Developer eXperience (DX). Our mission is to construct transversal tools and processes that minimize friction and maximize confidence in development and maintenance tasks.

Curious about our 2023 and half of 2024 achievements and our vision for the rest of 2024? Let’s dive in!

Sneak peak of 2023 and H1 of 2024

Expo migration

Navigating the complexities of native code in React Native application development has traditionally been a daunting task. It often led to build issues and consumed a significant amount of our engineering time and resources. This diverted our focus from creating value and innovations for our users and made the development process less efficient and more cumbersome.

To address these challenges, we transitioned to using Expo, a robust framework and platform for React Native. This move has streamlined our development process by simplifying many of the intricacies associated with native code. As a result, our engineering efficiency has seen a significant boost. The team can now concentrate on delivering value and enhancing user experience, rather than getting bogged down by build issues. For more details on this transition and its benefits, we have dedicated an entire article that delves deeper into the topic.

Code offenses tracking

Maintaining a clean and efficient codebase can be challenging, with code offenses such as violations of coding standards and best practices leading to technical debt and maintenance difficulties.

We’ve implemented measures to track and reduce code offenses, ensuring our codebase remains clean, efficient, and easy to maintain. These measures gather the number of code offenses such as TypeScript types to fix, ESLint ignore… This initiative supports our commitment to high code quality standards, helping us manage technical debt and improve overall code reliability and scalability.

Adoption of Mantine for Internal Interfaces

Our design system is mainly built for our end user applications, with playful buttons and colors and large text to increase visibility. But recently we faced an interesting decision about keeping it for our internal interface. Our internal interface needed more condensed styles, more component variations, and a larger set of components including complex ones.

We decided to take a risk and use a separate design system for our internal interface. We chose Mantine because of the large choice of components and for API design choices close to our internal design system.

Now new internal products or new parts of existing ones are using Mantine, and we’ve received great internal feedback and impressive adoption from both the engineering and the design team.

Making our design system universal

Building separate components for web and mobile applications often led to redundancy and inconsistency, increasing development time and effort.

We decided to build components for our design system in a universal way. This means we can now create a React component once and use it seamlessly on both web and mobile apps. For more details, we have dedicated an entire article to this topic.

Storybook for application development

Initially, Storybook was reserved only for our design system, limiting its benefits in building and maintaining components and application views across all projects.

Recognizing the value of the Storybook workflow, we’ve deployed it across all our apps and packages. Now, any engineer can add stories for any project, enhancing our ability to build and maintain components and application views efficiently.

One repo to rule them all

Initially, our setup consisted of two primary monorepos — one for the backend and one for the frontend — along with several other scattered repositories. This structure required us to create two separate pull requests for any feature that involved changes to both the frontend and backend. Additionally, we faced several other developer experience challenges, such as:

• Difficulty in deciding where to host code for an internal CLI
• Inability to share typing between the REST API and frontend code
• Complexities in local setup

To address these issues, we decided to consolidate everything into a single monorepo 🔥.

The migration process was challenging, but the benefits were immediately evident:

• Tooling is now shared across all our stacks, including CI configuration
• We established a unified method for installing all dependencies using Devbox (more on this below)
• Developers can now submit a single PR that updates the frontend, backend, and infrastructure simultaneously

DevBox

Onboarding new engineers and maintaining consistent development environments can be time-consuming and prone to issues, often due to Homebrew misconfigurations or dependency conflicts.

We experimented with DevBox in beta and found it significantly simplified onboarding and environment maintenance. After rolling it out to everyone, we drastically reduced local setup issues, allowing us to focus on enhancing the developer experience rather than fixing individual cases. This setup has provided consistency across all engineering setups, ensuring that patches and features are deployed smoothly to everyone, and, most important for my crew, make it easy to reproduce bugs locally.

Alan CLI

Managing tasks with over 200 scattered shell scripts across the codebase has been challenging. This approach is hard to maintain and lacks discoverability, making it difficult for engineers to perform common tasks efficiently.

With our monorepo switch, we set up our CLI using OCLIF, which is automatically installed through DevBox init scripts. Initially focused on infrastructure tasks, the CLI aims to centralize and reduce the numerous shell scripts.

Since it’s automatically installed on all engineering computers, it can reliably handle common tasks, like promoting a staging environment to production.

We also integrated it into our CI/CD pipelines, providing a unified way to perform actions both locally and in pipelines, simplifying debugging and requiring minimal environment variable adjustments. Internal promotion before and after the release led to numerous feature requests, indicating strong adoption and engagement.

So what’s next?

At first, let’s take a step back on what we don’t do well:

1. One significant issue is our numerous unfinished migrations, which create considerable friction in building quality. This is because they generate overhead, leaving our engineers uncertain about the best procedures to follow.
2. It remains challenging to assign clear ownership over various parts of the code. This difficulty makes it hard to delegate ownership to other areas, which is crucial for advancing core topics or enhancing their monitoring capabilities, for instance.
3. Even though DevBox has introduced several improvements, there are still areas that may appear obscure, especially the installation experience for newcomers.

Building on those observations, we have pinpointed three key areas to prioritize moving forward: Local Development, Web Development, and Infrastructure Agility.

Local Development

We need to enhance our local setup documentation, particularly to better support newcomers. Additionally, we aim to improve the local development environment using DevBox.

Moreover, we will continue to enhance our CLI to streamline the local workflow. This includes features such as quickly launching environments, refreshing data, and providing diagnostic tools to assist engineers when they encounter setup issues related to cache, dependencies, and other common problems.

Web Development

Our goal is to empower the engineering community to confidently make impactful changes to our web applications (including frontend and backend). To achieve this, we have identified several key initiatives:

1. Automatic Deployment of Preview Environments: Implement automated processes to deploy preview environments for testing new features or fixes before they are deployed to production.
2. Universal Design System Components: Continue migrating our design system components to a universal format that supports both web and mobile app development.
3. Shared Typing Between API Endpoints and Applications: Explore tools like Swagger or other API specification solutions to facilitate shared typing between our API endpoints and applications.
4. Enhanced Visual Regression and E2E Testing: Increase the setup of visual regression and end-to-end (E2E) testing for critical workflows, ensuring engineers can confidently verify that no unintended changes have occurred.

Infrastructure Agility

To enhance our infrastructure, we’ve identified several key initiatives:

1. Reduce Terraform Drift: By reorganizing our Terraform stacks or potentially adopting new technologies, we aim to minimize drift. Implementing continuous deployment and other tools will help ensure our infrastructure remains consistent with our infrastructure code.
2. Empower Engineers with Infrastructure Changes: Provide tools and processes that instill confidence in engineers when making infrastructure modifications, thereby reducing the reliance on the dedicated infrastructure team and minimizing their workload.

These enhancements will streamline our infrastructure management, promote consistency, and empower our engineering team to make impactful changes with confidence.

Let’s dedicate the coming months to making significant advancements in these key areas. Wanna join us in enhancing our Developer Experience? 😇 We’re hiring!

Also, your experiences and feedback are invaluable, so please share them in the comments section below. I look forward to reconnecting for another DX roundup next year!

See you soon! 👋