Language, Technology, Culture

Learning new languages is one of the most rewarding endeavors I’ve ever decided to commit time to. Language is a reflection of people and culture. Getting to know other languages helps you better understand people and can unleash new ideas in your brain.

Mandarin and Taiwanese are my native tongues, although I’m far more fluent in English today. Every once in a while, I encounter phrases that I can’t translate. For example, 撒嬌 (sa jiao). There is no phrase in English which is an accurate translation. I’ll attempt in several sentences.  It is a verb for females towards males, generally for the daughter/gf/wife towards the father/bf/husband. It is act of acting cutesy/lovable in an attempt to manipulate the man into doing something the female desires. Related words which come to mind are “spoiled” and “manipulative.” If you take a second to think about the implications of why it takes so many sentences to translate this innately Chinese concept into English, you start to see differences in the cultures from an angle you might not appreciate otherwise.

In Spanish and Portuguese (both Romantic languages), there are more precise verbs for “to be” than in English. I’m not very good at either, so bear with me. There are two verbs, “estar” and “ser”. Estar is more transient than ser. For example, “I am American” (Soy Americano/Sou Americano) uses ser – it’s not something that you can change. However, “I am sad” (Estoy triste/Estou triste) uses estar – since it’s a transient mood. Between Spanish and Portuguese, there are subtle differences, “Where is the bathroom” translates to “Dónde está el baño” (estar) and “Onde é o banheiro” (ser),  respectively. It’s as if the Spanish have a more relativistic view of space than the Portuguese! I’m not sure I’ve come to any conclusion about why this difference exists, but it’s pretty interesting to think about.

As a tech geek, different languages are of interest in both practicality and curiosity. In my early years of programming, I often scoffed at people who would rave about the latest language in the interweb limelight. In my head, there wasn’t anything that could be programed in one language that couldn’t be done in another, after all, all (relevant) programming languages are Turing complete. It wasn’t until after I used Clojure in a non-trivial project that I truly started to appreciate the higher level benefits of some languages. The expressiveness in Clojure was just not something I could replicate in Java. Its beauty and concision allowed me to express and realize ideas that I wouldn’t have reached otherwise. As a default, I now think and prototype in Clojure just to get my head straight, even if the project requires that I deploy in (and thus need to translate to) another language.

Pretty wide range of thoughts, I know, but I think my point is that understanding and thinking in other languages – whether spoken or for programming – can provide a deeper understanding of the subject than otherwise possible. Plus, it makes traveling and programming more fun!

“Where economists make the fundamental mistake is they think that money is money”

Rory Sutherland: Perspective is everything. One of the best TED talks to date.

Economics as a study (I’m not ready to call it a science) has a ways to go before realizing its full potential for improving human outcomes. One simple example of the fallibility for treating all money as the same is the St Petersburg paradox.

People are irrational in the eyes of economics, but what kind of study makes derogatory remarks about its subjects as if the real world is suppose to follow the rules of its inadequate models? Reminds me of the famous comments in 2007 by David Viniar, then CFO of Goldman Sachs, that 25-standard deviation events had occurred on several successive days. How dare nature disobey my models!

Good thing we have people like Daniel Kahneman, whose recent works point out rather methodically some unexpected outcomes of human behavior.

Migrating from Github to Bitbucket

First of all, I’m a fan of GitHub. For open source projects, there’s no better. For a long time, I had a paid account there for my private repos. However, recently, Bitbucket added some features which made migration from Github very easy. Since Bitbucket gives you free private repos, this is good news.

First, go to Bitbucket > repositories > import > import from GitHub. Give authorization on  GitHub, choose which repo you want to import, and that’s it! Your code and all its history is now at Bitbucket.

Importing “issues” still require a little bit of hoop jumping at this point. You need to export it from GitHub, then import from Bitbucket.

git clone https://github.com/sorich87/github-to-bitbucket-issues-migration
cd github-to-bitbucket-issues-migration
bundle install
bundle exec ruby cli.rb githubuser/repo username password exportfilename.zip


Select your repo on Bitbucket > settings > Issue tracker settings > enable. Go to settings > Import & export > import issues, choose the zip file, and that’s it!

Low-Tech FTW!

Engineers love to use the highest-tech tool for their problem. It’s quite understandable as, hey, who doesn’t like playing with shiny new toys. In my experience, engineers are more predisposed to shiny things than others.

This is a problem because this goes against what the end-user wants. They just want their problem solved! They could care less whether it’s done on a shiny new Hadoop cluster, a thirty year old mainframe, or a toothpick – as long as the job gets done and gets done right every time. Meanwhile, the engineer wants to solve the problem as generically as possible so it can even solve problems that don’t yet exist.

An experience of mine some years back illustrated this point quite well. I was driving down the PA Turnpike. For those that don’t know, it’s a toll road with gates along exits so you pay only for the segments driven. As usual, I was speeding. But this time, I got pulled over by a cop. The cop took my ticket which specified where and when I entered the Turnpike, then proceeded to calculate my average speed over 100+ miles. Needless to say, my average speed was quite a bit above the speed limit, even given my visit to the rest stop. All I could say to the cop was, “I’m sorry and well played!”

