From The Ground Up

Fwd: Engineering, startups and life

Dare To Give Yourself The Opportunity To Win

leave a comment »

Though not as well known as other founders, Dalton built a great product in picplz. Unfortunately for his team they were just unable to match Instagram’s growth. Dalton’s response to criticism here reads like an entrepreneurial manifesto. These thoughts can be viewed in a grandiose light and are thus easy to ascribe to. But only when you walk the path do you realize the truths here and the emotional investment that prompted these words.

Anyone reading this article needs to remember to never be afraid of putting yourself out there because you are afraid of failure.

I saw the market first, I created picplz, and I went for it. I was a huge believe in the mobile photo sharing opportunity, and I went for it with all of my heart. Clearly, picplz didn’t win, but I have ZERO shame or regret for doing my best.

When I read articles like these, which are about myself, my company and people that I know well, I can’t help but feel vitriol aimed at me for DARING to create, launch and raise funding for picplz. I am not clear on what exactly people want, an apology for trying?

The fact is, I saw the writing on the wall that we wouldn’t win early and pivoted out of photo sharing which I had ~90% of my series A cash still in the bank. It certainly seems like that was the right move, but all of this press makes it look like pivoting was the wrong call(?) The press I read is written in such a way that it assumed that the A16Z investment is dead and my entire company should just be written off to zero today. That is bullshit. If I started to take press like this too seriously I might as well just dissolve my company and stop coming into work.

I say this to the hn comminity: never be afraid of failure. No one knows what will happen. All of this arm-chair quarterbacking is a waste of time. Stop reading this kind of crap and instead put your energy into doing your best work. Sometimes you win, and sometimes you lose, but if you give yourself the opportunity to win enough times, you WILL be successful.

Dalton Caldwell, Founder of picplz

There is so much good advice packed into these few paragraphs. Often the smallest ideas grow and grow into a larger vision, and big vision companies with vaults of cash crash and burn. He’s right — no one knows what will happen. But this fact should never stop you from trying. The unknown outcome is what makes this adventure so exciting.

 

Written by Girish Rao

July 11, 2012 at 23:01

Posted in Uncategorized

Intuition Versus Rationalism

leave a comment »

I love this excerpt from the biography Steve Jobs by Walter Isaacson. Steve Jobs truly delivered products that seemed like they had been beamed in from the future. I believe that while a lot of decisions at Apple are based on cold, hard data and facts, the overall vision and user experience that Steve imagined was one drawn from an intuition, innate and plugged in to help push humanity in to the future.

 *

Coming back to America was, for me, much more of a cultural shock than going to India. The people in the Indian countryside don’t use their intellect like we do, they use their intuition instead, and their intuition is far more developed than in the rest of the world. Intuition is a very powerful thing, more powerful than intellect, in my opinion. That’s had a big impact on my work.

Western rational thought is not an innate human characteristic; it is learned and is the great achievement of Western civilization. In the villages of India, they never learned it. They learned something else, which is in some ways just as valuable but in other ways is not. That’s the power of intuition and experiential wisdom.

Coming back after seven months in Indian villages, I saw the craziness of the Western world as well as its capacity for rational thought. If you just sit and observe, you will see how restless your mind is. If you try to calm it , it only makes it worse, but over time it does calm, and when it does, there’s room to hear more subtle things — that’s when your intuition starts to blossom and you start to see things more clearly and be in the present more. Your mind just slows down, and you see a tremendous expanse in the moment. You see so much more than you could see before. It’s a discipline; you have to practice it.

Zen has been a deep influence in my life ever since. At one point I was thinking about going to Japan and trying to get into the Eihei-ji monastery, but my spiritual advisor urged me to stay here. He said there is nothing over there that isn’t here, and he was correct. I learned the truth of the Zen saying that if you are willing to travel around the world to meet a teacher, one will appear next door.

Written by Girish Rao

July 9, 2012 at 14:30

Posted in Uncategorized

leave a comment »

I do not think there is any thrill that can go through the human heart like that felt by the inventor as he sees some creation of the brain unfolding to success… such emotions make a man forget food, sleep, friends, love, everything.

Nikola Tesla

Written by Girish Rao

July 9, 2012 at 14:27

Posted in Uncategorized

Hacking Growth To Your First 500K Users

leave a comment »

Engineers are used to solving problems using a certain approach. Generally it can be defined in the following way: 1. Precisely define input and output requirements (let’s set aside performance, non-functional, etc requirements aside for the purposes of this post) and 2. Iterate in a deterministic way until your approach (algorithm) achieves Step 1.

