Behaviour and protocol

Code Code reviews Consulting 101 Feedback Good meetings practices How to facilitate team meetings Inclusive language Values

Career

360 review Continuing education policy Engineering manager career ladder Roles Software engineer progression framework Technical skills sheet

Employee manual

Abtion's pomodoro Employee benefits Internal days & community Intro Parental leave policy Safety and security Schedule, time tracking & calendar Sickness & unplanned absence Travelling Vacation & planned time off Work from anywhere policy

Project management

Technical setup when starting a new project Client discontinuing hosting or sla Converting projects from development to maintenance mode Estimating Go live checklist Handoffs Invoicing guidelines Procedure for traffic Sla

Setup

Audio setup Create amazon bucket Database backup setup Gpg signing Pairing setup

Technical practices

Bug triaging Css How and why we do design research Kick off meeting Pair programming Tdd testdriven development Workflow

Templates

Readme.standard

Tools and services

Access and permissions Purchasing licenses and memberships Sharing sensitive information Stack and services Wordpress
=

Behaviour and protocol

Code reviews

General

  • For discussions that are happening outside a PR, summarize them afterwards as a comment for future reference.
  • Code reviews are discussions where everybody is encouraged to chime in irrespective of their job title.
  • Words such as “just”, “simply”, and “easily” tend to pass judgment about the difficulty of a problem.

Giving feedback

  • Always read your comment from the perspective of the author of the pull request.
  • If you see something good, say something good.
  • Suggest specific changes rather than using phrases such as “What do you think about clarifying X?” and explain why a change might be appropriate.
  • Avoid selective ownership of code (“yours”, “mine” etc.).
  • Consider reading the code changes from the bottom to the top to catch issues that others might overlook (as most people tend to read the code from the top to bottom).

Receiving feedback

  • The feedback is not a critique of you but the code.
  • Be grateful for the reviewer’s suggestions.
  • Provide context to the pull request and explain the motivation for it.
  • Add comments to specific lines where you want feedback or have questions.
  • Add comments to specific lines where you anticipate questions and explain why you changed something.
  • Every comment should be seen as a suggestion. Ask questions until you understand it and agree that the change would be an improvement.
  • Tag the appropriate people in the PR (git annotate can be useful here).
  • Add a link to the ticket in Asana, Trello, JIRA etc.
  • For frontend changes, consider including GIFs or screenshots showing what has changed.

Additional reading