Languages and Programming Tools

This post and others like it relate back to an introductory post that explains the point. This is an edited variant of something I wrote in 2007, in this case, the part on programming tools, languages and such. As usual, I may be forgetting some that would fit here, especially if I dabbled more recently. Also, lest one get excited, just because I have laid hands on a language, perhaps written a “hello world” program with it, maybe compared its language and syntax on paper, that does not mean proficiency, or even familiarity. It’s merely indicative of a bit of added depth to my overall background. The only things I’d claim proficiency in are VB through 6.0, Wordbasic from Word 6.0, and perhaps VBA as applied to later versions of Word and Access. In no particular order, the list as best I can remember…

Visual Basic 3.0 through 6.0
QuickBasic 4.5
Professional Devlopment System 7.1
Visual Basic for DOS
VBA
WordBasic
Visual Basic.NET
VBScript
JavaScript
PHP
J
Borland C++
Borland Delphi
MS Visual C++
C#
BASIC
Pascal
Cobol
HTML
Visual Interdev
Visual J++
Visual FoxPro
Rexx
MS-DOS batches
Perl

I think I’ve looked at other things like Python or Ruby, but I can’t remember exactly which, so I left them out of the list. I definitely played with, and helped a friend with, Perl. J is something I discovered a couple years back, downloaded and played with a bit. I find it fascinating to look at new languages.

The first six items on the list I supported for Microsoft to some degree or another. Officially in Word support we did not support macros, but that was my specialty and we tended to make exceptions to some degree. That carried over into automation of Word from VB programs, which later meant becoming familiar with VBA when Wordbasic was replaced. Right around the time I migrated from Word to VB support, the first Word macro virus hit. Because I’d shown you could do some mischievous things with macros, colleagues jokingly suggested I might have been the source. Flattering, in a twisted sort of way.

The interesting thing about supporting a programming product is that you get a huge range of exposure that you might not get coding a project, but you don’t get the intense depth in one area that coding a project that uses certain features might impart. You also learn how to find things out in support, which is extremely useful. I always emphasized when providing references that the candidate in question might not know a specific thing – there’s too much for anyone to know it all pat – but troubleshooting and research ability on top of the broader knowledge are a huge benefit. Sometimes it was depressing talking to software developers and realizing just how bad many were, yet they were making real money. Sometimes it was weird having limited knowledge about a customer’s question, compared to them, yet having enough knowledge, access to information, and alternate perspective to cut right to it and look like a miracle worker. Despite having started the call in a panic because you didn’t know much about X.

There were obsolete products we supported for a time. The training was all about VB3 and then VB4. If someone called about the DOS versions of Basic or VB, it got interesting. Even when it wasn’t someone doing something goofy like running QuickBasic from floppies on an ancient PC without a hard drive. (Perhaps the equivalent in Word support was when someone couldn’t make Word 6.0 run on a 286, where I congratulated them for getting Windows to run and could do nothing for them.) It helped that I had dabbled with BASIC off and on since I learned my first bits of it circa 1977.

Before I even got the job in Word support, I had bought and installed Borland’s C++ product, dabbled with it slightly, and eventually read a book and tried the code it taught. The Absolute Beginner’s Guide to C Programming or something like that; great book. I dabbled just as slightly with some of Microsoft’s versions. More recently I tried to run and compile a component one of my old partners wrote in VC++ to be used from Prometheus, our case/document management product.

Pascal and COBOL were classes in college. That and I dabbled with Delphi, which used a form of Pascal. What was weird was when I read the book Code Complete, it gave examples and comparisons in various languages, and Pascal always looked surprisingly familiar to me. It’s kind of like French from 7th, 8th and 9th grade. I can see or even hear French and it doesn’t sound alien to me the way another language other than English or German might. Years later, when I took German, I’d find myself needing the German word and inexplicably remembering the French word for something, and usually forgetting the German in the process. I’d have told you I’d forgotten it long ago, but there it was, bubbling up.

It’s hard not to have learned some HTML, or at least gotten comfortable looking at it, after having web sites for seventeen years. Still, I am not a wizard and like tools that make it easier.

I poked Rexx with a stick when I played with OS/2 Warp, having seen much discussion of it ahead of time among Team OS/2 denizens. I don’t remember anything, but I know I touched it and was naturally curious after hearing so much.

Whereas I did a lot with DOS batch files, which do count as a form of programming/macro language/tool. I still do. My most recent VB program was a quick utility to read a couple of fields from an Access database and write out a text file with traditional file I/O (rather than referencing FSO – File System Objects – and going beyond an EXE that would run fine after a straight copy to the target machine). The fields were original and current paths of archived documents. Restoring them called for a mass of copy commands using the two paths. Nothing fancy.

It’s funny; I could probably have gone ahead and done programming for a living. I’m better than I generally give myself credit for, and certainly more of a natural, but I tended to be surrounded by people who were prodigal by comparison. In a business started originally to write software, that was why I was the business guy, along with some testing, user interface work and such. I’m good at orchestrating the activities of other people, understanding requirements, and grasping a whole project. I’m good at debugging existing code. I’m good at making attractive and usable interfaces, or improving existing ones. Sometimes I think about it and it seems cool. Sometimes I think about it and it sounds onerous to have to maintain that level of concentration all day, each day. Which is not actually how it works, because that just isn’t possible, which is one reason why production of code isn’t as voluminously fast as some less technical types might anticipate.

When dotnet came out, none of us were doing Visual Basic support anymore. That meant we wouldn’t receive the customary training and were on our own. While I and others checked it out on our own to some degree, which was frustrating when it took forever to figure out how to do the equivalent of Form2.Show and other simple things that were the beauty of VB, it wasn’t the same. So I organized a couple of day long sessions at my old office. A bunch of us gathered around several computers and banged away at it, getting pointers from anyone who knew more about or was faster to figure out a given thing. It was excellent. We also had some partial training material from within Microsoft to look at. Other than that and playing with it (and C#) a bit before and after, I’ve not used dotnet. Code I’ve maintained or worked on has continued to be in VB6. There was no reason to change that.

Oh, forgot VBA. I’ve used it directly and through automation in MS Office products. I’ve also looked at the VBA kit that came with MSDN, and in at least one non-Microsoft application. I seem to recall that having been Lotus WordPro, and the app-specific commands having seemed rather obscure even by Word VBA standards. One of my partners created an Access-based application using VBA, a custom billing program, for a groundskeeping business. I helped with it some, and was primary contact for the customer. Actually, I ended up doing most of the support, debugging and testing. It seemed best to use Access directly, because of the convenience of generating reports as invoices. It was so shaky (mainly prone to collapse under the slightest bad data) that a real program in VB might have been better and not much more time-consuming. We ended up charging what the customer was willing to pay, which was about a third of what it was “worth” by the hour. The partner had nothing else doing at the time. At any rate, that was a big education in Access VBA.

There you have it. This will sort of overlap one of the remaining sections, in which I list and discuss software I was involved in creating (or attempting to create) on at some level.

Next up, server software.

This entry was posted in Experience, Job Hunting, Skills, Software. Bookmark the permalink.