It is my firm belief that there are many organizations, teams, managers, engineers, testers, operators, users and individuals of all kinds that in one way or another suffers because we are bad at building software products. The purpose of this collection is to provide anyone that works with software in as a creator with the tools to improve how they work. For the better of themselves, their organizations and their users. Thus, this collection provides a somewhat consistent view into DevOps thinking. Not, that this document is the canonical definition of what _DevOps_ means, or is. But it can be very scary and difficult to start working with DevOps because there are a plethora of different perspectives, definitions, purposes and priorities. This abundance of information is fantastic when you come from a perspective of abundant energy, time and skill. But if your working conditions are poor. You are bogged down by highly coupled software architecture. If you are afraid to make any change because angry colleague will scold you. If you are a part of a dysfunctional team or organization, it is nice to have some concrete suggestions for what to do. Backed up by experience, examples, arguments, stories and sources.