Thursday, June 02, 2016

How to Get Hired as a Technical Co-Founder

I recently left my tech job with a plan of finding a new challenge. In the brief time I was a free agent, I got a handful of emails from friends, acquaintances, and intros about joining them on a new venture. A couple of those turned into coffees and dinners.

All of them were people looking for their "tech co-founder". Some of them had some promising ideas and I deeply appreciated the offers, but in the end it wasn't what I was looking for.

Finding a technical co-founder is quite hard. Part of the reason that's true is that non-technical co-founders (looking to start a tech startup) will need some technical expertise at some point probably sooner rather than later. They can outsource it, or hire employee number one, but getting someone fully vested in the new company (and the idea) is a great path.

When someone technical has an idea, their first inclination is simply to go build it. I'm super critical of my own startup ideas these days but development tools are so incredibly good now that I still can usually build a quick (and crappy) version faster than I can veto the entire idea as something to pursue (which almost always happens).

Non-technical founders will follow a different path with more research and discussions with relevant people up front. Finding a tech founder is likely part of that process. It would seem that by design, there's typically more business co-founders looking for technical co-founders than visa versa.

Needless to say, if a business co-founder is recruiting you, it's also pretty much implied that they're planning on being the CEO. As one ex-business-co-founder told me, "Either of us could be CEO, but only you can be CTO because I can't code". Despite me being penalized for having a unique skill in the relationship, he had a point.

The part you should understand right off the bat is that all co-founders besides the CEO will be in the backseat for the rest of the company. On a case-by-case basis, that may be understated or it may be end up being supremely obvious but it will be the situation. By definition, you report to your co-founder. Your investors will get to know the CEO far better than you, that's who's calling the shots. During the courting period, your prospective new co-founder will tell you its a partnership (or even "family"). There's no question its a unique type of relationship, but its just as easy for those sentiments to disappear when money or opinions get on the line.

