If your code has little or no test coverage, you're working too hard. While testing may seem like a lot of extra work, it's really a way to debug your code before you even write it, and to make sure it keeps working when you change it later on.
In this session I'll share my journey from a "non-tester", to "pragmatic tester", and finally to "test-first developer". I'll explain how writing tests first forces you to write better code, then describe how to build an application-specific testing framework that makes writing tests easier, use sample data to write integration tests, and use mocks when you want to avoid complicated dependencies. In the end, you'll be ready to start working smarter by writing your tests first too.
Programming is a wonderful profession for problem solvers, and a random sampling of developers will generally have different ways of solving the exact same problem. This can be great in teams, as it allows finding solutions that resolve the unstated issues: performance, flexibility, and maintainability being some of the more frequent.
But programmers tend to also have egos, and think their way is the correct way, disregarding one or more facets of a problem, and this is when we have conflict within our profession.
How can we resolve those conflicts? And when does quantity of code give way to quality of code — and how do we even judge quality? We'll discuss these issues, some potential ways to resolve them, and how we can become both better programmers as well as communicators.