Surely there were high-tech solutions for catching speeders – sensors on the highway, monitoring by air, etc. But he was able to indisputably prove that I had been speeding in a fail-safe way.

What I learned is that the crudest and most archaic tools could turn out to be the most elegant solution. It takes a deep understanding of the problem to arrive at the best solution, not one that is most flexible.

Speed of Light

Though I don’t come from a physics background, the subject has always intrigued me. One of the more interesting constants to me has been the speed of light, which is roughly , which I’ll refer to as . That in itself isn’t too interesting, as it must have a speed, so any number is as good as any other.

The interesting fact, which has been verified experimentally, is that the speed of light appears constant to all observers. That is to say, if you’re in a very fast moving space ship moving at , and you shoot a ray of light out the front of the ship, you’d expect that a stationary observer would see the ray of light move at . To the contrary, it appears  to the stationary observer as it does for you on the ship!

This result is very counterintuitive, but what does it imply?

Say you’re on a space ship moving at , and you’ve installed two vertically opposing mirrors. You observe a photon of light bounce between the mirrors. A stationary observer would see that same photon of light moving along a diagonal path as it bounces back and forth, due to the forward trajectory of the ship.

  VS 

Say the observation period is one second. If the distance between the mirrors is  meters, I’ll have observed the photon bounce back and forth  times on the ship. The stationary observer sees the photon bouncing back and forth in a diagonal path of length . But because of the diagonal path is longer than , the photon will only bounces back and forth times in one second.

This implies that what I experienced as one second on the ship (seeing the photon bounce  times) is in fact more than one second to the stationary observer. Time slows down when you’re moving fast!

How can this possibly be? What you have to accept is that space and time are relative. Everything slows down when you’re moving fast: the clock, molecules, your brain! I can see light moving at . The stationary observer sees the same ray of light moving at .

The Nash Equilibrium is Real

As someone who studied business and economics in College, I encountered game theory in multiple classes. In particular, the prisoner’s dilemma was something we studied in at least three classes. Being the student that I was, I learned what the theory was and moved on.

Fast forward eleven years, I finally experienced this theory in a very real and unfortunate way. It wasn’t that I committed a crime, but rather a more general case of the phenomenon. From wikipedia:

In game theory, the Nash equilibrium is a solution concept of a non-cooperative game involving two or more players, in which each player is assumed to know the equilibrium strategies of the other players, and no player has anything to gain by changing only his own strategy unilaterally.

I previously worked at a financial services institution where I was growing restless. A colleague of mine, whom I respected very much, was in the same boat. Let’s call him Jim. Jim and I often talked about starting our own company to escape the BS and realize our full potential.

Then there was another one of our colleagues, whom I’ll refer to as TDB. I had referred TDB to my company because a good friend of mine had asked to as a favor. He didn’t have the right experience to be hired at this institution, but through my goodwill, he was hired. TDB never hesitated to cash in on my goodwill and often presented himself as a good friend of mine when the reality is that he is a friend of a friend. At the time, I didn’t mind, I had no reason to.

As Jim and I increasingly talked about our plans, TDB would tag along in these conversations and interject himself in our endeavor. I knew that I didn’t know TDB enough to want to go into business with him. That and as I got to know him more, he exposed himself more and more as a person with questionable character. At the same time, he was seemingly intelligent, and maybe his help wouldn’t be all that bad. TDB did his best to befriend Jim. Jim thought I was good friends with TDB as TDB always presented our relationship that way, so Jim gave TDB the benefit of doubt. The more I saw Jim with TDB, the more I thought Jim saw good qualities in TDB.

Through mutual respect between Jim and me, a positive feedback loop was created. The more I saw Jim and TDB in good repport, the more I trusted TDB. The more Jim saw TDB and I get along, the more he trusted TDB. In the way which animal spirits create disastrous financial bubbles, TDB gained a lot of superficial respect from Jim and me by this positive feedback loop.

Fast forward another year or so, we’re co-founders of a startup. It’s a story I will tell later, but the cliff note version is that TDB single-handedly destroyed the startup twice. The first was salvageable, but the second was not.

Back to theory. Jim and I were essentially playing the prisoner’s dilemma game. We both unilaterally decided that TDB was fit to be our co-founder. If we had collaborated more and conversed frankly about what we thought of TDB, he wouldn’t have been part of the picture. If we had been able to speak without risk of potentially offending each other, we would have ended up at the best possible square of the game, without TDB.

It’s not everyday that I see economic theory applied to the real world. Economic models are often an over-simplification of the real world that it just doesn’t apply. In this case though, the gist of the Nash Equilibrium was demonstrated in a terrible way.

The most important thing I learned from this failed startup experience is to pay a lot of attention to the dynamics of the situation. In finance, valuation of derivatives is all about understanding the stochastic factors underlying the security and figuring out the expected value of the derivative given those stochastic factors. If the dynamics my startup were more fully understood, it would have been easy to see that destruction was the most likely outcome.

Yes, hindsight is 20/20, but that’s what I’m working with. Til next time.