To Mom, Dad, Lyalya, and Molly.
Preface
main
(
)
{
printf
(
"hello, world"
);
}
When you learn a new programming language, the traditional first step is to gothrough a Hello, World tutorial that teaches you everything you need to knowto get a basic program working, such as one that prints the text Hello, Worldto the screen. This book is the Hello, World tutorial for building products,technologies, and teams in a startup environment.
I wish I had a book like this when I was in college. By the time Igraduated, I had a BS, a Masters, a bunch of internshipsand absolutely noidea what I was doing.
I remember one of the first big projects I built by myself was a desktopapplication for performance testing at Thomson Financial. I had no ideahow to create a user interface, so I randomly sprinkled text fields, menus,and buttons across the screen. I had no idea how to reason aboutperformance, so I randomly sprinkled caches and thread pools across the code.And I had no idea how to think about code maintenance, so I didnt bother withtests or documentation, but I did manage to cram several thousand lines of codeinto one gigantic file.
I remember my first project at TripAdvisor was to add new sort options to thewebpage that listed all the hotels in a city. It was a quick task, just enoughto become familiar with the code base, and I was able to get it done and pushedto production in my first week. Shortly after, I was in my managers office forour first one-on-one meeting, and I watched as he clicked on the hotel listingsfor Paris, selected the new sort option, and then waited. And waited. Andwaited. It took nearly two hours for the page to load. Well, it was probablycloser to two minutes, but Im pretty sure there is a law of specialrelativity that causes time to dilate when youre sweating profusely andjust hoping you can melt through the floor and disappear. Later thatnightmuch laterI figured out that my fancy new code was makingtwo database calls every time it compared hotels during the sorting process. Ittakes on the order of n log n
comparisons to sort n
items, so for Paris,which has roughly n = 2,000
hotels, that works out to roughly 40,000 databasecalls for a single page load. I may not have melted that day, but our databaseserver nearly did.
I remember lots of other nasty bugs, ugly code, uglier user interfaces, siteoutages, and late nights. But mostly, I remember having tons of questions, andno easy way to find an answer. What technologies should I learn and use? Whyshould I bother with automated tests? How do I build a product thatdoesnt look terrible? How do I get people to use my product? How do Inegotiate a job offer? Should I negotiate for more salary or more equity? Whatis equity, anyway? Should I work at a large company or join a startup?
I learned the answers to these questions, and many others, the hard way. Itried to capture what I learned, much of it the result of painful trial anderror, in blog posts and talks, but afterrealizing that thousands of other developers were going through thesame trial and error process, making the same mistakes, and still havingnowhere to turn with the same questions, I decided it was time to do somethingmore substantial. This book is the result. Of course, some lessons you can onlylearn by making your own mistakes, but for the rest, I hope Hello, Startupwill save you a lot of pain by letting you learn from the mistakes of others.
One of my biggest mistakes was not paying enough attention to the startupworld early in my career. My first few jobs were all at big, establishedcompanies (Cisco Systems, Thompson Financial, Cornell University), and it wasonly later, and somewhat accidentally, that I made the jump into the startupworld (LinkedIn, TripAdvisor). What I saw there astonished me. I learned more inmy first few months at a startup than I had in all the years of work,internships, and schooling before that.
A startup is not just a smaller version of a larger company[], much like quantum mechanics is notjust a smaller version of classical mechanics. Classical mechanics describesthe behavior of large objects (e.g. a baseball or a planet) moving atrelatively slow speeds with rules that are predictable and deterministic.Similarly, large companies tend to move slowly and live in a world withpredictable rules because the customers and products are all known. Quantummechanics describes the behavior of tiny objects (e.g. photons and electrons)moving at extremely high speeds with rules based on uncertainty, probability,and non-determinism. Similarly, startups tend to move at a hectic pace tosurvive in an unpredictable world where nothing is known. While manypeople are familiar with classical mechanics and large companies, youwont have a complete picture of the world unless you also understandquantum mechanics and startups, and that means youll need new ways ofthinking and new ways of working.
The way you work is, in many ways, the way you live, as you will spendhalf of the waking hours in your life at work.Wouldnt you prefer to spend those hours doing something that makes youhappy? I used to think that all software jobs involved endless cubiclefarms, pointy haired bosses, TPS reports, and enterprise code.Fortunately, there is an alternative, which I hope to show you in this book byintroducing you to the way work gets done at some of the best startups in theworld. The ideas from these companies will be useful even if you never join astartup yourself and will grow even more useful as startups become more and moreubiquitous.
This book is based on my own experiences, plus a considerable amount ofresearch, including a series of interviews with programmersfrom some of the most successful startups of the last decade, such as Google,Facebook, Twitter, GitHub, Stripe, Instagram, Coursera, Foursquare,Pinterest, and Typesafe (the full list of interviewees is in the). Youll find their stories and thoughtsthroughout the book. They offer a raw glimpse into startup life, with nomarketing or PR spinjust programmers sharing their successes, mistakes,and advice.