I’ll admit, I’ve been slacking the T-SQL Tuesday habit for a much too long time. Almost a year since the last time I joined. Time to get back into it!

This month, our host is Kenneth Fisher (b|t). He challenges all the #SQLFamily member to reminiscence about their first ever technical job. Is this a secret plot to figure out who of us are too old to remember that far back? Or just human interest?

I’ll always remember my first!

No matter how many senior moments I have in my life, I don’t think I will ever forget my first technical job. Which, by the way, was also my first job of any kind. And some might argue it was not even a proper job.

Conscientious objector

Back in the days when I was still a sturdy young lad, the Netherlands still mandated military service. Starting at 18 (or later if you qualified for deferment due to study), all able men had to serve in the army for 14 months, mostly as training. After that, they became part of the passive defence force, not on active duty but ready to be called to arms if the country needed them.

But there was also a law for people with conscientious objections. Those who could not unite military training with their conscience could apply to this law. After an interview, if they were considered to be honest, they were excluded from military service, but had to do a mandatory social service instead. And to discourage frivolous usage of this law, the replacement service was 33% longer than then regular military service, so 18 months and 20 days.

In those days I was firmly pacifist. I opposed any type of war. And I most definitely did not want to learn the fine art of killing people. So I applied as a conscientious objector, and passed the interview. Hooray! Four months and twenty days more underpaid service for my country, but  at least my conscience remained clear.

Lucky break

Most of the conscientious objectors had to perform simple services, that required little to no education and were boring and repetitive. Typically jobs nobody wanted, because both higher educated and lower educated people in the work force would find other, more interesting and/or better paid jobs. Things like picking up trash in the city park, or ordering returned books in the public library. That’s the type of work I expected to do the next one and a half years (and twenty days!).

But I got lucky.

The day I dropped out of my IT study and indicated to the government that I was now ready to start my social service was exactly the day that a small branch of a semi-government organization needed someone with “some knowledge of computers”. Someone matched my name to that request. Not much later, I worked, through mandatory social service, as the IT person for a small semi-government chemical laboratory that specialized in monitoring water quality.

The IT infrastructure

The entire IT infrastructure of that laboratory consisted of … two computers. Both Hewlett-Packard. Both equipped with an expensive hard drive that boasted the insane storage capacity of 20 whopping megabytes. One was used for data entry. The other was used for reporting. Every day, at the end of the day, the data entry machine was backed up to tape, and then that tape was restored on the reporting computer the next morning. Yes, indeed, we had a read-only secondary replica before Microsoft had even invented the term!

My first job was to do maintenance, bugfixes, and new feature requests for the homebrew software that they were using. This software was written in HP’s own dialect of Basic, by someone who had recently left the company (which is the reason the position opened up). I usually worked with pen and paper on a printed listing of the program code to prepare a change, to minimize the time windows that I had to hog one of the computers to enter the program changes and test that they worked as I planned.

Upgrade!

As the workload grew, having to do all data entry on a single computer started to become a huge bottleneck. My boss decided it was time to upgrade to the modern world, and purchase a fancy multi-user system. Of course, this being a semi-government organization, this meant writing long reports to justify the investment – and while the final reports were made by my boss, they were all based on drafts from my pen.

We also had lots of talks with sales representatives from various companies. In the end, we decided to go with Hewlett-Packard, mostly because they promised that their Unix based systems (HP-UX to be precise) supported a special form of basic that was 100% compatible with the HP basic dialect used on our existing hardware. The sales representatives guaranteed that we would just be able to keep using the same programs wit no modifications at all.

And we, foolishly, believed them.

Crawl space

Finally, “only” eight months after we started the process, we got approval for the budget and we could order the fancy new hardware. And then, of course, someone had to install everything.

For the younger readers here, there used to be a time when networks were not wireless. The word “wireless” is not just a word without meaning. It is a word to indicate that, as opposed to “normal” networks, a wireless network does not use wires.

Crazy idea, right? To think that there used to be a time that you actually had to physically connect a wire to your computer to have network access! And yet, I lived in those crazy times.

So once we had the new hardware, guess who was the lucky guy who had to descend in the crawl space under the office floor and lay cables between the location of the central HP-UX server and all the installed terminals? Yup, that was me!

Fully compatible, they said

And then the big day came. We loaded the software on the new system, migrated the data, and started testing how the software would work. Finally able to work from multiple computers at once! We would be so much more productive!

Except …

There’s this saying that I like to quote: “In theory there’s no difference between theory and practice. But in practice, there is.”

So, did you remember those sales people telling us that the same software would still run, fully unchanged, doing exactly the same as it did before? Turns out they were right. Just a bit more right than we had assumed they would be. The software quite literally did exactly what it did before.

On a single user system, software printing a report can just send lines to the printer. On a multi-user system with a shared printer, you would expect a spooling service. But no, the software did, as promised, exactly what it used to do: it connected directly to the printer. So if two people printed a report at the same time, lines of the two reports alternated on the final printout!

And how about locking data for editing? No need to do that on a single user system right? And yes, indeed. Once more, the new fully compatible basic did exactly what the old version  did – which is to use zero locking. Multiple edits of the same data would simple overwrite each other. Reports running while someone else was entering data would report inconsistent data. Oh, what joy!

Low level

And so I spent the time after that frantically trying to modify the software. And that turned out to be a challenge. The HP-Basic dialect we had purchased and installed on the network was indeed, literally, an exact copy of the HP-Basic dialect that was designed and created for use on single-user computers. It not only ran existing software without consideration for multi-user issues, it actually had zero support for any type of feature that would be useful for a multi-user system.

There was, for instance, simply no support for spooling print jobs. So I had to modify all code that wrote reports to instead output to files in a specific directory. I then set up a scheduled job that would periodically check that directory for files and send them to the printer.

There also were no features at all in the language to support any type of locking. So I actually spent a lot of time thinking about and designing features in the existing data structure (which, by the way, was not a relational database at all; the system was using flat files for all data storage!) that I could use to implement my own locking mechanisms. And then rewrote all the parts of the software that did data access to actually respect the indicated locks.

Summary

In short, my first technical job was not even a real job. It was mandatory social service, as replacement for military service due to my conscientious objections. But it sure was a wild ride!

I did regular software maintenance. I wrote draft reports for upper management decisions. I crawled underneath the office floors with network cables. And I implemented features that most people would consider low level operating system basics. All of that for less than minimal wage.

And once my mandatory 18 months and 20 days were over? Well, the organization was apparently quite happy with me. They offered me a contract, that I accepted. My pay went up by roughly 50%, to even a bit above minimal wage. I felt rich. Looking back now, I was still severely underpaid for the work I did and the value I added. But I had enough to live, I had fun in my work, and I was a happy young man. Isn’t that enough?

Thanks

Thanks, Kenneth, for “forcing” me on this trip down memory lane. I don’t know whether any of this part of my past has any relevance for my readers … but at least I had fun writing, and perhaps you had at least a bit of fun while reading. Isn’t that enough?