Languages I’ve Learned, or Not — My Days in Shadow IT

In my 20+ years as a professional software developer, I’ve learned a variety of languages and tools. Of course, there are many more languages and tools that I’ve chosen not to learn, or never had the chance. Regrets? I’ve had a few…

VBA macros in Excel and Access were probably not the most conventional place to start, but those early experiences convinced me that I could make a living building the tools that help people get their work done. But an interesting turn of events led me to spend a few years learning some valuable soft skills while also getting a deeper grasp of how technology works in the real world.

Flying Under the Radar

I can’t really explain why I was afraid of Corporate IT. They hadn’t ever really done anything to me. Maybe it was something somebody said about them, and I naively believed it. I don’t know. But the fact is, I knew with complete certainty that it was in my best career interests to stay on the “business side” and avoid IT at all costs.

So imagine my concern when I heard of an initiative wherein Corporate IT was going to be reviewing the business areas that dealt with any kind of information management (at the time, I was doing mostly SAS reporting and some one-off MS Access work on a team that did some heavy-duty statistical analysis). At the end of the review, the plan was to (horror!) possibly consider reclassifying some positions intoIT.

Upper management (we didn’t call it “executive leadership” just yet) saw a relatively benign opportunity to consolidate some costs and leverage some shared technology resources. I saw an existential threat. I jumped at the first opportunity to escape the deathly grasp of Corporate IT and hide a little deeper in the business side. It may have been an overreaction, but it turned out to be a great move, eventually.

Deeply Embedded

I spent the next several years working as a business analyst/front-line support person/solo developer/technical consultant/whatever other techy stuff was needed for a small department in a small division that dealt with some very sensitive information about doctors and patients. There were days I loved what I was doing. There were other times I thought about becoming a landscaper (seriously! I bought an old pickup truck and a used commercial mower and everything!). Here are some things I learned in that role:

I learned everything that it was possible to do with MS Access, and then a lot of things that weren’t really possible to do.

I learned more than I ever thought I would want to know about FoxPro. Seriously. Those were the days of evil Microsoft. It was a crime what they did to FoxPro. Embrace, extend…extinguish.

I learned a lot about document imaging solutions, particularly FileNet (before IBM bought them).

I became very good at Crystal Reports. I think that was about the time I decided to become a landscaper.

I learned a lot about batch processing and all the stuff that happens behind the scenes to keep systems running correctly.

I learned that ad hoc SQL updates to the production database are not something to be approached casually. I won’t go into how I learned that.

One thing I didn’t learn was .NET. Not that it didn’t exist. There just hadn’t really been any opportunity for me to get into it. That all changed when a job offer to work on a small (me and one other guy) development team fell out of the sky.

It was an opportunity I found hard to resist. I knew my skills were stagnating. It was past time for me to have moved away from VBA and VB6. This new job was still safely on the business side (or so I thought), and it offered the opportunity to update my skills to .NET. It was perfect!

Except it wasn’t. I finally had the tools, and I quickly learned how to use them, but I was in no way prepared for the challenges I would face.

Learning C#

Before I explain that, since I’m supposed to mostly be talking about languages, let me say that it was very obvious to be from the very beginning that VB.NET was, well, just not going to be the best investment of my learning efforts. Microsoft had a huge I mean huge customer base of VB6 developers (I was one of them, remember) who had invested gagillions of hours into building millions upon millions of RAD applications with VB6. M$ (I had to do it) just couldn’t walk away from that. But whether or not you agree with the wild-eyed theory that they were trying to grab market and mind share from Java, or acknowledge (as was obvious to us hard-core Softies at the time) that they were just plain innovating, it’s clear that VB6 was not the way forward. So they came up with an ingenious solution: a “virtual machine” like Java’s, but one that would support a new “modern” version of VB in addition to the new flagship language C#.

The only problem was that it was 100% obvious from the very beginning — to me at least; somebody who was there might present some actual facts to contradict me, but this is how it looked anyway — that .NET was designed around C# and C# was designed around .NET and all the other stuff, including VB.NET, J#, Managed Extensions for C++, COBOL.NET (was that ever really a thing?!), etc., was bolted on to address the concerns of one customer segment or another. There was only ever one first-class citizen in the .NET family.

Long story short, I learned C# instead of VB.NET. Being already familiar with JavaScript, the C syntax was easy. Being already familiar with VB6, once I learned C#, I already knew VB.NET. I didn’t expect I would ever even use VB.NET. More on that another time.

Seeing things differently

I mentioned unexpected challenges. Well, I had some big successes early on. My very supportive management team gave me some interesting projects to work on, and I jumped in and knocked them out. It was a validation of what I had always heard, and the management team firmly believed, that building tools at the department level was way faster than asking Corporate IT to do things. In fact, we had a long list of things we had asked Corporate IT to do and were still waiting for, while we were dancing around getting things done at record speed.

But as time went on, I started getting slower and slower. I was juggling literally 20 or 30 things at a time. Anything that took more than a few hours to finish, no matter how urgent, never got finished, because something even more urgent took its place. Priorities were constantly changing. Quality and maintainability were always at the bottom of the list. We were not on a sustainable trajectory.

Finally I began to understand. The things that made Corporate IT seem slow were the same things that it possible for Corporate IT to continue to deliver at a some kind of pace. There were processes and controls. Work was prioritized at a strategic level, not department by department. Tools and skills were managed centrally. Shared services (databases, servers, network infrastructure) were provided in a controlled manner. Developers were shielded (somewhat) from the day-to-day chaos of the business. It wasn’t perfect, but it was a real system.

Even though I was “shadow IT”, I had developed some excellent working relationships with “real IT”. I’m grateful to this day that I was given the opportunity to “cross over to the dark side” and begin work in an actual development shop. More on that next time.