Unmotivated programmer

Pages: 12
Lumpkin wrote:
I would hope it isn't challenging :P

I'm going to do a little research on it.

First link I clicked on showed an extremely simple problem considered "hard".

And a few other links told me that you really only need to know mean, median, and mode, plus addition, subtraction, multiplication, and division.

Wow, they got it easy.
Mind posting those links? I have a feeling they aren't talking about real financial programming.
closed account (3qX21hU5)
Finacial programming is no joke and it is no where as easy as you make it seem fred. Look into High frequency trading systems and then come back and say it is easy ; p

What you are basically saying if you know basic arithmetic you can do finacial programming which is complete nonsense. If you are interested in the field I would study up on threading and make sure you have a very good handle on them. You also need to be able to have very high preformance code. I could go into more detail but I'm typing this on my phone at the moment.

Though if you really are interested in financial programming you could try asking Cubbi about it. I believe he has been in that field for a while and is very knowledgable about it.
I just looked up "is financial programming hard". The first page has the results. High performance? Why would it need to be that?
^Efficient algorithms to quickly manipulate/update large amounts of data. Multithreading to make the most of concurrent execution.
Last edited on
closed account (3qX21hU5)
Like montario said you most likely be dealing with large amounts of data that you need to manipulate very quickly and in order to do that you need to make sure you have optimized efficient code. It really all depends on what your employer wants you do to though. You might be working on the front end interface or you might be working at a lower level optimizing things it can vary like in every field.

Though you will need much more then basic arithmetic to get into the financial programming sector. It would probably be best that you have a advance understanding of maths and also have been introduced into economics among other things.

For example take this programming example from a intro to C++ and financial programming college course. This is actually at a beginners level and was one of the first lectures.

// Generates discrete time random walks and plots the realisations
// y[t+1] = a y[t] + epsilon[t]
// epsilon[t] ~ Gaussian(0, sqrt(var dt) )
// The output, plot.ps file can be viewed with GSview and ghostscript
// (To download Visit http://pages.cs.wisc.edu/~ghost/ and follow links to GSview)

#include "nr3_psplot.h"

const int N = 500; // Number of steps
const int E = 10;  // Number of paths
double T = 5.;   // Final time

const double var = 25; // Variance of the random walk
const double a = 1;  // AR(1) coefficient
const double dt = T/N;  // time increment

// Uniform [0,1] , Warning: cstdlib::rand() is not very reliable
inline double Rand() {return double(rand())/RAND_MAX;};

const double pi = 3.14159265358979323846;
// Box-Muller Transform method, Warning: this implementation is not very efficient
inline double Randn(){return (-2*log(Rand())) * cos(2*pi*Rand());};

int main(void) {
	double ep; // Noise, (shock)
    vector<double> t(N),y(N); // time index and state of the random walk

	PSpage pg("plot.ps");
	PSplot plot1(pg,100.,800.,100.,300.);
	plot1.setlimits(0., T, -5, 5 );

	for (int e=0; e<E; e++) {
	  y[0] = 0;
	  for (int i=0;i<N;i++) {
	    t[i] = i*dt;
	    ep = sqrt(var*dt)*Randn();
	    if (i<N-1) y[i+1] = a*y[i] + ep;
	  int col = int(e/double(E)*255);
	  plot1.setcolor(0, 0, col);


That isn't exactly 5 + 5 = 10 ;p

The point is that financial sector programmer don't get paid good money because the job is easy. It is actually very hard but it is also a very interesting field (In my opinion though a lot of people tend to think it is boring).

Last edited on
Lumpkin wrote:
Finding interest rates and working with doubles isn't very hard.

True, but finance is not all about rate of return, which is indeed just arithmetic (and exponentiation), even with all the complexities of the calendar conventions, quoting and compounding rules. Even fairly common numbers such as derivatives pricing or risk calculations require advanced statistics and calculus, and specialized mathematical models used in quantitative finance can get to PhD level math.

Lumpkin wrote:
High performance? Why would it need to be that?

Even the basic calculations above have to be lightning fast to make today's economy possible, but where finance goes to the extreme is arbitrage: suppose you've learned that someone wants to sell 500 contracts of frozen pork bellies for Nebraska delivery* in Chicago at .31500 USD per pound, while someone else wants to buy 100 of the same contracts in Kansas City at .31625 USD/lb. As any sensible person who has the means to do so, you're going to simultaneously sell 100 in Kansas City at .31625 and buy 100 in Chicago at .31500, making 5,000 USD instant profit.

Now suppose the office across the street saw that opportunity too, and they entered their orders a microsecond before yours (orders are executed in the order received). Now they have 5,000 dollars, while you have 4 million pounds of pork bellies that will be waiting for you in Nebraska next month and you've tied up 1,260,000 USD cash that could be used for more trading.

[*] pork bellies were delisted in 2011, I just like to use them in examples

To get back on topic
aimforthehead wrote:
I have spent so much time working on console applications that are about payroll and things like that, when I think I'm more interested in making games and whatnot
I guess I'm just looking for programmers to tell me it gets funner if you just stick with it

It's normal to see people change jobs every 5 years or so. If you get a job making games and, years later, get bored doing the same thing every day, you might switch to OS development, or programming robots in car factory, or making cell phone software, or, sure, finance, if you like the stress.
Last edited on
Oh, now I see.

It actually does seem interesting.
I would imagine accuracy and high-quality (minimum number of defects) are the most challenging tasks in the financial industry.

Writing bug-free code is not only practically but theoretically impossible as a system scales upward in size.
Yes, bugs can cause problems, Knight had a big one last year: http://www.bloomberg.com/news/2012-10-17/knight-capital-reports-net-loss-as-software-error-takes-toll-1-.html
but I feel that overall it's less critical than, for example, real-time programming I did before. A lot of things in finance can be rolled back, cancelled and corrected after the fact, but if you broke a jet engine, you can't replay the flight from take-off in debug mode.
Who's that?
Topic archived. No new replies allowed.
Pages: 12