The key here is that this approach is largely deterministic. Software is driven by cause and effect. Engineer says, machine does. (As we all know, almost to a fault. If only the machine could tell us how to do what we are really trying to get it to do!). We know that if we tell the machine to do something it will do exactly that. Furthermore, if some piece of code fails once we can be fairly certain the code will fail again in the exact same way, regardless of the machine on which we execute this piece of code.

In this way, humans are very different. And this is part of what makes marketing and growing the user base of a product so challenging. While overarching patterns in human behavior may be identified, on a day to day basis we have no idea who will respond to a certain product or promotion positively. We can’t even say for certain if the same person will respond the same way to the same product next Tuesday.

To have your product capture the attention of as many people as possible, and as many types of people as possible, and to grow your number of active users, you need a multi-channel approach. Some efforts will fail miserably, while some will succeed for no obvious reason, while others will succeed after a quirky fix to a campaign. The human mind is not so deterministic. You need to take the time to understand your users.

I came across this slideshare that highlights some of the wide-ranging, far-reaching efforts necessary to grow your user base. Unlike in engineering, the relationship between cause and effect is not so clear when managing users and user growth. Like our ancestors, your strategy for driving user adoption will have to evolve and adapt.

Written by Girish Rao

June 18, 2012 at 11:12

Posted in Uncategorized

Building Relationships With VCs

leave a comment »

Building a relationship with a VC or angel is just like building a relationship with anyone else. It needs to be fostered and it takes time. Above all, time to build trust and respect, and time to build a sense of how each of you approach problem solving, and how you work together when problem solving.  Along with these things you get to figure out if you actually like the guy or girl enough to be a passenger on your startup rollercoaster. I pulled this simple yet helpful list from a PandoDaily post written earlier this year by John Lilly.

John Lilly is a partner at Greylock Partners. Prior to Greylock, John was CEO of Mozilla, makers of Firefox.

Written by Girish Rao

June 16, 2012 at 20:00

Posted in Uncategorized

What If Everything Ran On Gas?

leave a comment »

Written by Girish Rao

June 16, 2012 at 18:49

Posted in Uncategorized

leave a comment »

Written by Girish Rao

January 10, 2012 at 13:14

Posted in Uncategorized

Talent Wins Games, Teamwork And Heart Win Championships

with 2 comments

In his autobiography Rare Air: Michael on Michael, Michael Jordan talks a lot about teammates and teamwork. One page I distinctly remember has a picture of Jordan on the court in his red home jersey bent over with his hands on his knees, and Scottie Pippen is standing next to Jordan with his hand placed on Jordan’s sweaty, shaved head . It was a picture taken by acclaimed photographer Walter Iooss Jr. during the heated NBA playoffs in the early 90s and it tells a thousand words.

There’s a weariness in their body language, they are exhausted or very close to it. But there is also a sense of determination and connectedness, a feeling between the two players that they are going to fight through the challenges in front of them together and as a team – that they would fight together. Jordan obviously carried the team, but he was never alone, it was as a team they won the championship that year and for so many years after.

Another paragraph in the book quotes Michael while he talks about his pick-up games he’d play during practice or on the blacktop. He always played to win, no matter the stakes, no matter the players, so high was his competitive enthusiasm. He said, and I paraphrase, “Give me a teammate with talent or give me a teammate with heart, and I will choose the teammate with heart every time”.

Talent will take one only so far, and relying on talent alone can often lead to excess ego. Someone with heart is usually someone who takes on any role for the team to succeed, someone who admits they don’t have all the answers, learns from others, and is hungry enough to be coached. Someone with heart has an internal fortitude to give that something extra when success is on the line. With heart comes determination and perseverance.

The photo of Jordan and Pippen embodies this sentiment. The Chicago Bulls were smart and lucky enough to build such a team around Jordan.

 

Building a startup requires people of similar character, especially at the founder level and with early hires. In order for a startup to grow and flourish, you need teammates willing to take on multiple roles, put in long, hard hours, and absorb and learn new things.

I don’t mean to berate talent. Talent is so important, critical for success and talented people are hard to find. But talented people with the determination and perseverance to run through walls with you are even more difficult to find. They separate the wheat from the chaff.

Written by Girish Rao

January 9, 2012 at 13:33

Posted in Uncategorized

Your System Is Defined By Data. Engineer Accordingly.

leave a comment »

Data used to be the realm of scientists, researchers, and mathematicians in government institutions, universities or massive corporations (think banks). Even in the latter case, and still today, data is often buried under layers of infrastructure and protocols.

The internet and increased bandwidth/accessibility over the past decade gave birth to the democratization of data. Okay, democratization is a big word, but you get the point. Data is being generated everywhere in various forms and is being collected and analysed by anyone who desires to do so.  Even governments are opening up their troves of data to the public with the goal of greater transparency and efficacy.

