Playbook: Rules We Roll By

Playbook

In today’s post I’d like to share our processes and our vision. That’s the rules we roll by, and that’s what every new employee must read before they start.

Our goal is to create a working environment that allows us to learn, to teach, to reach our goals - both corporate and personal, and to have fun!

Xiveti Motto

Personal Qualities


  • Friendly and positive attitude

  • Willingness to learn, and to teach

  • Attention to details

  • Clear communication

Communication

  • Available and responsive on Slack during your working hours
  • Daily checkins in the #standup Slack channel
  • Answer these 3 questions: what was done the day before, what is planned for today, and what obstacles/problems you faced.

  • If you’re stuck, don’t hesitate to ask!
  • We all want to figure it out ourselves, I know. But please, don’t spend more than 30 minutes on something you can’t do! You’ll be surprised how much easier it will be with somebody’s help. Also, you’ll feel better 🙂

Development

  • Find a balance
  • Find a balance between overthinking a feature/missing a deadline and delivering a shitty code: think how to implement a certain thing in a best way, but realize that at this moment you might need to take some shortcuts, just to get back to them later to make it right.

  • Make your habit to refactor as you go
  • If you see something that is not right and can be improved, please don’t hesitate to include it in your commit! Your future self (and present myself!) will be very grateful.

  • Add story ID to commit messages
  • Commits have JIRA story id in the beginning, followed by a short description of the changes made, ie: [VID-18] Sort by Description field in Admin panel.

  • Pull Requests
  • Pull requests are made from your feature branch to master.

  • One Pull Request a day is mandatory
  • This way we ensure both granularity and consistent delivery; your performance is judged by it.

  • JIRA time-tracking
  • Time is tracked in Jira using its time-tracking feature, at least once a day.

  • Continuous Integration
  • On each push to master, tests and linting is launched, and the project is getting built.

  • Dockerization
  • Projects are Dockerized. This allows us to develop and deploy software in a closely contained environment, avoiding lots of potential problems with library conflicts, OS conflicts, etc.

Code Styling

  • Tests
  • Each public function in a class has a unit test.

  • Consistency
  • Code styling is consistent across a single project: function/var names, single/double quotes, spaces/indents, etc.

  • Enforcing code styling
  • Code styling is enforced using IDE-based or CI-based (even better – both) linting tools.

  • Commenting out
  • Don’t comment things out without a proper comment of why it was done, and how you are going to fix it. If you truly need to remove something – just delete it. We’re using a VCS after all! Can get this piece back if we need to, at any time.

Software

OS X is preferred, Linux is a second best choice, and Windows is a distant third.

Must encrypt your startup OS X disk with FileVault. For PC-based hardware, make sure you have a password on BIOS, and that you disabled booting from external devices.

IntelliJ PyCharm / RubyMine / WebStorm / IDEA

screen or tmux as console screen manager

zsh + oh-my-zsh as your shell

Homebrew for package management on OS X

Slack desktop client

Skype. Wireless headset is required! Otherwise we’ll have lots of problems with call quality, especially on conference calls.

Gmail / Google Drive / Google Calendar

TeamViewer for being able to help (or be helped) remotely

Docker and Docker Compose

virtualenv for Python/Django

nvm for Node.js

rvm for Ruby/Rails


Leave a Reply

Your email address will not be published. Required fields are marked *