I write my code in Visual Basic and you should too.
It’s not sexy, but I’m consistent and that matters in the business world.
I’ll grant that’s a cheeky headline. Maybe it alone will inspire the ire of the software development world — people will come here and comment without reading the context and such is life in the 21st century. But for those of you actually interested in why I do what I do, thank you for your time.
I’ve been working for a small mailing company for over 20 years now. They hired me right after 9/11, to start their printing department. At the time, only two of us in the company had any idea how to program: me, and the IT manager/programmer who recommended me for the job, who also happened to be a close friend.
It’s not everyone who gets the opportunity to start something from scratch. On the one hand, the task is daunting: no guidance, no help, no experienced people mentoring you, at least, not at first. You get to pick those people as you move forward. Sadly, I didn’t understand that at 25 or so, so much of what I did as I started that department up I did poorly. We ate paper like we wanted to personally deforest the Brazilian wetlands. It took days to do what, today, would take an hour, tops. We made mistakes that cost our customers time and money and cost us some of those customers. But we also made decisions that have been, on the whole, beneficial.
We decided early on to be a “Microsoft company,” to use what was thoroughly tested and popularly used as our software infrastructure. This saved us untold time and money trying to figure out, patch, maintain, worry about the legality of, worry about the support for, patch, patch, patch, and patch again some Linux distro. If I may digress a moment: it has saved the company hundreds of thousands of dollars on salary alone to pay a little upfront for Microsoft products rather than try to reinvent wheels or jerry-rig Linux into working with our equipment. If you are a small business, start with Microsoft products and move on if you have to.
So our first decision was to go with Microsoft: Windows, Office, Exchange — the whole package. This enabled our small group of two to quickly put everything data-wise in place with the confidence that once we set it up correctly, we could rely on it and move on. Twenty years later, it was an excellent decision.
That decision also meant that we got a subscription to Visual Studio, and this, in turn, meant that our internal development language was largely going to be either C++ (what my friend used) or Visual Basic (what I used). Long story short, my friend moved on to work with big name companies and get big salaries and I’m happy for him, I really am, but that means that all the code in the building is now in VB.net. The code is written by the people who stay to write it.
Now, I can read C/C++/C#. I’m not exactly comfortable writing in it because I don’t typically, but given some code, I can generally follow what it’s supposed to be doing without much help. But I chose Visual Basic and VB.Net because of one simple, inescapable fact:
If I die tomorrow, the people who will need to maintain this code will need to know what it does and won’t have the luxury of days or weeks to decipher my obfuscations. And there’s every reason to believe that they will try to promote from within rather than hire someone brand new and nobody here is trained at programming.
So I picked the easiest to read, easiest to understand, highest-level language I could and I write code that is simple and straightforward. I’m not trying to win that obfuscation game, where you write everything on one line and people have to guess what it does. I’m not interested in paragraphs of comments in my code describing what this section does. I don’t comment my code nearly as much as I probably should but that’s okay because the code makes sense as it is.
For example:
dim thislist as new list(of string)
if openfiledialog1.showdialog.dialogresult=dialogresult.cancel then return
fileopen(1,openfiledialog1.filename,openmode.input)
while not eof(1)
thislist.add(lineinput(1))
endwhile
fileclose(1)
This is my typical “Load data” procedure, across dozens, possibly hundreds of programs I’ve written. Is it inefficient? Probably. Bulky? Sure! Verbose? Quite likely, compared to many options involving streamreader. But that’s exactly why I like it, because even if you aren’t a programmer, you can read this and go, “Oh, I see it’s opening a file and adding the file’s contents into “thislist.””
Believe me, my output process is very similar, unless I’m outputting XML, in which case, those snippets are really worth using.
And yes, all my code is like this, because I am consistent. I made a choice twenty years ago, and since I’m still at the same company and nothing has happened to force us to choose differently, all the code from 2003 to 2023 is going to be easy to read, easy to understand, simple to follow, and possibly verbose and in VB.net so that whoever comes after me won’t have a hard time taking care of those customers who stuck with me through those opening months. And yes, I still have customers today who are original customers and even some who left came back after we figured out what we were doing.
That’s my lesson today, kids. When writing code, pick a language, stick with it through your tenure at that company/throughout the project, be consistent in your processes as much as possible, because one day, you might have to rewrite someone else’s code at your new job and you’ll appreciate it if they do the same.