In order build 24/7/365 web-scale applications on top of this data, we need to think about data in a disciplined way. The system does not stand alone. Data is part of the sytsem. Testing and measuring the system’s response to different types of data and/or increased loads of data requires a framework that informs the engineering team.

To that end, here are eight parameters that should be accounted for when building systems that deal with high volume data. These are things to think about up and down the full stack, not just the “back-end” or the “front-end”.

1. Total data size.  This is the amount data the system reads and writes while operating.  The proportion of data read to data written varies among systems. A site like the NYTimes.com ostensibly performs many more reads (serving articles to each visitor) than writes, while an email application may need to handle more writes when accounting for spam. Some systems can generate massive amounts of secondary output such as log files. The growth of these outputs should also be taken into account.

2. Growth and change. How fast is data added to the system? Can older data be edited? Can data be removed? If so, how often do these types of transactions occur? Knowing how fast your data grows and changes is critical to understanding system performance and tackling scalability. Set up an internal testing component that simulates increasing data loads and run your system against this to see how it responds to different operations.

3. Temporal axis. Almost all data has some temporal nature, whether it’s a publication date, location timestamp, or time of last access. The system often needs to handle data differently depending on where the data lies along the time axis. For applications such as email and to an even greater extent on Twitter, older data is less frequently accessed. Conversely, users of Facebook very often look at pictures taken months or years ago. This is even more true with Timeline. Data must be stored with these access patterns in mind.

4. Network vs Disk vs RAM vs CPU. I’ve stated these in a specific order, you should know why. To borrow and mutate a common phrase — Know thy system. One of these four components will be your bottleneck as the amount of data grows. A bottleneck at the CPU indicates that your algorithms and processing is slow (perhaps you’re doing a lot of compression or maybe you’ve nested one too many for loops). Conversely you may have an “I/O bottleneck” where the system spends most of its time fetching data from disk or over the network. In this case maybe you’ve missed an index on a database table or maybe you need to think about distributing your data to increase read/write throughput. Think about whether you should be bringing the computation (“CPU”) to the data rather than trying to fetch large amounts of data to a processing component.

5. Throughput. Throughput is defined by two numbers: request size and request rate. Request size is the amount of data the applications reads or writes in a given call or user transaction. Request rate is how many transactions occur each second or each minute. Request rate is defined by the number of concurrent users and the distribution of activity levels across those users (from power users to casual users).

6. Consistency. This becomes more of an issue when dealing with distributed data. One machine or storage unit may be written to with the most up-to-date data, but the other storage units need to be updated as well. Different storage systems tackle this problem in different ways. MySQL Cluster uses the two-phase commit which has long been in use but gives up some availability (MySQL Cluster assumes some level of redundancy). The recent NoSQL movement sacrifices consistency for availability. The strategy used depends heavily on the application and use cases. In cases such as at an ATM, you expect your checking account to update immediately after withdrawing cash. In other cases, such as updating your Twitter profile, the consistency requirement is not as strong (although it does make for a frustrating experience when you still see your old profile up several minutes after editing it).

7. Latency. How fast does the application need to respond to a user’s action? When performing a friend search on Facebook I expect the friend to be returned within a second or two. When buying tickets to a show online however, I would expect this transaction to a take a few seconds longer. My tolerance for waiting is higher here. Your application should optimize for frequently accessed data, either by indexing the data or caching the data.

8. Physical and logical proximity. Data that is requested together should be stored together. When I visit a friend’s Facebook page, all of her pictures need not be loaded as well. Information that appears on a friend’s profile page such as name, profile pic, age, location, statuses should be stored close to each other so that these bits can be retrieved more efficiently. Sharding is one strategy used to keep commonly accessed pieces of data close together while simultaneously using the advantages of a distributed system.

“Big data” in and of itself is not useful. Bryce from OATV wrote a great post about “big data” and it’s shortcomings. However it’s still up to us to build the systems that can deal with this type of data and it’s up to us to then figure out what data is useful and what isn’t. To be hamstrung by your own system is not a place you want to be.

Engineer and test with discipline and you will be headed in the right direction.

Written by Girish Rao

January 4, 2012 at 20:08

Posted in Uncategorized

You Can Build Your Own Things That Other People Use

leave a comment »

…Life can be much broader once you discover one simple fact — and that is everything around you that you call life was made up by people that were no smarter than you. And you can change it, you can influence it, you can build your own things that other people can use…

Written by Girish Rao

January 3, 2012 at 15:14

Posted in Uncategorized