Ravi Mohan's Blog

Saturday, January 27, 2007

Tech Skills - An Investment Metaphor

A snippet of a (yahoo messenger) conversation with a friend who thinks differently.

"... friend: i'm actually quite happy being a follower with technology... i'd rather build cool apps than hack frameworks. Its similar to my approach to investing... get on board a stock just as it makes new highs :-) and ride the wave. ..."

Viewing technical skill acquisition (including the choice of language/frameworks/tools) through a metaphor of investment of scarce resources (that would probably benefit from the use of a deliberate strategy to maximise returns) is illuminating.

The metaphor fits loosely, with plenty of holes in it. The "investment" made by a developer in a particular technology (and thus by implication in the underlying paradigm, community, toolset etc) is primarily the time he spends on mastering the technology, and secondarily the mental effort required to do so (Kernel hacking is much harder then Ruby on Rails). Mental effort is not strictly equal to time consumed. If you have 24 hours of free time you can use it to work through a RAILS tutorial or understand continuation passing interpreters. The latter requires significantly more mental effort/unit time.

Spending time, however, is very different from spending money. Money does not diminish when you don't actively spend it(ignoring the time value of money), but the time available to you diminishes at a constant rate till it is all gone whether you consciously spend it or not. With money, you can make a marginally suboptimal investment, watch it for awhile, then re extract most of the value and reinvest it in another instrument without too much effort, losing just the "time value" of the money. You can't decide to learn RoR for a year, then extract most of the time invested, and reinvest it in say Kernel Hacking. Time, once "invested" is gone forever.

Like most non professional investors in stocks and shares, developers mostly invest their time into particular technologies by default rather by deliberate strategy and many people find themselves having "6 years experience in C++ " or whatever, without knowing quite how they got there. So it is useful to look at the "correct" ways of investing in shares and try to extract any lessons to apply to tech skill acquisition.

My friend's technology strategy is "similar to .. get on board a stock just as it makes new highs .. and ride the wave." . In the world on Finance, such a strategy is called "technical investing".

When the objective of the analysis is to determine what stock to buy and at what price, there are two dominant methodologies.- value investing and technical investing.

from investopedia

  • Fundamental analysis is a method of evaluating securities by attempting to measure the intrinsic value of a stock.
  • Technical analysis is the evaluation of securities by means of studying statistics generated by market activity, such as past prices and volume. Technical analysts do not attempt to measure a security's intrinsic value but instead use stock charts to identify patterns and trends that may suggest what a stock will do in the future.

Technical investors try to guess how other people (collectively called "the market") think. The key skill is timing - the ability to jump into the market when it is about to "take off".

Value investing is about cold blooded analysis of the financials - the key skill is finding the " intrinsic value" so you can buy when intrinsic value >> price in the market . The (short term) market "trends" are of little consequence to the value investor - the only 'trend' they believe in is reversion to mean (where mean == intrinsic value).

Let us take a concrete (but extremely simplified) example. Suppose a company has a million dollars in annual profit, with a million shares in the market.

The value investor thinks "If I buy a single share in this company, I 'earn' an income of a millionth part of a million dollars(the profit/year), i.e one dollar/year. If I want a 10% annual ROI, I can buy this share at any price <= 10$"

Thus the "intrinsic value" of a share in the company depends on how much "ownership" of the company (and thus a share of its revenue and profits) that share represents.

The technical investor looks at the same stock through a different conceptual lens. He doesn't care what the present price or intrinsic value of the share is. It could be 10$, 100 $ or 1000$. All he cares about is whether the price of the stock is going to surge or slump. If he thinks it is going to move from 100 $ to 120 $ in the next couple of weeks, he'll buy the stock and if he thinks it is going to move in the reverse dierction (say from 100$ to 80 $), he'll sell it. (As with the value investing example, this is an extremely simplified example. Real life strategies are more complex).

To judge whether a stock price is about to move up or down, the technical investor uses historical data, often in the form of graphs/charts of price movements over time. He looks for patterns in the charts which predict an upswing or fall in price and uses these patterns to judge when to buy and sell.

Evaluating financial instruments is easier than evaluating technology choices because for the former ,what you invest and the returns you get are measured in the same unit (money). As mentioned earlier, developers invest time and mental effort in mastering particular technologies. Measuring "returns" is a bit more problematic, and could be "employability" or "chances of getting rich through code " or "interesting work" etc and often multidimensional, often being a compound function of these factors. Thus investing in a particular technology would mean trading time(the cost)for money earned/month or the "Interest Quotient" of the job etc (the returns).

My friend uses a technical investment strategy (waiting till a wave builds and riding a wave - and presumably jumping off an abating wave ) to acquiring technical skills. An alternative approach is to use a more value oriented strategy - ignore the 'trend' of a technology and evaluate its "intrinsic value" - the advantage (or returns) it gives on a particular (set of) projects, as contrasted with other options.

Thus I can decide to learn Ruby on Rails (say) either because it is a 'hot' technology (the technical investment approach) or because cold analysis indicates that for developing a certain type of web app, it delivers a speed multiple at the cost of slower speed, and less tool support and an estimated 3 or 4 weeks of learning time (the value approach).

As in stock investment, some people use a mix of strategies. There are approaches to investing other than "technical" and "fundamental". E.g the Capital Asset Pricing Model which focusses on measures of volatility in price.

While the metaphor is imperfect, I find it illuminating. Of course, the fallback approach is to learn whatever fascinates me, irrespective of intrinsic value or trends or volatility or whatever- an approach that has provided rich "dividends", in my experience anyway.

PS:-Much Thanks to Yogi and Manoj for excellent feedback on the initial draft.


Anonymous said...

Nice essay.

I think the basic question one needs to ask themself is

"Do you want to follow the herd, or your heart ?"

Once one has an answer to that, Its pretty simple... :)

Anonymous said...

...the time available to you diminishes at a constant rate till it is all gone whether you consciously spend it or not

that really got me thinking! :)

Nested said...

I like this analogy. I am not a pro at investing, but I believe in investing in companies that I genuinely believe are undervalued in the long term rather than trying to guess whether the value of a particular stock will go up or down in the short term. When it comes to technology, I also look for technology that I truly feel will help to solve problems I recognize rather than following fads. To use Rails as an example, it really makes web programming more straighforward and removes a lot of the silliness of so-called enterprise architecture in Java and .Net land. One thing I wish was more well understood in the software development community is that your domain code should represent a huge majority of the work you do and this code should be free of dependencies on the framework. A framework can make life easier, but at the end of the day it's unlikely that choosing one framework over another should really make a huge difference - as long as one emphasizing minimizing the importance of the framework used for any given application.