Finance for Programmers

So much bad clipart to choose from

One of the cool things about being in software is that you get to learn about all the industries that use software--which is pretty much all of them.  I figure that by the time I retire, I'll know how the whole world works.  Since I work in financial services, I'm trying to understand what finance is.  I've taken a couple MOOCs and have tried to figure out why I get paid.  Some thoughts:

I think finance and microeconomics are worth learning if you're a programmer, because it's important to understand how a company makes money.  I've heard lots of cockamamy ideas from programmers who didn't know anything about business.  It's even more useful if you're thinking about becoming a manager or entrepreneur at some point.

As a discipline, finance is mostly about evaluating projects or choices in today's terms.  You have to have at least two options if you're going to use financial analysis.  It's essentially comparative.  It doesn't make any sense to say an option is good in itself.  You have to say what it's better than, and you have to be able to do it using some kind of common scale.

The two metrics finance focuses on are risk and return.  When you're talking about things whose prices are set by a market, risk and return tend to be correlated (at least, according to academics).  Risky things may payoff big.  Chances are, however, they'll cost you.  That doesn't mean you shouldn't do them, only that you have to compare them to other possibilities.

Risk and return are not limited to assets or financial instruments.  We think in their terms all the time.  I'm a decent drummer, and I briefly considered trying to make drumming into a career.  But I realized that the chances of becoming a professional drummer were pretty small.  When I compared the risk and return of being a drummer to being a programmer, the choice was obvious.  If I didn't like anything else or wasn't good at anything else, it would be a different story.  

Financial analysts, of course, are typically interested in money.  In the case of money, you almost immediately have to start talking about interest.  And the weird thing about interest is that you gain interest on interest.  This is called compounding.  Everyone thinks they understand compounding from high school, but it never ceases to blow my mind.

Even if you're not interested in money, there is always a cost associated with doing something, since it involves not doing something else.  This is called opportunity cost.  When you think about whether or not you want to see a movie, for example, you could consider all the other things you could be doing.  Businesses must make decisions that take opportunity cost into account.  There's even a cost associated with having cash, since that money could be invested in something else.

In short, finance provides a lens for evaluating pretty much anything.  It's not always the right lens, because it is highly simplistic, but it can give you a start when trying to get your head around very different options.  For many choices, risk, return, and opportunity cost don't provide much help, such as choosing between hanging out with friends or staying in and reading poetry.  Even if it's not the right tool in all cases, I think the overall goal of comparing things along a common axis is a useful way to begin thinking about many problems.

I Know What You're Thinking

Back in grad school, I had a professor who told me about an interdisciplinary summer retreat he had been invited to years ago.  There were economists, political scientists (like him), sociologists, educational theorists, philosophers, and many other smart people.  Though they talked about a wide range of topics, he found it most interesting that, by the end, he could predict the kinds of questions people were going to ask before they asked them.

Economists would wonder about incentives, transaction costs, and barriers to entry.  Sociologists re-framed things in terms of demographics and norms.  Educational theorists were concerned about developmental impact.  Philosophers and English professors would bring the conversation back to 'the text.'  Political scientists would analyze power relationships and procedural constraints.  And so on.

This story has stuck with me for years, especially as I experienced the same thing myself in a similar summer seminar.  On the one hand, it's no surprise that professionalization teaches you a conceptual system with a specialized vocabulary, and it shows the value of doing so.  On the other hand, it's all a bit depressing, as if what we study and do for a living bends us to the wheel of a necessarily partial worldview.

Since leaving the ivory tower and returning to software full-time, I've noticed the exact same phenomenon.  In a technology firm, people from each team will have a perspective that's hard to shake.  Developers and architects will be concerned with system coherence and stability.  Testers live in a world of exceptional cases, where everyone is trying to divide by zero and servers are falling like flies.  Product analysts think in terms of costs, revenue, and rates of return.  Accountants want to know how they can report on it.  Support teams are concerned with how much manual intervention is required.  And project managers want to know how many person days it will all take.  And so on.

(This is all very rough, but you get the idea.  It takes a lot of work to truly appreciate any of these perspectives.)

It's important to recognize these points of view when working with other teams.  If you give a technical reason why it will take a long time to develop something, non-developers will only hear white noise.  They'll probably just think you don't want to do it.  But if you can talk about it using a set of terms they understand, such as existing products and features or past time estimates, you're much more likely to have a productive conversation.

This may seem like common sense, but I think it's one of the central challenges of getting things done in a complex organization: you have to be an expert in one knowledge domain while simultaneously being able to communicate with other experts in other knowledge domains.  All projects involve some give and take.  The less agile your process, the more important it is to make sure you have good communication from the start.  I've seen many projects fail because no one really understood what anyone else wanted.

Cryptography and MOOC's

Instead of posting during the last month or two, I've been taking a couple of MOOC's (or massive open online courses).  If you haven't heard of these, check out Venture-Lab, Coursera, Udacity, and edX.  Rather than just posting a bunch of online lectures, universities now provide quizzes, group work, forums, and tests.  MOOC's are taught by top professors at top schools (though being a top professor has nothing to do with being a good teacher).  And, if you care about it, you can get a certificate of completion.

It's not yet clear what the future holds for MOOC's.  Some predict that, in a few years, only a handful of universities will remain.  Others think MOOC's are antithetical to the selectivity top universities cultivate and thus can't be sustained.  In any case, I'm taking as many as I can while they're still free.  If you don't care about getting credit, they're a great way to keep learning.

I never took a cryptography class in college, so I enrolled in Dan Boneh's.  Basically, cryptography is all about taking strings of 0's and 1's and then XORing them with a key (also made up of a bunch of 0's and 1's) in order to get a cipher text.  The bulk of cryptography, as a science, is determining what counts as a good key and how two or more people can share keys in a secure manner.

While it was interesting to delve into number theory and modulo arithmetic, the point Boneh hammers over and over again is that you should never develop your own cryptographic solution, because you will screw it up.  Many commercial applications make silly mistakes; you're certain to forget something.

For this reason, I quickly became bored of the course.  The abstract problem of designing and cracking keys is completely different from the real-world problem of securing applications.  In college, there was no limit to the amount of useless theory I was willing to learn.  But now there's a premium on my time.  I could be learning a thousand other things in other MOOC's, after all.

I have found that this flexibility is the main benefit AND drawback of MOOC's.  You're free to come and go as you want, which became a problem in a group project I completed in my finance course.  Two of the four group members dropped out, and I wasn't much help either, leaving the bulk of the work for one person.  MOOC's promise something akin to the college experience of making friends from around the world, but there is no incentive to stick with it when the going gets tough.

I will definitely continue to use MOOC's as long as they are available.  I started a course in networking today.  I think it is unlikely that MOOC's will upset established universities, but they will increase the (already high) pressure on colleges--especially lower-ranked private schools that already offer a questionable return on investment.  Educators of the future will have to be able to teach large numbers of students in ways that work.  I'm happy to be part of the experiment.