Skip to content
No description, website, or topics provided.
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.



  • 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


  • 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


  • 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)


  • 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


  • 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


  • 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


  • 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


  • 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


  • 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


  • 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


  • 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


  • 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


  • 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
You can’t perform that action at this time.