Forgotten but Not Gone
There was at least one place, I would discover, where that “instant” of Borges persisted, a land where Borges lived on as both Borges and “I,” legend and life. That place is Texas. Starting in 1961, Borges made five visits to the state—first, to teach for a semester in Austin as a visiting professor; then to lecture on Cervantes and Whitman as a literary celebrity. When Borges died on June 14, 1986, the University of Texas’s main campus lowered its flags to half-mast, a rare tribute for a writer and a perplexing honor for one without deep Texas roots. Why had Texas so embraced Borges? And why had Borges continued to return there throughout the final twenty-five years of his life?
In early January, I began to investigate what seemed a long-forgotten romance. From New York, I emailed the Ransom Center’s staff about my search for Borges, and they replied that they’d be eager to help me. Indeed, there in the Hill Country, they had a treasure trove of Borges’s work. There was a film-script outline on which Borges collaborated! An autographed draft of his classic revenge story “Emma Zunz”! The completed pages of “Los Rivero,” a fragment suspected to be Borges’s never-finished novel! And, most promisingly, five notebooks full of handwritten essays that might shed new light on Borges’s time in Austin. I was convinced that at the Ransom Center, I’d discover the living, breathing Borges who had so enamored Texas. I booked my trip that week.
(via the-feature)
: Stock, Flow and why we are working on The Shared Web
I read an article today on The Shared Web, that discusses two types of value that you create from your work and uses them as a metaphor for media today - Stock (durable stuff - blog posts that can be read 2 years from now and still be useful) and Flow (status updates on Twitter that engage with…
Flow is always being one pixel away from perfection
Asking the right questions (or why Program Managers at Microsoft are useful)
I’ve been thinking a lot about the hidden assumptions that are communicated every time I talk with someone. The non-verbal cues and context that are intangible, but are the starkest reminder of the difference between asking a person to do something (where you DON’T have to detail all the requirements) and telling a computer to do something (where you DO have to detail all the requirements). Knowing that communication is laden with inferences, then noticing and rectifying (with a question) when there may be a misunderstanding, is one of the most important lessons I learnt as a Program Manager at Microsoft. It’s one that I think that all hackers/product managers should internalize, to keep their team running effectively, and deliver the product on time with the right feature set.
Asking the right questions is a skill that every body looks for but is hard to quantify. Here is how I think of it:
Imagine I ask this question - A person mows 2 lawns in 2 days, how many days would it take them to mow 1 lawn?
A common answer to this question is 1 day, which assumes that the person mows the law at a steady rate. The correct response, in my opinion, is to ask if they mow the lawn at a steady rate - then decide if you can answer the question with the given information or not.
It’s these kinds of assumptions that lead to miscommunication, delays, and unmet expectations. However, asking the right questions does not mean asking every question; it does not mean being pedantic. The art is knowing when to ask and not just what to ask. Mastering this art helps you get the right outcome by avoiding possible problems in the future without adding more layers of process. i.e. Use your insight to ask questions about opinions that are masquerading as facts, or assumptions that could be problematic and dig deeper into them. This is instead of just asking questions that slow down meetings and aggravate their participants.
I’ll end this thought with an example of an episode of miscommunication that happened while I was at my 1st year at Microsoft. I was working out of the Canadian office in Vancouver, when two of my friends were having a heated debate about the usefulness of PM’s (and all the questions they ask!). I overheard the conversation that happened next:
Dev 1: Anyway, what did you do last weekend?
Dev 2: I went to Cyprus.
Dev 1: How was it?
Dev 2: Really cold, but I really enjoyed it.
Dev 1 (suprised and slightly incredulous) : I remember it being really warm this time of year, but I was there a while back, I guess it must be global warming messing with the weather.
Me: Hey guys, I overheard you and I just thought this would be a great time to tell you why PMs are useful and why they ask so many questions :) You are talking about Cyprus the mountain (10kms from Vancouver) where it is very cold right now and you are talking about Cyprus the country - where it is very hot….
Dev 1 and Dev 2 : Nods of understanding and mild embarrassment.
3 Lessons for Startups from Arthur C. Clarke’s Superiority
I just finished reading ‘Superiority’ by Arthur C. Clarke and I found it to be a great parable of the perils of over engineering, pre-emptive optimization, and how having the best product/technology doesn’t guarantee success.
If you are not familiar with the story I encourage you to read the full text, otherwise I’ll try to summarize the relevant sections. Basically, it’s the story of two empire’s war in the far future and the series of faulty strategic choices, in particular in the pursuit of technological superiority, by one of them, that leeds to their defeat. The empire that starts by having better technology and vastly outnumbers its enemy, falls to ruins by it’s purusit of advanced ‘killer’ technology even though they didn’t need it to win the war. They end up misjudging the challenges of integrating their new technology and underestimating the number of things that can go wrong. Their cheif scientist intices them with the promise of quick victory, and unheard of power. He wins over the military decision makers with flashy demonstrations and unshakable conviction. They create new weapons that require updating their fleet and face unexpected delays. They discover faults that start out being ostensibly minor and end up costing them their empire. In the mean time, the other empire, laggards technologically but marching steadily and increasing in numbers, relentlessly marches onwards and takes advantage of each mistake.
I think you already see the analogy by now. This was a great reminder of the adage: don’t fix what isn’t broken. Sexy new technology is interesting to learn about and to use when appropriate. However, especially at a startup, where time and momentum is everything, it’s important to remember that the technology and even the product are just parts of the equation of providing value to your users and leading your business towards success.
My co-founders and I learnt this lesson the hard way at The Shared Web, where we are building a social news product. We were very excited about NoSQL databases and saw many justifications (that eventually may be vindicated) to use Cassandra. We did not correctly anticipate the set backs that we would face with emerging technologies - bugs in libraries, the impact of the learning curve on our development speed, the number of breakdowns when using Cassandra’s CLI, etc.
Here is what we (re)-learnt:
1. In Superiority, one of the empires started out with an advantage (they would’ve won the war) but wasted it in their attempt to out innovate the competition and possibly accelerate their victory. So when working on a new product if you are proficient in certain technologies don’t try to pre-emptively optimize by using sexy promising technologies you are not familiar with. In our case, whilst architectural decisions are very important, our main objective in the beginning was to find product/market fit and then we could optimize our stack, whatever technology gets us there fastest is the right choice.
2. The best product does not always win. In the story, the new empire had better technology at the end but they ran out of time as their enemies, with inferior technology, kept making advances and taking ground. The analogy to that in the startup world is running out of money while building the ‘perfect’ product, you need to continously be acquiring users and developing your business whilst improving your product. Your product is just one part of your business.
3. Don’t underestimate the number of things that can go wrong when you are using something new. This is a lesson worth hearing every once in a while. Even if something takes only a few days more than it normally would have, that’s a big deal when you are building a startup. That’s time you could have spent doing more faster.
InnovationInspiration: 10 Ways Technology is Changing Education (Part 1)
Watching TED Talks, it seems like the most common theme is the paradigm shift that education is due for. The revolution in teaching and learning is two fold. On the one side it comes from new psychological studies about educational techniques, examining what works and what doesn’t….
Of the “pale blue dot,” astronomer Carl Sagan said: “That’s here. That’s home. That’s us. On it everyone you love, everyone you know, everyone you ever heard of, every human being who ever was, lived out their lives. The aggregate of our joy and suffering, thousands of confident religions, ideologies, and economic doctrines, every hunter and forager, every hero and coward, every creator and destroyer of civilization, every king and peasant, every young couple in love, every mother and father, hopeful child, inventor and explorer, every teacher of morals, every corrupt politician, every ‘superstar,’ every ‘supreme leader,’ every saint and sinner in the history of our species lived there—on a mote of dust suspended in a sunbeam.”
Your thoughts in bytes
I recently read in a book on speed reading that one of the reasons you may daydream while listening to someone speak, is that invariably thought is faster than speech. The author went further and boldly estimated that on average you think at about 400 wpm vs speaking at 150 wpm. This got me thinking about a number of things. First I wanted to analyze, highlight and decouple all the assumptions that were made in that statement.
Here is my intial attempt:
1. You think in words.
2. He makes no statement on the composition of the words - length, number of syllables, obscurity, etc.
3. The number of words per minute that comprise your thoughts is language agnostic
We can take this a step further and add the following assumptions:
1. Even if thoughts occur and are manipulated in a form other than language at some point they are translated into words.
2. We must be able to think faster than we speak or else we wouldn’t be able to have conversations.
3. Thoughts and meaning can be encapsulated in words even if not fully. We can ignore any loss off efficiency or decrease in the number of thoughts that one has per period of time due to the the process of translating mind speak to language.
4. For the purposes of this discussion, I’ll ignore any other forms of thought that can be processed in the brain. i.e. Ignore visual, auditory, tactile, etc
Where am I going with this? I want to calculate, based on these assumptions, an approximation to the size - as they would be represented on a computer - of conscious thoughts that are processed by the human mind every day.
Let’s get to it.
1. 400 WPM - Number of thoughts expressed in words per minute
2. Let’s use English for this example to keep it simple. Assume 5 characters per word on average. That is 5 bytes per word.
3. 400WPM x 5bytes/word = 2000 bytes/minute ~ 1.95kb/min ~ 2.8Mb/day
We know that the brain processes, manipulates and creates much more than words however as a first approximation, based on the previous assumptions, the number of thoughts - represented in words - that you think of each day would fill up 2 Floppy disks from the 90’s.
More thoughts on this in the coming few weeks.