(Check out Reid Hoffman's thoughts on using "family" to describe an employment relationship)

A partnership is the right word - but is that really what they're offering? It will be before you join, but I've seen it go both ways thereafter. The fact that your co-founder is CEO and you're not is already an inherent inequity. That's already an unequal partnership.

When a prospective business co-founder now calls me, my first question is to ask what they are looking for and what they are offering. I mean the exact statements and exact numbers. I'm not saying I'm the right guy for the job, but I am saying they should know all that already and for the right technical co-founder, they should be willing to put it right on the table. The only reason to be coy about it is to hide the unequal parts of the deal.

For the moment, let's assume the situation is that they have an idea, investigated it to some degree, but have not yet raised money or built anything. Once in my life a prospective business co-founder gave me the following pitch:

I'm looking for a technical co-founder to be my partner in this new company. I expect that person to be able to fully deliver on the technical needs of the company including building the initial tech and the team. They also need to prove that to potential investors. Someone who believes in this idea completely and thinks they can make it work. Someone who will go all in on this once adequately informed. Someone I can trust.

I am confident of my ability to raise money and build the company. I believe in the idea and my ability to execute on it. I can sell it.

As I said, I'm looking for a partner not just a coder. I would be the CEO, that person would be CTO/President. My partner and I would split equity 50/50 and have equal salaries - for the life of the company.

Now that's a partnership.

I've always advised new startups to have all co-founders take equal salary and equal equity. If the company lives awhile, its a sure thing that at some point discussions will get heated. There'll be a time your co-founder needs to leave work early and you need to work through the night. Add onto that fact that he or she makes ten thousand dollars more than you per year, and the resentment will just keep growing.

Having perfectly equal equity and salary won't solve every problem, but it also won't become the focus of yet another one.

There are of course factors that can influence the equity split (salaries really should be locked, even when they're both zero) but keep in mind, the moment the equity is not equal - even for damn good reasons - you are no longer equal partners. That's forever. That will come up again. I promise.

If the business co-founder put money in already, the company should pay them back. If they came in with money already raised from investors, that's like the most valid point worth considering an equity inequity at the very early stage. Of course, if the company has been up and running for some time, the arrangement is completely out of scope for this article. A fair deal in that case looks quite different.

If I were to be pitched as a tech co-founder again I would want to hear what I heard above. What they want, what they expect, what they'll deliver, and what they are offering - in concrete numbers. If the business co-founder won't tell you the numbers right off the bat - it's surely not equal. They are selling you to join for less. Just like a used car salesman, after the sales pitch and the box of chocolates, at the very last minute, they'll slide the offer letter across the table with the value on there telling you what they think you're worth.

If you can't trust your co-founder, things won't end well. Part of that initial negotiation is telling you how they value tech and how they will value you. If they're talking you down before the company even starts, it's not likely that will stop when the money, fame, or credit (or blame) is handed out.

Technology is, like it or not, often just a means to an end. So its not all that uncommon for people to treat technologists the same way. It's up to you to defend yourself, and if nothing else, just make sure you get a fair deal.

Friday, April 26, 2013

Why We'll Never Meet Aliens

If you combine all our current knowledge of statistics and astronomy, it's nearly comical to believe we're the only intelligent life in the universe. It's easy to get lost in the numbers thrown around - there are billions of stars and planets in our galaxy and billions of galaxies. Humans are rather bad at fully understanding such large numbers.

Despite where this article might lead, it isn't really about science - its about thinking big. Big enough to consider that if there are any aliens with the ability to come visit us, they would almost assuredly not care to.

Photo Copyright UncoolBob  -
We come in Pea.. actually, we're not coming

Stephen Hawking, the famous physicist, said in an interview that aliens visiting us would be similar to Christopher Columbus first landing on North America (not a good event for native Americans). His idea being that they would come for our resources, not with any particular purpose of friendship.

There are a few problems with that thought however. To introduce the idea, consider most any space movie in existence. Movies are of course, just movies, but they have shaped our thinking about meeting aliens. And small thinking it is indeed.

From what movies tell us, it would seem that scientists from alien races pretty much focused on 3 primary technologies: faster-than-light travel, energy weapons, and artificial gravity. Movies don't highlight artificial gravity much  because given our limited view, we pretty much expect gravity to just work and shooting a movie without it would be an unnecessary pain. So, screw it, all movie alien races invented artificial gravity.

There's a lot of implied technology thereafter (i.e. movie aliens don't often get sick and seem to not worry about eating) but that's not the fun stuff to think about. Lasers, phasers, and pew-pew-energy-blasters however, are fun to think about.

Did you ever wonder though - why these same scientists who made these neato energy weapons never bothered to develop targeting systems? They still rely on crappy biological reflexes to aim them. It's even sillier when alien robot/cyborgs that can outperform humans in every other way somehow still aren't so great at aiming their phaser zapper. They miss just as much as the humans do, and by that I mean - a lot. Of course, Star Wars would have been a short film if every shot stormtroopers made hit Han Solo but it would have made more sense.

Its actually rather ridiculous when you think about it - we (as in current state of human tech) already have automated targeting systems that work well with our doofy bullet-guns. We literally have targeting systems in existence today better than anything you saw in Star Wars.

Truth is, given how far along we already are - by the time humans develop usable energy weapons - we'll have awesome targeting systems to match. We won't miss. It is with fantastically geeky sorrow that I proclaim that there'll never be an energy pistol or rifle I'll get to shoot. Sure, there'll be energy weapons. Sure, they'll shoot. But it won't be me "aiming" them. They'll darn well be perfectly happy aiming themselves. Chances are I'll probably just be running away.

Movies get to ignore whatever they wish. However, reality dictates that science tends to advance in all directions at the same time. Not only because there's some level of constant pressure in all directions, but because advances in one field often accelerate many others (much like the invention of the computer accelerated all other fields of human science).

If Stephen Hawking is right, then he is saying a race of aliens have, at a minimum, perfected faster-than-light travel (or be willing to travel for several thousands of years at sub-light), conquered longterm biological effects of space radiation, and mastered extreme long distance space navigation just to come to earth and steal our water.

Another consideration that I rather enjoy is that if aliens would come here for resources, then that inherently implies an economic model into their decision. By definition, they need and value resources. Consequently, coming here to get them must have been their most economical choice. Getting them somewhere closer to home or manufacturing them must be more "expensive" (in some sense of the word) than the cost of them traveling all the way here, gathering our resources (probably atomizing us in the process), and flying them home.

While not impossible, that seems like an unlikely set of events - both technologically and economically. Again, even we have (expensively) already mastered alchemy. We even have the tech to create matter from energy. Imagine that tech in a hundred years, or two hundred, or whenever it is you think we'll be able to travel several light years for a mining expedition. What would be cheaper and better, forge the plutonium at home or send a galactic warship with thousands or warriors (and miners) to some far off planet?

From where we are now, we're not even close to being able to get to Proxima Centauri (the closest star to us besides the sun) much less a place where we think there's an actual planet. Even the technology required even to get us to Proxima Centauri in less than, say, 1000 years would require tech orders of magnitude from what we have. Propulsion, sustainability, radiation protection, nanotech - you name it.

Comparatively (and no disrespect to NASA) our existing space program involves us putting bombs underneath rocket-ships, blowing them into space with enough air supply for a few weeks, and bringing them back before the astronauts lose too much bone mass and/or the Tang runs out. If getting humans to another star system is a 100 on some "technology ability scale", we're a 2 which is not comparatively far ahead of say, poodles - who are probably at a 1.

The idea that they might come to Earth to colonize hits a similar argument. You could argue that terraforming (or xenoforming for them I suppose) could be a technology more advanced than FTL travel. With that assumption, you could imagine an alien race within the technological sweet spot of knowing how to travel across the universe but not alter planets to suit their biological needs. Coming to colonize Earth (again while likely blasting us into being "no longer chemically active organic matter") could make sense. But this ignores the fact that several other requisite technologies would probably make their need to colonize obsolete.

Before they had FTL travel, they likely spent many decades traveling at less that light speed. Even if not, chances are their ships are quite hospitable to themselves. In fact probably more like sailing biodomes than ships - someplace they could live indefinitely. But a biodome is probably the wrong inference - assuming their bio-scientists were at work while their space-propulsion engineers were perfecting FTL, they would likely have quite minimal external environmental needs. Stuff like air and food has long been technologied away.

The only thing something like Earth could give them is a place to stand on. Xenoforming a planet might be out of their reach, but creating ships to live in is by definition, well within their reach. The home-iness of living on a planet probably is questionable. It won't be as hospitable as their own ships.

So why else might they want to come here? Maybe they want to trade with us. Well, yeah, right. If you've gotten this far it's obvious we have no tech that would interest them. Maybe we'd be able to trade them some local arts and crafts or pottery or something - but other than that, they won't be interested in our childish technology.

Well, maybe they want to study us? Well, maybe. It seems probable that if they were on a mission to study life forms, we would not be the first planet they would have visited. Chances are, they've seen other life forms already. Probably some at least similar to us. Statistically speaking, we might be interesting but not all that interesting.

Oh yeah - and statistically speaking - what about statistics? Remember, my thesis is that all fields of science tend to advance simultaneously. That includes math and statistics. In order to make FTL ships, pew-pew-lasers and artificial gravity you're going to need math (and computers) that are light years ahead of ours.

Let's say they could use their super-advanced Hubble telescope, and see our solar system (at some point in the past). They'd see earth in the goldilocks zone for life. They'd know its land and atmospheric composition. They'd see it's oceans and know the planet's temperature variations. They'd see Jupiter acting as a bodyguard soaking up dangerous asteroids.

Even today, if we saw such a solar system, we'd have a pretty good idea that life could be there. If our math, statistics and knowledge of other life forms was 1000 times more advanced, how accurately could we predict that the life forms there would have 2 nostrils? How close could we come to guessing exactly what those life forms would be like?

And if we couldn't get exact - how close would we care to? Does it really matter? In other words, with enough data and statistics (the foundation of what humans like to call "machine learning" or "artificial intelligence") they already know we're here. Just like we know there was water on Mars or high temperatures on Venus.

Even with that however, we're still thinking too small. It's not just their science and tech that's advanced - you need to expect that they have too.

Twenty years ago if I asked you how many feet were in a mile (and you didn't know) you could go to a library and look it up. Ten years ago, you could go to a computer and google it. Today, you can literally ask your phone.

It's not a stretch at all with the advent of wearable computing that coming soon - I can ask you that question and you'll instantly answer. The interesting part of that is that I won't know if you knew the answer or not - and more importantly, it won't matter. If information is reliably fed directly to you from an external source, there'll be no advantage to remembering anything.

How many years before we have a brain interface to Google? You'd know everything. And its not crazy to think that soon after we'd find ourselves limited by how slow our brains process information. The obvious next step being to augment our brains, our thinking, and in the process - augment who we are. That's what our scientists will be working on then (and of course, are actually already working on).

How would you change if you had instant brain-level access to all information. How would you change if you were twice as smart as you are now. How about ten times as smart? (Don't answer, truth is, you're not smart enough to know).

Now, let's leap ahead and think about what that looks like in 100 years. Or 1000. Or whenever it is you'll think we'd have the technology to travel to another solar system. We'd be a scant remnant of what a human looks like today. Movies like to show aliens with over-sized heads and that may well be the case, but not because of biological evolution. Technological evolution will have long surpassed the snail-pass of biological evolution by then (read most any Ray Kurzweil book to hear this a lot).

The question of why aliens might "want to come here" is probably fundamentally flawed because we are forming that question from our current (tiny) viewpoint. The word "want" might not apply at all to someone 1000 times smarter than us.

If we discovered a fish-like creature on Europa today it would be fascinating for us to study it. If however, we were 1000 times smarter and had spent the last 1000 years finding fish-like creatures across the galaxy, and could with 99.99% accuracy predict the exact existence of such creatures from light-years away, it probably wouldn't be all that interesting to go study another one.

The bottom line is that if an alien race is capable of getting here, all the other technology they've requisitely developed in the meantime would make the trip unnecessary at best - and more than likely, simply meaningless.

We're just not as advanced or as important as we like to think. In the end, there's no compelling reason to think they'd be interested in meeting us - we simply think too small.

Wednesday, May 02, 2012

How to get your resume "Silicon Valley Ready" - Part I

Per my last post, I've been given the opportunity to review a nice pile of resumes. As I am prone to, this got me to obsess a tad over how the resumes were put together and more importantly, what each told me.

What I perceived as issues are, in retrospect, my fault, not the resume owner's. That's because, per the entire point of my last post, the start-up environment is radically different than the corporate IT department. And the latter is where many of these resumes came from (which is exactly what I wanted and asked for).

In many cases, I received a resume from someone that included the regular set of data - experience, education, skills, etc. But the ones that got me excited were the ones where the person included in the email links to the websites or mobile-apps they had built. As I've said - the number one selling point for you as an engineer to get a job in Silicon Valley is that you love this stuff. There's an age-old conundrum of new grads who say "Employers want me to have experience before they'll hire me - but how do I get experience if I can't get a job?"

In our business I'm happy to say - that problem does not exist. Simply because you don't need anyone to give you a job to build something. A website. A mobile app. Heck, a program that finds smaller sets of strings in larger ones.

I realized that's probably the number one thing I'm looking for. You can show me, with no doubts, that as a software engineer - you can build something. Start to finish.

Interestingly, I like to think that I also don't put that much weight into whether a project was a commercial success. If it was, that's nice but and maybe it's because you are not only a great engineer but you have an awesome product sense - who knows (it just might mean you were lucky too). And unless it wasn't a commercial success because it was poorly engineered, that's not really the point. The point is that you built it. Or at least some non-trivial part of it.

With that in mind - this article sprang forth on what I like to see in resumes. I'll point out that this isn't very different from what I looked for when I was on a hiring committee at Google (so there are at least some current Google engineers that are partially there because of these thoughts).

First - I propose a new section to resumes - at least for software engineers. In addition to Experience, Education, Skills, Interest, and References (not suggesting we remove any of those) - I propose we add Cool Stuff I Have Built.

If your resume is going to go over one page (which, personally, I don't mind) - I'm hoping it's because of this section.

Any project you did solo or had a major hand in - whether paid or not paid, million users or just your mom, I'd love to know about. Websites, iphone apps, android apps, desktop apps, open-source projects, github accounts - you name it. Solo or as part of a team (indicate that). But it has to be, in one way or another "finished". Even if your iphone app was rejected by the app store - you can point me to a link to see it. It doesn't have to be a product either - maybe its an open-source project. The bottom line is it is something that you "finished". You executed. Your idea became a living breathing application or piece of code that in some way some how you could show to people.

The section might be broken up into individual projects with bullet points about each. For example:

Project Name: Mailinator
Technologies used: Java, tomcat, (no database)
Team Size:5'11", 175lbs (haha)
Implementation details/challenges:Custom server architecture built as an experimental test-bed for highly-multithreaded server design. Custom SMTP server. No database as emails are stored in RAM with a custom compression scheme.
Notable Metrics: up to 25MM emails per day, ~20k users per day, runs on a single server (on purpose as part of a personal experiment to optimize the system).
relevant links:,

Surely you could add other bullet points too (and suggestions welcome, leave a comment to this post). But you get the idea.

My previous post resonated strongly with some people - that is, they were in "IT departments" feeling like they weren't growing technically. And as you can imagine, a resume telling me you did a payroll system is great - but it's not what (most) start-ups are building. But what if you haven't built anything? And your "Cool Stuff I've Built" section is empty?

Well .. fix that.

No one is stopping you from building something. No one said you're ready for a transition out of your current job today and as with much of life it's up to you to take yourself to the next level. But nearly any person that already writes software with a penchant for learning and some ambition can spend the next few months of nights and weekends learning and building. (And it's absolutely possible that your day job accomplishments belong in that cool stuff section too).

So if by day you're a payroll guy, but by night you're in iphone ninja - you've got my attention. Not only because you have the skills that I'm looking for - but that in your spare time, you're out doing great things. And instead of going out every night drinking with your friends - at least some of those nights, you chose to stay home and learn and build cool stuff. And why would you do something like that? Simple - you love this stuff.

(My start-up is located in Palo Alto and I am right now interviewing for the initial engineering team. We're well-funded, building cool stuff, and plan to change, ya know, the world. No matter where you are - if you're a software engineer, willing to relocate to San Francisco/Silicon Valley (and of course, love to build great things) send me your resume. or check out

Thursday, November 18, 2010

A Google Interviewing Story

A few years ago I was entering the Silicon Valley job market and at that time looking for senior engineering positions. A good rule of thumb about interviewing if you haven't done it in awhile is to at least somewhat accept that you'll probably make a few mistakes on your first few tries. Simply, don't go for your dream job first. There are a million nuances to interviewing that you've forgotten, and a few up-front, not-so-important interviews first will educate (or re-educate) about them.

One of the first places I interviewed was a company called As far as I know - gofish is an utterly different company now than when I interviewed there. I'm almost sure that everyone I met there no longer works there, so the actual company isn't terribly relevant to the story. But the interviewer is. My technical interview there was with a guy named Guy.

Guy wore leather pants. Its a well-known fact that interviewers in leather pants are "extra" scary. And Guy was by no means a let down. He was also a technical crack-shot. And he was a technical crack-shot in leather pants - seriously, I didn't have a chance.

One question he asked me I'll never forget. In truth, its a pretty innocuous question - but it's also pretty standard fare for silicon valley interviewing questions at that time.

Here it is:

Say you have one string of alphabetic characters, and say you have another, guaranteed smaller string of alphabetic characters. Algorithmically speaking, what's the fastest way to find out if all the characters in the smaller string are in the larger string?

For example, if the two strings were:


You'd get true as every character in string2 is in string1. If the two strings were:


you'd get false as Z isn't in the first string.

When he asked the question I literally jumped to my feet. Finally, a question I could answer with some confidence. (Note my answer to him was solely considering the worst cases as there are plenty enough nuances there for an interview question).

The naive way to do this operation would be to iterate over the 2nd string once for each character in the 1st string. That'd be O(n*m) in algorithm parlance where n is the length of string1 and m is the length of string2. Given the strings in our above example, thats 16*8 = 128 operations in the worst case.

A slightly better way would be to sort each string and then do a stepwise iteration of both sorted strings simultaneously. Sorting both strings would be (in the general case) O(m log m) + O(n log n) and the linear scan after that is O(m+n). Again for our strings above, that would be 16*4 + 8*3 = 88 plus a linear scan of both strings at a cost of 16 + 8 = 24. Thats 88 + 24 = 112 total operations. Slightly better. (As the size of the strings grow, this method would start to look better and better)

Finally, I told him the best method would simply be O(n+m). That is, iterate through the first string and put each character in a hashtable (cost of O(n) or 16). Then iterate the 2nd string and query the hashtable for each character you find. If its not found, you don't have a match. That would cost 8 operations - so both operations together is a total of 24 operations. Not bad and way better than the other solutions.

Guy wasn't impressed. He showed it by rustling his leather pants a bit. "Can you do better?" he asked.

What the heck? What did this guy want? I looked at the whiteboard and turned back to him. "No, O(n+m) is the best you have - I mean, you can't do this without looking at each character at least once - and this solution is looking at each character precisely once". The more I thought about it, the more I knew I was right.

He stepped up to the whiteboard, "What if - given that we have a limited range of possible characters - I assigned each character of the alphabet to a prime number starting with 2 and going up from there. So A would be 2, and B would be 3, and C would be 5, etc. And then I went through the first string and 'multiplied' each character's prime number together. You'd end up with some big number right? And then - what if I iterated through the 2nd string and 'divided' by every character in there. If any division gave a remainder - you knew you didn't have a match. If there was no remainders through the whole process, you knew you had a subset. Would that work?"

Every once in awhile - someone thinks so fantastically far out of your box you really need a minute to catch up. And now that he was standing, his leather pants weren't helping with this.

Now mind you - Guy's solution (and of course, needless to say I doubt Guy was the first to ever think of this) was algorithmically speaking no better than mine. Even practically, you'd still probably use mine as it was more general and didn't make you deal with messy big integers. But on the "clever scale", Guy's was way, way, (way) more fun.

I didn't get the job. Or I think they offered me some trial position or something that I refused, but it didn't matter. I was on to bigger and better things.

Next, I interviewed at After a phone interview with the CTO he sent me a "programming assignment". It was a bit over the top - but in retrospect, worth the 3 days it took me to complete. I got an interview and a job offer - but the biggest value was what the programming assignment forced me to go out and learn. I had to build a web-crawler, a spellchecker/fixer, and a few other things. Good stuff. In the end however, I turned down the offer.

Finally, I had an interview at Google. I've written before that the Google interviewing process does tend to live up to the hype. Its long - its rigorous and in all honesty, pretty darn fair. They do as best they can to learn about you and your abilities in an interview setting. By no means is that an exact science, but I'm convinced they give it a good try.

My 4th technical interview at Google was with a woman engineer that honestly seemed a bit bored of interviewing. I had done well in all my previous interviews there and was feeling pretty good about my chances. I was confident that if I did nothing ridiculously silly - I'd get the job.

She asked me a few softball questions about sorting or design, I'm not sure. But towards the end of our 45 minutes she told me "I have one more question. Let's say you have a string of alphabetic characters of some length. And you have another, shorter string of characters. How would you go about finding if all the characters in the smaller string are in the larger string?"

Woah. Deja-Guy.

Now, I could have probably stopped the interview right there. I could have said "Ahee! I just got this question a few weeks ago!" which was true. But when I was asked it a few weeks previous - I did get it right. It truly was a question I knew the answer to. Almost as if Guy had been one of my study partners for this very interview. And heck, people study interview questions on the internet all the time - by me non-chalantly answering the question I wouldn't be "lying" in any way. I did know the answer on my own!

Now you might think, that in the instant after her asking, and before the moment of time that I began speaking that the entire last paragraph sequenced through my thought process rationalizing that I was, indeed, morally in the right to calmly answer the question and take credit for the answer. But sadly, that wasn't the case. Metaphorically, it was more like she asked the question and my brain immediately raised its hand and started shouting "Me! ooh! ooh! ooh me! I know! ask me!" My brain kept trying to wrestle mouth-control away from me (which happens plenty) but only by stalwart resolve was I able to retain composure.

So I answered. Calmly. With almost unearthly grace and poise. And with a purposeful demeanor - with, I think, a confidence that only someone with complete and encyclopedic knowledge of this timeless and subtle problem would hold.

I breezed over the naive solution as if it were unworthy. I mentioned the sorting solution as if it were wearing a red-shirt on an early episode of Star Trek. And finally, nonchalantly, almost as if I had invented all things good and algorithmically efficient, mentioned the O(n+m) linear solution.

Now mind you - despite my apparent poise - the entire time I was fighting my brain who, internally, was screaming at me -- "TELL HER THE PRIME NUMBER SOLUTION YOU DIMWIT !"

I ignored his pitiful pleas.

As I finished the linear solution explanation, her head dutifully sank with complete non-surprise and she started writing in her notes. She had probably asked that question a hundred times before and I'd guess most people got it right. She probably wrote "yep. boring interview. got boring string question right. no surprise. boring guy but probable hire"

I waited a moment. I let the suspense build as long as possible. I am truly convinced that even a moment longer would have resulted in my brain throwing itself fully into an embolism resulting in me blurting out unintelligible mis-facts about prime numbers.

I broke the calm. "You know, there is another, somewhat cleverer solution"

She lethargically looked up with only a glimmer of hope.

"Given that our range of characters is limited. We could assign each character to a prime number starting at 2. After that we could 'multiply' each character of the large string and then 'divide' by each character of the small string. If the division operation left no remainder, we'd know we have a subset."

I'm guessing that at this point, she looked pretty much as I did when Guy had said the same thing to me. General loss of composure, one pupil was dilated, slight spitting while talking.

After a moment, she blurted "But.. wait that wouldn'... yes it would! But how.. what if.. wow. wow. that works! Neat!"

I sniffed triumphantly. I wrote down "She gave me a 'Neat!'" in my interviewing notes. I'm pretty sure I was getting the job before that question, but it was pretty clear that I was in for sure now. What's more, I'm pretty confident that I (or more precisely, Guy) had just made her day.

I spent 3 years working at Google and had a great time. I quit in 2008 to CTO a new startup and have subsequently started another of my own after that. About a year ago I randomly met Guy at a start-up party who had no idea who I was but when I recounted this story he nearly peed his leather pants laughing.

Again, if there is a moral here - it's to never chase your dream job before you chase a few you're willing to fail at. Apart from the interviewing experience you'll gain, you never know who might just get you ready for that big interview. In fact, that rule just might work for a lot of things in life.

And seriously, if you get the chance and you're looking to hire a crackshot engineer - you could do far worse than hiring Guy. That dude knows things.

(a bit of nitpicky technical detail for the fusty: characters may repeat so strings can be very long and thus counts must be kept. The naive solution can remove a character when it finds it from the large string to do that but its remains O(n*m). The hashtable solution can keep a count as the value of the key->value. Guy's solution still works just fine)

Edit: 11/30/10 - Guy from the story has found this post and gave some clarification in the comments. Worth the read.

Thursday, June 17, 2010

The Young Man's Business Model

I've had an idea bouncing around in my head for awhile that randomly came together recently. And given I have a blog, I thought I'd write it down. This idea came from 3 experiences I've had - and here they are:

Mini-story #1:

In my early 20's I pretty much did 2 things. Ride motorcycles and code. Oh, and given my motorcycles were always sort of junky and I beat the snot out of them, I spent plenty of time fixing motorcycles too - I guess that's 3 things then. (If you think I forgot dating or went to bars or some such - nope. We're good. 3 things).

Every now and then we needed an "old man" (like in his 40's or something) to help us fix something when it was beyond our self-taught abilities. Now when I say "old man" here and throughout this article, I don't necessarily mean "old" (and I don't necessarily mean "man") - I mean "experienced". Experienced at whatever I'm interested in at the time - or more specifically, experienced at what I wasn't experienced in at the time.

And as far as fixing motorcycles, what struck me was the way he'd go about it.

A rather common case would be something like there being one final screw holding on some engine part that we needed to replace, but it was buried deep inside the engine - i.e. you could barely see it. My first reaction was to wedge a screwdriver in there as far as I could - and see if, with luck, brute force, and karma, I could turn it enough to get it out.

The old guy on the other hand never went this route. He merely looked at it a moment, then immediately started taking off the neighboring easy-to-remove piece of the engine. Once that was off, he then effortlessly put his screwdriver in to remove the now exposed screw. Now mind you, the old-guy's way was my back-up plan - but I was betting that my brash exuberance would payoff in a slightly quicker result. Sometimes it did - sometimes it didn't - and sometimes I broke screwdrivers.

This trade-off of investment up-front versus brute-force hope became so obvious that my friends and I used it as vernacular. "Do you want to try this the 'young man' way or the 'old man' way?". It was surprising how without any further explanation we would know all the precise steps involved in both for whatever situation.

Ok. That was mini-story #1, here's mini-story #2. This is a business story but its actually surprisingly similar to the previous one whether you know it or not.

In 1997, I was writing a Java optimizer (this made a lot of sense when Java was interpreted) called DashO. Somewhere along the line I was introduced to a guy at Adobe, who (I was told) wanted exactly what I was building.

When I finally spoke to him, it turned out that the Adobe guy didn't really want Java optimization at all. What he wanted, was Java application size reduction. It had literally become a show-stopper for what he was developing. He was clear that money wasn't a problem - if I could solve his issue, he was a customer.

Wanting to please my newfound (big-time) customer I said "Sure! I can add that in!". Then I shrewdly secured the Adobe guy as a beta tester. This changed the direction that my product took and added about 2-3 months of development, but given the payoff, it seemed worth it.

About mid-way through those 2-3 months my partners and I had lunch with a veteran ("old man") business guy that for some reason seemed to like us and liked to keep tabs on our progress. As I excitedly told him the story of Adobe waiting anxiously for our product, his reaction wasn't as I expected. I thought he'd be excited for us, but instead he had a look of disappointment on his face.

Me: What? What's wrong - this is awesome - Adobe is our first customer!
Old-guy: So you spoke to Adobe. Directly to an internal guy that's a customer
Me: yeah!
Old-guy: And he has plenty of money to solve his problem.
Me: yeah, tons!
Old-guy: And how much of that money are you going to get in the best case?
Me: erm. um. We'll sell a copy.
Old-guy: Right. A copy. Maybe a few if you're lucky.

Old-guy went on to discuss how that deal should have gone. Adobe had effectively contracted me to build them a product that didn't exist (this was true). It was possible that no other customers would ever want that functionality (possible). Simply put, they had a specific business need, lots of money to solve it, and had hand-picked me to be the solver.

I should have structured the deal as a contracting agreement. Charging on a per-hour basis to develop their product using what we already had as a base. Then, give them a discount rate on the hourly rate in exchange for full-rights to further develop and sell the product as our own. This would have been a 6-figure deal which would have meant a lot at that time. What's worse is you might be thinking that I missed an opportunity to fleece a customer - but I argue you're wrong. In fact, that arrangement would have actually brought more value to the Adobe.

In the old-guy's arrangement, Adobe would have then had a hand in guiding the project and making sure all the features they wanted were in the soup. Not to mention, if I didn't build this for them, they simply would have had to hire someone else to do it - probably spending lots more.

Once in awhile, you have a fucking-duh moment - and for me, this was one. If you're thinking "well obviously" then clearly you've done this before, at that time - I hadn't.

Story 3 - a recent breakfast.

I recently had breakfast with a guy I met at an entrepreneur event. He was CTO of a pretty popular website. When he first described his site, I liked the business model a lot. His site fed him data that allowed him to refine his real product: pre-built server boxes which he sold to companies that allowed them to use his software internally.

Visions of sugar-plums and multi-million dollar deals immediately started dancing in my head. As he talked, the rolodex in my mind quickly flipped from person to person. I thought of potential customers, potential partners and even maybe people appropriate to join his team. His product was good, and not that he asked me to, but I couldn't help forming a deal network in my head.

I asked about his sales infrastructure. His answer left me wanting but I figured he was probably still fleshing it out (a very hard task). I almost rhetorically asked about the sales cycle. There wasn't one. Now I was getting confused.

As we talked more it became clear that he and his company were following what I'd call the young-man's business model.

He was basically building a (good) product, then laying it out on the web for all to see and hoping to get a million eyeballs. The viewpoint of the business is to get eyeballs, often from things like Digg or Techcrunch, and then figure out how to keep them. And then amazingly often, this really is the step where entrepreneurs have no clue what happens except they are sure the next step is "and then Profit!".

This is an extremely innocent look at business - and in some sense, its the most logical one if you simply have no other avenues.

This model isn't wrong but now to me (who has of course only recently come to rather shocking self-realization that I am... an "old-man" at how I view business) it seems like a business model without considering connections. Deciding to make connections for your business of course isn't conscious. When something happens, the first thing that pops in your head is "Boy, Fred needs to hear about this". And depending on how many Freds you know dictates how often that idea pops in your head. (and of course, the more Freds you know, the more Freds you will know).

My old-man/young-man nomenclature may not be perfect but it might be statistically correct. Its probably safe to say that on average a 30 year old has a generally more business connections than a 20 year old. From there people simply follow business plans as they occur to them.

To me, my friend at breakfast had a sure winner if he had put together a solid sales and marketing infrastructure. His product should have been selling inside 6 figure deals with several month sales cycles. Now clearly, this model doesn't apply to everything. And plenty of new Web 2.5 startups don't fit this mold - but I also think many people underestimate the idea. So far it seems the evolution of all businesses, even something so webby as Facebook eventually becomes about making deals with big partners at least as much as its about eyeballs.

It wasn't so long ago that saying your new startup was monetized by ads wasn't scary. Some companies go right from eyeballs to ads and to sell-out. Thats great work if you can get it. But the number of eyeballs is limited. Its scary to think that, but on the web, we tend to give value away and "make it up on volume". The only problem is you need a hell of a lot of volume to make up for free. And 6 billion people isn't all that many when it comes down to it.

Personally I think web businesses are growing up. The eyeball business model is getting to be like Market street in San Francisco. Everyone is pierced, shaved, screaming, or on fire. They're crying for attention and they have to keep shouting louder than everyone else to get it.

I have plenty of opinions about business models, but to me, the best business model is one that makes your customer money. I didn't say "saves" them money - big difference. Also, its better yet if that customer is a business. You need less businesses as customers to be successful than if you had individuals as customers. A common sweet-spot is BtoBtoC. Supply to businesses that supply to consumers (and of course, make them money).

If you don't have a ton of business experience, try this - think about your next great web app, then imagine the slickest (or sleaziest, your call) old-man salesperson you ever met sitting in front of you. Picture the idea that this guy is really good at persuasion and networking. He can't code, you may not like him, and he wears shoes you wouldn't wear on halloween, but he's good at what he does. Then imagine handing the old-man 5% of the company (I know its hard, try - remember, its just pretend). You need him truly on your side.

If you had access to the old-man and his imaginary immense rolodex of connections. How else could you sell this? What value could you bring to some customers that currently you can't reach?

Your real business model might be hiding like that last screw holding on part of the engine. Despite you stubbornly breaking screwdrivers, you might not get to what you need. It might just be worth asking yourself, "WWTOMD" - What would the old man do?

Wednesday, March 05, 2008

Writing Java Multithreaded Servers - whats old is new (PDF Slides)

I'm giving another talk tomorrow at the SD West conference:

Here are the slides
Thousands of Threads and Blocking I/O: The Old Way to Write Java Servers Is New Again (and Way Better)

I've encountered some very strong misperceptions in the world that:

1) Java asynchronous NIO has higher throughput than Java IO (false)
It doesn't. It loses by 20-30%. Even with single thread against single thread. If multiple threads enter the equation (and multiple cores) which of course blocking I/O is intent on using - its skews even farther.

2) Thread context switching is expensive (false)
New threading libraries across the board make this negligble. I knew Linux NPTL was fast, but I was quite surprised how well Windows XP did (graphs inside notes).

3) Synchronization is expensive (false, usually)
It is possible for synchronization to be fully optimized away. In cases where it couldn't it did have a cost - however given we have multicore systems now its uncommon to write a fully singly-threaded server (synch or asynch), in other words every server design will pay this cost - but, non-blocking-data-structures ameliorate this cost significantly (again graphs inside show this).

4) Thread per connection servers cannot scale (false)
Thats incorrect at least up to an artificial limit set by JDK 1.6. 15k (or 30k depending on the JVM) threads is really no problem (note linux 2.6 with NPTL using C++ is fully happy with a few hundred-thousand threads running, Java sadly imposes an arbitrary limit). If you need more connections than this (and aren't maxing your CPU or bandwidth) - you can still use blocking IO but must depart from thread-per-connection. Or fall back to NIO.

I'll try to spruce up the benchmarks I used and try to post them. I'd like to point out that writing Java benchmarks is very hard. I spent a great deal of time making sure I warmed up the VM and insured there were no positional biases or other overzealous or skewing optimizations.

I was then *extremely* lucky to get help from Cliff Click of Azul systems (if you want to write a benchmark, a VM engineer is the right kind of person to get help from). He spent half a saturday tweaking my benchmark in ways I never thought of. Then ran them for me on his 768core Azul box (graph inside)!! thanks Cliff !

Thursday, March 22, 2007

Howto Pass a Silicon Valley Software Engineering Interview

I do a fair bit of interviewing. This probably averages about 2 to 3 interviews per week - mostly for Java developers. I'm also giving a birds-of-a-feather at the Software Developer's conference tonite in the Santa Clara Hyatt bar on just this topic (7:30pm if you're interested).

Now mind you, being an experienced interviewER does not necessarily give you relevant information on being an experienced interviewEE. However, the latter is hard to gain a lot of experience at. Because of course, if you're good at it, you tend to not do it for very long (i.e., you get hired).

Before Google, I interviewed at several startups in the valley. And combining that experience plus what I know about how I interview at Google and how I interviewed at Preemptive I do have a few guidelines.

1) Don't interview at your dream job first.

If you haven't interviewed in awhile, your first interview is likely not going to be great. It's not because you're not a crackshot developer or a math whiz. It's just because you aren't familiar with the whole process. From getting used to jumping from topic to topic all the way to saying why you want the job. Its always a good idea to interview at your 3rd or 4th choice first.

2) Be positive - no swearing.

You will get asked about your last job. Saying your manager sucked and the dev team was a mess wins you nothing. I've seen candidates attempt to put down some technical faction or previous employers seeking my solidarity with them. Nuh uh. Doesn't happen.

Why are you leaving your current job? Simple - because this new job is a better opportunity. Your last job was a fine career builder but this one's business model or development principles or philosophy or job description or reputation suits you way better. Not to mention your skillset can bring significantly more value in this new position.

Don't tell your new employee what's wrong with their products - mention you hope you can (non-specifically) improve such products. Even if asked what you'd improve, phrase it such that it is indeed an improvement and not a fix for something you think is terrible.

Also - forget technical religion. If you love Agile say so - but don't pretend its the only solution. Millions of people get work done on windows, linux, agile, waterfall, C++, java, .NET everyday. All are solutions - sure, some are better than others and defensible positions are great - but unfounded zealousness is not.

And, I am amazed I need to write this - don't swear. Its a respect issue. You don't know your interviewer. Some people don't mind swearing - some do. There's really no need.

3) Check your attitude at the door.

As I've said in previous articles, if you are the smartest person at where you work - QUIT. Similarly, its a silly idea to join a company where you will be the smartest person the day you start. Therefore, if you ARE smart, you will be looking to join a company where you AREN'T the smartest person. Therefore - you should leave your arrogance about how great you are outside.

I ask most every candidate to rate their Java and C++ skills on a scale of 1-10. Then I write that down for the next interviewer. At Google, you never know who your interviewers are going to be. If you say you're a Java or C++ expert that rates a 10 - you darn well better be - because you never know - your next interviewer could be Josh Bloch, Matt Austern,
Guido van Rossum,
or Ken Thompson. Or worse, someone else you've never heard of that's a super crackshot - and there are plenty of those.

Again, I'm amazed at people that give their interviewer attitude. It's such an obviously stupid act that I have to question the person's intelligence in addition to being annoyed by their arrogance.

4) Be passionate about development.

I have a dirty secret - if Google stopped paying me tomorrow, I'd still come to work (unless they like took my badge too and got Hector the security guard to watch out for me - that dude could smoke me). God forbid that while sleeping I have a dream that solves a coding problem I've had the day before. When this has happened in the past, I found myself sitting awake in bed with my mind racing. I was too excited to sleep and figured I might as well drive into work and start implementing the solution (despite the fact that it happened to be 4am).

The number one thing I look at on resumes (and I don't look at resumes all that much) is extra-cirricular coding activities. I want to hire engineers that I want work with. And those engineers are passionate about cool algorithms, slick code, and new ideas. They do that stuff in their spare time - its not just a job, its what they do because they love it.

5) APIs really don't impress.

People seem so proud they know a lot of APIs. As far as I know, APIs were designed to be easy to learn. I'd really rather hire a smart person that I know can learn most any API than one that brags about the few they already know.

I'm not saying knowing APIs is bad - it's not. It's just not the most interesting thing on your resume.

6) Know algorithms and data structures.

One theme in Silicon Valley is massive amounts of data. And its not always of the classic relational database type of data. Its massively huge datasets that require plenty of processing (imagine the graphs made for page rank).

One of my favorite/fun interview questions (actually, probably one of my ex-favorites given that posting it here means its too well-known) is simply how to sort some objects. The absolute beauty of this question is that very many software engineer interviewees have given me a suboptimal answer for this - whereas my mom (who, despite making crazy good pirogis, has zero computer training) got it right.

Here it is, as I ask it of engineers, and as I asked it of my mom:

Engineer's version: Say you had a million objects in memory (assume we have no memory constraints) all of type UniversityStudent. These objects have two fields:

String name;
int numberOfYearsOld;

What is the fastest way to sort these objects by "numberOfYearsOld"?

... So.. whats the answer? quicksort? mergesort? whats the running time?
The most common answer I get is something like quicksort with an average running time of O(nlogn). For a million objects, that's something like 20million operations (comparisons) to do the sort.

Mom's version: Say you came into a very large room with a million papers in a stack. On each paper is written the name and number-of-years-old of a given student. Whats the fastest way to sort these papers by hand by number-of-years-old?

Mom made stacks. A stack of 18yr olds. A stack of 19yr olds, etc. She needed a possible of about 100 stacks maybe (ages 10-110). How many times do you need to look at each paper? Once. Right. That's 1 million operations or O(n). Go mom.

Of course, Mom got it right because she had no preconceived notions about the problem or sorting in general. A candidate that memorized sorting algorithms before coming to the interview probably robotically responded with O(nlogn) without really thinking about the problem.

If you've written plenty of code, you should be familiar with when to use what data structures and to know their runtime characteristics. You should know that a hashtable's worst case search time is linear - and you should have an idea how to avoid it. And why you might use a binary tree instead of a hashtable even though it's an O(logn) lookup. And that O(1) is effectively the same as O(100). Surely the subtleties are situation dependent - but that's why you understand it - to apply it in the right situation.

This is all datastruct and algorithms 101. I perpetually hear developers tell me that they learned that stuff in school but now forgot it. Personally, I wonder what the hell they have been coding? If you've just been gluing APIs together then thats nice, but its not very interesting. Even if you don't interact with them directly, knowing data structures and algorithms is key to understanding performance. This is not premature optimization - this is choosing the right tool for the job. And that choice is often wonderfully subtle.

And if you decide to do 20million operations when you could very easily instead do 1million, eventually we're going to have some problems.

7) Be an engineer that your interviewer would want to work with.

I don't know exactly what that means because it will vary with every interview and interviewer. Obviously be genuine but be passionate.

8) Know the language you say you do.

