Manifesto

Git

• 1 commit per change, do squash on merge
  • you can easily work with changes
• there might be few (already squashed) commits in a pull request
  • don't make huge changes they will bury the truth
• touch few things at once
  • it's kinda obvious
• rebase instead of merge
  • no merge commits, cleaner git history
• pull request must have at least 1-2 approvals
  • changes must be visible to the team members
• master is read-only
  • it's a rule. Always. No exceptions.
• delete branches after a merge
  • better navigation and git performance
• use SemVer as a standard for versioning
  • do not reinvent the wheel
• release tags
  • tracking releases/deployments are simpler
• omit release branches for patches (aka 0.1.x)
  • use release tags for that
• no global history changes
  • prevents git history misuse
• commit message format
  • clear, well explanatory, structured
• no big binary files inside a repo
  • slowdowns without a reason
• have a meaningful README
  • so everyone can quickly get an overview of the repo

CI

• auto-revert on failure
  • rollback changes, no broken code in the master
• run at any commit
  • the obvious ability for CI
• CI plan in git
  • know all plan changes and have consistency
• warn about formatting verification
  • no developer disruption in the future
• warn about coverage illness
  • coverage is a quite important thing
• track test failures and flakiness
  • statistics, hints, conclusions
• store build logs for 3+ months
  • having analytics and working links to them
• do not remove builds/PR/issues
  • unexpected 404 will help no one, will not save disk space also
• docs are generated from the code
  • end-user changes must be explicit
• locally reproducible builds
  • re-run part of a job on my local machine
• use Makefile, Bash
  • simple, easy, well known
• ability to start/stop a job on CI
  • waiting for an approval to make this action is a horrible bottleneck
• CI jobs should be runned periodically
  • to reduce possible errors due to hidden dependecies

Deploy

• configuration files must be validated before a start
  • unless difficult debug is your goal
• store config in the same repo as a code
  • this prevents 'the chick or the egg' problem
• all features must be protected by feature flag
  • in case of an accident, it will(might) be enough to turn it off
• deployment of a new config must be isolated
  • to separate different machines/containters/storages from each other
• deploy must go from a (git-)tag or release, not from the master
  • this restricts a changeset which will be deployed

Code health

• leave your code better than you found it
• document your code
  • giving a small context for API will save a lot of time
• use linters and code analysis all the time
  • the best handling for the best code
• touch legacy, often
  • it becomes non-legacy faster
• remove deprecated stuff
  • having a bloated dead code is a mistake
• also remove old code
  • it adds even fewer reasons to the new code
• use TODO, BUG, XXX in code
  • jumping to the issue tracker can be minimised
• no experiments in the master
  • use your 20% time as a playground, please
• allow changing log-level on the fly
  • this will simplify production's debug routine
• limit your log file, 'cause it might grow unlimited
  • this might cause troubles to your app, be careful
• store your config in /etc/myapp and logs in /var/log/myapp
  • this will make everything more structured and well defined
• all modules must have the same structure
  • similar environment everywhere is a good idea
• if you can’t show a bottleneck, don’t start to optimise it
  • it might be interesting and challenging, but useless
• check back compatibility before the new releases
  • make it explicit and obvious (+doc how to port)

Database

• think about your data
  • don't use SQL/NoSQL without a reason
• keep models normalized
  • less storage, better performance
• but don't normalize without a reason
  • everything is a trade off
• use timestamp to store a date/time
  • this will save you from formatting hell
• log slow queries
  • see what is happening in a database and who is too greedy
• don't put business logic into DB or at least make it loosely coupled
  • this will give you an easy migration to another DB

Dependencies

• wrap any dependency with an interface(or analogue)
  • this will prevent a vendor lock on it
• bump libs on a permanent basis
  • the new version is expected to be better
• have a local cache-server with dependencies
  • adds stability to the infrastructure
• pin your dependencies to a specific version
  • accidental commit to dependency's master will break nothing
• prefer mature technology, rather than a hyped one
  • mature will die slower, then hyped
• fork instead of hack
  • it might be better to fix a lib instead of wrapping for the desired behaviour

Tests

• use one test framework
  • a similar environment is better
• show results, not just stack traces
  • some failures are obvious with visible result
• isolated tests
  • use beforeTest and afterTest aggressively
• TDD
  • it really works
• measure a code coverage
  • a quick and easy way to eliminate bugs
• test your backups
  • they might be broken
• do not hard code ports in tests
  • unless you're interested in random flaky tests

Team

• pairing, 50% and more
  • you're doing better, you're not bored
• high-level stand-ups, time bounded
  • less info about irrelevant stuff
• 2-3 week sprints
  • have an achievable sprint goal
  • UPD: depends on team/project, might be unuseful
• per sprint roles
  • it's quite comfortable time bounds
• only urgent topics are face-to-face
  • fewer distractions for unimportant things
• friendly atmosphere
  • no insulting environment, respectful trolling
• 'coding rockstar'
  • it is a demotivation, not an inspiration
• if you're on the vacations - specify a date range
  • it'll be easier to find someone else or postpone the question
• FAQ for newcomers
  • 30-day plan with all stuff that they should accomplish
• document solved and unresolved problems
  • team members will be aware of some problems and it will be resolved much faster
• every ticket in progress must have an assignee
  • this prevents doing same work on one task
• there must be a run book or guide for every responsibility
  • 30/60/90 days plan for newcomers, guide for on call, support

Meetings

• I can skip if I'm out of scope
  • do not waste team and own time
• if you're organising a meeting - prepare an agenda
  • to have a way how to drive a meeting
• action points after the meeting
  • who does what and when
• avoid bus factor as much as possible
  • moving/cancelling an unimportant meeting because 1 person is a bad sign

Communications

• use the best apps
  • fast, flexible, pleasurable
• outcomes of important discussions should be on a wiki
  • better visibility for outcomes
• only important notifications
  • @all should be rare for irrelevant updates
• easy access to any team room
  • that's obvious, hey
• do not delete personal chats with inactive users
  • some chats contain interesting ideas
• closed ticket must contain a link to the changes
  • every change must be easily accessible and visible for others

Permissions

• Git, CI, SSH read-access to everything
  • reading server logs cannot cause troubles
• SSO to anything
  • better organisation of credentials
• each office should have global admin
  • different time zones are a bottleneck

Space

• engineers apart from non-engineers
  • fire & ice
• quiet open-space
  • someone might be sensitive to noise...
• quiet zones
  • ...really sensitive
• the kitchen isn't for chill-out
  • the playroom is a thing
• nothing smelly near working area
  • even coffee/cinnamon/mowed grass might irritate

Network

• VPN access from home
  • work from home is a cool thing
• Wifi must work all the time
  • obvious
• LAN must be even more stable
  • uber-obvious

Life

• how often should my salary be reviewed?
  • worth asking
• work from home is a must have
  • family, health, even weather might be a reason
• educational budget to anything related to dev stuff
  • I would like to learn new technologies, why not?
• allow committing to the open-source
  • company_karma++
• skipping team events must be acceptable
  • well...obvious
• 20% time is a vacation like time
  • creating anything that might help someone is awesome
• brown bags sessions must be rewarded
  • sharing knowledge is the best way to inspire
• monthly geek swag <3
  • t-shirts, hoodies and all other stuff
• health food in the kitchen
  • candies are cool, but I would like to live longer