Category: Work History

Math 101

Did you ever see one of those trivial sums on Facebook, which looked so easy and yet you knew there must be some trick going on? Something like:

3 + 2 × 6 = ???

Well, you’re right.

Because we, in English, read from left to right. But in math, you don’t. In math, you work certain sums out before others, and not necessarily in the same order that they appear on the page. This is a standard mathematical idea, usually called the order of precedence, Wikipedia talks about it here. So, something like a × happens before a +, and so on. Working in computing I’ve come across this a lot, and the rules in full are pretty verbose, but the basic thing is that you perform some operations before others. Left or right matters less. It matters for some things, like ÷, but mostly, no.

So, if somebody presented me with a line of computer code which said,

3 + 2 × 6

the first thing, I would probably fail its review, because it is ambiguous. In fact, it should be written as

3 + (2 × 6)

which gives the exact same result, but by introducing the brackets, you make it obvious. It’s easier for the reader to see what is going on, and that has always been my #1 aim when reviewing computer code.

The bracket says perform me first, so you can see we are no longer in the realm of left-to-right.

Once you realise that, the answer is trivial.

3 + 2 × 6 = 3 + (2 × 6) = 15

Easy, huh? But not so easy as you might think. Even Microsoft’s own calculator (on my PC) gets the sum wrong, unless I help it out by adding the brackets.

A Hot Date

Written for Fandango’s One Word Challenge (FOWC), engine.

I’m gonna post today about a component I once wrote in my professional life, which was a date engine.

For part of my professional life I was a consultant to an asset management company. Asset Managers run funds, hundrends of them. The way each fund is set up might be different. Half of it might be based on a commodity, like gold or silver, and half of it might be based on a spread of stocks in such-and-such a sector. Or, you might have a fund which is based on other funds. For example a fund might be based a third on Fund A, and two-thirds on Fund B. The possibilities are endless.

We use the term pension fund, and in fact the two are very similar ideas. The plan is just to invest into a fund, and allow the fund manager to grow the fund, without having to worry about too much detail. In fact, the funds we handled were popular with many pension companies.

Unlike the raw stocks or commodities themselves, each fund would only deal periodically. They tended to be long-term, rather than used by day-traders. In the simplest case, something might deal every day, but you could also have funds which dealt:

  • every Monday,
  • every other Tuesday,
  • the first Wednesday of each month,
  • the 2nd last Thursday of each month,
  • the 15th of each month,
  • once a year, on 31st December
  • once a year, on the first Friday

…and so on. The possibilities were pretty endless. Except that in practise, only a few tens of options were used.

The place I worked, they used to calculate these dealing calendars manually, for each fund, a year at a time. Just this process, over about 1,500 funds, took somebody about six months every year. And somebody else, another six months to check.

So they wanted to build a system which would automate the process. After all, it’s simple enough to have a computer just apply a set of rules and tag one date onto the last.

So I built an engine so they could do this. You needed to tell it the last dealing date, and once it had this, it would apply the rules for the fund and calculate the next dealinng date. So you can imagine, you could run this engine again and again, on each fund, to calculate dealing calendars years in advance.

The trickiest problem was in capturing all of these rules. Capturing them flexibly enough so as to allow many different types of rules to exist, but rigidly enough so the rule could be used to calculate a dealing date.

One of the oe other problem was, what if the engine came up with a non-banking day, for example a weekend, or New Year’s Day?

Plus, the funds were based in different countries/currencies. Different currencies have different ideas about what day is and isn’t a bank holiday. So straight away, you’re having to also capture bank holidays against all the currencies (although funds tended to be only set up in the main half-dozen currencies).

It had to take all of this into account, and more besides.

We got there in the end. It this sounds quite boring to you, that’s because it was. Working with banks was quite well-paid, but it wasn’t rocket science. The reason it paid well was because people had to be meticulous*. A lot of the time you would be working on something to improve a manual process. Either to make it quicker, or less error-prone (in this case, both). Banks are quite a specialised environment, in that respect. In later years, when I was hiring people, previous banking experience was always a big factor, just because it showed that somebody was used to that environment.

* some banks are more meticulous than others!

Hello, World

The other day, I posted a little bit about the technical work I used to get up to. Sharp-eyed readers will have noticed that although I talked technical, there was no mention of computer languages whatever.

In fact there are lots of computer languages, both object-oriented and not. Largely, it is the constructs that are important, the specifics come second. Once you are good at writing in one language, it’s not so difficult to learn other languages. Traditionally when a new language arrives, the first demo program is just to print the text Hello, World onto the console, hence my title.

