handbook/handbook-main/team-norms/development_practices.txt

# Development Practices

When a new engineer joins the team, we'll often find they need some guidance on our preferred practices.

Below we've included a list of practices that we encourage engineers to adopt so they can get up to speed as quickly as possible:

## Understand our Delivery Standards

Regularly validate your delivery against our [Delivery Standards](delivery_standards.md).

## Commit little and often

Engineers should commit frequently (5, 10, 15+ times per day) using short-lived branches that are merged back in to main via PR the same day. Commit messages should be well [structured and descriptive](https://github.com/erlang/otp/wiki/writing-good-commit-messages).

## Bring the pain forward

Tackle the hardest and most uncertain things in an iteration first. Use [spikes](https://en.wikipedia.org/wiki/Spike_(software_development)) where appropriate.

## Attend your standup

Your team should be having a standup every day. Prepare yourself ahead of the standup to talk about: what you achieved yesterday, what you're planning to achieve today, and things that are currently or likely to block your progress. You should be specific at standup, preferring "styling of cart line items and flash notification for mobile and desktop breakpoints" over "working on the cart".

## Be loudly blocked

If you're blocked on making further progress, loudly and immediately raise this with your team and continue to do so until you have assistance in becoming unblocked. Do not spend more than an hour trying to solve a problem before asking someone else for help.

## Communicate effectively

Be sure to communicate effectively. Asking too many questions is much preferred to not asking enough:

 - Talk to your team frequently
 - Request clarifications if you're unsure
 - Don't be scared to speak to the customer
 - Involve any other specialists that might be available to you

## Document the decision making process using ADRs

ADR's are a formal way of documenting the decision-making process. (ADR stands for Architecture Decision Record)

For a full write up see [Michael Nygard's blog post on ADRs](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions).