No Water, No Moon

Arman Suleimenov: daily essays on startups, life hacking and happiness.

August 22, 2013 at 11:28pm


The Top 10 Electrifying Insights from Stanford Superstar Feross Aboukhadijeh


Expected read time: 8-12 minutes

This was by far one of the most inspiring episodes of Princeton Startup TV. Sometimes you have high profile entrepreneurs or professors as your guests, and you, as an interviewer, get nervous, look up at the authority too much and do a terrible job as the result. You suck because you are afraid to suck. The impossibility and rejection of failure limits your ability to succeed. You’re afraid to fail, you’re afraid to improvise and resort to the cheapest trick - going through the list of rehearsed questions. Without any follow-ups, and forgetting to even look in the interviewee’s eyes. The interview doesn’t feel like the conversation. If the host is not at ease, how should the guest be? The result is zero insights and waste of everyone’s time.

But this time things were different. Nice May evening on Castro Street in Mountain View, CA was conducive to the relaxed atmosphere and an interesting conversation. Feross was awesome and here are 10 of his insights which made the biggest impression on me. Note: skip the first two if you’re not feeling like reading the technical details.

1) Start from the first principles and question assumptions.

In the midst of my current project I’ve been working on (which we should talk about by the way because it’s awesome and I’m really excited about it) - I was playing around with local storage. Local storage is the HTML feature that is sort of like a super cookie. It allows you to store up to five megabytes of information on the user’s computer. It’s pretty handy, because before this feature it was really hard to store any substantial amount of data on the user’s browser. Anyway, I was playing around with it and I was reading the spec, which is very short. I noticed that the spec says that every single domain should be allowed to have its own storage space allotted by the browser. That way, a given site can’t use more than 5 megabytes, so they can’t fill up your computer’s hard drive. It’s sort of a security precaution. Of course, when I read something like that, I always want to go see if that’s how it actually works, if the browsers have implemented the spec correctly. It turns out that everybody, except for Firefox, did it wrongly. They allow you to make different subdomains on your site, and each subdomain gets its own different allocation of five megabytes of space. So if you make a thousand subdomains on your website, you now have five gigs of space on the user’s computer. So the website I made to demo this. Here’s this site you visited, and without even asking for your permission it fills up your hard drive with pictures of cats. It doesn’t even wait for you to notice what’s going on.

2) On building the cheap content delivery network which as fast and as reliable as Amazon or Akamai.

The idea is to make it so that when you are on a web page as a visitor; you are basically, sharing your web cache with all the visitors who are on the site with you. So, when a new visitor comes to a website before they get the resources for that page from the server they first ask the peers that are near them if the peers have those resources and if they do they will fetch the resources in a peer to peer fashion and then they can avoid basically, taxing the site server at all. So, the site saves RAM. The site saves servers.

So basically, the way it works is - it uses a WebRTC which is this new browser specification. It’s honestly, the coolest thing I’ve seen in ages. I think more people should know about it. I’m surprised. It’s been sort of talked about on Hacker News and in a few places. The thing that’s sweet about it is that you literally can open up a socket to another browser and talk and send arbitrary data down that connection. This is peer to peer on the web and this is the first time this has been possible. You could have used Flash in the past, but there is a lot of problems with the Flash solution that this addresses. Anyway, I think this is a huge revolutionary thing and there’s going to be all these applications that are going to be built on top of it, from the most obvious things like Bit Torrent clients that you don’t have to install. You literally can imagine going to Torrents site and clicking on a movie you want to watch and then having it play like YouTube. That’s one awesome use case. There is going be a whole bunch of non-obvious ones. I think PeerCDN is another unexpected one. It’s like, woah, we can actually build a content delivery network that is as fast and as reliable as something Amazon offers or what Akamai offers and do it for much cheaper.

3) Memorable interactions with Mark Zuckerberg.

One thing is when I was at Facebook I got to interact with Mark Zuckerberg a bit. The way the team worked was there were three full-time engineers and two interns. I was one of the interns on the Groups team. What happened was, the team had just formed before I got there. The mission of the team was like Facebook Groups currently suck because no one uses them for actual communication with their friends. It’s all these memes and these stupid things so let’s throw them away and do something better. It was interesting to see how the team interacted with the leadership in the company and how that process worked. For example, for the last two months of the summer, our team had its own room, called the War room, where everybody was basically working really hard to finish. Zuck would come by in the evenings around 8:00 or 9:00pm. and of course most of the team was still there. And he’d come by and I’d be like “Hey” and he would say,  ”Show me what you’re working on”. He would talk to interns all the time. He would ask, “Show me what you’re working on”. I thought that was really good leadership strategy. Especially, at the size they were at, at the time. To see the CEO go around and talk to interns is very, very, good thing. Actually, I think it is quite rare in other companies to see that.

When I was first assigned I was actually really mad because Groups is a terrible product and I was like, I don’t want to work on this thing that is the worst feature in Facebook. Why am I going to work on this? But then I found out they were building a whole new version and it was very exciting at that point. And one thing that Zuck does really well is that he has a very, very good product sense. He understands the psychological motivations of Facebook users very well. He is able to take a look at a product, and be very perceptive and anticipates how a particular feature or UI change or messaging in the product will affect the users and affect the way that it gets used. He anticipated a lot of things that I initially disagreed with in terms of the product but it turned out to be right after we did testing and I thought that was a really cool thing to see and I learned a lot from that.

4) A little bit of slope makes up a lot for y-intercept!

We have this one professor at Stanford who teaches Operating Systems. His name is John Ousterhout and he was a generally, awesome professor in terms of teaching the material, but this one thing he did, that was above and beyond just being a good teacher of material, was that every Friday he would spend the last fifteen minutes of class just giving a life lesson for the week. He called it “Thought for the weekend.” It was something very inspiring or an insightful idea about life. He is an older guy, so he has lived for a while and he’s been doing software his whole life. He still programs and he is around sixty. He’s still working on cutting edge amazing stuff. His current project is RAMCloud. It’s this idea to make this cloud that lives totally in RAM so it’s super fast. And for particular workloads it’s really well-suited. Anyway, one of his lessons that he told us about was if somebody is better than you at something - their skill level is up here and yours is here - you shouldn’t let that make you sad or feel like you’ll never be able to catch them. Because a little bit of slope makes up a lot for y-intercept. So if your slope is this, and their slope is like this - maybe they’re a software engineer, they’re not learning anything new, or they’re just doing their job but they seem sort of god-like in that they’re so good. But you learn really fast, really quickly, and can catch up to them and start to pass them if you keep your slope very high. So the most important thing is the slope and not the y-intercept.

5) If I could have dinner with anyone in history, that would be TJ Holowaychuk!

Someone who’s alive that I would love to meet is TJ Holowaychuk. I was joking with a friend that if I ever see him I’m just going to walk up to him and give him a hug. He’s a node.js developer who has written so many modules for the community that it’s impossible to make a project using node.js and not use something that he’s written. He writes all these core infrastructure features that everybody else includes in their projects. His output is just prolific. If you follow him on GitHub you’ll see that he does a hundred commits a day, opens and closes all these issues, and he’s managing hundreds of repositories. He started this project called Component, the idea which is to make a package manager for web components, like date pickers, forum elements and things that include CSS and Javascript. That project has thousands of little components under it and he’s constantly working on all of them and accepting pull and push requests and, just in terms of something to aspire to as a programmer, he’s super-inspirational to me. I’d just love to talk to him about how he does it and why he does it. I want to know how much time he spends in front of a computer. He really doesn’t go a day without having tons of stuff on GitHub. So I wonder, does he go outside? I want to ask him that. TJ, if you’re watching this, send me an email - feross [at] feross [dot] org. I want to know the answer.

6) You have to be completely sold and bought into the idea that you’re going to succeed. 

