That's interesting. I went into finance (option MM at first) with an Engineering background, and developed more and more programming skills as things developed.

The financial stuff is IMO not complicated. Anyone (a lot of the traders left school at 16) can understand how the option Greeks behave intuitively. Since I went to uni, I picked up the classics (Hull, Wilmott, Niederhoffer) and read through them. After a while, you get it. You may not be able to derive all the little things (options on options, Asians, whatever) but you'll still have a reasonable idea of how it works.

The programming side is a whole other can of worms. You think you get it. Take Excel. Put in BSM. Make a vol surface. Do a VLOOKUP on a grid, remembering to do the $ signs. Float it to adjust the calls when the market rises. Hey, it's easy right? You can just make some VBA code, dump it somewhere. Put some intermediate calculations on a hidden sheet.Boss wants an alternative model? Copy-paste and edit the formula. Call Bloomberg for some data on another sheet, use it to calculate some parameter. Save it as ESX-jumpmodel.xls. There's a get-it-done-quickly mindset that isn't great, but creates the illusion of working well.

Code written by finance people has a reputation for being incredibly spaghetti-like.

When I started off coding, I thought it was easy too. But it's the most time consuming part of all my financial work. Each time I had some new interesting thing to do, a huge gap in my knowledge was uncovered:

- Started using Excel to do end-of-day reconciliation, the bottom rung task of junior traders. Took me a week to do something that today would take me half an hour.

- Coding a NIG model to price options: took me ages as well, and the guy at the trading software company said it was easy. Spent a LOT of time getting Cygwin to work, had to go through loads of compile fails in gcc (I didn't even know what that was when he told me). What's static typing? Why can't they all be variants? The easy part was finding a formula for the Bessel function.

- Coding a spreadsheet for fixed income arbitrage: once again the easy part was understanding basis, swaptions, asset swap, carry. The hard part was organizing all these sheets in a sane way, for 10 currencies and terms from overnight to 50 years. Also, calibrating/fixing conventions was easy. Call your broker, ask him what he uses for his curves.

- Writing an FX feed multiplexer. Easy on paper: you get a better price by comparing feeds from different banks and picking the best one. In practice: you need to read all the intricacies of the FIX protocol. You need to know how service oriented architecture works (all those banks aren't going to run in a monolith, are they?). You need to know how a network works. You need something that isn't Excel, so now you need a UI as well. Oh, and you're saving trades in a database, right? Hello SQL 101.

- Glueing a trading engine on to the multiplexer. Easy on paper: model tells you what to trade, and you already have a multiplexer. Now you need the UI changed to put knobs on the model. And you're sure you won't machine gun the trades right?

- Making a thing that looks at the orderbook to trade: now you need to be fast. Is the math any harder? IMO no. But what does fast mean to a guy who's never had a speed issue? What's c++ anyway? And why is there an allocator on all the constructors? How do profiling tools work? What's this 200ms delay (I kid you not, forgot Nagle once!)? Why does everyone talk about Big-O? It never came up when I was does the spreadsheets.

- Making a thing that looks at an exchange binary feed: uhm, what's binary? What is this endianness? What's a lockless ring? What's a kernel, and why do I have to bypass it? Branch prediction? False sharing? Cache invalidation?

IMO it would all have been easier to teach a CS grad about finance than a finance grad how to program.