I try to phrase all language questions as things that I think any developer that has worked in a language for a year couldn't possibly not know. Tell me about wait, notify, and notifyAll (3 methods every Java class ever created has).

I'm not worried if you don't know Java generics, but if you say you do, I'll ask for some code.

Good interviewing coding questions in my opinion should be meaty, do something, and take no more than a whiteboard.


There really is a spectrum of good to poor engineers. And the one theme that runs through it all is passion. Not for a given language or system - but for problem solving. And building things. Certainly a good degree doesn't hurt but I promise you its not the whole story. I have flunked MIT Ph.Ds. and recommended-for-hire people with very modest formal educations.

As I've said before - the interview is very very honest. Its about you, the whiteboard, and what you can do.

Bottom line is I want smart, passionate, crackshot developers. They're out there and I want them here - partially because they'll help to make my company better. But also because they're very likely going to be smarter than me - and working with them is going to make me better.

Notes from my BOF can be found HERE


Tuesday, November 07, 2006

Evaluating Start-up Ideas - (part TWO)

My entry last week on evaluating start-up ideas netted me some nice feedback. Rereading it, I realize there were a small pile of things that also should be on that list. So, welcome to part 2.

1) Let ideas gestate.

Every new idea seems to be the greatest idea I ever had. Usually it goes something like:

