Playbook: Rules We Roll By
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
- Friendly and positive attitude
- Willingness to learn, and to teach
- Attention to details
- Clear communication
- Available and responsive on Slack during your working hours
- Daily checkins in the #standup Slack channel
- If you’re stuck, don’t hesitate to ask!
Answer these 3 questions: what was done the day before, what is planned for today, and what obstacles/problems you faced.
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 🙂
- Find a balance
- Make your habit to refactor as you go
- Add story ID to commit messages
- Pull Requests
- One Pull Request a day is mandatory
- JIRA time-tracking
- Continuous Integration
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.
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.
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 are made from your feature branch to master.
This way we ensure both granularity and consistent delivery; your performance is judged by it.
Time is tracked in Jira using its time-tracking feature, at least once a day.
On each push to master, tests and linting is launched, and the project is getting built.
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.
- Enforcing code styling
- Commenting out
Each public function in a class has a unit test.
Code styling is consistent across a single project: function/var names, single/double quotes, spaces/indents, etc.
Code styling is enforced using IDE-based or CI-based (even better – both) linting tools.
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.
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
zsh + oh-my-zsh as your shell
Homebrew for package management on OS X
Slack desktop client
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
September 9, 2017
July 27, 2017
July 19, 2017