I had the privilege of attending RailsConf last month and seeing DHH’s keynote. A lot of feathers were ruffled. Mine weren’t. Maybe that’s why I’ve been only peripherally aware of the ensuing debate. But I did watch today’s discussion. It reinforced what I thought was going on: people are stuck in their own point of view and talking past each other.

In his keynote, DHH challenged the idea of programming as hard science. I personally do think of myself as a software engineer and programming as hard science.

Hard. Fucking. Science.

But – if I understand correctly – I see what he’s getting at. Programmers learn design patterns, principles, and techniques and assume they are universal truths because science. The reality is, however, that even in hard science there’s often room for subjectivity and multiple approaches. Even in mathematics – the hard science – there is often more than one way to arrive at a solution. There may even be many correct solutions, any one of which can be used, depending on what you’re doing.

I don’t think becoming French poets or software writers will make us immune to this sort of black-and-white thinking – text editor holy wars have been around as long as text editors have.

What will? Professional courtesy. If we see ourselves as craftspeople – whether that craft be  writing, engineering, or otherwise – shouldn’t we treat our fellow programmers with the respect we’d like to receive ourselves? Oughtn’t we withhold judgment of their process until we’ve seen the deliverable – the code?

Can we let go of our absolutes? Absolutes like “If you don’t write your tests first, your code is shit.” And like “Writing tests first leads to bad design.”

I’ll start.

I love TDD. The rhythm works for me. For many things. But sometimes I write tests last. And sometimes I don’t write tests at all. Good design drives good tests and good development – regardless of which happens first or whether testing happens at all. Testing is a tool, not the deliverable. Every problem is not a nail and testing is not a silver bullet.

I love using mocks and isolating the thing I’m testing. It makes my tests run really fast and I can easily isolate what I broke and where. But they sometimes come at a cost and sometimes that cost isn’t worth it.

I like RSpec and TextMate 2, but there are plenty of other great tools for writing code. I like design patterns and principles and learning them has made me a better coder. But there isn’t a design pattern for every programming problem. Sometimes principles conflict and there are tradeoffs to be made. Good code is a little bit subjective. We sometimes have to choose between DRYer code and code that’s easier to read. Between code that’s faster and code that’s more easily reusable.

If everyone did things the same way, how on earth would we learn from each other?