• C++ Programming for Financial Engineering
    Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering. Learn more Join!
    Python for Finance with Intro to Data Science
    Gain practical understanding of Python to read, understand, and write professional Python code for your first day on the job. Learn more Join!
    An Intuition-Based Options Primer for FE
    Ideal for entry level positions interviews and graduate studies, specializing in options trading arbitrage and options valuation models. Learn more Join!

Don't Call Yourself A Programmer, And Other Career Advice


Excellent article. Great share.

Most STEM graduates do not understand this. No one cares you can run lines of code for whichever current fad exists.

Right now you have lots of people bragging that they can machine learning packages and neural networks on Python. Who knows what the next fad will be. No one cares you can run other people's code or program. Any monkey can program in a month.

Businesses care about cost reduction and revenue generation. It is that basic.

This article is probably the number 1 reason why most STEM PhDs from Top 10 schools end up making no money/have unfulfilling careers once they leave academia. They either (A) Cannot communicate or (B) Do not understand how their education translates to profits or cost reduction.
 
Last edited:
That article is way too long. I reckon 70% can be removed while keeping the message.

A related issue is that Computer Science is not science as many think it should be an engineering discipline which it is not.
I have never seen a CS degree that teaches software maintenance (90% of what we all do, amen) or project management. It is a culture shock when they leave the tower into business.

But every CS student learns to program Fibonacci using recursion.

Right now you have lots of people bragging that they can machine learning packages and neural networks on Python
Anyone can learn how to use a software package. But it does not make you a programmer. I would be more impressed if you developed your own small ML library from scratch.
Real programmers do it in C.
 
Last edited:
That was the old days. Now they learn how to do it using recursion... and memoization.
I hate Fibonacci :D
What's the point?

If you are hinting that functional programming is cool, then I would agree. It's very close to mathematics.
 
Last edited:
I hate Fibonacci :D
What's the point?

If you are hinting that functional programming is cool, then I would agree. It's very close to mathematics.
no, I'm just hinting at how things have changed (sometimes they don't change at all) with time.

By the way, memoization is just a fancy word for "caching".
 
Indeed.

Most CS dates from the 60s. Even AI. There' certainly no lack of redundant (hyped) terms for things that are already known. This does not occur in mathematics. They avoid terms containing adjectives e.g. "deep learning", BIG data, fast algorithms, artificial network, fuzzy set. The list goes on.

However, "tropical mathematics" does exist.

End of rant :)
 
Last edited:
I think a take-home point is that mapping skills to outputs/benefits for business' and organisations is key.

I actually think agility, flexibility and creativity are the key most important skills looking into the next 15 years for younger people. Anybody can pick up a book and learn to program SQL/R/Python etc.. But how one tackles problems and finds innovative business benefits is much more important.

identify problems -> apply creative solutions -> learn how to apply solutions -> repeat

I purposefully left out communications and relationship management.
 
In the past there was no distinction between domain savvy and computing skills. It was expected that you take client requirements/feature list and map them a working program.

identify problems -> apply creative solutions -> learn how to apply solutions -> repeat

It is interesting how the impedance mismatch (the ->) between these activities is resolved.

At some stage the industry will hopefully realize that programming skills are important. As well as domain skills. Some of the top quants are very good C++ programmers.
 
And of course, the definition of 'programmer' is important.

If you write code to do anything, you are a programmer. It is said that quants spend > 70% of their time programming.
 
identify problems -> apply creative solutions -> learn how to apply solutions -> repeat

It is interesting how the impedance mismatch (the ->) between these activities is resolved.

Yes I agree that the impedance and often friction between those steps is often an interesting problem. I imagine it's a problem in finance - however I'm a stand alone investor / young investor, but I know for a fact it is definitely a problem within academia and the common workplace.

If you write code to do anything, you are a programmer. It is said that quants spend > 70% of their time programming.

Whilst the definition is of course important, I think a larger question of the ideal form of a programmer working in the financial institutes is more pertinent considering, in my lived experience, programers are typically low EQ high IQ which can often lead to the clash mentioned above.

Pingu linked an article by Prado recently discussing the reasons ML funds fail and the paper addresses this very issue of organisational social structures surrounding research and development within financial funds (Prado, 2017, p. 9)

Prado, M. L. (2017). The 7 Reasons Most Machine Learning Funds Fail. Lawrence Berkeley National Laboratory Computation Research Division.
 
Prior to the 90s' the term IT did not exist. It was called programming, computing, automation, call it what you will. It was a discipline executed by the high priests of systems analysis. Then came HTML and Java applet and all of a sudden everyone was a programmer.
I wonder how many software applications last more than let's say 5 years. More crucially, how expensive is it to maintain undocumented, monolithic software systems?

A common anti-pattern is design tends to 1:1 with coding. That's like building a house by buying the bricks and slates and ignoring the architectural and engineering blueprints.
 
That was the old days. Now they learn how to do it using recursion... and memoization.
Doesn't really help with programming software systems. Just only nice to have, maybe. It's premature optimisation IMO. CS education is very much focused on these nice (Pareto 20-80) features as far as I can see but I could be very wrong.
 
Last edited:
Here's a (biased?) note on what constitutes a REAL PROGRAMMER :D

http://web.mit.edu/humor/Computers/real.programmers

But, as usual, times change. We are faced today with a world in which
little old ladies can get computers in their microwave ovens, 12-year-old
kids can blow Real Men out of the water playing Asteroids and Pac-Man, and
anyone can buy and even understand their very own Personal Computer. The
Real Programmer is in danger of becoming extinct, of being replaced by
high-school students with TRASH-80's.

history-of-cpu-architecture-75-728.jpg
 
Last edited:
More crucially, how expensive is it to maintain undocumented, monolithic software systems?

Documentation has gone down the toilet. Seemingly no-one hires technical writers any more. The documentation available -- typically online -- is almost invariably abysmal.
 
CS education is very much focused on these nice (Pareto 20-80) features as far as I can see but I could be very wrong.

Got to fill up the syllabus with something. This is being force-fed to students who don't know what is important, what isn't.
 
Back
Top