Time 0: get new idea
1 minutes later: (some details)
2 minutes later: start thinking about suit I'll wear when I get to ring closing bell when we IPO

After getting way too excited about way too many ideas, I set myself a rule. Think through an idea for 3 days before I tell a soul. My excitement is usually killing me the first day or so, but by the third day its rather died down. Or, if it isn't, I get a better sense of whether I'm really onto something. Simply put, ideas always look better the fresher they are. You're looking for ones that look good even when not fresh.

2) Consider the size of your market.

If you read Guy Kawasaki's blog you'll see him mention quite often how new companies pitch to him about the immense size of their new market. Guy often chides them for their optimism but even he knows you better believe you do have a big market (and maybe even puff the number in conversations) or you can forget it. Numbers in the hundreds of millions or billions are good - you're really only realistically hoping to glean a smidgen of that.

Consumer markets can be drastically immense. If you're one guy in your basement with an idea that will capture you a 40billion dollar market, that's dandy. Hopefully you have no misconceptions that you'll just own the market yourself (where there's money, there's competitors, and they'll steal plenty, if not most of it before you can penetrate it all) but, the bigger the market, the easier it is to find customers.

Niche markets like hardware stores, developers, and/or mailmen don't suck - so long as you can effectively penetrate most of it - and fast. Simple rule, bigger is better. If big enough (and your idea does actually penetrate it), you'll capture the attention of someone big who will want it for themselves. That either means buying you or chasing you - where the actual outcome happens in the execution (not the idea).

