When Code Isn't Enough
I’ve been having an interesting ‘debate’ (if I can call it that) about whether it’s more relevant to show code when discussing non-MS frameworks, or to prod people to find out for themselves.
On one hand I completely fall in to the “Morpheus Camp” – essentially that “I can only show you the door, you have to walk through it”. It’s the power of choice, the wonderful realization that you control who you are, what you believe, and where you put your faith – no one can and should control that but you.
On the other hand you’re a thinking person that needs evidence and thoughtful discourse – perhaps the breadth of your life/professional experience doesn’t give you a wide enough perspective to understand that it’s a door I’m trying to show you in the first place.
To be more specific: I’ve been asked repeatedly to “show why Ruby is so awesome” with regards to
my NDC 2010 talk. After all the premise is, basically, that .NET devs are pretty much missing out. In my mind I felt a bit like Hemingway – I don’t need to paint the scene for you: you do that. Superlatives and colorful imagery put my scene in your head; I’d rather you create your own.
My friend Jon Galloway sees it differently – that discussing specifics removes “the fluff and armwaving” (my words, not his) and therefore keeps the conversation directed and civil.
The problem I see is the assumption of directed and civil. If I tell you that I can do XYZ with Ruby (and you’re a C# dev) – you’ll likely counter with “well I can do XYZ too, but in a much better way”. I’ll then counter with mental shift of dynamic languages, you’ll counter with safely coding in a static language and compiler, I’ll counter with Unit Tests as replacement for compiler and …
We’ll get nowhere. Ultimately far, far away from where we should be – that there’s something different out there, and what it means to me will be entirely different then what it means to you. You might not like it – and that’s really OK. Which is my point.
I’m not trying to convince you to like Ruby. Or Python. Or whatever. What I’m trying to do is push the discussion into the realm of the informed: know why you don’t like something – NOT why you don’t need to know it.