Some people will say the exact same things about spoken languages, and in fact I got a lot more of an idea about linguistics when I learned French, than when I learned English. In English, we just said it, without necessarily knowing the technicalities. Knowing what a past participle was, say, then helped me when I then took up German.

And computer geeks will argue for hours about the best computer language, but in reality, it is horses for courses. Some languages are good for some things, others for something else. Plus, there is a Darwinian pattern of natural selection going on – the most useful languages rise to the top and the least useful sink to the bottom. Programmers have their favourites, sure, but this is mostly like somebody saying they prefer blue to red.

My first project was in a procedural environment, using a language called Fortran. Fortran taught me the basics: if this then do that, and so on. So I had a feel for the structure. In Fortran, as in many other languages, you wrote the code in small sections, then checked the syntax by compiling the code. We would then link these pieces together to make the program itself. A program might be anything from one to hundreds of these sections. Because of this, Fortran is a compiled language. Not all languages are – these others tend to be looser, and are called interpreted languages – there is an engine which interprets each line of code, as the program runs. With the benefit of experience, compiled languages are far superior, because they allow the developer to find many errors far sooner in the process. The tool I use now even compiles things while I am typing, so I pick up silly errors like typos even sooner. Bottom line, the sooner an error is found, the cheaper it is to fix.

My next project was in an object-oriented environment. PCs were just gaining popularity, but this was before the days of Microsoft Windows. The decision was made to write in an object-oriented language called C++ (C-Plus-Plus). I was sufficiently inexperienced that I had no say in the decision. C++ is also a compiled language, although at the time only a couple of compilers existed for PCs (a compiler has the job of compiling! – you need one to build anything.)