3) "Building a business around a new developer tool" is wrong on so many levels.

Some markets are not only niche - they live in the land of the free. And I don't mean the USA - I mean a market where people are used to getting everything for free.

The software developer inside me keeps coming up with ideas for software development tools. Occupational hazard I suppose. I understand the domain space and understand how to solve the problem. However, development tools are, in general, a really bad place to find good business ideas. Consider that things like Netbeans and Eclipse that took thousands of person-hours to create are given away FREE. Therein lies the rub, developers have created their own culture of giving away tools for free. There is certainly nothing wrong with that, unless of course you think you're going to make a business out of it.

Even then there are niches inside dev tools that are worse than others. Two dollars and an idea for the greatest Java software dev tool ever will buy you a cup of coffee. Java developers are especially used to getting tools for free. In contrast, Microsoft has created a nice culture of getting .NET and windows developers used to paying for stuff. In other words, if you "must" create a developer tool that you intend to sell, stick with Microsoft or some other market segment where paying is an accepted idea.

4) Ideas really aren't worth all you think they are.

Yes I know you're smart. Yes, you amazingly, super-duper wonderfully creative. But in reality, very few ideas are truly novel.

What happens is that two independent technology evolutions (say, the internet and mobile phones) eventually progress to a point where it takes a simple idea to act as a bridge and converge the two. And a product is born. The farther ahead you see that convergence, the more "brilliant" your idea is.

