Overview

These Instrument developer guidelines are intended as a starting point. Each project and client has different requirements that teams will adjust and adapt to accordingly. In communicating these guidelines, we establish a set of guiding principles and best practices that drive the efficiency and quality of the work we do.

General Guidelines

What’s right for the project is not always what’s easy for the developer.

Make the complex simple.

Development Breadth

Instrument creates impactful user experiences that are delivered through websites, web applications, native applications, physical installations, connected products, augmented reality, and virtual reality. Our expertise often informs all stages of the project, from ideation to prototyping, to execution and deployment.

Process

Select the right process

Every project needs an effective and clearly defined process to drive efficiency, quality, and creativity. It’s important for the team to establish and align on a process early on, with consideration of the technical requirements, key stakeholders, and project delivery specifications. Buy-in from all disciplines (not just development) is critical to the successful adoption and exectution of a project process. For this reason, it is not uncommon to use different processes for different projects.

Select your SDLC methodology

Agreeing on the Software Development Life Cycle (SDLC) model up front is a critical step to ensure the smooth operation of a project. Depending on project and client needs, we can often add flexibility by working within several different models.

Evaluate, adapt, and refine your process

Routinely review and evaluate how a process is working for your team and client. Don’t be afraid to implement changes that improve efficiency, product quality, and quality of life.

Collaboration

Communicate early and often

Nothing beats working side-by-side, but it isn’t always an option. We use multiple channels of communication, and collaborate in a way that respects people’s time and need to focus. We primarily use Slack as a way to quickly and efficiently communicate with team members, or to request in-person communication.

If you encounter a blocker, need clarification, or help solving a problem, we encourage speaking up early; this allows resources and priorities to shift so team members can get the help they need.

However you work best, be sure to communicate; doing so frequently is a cornerstone of how we work together.

Be involved in design

Creating compelling digital experiences requires a close relationship between designers (visual/feel) and developers (execution/function). Pair programming with designers allows a free exchange of forward-thinking ideas that are both feasible and compelling. Injecting developers early in the design process cuts down on wasted effort and produces more innovative ideas.

Develop as a team

We don’t expect our developers to figure everything out by themselves. As a team, our shared knowledge and joint problem solving allow us to move quickly, arrive at solid solutions, and continually learn from each other. Slack is a great way to start communication unobtrusively. From there you can request face-to-face time, schedule pair programming, or agree on other methods of collaborating.

Use ticketing

Using a ticketing system is critical for setting expectations, forecasting delivery, predicting velocity, and understanding requirements. We use meaningful titles and descriptions in tickets and keep them up-to-date so the team knows what everyone is working on and what the current status is.

Check code in often

We check in our code often to minimize disruptions caused by team member absences, to protect against device loss, and to account for other cases when a developer may not be able to continue on a feature. This practice helps enforce smaller and more frequent feature completion.

Keep pull requests small

Focused, single-ticket pull requests are easier to review and validate. Giving your PR a meaningful title (versus using the default branch name) and adding a clear description allows team members to understand the context, purpose, and intention behind your code, keeping reviews timely and efficient. As you work, remember to open PRs frequently, and to keep them scoped to a single ticket when possible.

Documentation

Documentation is a key component of good collaboration and communication. Document as you go with clear code commenting, and by creating technical specs and architecture diagrams. When adding code comments or creating documentation, keep the writing style professional, tailored to the target audience, and easy to understand by team members and/or clients.

Coding

Avoid complexity

We aim to implement the right solution that fits the technical challenge. By keeping it simple and avoiding over-engineering, we are able to maintain project health and scalability—always keeping the end-goals of the project in mind. We write code we’d be glad to inherit from someone else. As we rapidly iterate on features, we keep it lean, focused, and don’t prematurely optimize.

Producing clean, focused code often requires more mental effort, and a solid, holistic view of the project. Our developers are more than just coders, they’re thinkers, strategists, and creative problem solvers.

Use enforceable standards

Code reviews should not involve two developers arguing over their preferred formatting; using a style guide and linting is a great first step in setting up a project. Making formatting decisions early on keeps the project’s code clean and consistent, so code reviews can focus on what matters.

We often need to adhere to client and/or third party standards (ex. functional, accessibility, analytics, maintainability, deployment) when producing our work, and carefully factor these requirements into our development set up and final implementation.

Automate

We automate development as much as possible. Automation reduces bugs, increases efficiency, and ensures quality. Automating for continuous integration, development builds, unit tests, and deployment is part of our regular Software Development Life Cycle (SDLC) process.

We strive to make every software engineer’s development experience on a project consistent and predictable by utilizing technologies like Docker and Kubernetes. Being able to virtualize, containerize, replicate, and modify dev environments quickly is critical for flexibility and code protection.

Control your code

We always use source code control. It allows us to work in parallel, protects against data loss, and provides for rollback when needed. We have preferred platforms and standards for code management, but conform to client standards when necessary.

Be secure

Security is critical in software development and paramount to our clients. Requirements often vary between clients and projects; for this reason, it is critical to discover and address any security considerations early on in the project. After the team and client have established the project’s security standards, a clear process is defined, documented, and implemented to ensure security standards are met throughout the projects life cycle and delivery.

Be inclusive

As developers at Instrument, we aim to create accessible digital experiences. Accessibility is not only an important legal consideration for many sectors, but it’s also a critical part of creating an inclusive experience for users. Not all projects will have strict requirements, but we make a point to discuss accessibility considerations early on in projects, educating clients as needed about the importance of compliance and fostering an accessible web.