Introduction

This document describes my life as a computer programmer, a slightly less formal and more personal adjunct to my CV.

First steps

My first computer was a Sinclair ZX Spectrum, purchased sometime around Christmas '82, near to my 10th birthday. The first one died not long after we got it but its replacement lasted a good five years before I upgraded to a slightly later model.

By modern standards, the Spectrum's capabilities were meagre: 48K of RAM, a 3.5MHz microprocessor and no mass storage except for audio cassette (floppy disks were only to appear for the Spectrum much later in its life). But the Spectrum was a triumph of industrial design. It looked like a little bit of the future: black, compact, inscribed with arcane symbols. The design made virtues of the machine's shortcomings, for its small size and cramped rubber keyboard were the result of extreme cost-cutting on its manufacturer's part. Other home computers of the time had luxuries like full-size typewriter keyboards and proper sound. The Spectrum had a rubber mat, morbidly nicknamed the "dead flesh keyboard", in lieu of a real keyboard and a built-in buzzer that could make assorted farty noises and that was about it.

In a way, the Spectrum and its contemporaries had a number of advantages over modern PCs. They represented a known quantity whose workings could be internalised by even a ten-year-old kid. You knew were everything was; even today, I can still remember the locations in the Spectrum's memory where the screen image was stored, where the routine to print characters on the screen was located, even the location where the duration of the clicking noise the Spectrum made when you pressed a key was kept. Modern PCs are changing all the time: software is installed, updates are downloaded, dodgy Web pages load who-knows-what behind your back. Lacking a hard disk, the home computers of the early 1980s could be restored to a pristine state by unplugging them. Short of hardware failure, they could not be rendered unbootable in the way a modern PC can be if its hard disk is trashed. This feature of early home computers, I believe, gave their users the courage to experiment with their machines in a way that is rare nowadays. In some ways, I was fortunate to learn about computers at this time, when they were less complicated and fragile than they are today. This gave me the confidence to explore and truly understand them. When I see friends and relatives today trying to get the hang of the expensive computer they have bought and the almost fearful way they use them, I can't help but think that something got lost along the way.

Another thing about the home computers of the '80s was that they were unashamedly computers for programmers. When the Spectrum was plugged in, it dropped you immediately into its BASIC interpreter. There was no "operating system" or "user interface" in the modern sense. Off-the-shelf software like spreadsheets and word processors (and of course games) were available for the Spectrum and its ilk but the implication was there that if you wanted the machine to do anything at all, you'd best roll up your sleeves. This is a great failing with modern PCs, most of which ship with no programming language tool to speak of. Call me prejudiced, but I believe that a person who cannot program will only scratch the surface of what the computer is capable of.

It is difficult to explain what the sensation of programming can be like to someone who doesn't do it. It can be a literally mind-expanding experience, a state of concentration so intense that hours can pass without notice. I imagine that most skills have this transcendent quality to them but I think it is stronger with programming because it occurs entirely in one's mind.

Spectrum BASIC was slow; to get any kind of performance out of the limited hardware, you needed to learn machine language. The Spectrum's microprocessor, the Z80 (variants of which are still used in embedded systems today) had a well-designed instruction set but machine language programming is a tough business. In some ways, it is great discipline for a programmer: every task must be broken down into smaller steps than those required by a high-level language like BASIC; and every machine language program must be designed in the knowledge that any mistake is likely to crash the machine hard, taking any unsaved data with it. Machine language programming is akin to recreational bomb-defusing but the power rush — the knowledge that one has complete control over the computer — is irresistable, especially for a 12-year-old kid!

Machine language programs are usually created with a program called an assembler. I didn't have an assembler; I had to write the machine language instructions out by hand and convert them to binary code by consulting a table of the Z80 processor's instruction set. Consequently, I never wrote any large-scale machine language programs on the Spectrum; instead, I wrote the bulk of my programs in BASIC, with only the stuff that really needed the speed boost coded in machine language.

