There’s an interesting opinion piece by Kathleen Dollard in last month’s Visual Studio magazine. The latest issue has another piece by Kathleen that is very similar. There’s no link to the latest one, because that issue has just come out (I got mine not 30 minutes ago).
In them, she’s essentially saying that the .NET framework, and all the various supporting enterprise frameworks, have become so large that no one can hope to be competent enough in them to be able to intelligently determine what to use, when to use it and when to stay away.
I couldn’t agree more. But despite comments in the article that she is “more optimistic today” and that “the revolution has begun”, I still come away from the articles sensing a muted dread. Fear that suddenly, skills you possess today and have honed over the years will become worthless. The value of the knowledge you currently have is drying up like last weeks doughnut holes.
And I’m just not down with that.
The fact is, my experiences seem to suggest that the less you know about these high level frameworks, the better off you are. I’m not saying don’t get familiar with them. I’m saying that if you spend time to learn the basics of computer functionality, hardware, interfaces, binary, and object oriented principles like encapsulation, polymorphism and inheritance, details of specific frameworks just tend to come out in the wash.
On the other hand, if you spend all your time focusing on a specific framework, when it’s no longer de rigeur, you’re screwed.
Microsoft has created some great stuff, to be sure, and some of the newest bits out of the pipe certainly seem compelling, WPF probably more so than anything else. But it’s also thrown out plenty of red herrings, costing companies untold money before people realized that “the silver bullet of the day” probably wasn’t a good idea after all.
Back to the knowledge issue though. When VB1 came out, and only a bit later VB3, everyone exclamed at how great it was because “you didn’t have to know the nuts and bolts of the Windows API to get something built for Windows”. Which was true, unless you wanted to build an program you could actually do something with.
The fact is, VB was like that first step down into the pool. It lets you get your feet wet and get used to cold water before you dive in headfirst. Plus you get to feel for sure whether there’s any water in the pool.
But eventually, you either dive in, or you decide you don’t like programming.
VB.Net has always been more like the diving board. You either walk away, or you dive in, and you won’t know if there’s water in the pool till you feel it or you bash your skull on the gunite.
I think there’s a bigger issue here, though. Emphasizing all these layers of Linq, Sharepoint, WPF, WF, WCF, Ajax, and blah blah blah, won’t help encourage anyone to dive in, and that’s what VB.net needs to be doing. Instead we get, what, the MY classes. Puh..leaze! At least edit and continue finally came back with VS 2005. Where’s the genius that decided it’d be a good idea to leave it out in the first VS releases, anyway?
Don’t get me wrong. You can create some hardcore stuff with VB.Net, a lot easier than was ever possible in VB. But you get some hardcore baggage coming along for the ride too. And that’s unfortunate, because falling CS enrollments may mean a pretty sweet employment future for me, but it bodes some not so sweet prospects for our long term technological advancement as a nation.
And dammit, I want my flying car before I GOTO END !
2 Comments
Wow, interesting read.
Myself, I’m torn. When I started programming (late 70’s) the conventional wisdom held that *real* programmers knew what was going on under the hood. You didn’t HAVE to program down to the bare metal, but knowing what lay there was certainly a help.
I can’t help but feel sad that we’ve lost that. I grant you it’s impossible to comprehend everything WIndows is doing behind the scenes but too many programmers are content to plug values into mysterious black boxes and collect the results.
You end up trusting the black boxes to be right, and usually (to Microsoft’s credit) they are. But what to do when the unexpected happens? When the black box in question doesn’t do *quite* what was advertised, or does it with unexplained consequences?
What usually happens is this: smart developers google for their exact situation, or scour the MSDN knowledgebase, or turn to comrades with greater skill. Explanations and/or workarounds present themselves and life continues. Less-than-smart developers stall completely, left to stew in their own frustration with "stupid Windows". The "Learn .NET in 21 Days" crowd won’t even know there’s a problem and assume the answers are correct.
When the Win32 API wasn’t so formidable, one could actually grub through the sourcecode and figure out why something failed, and code a solution. It was possible to be mostly self-sufficient, armed with a decent library of books and an MSDN subcscription. But not any more — I doubt it’s even possible to know all the names of the API functions in Vista much less what they do.
My approach has been to hone a set of tools and routines I know intimately and rarely venture outside my little world unless there’s a need. If a customer wants support for biometric finger-print readers, that’s when I read up on the tools. I never troubled with SQL Server until a customer made it a requirement for a project — like that. Gone are the days of paging through "interesting" sections of the API just out of curiousity… it’s about as useful as browsing the phonebook just in case I ever want to call somebody.
Depending on your point of view, the situation is either going to get much better or very much worse. If you’re a type-A "gotta know everything under the hood" sort, you’re screwed. Those days are past. We’re in a transition state now, but eventually the tools will evolve to the point when the machines program themselves, and our role as programmers will transition to more of an analyst role. Programming won’t be punching symbolic code into a keyboard, it will consist of describing detailed requirements to the machine so that it can program itself.
And when that day comes, folks who really know how to code will still have an edge. 🙂
I think the "hone a set of tools you know works" is a very very good one.
I have a utility module with routines that date back to the Basic PDS days (that’s DOS basic, for those that don’t recognize the acronym).
Its latest incarnation has been to .NET. Sure, .Net has routines to "read ini files", or "replace chars in a string", and in many cases, the port involved just putting a wrapper around the .net functionality, but now I don’t have to go hunting through that formidable .NET class library for that functionality when I need it. It’s right where it’s always been.
Plus, in porting it, I learned quite a bit about the various namespaces in the .NET runtime.
Win, win, in my book.