Our Principles

This page explains the Planet Argon Core Values and the Engineering Team Decision Principles, and how they both guide our work.

Planet Argon Core Values

🙋 PROACTIVE

We actively seek opportunities to improve our client’s products, our processes, and our abilities.

How this shows up on the engineering team:

• We tag technical debt in clients’ code bases so we can improve that code later
• We keep lists of ideas for ways we could improve the performance or user experience of clients’ applications and suggest them to clients at appropriate times
• We use automated tools to detect security vulnerabilities and potential areas for performance improvement

🐒 CURIOUS

We have a natural curiosity for the undiscovered that results in remarkable work for our clients and stronger connections for our team. We ask questions, experiment, and learn.

How this shows up on the engineering team:

• We research new tools or technologies that could improve our development workflows
• We research new tools or technologies that could improve our clients’ applications
• We work on group projects together to build solutions for common team problems
• We read blogs, articles, and newsletters to keep up on trends in our industry

🤝 DEPENDABLE

We are invested in our work. We manage expectations. We support our clients and teammates. We hold ourselves, our teammates, and our clients accountable.

How this shows up on the engineering team:

• We give realistic estimates on Jira tasks
• We communicate work progress to our PM and clients in Jira issue comments and Slack channels
• We document the root causes of bugs and outages so that future devs can avoid them
• We QA our work before pushing to production
• We require at least one other developer’s approval on a PR before we merge our changes

🕺 VERSATILE

We readily adapt to change and encourage innovation because our team and work are transparent and flexible.

How this shows up on the engineering team:

• We are quick to recognize when a technical plan is not working and collaborate with team members to create a new one
• We regularly switch between BE and FE tasks, regardless of our official role title
• We review PRs on projects to which we have not been officially onboarded
• We can two or more applications set-up on our machine so we can easily switch to a different project’s tasks if we are blocked

🙃 DELIGHTFUL

We choose to set a mindful, positive tone that allows everyone to flourish.

How this shows up on the engineering team:

• We share helpful information in the #engineering-learn Slack channel
• We participate in regular Donut meetings to chat about non-work stuff and better get to know our teammates as people
• We use graceful and grateful language in our communications with clients

Engineering Team Decision Principles

Decision principles are similar to values in that they represent the team’s beliefs and best practices, but they offer a foil to the ideal value in order to help guide decision-making.

The strucuture of a decision principle is this over that. An example of a decision principle is security over speed. This principle would emphasize shipping stable, secure code over rushing to ship as much work in as little time as possible.

Our Principles

Iteration over giant deliverables:

• We value smaller, more frequent releases.
• We update documentation as we work and don’t wait until a doc requires a large overhaul.
• We communicate work progress on Slack and in ticket comments regularly, even if the progress made seems minor.
• We always seek ways to refine and improve client applications and internal processes.

Readability over cleverness

• We write code that is easily understood by others.
• We are explicit in our naming conventions, including variables, components, files, and assets.
  • BM: documentation somewhere? what about names that are already in a codebase by previous devs?
• We provide context to our work in the form of descriptive commit messages, specific branch names, and, if appropriate, comments
• We follow common conventions when designing folder and file structures.
• We are open to non-DRY code if it will help future engineers onboard to a project.

Automation over manual processes

• We practice TDD.
• We can diagram a CI config file.
• We use monitoring tools to alert us of system issues.
• We use or write scripts that bundle common tasks and streamline our workflow.

Long-term value over quick fixes:

• We prioritize scalable solutions and rely on temporary patches only in severe incident responses.
• We focus on tasks that align with the client’s broader business goals.
• We make decisions based on well-thought-out and well-documented strategies.
• We anticipate issues and implement solutions proactively.

Transparency over obscurity:

• We promote openness and clarity in all communications and interactions.
• We discuss projects in places all members of the engineering team can see, such as shared Slack channels and in comments on Jira issues.
• We take detailed meeting notes and share screens during video calls so other attendees can see what is being documented.

Standards over improvisation:

• We adhere to agreed-upon team standards.
• We trust our teammates to update READMEs and wikis with accurate instructions and information.
• We actively review and contribute to the Engineering Team Handbook.

Humility over complacency:

complacency in it’s official definition: a feeling of smug or uncritical satisfaction with oneself or one’s achievements

• We recognize that there is always more to learn about any tool, technology, or subject.
• We recognize that it takes a wide variety of skills and talents to create a successful engineering team.
• We create professional development plans to increase engineers’ understanding of a variety of technologies.
• We regularly celebrate the accomplishments of our fellow engineers in Meet-the-Week and the ETM.
• We ask for help in the #engineering-help Slack channel.
• We share interesting news and information in the #engineering-learn channel.
• We are quick to ask questions or consult a README or wiki.

Consensus over mandates:

• We value team agreements and design systems to extract as much individual input as possible.
• We encourage and facilitate conversations in which opposing viewpoints are discussed and understood.
• We make important decisions collectively and document the outcomes of those conversations.
• We say “Yes, and…” a lot.

Resources:

• The Power of Setting Decision Principles
• Why Decision Principles?