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!

Costing Projects

Oftentimes in my career, I’ve been asked to produce project plans. I have a few simple rules I worked by, but they were not rocket science and I usually just ground them out.

By grinding them out, it was basically sitting down and working out, as best I could, all the different little tasks which went into the whole project, and, as best I could guess, the duration of each task. From there, just basically adding up the numbers together. The end goal was to be able to say how many man-years of effort would be required. I let other people juggle with the number of people involved, and, frankly, a lot of the time it really was no more than juggling!

A lot of tasks were repeated across the board. For example, every task finished with a unit test, so “unit test” was always a sub-task. A unit test is simply testing the part in isolation. But again, unless you realised this and took account of it, you wouldn’t allocate enough time for it.

I had a basic rule that a task would take a minimum of half a day. Sometimes a task might be a single change to a single line of code, so a half-day was overkill. But over the course of the project, it averaged itself out. Conversely, if I costed a task at more than a fortnight, I knew I needed to break that task down into smaller parts to get a better idea. Overall, there were normally the same feelings on each project – when you first worked out the numbers, you, and other people, would say “crikey, will it really take that long???” because the number you calculated would always exceed your gut feel. But at the end of a project, I was generally happy with my initial estimates, although requirements invariably changed during the course of the project, par for the course.  After all, because the duration of an entire project was just the sum of these small tasks, for each task if would have been very difficult to miscalculate by all that much. So, unless you hadn’t thought of all the tasks… Project Managers would often be not happy at the end result, but that was their problem – ultimately tweaking the numbers at this point would just have been wishful thinking – they’d have the math right there in front of them, so it’d take a degree of bravery (foolhardiness) to ignore it in favour of their gut. But some of them did, and they invariably got burned. If my advice had been wrong I’d have been concerned, but if they’d chosen to ignore my advice and subsequently got it wrong, that was their problem.

In my last few years, I met another guy who claimed he could estimate the cost of projects without grinding things out as I did. Quite funny, really, I’d regularly meet people in my career who could do things more efficiently than I could. For some reason, I survived despite being so inefficient. This guy just used his gut feeling. The difference, as always, is the working out – the documentation. My detail would be used as the basis of the plan that would span the entire project, the final number that I produced was just the headline. I was fortunate, I suppose, because I encountered this behaviour early on in my career and developed coping strategies – the guy, often parachuted in, who tells you. ever so nicely, that what you’ve been doing is crap, so you just had to cover your backside.

Telltale Signs

When I worked in the City, people (agents) would often call me to see if I was interested in a new job. I got into the habit of asking them to sent a spec (specification) over to my email address. Why? The spec itself might go on to be important or it might not, but relly, in the first instance, I just wanted to satisfy myself that a spec existed. A spec showed that the clients had, at least, put some thought into what they wanted. Furthermore, clients often need to produce a spec internally to receive budget, so a spec helped me to know that there was a pot of gold at the end of the rainbow. I’d sometimes get some bright spark of an agent saying, “this role is so new that there isn’t a spec yet”, to which I’d just say, “well, when there is one, send it over”.

Another thing with the type of work I used to do, was the duration of the work. The role I did took a few years, normally. So if a client wanted to offer a short-term contract, that raised an eyebrow. Okay, there might be good reasons for that – a probation period, for example. Alarm bells started ringing, though, if a client said they wanted a designer for just a couple of months.

So I ended up looking more for things that should be avoided, rather than things with potential. The things with potential were the ones left over after I’d discounted the things which fell at one of the hurdles.

It is the same, really, now, although there are altogether fewer vacancies locally so the scale is smaller. Indeed I haven’t seen anything in almost a year which ticks all the boxes.

I saw a funny one yesterday. Somebody was offering just a three-month contract for a Head of IT. Obviously interim – someone must’ve been taking a leave of absence and the company didn’t feel they could manage without, even for three months. But who do they seriously think will take that on? What do they think somebody can achieve in just three months? I must admit that I could happily take on a “head” role these days, but reall, I’d want to have a bit of time to see the effects of any changes I introduced.

American Memories

I had a job in the UK between September 1995 and February 1997. I was a programmer with probably 7 years’ experience, and a novice project manager. The company was looking for a technical specialist cum project manager, so I suppose I was a decent fit.

The company was a start up and everyone was working on just the one project – a web-based business-to-business purchasing solution. Think Amazon, but without the frills. The idea was that somebody could buy someting as quickly as possible for their business, and to speed past all the frills. The web was, in those days, sufficiently immature (and the company’s idea sufficiently visionary) that this company could quite happily get into meetings with the High-Street banks.

The product required quite advanced (for the time) encryption, and we ended up building on a commercial US library. The library itself couldn’t be exported, but it was perfectly OK for our product to use the library (as long as we sat physically in the USA while we built it into our product), and for our product to be exported. It indicates that the lawyers didn’t understand the technology, because physical borders are no defence against cyber attack, but I suppose nothing much has changed in that respect. I didn’t have any hand in selecting this product in the first place, which probably also says how inexperienced I was.

So, the solution was for me to fly out to the USA to do the work. It was only for about a month, and my first taste of the USA. The company’s backers were venture capitalists based near Washington, DC, so that was the natural place to work.

