Schooling and Spitfires
My career started with an electrical engineering apprenticeship. Although I did not realise it at the time, this gave me invaluable skills and knowledge that I would use my entire career.
The company that I served my apprenticeship with was an aluminium company in Banbury by 
the name of Alcan. It is a sad fact of life that due to the decline in British engineering, many of these types of factories no longer exist.
The factory where I learned on-the-job skills working on cool machinery like extrusion presses, rolling mills and induction furnaces, and was famous for making aluminium sheets to build Spitfires during WWII, is now an Amazon warehouse (sad face).
My training lasted for five years, and in that time, we were taught a variety of engineering skills ranging from drilling, filing, welding, sheet metalwork, turning and milling, as well as training in electrical and electronic systems used in both home and factory installations.
We had exams every year in theory and practical, and at the end of the five years came out with a degree-equivalent engineering qualification. (and with an Engineering Industry Training Board certificate signed by Hugh Scanlon !)
Once qualified, I worked in the drawing office as an Electrical Draughtsman. This included working on upcoming projects such as upgrading the control systems on one of the extrusion presses.
This is where I learnt about programmable logic controllers (PLC’s), which are essentially computers designed to operate, control and monitor complex machinery – such as extrusion presses.
At this time, many factories, including Alcan, operated a ‘closed shop’, meaning that everyone who worked there had to be a member of a trade union.
With this came strict rules about how you did your job. For instance, as an office worker, I was not allowed to use any tools or do anything that would not be part of my job.
I got told off a few times when helping one of the electricians or fitters when they were busy fixing a breakdown. I found this restriction quite frustrating. This, coupled with my increasing interest in computers, was how I made the move into IT.
The start of IT all
I started as a workshop engineer working for a company in Bicester that sold IBM PC’s and daisy-wheel printers, so I turned in my drawing board and pens for a soldering iron and oscilloscope.
As a workshop engineer, everything was repaired to component level. When a faulty printer or whatever came in, you would determine what sub-assembly of the printer was faulty, and when you had done that, using circuit diagrams and an oscilloscope, you would find which component on that sub-assembly needed replacing.
I did that for a couple of years; over time, you see the same faults and the same components failing, and it got a bit routine, so I looked for something more challenging.
I moved to a larger company, part of the Plessey group which was a DEC reseller. DEC (Digital Equipment Corporation) was a producer of minicomputers such as the PDP-11 and VAX.
Plessey would buy in the DEC processors and add their own disk drives and tape drives, which would be a cheaper option than prospective customers buying a complete system from DEC themselves.
The product range was larger, and the equipment was a lot more complex. I started off fixing VDUs then moved on to larger items like disk and tape drives.
Again, everything was repaired to component level, even where sometimes we had the AC motors in the disk drives experiencing bearing failure, I would use my engineering skills and strip the motors down and replace the bearings, saving on refurbishment costs.
The workshop was a happy place. We all worked together, had our own areas of expertise, and if one of us was snowed under, we would help each other.
I would make sure I always kept up to date with my backlog of repairs. I would try and get all my repairs done in the morning and then work on my working environment in the afternoon.
For example, I wrote a Cobol database to record all my repairs (my wife was a Cobol analyst, so I had some help).
When a faulty tape or disk unit came in, I could look up its repair history before I started working on it.
We would all annotate our circuit diagrams with expected waveforms and amplitude on our scopes, so when you were finding a fault, it made it much easier and quicker to trace the problem.
Driving ambition
When the DEC bubble burst and the mini-computer market was moving towards RISC-based processors of a more modular design, I moved to a company dealing as a SUN Microsystems reseller.
This was my first experience with a UNIX operating system. I also changed my role, moving from the workshop to field service.
Field service is different for a few reasons: you have direct contact with the customer, the emphasis is on solving whatever the problem is as quickly and efficiently as possible, and to be smart and presentable while you do so.
There is also a lot of driving. I had a company car, which, after the extra taxation, is not that much of a benefit.
It is also seasonal, in that working field service is fine in the summer with more daylight, but not so fine in the winter if you have a 2-hour drive home in the dark and rain.
Having said this I enjoyed field service, our customer base was a lot of academic sites, and the people I dealt with were usually friendly and cooperative.
You do get the odd grumpy customer, but you have to realise that their day has mostly been spoiled by their computer system breaking to some degree and depending on how long they have had to wait, depends on how you are likely to be received.
Usually, they are glad to see you, and all you can do is apologise on behalf of your company if the response has not been as quick as they might have hoped.
I worked in field service for quite a few years and although the company I was working for went through a few permutations of buyouts and takeovers I found myself in quite a senior position as field service manager responsible for 20-30 field engineers.
More office-based with a few visits to customer sites. I was now in a managerial role spending all my time in meetings or on the phone.
Some people may see this as progression, but it was not a place I wanted to be in, so I left and joined a much smaller company specialising in workstations and NAS file servers.
Role back to hands-on
The workstations we were dealing with were SUN – based as before, and the file server was x86 hardware with high-end raid storage attached.
The software / operating system was bespoke and written by a US company, and was distributed on a 3.5-inch floppy disk!
As the NAS fileserver was our product, we used to spend time tuning different settings, CPU and memory types, raid controller settings, etc in order to get the best performance out of the product.
We installed them in various sites around the UK and we also had a partnership with a German company, so I spent some time at various German sites installing them over there.
The NAS work died down a bit, and we were looking for other areas of work. The owner of the business had good relationships with a lot of academics who were talking about building a parallel computer from low-cost commodity hardware called a ‘Beowulf’ which you connect in a small private network, and by using various open-source libraries and applications that share workloads by communication with each computer, or ‘node’, the group of machines act like a single, larger parallel computer.
This computer could be used to solve complex scientific problems, whereas before this could only be done on a larger, much more expensive system like a Cray.
This could be of great interest to academic sites that still had these complex problems to solve but did not have the budget to afford a supercomputer like a Cray.
I was intrigued and fascinated by this, but wondered how we could make what was basically a low-cost DIY parallel computer that some academics were experimenting with, into a viable, sellable product.
My boss was talking with some scientists at Imperial college who have a parallel computing department about how to build and run codes on one of these parallel machines, and from those conversations we came to embark on a project that would completely transform the company I was working for, and was the start of my HPC career.
This is just the beginning of my evolving HPC career. There’s more to come, so keep an eye out for the next chapter in my journey.
Paul Ingram
Senior Principal Consultant
Red Oak Consulting
