In my investigation of rails-style development I’ve come up against a meme that has been circulating out there forever. “Real Developers”, it’s said, take to MVC / rails environments like ducks to water. It’s only the baby noobs who known nothing but ASP.NET who find themselves lost — because they aren’t deeply intimate with the HTTP protocol itself.
It reminds me of the old days when it was said that “Real Programmers code in assembly language”. In the face of pragmatic reality that meme gradually morphed into “Real Programmers know assembler” and can use it in appropriate circumstances. Still later, the “Real Programmers” used C, and so forth. In some ways this mentality has passed into legend, but it keeps reinventing itself periodically. Sometimes it expresses itself as more of an anti-meme, in terms of what it’s against rather than what it’s in favor of. The VB folks, for example, have taken a lot of this kind of abuse over the years.
To my way of thinking, a “real developer” is someone who consistently produces quality software systems that delight customers. “Real developers” do this in spite of whatever handicaps happen to exist in their world. They know that no technology, platform, API or software ecosystem is perfect, but they know how to leverage the strengths of what they are given to work with to produce excellent results. And if they don’t know, they can admit it to themselves, and learn quickly.
MVC fans can look down on people who use ASP.NET because ASP.NET developers don’t necessarily know much about the arcana of web protocols. I grant you this will increase the learning curve for environments that require them to know such things. But personally I don’t see an inherent problem in abstracting away the details of HTTP, POST, GET, headers, cookies, and so forth, for our daily work. How is that any different than, say, Java abstracting away CPU registers? Do you have customers who are willing to pay you to code in assembly language so that as to wring out more performance than Java? I didn’t think so.
In my experience, devs who are “into” low-level protocol hacking don’t necessarily grok business realities, and may even take refuge in the esoteric in order to avoid the concrete — they don’t like coping with the “wetware”. It’s the same reason people go into medical research rather than clinical practice. They want to avoid those damned patients and their messy, unpredictable problems and needs. Test tubes are much more predictable.
Clients want problems solved in their business domain. So if ASP.NET takes care of handshaking with web servers in such a way that it frees up developers to concentrate on solving business problems rather than re-inventing the wheel for managing HTTP traffic, so much the better — all things being equal.
Returning to my definition for a “real developer”: what about ASP.NET might frustrate such a developer from delivering great software systems that delight customers? I don’t think it’s the useful abstractions that ASP.NET provides; it’s just perhaps in some cases the implementation of those abstractions. And even then, the problem isn’t immediately apparent, and isn’t a big factor in all kinds of projects.
Do “real developers” have tons of curiosity? Yep. Do they learn things for the pure joy of it? Sure. Is knowing what’s going on under the hood going to make them better rounded and more effective? Most definitely. But if they don’t need to think about low level protocols on a daily basis, or if the minutiae they’ve chosen to learn in their spare time happens to be in a different area, I don’t think that in itself reflects badly on them, either.
Great software can be produced with a variety of languages, tools, and APIs … with varying degrees of pain in different phases of design, implementation and maintenance. Great developers — “real developers” are behind all of those solutions.