tag:blog.chriszacharias.com,2014:/feedChris Zacharias2023-11-08T22:00:51-08:00Chris Zachariashttps://blog.chriszacharias.comSvbtle.comtag:blog.chriszacharias.com,2014:Post/eat-sleep-exercise-work2023-11-08T22:00:51-08:002023-11-08T22:00:51-08:00Eat. Sleep. Exercise. Work.<p><img src="https://cz.imgix.net/yc-s2011.jpg?w=1920&h=1080&fit=crop&sharp=75&txt=YCombinator+S2011&txt-size=48&txt-color=fff&txt-pad=48&txt-shad=10&txt-align=top,right" alt="YCombinator S2011" title="The first week of YC Summer 2011"></p>
<p>“Eat. Sleep. Exercise. Work.”</p>
<p>I remember Jessica Livingston telling our YCombinator batch this in our first week of the Summer 2011 session. As a first time founder, I was terrified that I was expected to never see my friends or family again and that extracurricular activities of any kind had to be foresaken if I wanted any chance at being successful. Looking back, I have to laugh, because I was so naive.</p>
<p>For the vast majority of us, this was not an immediate call to eliminate distractions… it was a pointed reminder to eat, sleep, and exercise!</p>
<p>What most traditionally employed people, like myself at the time, would not understand is how unbelievably intoxicating it is to put your shoulder into the millwheel for the first time and feel it turning. Especially in the early days of founding your company, every minute you spend feels so incredibly consequential, and very often, it is! You can very viscerally feel how the work you are doing has the potential to create exponential value. Conversely, everything stops the moment you stop. So the temptation is there to just never stop working. If you are lucky enough to become truly enamored with solving the problem in front of you, then cutting out everything else in your life begins to seem easy and obvious. The work can become an addiction.</p>
<p>I found this out quickly, but the hard way. About three weeks into joyfully embodying the hacker stereotype of sleeping under my desk, eating unfathomable amounts of takeout, and working 18-20 hours a day, I became as sick as I have ever been. The entire next week was spent just trying to recover. Despite it trying to convince you otherwise, the human brain is inextricably tied to the human body. Writing a half-sensible email became like summiting Denali and any thought of writing code was out of the question. I was incapacitated.</p>
<p>From that point forward, Jessica’s words took on a whole new meaning to me. I truly understood the cliche that it is “a marathon not a sprint.” The amount of time I lost, an entire week, was far more time than it would have cost me to have eaten well, slept well, and exercised appropriately during the three weeks prior. Furthermore, it took time to reorient myself and load everything back into my brain after a long break like that. It just was not worth it to extend myself the way I did for no reason.</p>
<p>If I could go back in time and advise myself, I would advocate for truly understanding all of the ways one’s body can become stressed and to get really good at recognizing those indicators early. There are going to be times when you know you are going to have to go beyond your limits, but you have to understand what that will cost you. Any time you are hungry, tired, stationary, or isolated for too long, you are risking getting sick. Getting sick is the momentum killer for very early startups. This is why “Eat. Sleep. Exercise. Work.” is such important advice.</p>
tag:blog.chriszacharias.com,2014:Post/imgix-a-new-step-forward2019-11-13T11:41:22-08:002019-11-13T11:41:22-08:00imgix: A New Step Forward<p>Nowadays, you can take out your phone, open a user-friendly app, capture a shockingly high-quality picture, make any corrections you need, and then send that picture to your grandma, who can see it seconds later. Consumer photography is a largely solved problem. However, the same innovations that have benefited consumers - access to high quality cameras, ease of use, rapid distribution of photos - have created a multitude of complexities for businesses who are now forced to deal with both a more discerning user and a more complicated visual landscape. Delivering the highest quality, lowest latency image to your users is getting progressively harder over time as more and more factors play a role in what delivering the “perfect” image means. <strong>Nobody should have to become an imaging scientist to achieve the most with their images. We built imgix to solve this.</strong> </p>
<p>By providing a simple URL API and tools, we have empowered developers and businesses to serve their existing static images dynamically, in response to the various device types, network conditions, art direction requirements, and browser capabilities. To date, <strong>we have transformed and delivered well over 1 trillion images for our customers</strong> and see tens to hundreds of thousands of image requests per second, every second of every day. As a team, we are so incredibly proud of this accomplishment. And yet, we recognize that there is a lot of work still to do before we can confidently claim to be developing all of the world’s images. With that as a goal in front of us, we realized that we need to begin expanding how imgix fundamentally works to meet the evolving needs of our customers and to bring forward the innovative features we have been imagining internally for a long time. That is why today, we are introducing a new tool that will mark the starting off point for a much larger reconception of what imgix is and how imgix works. I wanted to take a moment and explain what we are doing from the developer perspective so that you know what to expect from us.</p>
<p><strong>Since the beginning of imgix, we have statelessly processed images as they are requested.</strong> You connect your existing image buckets to us and we provide you the API to access those images, enabling us to transform them on-demand and deliver them over a CDN. All of this processing is done in real-time and is heavily reliant on intelligent caching at multiple layers of our infrastructure. While this approach has been monumental to our success, it does create a number of limitations. First, every decision we make about an individual image has to be measured and made during the <100ms we have to process that image. Without state, the output of every analysis we need to perform needs to fit within this window, preventing us from performing many advanced operations. Next, we analyze and learn from the images requests that navigate their way through our stack and use those findings to hone our algorithms, but only at a global level. Without state, we cannot easily optimize our algorithms at the per-image level. This means that we cannot separately tailor our rendering output for images used on a dating site versus an e-commerce site, for instance. Finally, we want to enable you, the content owner, to provide more context about your images so that we can deliver them even better for you. You know your images better than we ever will and involving you in the imaging process will only help you achieve more with your images by using our service. Without state though, there would be nowhere to capture these insights you might want to provide us.</p>
<p>So the answer is, <strong>we are adding state to imgix, which will enable an entirely new class of features, functionality, and tools.</strong> Going forward, each source will have a database of image data associated with it. It will store all of the data about your existing images and give you the ability to add, edit or delete that data to your specification. Each image will have its own record in the database and that record will exist in sync with the image object in your bucket. You will get to choose how your images are added to this database, whether it be by having us spider your bucket all or in part, by having us add records based on which images are accessed through our service, or manually via API (coming soon). By default, images that are added to the database are automatically pushed through content detection (is this actually a JPEG or GIF?), image analysis (what colorspace and bit depth is this image?), content warning analysis (is this image acceptable for my site?) and machine-learned-tagging operations (what is actually in this image?). Soon, you will have the ability to configure the amount of analysis you want as well. As a user of your image database, you will be able to edit the image records to your liking. You can add categories, create and store custom fields, and set many other properties we have yet to announce. You can also edit or add to various analyzed properties in a non-destructive way. For instance, if you notice that a tag added by our machine learning is not quite right, you can delete the tag and it will not come back on future refreshes by the machine-learning analyzer. Similarly, if you add a tag, it will never be overwritten by the analyzer either. In fact, your edits to the tags will help us eventually improve the machine learning over time. </p>
<p><strong>Today, we are taking the first step by announcing the invite-only beta of our first tool for managing the data associated with your images – <a href="https://blog.imgix.com/2019/11/13/introducing-image-manager">Image Manager</a></strong>. It is a sophisticated UI we created to help you view, search, and edit your image data. We have been using it internally for a few months now and it has become an invaluable staple in our daily activities. Beyond any of our future plans with it, straight out of the box it is the single best UI for navigating an existing S3 or GCS bucket any of us have ever worked with. Over the next few months, we will be expanding how you can access the data associated with your images programmatically by building a dependable and robust API for it and from there, building out the various integrations and SDKs that will make the lives of developers even easier. Further roadmap details and pricing updates will be discussed as we move forward. </p>
<p>Right now we are focused on getting this first step right for our customers and we need your help to do that. <strong>We are looking to work with early adopters</strong> who can help us improve the technology and provide feedback about how they are using it. If that sounds like you, then please <a href="https://www.imgix.com/solutions/image-management">reach out to signup for the beta</a>.</p>
tag:blog.chriszacharias.com,2014:Post/a-conspiracy-to-kill-ie62019-05-01T09:24:01-07:002019-05-01T09:24:01-07:00A Conspiracy To Kill IE6<p>The bittersweet consequence of YouTube’s incredible growth is that so many stories will be lost underneath all of the layers of new paint. This is why I wanted to tell the story of how, ten years ago, a small team of web developers conspired to kill IE6 from inside YouTube and got away with it.</p>
<p>I do not recall the exact triggering event that led to our web development team laying out plans to kill IE6 over lunch in the YouTube cafeteria. Perhaps it was the time I pushed out a CSS stylesheet that included an attribute selector on a semi-supported HTML element. Any reasonable web developer would expect this to be ignored by browsers not up to the task. This was not the case with older flavors of IE. Under very specific conditions, an attribute selector on an unsupported HTML element in IE would create an internal recursion that would at best, cause the browser to crash and at worst, trigger a blue screen of death. Or perhaps it was the hundredth time one of our software engineers had innocently pushed out an <code class="prettyprint"><img></code> tag with an empty src attribute. Nobody joining the team could be expected to know that in early versions of IE, the browser would load the root path “/” for empty src attributes. The <code class="prettyprint"><img></code> tag would suddenly behave like an <code class="prettyprint"><iframe></code>, loading our homepage and all of its dependent resources in what could become an exponentially expanding recursive loop. Whenever an empty image tag found its way on to the homepage, it was all-hands-on-deck emergency to locate and replace the offending code before we melted our servers into paperweights.</p>
<p>Regardless of whatever the event at that time was, it had been brutal and it had been IE6 related. IE6 had been the bane of our web development team’s existence. At least one to two weeks every major sprint cycle had to be dedicated to fixing new UI that was breaking in IE6. Despite this pain, we were told we had to continue supporting IE6 because our users might be unable to upgrade or might be working at companies that were locked in. IE6 users represented around 18% of our user base at that point. We understood that we could not just drop support for it. However, sitting in that cafeteria, having only slept about a few hours each in the previous days, our compassion for these users had completely eroded away. We began collectively fantasizing about how we could exact our revenge on IE6. One idea rose to the surface that quickly captured everyone’s attention. Instead of outright dropping IE6 support, what if we just threatened to? How would users react? Would they revolt against YouTube? Would they mail death threats to our team like had happened in the past? Or would they suddenly become loud advocates of modern browsers? We openly daydreamed about cubicle workers around the world suddenly inventing creative “business” reasons for needing upgraded browsers. Grandparents would hold their technically savvy grand-kids hostage, demanding they fix their “YouTubes”. What had begun as a team therapy session started to materialize into an actual plan, a plan we quickly realized we were uniquely positioned to execute on. </p>
<p>The plan was very simple. We would put a small banner above the video player that would only show up for IE6 users. It would read “We will be phasing out support for your browser soon. Please upgrade to one of these more modern browsers.” Next to the text would be links to the current versions of the major browsers, including Chrome, Firefox, IE8 and eventually, Opera. The text was intentionally vague and the timeline left completely undefined. We hoped that it was threatening enough to motivate end users to upgrade without forcing us to commit to any actual deprecation plan. Users would have the ability to close out this warning if they wanted to ignore it or deal with it later. The code was designed to be as subtle as possible so that it would not catch the attention of anyone monitoring our checkins. Nobody except the web development team used IE6 with any real regularity, so we knew it was unlikely anyone would notice our banner appear in the staging environment. We even delayed having the text translated for international users so that a translator asking for additional context could not inadvertently surface what we were doing. Next, we just needed a way to slip the code into production without anyone catching on.</p>
<p><img src="https://cz.imgix.net/youtube-ie6-highlight.png?fm=pjpg&w=800&border=1000" alt="YouTube IE6 Deprecation Banner"></p>
<div style="text-align:center;">The IE6 Deprecation Banner on YouTube in 2009</div>
<p>It turned out that a handful of us had entered YouTube at an interesting time… several months after YouTube had been acquired by Google but before Google had begun deeply integrating YouTube into their larger organization. The early YouTube engineers were rightfully territorial and initially hesitant to adapt to Google’s infrastructure and norms. With their penchants for gray-hat hacking, fast cars, and hard whiskey and an uncommon number of piercings, tattoos, and minor arrest records, many had been rejected during previous Google interviews. Ending up at YouTube instead, they found themselves breaking their backs to stay ahead of exponentially growing traffic while having to constantly defend against critics explaining how Google Video would imminently kill them. By the time they were acquired into Google, many of these engineers had come to view their outcast identity as a critical component of their eventual success. </p>
<p>To cement their authority over the YouTube codebase during the integration into Google, the early engineers created a specialized permission set called “OldTuber”. OldTuber granted you the ability to completely bypass the new Google-oriented code enforcement policies, enabling anyone holding it to commit code directly to the YouTube codebase, with only the most glancing of code reviews from anyone. No need for code readability. No need for exhaustive tests. No need for maintaining code coverage. If you broke the site by improperly wielding OldTuber status, it was on your head and you would lose the privilege immediately, if not your job. So you just had to be a good citizen and never break the site. Our boss, an early YouTube engineer himself, had gone out of his way to ingratiate the web development team with the rest of the early YouTube engineers. Through his efforts, a couple of us eventually found ourselves in possession of OldTuber status, despite never having been a part of the original team. It was like we were just walking down the street when someone mistook us for valets and handed us the keys to their Ferrari. For better or for worse, we were not exactly the types to just hand the keys back and walk away. We saw an opportunity in front of us to permanently cripple IE6 that we might never get again. If this went at all wrong, a number of us would surely be fired. Our most renegade web developer, an otherwise soft-spoken Croatian guy, insisted on checking in the code under his name, as a badge of personal honor, and the rest of us leveraged our OldTuber status to approve the code review. The code merged into production and our banner went live a few days later.</p>
<p>The first person to come by our desks was the PR team lead. He was a smart, dapper man who was always bubbling with energy and enthusiasm. Except this time. This time he was uncharacteristically prickly. He had come in on an otherwise normal day to find email from every major tech news publication asking why the second largest website on the planet was threatening to cut off access to nearly a fifth of its user base. Fortunately for us, the publications had already settled on a narrative that this was a major benefit to the Internet. By their call, YouTube was leading the charge towards making the web a faster, safer experience for all of its users. The entire PR team had Macs running Chrome and could not even see what we had done, let alone issue comments to the press on any of it. They were caught completely unaware. We eagerly told them everything about what we had launched and helped them craft the necessary talking points to expand on the narrative already established by the media. Satisfied that he could get back in front of the story, the PR team lead turned and warned us to never do anything like this without telling him first. He did not want to let great public relations opportunities like this slip by ever again.</p>
<p>Next came the lawyers. Two senior lawyers sprinted over to our desks in a state of buttoned-down panic. They immediately demanded that we remove the banner. We explained how we would need the SREs to do an emergency push and that it would take at least a few hours to do. Frustrated, one of the lawyers asked “Why did you have to put Chrome first?” Confused, I explained that we did not give any priority to Chrome. Our boss, in on the conspiracy with us, had thoughtfully recommended that we randomize the order of the browsers listed and then cookie the random seed for each visitor so that the UI would not jump around between pages, which we had done. As luck would have it, these two lawyers still used IE6 to access certain legacy systems and had both ended up with random seeds that placed Chrome in the first position. Their fear was that by showing preferential treatment to Chrome, we might prick the ears of European regulators already on the lookout for any anti-competitive behavior. While the lawyers conceded that nothing we had done would have likely risen to that level of offense, it had happened on their watch and they did not appreciate that. I repeatedly cleared the cookies in my copy of IE6 and showed the browsers reshuffling with each refresh. Content with the demonstration, the lawyers quickly retreated back to their desks without any further concerns.</p>
<p>I expected the next people to be the engineering managers and that they would be the angriest given how clearly we had abused our OldTuber status. Suspiciously, nobody came by that day. The next day, a handful of engineers stopped by to congratulate us on the launch of the banner after reading articles around the Internet, but that was it. I asked my boss if he was getting any blowback and he shrugged, indicating that nobody had pulled him aside yet. It seemed that for the moment we were in the clear. Surprised and unable to make sense of this, I probed one of the managers about what he thought about the banner launching. He responded “Oh, I just figured you guys copied the banner that Google Docs had put up.” I was confused. How could Google Docs have beaten us to the punch on this? I opened up Google Docs in IE6 and sure enough, a banner very much like ours was showing at the top. It implored their users to upgrade to avoid breaking features in terms similarly vague to ours.</p>
<p>I had met a few engineers on the Google Docs team while working on some shared Javascript libraries. I reached out to one and asked how they had arrived at the decision to launch their own banner. He explained to me that they had been wanting to deprecate IE6 support for a long time but their managers would not let them for the same reasons we had always heard. One of their engineers testing in IE6 had noticed the YouTube banner pretty shortly after it went live and immediately took it to their manager as evidence as to why they should do the same. Shortly thereafter, the Google Docs engineers whipped up their own IE6 banner and pushed it into production, presumably under the mistaken assumption that we had done our diligence and had received all of the necessary approvals. The first time many Googlers heard chatter about IE6 banners was from email threads where other teams had begun asking if they could deprecate IE6 like Google Docs had. Luck would have it that this had included many of our managers. Amazingly, we had somehow bypassed detection as the originators of the IE6 banner inside of Google.</p>
<p>Eventually the YouTube engineering management did ask themselves how the decision to deprecate IE6 was ultimately made, given it happened so quickly and seemed conspicuously premature for a media site of our scale and with such a wide user base. Once they realized what had happened, they cornered our boss for details, grappled with the consequences of our actions and begrudgingly arrived at the conclusion that the ends had justified the means. Between YouTube, Google Docs, and several other Google properties posting IE6 banners, Google had given permission to every other site on the web to add their own. IE6 banners suddenly started appearing everywhere. Within one month, our YouTube IE6 user base was cut in half and over 10% of global IE6 traffic had dropped off while all other browsers increased in corresponding amounts. The results were better than our web development team had ever intended. </p>
<p><img src="https://cz.imgix.net/youtube-ie6-stats.png?fm=pjpg&w=800&border=1000" alt="Historical IE6 browser share" title="Historical IE6 Browser Share"></p>
<div style="text-align:center;">The Historical Share of Different IE Browser Versions (https://www.w3counter.com/trends)</div>
<p>We somehow got away with our plan to kill IE6 without facing any meaningful corrective action. Few people even knew we were involved at all and those that did, did not want to bring attention to it or risk encouraging similar behavior. At a beer garden in San Francisco, our boss, winking his hardest, made us swear to never do anything like this again. We agreed, toasted IE6 falling into single digit percentages, <a href="https://techcrunch.com/2010/06/23/bzzzzzz-youtube-gets-a-vuvuzela-button-seriously/">and never snuck anything into production again.</a></p>
tag:blog.chriszacharias.com,2014:Post/imaging-and-the-internet2016-02-08T12:49:40-08:002016-02-08T12:49:40-08:00The Imaging Chain and the Internet<p>Consider what taking a simple photograph meant 25 years ago. You had film cameras, negatives, dark rooms, emulsions, and paper. It would take days to produce a picture you could show to someone. Now consider what taking a photograph means today. With a smartphone that fits in our pocket, we can capture a photo, edit it, view it, and show it to anyone, all in as a little as a few seconds. These fantastic devices are simultaneously capable of capturing high resolution visuals, displaying them, and immediately distributing them to a billion other devices similarly capable of the exact same things. It is now actually perceivable that a photo you take one moment could be seen by over half of the entire human population a moment later. This power in visual expression has never existed before. </p>
<p>We can create and express visual media so incredibly fast that it is causing new behavioral patterns to emerge. Images and videos have come to inform our every purchasing decision, our selection of potential mates, and even our day-to-day communications with each other. They are used to meaningfully represent thought, emotion, intention, status and presence. Visual media has made every interaction on the Internet faster, especially as the Internet has expanded further and further beyond the desktop. Consequently, nearly every mobile application today is some combination of scrolling up, scrolling down, swiping left, swiping right, tapping or snapping image or video content.</p>
<p>These emergent behaviors have created an explosion in the amount of visual information traversing the Internet. Image and video data constitutes the vast, vast majority of all bandwidth used. Device makers, browser vendors, and network engineers have had to rapidly innovate to keep pace with this influx of content and the new markets that this content is creating. Higher resolution cameras, higher resolution displays, new ultra-compressible file formats, and new standards for delivering visual media are being introduced every week. Making all of these technologies fit together is causing rapid iteration in a technology stack known as the “<a href="https://en.wikipedia.org/wiki/Imaging_science#Imaging_chain">imaging chain</a>”. </p>
<p>The imaging chain is the sum total of all processes that factor into capturing a subject matter visually and communicating it back to the human visual cortex. It is a metric ton of intersecting sciences that we as consumers take incredible advantage of without ever even noticing. The relatively recent transition into digital imaging has had the consequence of abstracting most of the imaging science away from us. The average consumer does not need to consider the optics of their camera, the responsiveness of it’s capturing sensors, the nuances of the file format the data is stored in, the consequences of the compression algorithms used, the performance of the uplink, or the resolutions of the audience’s screens when posting a photo to Instagram. </p>
<p>As technology advances, new uses for visual media are discovered and the imaging chain is forced to adapt to keep pace. A good example is the rise of cellphone photos such as “selfies” and “snaps”. Given the quick and disposable nature of cellphone photos, few invest much sophistication into preparing their shots. This often leads to poor construction, tilted horizon lines, and blurry focus. To help stabilize and orient these kinds of images, accelerometers and gyroscopes are added to smartphone cameras. Signals from these sensors are fed through algorithms to help make sense of the captured image data (a concept known as computational photography). This has the compound effect of reducing motion blur, correcting horizon lines and fixing other deficiencies that occur when “shooting from the hip.”</p>
<p>The unanticipated consequence of adding accelerometers and gyroscopes to smartphones is that they emit new signals to the imaging chain that have sparked new possibilities. These new signals enable developers to orient visual media to the device, fixing the aforementioned problems. More interestingly though, these signals also enable the reciprocal capability of orienting the device within the visual media. By strapping one of these devices to your face, you can feed your own viewing perspective into the imaging chain. This is how “virtual reality” has developed in this technology cycle. The subject matter may be a digital projection of a fictional world, but the stack driving it is no different then the one used to quickly orient your selfies. Virtual reality is a new output of the modern imaging chain that only became possible with new signals for position and orientation. </p>
<p>Whenever a new signal is introduced, it amplifies the possibilities of the entire imaging chain. GIFs, Vines, Snapchats, Periscopes, Cinemagrams, Twitch streams, 3D video, virtual reality, and augmented reality are all different exercises of the same fundamental imaging chain, with a variety of new signals playing a role in how they came into existence. There are going to be more signals introduced as our devices increase in capability and our uses for visual media expand. The reality is that the Internet will increasingly operate in service to visual media until the imaging chain and the Internet become indistinguishable. Developing technologies that understand and respond to signals feeding into the imaging chain will be the greatest area of exploration and value creation in Internet technology for the next decade.</p>
tag:blog.chriszacharias.com,2014:Post/multiplane-camera2015-08-26T16:39:22-07:002015-08-26T16:39:22-07:00The Multiplane Camera<p><a href="https://svbtleusercontent.com/7dwsc02e6djmma.jpg"><img src="https://svbtleusercontent.com/7dwsc02e6djmma_small.jpg" alt="RD-MultiplaneCamera_1000.jpg"></a></p>
<p>During a recent trip to the Disney Museum in San Francisco, I became immediately fascinated by the multiplane camera that was on display there. The gigantic machine represents so much of what I find inspiring in graphics and technology. It is fun to get lost in thought, imagining what the modern equivalent of the multiplane camera might be and how to foster the intersection of art and technology from which the multiplane camera emerged.</p>
<p>The multiplane camera was invented in 1933 by famous Disney animator/director Ub Iwerks. It worked by enabling animators to position their layers of acetate animation cels at varying distances and offsets in a vertical column. They could then shoot a camera downward to compose the cels into a single frame. While animators had been using acetate celluloid frames composited over painted mattes for decades prior, the technical effects that the multiplane animation camera introduced were an unprecedented leap forward in the field of animation. </p>
<p>What is most interesting about the development of the multiplane camera is that the tools of the animator did not really change much. Acrylic paints were still brushed onto acetate cels, then layered on top of other cels and background mattes, and then captured by a camera. However, armed with the newfound depth and focus components that the multiplane camera enabled, animators could think about their animations in radical new ways. Exciting new animation techniques emerged, like depth of field, parallax, and zooming, as Disney sought to explore the third dimension within their two dimensional animations. </p>
<p>It is fascinating to think about a technology as simple as the multiplane camera unlocking so much potential. It enabled a generation of animators to play in a three-dimensional world decades before Pixar could come along and make it a reality through digital technology. Even then, Pixar animators needed to draw upon the vast base of knowledge captured by early Disney animators in order to capitalize on the nascent and unexplored field of computer animation. The multiplane camera proved to be a catalyst that laid the groundwork for future achievements its inventors could never have anticipated. It was a window into the future of animation.</p>
<p>How wonderful it must have been, whether one knew it or not at the time, to be working on the multiplane camera, the physical manifestation of an inflection point in animation history.</p>
<p>–</p>
<p>Walt Disney’s Multiplane Camera<br>
<a href="https://www.youtube.com/embed/YdHTlUGN1zw">https://www.youtube.com/embed/YdHTlUGN1zw</a></p>
tag:blog.chriszacharias.com,2014:Post/page-weight-matters2012-12-21T20:17:00-08:002012-12-21T20:17:00-08:00Page Weight Matters<p>Three years ago, while I was a web developer at YouTube, one of the senior engineers began a rant about the page weight of the video watch page being far too large. The page had ballooned to as high as 1.2MB and dozens of requests. This engineer openly vented that “if they can write an entire Quake clone in under 100KB, we have no excuse for this!” Given that I agreed with him and I was excited to find a new project, I decided to champion the cause of getting the YouTube watch page to weigh in under 100KB. On the shuttle home from San Bruno that night, I coded up a prototype. I decided to limit the functionality to just a basic masthead, the video player, five related videos, a sharing button, a flagging tool, and ten comments loaded in via AJAX. I code-named the project “Feather”.</p>
<p>Even with such a limited set of features, the page was weighing in at 250KB. I dug into the code and realized that our optimization tools (i.e. Closure compilation) were unable to exclude code that was never actually used in the page itself (which would be an unfair expectation of any tool under the circumstances). The only way to reduce the code further was to optimize by hand the CSS, Javascript, and image sprites myself. After three painstaking days, I had arrived at a much leaner solution. It still was not under 100KB though. Having just finished writing the HTML5 video player, I decided to plug it in instead of the far heavier Flash player. Bam! 98KB and only 14 requests. I threaded the code with some basic monitoring and launched an opt-in to a fraction of our traffic.</p>
<p>After a week of data collection, the numbers came back… and they were baffling. The average aggregate page latency under Feather had actually INCREASED. I had decreased the total page weight and number of requests to a tenth of what they were previously and somehow the numbers were showing that it was taking LONGER for videos to load on Feather. This could not be possible. Digging through the numbers more and after browser testing repeatedly, nothing made sense. I was just about to give up on the project, with my world view completely shattered, when my colleague discovered the answer: geography.</p>
<p>When we plotted the data geographically and compared it to our total numbers broken out by region, there was a disproportionate increase in traffic from places like Southeast Asia, South America, Africa, and even remote regions of Siberia. Further investigation revealed that, in these places, the average page load time under Feather was over TWO MINUTES! This meant that a regular video page, at over a megabyte, was taking more than TWENTY MINUTES to load! This was the penalty incurred before the video stream even had a chance to show the first frame. Correspondingly, entire populations of people simply could not use YouTube because it took too long to see anything. Under Feather, despite it taking over two minutes to get to the first frame of video, watching a video actually became a real possibility. Over the week, word of Feather had spread in these areas and our numbers were completely skewed as a result. Large numbers of people who were previously unable to use YouTube before were suddenly able to.</p>
<p>Through Feather, I learned a valuable lesson about the state of the Internet throughout the rest of the world. Many of us are fortunate to live in high bandwidth regions, but there are still large portions of the world that do not. By keeping your client side code small and lightweight, you can literally open your product up to new markets. </p>
tag:blog.chriszacharias.com,2014:Post/investors2012-12-13T12:45:00-08:002012-12-13T12:45:00-08:00Investors<p>When I was going through YCombinator in the summer of 2011, I felt like I was the only person in the entire class who knew nothing about taking investment. I remember distinctly when Jessica Livingston announced the $150K we would be getting from SV Angel and Start Fund. When she told us the terms, the room erupted in shouting and applause. I sat there Googling nervously, trying to understand what had just been said and wondering if I really belonged in YC at all.</p>
<p>Being surrounded by such a select group of founders, each in varying stages of building their companies, you pick up the knowledge you need very quickly. This is the most valuable part of the 3-month YCombinator session. One piece of knowledge you learn very early on is that investors tend to have a herd mentality. What I would later realize through observation was that founders tend to as well.</p>
<p>I remember getting the strangest looks from my peers when I suggested that I might decline the Start Fund money. I had spent time socially with the SV Angel team and knew them well, but I had never even heard of Start Fund. Taking money from someone I did not know seemed crazy to me, but I was becoming increasingly self-conscious that something might be wrong with me for thinking this way. After going through the paperwork with my lawyer and spending quality time talking with Felix from Start Fund, I ultimately felt confident in taking Start Fund’s investment.</p>
<p>When Demo Day came around, focus rapidly shifted from product development into fundraising. As a single founder at the time, or “pre-cofounder” as I liked to refer to myself, I knew that I would not be able to raise money on anywhere close to the same terms as my multi-foundered peers. In fact, I did not even bother trying. After my last Demo Day pitch, I skipped mingling with investors, biked to Whisman Park in Mountain View, and proceeded to sleep in a field for two hours. I figured it was time better spent given the madness of the previous three months.</p>
<p>My classmates were returning with stories of deal terms on convertible notes with caps of 8M, 10M, 12M, and beyond. I was happy for them, but I just could not pin down what the real long term benefits of optimizing for term sheets was. Like before, I presumed this was simply evidence of my lack of experience. When I openly questioned whether these high caps were a good thing, I started receiving weird looks again. I meant it only as a question in the pursuit of deeper understanding, not a criticism of any kind.</p>
<p>It was not until I began chatting with my friends Christina and Dwipal, early YouTubers turned angel investors, that I discovered an opportunity that no one else seemed to see. Christina and Dwipal both told me that they had not invested in a single YCombinator company out of my class, despite liking a good number of them. They had been completely priced out! Here were two of the smartest entrepreneurs I know, with deep industry experience, an extensive network that spans the globe, and some of the biggest wins in Internet history under their belts, and they could not get a YC company to do a deal with them on reasonable terms. I realized that there must be other angel investors in the same situation as they were, people who could bring incredible value to a startup.</p>
<p>Once I had found a cofounder and it became time to fundraise, I decided to structure our raise on the hypothesis that the market was overvaluing YCombinator companies and undervaluing quality angel investors. To test this hypothesis, we would raise a small amount, $500K, on a cap at about half the market rate for YCombinator companies at the time. If it proved to be a bad bet, there would still be enough of the company left to do a second seed round on market terms, averaging out the dilution. I set to work finding the most valuable set of angel investors I could and then offered them our terms.</p>
<p>The results were amazing. We had verbal commitments for half of the round within 3 days and the rest of the round was closed out over a 45 minute conversation at a coffeeshop in Lower Manhattan during my layover from a trip to Europe. While I had expected to be spending weeks or months trying to fundraise, the whole process was basically over before I knew it and I was back in my seat coding.</p>
<p>Our investor list ended up being better than we could have ever hoped for. We have experts in infrastructure, engineering, product, user experience, mobile, content policy, business, and entrepreneurship. All of our non-institutional angels were either the creators of or very early employees at well known Internet companies such as Etherpad, Rentjuice, Vimeo, and YouTube. The breadth and depth of experience of our investors is incredible. They are readily accessible and eager to help. We are so unbelievably fortunate.</p>
<p>What we have learned from this experience is that giving good terms to good investors will create overwhelming compounding value for your company. Think about it. With too high of a cap or valuation, what incentive does an investor have to go to work on your behalf in the short term when the real return on their investment requires several orders of magnitude of growth, which has a very low likelihood of happening ever? This presumes you can get them to even take the deal to begin with. The good investors will not even bite.</p>
<p>If you give the right investors the right deal, they will instantly become part of your team. Our investors have secured deals for us that have allowed us to run much of our infrastructure for free or far cheaper than what is available on the open market. They have gotten us in the door places that other companies would only dream of. Because of an investor’s work on our behalf, we stole the business from a competitor right before they were about to sign a major deal. Our investors have introduced us to the best lawyers, accountants, sales people, etc. I can go on and on.</p>
<p>We have been experiencing explosive growth over the last few months. Crediting it to our feats of engineering would simply not tell the real story. Our investors have played a substantial role in helping us grow and develop in a way I would never have expected. Even now, as we move into our next stage of our company, I could not be more excited to work with them in positioning the company for the future.</p>
<p>While this may seem like a love letter to our investors, that is simply not my intention. What I hope to impart is how optimizing for smart money has benefited us and could benefit you. Smart money is more expensive, but the value that it can bring your company is exponential. My enthusiasm comes from unexpectedly being in a position where I can see how tremendously powerful and valuable having everyone’s incentives aligned can be.</p>
tag:blog.chriszacharias.com,2014:Post/cruise-ships2012-02-04T12:00:00-08:002012-02-04T12:00:00-08:00Cruise Ships<p>In July of 2010, I made the decision to leave YouTube. The first thoughts I had were “How am I going to explain this to anyone? How will I tell mom?” To my family, I had the greatest job in the world and the amount of money I was making was unfathomable. They were certainly not wrong in thinking this. Google is absolutely the best place in the world to work and they do pay very well. It certainly was not an easy decision on my part. </p>
<p>About 4 months before, I was backpacking through Europe, stopping off in major cities to present our latest HTML5 work at the local Google offices. It was my first time really exploring a different part of the world. I met fascinating people and experienced many random adventures. I was trapped in Stockholm for 9 days due to the Icelandic ash cloud. I was a successful stowaway on a train from Copenhagen to Hamburg. I had a girlfriend break up with me during a rendezvous in Bruges. Strangely, throughout both the good and the bad, I just kept thinking about how fun it would be tell these stories to my grandkids one day. </p>
<p>The decision to leave Google hit me while on a train through the Swiss Alps headed towards Milan. I had just been mugged the night before in Zurich and lost about $600 USD. It certainly was not a fun experience, but it added yet another crazy story to my list. I sat in the dining car thinking back on everything that had happened. To cheer up, I remember saying to myself “Well, I would never have had these stories if I had played it safe and gone on a cruise.” And that is when a thought occurred to me: Google is a cruise ship.</p>
<p>Large companies are cruise ships. They work very hard to make you comfortable, provide you safety, and satisfy every need you have. There is plenty of free food, great entertainment, massages, yoga, gyms, opportunities to travel, excellent childcare, and plenty of people to connect with, ranging from young to old. You are all moving in the same direction and seeing the same sights along the way. For many people, at different stages of their lives, this is an ideal way to travel. </p>
<p>Google happens to be the best cruise ship in the world, but it is still a cruise ship. What you sacrifice by traveling on a cruise ship is the opportunity to experience the world on your terms. That was the part of backpacking that really appealed to me, even despite some of my misadventures. To me, the negatives were ultimately just part of the risk inherent in defining my own path. Not everyone can tolerate those kinds of risks, for all sorts of reasons. Given my plans for my life, I realized there was only a small window where I could reasonably afford to take big risks. By staying at Google, I became very worried that this window might pass me by. So I left.</p>
<p>I departed with no plan. As I spent months weaving my way through contract work and side projects, I kept looking for paths that spawned random adventures like those that I experienced while backpacking in Europe. A friend suggested I should submit one of my longterm projects to YCombinator. When I did and got accepted, I realized that it was the start of a crazy new adventure with no clear finish line. So I jumped into the unknown and moved to Mountain View where I slept on my friend’s floor for three months. In my mind, the worst thing that could possibly happen was that I would eventually turn up on a beach. The only question was whether it would be with a yacht… or a shopping cart. </p>
<p>Along the way, I discovered that startups are just like backpacking. There is not a lot you can carry with you, you have no real protection, and there are no guarantees your journey will be fruitful. However, by committing to the path you get the opportunity to travel on your own terms. One of the most rewarding parts to me is collecting tons of crazy stories, both good and bad. It is the stories that keep us going when everything goes to hell. </p>
<p>For the right type of person, at the right time in their lives, working on a startup is the best possible way to experience a unique journey that few others have had the chance to or have dared. When I explained to my family and friends that I was starting a company and explained it to them in these terms, it finally made sense to them. I had stepped off a cruise ship and picked up a backpack. </p>
<p>Now, whenever I interview someone who is working at a large company, I begin by asking them “Have you ever been backpacking before?”</p>