But with every passing day, the distance between the two technologies lessens and your brilliant idea becomes ever so slightly more obvious. In other words, if someone else hasn't thought of it, they will soon. And as more people realize it, the odds of it hitting someone who's looking to start a company increase.

Basically, the winner will be the company that gets things to market fast, creates a marketing and sales infrastructure, and actually makes sales. Don't rely solely on an idea to make it all the way. It has to be supported. If it isnt - at a minimum - it will be stolen (at least in a market sense). You can definitely create a world-class company on a good idea and a great infrastructure. Visa-versa is nowhere near as easy.

And, as an aside, once the technology progressions converge by themselves (apart from your idea) - your idea will probably be made irrelevant (hopefully you cashed out long before then).

5) Competition is good.

If you don't have competition, you don't have an idea. Competition tells you and investors that your idea isn't wacky. If you work 3 years on a product with no challengers, maybe they know something about the day you're going to release and try to make sales that you don't.

Don't be afraid to chase an existing idea if you have what you consider a sub-idea that makes a key difference. Both Altavista and Google did search. Altavista was doing it long before Google started and probably laughed when they heard some challenger Google was going to take them on. I hate to say it but the concept of "stealing ideas" in business is very hard to define. Patents tried to enforce this notion but its so broken (although you still need them of course) that it hardly matters.

Every idea you have is already an extension of some existing idea (Every web 2.0 idea "assumes" the internet "exists". Every "mashup" not only assumes, but steals functionality from 2 or more existing web services). How close your new idea is to old ideas defines how many people will say you stole it. And there will *always* be people saying that.

As a concrete example, I created Mailinator in July 2003. It was first disposable email service that allowed incoming emails to create an inbox as they arrived. There are now a half-dozen copycat sites (some even stole my FAQ questions and license!). Does this matter? Could I do anything about it if it did? Should I try to squash them?

A better tactic is to simply out-market them and introduce new features. Protecting an idea nearly impossible, working to continually better serve your customers isn't. (And, by the way, the idea for Mailinator wasn't mine. It was Jack's).


So there's 5 more. I have a feeling I have another handful brewing, stay tuned.


Thursday, November 02, 2006

Have a great startup idea? Hmm. Maybe not.

Over the years I've started a small handful of Internet/software projects/companies. Examples include Mailinator, Preemptive Solutions, Inc., and Classhat. Actually, I've started a large handful but no one knows about most of them because they were (in no particular order): dumb ideas, unsuccessful, too hard for me to complete. Given that I now rate any new idea I get according to a set of rules that helps me filter out good ideas from bad. At least, whatever I consider bad. Keep in mind these rules are for the canonical one or 2-person pre-startup - if you have 8million in VC, there's a lot of other magic you can do.

Here they are:

1) If there is no business model, its a hobby, not an idea. I love compiler optimizations. I wrote a Java optimizer soon after Java came out. I spent months trying to figure out how to turn it into a business. But guess what, people don't pay for optimizers, or compilers, or even runtimes. At least not without a strong sales team telling they need that. By and large most ideas I get are about things that I'd love to work on but have no real business model (ala my Classhat project took several years and is, absolutely, a hobby). There's nothing wrong with hobbies, as long as you know what they are.

2) The best ideas make your customers money. If your idea can say "If a customer uses our product, they will make X% more money" (where X is a positive number, even if quite small) - you have won the game. Importantly - I did not say the customer will save X% more money. I said they'll make it. That's a big difference. Saving money is great, but you are then faced with the mission of convincing your customer that if they spend $100k on your product now, it will pay itself back in 8 months. It's way way way easier to say "Use our product and you make 2% more money (of which we get a cut). Don't use it, and don't." Who wouldn't buy that?

3) The best place to be that I know of is B2B2C. That is, you want to be a business that serves businesses that serve consumers. If you're B2C, then welcome to some important challenges. One is to get people to pay for your stuff, which in this Internet world, we're not all that happy about doing. Secondly, welcome to support hell. Its very hard to provide consumer support (and you see many complaints across the net). It takes a lot of support people and a lot of money to do it right, which is why it rarely is. If your idea plans to charge consumers, I'd definitely think twice unless you can ramp up a support system fast. Thirdly, you'll need a powerful infrastructure (apart from support) just to handle large numbers of small transactions. Its harder to sell 1000 $10 widgets than 10 $1000 ones.

On the other hand, if you're simply B2B, life isn't so bad. Big ticket sales but encompassing the market is harder. Sales cycles are long. Again, you might need a faster ramp-up of a sales and marketing infrastructure (which you are going to need eventually anyway), but you're probably ok if the idea is generally good.

4) If you're going B2C, look for revenue models that don't come right from the consumer. Given the last point you're probably thinking I'm crazy given things like youtube or myspace or facebook or google. I'm not (at least I don't think I am). All those places dodged the problems of providing support and tracking sales by giving away their services for free and making money on the backside (whatever that is). Often that's advertising revenue. Often its partnership deals. Simply put there absolutely is an Eyeball Business Model. If you can get the eyeballs, you can sell them. Just try to do that instead of charging them directly. They'll be ornery about it and demand support.

5) Revisit every bad idea every once in awhile. Why is AJAX hot? Because its enabling things technically that weren't enabled before. Are any of these mashups really novel ideas? Not usually. Old ideas become new again by new technology, faster computers, etc.

When the computer game Doom came out it included very little novel technology. All the 3D math and graphics tech had existed for years. The guys at ID were just the first ones to realize that personal computers (as opposed to graphics workstations) at the time had finally gotten powerful enough to do it all in realtime.

Every time bandwidth gets faster for cheaper, previously bad old ideas become new and shiny (e.g., video over the Internet). Mobile phones seem really ripe. Apps and usability currently sort of sucks. Thats really hampering a ton of uses. With every new advancement however, its going to open up new doors.

6) Do your best to create a system of recurring revenue. Advertising on websites and such is easy. But things like packaged software is hard. Why does Microsoft change the doc format every time it releases a new Microsoft Word. Surely it probably includes new features, but why can't old versions just ignore those and load the file (which is really text right?) anyway? Because they don't want it to. They want you to buy a new version of Word to get all the new features (even if you just write letters to your Aunt Edna and would never use them). They want recurring revenue.

Doing that with packaged software is harder and often somewhat transparently greedy. Heard of "software as a service"? That is of course, really, "software that we can just keep charging for". Bottom line is if tires, light bulbs, or razors never wore out, the economics of those businesses would be radically different. Getting more money from your customers (hopefully while providing value to justify it) is a good way to go.

If have an idea that follows #2 above (making your customer money), do your best to simply take a small cut. Small cuts add up and the customer has no risk in trying your product.

Edit: There is now a part TWO to this article.


Saturday, January 07, 2006

Damn you Lizard Brain!

Lately I've been having a nasty fight with my lizard brain. Come to think of it, I've been fighting with that idiot as long as I can remember. I hate that guy. This might sound funny to you if you're not familiar with the concept, but I promise, you too know your lizard brain all too well. I can prove it too, and I bet you hate yours like i hate mine.

