To be honest, I didn't think there was much of an argument or a point here. The conclusion that "there's no substitute for experience" doesn't follow from the rest of the article, and most of the rest of the conclusion falls into "getting things done" anyway.
You were able to think of an edge case for language feature that neither of your friends had considered. Awesome. Smart. Realising that upfront is the kind of skill that saves you hundreds (anecdotally) of hours of debugging because you solve it in the design phase.
Saying "smart interferes with gets things done" is exactly what Joel was saying when he tacked on "and gets things done" - so you can't really use that to argue he left something out.
They would rather mull over something academic about a problem rather than ship on time. These kind of people can be identified because they love to point out the theoretical similarity between two widely divergent concepts. For example, they will say "Spreadsheets are really just a special case of programming language" and then go off for a week and write a thrilling, brilliant white paper about the theoretical computational linguistic attributes of a spreadsheet as a programming language. Smart, but not useful.
This is an interesting reply, thanks. I possibly didn't explain this well. My reasoning didn't actually help, unfortunately, because I convinced my self that a proc MUST behave like a lambda with respect to "return" semantics.
So had I been left to my own devices, I might have written some Ruby code that assumed it was perfectly safe to return a proc from a method. This is a real danger for me, as I like programming with combinators. And I would have been bitten by my mistaken beliefs.
The only thing I'll say in my own defence is that having made this mistake many times, I had the good sense to check how things actually worked when I got home. I used to know, I'd forgotten, and now I know again.
I don't know if that's "getting things done." It may be spinning wheels. Perhaps someone "getting things done" never wastes any time worrying about the difference because they never bother to wonder what happens when you return a proc from a method.
They simply avoid the problem in the first place, so not knowing is irrelevant.
I had the good sense to check how things actually worked when I got home
Sounds like you fit both the criteria for "Smart and get things done".
I like programming with combinators -> They simply avoid the problem in the first place, so not knowing is irrelevant.
I think that a general awareness of the tools available to you is extremely useful. Specific knowledge isn't unless you're using them. Given that your friends "read about it today", I assume they don't often make use of this particular language feature - in which case it's fine not to know. In your case, not knowing was dangerous, and when you realised the limitations of your knowledge (unknown unknowns and all that), you corrected it.
My point is that I think all of this is covered in Joel's original essay, so your title isn't really justified.
Finally, I think there's a good essay to be written with a similar title, where you explore the point that "sometimes you need an expert". luu touches on this wrt hardware engineers: http://news.ycombinator.com/item?id=4882560
"They simply avoid the problem in the first place, so not knowing is irrelevant."
I always see this as a quality that I'm missing compared to other coworkers. They'll go for the simple implementation with the complicated usage pattern while I always aim for the complicated implementation with the simple usage pattern (to a point).
We've had a lot of discussion of your simplicity-is-not-simple article which did a great job articulating the trade-offs.
I also learnt the hard way that answering a message differs from returning from a closure. And I was using Smalltalk, whose designers chose distinct syntax for those actions, a good idea that was apparently broken when Smalltalk became Ruby. "Return" should mean the same thing in different places; scepticism about how tools behave has to stop somewhere.
You were able to think of an edge case for language feature that neither of your friends had considered. Awesome. Smart. Realising that upfront is the kind of skill that saves you hundreds (anecdotally) of hours of debugging because you solve it in the design phase.
Saying "smart interferes with gets things done" is exactly what Joel was saying when he tacked on "and gets things done" - so you can't really use that to argue he left something out.
They would rather mull over something academic about a problem rather than ship on time. These kind of people can be identified because they love to point out the theoretical similarity between two widely divergent concepts. For example, they will say "Spreadsheets are really just a special case of programming language" and then go off for a week and write a thrilling, brilliant white paper about the theoretical computational linguistic attributes of a spreadsheet as a programming language. Smart, but not useful.
http://www.joelonsoftware.com/articles/fog0000000073.html