Developer Ethos

##There are no geniuses

Software development is hard. It's hard because systems are complex, new technologies and practices are constantly being produced. In the face of this complexity, humility is a virtue. Developers might be in different stages of professional maturity but even experienced developers have as much to learn as inexperienced developers since the amount to learn is infinite. We all have to strain to learn new things and get better. In this setting, no one is a genius. All team members depend on help from other members. 

##Explanations

All design choices are subject to discussion about what is the best way to solve a problem. Nothing is sacrosanct. All designs can be questioned. There are objective standards however of what is a good practice and we do have to work to a conclusion on building software with a commercial purpose. The main thing is to be able and willing to articulate the motivation for a design or technology choice. This is an explanation. It is critical to knowledge sharing to be able to _explain_, which means verbal written explanations of why things are good (or bad) that are fact based and contain as little emotional motivation as possible. 

##Sharing knowledge

We share our ideas with colleagues. We discuss and find solutions together and when we find a good solution by ourselves, we share that with the team by providing explanations. We listen to the explanations of others and let that influence us. We act courteously and respectfully at all times towards team members and everyone else. 

##Openness

The team owns all the software. We don't have individual owners of source code. Be prepared to share your work on a continuous basis. Everyone hates sharing unfinished work. We therefore break work down to at most one-day increments and are prepared to publish that work every day. We avoid work increments that take longer than one day. That way, you are always pushing finished work on a daily basis.

##Estimating work

Because of the complexity of software, it's hard to figure out how long some tasks will take. We always let developers take time based on the principle of estimates: if you need time to estimate, provide how much time you need to come to an estimate. This might go in iterations of estimates. Depending on the urgency of the solution, we can let you take the time that is necessary

We rarely impose a deadline on any developer for a task. But we always expect a reasonable estimate of time and for those estimates to be usually approximately correct.

##Pragmatism

Simple is better than complex and "you aint gonna need it" are principles of pragmatism that we use to prevent us from taking on too much at once and building things we don't yet need. 

##Ambition

Strive for the highest level of professional capability, individually and as a team. Our ambition as a team is to be better than the average tech company by a wide margin. And we expect team members to profit individually from this by being better than average software engineers. Each technical staff member has to contribute to this project to enable this to happen. This can be by continuously informing oneself of new developments in your field and holding conversations with team members on the best practices. 

As commercial technical engineers, we have an obligation to deliver the best work we can to give our company a commercial advantage and to pay attention to the requirements of our products. As individuals, we owe it to ourselves to invest time and effort to skill up and be competitive with across the software industry.