Plenty of modern research suggests that our brain is made up of layers that perform many different functions (surely, I'm being simplistic on a complex topic, see Jeff Hawkin's "On Intelligence" for a far more informative discussion on specifics). In short, our brains share many characteristics as brains of lesser creatures. Different sections of our brains have different functions and some of our more primal instincts are controlled but what some call the "Lizard Brain" (implying we share this brain structure with lizards). Now mind you, the way I use the term, I am considering it to have a definition only I have provided. Again, if you're really interested in a better treatise, they are out there. I'm far more concerned with how this primal part of my brain makes me act rather than its exact anatomy.

Ok, so there's the oversimplified technical overview which probably doesn't clear much up. Allow me to give you a in-your-face introduction to what I'm talking about.

At one point in my adult life I went on a stunningly successful diet. At least it was stunningly successful in the "crash" sense - I lost more weight than ever before but it didn't last long. That's probably typical but my current point. I am 5'11" and after age 20 I have weighed between 156 and 206 pounds. The result of this diet was the 156. What was the secret to this super diet? I'll tell you (move your ear closer to the screen).. here it is... (don't tell no one, it's a secret) - it's simply: "don't eat".

Ah, you say, you've heard that before. But when I say "don't eat", I'm not kidding. And everyone knows that *saying* "don't eat" is about 1000 times easier than *doing* "don't eat". Let's be real, its pretty damn easy to make diet resolutions walking out of a restaurant. It's a heck of a lot harder to do it. In fact, that's the real secret - the way I made it happen.

It was really just a wild extension of a simple rule - if you have a bundt cake sitting on your kitchen table, eventually you're going to eat it. Thusly, I made sure that I had no bundt.

I learned this very important rule without knowing I learned it. Once lizard brain is hungry and sees a bundt cake, he is relentless - and he is really, really good at being relentless.

Lizard: ...zzzzZZZZZ...
You: "Huh, I still have that bundt cake Aunt Jane forced on me"
Lizard: "*cough* wha?"
You: "Um. nothing."
<*noises of Lizard brain processing the idea of bundt cake*>
Lizard: "Eat Bundt"
You: "No"
Lizard: "Eat Bundt"
Lizard: "Eat Bundt"
You: "No, I'm strong"
Lizard: "Eat Bundt"
Lizard: "Eat Bundt"
You: "Hmm, whats on tv?"
Lizard: "Eat Bundt"
Lizard: "Eat Bundt"
Lizard: "Scratch itch"
Lizard: "Eat Bundt"
Lizard: "Eat Bundt"
You: "Ooh. Reality TV about losing weight"
Lizard: "Eat Bundt"
Lizard: "Eat Bundt"
<*channel change*>
Lizard: "Eat Bundt"
Lizard: "Eat Bundt"
You: "Woah. Gwenneth Paltrow bikini special!"
Lizard: "Eat Gwenneth Paltrow"
Lizard: "Eat Gwenneth Paltrow"
You: "as if"
Lizard: "ok, Eat Bundt"
Lizard: "Eat Bundt"
Lizard: "Eat Bundt"
You: "Hmm. Maybe just a little bite"
Lizard: "Eat More Bundt"
Lizard: "Eat More Bundt"
You: "Damn, might as well have a whole piece now"
Lizard: "Eat Bundt"

Lizard is as dumb as they come, but he is persistent beyond all imagination.

Just like in the movies he'll be that little devil on your shoulder telling you the wrong thing to do. You'd damn well think that if you had a teeny-tiny angel on one shoulder and a stinky little devil on the other, you'd have NO problem figuring out who to listen to. Yet as my admission of 206lbs sits above, I was a bit fuzzy on the concept.

Truth is - its not a little devil. Its lizard brain (bastage).

Your perfectly rational mind can take days or weeks of consideration about how you'll plan your diet so long as the lizard stays asleep. Keep in mind, he is a benevolent master. Lizard brain is directly tied into your pleasure centers and he's damn well not afraid to use them. You give him strawberry cheesecake, he gives you seratonin (i.e., brain candy). Its a fair deal.

What I learned is that much like a real lizard, my lizard brain had absolutely no foreplanning. No concept of the future at all. He was ALL about the here and now. If my tummy was full he disappeared. Hell, maybe he went off to some lizard strip club smoking lizard cigars or something. Heck if I know. And heck if I care.

But - I used this time to scheme against him. In fact, he had so little perception that LATER he might want to lather my ass in bundt cake and Gwenny Paltrow bikini pictures that I could make it well-known inside my mind that I was plotting his demise - and in a blank stare of overconfidence, he just sat there in the back of my mind indifferently flipping through some lizard magaizine.

Aha! I have you my scaly friend!

I removed from my house all interesting food. Actually - more precisely, I simply stopped stocking my house with interesting food. Lizard helped me clear the house over a few days.

Then, I stopped carrying my ATM card (lizzie is dumb - but even he quickly realized that money can equal food). Eventually going to lunch at work daily, I ran out of money. Now I could have always driven home, got my ATM card, grabbed some cash, drove to McWendyKings's and got a Tripple-cow burger with all the fixins, but that was WAY too much work. Despite how bad lizard wanted that burger, he simply couldn't navigate motivating me through all those steps. At one point he had me sifting the seat cushions of my car (I swear, it was him - not me) for quarters and dimes to add up to 75 cents to buy a Rally burger. Let me tell you, Lizard is a powerful god. Its pretty scary to consider your personal resolve as you weave through a drive-thru to order a 2-ounce lipmeat-burger and pay in dimes.

But eventually, the dimes ran out. Now remember, we don't call him lizard brain for nothing. Lizards run through life following a pretty simple program:

1) If See bug, Eat bug - goto 1
2) move a random distance or wait a bit
3) goto 1

Thats it. Once there are no more bugs (i.e., or in our context we'd say dimes, bundt cakes or rally burgers) he does not lament the point. He simply waits for the next opportunity and really pulls the pressure off you. No need to have you scurrying about wasting energy trying to catch flies when there are none.

The simple fact is that you have the ability to plan ahead. Lizard does not. In fact, things like artificial sweeteners or contraception are commercial ventures at lizard brain deception. Both of these things are in some respects made for lizzie. They make him think he is getting what he wants without really giving it to him. Plain and simple, he's an idiot. He's happy as a pig in mud thinking that sucralose is sugar. You can even tell him to his face its not sugar - but lets be real, he's a friggin lizard - he doesn't know better.

I'm not saying this battle is won. I'm not even saying this battle can be won. Everyone has weak moments (probably even lizard). When you're weak and he is strong, you're probably gonna bundt.

In addition, I must admit - his existence is probably part of why life is fun. I love a good challenge and lizard is always there to provide me with one. Damn you Lizard brain! I shall defy thee! Well, right after I eat these cheetoes I will.

Tuesday, December 06, 2005

The Squirt-Gun Offense

Kids! don't read this ... its dangerous advice

While attending a not-so-recent computer conference I stayed at a rather interesting hotel in San Francisco's tenderloin district. The hotel provided an adequate coffee and donut breakfast each morning. I came into the eating room one morning, grabbed a jelly-filled, a cup of coffee and had a seat. Across from me was a well-dressed man munching happily. Before we could start a conversation, the hotel manager walked up to him and stated "Sir.. these donuts are for guests only."

The man stood up with a smile and walked out leaving a half-eaten cruller on the table (possibly this being the biggest crime). The whole event struck me and I warily looked at the hotel manager to see if he was about to yell at me next (although I truly was a guest). The donut thief's nerve was pretty impressive. He wore a business suit and maybe stopped in at random hotels on his way to work every morning and munched free crullers. If he was ever caught he simply got up and left. Now say what you will but this guy truly was a thief. He was stealing. Granted, it wasn't a lot of monetary value he made off with but he was a thief nonetheless. The question as to why the hotel manager didn't call the police is unneeded. The offense simply wasn't that big of a deal. The police would have been overkill and probably cost the hotel more angst than simply booting the guy out.

The bottom line is .. this guy got away scot-free. He got half a cruller, a few slurps of coffee and was politely asked to leave. Welcome to planet earth - where small crimes are unpunishable. Or, more precisely, where retaliation for small crimes can be more expensive than the crime itself.

I decided to test my theory more. I happen to be a speaker at this conference but that afforded me little except access to the speaker ready room (which coincidentally included yet more donuts and coffee). Speakers did not get the privilege of entering the exhibit hall prior to its opening time. Getting in a few minutes early would not be bad since there are no crowds and the exhibitors are all too happy to talk (and give free schwag) to speakers.

The guards at the entryway must have been retired military too - their only insecurity seemed to lie in the fact that they weren't allowed their M16s at this gig. The donut-thief inspired me. What if I tried a forced entry? Would I go to jail? Would I get kicked out of the conference? Would ANYTHING happen besides someone stopping me and telling me I "wasn't supposed to be there"? No, nope, nuh uh, and not a chance.

I went for it. I looked confident and strolled in between the two para-military at the door. They glanced at my badge with strained necks so I picked up my pace. I got past them before they jumped me.

Guard-1 put his hand on my shoulder "Sir! you can't go in.. sorry.. no non-exhibitors in before 10"
(Guard 2 immediately assumed the "drunken dragon" stance from what appeared to be a style of wing-chin kung fu)
I confidently replied "um.. I.."
Guard-1 interrupted me "Oh wait, speakers have a meeting in here today don't they?"
I pretended to have a clue "Um.. yeah!"

Now here's Tyma's life rule #152. If someone believes something wrong - but you WANT them to believe that wrong thing -- say as little as possible. Your words can only screw things up. I knew this. I shut up. I kept walking.

As I filled my bags with polyester t-shirts I didn't need, squeezing toys with company logos on them, and the occasional usb-drive key fobs I thought more about this whole concept. Its real simple - break the rules with no consequences. Usually the crimes you commit are small - but the trick is that they can add up. The business man from above could probably eat free every day. Getting into places your not supposed to (like conference exhibit halls pre-opening) often have advantages - after all - they are keeping you out for a reason. All you need for this little plan is some confidence. Our business man wasn't embarrased or frightened when asked to leave - to him - it was simply the end of this opportunity. On to the next.

Now it sounds like I'm a proponent of this whole underhanded way of life. I do believe you should reach out and grab what you can in life lest it pass you by. But I hate it when I am the victim of these little trangressions a lot. There must be a way to punish these mini-evil-doers. After playing with this idea for a long time I've come up with a name for it -- the "Squirt-gun offense". Succinctly, this describes any offense that the logical retaliation would step "over the line" and thus you really can't do it. The idea is that if you can't retaliate like you like to, you can at least soak the perpetrator in water. For example:

1) Someone maliciously cuts you off in traffic in a personal way.
Correct response: Side-swipe them and give them the finger.
Why you can't do that: Your insurance goes up and you might injure your finger.
So what you usually do: Attempt to cut him off in return or get yelled at by your wife for trying and sit back in traffic as the loser.

