Life as a quant

June 17, 2008

Since I’m reading Derman‘s My Life as a Quant, and since desk moves are banned at my bank for cost reasons, I got a laugh out of this cartoon

PIMCO bond resources

April 7, 2008

I’ve been refreshing my fixed income knowledge with PIMCO‘s collection of bond resources. Strongly recommended for anyone wanting a primer on the rates market.

Please leave a comment if you’re a New York based C++ developer who wants to work on a brand new fixed income electronic trading system. No banking or front office experience is required – I’m just looking for flat out coding ability and raw talent…

Hiring again…

January 10, 2008

I’m recruiting again, for a new project. The developers I hire may find themselves coding in C++, Java, C#, Python, SQL or JavaScript. But I’ll stick with my approach of just hiring strong C++ devs. From experience I know that a developer who’s mastered C++, STL and multithreading can tackle anything. The same is not true for a Java only developer: Joel explains why

So we’re still in the middle of the recruiting round I alluded to earlier. Joel on Software is one of my regular reads, and I’ve followed his recent posts on recruiting. One post presents an amusingly stereotyped caricature of the relationship between developers and traders, and bank attitudes to technology. Scroll down to the bit about “Use cool new technologies unnecessarily”: I think Joel must have read Liar’s Poker. Needless to say, it’s not really like that…

Do you fancy trying your hand in a London front office role, working closely with bond, swaps, futures and options traders ?  If so email me at the address on my About page. And when I say “young”, I mean young in spirit, rather than body…

I started programming as a kid back in the 70s, and I’ve never stopped getting a buzz from learning the new paradigm that goes with any genuinely different programming environment. But I haven’t picked up a new paradigm since I starting using dynamic languages with Python and Smalltalk in 00/01. Now I’m starting out with R I’m experiencing all the excitement that goes with every new glimpse of the possibilities of a fresh conceptual toolkit.

Here’s a timeline of the programming languages I’ve picked up along the way, with comment on which ones excited me, and which ones didn’t. Bear in mind this is purely about programming languages, and not operating systems or hardware…

  • Late 70s: Basic on a Commodore Pet, coding home brew games. You always remember the first time !
  • Early 80s: Z80 on a ZX81. My first taste of the power, control and efficiency of close to the metal coding.
  • Mid 80s: early professional coding in Basic, dBaseII and Fortran. Nothing new or interesting there.
  • Late 80s: learn to code in C. Data structures and pointers ! They say all programming problems can be solved by adding a level of indirection, and all bugs can be fixed by removing one ! One has to master indirection to code in assembler, and in C I rediscovered something crucial that’s missing in Basic and Fortran. Combine that with structs and dynamic memory allocation and you have a big jump forward in expressive capability of Basic and Fortran.
  • Early 90s: C++, object orientation and polymorphism. After initial excesses with inheritance I discovered the power of interfaces and composition with the GoF patterns book. A huge jump forward.
  • Late 90s: Java. Big standard libraries and portability courtesy of a VM, but no improvement in terms of expressiveness, power, control or efficiency over C++.
  • 2000: Python & Smalltalk. All the power of OO, but much less code. Don’t need to write acres of type declarations to get anything done, and containers are built in to the language. Radically interactive too, so we get away from tedious compile, link, debug cycles.
  • 2001: C#. Yawn.
  • 2006: R. Array operations. tapply. Built in stats and charting. Wow ! R is to Excel as Unix is to Windows…

VentureBlog is discussing the business ecology necessary to support a startup, and whether such an ecology could be fostered in Europe. I’m intrigued by the comment at the end “Amsterdam … may just succeed while London isn’t looking.” Which reads to me as assuming that London has pole position in European startups, possibly a natural assumption for an American to make, as London is the financial centre of Europe, and is English speaking.

I suspect London’s role as a financial centre will prevent it ever being a start up centre. In London hacker types are drawn into banks to work on trading systems by the excess remuneration. Start ups can’t compete on salaries. Consider New York: all the coders are working on Wall St.

Fortunately the UK does have start up action outside London. Cambridge is the centre of a lot of activity in the business park & MS Research has an office there. Autonomy and ARM are recent Cambridge success stories. The Thames Valley hosts a lot of software activity too.

I wonder if this is invisible to the US VC mindset because so many of the UK companies are focused on verticals. ARM and Autonomy are exceptions in cutting across sectors and having the horizontal reach and scale that generate really big pay offs. Before I worked in finance, I spent several years with UK ISVs that were world leaders in mechanical engineering and petroleum production software. They were more typical of the UK start up scene. Both were businesses founded in the 80s.

David Craig has produced a new book on the huge amounts of money squandered on IT consultants by the NHS in recent years. You can download the first chapter of his previous book on management consulting: Rip Off !

My own local council has been the victim of consultants. And I have witnessed at first hand a bank spending $25M on a system that never went live and was subsequently binned.

Why does it happen ? Because the interests of the conultants, maximum billing, are misaligned with those of the client, project done and consultants gone.

Why isn't it stopped ? Because the managers who hire the consultants hush up the disasters to protect their careers.

For those of us plying our trade as coders in the City of London, or Wall Street, there’s a choice to be made about our mode of employment. Each of the three options has its own particular pros and cons. And if you’re to avoid a mismatch between your employer’s expectations, spoken and unspoken, and your own, it’s best to be clear sighted about those pros and cons. I’ve worked as permie and consultant. I’ve never been a contractor. But I do have a very strong preference for permanent employment. Here’s my take on the up and down sides…

  • Contractor
    • Pros
      • Good money
      • When times are good, you get to pick from a wide range of gigs, and to almost switch at will
    • Cons
      • When times are bad you can be out of work for a long time, and you may have to take a cut to get back in
      • You may not get much choice or influence over your work day to day
      • You’re unlikely to be in the room when the final decision is made
  • Consultant
    • Pros
      • Slightly more security than a contractor. This security can be illusory. During the last downturn lots of consulting firms canned staff pretty quick when the work dried up
      • You get to switch projects, like a contractor. But you may not have much choice over which projects your assigned to.
    • Cons
      • Money not as good as contracting
      • Negotiating the eternal conflict of interest between consultancies and their clients. The consultancy wants maximum duration and headcount from any project to maximise billing. The client wants the project done, and the consultants gone.
  • Permie
    • Pros
      • Security. If you’re any good at your job you should be more secure than consultants or contractors
      • Bonus: that’s why we’re working in the front office!
      • Influence: the chance to bring your own ideas, proposals and innocvations to the table. If you can get the business to sign up, you work on your own pet projects. To me, this is invaluable. Also, being in the room when the final decision is made.
    • Cons
      • Lack of change can be frustrating for the easily bored.
      • Sometimes you have to resign to escape a project you’re fed up with.

Sometimes advocates of consultancy represent it as combining the best of contracting and permie work. I fear that in many cases it combines permie compensation with contractor security.

I haven’t mentioned the distinction between working for a technology consumer org, like a bank, and a tech producer, like a vendor. That’s a topic for another day…