Dear Visual Basic Programmers,
I’m one of those developers who prefer their braces curled, that is to mean that I’m partial to C-like languages. I started my career programming in C++ and then switched to C# later on.
And although I have worked with good old pre-.NET Visual Basic and VBScript on several projects, and although Visual Basic .NET is now nearly identical to C# in capabilities, I’m still reluctant to touch any VB code, .NET or otherwise, and I find myself overly more cautious when hiring or working with programmers who still call VB their primary programming language.
But I’m not alone. Eric S. Raymon, author of The The Cathedral and the Bazaar, singles out Visual Basic in How to Become a Hacker:
Also, like other Basics, Visual Basic is a poorly-designed language that will teach you bad programming habits. No, don’t ask me to describe them in detail; that explanation would fill a book. Learn a well-designed language instead.
In a blog post about VB, Scott Hanselman had this to say:
Visual Basic programmers, historically, have tended to be a bit long suffering, patiently enduring the wrongs and difficulties of VB while being mocked by the C# folks. "VB’s a toy." "VB’s not performant." "VB programmers aren’t real programmers."
The above agrees with the general vibe that I’ve felt on the Internet and in the workplace over the years. Programmers, especially those working with C-like languages, look down on their VB brethren.
That attitude is often uncalled for. If I remember correctly, Jeff Atwood of Coding Horror and Stack Overflow started his career as a Visual Basic programmer. Rockford Lhotka, author of what I consider the best enterprise architecture book for .NET, also started out as a Visual Basic coder. And I would love to be another Jeff Atwood or Rockford Lhotka.
Clearly a good programmer is a good programmer regardless of which programming language they use. So why pick on Visual Basic?
Maybe part of it is lingering envy. Back in the dark ages when it took 100 lines of C to display an empty window, a VB programmer could get the same by just creating a new project and not writing a single line of code. When Microsoft’s main web development offering was ASP sans the “.NET” part, VBScript was the de facto language for that platform. The closest thing C++ developers had was ATL Server, which I doubt anyone actually used.
I think there’s more to it than just sour grapes, however. But before I go on, I would like to offer two extreme yet relevant anecdotes from my own experience.
Dim what now?
I once worked for a company where I could have sworn that my managers (all three of them) were taking bets on how soon they could break me. Almost every project that was once abandoned found its way to me to shape up and ship out, and a lot of them were horrendous hacks. The final straw came when I was given a utility built in Visual Basic that needed some “very minor modifications” as manager #2 said.
I opened up the project and it contained a single form that looked something like the following:
Imagine it in Battleship grey and much, much more cluttered. It was an insult to both “theology and geometry” as Ignatius J. Reilly would say. But let he who has not made an unusable mess of a UI cast the first LOL.
The real horror was those little aqua-colored rectangles next to the text boxes. Those turned out to be label controls that were invisible at runtime. The programmer—and I’m using that term generously—stored some data in the text fields of those labels.
Allow me to repeat: He used invisible label controls to store data.
The only reasonable conclusion is that this person did not understand the concept of variables.
I gave up right there and then, went to manager #3 (since he was on paper my direct manager), and told him that I can’t work on this. They ended up contracting the programmer who originally wrote it to do the required work.
You don’t need a textbox for that
In the same company mentioned above, I was tasked with interviewing candidates for programming positions. I finally settled on a simple programming question: For your programming language of choice, write a subroutine that would take a single string as an argument and would reverse it in place.
Most people I interviewed didn’t know where to even start; the question simply seemed to make no sense to them. The remaining few who provided an answer got it wrong. I can remember only two people who eventually got it right after a nudge in the right direction.
But the most memorable interview was with someone who was MSCD-certified in Visual Basic. Unprovoked, he went on a monologue describing in detail his endless accomplishments and, his total awesomeness, and how unfair life was to him.
I had to interrupt him after fifteen minutes or so. I gave him a paper pad and a pen and asked him to write the subroutine described above.
Nothing came. And nothing continued to come for two minutes.
I offered to help. I wrote a skeleton of a Visual Basic subroutine for him and told him to fill in the rest.
Still nothing.
Finally, he began to write, and I quote:
TextBox =
“I don’t think you’ll need a textbox for this,” I said.
He crossed that out, wrote it again, and then we just sat there.
The way I had to end the interview was a sad affair that I will not recount here.
But here’s the thing: That person did not even comprehend that code could exist outside the scope of responding to UI events. Even the most basic structured programming concepts like functions and methods were alien to him.
Of Goats and Sheep
I believe that those two examples are just extreme cases of non-programming goats. Actually, I believe that they are so far up the goat end of the sheep-goat spectrum to qualify as members of the Arian-goat race.
Yet they and people like them who are simply incapable of programming have managed to coast by, jumping from ship to ship taking away padded résumés and leaving unmaintainable rubbles of code in their wake. The saddest thing is that many of them end up becoming beneficiaries of the Dilbert Principle, probably leading them to hire even more goats since they wouldn’t know any better, and the vicious cycle would continue.
Visual Basic and its ilk of RAD tools weren’t the only culprits that enabled the goats to masquerade as sheep, but they certainly helped.
But goats in sheep’s clothing aside, the damage was also extended to those who could actually program to save their lives. Most developers who stayed within the safety of the Visual Basic bubble were insulated from ever having to know about such trivia as the differences between the stack and the heap, how pointers work, the trade-offs between garbage collection and reference counting, or that reference counting even existed.
The problem is that these trivia do still matter:
Life just gets messier and messier down here in byte-land. Aren’t you glad you don’t have to write in C anymore? We have all these great languages like Perl and Java and VB and XSLT that never make you think of anything like this, they just deal with it, somehow. But occasionally, the plumbing infrastructure sticks up in the middle of the living room, and we have to think about whether to use a String class or a StringBuilder class, or some such distinction, because the compiler is still not smart enough to understand everything about what we’re trying to accomplish and is trying to help us not write inadvertent Shlemiel the Painter algorithms.
-Joel Spolsky, “Back to Basics”
Ignorance of byte-land isn’t something unique to Visual Basic, but there seems to be something about Visual Basic of old that encouraged this type of ignorance. Maybe it was because the abstraction was near leak-free, or maybe it was the IDE that tucked away the details too neatly, or maybe it was the poor design of the language itself, or maybe it was the tiering of developers into the component developers caste that did all the bit twiddling and the application developers caste that did all the dragging and dropping.
In Conclusion
Whatever the reasons were, and whatever the actual scope of this ignorance of byte-land was, it left a lasting impression among the curly-bracers that borders on being a full-blown stereotype: Visual Basic programmers don’t know the basics.
This stereotype is harsh, unfair, and is often too quickly applied to Visual Basic programmers in our community, and I would personally like to see much less of it. But maybe you can now better understand the reasoning behind it.