2) Your business rival asks if your wife has quit her Jenny Craig program again.
Correct response: Comment that you used to sleep with his wife and you're glad that's over.
Why you can't do that: You've overstepped the line - he'll punch you. His insult was subtle - yours is an attack. It would make sense to retaliate with a subtle insult but that's hard to do once your mad from his comment. Your intent is to retaliate hard at this point. His subtle insult was really an attack to, but as a conversation opener and given with the right tone, it could be cloaked as concern.
So what you usually do: Smile and comment on your wife's successes.

3) Someone off the street has the nerve to crash your wedding reception and eat/drink.
Correct response: Have the groomsmen take him out back and beat the living snot out of him for trying to ruin someone's special day..
Why you can't do that: Groomsmen will get in trouble and they are your friends (presumably).
So what you usually do: Politely ask him to leave now that he's full and hope he doesn't make a scene.

Shooting someone with a squirt-gun is probably illegal (squirting with intent to dampen) but it's not likely you'll get busted for it. If you do it, you'll probably make the target mad - but there really isn't much they can do about without stepping over the invisible line themselves. If they whack you - its a whole new ball game. The judge is not going deem assault "ok if first squirted with water". A better plan by the hotel manager from our first story would have been to simply walk up to the business man and start pelting him with shots from a super soaker. What's the business guy going to do? Tell the cops they squirted him? Heck, he stole donuts - I think its even.

The paramilitary guys guarding the exhibitor hall looked downright uncomfortable not having a weapon of some sort in their hands. I doubt a greanie-meanie squirt cannon would have satisfied them completely, but it would have been a step in the right direction. They would have begged for offenders.

Honestly, I haven't found a solution to the problem of being the victim. I don't think there is one that works in every instance. Quick wit is a big helper in a lot of cases but doesn't do much if someone cuts you off in traffic.

However, at least now I have a name for the type of situation I'm describing. Anytime someone does something that makes me want to retailiate but circumstances prevent me from logically doing so, I should squirt them with water - they committed a "squirt gun offense". The more it happens to me, the more I try to learn from it.

I try my best to not be the victim, but if you get me, congratulations. And I hope you're wearing waterproof undies.

Mom, I think I'm a Cyborg

Keyboards are good. Mouses are dumb.

If I was an alien looking to slowdown the technological advancement of the human race, I would have implanted into their society the things we call the keyboard and the mouse. In fact, the only personal proof I have that this was not the case is if aliens were involved they would have updated the pain by now. Like making the "shift" key a foot pedal or something.

Assuming mailicious aliens weren't involved, this isn't good news. It means we were silly enough to have invented these things ourselves. And then we were silly enough to let them "catch on". And we're silly enough to not personally diverge to a more efficient invention just in case we might later still need to know how to use this one. We humans follow a frighteningly simple herd mentality, God forbid someone jumps off a cliff and yells "free USB fobs!" - we'd be goners.

Truth is however, that with the keyboard at least - we have adapted. Our brains and fingers have optimized this abomination enough to actually get decent output. Obviously, the optimal tool would be one that can output words (actually, getting rid of words and going right to thoughts would be way better, but that is as of yet - out of scope) as fast as we can think them.

Now you might actually have been thinking the opposite. That the mouse is the more precise tool of the two. Well not for me it isn't. For artists and graphic manipulators the mouse is all that and a bag of chips - but for text people like myself, you can keep your seedy mice.

The problem with mice (which the nefarious aliens know all too well) is that its use removes your hand from the keyboard. To open a file in your favorite editor, chances are you grab the mouse, find the pointer with your eyes, move it to "file", click, move it down to "open" (hopefully not having to deal with any of those sub-menus that always seem to unpop off my screen as I'm moving down trying to get a lower entry) and once again click.

The alternative way to do this using just the keyboard (which I'm callously assuming is where your fingers already are) is to hold ALT, press F, let go of both, then hit O (thats as in "oh", not zero).

I have never written down all those operations before now and just looking at the two makes me feel stupid to have every used a mouse to open a file. The ALT-F method is no secret - why the heck don't we use it? ALT-F then O is even two different hands - it really is quite fast. My only explanation is that such keystrokes are cryptic and will require a bout or two of memorization whereas the peachy mouse-menu route hand-holds us right along the way. The mouse cursor gives us a constant bookmark of where our thought process is "I just clicked the file menu - now I'm moving to click open".

There is a nice book by Andy Clark called Natural Born Cyborgs. He makes an interesting observation that we all are already cyborgs (loosely defined as a fusion of humans and technology). His example is that if I am at your house, I may ask you "Do you know what the word poikilotherm means?". If you don't you would say "No, but we can look it up!". Upon consulting your house dictionary or your ubiquitous wifi connection, you can easily do that.

Now similarly, I might ask "Do you know what time it is?". And, at the very instant of me asking, you may not. However, the common response is to raise your wrist to your face and say "Yeah, its 4:30".

You liar. YOU did not know. Your watch knew but took credit for its perpetual temporal omniscience. I always know what time it is cuz dadburnit - I have a watch! In effect, we have extended our concept of self to include our watches - thus in Dr. Clark's claim we are cyborg. (Note that grammatically speaking, that sentence should end in "cyborgs", not "cyborg" - but if you ever watched Star Trek you'd know that cyborgs don't use contractions and often speak of themselves in a hive mentality - thus if we are them, no worries about speaking like them)

I may be creating a tenuous connection, but to me, the mouse seems like the dictionary and keyboard like the watch. That is, the keyboard is way more a part of me than the mouse is. I say this because I have painted myself into a very interesting computer-using corner.

My primary editor is a program called Emacs. It is as old as me. It was invented to provide editing capabilities on machines long before there were graphical windowing systems or meeces (some claim it was invented to scare small children, these however are bad people and ought to be ignored). Thus, everything (I mean everything) can be done with a precarious set of keystrokes. Without argument, these keystrokes are hard to learn - but once you do, your productivity goes up. Or more precisely, you are no longer slowed-down by the burden of learning the keystrokes while your real intent is to actually get work done. You go from an unproductive keystroke learning stage, hurdle the entire semi-productive mouse usage stage, and arrive in a land of control-key laden goodness.

To further my argument that keyboard=watch, here is my predicament. I sometimes get asked "What's the keystrokes to do XYZ in emacs?". After a moment of thought, I often find myself stunned that I do not know. I mean - I DO KNOW - I do XYZ all the time! I just can't tell you.

In effect, I have used these keystrokes so long and talked about them so little that the exact sequences have left my conscious mind. In other words, there are many keystrokes that my fingers know that I do not. At times, I have literally had to observe my own fingers to answer a question about how to do something.

To this end (again, I work 99% of the time in text, I fully understand my observations are irrelevant for more graphical professions) I have structured my desktop to be purely manipulatable by keyboard. I didn't do this consciously - it happened in stages and one day I noticed my mouse had dust on it. Using the mouse feels like using a pen in my left hand. I can do it, my output will inevitably be the same (albeit harder to read maybe) but I'm faster with the pen in my right hand.

I fully understand that if the aliens I mentioned in the first paragraph do exist, then I am a dangerous revolutionary in their eyes. I am thwarting their ingenious mouse device intended to often remove my hands from my productive keyboard. It is distressingly likely that some large death ray is pointed at the top of my head as we speak (and thanks to my body's recent affinity for dihydrotestosterone, this is much easier to target from space).

You never know though, it is possible they may be more subtle and simply try to slow me in other ways. I shall in the coming weeks keep a close eye for incoming packages that lack return addresses but contain USB footpedals that have the word "shift" on them. If such a thing arrives, I may heed the warning and go back to using my mouse. Until then, ALT-f x.