Manifesto

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

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

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

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

cristaloleg/awesome-manifesto