Languages I’ve Learned, or Not — the Early Days
I’d like to start a series of posts about languages I’ve learned, and languages I haven’t learned, or know only a little about. This series will be part of a larger series of things I’ve learned, or not, including a variety of tools and practices that make up the profession of software development.
This series is in large part a retrospective on my 20+ years of software development. One of the hardest parts of maintaining a viable skillset as a software developer is knowing where to focus your ongoing learning efforts. Overall, I think I’ve done a good job, but there are a few things I wish I had learned early on, and a few other things that didn’t prove to be worth the effort.
I’ve got a lot of good work left to do, and I’m still learning and growing. At the same time, I hope my experiences may be helpful to some who are just starting out in the industry. I’d be grateful for your feedback.
Let’s start at the very beginning…
BASIC on TRS-80
Full disclosure: I’m not really an alpha-geek. I enjoy creating software and solving problems, but I was not one of those kids who stayed up all night in the garage (didn’t actually have a garage) poring over an enthusiast magazine, trying to put together some kind of homebrew microcomputer in a wooden box. But we did have a TRS-80. I don’t know why we had a TRS-80, but I had a lot of fun with it. We had a cassette player with a bunch of games, which was cool — you had to fast-forward the tape to a certain number on the counter, press Play, and then type a certain command in the computer — but I also figured out how to do some simple stuff using the version of BASIC that shipped with the TRS-80.
So if you’re looking for some geek cred, there it is. Actually, I can even go farther back, to my days playing Oregon Trail on the Apple II, but that wasn’t really programming, and I was just in first grade.
But after the TRS-80, I didn’t really do much with computers at all until after high school. I do remember using the DOS version of WordPerfect in the computer lab at the university, but again, I was just a user.
VBA: Fascination, Disillusionment
The first code that I ever got paid for was Excel macros written in Visual Basic for Applications. There, I said it.
It actually started from laziness. I was employed as a low-level analyst on a team that did some deep statistical analysis on the state’s Medicaid population. My part was mostly mechanical, which meant incredibly tedious. I have a pitiably low tolerance for being bored, so I immediately started looking for ways to make the work more interesting, or at least get it done faster. That’s when I discovered macros. I found that I could record actions in Excel, then look at the VBA code behind those actions. It was amazing!
Then I learned you could do the same thing with Access. I was hooked. Now, I wasn’t just getting out of busywork, I was actually creating useful tools! To this day, I still feel that same sense of amazement when something I’ve created actually comes to life and solves a real problem somebody has, or adds real value to their workday.
But there was a dark side. VBA code lives inside the Microsoft Office files it’s created for. There’s no source control. There’s little opportunity for separation of concerns. Unit testing? Not impossible, but not really done. So all the nifty tools were essentially unmaintainable. But it started me down a path, and I’m glad for that.
VB6 and My First Lesson on Technical Debt
I guess you could say my first “real” programming language, in the sense of being able to build independently deployable components, was Visual Basic 6. Of course, there were versions of VB before 6 — VB4 seems to be the point in time when it started to really be used for serious development — but since 6 is the last pre-.NET version, that version is sort of where that particular programming language froze in time.
VB6 was an essentially proletarian language, designed for the masses of working programmers, not the rarefied elites working in C and C++ (or, in actual fact, the much larger proletariat of Cobol programmers). A VB6 programmer could get stuff done. It was pragmatic. It was productive. And it was a long-running trainwreck in the making.
A lot of pre-.NET VB code was written on Windows 3.1 or Windows NT. Some was written on Windows 2000. An even smaller proportion was written on early XP releases. We’re talking late 90s, early 2000s here. But I can guarantee you that there are still functioning applications, including some mission-critical ones, that were written in VB6 and haven’t been touched since then. They’re holding up technology upgrades because it’s hard to get the runtimes working. They’re hindering business initiatives because core operations depend on software that would be too costly to change. That $20,000 (or, OK, maybe $200,000) we saved in 1998 by building the system quickly in VB has cost us ten times as much in lost productivity and lost opportunity.
Then, as now, there are tools (and developers) that promise quick development turn-around, but they focus on the financial cost savings and don’t always tell you about the “technical debt” you’ll be taking on.
Like financial debt, technical debt isn’t necessarily a bad thing. If you want to open a bakery, you will need a place to bake stuff, and a place for your customers to come and get the stuff you bake. So you borrow money to build a bakery, and in time, you pay off that debt from the proceeds of your cakes and pies.
Similarly, if you see a business opportunity with a limited window, you may simply not have time to create the most perfect software to capitalize on that opportunity before it slips away, so you make compromises. You eliminate nonessential features. You compromise on performance or even robustness (but hopefully not security or correctness). Very often, you lower the maintainability standards. That’s a legitimate business decision. And ideally, if the opportunity is realized, you then have the time and resources to “pay off” that debt by improving the performance and maintainability and can even afford to add useful features.
In my early days of developing software, enamored with all the things I could do, I didn’t really understand technical debt. I couldn’t see the long-term costs of doing things quickly and cheaply. It was a lesson learned through hard experience. It pains me to see business leaders still today who don’t understand the real cost of building things too quickly and (nominally) cheaply.
SAS, a Brief but Fun Diversion
I’ll end my trip down memory lane with SAS, which, for a brief time, was my primary working language. SAS, for those who aren’t familiar with it, is a “4GL”, a fourth-generation language (where C is the 3GL, assembly is the 2GL, and machine instructions are the 1GL); in other words, SAS is built on top of C. It has a mixed imperative/declarative syntax based on “steps”, which can either be one of a number of “procs” or a “data” step. A SAS expert could give you a better summary, but, essentially, its purpose is to apply various transformative and analytical techniques to a set of data.
SAS has a macro language, which is similar in purpose to C or C++ macros. Once upon a time, I was able to figure out how to use the macro language to use DDE to insert data into specific cells in Excel. Fun times.
A lot of my work involved using SAS on Windows to access a DB2 database on the mainframe, using, essentially, remote method invocation to get a SAS instance running on the mainframe to read the data and return it.
Working in SAS actually broadened my horizons about what programming really is. I’m grateful for the experience, and in some ways, really miss working in SAS.
Moving On
I did a lot of different things in those early years, including some things that weren’t exactly what I’d consider software development, but all of which helped me to be better at what I do now. Then, around the mid-2000s, I took on a new role where hands-on programming was my 100% focus. I’ll talk about that next time.