In the end, it was a small town right by Dulles (Washington’s main) Airport. Aspects of the USA were brilliant but it was very “suburbs” – every journey had to be made by car, the highway was dotted with clumps of either houses or shops, and in between there was a whole lot of nothing. I didn’t like the suburb aspect but I did like things like the shops in the larger malls (I bought a new wardrobe!), Mexican food, say. Some things. I have a vague memory that this was around Easter 1996, and because I thought it was a one-off trip, I tried to squeeze in all the Washington touristy bits – the White House, Smithsonian, Arlington Cemetery etc. I remember watching the Oscars live from a bar – it was Braveheart’s year and probably to this day that’s the only Oscar winner I can name.

But because of the suburbs aspect, when I got back home I didn’t take it any further, and the project trundled on. The company signed a deal with Barclaycard in the UK, but Chase Manhattan were also interested, and the US is a far bigger market than the UK. Meantime I had started managing the entire project, although, because it was a one-project company, there was a lot of involvement from directors. I knew early on that management was not really for me – one of my employees came to me one day with a personal problem, and I remember thinking, “stuff your problem, as long as it doesn’t interfere with my deadline”. Not a brilliant attitude on my part and, in all jobs since, I’ve concentrated on the technical side rather than on people.

In order to help close the deal with Chase, I was sent out to their campus in Tampa, Florida. for a few weeks to hold a series of technical meetings about how the solution worked. I liked Tampa, it was mostly very new but had areas with a decent history and vibrant atmosphere thanks to its Spanish background. Plus, of course, the weather was a big improvement on the UK. This was early summer 1996, and the trip culminated in a meeting at Chase’s head office in New York City.

The series of meetings obviously helped, and we duly signed a deal with Chase. Instead of Washington, DC, we’d be located in Tampa, Fl. to be close to them. The company clearly had designs on moving to the US, so I let it be known that I’d quite like to go over there permanently, and they set the wheels in motion to obtain a visa. I liked Tampa much more than DC, somewhere I’d happily have lived.

Chase must have been having their own meetings about the project, and the next thing I knew, Chase dictated that the project now had a sufficiently strategic importance, that they wanted us close by, in New York City. Personally, this was fine by me, since I’d liked New York City even more than Tampa. My first impressions of Manhattan had been very positive. The only thing was that the cost of living was that much higher than in Florida, but that was the company’s problem, not mine, right? At the time, everything for me was on expenses anyway.

From midsummer 1996 onwards, therefore, I was over in New York City quite a bit, helping to set up a US operation. Funnily enough, I didn’t do many “tourist” things, mostly because there was no hurry. I did go up to the top of the World Trade Center, and remember going to Staten Island on the ferry, to see Liberty, but there was lots more I eventually wanted to do. I loved New York – it was very different to most of the US, just in terms of its compactness. And there was so much going on – if I had to identify the capital of the world, this was it.

By the end of the year, my visa had come through so it was time to make things permanent. I said most of my goodbyes in the UK and gave up my rent. Then, the snag!

Basically, the company offered me a deal to work in Florida, which I accepted. They offered me the same deal, but in New York City. I researched, and that the cost of living in New York was 3x that of Florida. Additionally, I’d been in New York for some months now, I’d made a few friends and, more importantly, had been involved in hiring future co-workers. So, I’d had some knowledge of the market – I’d be managing people earning $1000/day, while I’d be earning a quarter of that! Presumably the company gambled that just the opportunity to work in the USA would be irresistable, but that was never really the case. I also had my doubts about the company itself – was it really something I wanted to be involved with? I felt that the atmosphere could be quite toxic at times, even between the directors (which they should never have let me see). The company was very marketing-driven, often making promises that were impossible to deliver given the technology of the time. I remember once working a 26-hour stint the day before a meeting, for exactly this reason – and I was expected back in the office after a half day’s rest!

Also the support we had from Chase was equivocal. I’ve seen it many times since, but at the time it was a new experience. Weren’t we all on the same side? The middle-managers we dealt with harboured ambitions to become senior managers – they had to maintain a certain distance from us because if not, and the project went sour, then it might reflect badly on them. Middle managers in large corporates think very much like that the world over – make sure you don’t go out on a limb for anything, and you’ll get promoted just for not screwing up! Actually, the senior managers I know got there precisely by going out on a limb and succeeding against the odds, but that’s a different story, and I have the benefit of experience.

Anyway, the to-ing and fro-ing went on over Christmas 1996, but in the end I decided not to take the offer – it was a step backward rather than forward for me. I was still minded to get to New York somehow – the visa (which wasn’t transferable, but it did at least show that the US Immigration people thought that my skills were sufficiently desirable), whilst at the same time set up my own company in the UK, in case things didn’t work out. I was really at the point in my career where I felt able to strike out on my own.

As it happened, I severed my ties formally with this company in February 1997, fortunately there was a spell where I was on gardening leave but on full pay, which I used to develop my own business. I got the first work through my company in early March, down near Winchester (which brought me to this area), and over time lost the urge to work in the USA. I loved New York City but looking at how things turned out both personally and professionally, I can’t really complain.

I got a letter from an official receiver, some months later, telling me that the UK arm of this company had gone to the wall – I suspect they put all their eggs into the Chase basket and Barclaycard weren’t too thrilled – but by then I was nicely into the rest of my life.