Apploi Engineering Guideposts

Introduction

At Apploi, we do our best to foster an environment where engineers can thrive independently, empowered with agency. Our ethos revolves around avoiding micromanagement and instead nurturing a culture of growth within our team. We are a diverse group and value diversity as a cornerstone of our organization, recognizing the multitude of backgrounds and experiences that enrich both our personal and professional lives. As you engage in your work, keep these guiding principles in mind, as they are integral to the fabric of Apploi!

ChatGPT and DALL·E is crazy.

Guideposts

Don’t waiver from Apploi’s mission. This guides our work.

Apploi helps healthcare organizations provide the best care to the most vulnerable populations by hiring & retaining the right people.

In practice…

1. Work and resist laziness. People need our help.
2. Be proud of the software that you are building. It’s important.
3. Stay in our lane. Apploi is focused on healthcare, no other industry.

We want and need users.

Apploi doesn’t exist without customers, so build with customers in mind.

In practice…

1. Work hard so that users do not wait more than 200ms. Put the time in so our users don’t have to.
2. Don’t assume. Solicit regular feedback from users through both interviews and collected data. Understand the user experience and impact your changes have on customers.
3. Internal users are important too. Treat your co-workers like you want to be treated.
4. The user experience is important.
5. Security is non-negotiable. Everyone has a right to privacy and no one wants their data stolen.

Ship frequently and focus on quality to ensure confidence in the deliverable.

It’s well documented that high-performing teams deliver frequently in small batches.

In practice…

1. Work with the Engineering Manager and Product Manager to break down Jira tasks that are more than 3 story points.
2. Avoid large pull requests.
3. Include automated tests with every change.
4. Configure your local dev environment to continuously run tests and receive quick feedback.
5. No really, avoid large pull requests.

No one likes to wait on a system.

While patience is in fact a virtue, we never want to see our software or organizational system unnecessarily hesitate.

In practice…

1. Don’t make our users wait more than 200ms unless there’s an expectation designed into the UI or UX.
2. Don’t make your peers wait on a peer review.
3. Optimize for flow, but don’t neglect meetings and responses to communication.
4. At the right time, consider scale and optimize performance.

Feedback is required.

One Proverb reads, “The one who states his case first seems right, until the other comes and examines him.” We are amazing but imperfect and fallible people. Asking for feedback is not a sign of weakness but an effort to improve.

In practice…

1. Code reviews are important, both giving and receiving reviews. Take these seriously, both in the time spent reviewing and the time spent considering the review.
2. Don’t assume we know the user (internal or external), and make sure you are soliciting feedback from the right user.
3. Observability. We need feedback from running code too.

Leave it better than you found it.

In practice…

1. Tech debt must be on the roadmap.
2. You have freedom to improve code or a system WHEN it is broken or difficult to maintain, and when it meets a quarterly goal. (i.e. if it ain’t broke, don’t fix it.)
3. Don’t merge PRs when tests are broken. (i.e. if it is broke, fix it!)
4. See alerts through to the resolution. Let your Engineering Manager and Product Manager know how this might impact the sprint.

Constraints are necessary but don’t neglect stability.

We have time, resource, and requirement constraints. We must live within those guidelines, but we can’t let the house fall. If any one of those threaten stability, raise a flag.

In practice…

1. Don’t let perfection be the enemy of good enough.
2. Don’t let perfection be the enemy of shipping.
3. As engineers, sometimes we are the only ones that see and understand the fragility of a system. It’s important that you document and articulate risks.
4. Engineers are problem solvers. Use the constraints to design and develop clever solutions.
5. We have budgets. Live within that constraint.

Curiosity is encouraged.

Work to continually improve.

In practice…

1. Understand how Apploi works.
2. Understand our customers.
3. Understand the role of sales, customer success, finance, etc.
4. Understand the priority of a task and the specific requirements.
5. Understand the author’s intent. (e.g. Why is the code written this way? Why did a designer design it that way? What does the user mean?)
6. Understand the domain of your work and let that drive your design.

Finally

Apploi has great products, and we serve a very important market. As we navigate the complexities of software development, our engineering team is essential to realizing Apploi’s mission. We write code, solve interesting problems, and hopefully have a lot of fun; but we also have the opportunity to transform healthcare services for the most vulnerable populations. Let’s go!

2024 revision