There were always computers around. My father worked in IT and would bring the latest samples home. I remember: an old acoustically-coupled modem, from the days when the telephone companies would prosecute you for plugging anything but a handset into their precious network; an early laptop that used bubble memory (don't ask) cartridges instead of disks for storage; and a strange green-screen PC called a VAXMate that ran an odd program called Windows 1.0...

The 1990s, GUIs, SQL

In 1990, I got a summer job where I got a chance to see a computer of the type that would become common over the next years: an Apple Macintosh II. I had already seen and used GUI-based computers — an early Windows PC and Amigas in the houses of wealthy friends. I even had the loan of an Atari ST for a while. But this was the first GUI-based computer I had used in earnest. It was a beauty, especially compared to the PCs of the time. I learned to program it using HyperCard, one of the nicest programming environments I've ever used. By today's standards, the HyperTalk language was slow and verbose, its object orientation practically non-existent. But to a person first dipping their toe in the waters of GUI programming, it was great. HyperCard is no more, dying a slow death by neglect, but I wrote a number of HyperCard stacks that I used for a long time afterwards, including one for laying out circuit diagrams that I used to make my University lab reports pretty.

In the early 90s, I attended University College Dublin where I obtained my degree in Electronic Engineering. I opted for an EE degree partly because, cocky little bugger that I was, I figured I knew all there was to know about programming and it was now time to learn about the hardware!

It's said that at some point, probably in the mid-50's, it was possible to condense the sum total of human knowledge on Electronic Engineering into a modestly sized bookshelf. Those times are long gone. Even looking back on it now, the breadth of that course was staggering: circuit theory, analogue and digital electronics, solid state physics, transmission line theory, antennas and radiation, electromagnetics and control theory, the list goes on. And the math! Differential equations, complex analysis, linear systems analysis... at some points, it felt like we spent more time in the complex domain than in the real world. I'm still faintly surprised that I ever managed to remember enough of it to get me through my exams. And though the course was often onerous, tedious and in some ways only tangentially related to my career, I still think it was time well-spent. It taught me discipline. It honed my problem-solving skills, how to break a seemingly intractable problem in manageable pieces, how to stand on that fine line where science meets art and try to pull the best design you can from the mess of conflicting constraints.

Where IT was concerned, Engineering was a little backward. The Engineering language of choice at this point was still FORTRAN, the grandaddy of all programming languages, which we duly learned but which I personally never developed a great love for. At some point, some unfortunate lecturer from the Department of Computer Science was wheeled in to teach us Pascal (Again, not a language for which I have a great deal of affection but I still think Delphi is one of the most criminally under-regarded development environments ever built.) But the up-and-coming language was very much C. Although it wasn't formally part of the curriculum yet, many staff and students in the Department had begun learning it and I did so. The preferred C development tool was Borland Turbo C, an early example of what came to be known as an Integrated Development Environment: an editor, compiler, linker and debugger all in one. It is still available as a free download. Just over 1MB in size: the developers of modern behemoths like Visual Studio and Eclipse, take note!

Many people find C impenetrable, particularly its concept of pointers, but pointers are second nature to anyone who has done machine language programming. In many ways, C was an ideal language for me because it hit the sweet spot between the power and flexibility of machine language with the ease-of-use of a higher level language. Although C has declined in recent years, supplanted by C++ and Java, I still enjoy programming in it.

My final-year project was on a type of electronic device called a Field-Programmable Gate Array (FPGA), a type of programmable chip. As a person whose soldering skills are rudimentary at best, FPGAs are a great boon: they allow you to design a circuit using CAD software on a PC and then download that circuit description onto a chip that then behaves like that circuit. FPGAs are used extensively in many sectors to prototype new kinds of chips but they are still little-known in the mainstream.

During my time in UCD, I was working in summer jobs. It was on one of these jobs that I got my first exposure to Visual Basic. Version 1 of Visual Basic was a shadow of what it was to become (I remember it came on 3 floppy disks) but had some of the same magic as HyperCard. Plus, it was BASIC, or at least a dialect thereof: my first programming language. It was through Visual Basic that I first began to experiment with relational databases as VB came bundled with the Jet database engine (the same database behind Microsoft Access)

From an Engineering perspective, SQL was something off the beaten track. Most engineering databases (for example, the component libraries used by Electronic Design Automation software) tend to be proprietary and non-relational. Nevertheless, despite SQL's often clumsy syntax, there was an inner elegance to the concepts of a relational database that appealed greatly to me. Later, when I studied the area more closely, I found that many of the database design techniques I'd discovered and started to use because they "felt right" were well known and considered to be "best practices": entity-relationship modelling, database normalisation.

When I graduated in 1995, the "Celtic Tiger" was still very much a cub and job prospects for Electronic Engineers were slim — especially for Electronic Engineers with less than stellar qualifications like me! However, I got a job working in Corel Corporation as software localisation was (and remains) a big part of the IT sector in Ireland.

The first year or so of my work with Corel was overseeing the localisation of the help files that shipped with CorelDRAW! and other products. Creating Windows Help (WinHelp) files was a bit of a black art, never mind translating them into umpteen languages, but I liked the job. In my opinion, WinHelp is one of the great unsung masterpieces that Microsoft has produced, a technology that never got the attention it deserved. The HTML-based system that replaced it was nowhere near as good. Apparently, WinHelp has finally been phased out in Windows Vista. It's sad to see it go.

Although the pace of work was often hectic in Corel, it could also be fun. There was a great team spirit there with people from all over Europe and the world trying to get the gold disk out to the duplicators before the deadline. It was probably in Corel that I picked up some more "human" skills than I had hitherto: an appreciation for good documentation and clear writing, for user-friendly and culture-friendly software, for software development as an end-to-end process rather than a simple matter of grinding out code.

During the time I was working in Corel, I began to experiment with Linux in my spare time. I had heard of Linux from friends who were excited at the prospect of a freely-available Unix-like operating system for PCs. It was even invented by a Sinclair alumnus; apparently, Linus Torvalds, the creator of Linux, first learned to program on a Sinclair QL, the Spectrum's big brother.

When I first started using Linux, it was still fairly rough in parts and support for hardware was thin on the ground. But it was a solid operating system with lots to learn about and explore. Unlike many modern operating systems that hide their workings behind layers and layers of distracting GUIs, the innards of Linux are still available to the curious. Linux is a real programmer's system too, with lots of free programming languages and tools. I began to learn PHP, which eventually lead to me writing a Web-based accounts package in that language which I've been adding to since.

In 1998, I left Corel and went to work for ESB International Computing. This is where I did the bulk of my work as a developer and where I learned Oracle. Having become quite proficient with developing in Access and VB, Oracle was a new challenge. I worked on some very large databases for the ESB, including their systems for managing their call centres and the public lighting network in Ireland. The public lighting database was written in Oracle but most users of the system accessed it via handheld PCs. These were DOS-based and somewhat antiquated even when I took over ownership of them, but it was a very satisfying and fulfilling job knowing that some guy halfway up a pole in the middle of nowhere had his job made a little easier.

In 2002, I began work on the Market Opening project, initially in a part-time role and later full-time. The Market Opening project was an enormous project undertaken by the ESB to make their IT systems ready for the deregulated energy market. Many of ESB's existing bespoke systems were to be replaced by an “off the shelf” SAP system and the remaining systems would need to be able to talk to this new system and to each other. It was decided that an EAI (Enterprise Application Integration) system was necessary. I was involved in the site visits and selection process. In the end, the e*Gate Integrator product from SeeBeyond software was chosen.

Generally, an EAI system consists of a series of adapters that know how to talk to various kinds of systems (for example, enterprise systems like SAP and Peopleware, or more low-level protocols like FTP or HTTP), a messaging layer that allows data to be sent between systems, and a transformation layer that allows messages to be converted from one format to another (for example, a SAP IDoc message to XML). Amusingly, EAI-type systems are sometimes referred to nowadays as Enterprise Service Bus (ESB) systems.

The e*Gate product used Java as its transfomation language. I designed and implemented data flows to capture error-handling and auditing, as well as the data flows between the new SAP system and ESB’s meter-reading application.

In 2004, I left the ESB and became an independent contractor. In this time, I have worked for a number of different companies and organisations, of all shapes and sizes. I have picked up some new skills — notably Microsoft SQL Server and .NET.

Although the years spent with computers is only a fraction of the time they've been around, I've been fortunate enough to have lived at a time when a great deal of change has taken place in the world of computers. The next time you are walking through your home town, take a look through the windows of all the various office buildings you pass and try to spot a desk that doesn't have a computer on it. That level of penetration was nearly unthinkable when I first started mucking about on a rubber-keyed Spectrum 25 years ago. But even as some things have changed utterly, some things have remained stubbornly the same. Many people are still intimidated by computers. Much software is poorly written or badly documented. Many of the "holy wars" of my youth — Spectrum vs. Commodore, BASIC versus machine code — are still being prosecuted today with equal vehemence — Macintosh vs. PC, Java vs. .NET — and with about the same level of intellectual rigour; only the names have changed. At the end of the day, computers have a job to do and computer programmers have the responsibility to pick the right tool for that job.

Looking forward to the next 25 years...

Ken Keenan