Craig : How did you troubleshoot? Today I use Stack Overflow constantly. What would you do when you ran into a bug that you couldn’t figure out?
Shel : Stay up late.
Hahaha. I remember building an online art gallery back in 1996. It was for an internship. I got it because I bluffed and said I knew HTML. After I was hired, I purchased a book on HTML. Turns out, the company's "CTO" did the same thing.
We both learned on the job and stayed up late trying to put that site together. It's almost hard to remember how "primitive" that was now that there's Google and SO.
So true that I often question technical interviewing practices that look solely for ability to memorize complex algorithms exactly, vs ability to seek out an even better solution and apply it effectively.
I recently went through a final-round interview process, and a large piece of the technical part of the interview involved handing me a laptop connected to the internet and the interviewer saying "Build a REST API that can handle these 4 curl requests and respond correctly. Use any technology you want. You have access to Google and anything else you can find. You have about an hour, I'll be back to check on you in 20 minutes. Go!"
I felt like this was SUCH a better test of my abilities as a professional programmer versus remembering specific algorithms or reciting "best practices" for X, Y and Z.
Oh man, I'd probably spend the first half of that time adjusting to somebody else's development environment, and the second half troubleshooting all the runtime errors caused by various ':w's and 'u's scattered throughout the code (unless it were an OS I was familiar with, I'd hesitate to implement this in a language that requires configuring a compiler & build system. Fortunately, most web software seems to already be written in portable languages).
The better solution I've seen to this problem is for them to warn in advance that something like that will happen, suggest bringing your own machine with you, and point you at a skeleton git repository to start working on.
I've made this comment before, but people don't seem to understand how used one can get to a specific setup.
I've spent for example 20 years working with MY Visual Studio setup, with a normal desktop keyboard and mouse. Then I get handed that crappy flaptop that no one wants to use.
You do what you can, but still your effectiveness basically drops by 40%.
This was a great test - I just gave myself this test (I'm usually working in embedded systems so this wasn't something I do all the time) - completed in 30 mins, most of it waiting for installs or reading the web. I think it might be possible to add postgres and OAUTH2 into this as well (assuming one can grok OAUTH2 in 30 mins...).
At a previous job I put this in to practice. I would give interviewees a short list of questions on a piece of paper and after the interview they could use a browser and take as much time as they needed to answer the questions. Some were logic type questions that would be difficult to Google, some were just process questions that very few people would know off the top of their head but should be able to Google. The idea was to see if someone could find answers when they ran in to problems. Got some great hires using that technique (and avoided some hires that might have been disastrous!) HR killed it, though.
HR should have no input into technical hiring processes. I don't understand the thought process by which they feel they should have this authority.
HR interference was a MASSIVE pet peeve of mine at a previous employer. I eventually was able to strong arm them into forwarding me all resumes directly, but it was a battle.
I've been lucky to have had good HR recruiters, though there was a time when some routinely sourced me really awful candidates and resumes. It got so bad that I started sourcing them on my own. I was so successful that - to their credit - the recruiters asked me to train them on how I did this. These techniques later became standard practice across the company. It was awesome of them to be so open-minded and adaptable.
Agreed, it was very frustrating. They required that we follow the exact same set of interview questions for every candidate, verbatim. We were not allowed to ask technical questions or do any kind of proficiency questioning / testing, etc. When pressed, they said that we could ask follow up questions to their set of questions, and that we should be able to determine technical proficiency by inquiring about past experience.
Giving your HR group the benefit of the doubt, in my experience, when the pendulum has swung that far to the "process" side, it's because the company has been burned in some way in the past.
... And retaliates by burning everyone in it every day. That said, ive read more positive HR stories in this thread than I've seen everywhere else combined.
Not being allowed to ask technical questions sounds like a big problem.
Asking everyone exactly the questions at least seems like an attempt to ensure a level playing field for all candidates and eliminate bias that interviewers might not even realize is occurring.
Before starting my development career, I studied quite a bit of HR as part of my business degree. There was a fair amount of emphasis on a uniform, structured interview process largely to help eliminate interviewer bias.
The tech industry, and software companies in particular, are often accused of discriminating on the basis of age and gender. And I think that it does happen more than people want to admit, but I don't think it happens intentionally. People are terrible at recognizing their own biases. It's often not even conscious.
If we, as an industry, want to do something about it, we might consider listening more to what good HR professionals have to say. Yes, there are some HR people who are narrow minded and care more about rigidly adhering to process than about getting the best results. There are plenty of developers who meet that description, too.
I've heard so many developers dismiss all HR people as "HR drones" which is ridiculously unfair. If we actually care about eliminating bias from the hiring process, there's a lot we can learn by talking to good HR professionals. And yes, there are plenty of good ones. Some of them care just as much about a technically (and ethically) sound hiring process just as we care about good development process.
Technical questions are fine, and I'd argue that asking all candidates the same questions is one way to help eliminate bias. In combination with this, we could ask interviewers to rate the candidate based on their answers to the technical questions. If we wanted to go further, we could also ask people who didn't meet the candidate personally to rate the candidate based on their technical answers, without revealing any of the candidate's personal information (age, gender, ethnicity, etc.) and then compare these ratings. The comparison might help us see if our interview process is as fair as we think it is.
None of us want to believe we're biased interviewers, but from what I've seen of many technical interview processes, there are many tech companies who strongly believe their interview process is unbiased, but don't have much (or any) data upon which to base that belief.
But interviewing isn't about asking someone technical questions. It's about whether the candidate can get work done. I'll never understand the massive debate about the effectiveness of work-sample tests -- no questions, just "Here is some work. Can you do it?"
I've seen how effective it is. And how many people rebel against it. No idea why. Ego, sometimes. It's unfortunate.
May be so. These were pretty easy questions, though. Like 'What steps/commands would you use to reset the password on a [Make] [Model] managed switch through the serial port?' Very easy to Google.
Surprisingly, some people couldn't get the answer right even using Google.
> Surprisingly, some people couldn't get the answer right even using Google.
Never underestimate anybody.
I've seen numerous examples wherein folks would copy/paste an obviously inferior answer (or even incorrect) from a Stack Overflow post that contains a much better answer.
Last week I integrated with a service using (shudder) SOAP.
I tried the XML call with curl and couldn't get it to work. I cursed, I frothed. The reply error was some Java dump, not helpful.
It took me embarrassingly long to realize I got the HTTP header fields for SOAP from something wrong I googled -- it worked when I copied the header line from old code I wrote before... :-) :-(
My approach with Stack Overflow is to never copy-paste but always re-type by hand. This forces me to understand each line of code and its behavior (and double-check any errors). I can't recommend this enough.
I taught myself to code in the early 2000s, coming from a graphic design background, through javascript and actionscript[1]. It took me years of sitting in my bedroom after work, reading dense paper manuals with very few resources for clarification. The mailing lists were often intimidating and took days to get an answer, if it all. You can imagine how stressful that was when working on a deadline and hoping that someone responded to your question about some obscure error message before the project was due. I remember being intensely jealous of my coworkers who were learning to code around 2010 and could be spoon fed the information I fought so hard to unearth!
[1] Say what you will about actionscript, it was an extremely helpful platform for beginners. I probably would have given up without the easy installation and IDE support. Javascript had essentially no debugging tools (firebug didn't exist until 2006; browsers were a nightmare of inconsistency, and debugging meant dumping vars via document.write()) and I didn't have the technical skill to get a java development environment up and running at the time.
And every now and then you would come across someone describing the exact problem you ran into ... and the message trail would end with the OP saying "Nevermind, fixed it". Without sharing how!
Craig: Had you and Jeff stayed close?
Shel: Not really. When he replaced me in my original job and I
was moved into the CTO slot, I was nominally in charge of
architecture, but in fact that just meant rubber stamping
projects that were 95% complete by the time I saw them. That
was all after having told me that my job was mine as long as I
wanted it. And I didn’t have resources other than myself to
work on anything I was interested in either. So I would say we
were not really on particularly friendly terms at that point.
I think this was more honorary than anything. It sounds like he didn't necessarily have the skills necessary to be a true executive, but putting him on a team where he's managed by someone else would seem like a slap in the face. This was a decent way to keep him compensated fairly for his past contributions.
I've seen at other companies where people like this are moved into "R&D" so they can keep working on cool projects while the company can do what's needed to grow.
Personally I actually wish more liberal use would be made of this strategy. I've worked at a lot of companies where obstructionist employees are kept in their slots due to management's concern over the personal fallout (both for their relationship with the employee and for the employee's relationships with others).
It's none of my business whether they stay on payroll or not, and I don't mind at all if they do if that's what management desires, I just want them put in a sandbox where they can't do damage anymore. Scoot them over to R&D, give them a title with a nice ring to it, heck, even give them a pay raise, but just keep them out of the way.
I think he means it still wouldn't matter to him because someone like the guy interviewed would have obviously already contributed/was there early/etc.
We are talking startups: Your typical early employee that didn't grow past mid level dev is out of position by year four. Even though their options are vested, chances are that can't afford to exercise them, and will be worth zero if they quit. Therefore, firing those kind of people as a matter of course is probably not what they want. You joined early for the great equity (a bad idea in the first place). Imagine how bad it would be if you risked getting fired if you don't grow into a good architect!
It doesn't seem like more of a burn than leaving them in a position where they are regularly breaking things. Refusing to either move them into a position where they are more effective (read: less damaging) or provide the necessary training is worse than making up a new sidelined position -- it shows paralysis, inaction, and it's compounded by the negative effect such an employee has on his peers and subordinates (if he has any subordinates). Inaction on that matter can be crippling and reflects cowardice at the top.
The moved person cannot be compelled to accept the position if they don't like it. Move them out of the way, or if they insist, fire them (and this has happened to me -- I wasn't upset that they were trying to sideline me as much as I was that they were not straightforward enough for me to understand the nature of our disagreement until after the arrangement had already fallen apart (for the record, I didn't accept the sideline position)). Most likely the employee would accept the new position and start to look for employment external to the company if he/she was displeased with it.
I wouldn't call that the Peter Principle; he wasn't promoted above his skill set (per se) due to things like time in grade, which is what Laurence Peter wrote about. In the Peter Principle book the person causes damage through having responsibility without the ability to execute in that particular role.
As others mentioned it was more a great way to reward someone who now didn't really have a specific spot. This is frankly the most common use of the CTO spot. The best description I heard from a founder-moved-into-CTO was "Chief Talking Officer": they trotted him out to give talks but basically he had no other responsibility.
Great way to reward someone by not using their best skills and making them essentially ineffective?
He said he became essentially a reviewer placed too late in the development process to matter.
Peter principle concerns efficacy, not necessarily active damage.
"PR guy" (direct marketing) is actually a role many founders do well.
John Gage's [1] title at Sun was "Science Officer". But he sure did a lot of cool useful Official Science Stuff. He was also on Richard Nixon's Enemy List, which is the kind of community service experience that I am always impressed to see on a resume.
At Sun, if they didn't actually want an executive to continue working for the company, they'd promote them to Vice President of Looking for a New Job.
in most hierarchies, super-competence is more objectionable
than incompetence.
disrupts and therefore violates the first commandment of
hierarchical life: the hierarchy must be preserved.
In THE EVERYTHING STORE, which I happen to be reading, it's noted that Bezos told Kephan early on that he would have his job as long as he wanted it. This was Bezos's compromise, basically: stick to the letter of his promise while doing what he had to do for the company. As others have noted, it was not an example of the Peter Principle because it moved SK out of the hierarchy.
He failed to gain greater power in the organization and accomplish greater tasks after being promoted out of the role in which he was very competent. This implies that he wasn't very good at being a CTO. If he was, he would have had a bigger role in the projects and a larger team with which to accomplish his desired tasks.
This may have been intentional as a courtesy rather than accidental due to the Peter Principle, but the result is the same. It is the opposite of the Dilbert Principle, where incompetent people are promoted into a position at which they are sufficiently abstracted from real work that they can no longer do too much damage.
> He failed to gain greater power in the organization and accomplish greater tasks after being promoted out of the role in which he was very competent.
He didn't fail, as he was put in a role with no actual power. The Peter Principle is being promoted into a role you are incompetent at. He was shunted away into a ceremonial position with no power. He didn't even have staff.
> This may have been intentional as a courtesy rather than accidental due to the Peter Principle, but the result is the same.
I'm not talking about the ultimate result, I am talking about the definition of the Peter Principle.
Where does an awesome CTO get promoted to? It kind of seems like the end of the road, with the possible exception of CEO, but that position is probably occupied.
I agree that typically a CTO doesn't get promoted anywhere. In a smaller company, the role of an executive is about growing and evolving the business as a whole, and the technical strategy and choices that allow for that. I was CTO of a growing company for the past 4 years, and my concern was always around growing the business and the company.
No, he was likely promoted because he wouldn't cause much trouble as approving authority.
This is sort of being politically nice is rewarded in every institution. People like this are not given any genuine power per se. But since they listen to the powers and more or less do exactly as they say, they are put in positions where they can't be much trouble and are rather useful the higher authorities political goals.
"You walk down the streets, you have to weave around people standing there in random orientations in the middle of the sidewalk looking at their cellphones. Then you see people speaking robotically so that their speech recognizer can understand them. Now they are running around in mobs in parks with their phones in front of them trying to catch imaginary animals. I don’t necessarily see all that as a positive development."
People, or at least children, have been running around in parks trying to catch invisible animals for decades. As adults, it has definitely been a positive development for my wife and I.
I'm not the parent, but the new Pokemon game has been amazing for me. I'm 28 and single though. So obviously the target market. I've done more walking since the game came out than I had done in years. I've seen a lot of nature too. I found an owl in the park near my house. It was so close I could almost reach out and touch it.
In the context of the article, Kaphan is talking about technologies that isolate versus technologies that connect people. For the examples he gives:
1 seems to be neutral to me (people talking robotically to voice recognition systems). This is neither isolating nor connecting. It is just a different means of interfacing with a computer. I'm sure someone somewhere made a similar argument when the typewriter was invented.
1 seems isolating. Looking at your phone instead of being mentally present at your current location can be isolating. But then it depends on what you are doing. If you are participating in a text message communication, that's connecting you to someone else while isolating you from the physical world.
But Pokemon seems like it falls in the "connecting" category. I have something new in common with random strangers that we can discuss. I go out with my friends to play the game. The downside for some people seems to be that I am now physically present connecting with them and they would really rather I didn't. They liked the park empty and quiet.
Of course there are the incidents of people playing while driving or the one guy who walked off a cliff that one time (99% of the articles I've read slamming Pokemon Go mention the same 3 Reddit posts without attribution). But for me personally, I'm more present and walking around when I play Pokemon than I am when I'm posting on HN.
Also, this past year the morning of our anniversary, I had hidden 150 pokemon stickers inside easter eggs around our apartment complex as a surprise for my wife. We spent the day with me watching her find them and checking them off my list of locations. Fun things are fun.
An Amazon employee less than #10 does a seminar about SDE careers at Amazon where he/she brags about how Amazon fired all their early engineers because "they weren't good enough." Yeah the people who got Amazon off the ground weren't good enough. Then he/she talks about how if you want to be promoted you better start sucking up to the people deciding your fate in "smoke filled rooms" because you're wrong if you think it has anything to do with your work. This is supposed to be a seminar on how to get promoted at Amazon. It is truly vile and goes to the core of Amazon's culture. Smart people are only there to be exploited.
So I read this article interested to see how long engineer #1 lasted: 5 years.
It was used only in the form of Emacs Lisp, as a set of tools for customer service folks to make replying to typical email easier for them. They pretty much built all that themselves (and they didn't start out as programmers).
We worked together with Eric Benson and Dan Bornstein on ScriptX [2], which was basically Lisp with objects instead of parenthesis.
I found ScriptX quite useful for web programming [3]: "Link Globally, Interact Locally"!
ScriptX's legacy lives on: After Kaleida shut down, John Wainwright, the architect of ScriptX, created a very similar language called MaxScript [4] for 3D Studio Max, which I later used at Maxis for programming the character animation content pipeline for The Sims [5].
There was more Lisp influence than just the CS macros you mention here. Eric Benson was a major contributor to Lucid Emacs and many early Amazon engineers had Lisp experience. SICP was practically issued to every new software engineer--it was that popular.
The template language for Amazon's website at the time (catsubst) was a Lisp-inspired prefix notation language with a relatively small number of functions. For example, there was an add macro but not a subtract macro, so to do A-B, you had to say ${add A -B}. I might have the exact syntax wrong since it's been 20 years.
EB and I both worked at Lucid, which produced a Common Lisp system, not to my knowledge a version of Emacs (though maybe so after I left in 1989?). Some other early employees knew and liked Lisp, but we didn't use it on any core functionality. The text substitution logic you mention, that I wrote, was really simple and not particularly Lisp-like. Though again, after I handed it off, who knows what happened.
Lucid Emacs -> Xemacs was mentioned in a sibling comment, but I remember people being in awe about EB working on those. There were many interesting employees back then--J. Chenault, J. Gehlen, R. Braumeller, F. Eiden, K. Sears, etc. I've lost touch with most of them but I learned a lot from them.
I started in October 1997 and did Perl work on backend systems, but I had a few friends who worked on the frontend. They used to talk about how Catsubst had a very small set of verbs and that everything was a function, even arithmetic, and that prefix notation was used for all macro calls. They thought it was Lisp-inspired, but they were also pretty junior programmers too. I never worked with Catsubst myself, so my information is second-hand, while yours is zero-hand since you wrote it. :-)
Thanks for all the work you did on Amazon's infra!
Yes, there was a ton of Perl in the early days. This came about because Paul Davis was a Perl aficionado and did a lot of script writing with it early on, and the non-programmers, of which there were n-2, could pick it up much more easily than C (of course). Which is how some of them became programmers. Incidentally, we used C, not C++, though I liked OOP, because I had previously had less than great experience using C++ on large projects. We used a C++ compiler though because it could catch more errors than the C compiler could. This is one area where Steve Yegge was a bit off in that famous post.
After leaving Lucid I was really not paying much attention to what they were doing. It wasn't long before things started going badly there and they were out of business a few years later. But indeed, I had forgotten what little of the Emacs history I might have known. Here it is: https://www.jwz.org/doc/lemacs.html
"This Amended and Restated Incentive Stock Option Letter Agreement (this "Agreement") amends and supersedes paragraph 2(c) of the Employment Agreement between you and the Company dated October 24, 1994, regarding the grant to you of a stock option (the "Option") for the purchase of 709,568 shares (the "Option Shares") of the Common Stock of Amazon.com, Inc., a Delaware corporation (the "Company") at an exercise price of $.001471 per share (reflects stock split effected on November 23, 1996)."
A lot of people would haved bailed during the dot.crash of 2000. Amazon lost was high flyer and lost over 80% of peak value. Who knew it would become atop ten most valuable company.
"This Amended and Restated Incentive Stock Option Letter Agreement (this "Agreement") amends and supersedes paragraph 2(c) of the Employment Agreement between you and the Company dated October 24, 1994, regarding the grant to you of a stock option (the "Option") for the purchase of 709,568 shares (the "Option Shares") of the Common Stock of Amazon.com, Inc., a Delaware corporation (the "Company") at an exercise price of $.001471 per share (reflects stock split effected on November 23, 1996)."
Unquestionably!
Lets say he had a typical 5%, no conservatively lets guess 1%. So 1% of 366 billion! Let you do the math. On the other hand if he had 10% which would not be unreasonable, he would be very rich.
A quote from a 2011 Geekwire article. " Jeff was working on it full-time already, and his wife, Mackenzie, was writing checks every once in a while. But that was it. I didn’t get founder’s stock."
"So, after five years were up — and my stock was all vested — I probably would have left a little earlier if that had not been the issue.
So, did you hang on to all of the shares because Amazon hit a rough patch just after you left?
“I don’t know what the effect on morale inside the company was since I wasn’t there. But I did do a lot of selling during those times, because from the outside, without knowing what was going on inside the company anymore, I didn’t know if it was going to be a casualty of that era or not, so I cashed out quite a bit of my position. But I did hold on to some of it, and I continue to.”"
Probably between 1 and 2%, I would guess. Some of which he cashed out when the stock was at a low. So between what his current shares are worth now and what he cashed out, probably at least $100 million.
EDIT: His foundation has $53 million in assets, so that should give an idea...
Well, he was given the option to put up some money with Jeff at the beginning and declined. I'm guessing that would have doubled his eventual stake...
It was all done on a threadbare budget. At first Bezos backed the company himself
with $10,000 in cash, and over the next sixteen months, he would finance the startup
with an additional $84,000 in interest-free loans, according to public documents.
Kaphan’s contract required him to commit to buying $5,000 of stock upon joining the
company. He passed on the option to buy an additional $20,000 in shares, since he
was already taking a 50 percent pay cut to work at the startup and would, like Bezos,
earn only $64,000 a year. “The whole thing seemed pretty iffy at that stage,” says
Kaphan, who some consider an Amazon cofounder. “There wasn’t really anything
except for a guy with a barking laugh building desks out of doors in his converted
garage, just like he’d seen in my Santa Cruz home office. I was taking a big risk by
moving and accepting a low salary and so even though I had some savings, I didn’t
feel comfortable committing more than I did.”
I find there is a huge difference between the guess of people with knowledge, and people who are pulling things out of their ass. Considering I have held a number of CTO jobs, my guess'es are much better then most peoples.
"I wasn't really planning on reviewing this book, because I was mentioned in it several times and it didn't seem appropriate. But several other people who were also mentioned in the book have already posted reviews, and in fact, MacKenzie Bezos, in her well known 1-star review, suggested that other "characters" might "step out of books" and "speak for themselves".
I was at Amazon for the first 5 years of its existence, so I also have firsthand experience of those times at the company, and I have been a fairly close observer since I left. By and large I found Mr. Stone's treatment of that which I know firsthand to be accurate -- at least as accurate as it is possible to be at this great a remove, and with no contemporaneous documentation of the early chaotic days or access to certain of the principals. Relying on people's memories of nearly twenty-year-old events is of necessity somewhat perilous. Of course there are a few minor errors here and there, but I don't have firsthand knowledge of important mistakes much less anything that appears to be intentionally misleading. But there are a few minor glitches. In my case, I can testify that I did not, in fact, have a bushy beard at age 17 when I worked at the Whole Earth Truck Store & Catalog in Menlo Park. It was a publisher and seller of books and other things, not a lending library. It was in a storefront and was no longer a mobile service operating out of a truck by the time I worked there (p. 32). But I do not think this is a reason to disregard the entire book; it's just some not terribly relevant detail the author got a bit wrong in a way that doesn't change the story materially. MacKenzie listed one error, which didn't seem especially awful or material to me, and then referred only vaguely to "way too many inaccuracies". Without a more explicit list of mistakes it is hard to know what to make of that. Breaking news: a new 372 page book has some errors!
Since Mr. Stone did not have access to Jeff Bezos for this book, but had to rely on previous interviews and the accounts of others, it would be surprising if there weren't a few mistakes regarding his thought processes. As part of my agreement to be interviewed for this book, I was allowed to read a draft of the chapter which covered the time I was there, and I offered a number of corrections, some of which Mr. Stone was able to verify and incorporate. To the extent I am quoted, my quotes are, while not complete, fair and in context. I don't love or agree with everything that Mr. Stone wrote about me -- especially his broader conclusions regarding the circumstances of my departure from the company -- but I do think it was fair and reasonable. I am aware of at least one other interviewee who was also given a chance to check over the chapter in which his story was discussed. I obviously can't know this, but I suspect that if Mr. Stone had been granted access to Jeff Bezos, that he would have extended a similar courtesy. I have a pretty high degree of confidence that Mr. Stone made a significant effort, and did what was in his power, to make the book accurate.
The irony is, of course, that by reviewing the book as MacKenzie Bezos did, she has brought an immense amount more attention to it -- there are dozens of articles referring to her review via Google News this morning -- and its sales rank has shot up considerably. The book is not a fawning hagiography, but it is also hardly a completely negative account either. It describes not only Amazon's ultra-hardball business practices, but the better aspects of their services and products as well. To the extent of my knowledge it is a pretty realistic account, though necessarily incomplete. Of course Mr. Stone has his own point of view, and of course he does what nearly all biographers do, which is to impute thoughts and emotions to the people he writes about. It would be mighty dull reading without that, but I think readers are generally smart enough to understand that when they read biographies, especially unauthorized biographies, the author has to recreate some kind of persona to make the subject appear life-like. That doesn't make it fiction. This was written as a business book for a popular audience anyway, not as an academic treatise, so expecting every "Bezos thought..." to be footnoted, or couched in hypothetical language, is not realistic.
Especially in comparison to the sad collection of awful books that have been written on this subject, this one is much more detailed, more interesting, and a lot more deeply reported. Sure, there is plenty more that could be written about, and maybe someday somebody will. If and when that happens, I can only hope it is also "unauthorized" and not sanitized by a corporate PR department, and that some real investigative journalism is done, like Mr. Stone did here."
>We were even talking about possibly locating it in Santa Cruz. This was in spring of ‘94. Jeff went back home to New York and started thinking about where he wanted to locate. We were looking at office space in Santa Cruz but as he learned more about mail-order business he eventually decided it made more sense to be in a smaller population state or one that didn’t charge sales tax.
How California lost out on hosting Amazon because of taxes
Well, yeah. Those days were still before everything that’s happened with glorifying startups. If you were going to do a startup business, there wasn’t a huge expectation that it was going to be glamorous in any particular kind of way. You were going to work really hard and maybe it was going to work, though probably not.
Indeed.
Some might even go so far as to say:
if (glorifying_startups > BUBBLE_MAX) { kaboom(); }
> He connected us with Jeff because he knew that Jeff was going to leave to start a web-related business that he had analyzed for this hedge fund. For whatever reason, that company didn’t want to pursue it but Jeff did.
This makes it sound as if (i.e., connotes that) the idea for Amazon was DE Shaw's, not Jeff's. Is this true?? I was under the impression that Bezos personally brainstormed a bunch of ideas for businesses that he thought would be useful with the new internet -- with books being low on the list -- and then, over time as more analysis was done (by Jeff), it rose to the top. I'm sure he talked with fellow DE Shaw employees about his thought process along the way. But the idea was his.
I got this from internet folklore + reading the Jeff Bezos bio that came out a few months ago. Am I right or wrong here? I find this historical fact pretty interesting, so want to get it right :)
> For one reason or another, sorting out architectural issues to scale more gracefully was something I could never convince Jeff to allocate resources to do. There were always too many customer-facing features that needed to be developed.
Shel : Stay up late.
Hahaha. I remember building an online art gallery back in 1996. It was for an internship. I got it because I bluffed and said I knew HTML. After I was hired, I purchased a book on HTML. Turns out, the company's "CTO" did the same thing.
We both learned on the job and stayed up late trying to put that site together. It's almost hard to remember how "primitive" that was now that there's Google and SO.