C++ was quite new to the PC environment, although it was invented (and used in other environments) at the end of the Seventies. It wasn’t invented from scratch, however. Would it surprise you to learn that it is an extension of a language called C? C was a popular computer language which had been invented about a decade earlier. Popular, in the very small programming community back in those days. C is a compiled language, too. It is not object-oriented (as you might imagine (object-orientation was synonymous with complexity) but has the advantage of requiring fewer overheads – it is small, fast and efficient. Fewer overheads were a big deal back then – this was a big reason why C was so popular. Another reason it was so popular was, well, because of its popularity. It was a good general choice of language, because people, even then, wrote add-on tools that could neatly fit into C, so people could do a lot more with their programs. And speaking of natural selection, nobody ever heard of the languages A or B!

So I learned about object-orientation and C++. And, of course, this led me to mastering C too. There were some things which C++ gave me, which I didn’t have in C, but again there were overhead benefits if I could live with the restrictions. This knowledge also gave me experience of a language called Pascal (named after physicist Blaise Pascal). It is compiled, but not originally object-oriented, although some compilers were extended to provide limited support. Pascal was important because it was very well suited for the new Windows environment, although we never used Windows seriously back then. But really, if you could pick up one language, you could pick up several.

Windows gained ground, however, and by the time I started my second job, Microsoft had produced a C++ compiler for Windows. It was part of their strategy – make the tools for developers to produce programs, and people would use them, the good ones at least. The winner? Everybody ends up using Windows.

And so it continued through the Nineties. Computer hardware got better, Microsoft’s compilers became more functional, Windows got more functional too, to the point where it became the industry standard. C++ also got more functional, again becoming the dominant language for Windows development. But at the same time, it kept its C roots. Being pulled in both directions, C++ became more messy.

So at the turn of the century, Microsoft invented a new layer to sit on top of Windows. They called this layer the .NET Framework (dot Net), and if you own a Windows PC, you might even have installed it (although a lot of programs install it silently for you). Further, they invented a “new” language, called C# (C Sharp). C# was very heavily based on C++, compiled, of course, and object oriented. And a darned site tidier – they got rid of a lot of the sprawl by losing many of the roots of C.

And so we get to 2020. .NET and C# are both mature and still pretty much standard for Windows development. Each has gone through several iterations, just like the iPhone 10 became the iPhone 11. C# is my language of choice these days, and when I write next time on this subject, I’ll try and marry up some of the things I mentioned last time, with the C# language.

Specialising…

It is funny, I was chatting to somebody yesterday. The subject was the specialist skills that she had gained during her education, and subsequent working life. Well, they seemed specialist to me – I do my best to follow but sometimes it is difficult to keep up.

We finished the conversation with me saying that I would need to talk about my own “specialist” skills one day, so maybe today is the day to start?

In my first job, I did some computer programming. When I started, it was just making small tweaks to programs written by other people. The program would do this, then this, then this, then this, etc. All very much like an ordered list, if you have ever come across them. (WordPress lets you create ordered lists in your posts.) I later learned that this type of programming had a name – procedural programming. Because it was a procedure. Do A, then B, then C etc. One thing after another.

I was still quite a novice in this environment when I was asked to get involved in another type of project. The first one had been quite an advanced simulation – lots of physics coming into play. Very theoretical. The next project was far more practical – controlling things. Move something six inches along a track, by way of a computer program.

In fact, I had been dropped into an object-oriented (O-O) environment, though at that stage I didn’t appreciate what object-orientation was. More about object-orientation in a moment.

That first object-oriented project was a challenge, because I was trying to apply my A, B, C knowledge to an environment which didn’t really fit. These days, I look back and cringe. I guess most of us do when we think about the messes we created at the very start of our careers! Retrospectively, I was probably in the best environment possible, simply because I was given the time and space to learn and to actually become very good at object-oriented development, but at the time, the learning curve was very steep.

So, what exactly is object-oriented programming? Well, actually, it is a deceptively simple approach. You see things as a set of “objects” which interact with each other, to get the job done. Just like in the world outside our windows. Objects? Well, imagine a car, say. A car is an object. Anything can be an object. Within our idea of a “car” we can say a few things. The car contains four other objects, called wheels, plus another object, called an engine, one called a steering wheel, and so on. And you can do things to it, like “drive” it, or “stop” it. All real-life things. So, easy to visualise how something hangs together.

So, you have your world full of these objects. And each object does it’s own special job. If I were to get into a car, and drive off in it, to be honest I have no idea how it gets anywhere. What happens under the hood, I leave that to a mechanic. If it won’t go, I am stuffed – I leave that to a machanic.

And it is exactly the samewith onject-oriented programming. The “car” does not know how it moves, but it has an engine, and that does! In the same way, the engine can hide all the mucky bits away – the oil, the petrol, the spark plugs etc. All the car needs to know is how to drive the thing! In the world of O-O, we call this encapsulation.

Then, you look up and down the scale, not just at the car. Looking in more detail, we can see a wheel, which has tyres and so on. And, looking instead at the bigger picture, what exactly is a car? It is a motor vehicle. An engine, four wheels, a steering wheel….. Just like a bus or a truck. They all get us from A to B. Okay, they’re all a bit different from each other, but there’s a lot in common. Just recognising these similarities, we call specialization, or inheritance.

In fact you can go even further up and recognise that these motor vehicles are themselves just special cases of a vehicle, which might include a pushbike, say. Or, think of a motor bike – just two wheels, but still a motor vehicle. So do you see a kind-of tree forming? Where everything fits snugly into its place? At the trunk you’re very general, but your description covers many things, whereas as you proceed out to the tips of the branches, you gradually split off and become more and more specialised.

And that’s really 90% of the way there!

But you can imagine these trees can become quite complex. You can imagine, with a car, you’re talking about thousands of objects, from the tiniest nut or bolt, to somethind like the chassis. And that was my job, though not with cars – to look at a particular problem and work out what the tree looked like. It was one of those things, I got into it because I was good at it, at seeing similarities, at pinpointing differences, but believe me, a lot of people just don’t see the world in this way.

Shall I try to push it just a little bit further? You drive a car. You drive a bus. You drive a truck. What’s the difference? Okay, there’s a small difference in each, but fundamentally, you’re putting your foot on the gas, and <whatever you’re driving> goes from A to B. So, in fact, the act of driving the vehicle is pretty much the same in each case. We have a name for that too – the most complicated name of the day, because it comes from Greek. We call it polymorphism, which literally means many forms. But don’t worry, I’m not going to test you on any of this!

But would you like a little homework? Look again at my featured image, and tell me what’s wrong with it 🙂.

A Scary Place

Yesterday I didn’t do much, so I had a bit of time/inclination to write. For many of the prepared posts I write (as opposed to responses), I like to just save them as Drafts, then put them live maybe the next day. This gives me overnight, at least, to think about any tweaks, and also means that the final proof reading will be performed with a fresh pair of eyes. So, the post got its final check this morning, and here goes.

From having read my posts, would any of you believe that I have been a published author since very early on in my working life? Okay, not really in that sense! Let me explain:

My very first job out of college was with the UK’s Atomic Energy Authority. It was basically civil service – you can imagine that in the early days, atomic energy was very closely linked to government and military. By the time I jumped on board, quite a bit of separation had happened, but a lot of the structures etc. still followed the civil service’s. By the time I was on board, the Atomic Energy Authority was looking very hard into how it could turn the skills it had picked up in the search for atomic energy, into skills which paid the bills. So I ended up working in a field completely unrelated to atomic energy, in the field of high-energy electricity.

In particular, I worked in the Space Applications Department. Yep. High-energy electrical appications for space-related activities. So I can quite truthfully say that I was once a rocket scientist!

Thinking about it, space-related electricity has developed along a very similar trajectory to autos, albeit with a lag in there. We started with chemical (i.e. petrol) engines, and are moving gradually (very gradually!) toward electric propulsion. Exactly the same in space. Back in the Eighties, there was a lot of development and testing going on of electric engines. Did you know that when a satellite goes up into space, it doesn’t just sit nicely in its orbit, but wobbles about a bit? In fact, it wobbles in a kind-of figure of eight. In theory, electric engines were perfect for reducing that wobble to a minimum. That is one of the areas where we came in.

One of the benefits of coming out of the atomic business was the amount of hardware we inherited. In particular, there were some very large testing tanks, which we could put under a very high vacuum, to simulate, er, space! And very large, in terms of being some of the largest in Europe. Ideal for testing electric engines!

During my time, personal computers were just starting to come along. Somebody had the bright idea of putting several probes into one of these tanks, then controlling them by computer. Of course, at this time, we had to do all this ourselves. Bearing in mind this was back in 1990, we were really state of the art – for example, we were using fiber-optic cabling to communicate between things, because using regular copper wire was just too slow. Current broadband technology, but thirty years ago! (It is a lot cheaper now.)

There were, of course, mishaps along the way. We started off with nylon belt drives, which promptly melted when put near one of these engines! It took a good twenty minutes before anybody noticed, by which time the probe had well and truly melted – in the proximity of one of these engines, you’re in a very nasty environment, and nobody anticipated the temperatures which would be involved. Or rather, nobody anticipated this probe being stuck right in front of one of these engines! When we finally got in to examine this “probe”, we just found a big, melted slab of aluminium! But once we corrected the mishaps, we ended up with a working system, complete with fully-functioning probes.

Within the company, I was employed as a graduate scientist. Lowest of the low – all I really brought to the party was a freshly-earned degree. On this project, I wrote the software to drive all these probes, and to collect data from them. I’d hardly even touched a computer before then, I just happened to be in the right place at the right time. I think back and cringe at some of the stuff I hacked out back then, but it all hung together (somehow), the project revealed to me that this was something I wanted to be doing full-time, and gave me a very solid mastery of the technology. And it only took me until my mid-twenties, to work all this out!

With all these probes on board, we started collecting data. Lots of data. It soon became apparent that my second software project would be to write something which could analyse all this data! And it soon became clear that this second project would be far bigger than the first. Bearing in mind that I was still very green, it was all good experience. God knows whatever happened to that software (I expect it ended up in a bin many years ago) but I found something on Wikipedia which gave an indication of the type of analysis I did:

Okay, the data in my plots would have been completely different, but the idea – turning it into a pretty graph – was the same. It allowed everybody to visualise what was going on – otherwise we were just presenting lots and lots of numbers to people.

Although the whole project was performed on a commercial basis – there was a lot we couldn’t talk about – we were able, at least, to discuss some high-level aspects of it, including at various industry conferences and spin-off publications. Some of my graphs were included in the papers, and so that is how I became a co-author!

Not bad for my very first job, eh? It’s funny, because I subsequently had jobs in banks which easily paid 10x that of the first job, but I look back on this job as having the most interesting subject matter. Maybe a case of rose-tinted glasses? But while a lot of work I have subsequently performed has been in a virtual world, imagining solutions to problems, this project was ultimately dealing with something physical, something real, something tangible, one of these electric engines.

I used this first job as a springboard to become involved, full-time, in software development, and after these projects, I moved on from the space industry, never to return. But I do wonder sometimes whether the stuff I did eventually helped these engines to fly.

So, next time you happen to be passing your nearest technical library, you might want to have a look through some old journals from the International Electric Propulsion Conference paproceedings, or from the American Institute of Aeronautics and Astronautics, and look me up! Which finally brings me full circle to my post’s title, for the internet is indeed a very scary place. It never forgets! I was going to round off my post today with a few references to the papers I once wrote, confident that this far downstream, nobody would take the slightest interest. But I typed each of them into Google, and found the original bloody papers themselves, from thirty years ago! Which of course, are published under my real name…

So, I’m afraid you’ll have to just take my word for it!