I had this friend and she had this idea and said, “I want to run 40 miles to Sausalito”, and I said, “You’re crazy, you can’t do that, you have to train for this, people train for months before they run a marathon, what are you thinking?”. I was very skeptical at first but I thought about it and the next day I was thinking, I haven’t had a really epic adventure in my life in a while and I think that it’s important to have some sort of epic adventure every 3 months at the least - I hope preferably more often than that. So I just decided to do it and thought - worst-case we would stop after 15 miles and have a very nice workout, but we adopted the only rule was that we can’t say anything negative. We can’t say that we’re not going to finish. You have to be completely sold and bought into the idea that we’re going to succeed. There’s a lot of parallel to start-ups. What’s a reasonable distance to run? 10 miles, maybe? And we said we’re going to do 40, which is 4 times more - beyond what’s reasonable. Everyone’s telling you that it’s not going to work that your body’s going to break down. So we said okay, maybe you’re right but I don’t care. I’m going to try anyway.

I was really sore the next day and it was kind of painful to walk up and down the stairs in the house. But I’m fine now, I can run around right now. It’s been only 5 days and I’m already fully-recovered. I think that it’s really something that anybody could do. It’s not like you need to be a runner. If you go slow enough and you pace yourself you can achieve quite a surprising distance - another start-up parallel. If you show up and regularly work and push forward you can achieve amazing things over the long-term. It’s not like pulling an all-nighter and hammering out tons of code.

7) Remember: the point of programming is to make things!

Why is programming an interesting thing? Why do we program? You program because we can change the world. We can build things that didn’t exist before. While it may be interesting to build a beautiful program because it’s pretty and makes you happy, if it doesn’t do anything useful then you shouldn’t kid yourself. Don’t think you’ve done something useful. That’s only useful for your own satisfaction with the beauty of it. Most people aren’t programming for that purpose. They forget the purpose of programming.

That’s why I laugh at the whole meme on Hacker News where people make fun of Javascript or PHP. I think both those languages have problems, but I think that the kinds of people who spend all day writing long rants on those languages aren’t spending their days being productive in their language of choice. What are they doing? They’re missing the point. There are people out there using Javascript to build awesome things. We shouldn’t listen to people who don’t have output. That’s the thesis: remember the point of programming. The point of programming is to make things.

8) On staying interruption-free and being on the ‘maker’s schedule’.

- I try to not schedule meetings during the week at all. I have four days that are blocked off completely, Monday through Friday. If I try to put a meeting or a lunch in the middle of the day, it will ruin my flow. I save that for the weekend or Friday. I turn off or ignore my phone when I’m working. All my text messages accumulate during the day and I deal with them later. It makes people a little mad, but at the end of the day, you have to prioritize yourself.

9) Learn a new technology as a side-effect.

The best way to learn a new technology is to think of a use case for it. Find something specific you want to build that will use it. Then you focus, not on learning the technology, but on building that thing you want. As a side effect, you’ll learn the technology. You do it as you go.

It could be an entirely new project. You could go to a hackathon and say ‘I want to learn WebRTC’ or ‘I want to build something using WebRTC.’ The goal isn’t really to learn WebRTC, the goal is to build the thing. That makes the learning an organic process of building something. I’ve found that when I first was learning programming, I would get a book and read it front to back, and then when I would try to use it, it was very ineffective. It’s the worst way to learn. I would never do that again. By the time I got to the end, I forgot what I read at the beginning. The only way to solidify your understanding is to use it.

10) Don’t be a talker, focus on building!

My advice to future hackers is to focus on building stuff. Be very diligent about being a doer and not just a talker. The world is full of talkers. The ratio is some ungodly number like ten talkers for every doer. These people just like to talk all day about projects. They’re very smart people. They know about a lot of things. But at the end of the day, they don’t produce anything. They don’t execute. They don’t build. Be a person who balances those things very well. Spend some time thinking high-level about what you want to build and then spend a block of time building that thing. Maybe it will fail. Maybe it will succeed. Don’t just have it at the idea stage forever, just talking about it. Once somebody else does it, don’t say “That was that idea I had a year ago, I thought of it before they did.” So many people do that, just think of Facebook. Be relentlessly focused on building and doing.

P/S: The video as well as the full transcript of the interview are available here.

Arman (follow me on Twitter at @suleimenov).



  1. groundbreakin reblogged this from nowaternomoon
  2. nowaternomoon posted this