Paul Tyma

Why We'll Never Meet Aliens

2013-04-26T09:50:00.002-07:00

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.


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.

Its not much.. but its home.

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.

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

2012-05-02T08:35:00.000-07:00

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: www.mailinator.com, http://mailinator.blogspot.com/2012/02/how-mailinator-compresses-email-by-90.html

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. paul@refresh.io or check out www.refresh.io/jobs)

Why you should join a start-up - and maybe why you shouldn't

2012-04-24T08:43:00.000-07:00

I've recently been interviewing engineers for my new start-up (fyi, this is wholly separate from Mailinator). We're well-funded, have a world-changing idea, and as you can imagine, I plan to build an awesome engineering team. (Regardless of where you are, if you're a passionate developer, I'd love to hear from you. Check out the Job Description here and email me your resume at paul@refresh.io ).

I've been talking to engineers from all over hearing their stories. There's really amazing talent everywhere and honestly, a non-trivial amount of it seems to be idling or even decaying in environments that aren't using its full potential. A bunch of moons ago I used to work for Dow Chemical in the dreaded "IT department". It was pretty clear to me then that I was not growing technically in that job. I left to start my Ph.D. but I always vowed from then on that if I was going to be a software guy, I was going to work for companies who's business was creating software. In other words, at Dow I was an expense, I'd much rather be an asset.

Eventually and with that goal in mind, I ended up at Google. Without reservation I can say it was a fantastic experience. I have said before, "if you're the smartest person at where you work - quit". And trust me, nothing makes you realize how smart people can actually be by working at a place like Google. (To avoid any implications - I did eventually quit Google, but rest heavily assured, it was not because I anywhere even close to being the smartest person - read on!).

I did over 200 interviews while at Google and it was actually a bit fun to interview someone who was coming from someplace where they were the smartest person (at least about tech). I could always tell. It's no surprise that if you're the smartest person somewhere for a long time, you get used to it. You get used to waiting for people to catch up to where you are.

By no fault of their own they walked into the interview with some attitude. An attitude of impatience if nothing else. After someone like that started at Google however, it didn't take long for them to realize the situation they were now in. It was humbling in many respects and I don't mean that negatively, simply they'd not recently (or ever) experienced a place where many of the people they met were at their level or better. Obviously, there are smart people everywhere but almost universally, smart people enjoy the company of others like them, the synergy makes them all better. This is why Silicon Valley is a magnet for them.

As I said, Google (and similarly Facebook, etc) are great places to work. At some point after working there however I thought to myself what a wonderfully steady and safe place to work it was. My responsibilities, expectations, and compensation package were well outlined. I was working with awesome people and learned a ton but I still felt it was far too big for me to have any real impact.

For a time, I worked on the Google Web Server which I could best describe to non-techies as "well, sort of the thing you interact with when you do a search" (this is a bad definition at best). A woman I was dating thought about that answer a moment and condescendingly replied - "what do you mean you work on that - isn't that done?"
In one sense she was right, I worked on that darn thing every day but to her it all worked the same. To her, I was having no impact.

It occurred to me that Google would be a fantastic place to work if what I wanted was a meaningful 9-5 job that after each day of work I could drive my minivan back to my home in the suburbs. But I didn't have a minivan. And I didn't own a home. And I didn't live anywhere near the suburbs. What the heck was I doing there? The smart-person environment was at start-ups too - I could get that there and even have some ownership of what I was building.

It's a relatively normal course of life in our sea of first-world problems that you'll have many chances to take risks early in life and those chances diminish as time goes on. Simply put, Google will always be there. And if Google isn't - the next big, awesome company will be. Every decade or so has a "company" (or two) where the greatest things and the greatest people are happening. At times it was Microsoft, Cisco, Apple, Google, Facebook, etc.

I left Google not because Google was in any way bad, but because I wasn't done swinging for the fence. And I still had the luxury of trying. If I ever got to the point where I wanted to realign my life's risk profile, Google (or Google-next) would be there. And this is a pretty common theme - places like Google and Facebook incubate some set of people into entrepreneurs who then go start their own start-ups. But with big ideas, agility, and impact. And they don't tend to fall far from the tree. You might think Google doesn't like this - but I doubt that's true. This is a constant stream of risk-takers that go try stuff for them that they can buy back if needed.

What gets me today is how vibrant Silicon Valley is right now. And even for Silicon Valley this place is on-fire. It seems cities around the world try to copy it but that's really hard to do. The start-ups are here because the investors are here, and the investors are here because the start-ups are here. Guy Kawasaki wrote a great article several years ago partially about why Silicon Valley is Silicon Valley.

I am fully aware that Silicon Valley has a nasty habit of simply not being able to darn well shut-up about Silicon Valley. Other cities are hotbeds for tech too (Austin, NYC, etc), but truth be told, you could find a cadre of smart engineers doing a great start-up in a Des Moines, but it's not easy. There's LOTS of great companies in Silicon Valley that can take you to the next level.

We're in the midst of a huge wave. Depending on your risk profile, joining a start-up or joining "a Google" is the best way to put your chips in the game. Regardless of where you are - if you're a crack-shot engineer looking to change the world, you could do worse than coming here. Again it's all about your risk profile and what's keeping you where you are (which may be great reasons). Start-ups will not only pay to relocate you, we'll put you up for a few months (in the corporate crash-pad) while you find your own place. Joining a start-up now will get you experience both technically and start-up-wise that you can't get anywhere else.

I'm not thinking the start-up life is for everyone. I can definitely see a point in my life or where I have life-constraints where I'll want my job to be a less important part of my life (probably because my life will be more about, well, you know - just "life"). But for me right now, and maybe for you - I'm swinging for the fence. And love or hate IT departments, I couldn't do that there.

Again, if you're a software engineer that loves what you do and lives in commuting distance to Palo Alto, CA or is willing to relocate, I'd really love to hear from you. We're well-funded and I'm literally building the first engineering team right now. It's a fantastic opportunity to get in on the ground-floor of a great start-up. Refresh.io jobs

Overheard at my last Bullpen Cap VC Meeting

2011-11-21T08:14:00.000-08:00

I'm lucky enough to be on the advisory team at Bullpen Capital. The main part of that job is that once a month we have a meeting where the advisors get to hear multiple start-up pitches and give our thoughts about each.

It's always great fun but it's also not unusual that I find myself in a situation like this one:

Managing Director: "Everyone meet our new member Bob. Let's go around the room and introduce ourselves to him. Josh - you start"

Josh: "Ok. Yeah, so I was a Senior Product guy at Linked back in its early days. Then I went to Zazzle and Headed up product development for them. From there I went to Facebook for a few years before landing at Twitter - wow, those were wild and fun times. Currently, I'm a Principal for an awesome VC firm here in the valley."

Managing Director: "Great! Paul, you're up. Tell us who you are."

Me: "Huh? Who am I? Oh. um. I grew up in Ohio, I like pizza, and I'm never sitting next to Josh again. Next."

Of course, the little secret is that I make sure to sit next to people like Josh every time. I figure, surrounding yourself with overachievers can't help but rub off a bit.

Startup Ideas - Part 3

2011-10-29T15:41:00.000-07:00

A few years ago I wrote 2 posts about evaluating start-up ideas. They were pretty well received and recently I bumped into them again. It's always fun (unless it's frightening, which it often is) to read your old stuff but it made me think how much has changed and how that's affected how I evaluate start-ups and start-up ideas.

Apart from working on my own start-up, these days I'm an adviser to several companies and am part of a VC-firm's advisory team. The frosting is that I get to hear internet start-up pitches on a regular basis. Then I get to throw in my input as to whether the team, approach, tech, idea, and probably 100 other factors come together to make a company investment worthy.

Of course, like anything else, if you start doing something enough - you start to see patterns. What I'm writing here are some of most noteworthy things that have caught my attention.

Basically, a few questions to ask yourself about your new idea for a startup.

1) Do you see the "Snowball" ?

I pitched an idea a few months ago to the CEO of a rather-mature and happily successful start-up. He was rather intimidating in how fast he understood the big picture. I'm not sure what sort of casual conversation I could keep him interested with at a party but I'm sure that if I had had a whimsical need to immediately know, for example, the half-life of cesium-137 (and google happened to be down), I could have just asked him.

He sat and listened largely emotionless to my idea. At the end of my presentation, he looked at me and said "I don't see the Snowball". He ended the sentence with such a period I not only felt the meeting was instantaneously over, I was waiting for him to push a button and have the floor open up sending me sliding star-wars style outside into the dumpster. The "snowball" as he put it. That is, the very obvious reason this product is going to take off, keep going, and getting bigger. The reason why customers will come - and why they'll come back. Why they'll get their friends to come who will then get them to come again. The "viral loop" is a specific facet of this for social sites - but it applies in every case one way or another.

Interestingly, he didn't ask me "Where is the Snowball?". He fully assumed that if it was there, he should have seen it already. If it hadn't shown it by now, having to ask wasn't going to save me.

This idea is documented across the web in many different names. Viral loop. Customer acquisition/retention. Or even the "Techcrunch effect" - get mentioned on Techcrunch, watch your servers scream and then... nothing. In any start-up idea, you need to be able to see the snowball. And how it overcomes impedances such as cost (if any) and competition.

Spotify - free music, posts to FB to involve friends
Facebook - free gossip, detailed voyeuring of people in your life
Google - free information

Gamification is an artificial method of creating a snowball. The seratonin shot you get from competing with friends and winning at a game that is very easy and has fair, tractable rules for success. Then give them the ability to "cheat" using money while still taking credit for the success.

2) What's the customer effort required to gain what value? Your answer better be "a little" and "a lot".

Every keystroke you require from your users to use your product is a speed-bump to adoption. Every single keystroke. And, for keystrokes that are digits, where those digits together make up a credit-card number are like 20 speed-bumps piled together.

They don't call it the "pay wall" for nothing.

I love to see products that give me value the instant I'm introduced to them. If it requires a lot of work first - I better fully understand the value I'm going to get or it's not likely I'll care to find out.

3) Are you technically defensible?

I bet you're not. And although it's very nice to be, surprisingly you can get pretty far without it.

They say that the more little things in life surprise you - the younger you stay. Well thank God for that. It seems every day I say to myself - "now it's THAT easy?". I am perpetually amazed how radical advances in computing power, storage capacity, and programming abstractions have not so much advanced us as species - but instead made everyone a coder.

Now mind you - all that computing power also made it really really easy to be a bad coder. At least in the computer science sense. But the real bottom line is that it almost never matters until you get a lot of traction. And if you're ridiculously bad performing app starts to die because of too many users - that's what we call a "rich man's problem". In other words, at that point you'll like be making money or be ripe for investment to hire programmers or sysadmins or whatever to fix the problem.

I've seen I think one pitch in the last year where I thought the technical hurdles would cause a strong deterrence to competition. That was Flashsoft. Phil Karlton famously said "There are only two hard things in Computer Science: cache invalidation and naming things" and Flashsoft is doing cache invalidation.

Now mind you, technical hurdles don't mean "no competition" they just mean it takes a sophisticated (and crazy smart) team to be up to the task. But we all know - those are more common than you'd expect.

In full contrast, I saw a pitch this year where the team had a nice (web) GUI and then showed their technology. As they demo'd it became immediately clear to me how to recreate what they were doing. They were (pardon the technical jardon) making one call to Amazon's API, making one call to Facebook's API, and showing the results.

So, unless you count "call Facebook, get result and give to Amazon" as technology - they had none. There was no analysis, no intelligence - no nothing. Without the GUI (which was very very nice) - this was without exaggeration 20 lines of Ruby code.

It might be a shame to call this company a technology company, but as I said earlier, their technology might not have mattered. Execution and team still win the day. Sadly, their team would not have filled the gaps which was enough to rule out investment, but the "lack of tech" wasn't the only factor.

As a final counterpoint - GroupOn, AirBnB and Taskrabbit are 3 companies that have in my estimation completely uninteresting "technology". If you're a developer is there really anything there you couldn't see how to create with just a moment of thought?

4) What's your plan for moving off of Facebook?

Ever heard of a Remora? It's that fish that literally attaches itself to sharks as they swim around. Sharks don't mind apparently as they provide a mutually-beneficial relationship. They clean off parasites and sharks provide implicit protection and for the most part the shark doesn't even notice them.

If you watch some videos of them latching on to Sharks however, you'll notice something, it's not often you see one swimming in FRONT of the shark. It's probably some sort of well-known unwritten code among remoras - latch onto any darn thing you want - except near anything resembling teeth.

Sure, there were probably a few rebel mouth-latching remoras that flaunted convention throughout history - but they're gone now. And whatever gene they had that said "Hey.. try latching on the mouth - no competition and plenty of yummy parasites!" disappeared along with them.

I'm not saying Facebook is a shark. They're just a bigger company trying to grow their own business. In that way, they're no different than Apple (tons of iphone app developer "get squashed" stories) or Microsoft or anyone else.

Creating a mutually-beneficial relationship is what it's about. Regardless of what stage you're at - bringing and/or keeping users on Facebook makes Facebook happy. However at some point, you'll hopefully grow big enough where Facebook notices you. That's sort of like the "rich man's problem" from above except that people are trying to kill you and money doesn't change their mind.

Starting out partnering with a big company is usually good. Facebook or Apple or whoever. If your dream comes true however - you likely get two courses of action.

Get bought by them - or have a plan for surviving without them. For Facebook it's usually that you keep it as a customer acquisition mechanism, but not your only one. For Apple, you usually migrate to Android and/or Web.

No need to name names but most every big company has purposely or accidentally stepped on a few start-ups along the way.

5) Your business model is advertising? no. really. What is it.

Despite the incredibly obvious and utterly overwhelming evidence to the contrary, Facebook as an advertising platform never felt right to me.

For example, when you go to google to do a search. You are, literally - going to google.com in order to, as quickly as possible - LEAVE google.com.

Marissa Mayer's super clean homepage is great, but you're going there to find out something specific and move one. Like, what was that train movie where the guy keeps waking up in someone else's body?

If almost everyone comes to google.com to find something and then leave, then some percentage of those people will find what they're looking for via an ad. You have to leave somehow - once in awhile you'll leave via ad. At times, the ads are exactly what I was looking for.

Facebook however is different. You go to Facebook to stay. I'm not sure I've ever clicked a Facebook ad. Sure I've clicked photos of Aunt Edna's 75th birthday and videos that cousin Willy linked to. But I go to Facebook to find out family/friend gossip. Not do product research.

The days of monetizing through solely ads are sort of over. I don't mean that by saying ads are dead (phew - heck no). I mean that as there are far more options now than simply showing adsense.

a) Companies like Viglinks and Skimlinks will affiliatize every last link (that can be affiliatized) on your site. Wordpress and Ning do this to great effect. b) Install the browser plugin Ghostery and watch how many sites get to know where you are browsing. Tracking user movements is big money and imgur likely monetizes not through ads, but by selling advertising data companies the data that you were there at all.

Simply - more than ever, if you have a few million eyeballs a month - the baseline ways to monetize are better than ever.

5) How does this get to $100MM? (helpful hint: It's nice if the market size has a good size number followed 'B')

I alluded to this earlier, but it's important to point out that even if you think a company has a wonderful chance at being successful, that doesn't necessarily make it a good investment. Many factors surrounding that success help determine that.

One pitch I saw fell for this exact reason. I liked the product a lot. It felt like one of those products that you can throw off a cliff and all by itself - it will crawl itself back to the top still generating revenue. It worked. It was going to work.

But examining the market - I couldn't see how it could get past a certain level of revenue. This included factors of market size, competition, and strategy. This is one reason market-size is always part of pitches - if its big enough - then we can skip a few details in worrying that the company can get to a needed size.

So what's a needed size? That depends on your investors and how much money you're going for. It's another good reason to start with angels. If the company grows to Zynga size - great, we've proved the model and we can add investors as we go along. But if it doesn't, we've taken a good amount of cash for what we need to do.

Walking into Sequoia asking for you iniital funding round of 10MM might be cool. And you just might be the right person to be able to do that. But your projections better better warrant the round. Yes, everyone knows those projection numbers are shot from the hip. But they still better be there - and with a story that could theoretically make sense.

Simply - different investors need to make particular sized investments with expectations of particular sized returns.

Incidentally, this works for job offers too. Some of the hottest startups in the valley make great offers but you also always need to do the math. Being part of a hugely successful start-up is great, but sharing in that success is rather nice too.

6) Revenue is King. And so is Traction.

Ok, that's not a question. But seriously, everytime someone makes a list of questions - one of them has to not be a question with a sentence following saying "Ok, that's not a question".

If the rubber is meeting the road it gets harder to argue. In fact, if you have traction (and maybe even revenue) then investors only need to consider how you might get squashed somewhere along the way (see "getting off of Facebook" above).

Waiting until you have these two things is a great way to improve the interest and terms you'll see from investors. If you don't have them - investors will be looking a lot harder at you and trying to guess if your idea could someday get these things.

7) What's your customer acquisition and business development strategy?

As a disclaimer, I'm a complete techie. I started my first start-up with 2 other complete techies and you're not going to believe what we did - We sold our products just like a few complete techies would sell products like. (no.. I re-read it, that sentence is ok)

Maybe our worst sin was thinking we were kicking ass. When we finally hired a bizdev guy and with extreme skepticism - he changed everything.

Our pricing model was wrong. Our marketing was wrong. And most notably to me - he changed our company from selling products to selling solutions.

If you don't know what that means, you too may benefit from gaining the help of someone who's acquired customers and positioned products before. Put simply - we went from selling things for little bits of money to selling bigger things for bigger bits of money. All the while bringing more value to our customers.

It's really amazing what a small pivot can do for a product to bring it to new customers and to expose a much higher value to those customers. This should probably be filed under - "do what you're good at and more importantly, admit what you're not good at". And hire people in those roles.

Pitching is an art - and so are start-up ideas. I still get a few ideas a week I quickly kill for lots of reasons. The ones that make me the saddest are those I think people would love and use - but that I can't see how to turn it into a scalable business. I'd love to do those things for fun assuming time was an infinite resource.

Making web sites has absolutely never been easier. All you really need is to know how to code in some very high-level language and leave all the computer science and engineering problems for when you have scale. Getting the right idea, the right positioning, and the right go-to-market strategy that "can" get to scale however is still the tricky part.

A Google Interviewing Story

2010-11-18T16:30:00.000-08:00

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 gofish.com. 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:

String 1: ABCDEFGHLMNOPQRS
String 2: DCGSRQPOM

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

String 1: ABCDEFGHLMNOPQRS
String 2: DCGSRQPOZ

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 become.com. 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.

The Young Man's Business Model

2010-06-17T10:08:00.000-07:00

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?

A thought experiment on the end of Humanity

2008-11-11T09:46:00.000-08:00

Pretty slick title huh? Thought of it myself.

My girlfriend used to be a high school teacher. She told me an interesting fact - she said one of her bigger issues was that sometimes when a student handed-in an assignment, it wasn't uncommon for it to be something the student simply found on the Internet, cut-and-pasted into their word processor and handed it in. If you're like most people I tell this too, you're a bit unhappy about the laziness of these students. Instead of learning something for them self, they simply used Google to find it, and (effectively) recite what they found. Pretty weak, eh?

Einstein was once asked how many feet are in a mile. He replied something like "I don't keep information in my head, when I can just open a book up" (I googled that). Einstein apparently didn't have google.

Funny thing is that when Einstein was alive he'd look up simple facts (i.e. 5280 feet) in a book. Ten years ago we had the ability to look it up on our computers. Now I can look it up on my phone that's with me at all times. What do you think is next?

Let's say that what's next is mind interface to the net. Surely, this isn't a new idea and people are working on this right now.

But think a second - what happens when we have instantaneous access to the Internet without moving a muscle. If you ask me how many feet are in a mile and I answer - you won't know if I knew it, or if I "looked it up". And at that point, it pretty much won't matter. If it takes more effort to memorize it (to my real memory) than it will be better and faster to just leave it on the Internet and grab it there whenever I need it.

Like all technology this promises to have its glitches at first - but eventually, it will be pretty reliable. And what then? Well, if our minds work like our flabby bellies, then our human memory will atrophy. We'll slowly but surely lose the ability to remember things.

We tend to describe the idea of "knowing things" as wisdom. And we tend to describe the idea of "figuring out things" (like math or connecting disparate concepts) as intelligence. A way to distinguish this is that you can be born intelligent, but you can't be born wise.

Tomorrow's Internet has the potential to fully replace wisdom. We won't be any less wise - in fact, we'll all be instantaneously super-wise. And equally-wise (which may be weirder than being super-wise). Even children.

If you think this is crazy - I argue its already happening. Those kids in my girlfriend's old class already find memorizing things to be more effort than simply googling it. As soon as they get a faster interface to that information, they'll take it.

Most people that disagree with me on this don't actually disagree, they simply fear it. It does spell a fundamental change in humanity - and that's rather frightening. Surely things will change fast. At a minimum, all business that relies on hiding information will be, ya know, gone.

But it doesn't end there.

If we all gain super wisdom, then the only mental differentiation between us is intelligence. How fast can you multiply two numbers? How many times must some explain particle physics to you before you get the relationships between the elements involved?

The first computer beat the first human chess grandmaster in 1998. We pretty much always associated chess with intelligence, but chess is actually a pretty unfair example. Humans approach chess abstractly. In some sense considering the board as a whole, processing it in parallel, and extrapolating opportunities from it. Computers work far differently. They simply examine every possible combination (with some smart algorithms to not examine useless moves) of the game from this point forward. Chess has so many possibilities that it took awhile for computers to get fast enough and computer programmers to get clever enough to search enough possibilities to beat a human.

Computer "intelligence" is likely farther off than computer "wisdom". But you're fooling yourself if you think it isn't coming. The human brain is in essence, just a machine - damage it and it stops working. Give it alcohol and it gets off kilter. Computers will reach it - maybe not computers as we know them, but computational machines will. Ray Kurzweil predicts this sometime in the 2020's or so (per the book I read anyway, he might have changed his estimate - incidentally, he predicted computers would beat a chess grandmaster in 1997 - he was off by a year).

So what happens then? To us I mean.

By that time we will have farmed out our personal memory long ago. And then, we'll start farming out our thinking. We already happily do this with calculators or spreadsheets. We all know computers kick our ass when it comes to math. Who wants to do long division anymore? Let the computer do it. We've already farmed that part of our intellect out. If you told me I could get a chip put in my head that let me do all math instantly, I'd sign up for sure.

What happens when computers can do more? I mean, literally think for us. It won't happen overnight. But just like long division and multiplication today - we'll do it little by little. As computers get smarter and smarter, and as our interface to them gets faster and simpler, we'll slowly but surely, give them our thinking tasks.

And just like the dumbification of our kids today - and just like our fat bellies and long atrophied human memory, our unused thinking capacity then gets lazy too.

What happens then? Seems like, in some sense, we sort of cease to be as we know us. We become conduits to some consciousness we created elsewhere. You can call this extinction, paradigm shift, or apotheosis - it probably doesn't much matter.

I'm not smart enough to know what happens in this borgian future - but I have a feeling, that in 20 or 30 years, I sure will be. And so will you.

Kurzweil is a great read on ideas of the future:
Age of Spiritual Machines

Never send your Application out alone again

2008-10-27T08:50:00.000-07:00

Anyone that reads my blog knows I was one of the founders of a company called Preemptive Solutions, Inc. Preemptive was my first startup and has a very been very successful in evolving its DashO and Dotfuscator product lines. Those products are near and dear to my heart as the initial incarnation of DashO was spawned from my Ph.D. dissertation work. People often now associate it as a Java Obfuscator, but to me that was largely an afterthought. Its a static analyzer of an interesting sort for Java. I had originally set out to write a Java bytecode optimizer, but I quickly realized that given Java's nature, you fall pretty flat on how and when you can do static analysis.

Java (and .NET) have very many dynamic components (the more you look, the more you tend to find). My dissertation (http://portal.acm.org/citation.cfm?id=1087610) was most interested in a scheme to identify closed systems inside of Java applications. Basically cordoning off open hooks into Java applications and not trying to optimize across them. In essence, it identifies sub-applications within Java and .Net applications and optimizes those one at a time.

This is all well and good, but its basically old news.

Whats new news is Preemptive's new product line. As Preemptive evolved those static analyzers, they got really really good at instrumenting code. In fact it became second nature. Preemptive's new product line takes advantage of this know-how.

They call it "Runtime Intelligence" - I call it fricking cool.

I explain it like this... In past decade application servers popped up to provide an application services cradle for which you to drop your business logic code into. Basically, you write a nice little piece of business logic, put it into an application server, and that server took care of all boilerplate details like database access, fault-tolerance, load-balancing, etc. Its a silly idea to think every website had to write code to handle these generic ideas.

The heyday of application servers isn't what it used to be as many discovered that they added a ton of overhead for applications that weren't using all those shiny services. In fact, new web or server frameworks pop up all the time to literally "part out" application server functionality. You used to ask someone their server infrastructure and they'd say "Weblogic" - now its not uncommon to hear "Spring, Hibernate, Struts2 and GWT".

Runtime Intelligence is sort of the inverse of the idea of an application server. Simply put, Runtime Intelligence allows you to "inject" prebuilt functionality modules into your application. So, does your super application need licensing? Does it need to update itself through patching? How about statistics on how people are using the product?

You got it.

Write your code like you planned to without worrying about "generic" functionality pieces and "inject" them later.

Whats more is that Microsoft has bought into this idea in a big way for .NET. Microsoft today announced a joint press release (See it here) with Preemptive at PDC about this product. If you're familiar with how Microsoft works, you know that joint press releases are pretty rare. Its clear to me that they "get it". This is big.

Preemptive's first round of injectable functionality is pretty slick too. Basically a statistical package for your application. Like web analytics, only for applications. Ever implement a feature and wonder how many people really use it? How about finding out that 33% of your customers never get past the 2nd page on your wizard (maybe its design is too confusing?) How about finding out that 68% of users tend to do 5 features in the same order everytime - and you could easily add a new feature that does that for them. Simply put - releasing an application into the wild unknown and "guessing" how users use it is a thing of the past.

Surely, this kind of application monitoring makes a lot of sense for certain types of applications (of course, its not right for every application just the same way other boilerplate functionality like licensing or patching would or wouldn't be). Either way, this opens up all new possibilities in development planning for applications. I expect plenty of meetings between sales teams and project managers discussing this data.

Some people have compared this to aspect oriented programming, but that's quite inaccurate once you look deeper. I've used both and aspects feel like a sledge hammer (and at least for the packages I've used, an annoying-to-configure one at that). Runtime intelligence is surgical (as far as I know, no one is doing feature stats with aspects). You write the code and inject real business boilerplate functionality anywhere and anyway you want.

As you can tell, I'm really excited about this - and I'm doubly excited that Microsoft is on board with it too. If you're going to PDC this week, definitely check these guys out.

Disclaimer: I have an unhealthy crush on this company. It has gone farther than I had ever imagined and I'm continually impressed of their accomplishments and future.

Probably the hardest sales job ever

2008-08-28T12:37:00.000-07:00

The VP of Marketing of my old company is an absolute master at analogies. One of my favorites was when he described to me the idea of selling a new product that creates a brand-new niche - often a very difficult task.

He likened it to the first person that had to break ground selling thermometers. Not the "How's the weather" thermometers, I mean the "Do you have a fever thermometers". Surely nowadays these are digital little gizmos, but when they came out they were the old-fashioned mercury based ones.

I can imagine the sales-pitch:

Customer: So, whats it good for?
Salesman: It will tell you your temperature.

Customer: Why do I care about that?
Salesman: Well, then you will know when you have a fever.

Customer: Um. I already know when I have a fever.
Salesman: Yeah, but now you'll be sure.

Customer: Erm.. k.. What's it made of?
Salesman: Glass

Customer: Whats that stuff inside it?
Salesman: Mercury - careful, its toxic.

Customer: How do I use it?
Salesman: You just put it in your butt for 2 minutes.

Customer: Um. So basically, you want me to take this toxic-substance filled thermo-thing made of breakable glass, stick it and leave it in my butt for 2 minutes so that I'll know something I pretty much already knew.
Salesman: Yepper.

Customer: Awesome - I'll take 2 !

That had to be a hard job. Solve a problem that was perceived as not needing solving and then do it in a new, dangerous, and highly uncomfortable way. And you thought software was hard.

A few ideas about Negotiation

2008-03-17T16:32:00.000-07:00

A good friend of mine asked me for some negotiating tips. This is what I told her. Use, agree, or disagree with them at your own risk.

1) Never put numbers in email. Email lives forever. Numbers are only discussed on phone or in person. Only written down when you're signing the contract.

2) There's an old saying "Whoever puts the number on the table first - loses". In general, this is good fallback advice.

I modify this according to several factors:
a) The less you can predict the outcome, the more likely I let the adversary say the first number. (i.e. revenue-less company valuations are often voodoo - its quite possible your buyer will give a higher number than you ever imagined).
b) The more I need a deal, the quicker I am to say this first number. This sets a tone.
c) Conversely, the less I need a deal - I'm willing to let them show me just how bad they want it. The danger is if they give an extreme lowball, I need to be able to walk.

3) No matter what they offer, ask for more. How forcefully depends on how good the deal already is. If they offer you 10% when you were expecting 3, meekly ask for 12% and back down fast if needed. If they offer 1%, strongly go for 4% and settle for 2.5.

4) Don't answer the phone if they call to discuss the negotiation. You are probably thinking about the chicken mcnuggets you just ate and they have been thinking the last 20mins how the phone negotiation will go. In short - they are prepared, you aren't. Let them goto voicemail. Wait an hour.. spend 10 minutes focusing on the possibilities of the negotiation and call them back. Their mind will be elsewhere now. You'll be ready.

5) Seriously - don't ignore #4. Fifteen seconds is just not enough time to swap your mind into the right context. Besides, information they leave in the voicemail could be advantageous.

6) (Unless you're reading this and you end up negotiating with me - then we might as well set a time in the future to chat otherwise we'll never answer each other's calls.)

7) *Everytime* you sign a contract, you are giving up something. Take a step back and make sure you fully understand all that you are giving up - and all that you are receiving in return. Never sign a contract (or sleep with someone for that matter) because you feel bullied into it.

8) A common negotiating tactic is to put your adversary in an uncomfortable situation. The hope is that the adversary will compromise some just to relieve the discomfort (the more experienced the negotiator, the less likely this is). If you can, reverse the discomfort instead. (This is a class used-car-salesman tactic - think "But you told me yesterday you were going to buy this car!")

Surely negotiation is an art and there's plenty more to it. These ideas are at best a few tricks and tips. Negotiation is a dance - you can't exactly know what you'll have to do until you are forced to react to what your partner does. Thus just like dancing, practice does wonders for your skill.

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

2008-03-05T08:05:00.001-08:00

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 !

Notes for my SD-West talk tomorrow on Interviewing in Silicon Valley

2008-03-02T14:11:00.000-08:00

I'm giving a half-day tutorial tomorrow at SD-West 2008 in Santa Clara on How to Pass a Silicon Valley Software Engineering Interview.

Its the first of 3 talks I'm giving this week (subsequent notes to come subsequently).

You can download the slides Here.

If you're not attending the talk, please note that as with all slide decks, they are in a sense only half the story - as I'll be filling in many pieces during the lecture itself.

This is the third year I've given this talk and I'm amused to mention that I got a thank you a few weeks back from a veteran SD speaker that attended last year's class and now is just starting his new job at Google. He said the class was very helpful (he also offered to buy me dinner, but given that dinner at Google is free, I countered and offered to buy him dinner instead :)

Customers are the most honest people you'll ever meet

2008-02-24T20:44:00.000-08:00

My first startup was Preemptive Solutions, Inc., where apart from other activities, I turned the core of my Ph.D. dissertation into a Java bytecode optimizer called DashO. It was named after the javac (and gcc) command line option "-O". I thought it was a dashingly clever name at the time (The idea of "hypen-O" seemed nowhere near as cool).

In hindsight, it was a pretty dubious product idea. Developer tools are a tough business. For all the talk of application performance, people don't often pay for it except in the form of bigger hardware. However, as I came close to completion of the code, the idea morphed itself into something much more viable (as startup ideas are wont to do).

Turns out people weren't willing to pay for performance so much, but at the time, Java applets were taking off. And people were dying on applet download times - making applets smaller became a component of business success. A wonderful side effect of my code optimizer was that it also made code smaller. And with a few added features focusing on that, it made Java applications amazingly smaller than the original. Getting a 50% size reduction (mostly via bytecode manipulation, dead class/method removal, and identifier renaming) wasn't unusual. The product was a hit.

As time went on, applets gave way to Java ME - and source code protection was added later - but the idea of small code prevailed. If your Java ME application doesn't fit on the phone, then you really can't expect to get many users.

While writing that code, I had just finished writing the book Java Primer Plus. Honestly, I thought I was a pretty crackshot Java programmer. As time went on, of course I kept learning. There really is a teenager phase in your lifecycle of learning a language. It's a distinct point where you're convinced that you know it all. As Mark Twain said (summarizing), "When I was a boy of 14, my father was so ignorant I could hardly stand to have the old man around. But when I got to be 21, I was astonished at how much the old man had learned in seven years."

In your post-teenager phase, the biggest thing you often learn is how little you actually knew. Thereafter, coding in the language moves from your brain to your brain-stem and finally to your fingers. I can palpably tell the difference. When I code in a language I've done for more than a few years, I don't have to think about the language at all. My brain does things like data structures, concurrency, and algorithms whereas my fingers do the coding.

It was about the time that DashO made its first million in sales that I really sat down and realized how bad the underlying code was designed. My deficiency in Java when I had first coded the app was now obvious to me throughout the code base. The first thing that struck me was that I had made nearly every method in the damn application static. Talk about a C programmer moving to Java. I remember being convinced it would make things run faster (of course I probably never tested that given I was so sure of myself).

I remember thinking that it almost seemed wrong that such bad code could be so successful. But it was. To be fair it was quite bug free and actually did do what it advertised. Its success was that it consistently brought value to its users - and they were more than willing to pay for that. They really didn't care if every method was static or if I was bubble sorting my way until Tuesday - if it shrunk their J2ME application by 50% that was good enough for them.

Customers are honest. They vote with their credit cards and their attention. I've heard of more than a few startup launches be delayed because they "needed to rewrite some core pieces". Clearly, rewriting your code is essential at times, but at other times I've seen it be a feel-good technical decision and a downright bad business one. Quite often its like polishing your car's engine. It might make you feel better, but the car won't run any different and no one else is really going to notice when you drive down the street. Simple moral is that if you're going to delay your product launch because of a rewrite, just be sure its worth it. Delays have been known to be fatal.

These days, I don't get to visit Preemptive as often as I'd like but I'm happy to report it is a very successful 25+ person company, still growing, and is moving into some very exciting (to me anyway) new product directions. A new set of developers work on DashO and it continues to grow in both features and users (and happily, they've evolved the code-base into something far more reasonable to maintain). I'm still amazed at how well the application sells, but I guess I shouldn't be. As long as DashO keeps bringing more and more value to its customers, it will remain a successful product. And things like where-you-went-to-school or how static you decided to code your methods be damned. Value is value.

Your business model called; its leaving (and its not coming back)

2007-11-29T12:27:00.000-08:00

Let's say you found yourself a cash cow. Something that made you tons of money; day after day. And let's say that you get better and better at making your cash cow efficient. Pretty soon, you're rolling in dough. At some point you can nearly rest on your laurels while your money machine keeps churning. Eventually, you probably don't need anymore money, but that doesn't stop most people it seems. You just keep on wanting more (and why not, if the cash cow keeps delivering).

Its probably pretty safe to say that at this point in time, the advent of some technology enabled your cash cow. Maybe it was recorded media or a new video format or some computers in need of an operating system. Whatever it was, its likely that some recent technology gave you the building blocks to create your new cash cow business.

And, as you realized that technology enabled your cash cow, you also know that it's just a matter of time before it's going to disable it too. Usually by the advent of yet newer technology obsoleting yours. What do you do then? The best option is to see if you can morph your cash cow to be in synergy with the new technology. Kodak is a good example, they moved from pure film to a strong embrace of digital photography. AT&T is another - land phones are dying - they made sure they were in the mobile business.

Other models however aren't so easy to move with. Music CDs are sort of silly now and the new technology doesn't leave a lot of room for a new business model. What do you do then? You might think that you're the kind of person that if you spent a few years making millions (or billions) producing music CDs that you might eventually have enough of it all. If you truly can't save it then - you can take your millions, smile back upon the fun ride of building something great, and move on to something new.

You might be. But it doesn't seem like this is the way it works. Instead (statistically speaking) if you had an un-save-able dying cash cow, you'd defend it anyway. You'd start to use the millions your cash cow makes to try to change laws, start lawsuits, or stifle technology to artificially keep your cash cow alive. Quite literally, you'd use its own resources to hinder future technology that will hurt it (regardless if thats good, bad, or indifferent for humanity).

Technology enables business, art, and science. And it kills them too, usually by advancing to a point that makes the existing ideas obsolete. A few people miss LP records these days, and surely some still play and collect them. But that number will continue to diminish. I'm sure plenty of folks stuck with a horse-and-buggy because they thought automobiles were a stupid idea. Those people are mostly dead now, just like LP records will be some day.

Now, it might seem like I'm picking on the record industry. I'm not really, they're just a poignant example. Whatever you think, the people in that industry are not idiots. They *know* their business model is dead. Dead, dead, deaddity, dead, dead, dead. Music is really a service, the idea of putting in on a CD was always an artificial means of trying to turn a service into a product.

Instead of teenagers idolizing manufactured rock stars, the internet gives every indie band in the world an open forum. It wasn't that long ago that rock bands begged and prayed to get signed with a big label. Now they can start their own label and reach thousands of listeners, all for the cost of a website. Add a marketing and sales manager and you have a music-making company.

You don't need to be a futurist to predict some corporate business models that will be dead (remnants always remain for awhile) in the near future. Shrink-wrapped software, music CDs, desktop computers, and purely-gasoline automobiles to name a few.

What about if we go just a little longer term - say 30 to 50 years. Now I'd venture to say things keyboards, mice, paper books, bullets, telephones, and batteries.

You might disagree, but I think you're not thinking far enough ahead. I don't think people disagree because they think this idea is wrong. I think just like (or depend) on some of those things and don't want them to go away. If you sell batteries, you'll probably vigilantly tell me that we'll ALWAYS need batteries. In fact, although "30 to 50 years" might not be accurate, my predictions above are pretty guaranteed in some time frame.

A friend of mine disagreed with me when I said libraries were destined to disappear. He argued they won't because people will always like to read from books. "Will always" is a very long time. Most people like books because they're used to them, kids today are pretty used to reading off screens a fair bit of the time. Tomorrow's kids will be even moreso. And would you really be willing to bet we won't invent something better (in all ways) than a paper book in a 100 years? 200? Heck, I'd bet reading itself will be gone by then.

Coming back to the nearer future, the title of this article talks about dying business models. Finding ones in the global corporate marketplace is easy. What I'm more thinking about is *your* business model.

Whether you're a assembly-line worker in a Ford plant in Michigan, a C++ programmer (sorry, I mean "software engineer") in silicon valley, or a McDonald's fry cook. Its pretty damn likely that technology is going to kill your job or career (i.e., your "business model") in your lifetime.

I've read around the net that its a "bad time to be a photographer". Simply put, thousand dollar digital SLR cameras and photoshop have destroyed the historical profession of a photographer. Surely, a skilled photographer can take better photos on average than an amateur. But the rules are now changed. With multi-gigabyte memory cards, I can snap photos all damn day long. And the camera has gotten far better at helping me take great photos. And Photoshop can come in the backside and fix any minor problems I might have. Maybe its a bad time to *be* a photographer - but its a great time to *become* a photographer - anyone can be one in just a few hours! (Of course, thats exactly why existing photographers might think its a bad time to already be one).

Seriously, if I snap a quick thousand photos, its getting more and more likely that I'll snap a really good shot. Then I can sell it on the internet in many instant-gratifying ways for a fraction of historical stock photography. The profession as we knew it is likely soon gone.

I've seen this even in computer programming. Coding used to be much harder than it is today. It takes much less devotion and study to make programs these days and its getting easier all the time. You might argue that good programmers write the best code, but you rarely need the best code to get a website up and running. And programming is perpetually going to get easier. (It used to take HTML expertise to make a website, now it just takes a MySpace account).

Scary enough I can boot up Adobe Illustrator (or more precisely, Gimp in my case since I use linux) and I can do things that a professional graphic designer of 20 years ago could only dream of. This is really a frightening thought - I have a really exceptional lack of artistic ability, but Gimp gives me a baseline. I might not be able to reproduce Van Gogh, but I can make all the graphics I need for websites or Christmas cards or whatever.

In a grand view, this is probably a great thing for our world. More people can do more things faster. It all sounds great unless you're personally be obsoleted in the process. Complaining photographers have somewhat of a point. They spent years perfecting their craft. They learned tricks of lighting and developing and who knows what else just to have it taken away by some fancy new camera. Technology obsoleted their craft overnite (like the song says, "Video killed the radio star").

If you're not a photographer and you're sort of not feeling sorry for them, thats ok as long as you're careful to shine that mirror on yourself too. Like I said, if you spent years learning the intricacies of C++, tax law, medicine, or anything else - you surely have job security likely for awhile. But definitely not forever.

Whatever your business model - it is indeed, at some given rate, dying. And its always possible that a technology will come to be tomorrow that will destroy it instantly. And every year we shall see more fights ensue with people looking to save their business model.

Create a cure for cancer? Watch the chemotherapy companies go into action. Build an electric car thats cleaner, faster, and more economical than any gasoline one? Watch the oil and car companies head to Washington. Invent teleportation? Airline industry sponsored laws will quickly be up for debate.

If you're complaining that your business model is dying, you might as well complain that the sun is going to come up tomorrow. Its going to happen and you have two options - keep moving or retire. Be ready to throw out what you learned if you see it becoming obsolete.

If you're lucky you'll be on the forefront of that technology and you can start a company giving you your own technology-induced cash cow. Once that happens, you can sit back counting money. Until the next wave comes and your once new cash cow starts to crumble. Then, of course, you can adapt again or you can become the technology stifler yourself. Somehow I have a feeling that thats one job that will never go out of style.

Don't Chase your Dream Too Fast

2007-07-17T11:32:00.000-07:00

I thought of a funny quote today (which is oh-so-true):

Don't chase your dream too fast - chase someone else's first, and after you screw that up and learn a little; then go after yours.

(this applies to dream jobs, dream dates, pretty much "dream anything")

This blog made the Top 50 Google Blog list

2007-07-08T23:22:00.000-07:00

SEO-Space has ranked my blog #47 on the Top 50 Google Blogs list. That's pretty cool given how many blogs by googlers are out there.

They mentioned my earlier article on Why I work at Google.

Thanks SEO-Space!

(Of course, I work for, but do not speak for Google. All words are my own.)

Using Tricky Assertions

2007-06-25T13:54:00.000-07:00

I'm not sure why, but I never got much in the habit of using the java assert keyword. Its a nice idea, but I somehow just checked what I wanted the old fashioned way.

And, although I'm a big fan of IDEs and I love debuggers, I still find having some print statements here and there sometimes is really helpful.

Of course, print statements suck when you're done and you no longer want them. That is, you need to go delete (or comment them out) all over the place.

I've sort of combined these ideas into a pretty obvious trick (which I seem to get asked about a fair bit, hence this post). Its basically a comment-out-less, performance-free debugging (or stats, or logging, or whatever) facility.

Simply:

assert(Debug.out("test code val="+val));
or
assert(Stat.increaseHitCount());

The only trick is that the method (like "Debug.out") must always return true. Now run the app with assertions turned on "java -ea Main" and you get the messages. For production, simply don't run with -ea and the VM will ignore those statements (I hope) altogether.

This basically gives you an application-wide, command-line way to turn on or off (with no performance hit if the VM is smart) some code. If you think about, there's many possible uses for such a thing.

Edit: Code for Debug.out would look something like:

class Debug {
public static boolean out(String x) {
System.out.println(x);
return true;
}
}

Been Reading Crappy (Half)Books

2007-06-24T11:24:00.000-07:00

I don't read a lot of books. At least under the definition of, you open it, flip pages over several days or weeks, get to the last one, read the last sentence, say "huh", and put it down. I mean, I don't finish a lot of books, at least nowhere near the number I start.

I *do* read a lot of half books - that is I only get half-way through. I have a feeling I'm rather hard on books - I expect a lot.

The problem I see is that there is simply an absolute deluge of books that should be articles. Simply said, books are about ideas. However (fixing the english of that last sentence), every book should be about multiple ideas.

So so so so many (half)books I read are only about one idea. They have a wispy chapter 1 introduction, chapter 2 introduces the idea (which sometimes is so simple it takes a paragraph), and then the rest of the book cites contrived/researched/induced examples about how that idea is so great.

That's fine and all. Some of those ideas are pretty luminary (i.e. Freakonomics comes to mind) but one single idea has to be pretty damn big to make a book. (Meta-note: the idea that books should be about multiple ideas and not just one idea is probably not a big enough idea to be a book, just an article, or maybe even a stinky little blog post).

I read a lot of technical books (not halves usually) and technical books are pretty hard to be stuck on one idea. Brian Goetz' Java Concurrency in Practice is a great example. If you're a Java techie, this is an incredible page turner. (Another amazingly great techie book is Warren's Hacker's Delight .)

I also read a lot of (half)books about business. I just read a (half)book called Selling Blue Elephants. The basic idea was to do market research using actual customer testing. Cool. Good idea. They even gave a spiffy acronym to try to add it to the world's business vocabulary (much like "tipping point" and "long tail" have done in the past few years).

But that was about it. The rest was case studies on how customer testing helped a bunch of products. Yip.

I also have been listening to Good to Great lately, a pretty heavily lauded book. I don't usually do books on CD but it was a gift. There was a lot of solid empirical research in it which was helpful but it seemed (much like Built to Last) to be fraught by survivorship bias. And I don't discount the strong research, but the results were somewhat expected (that's no ones fault, its just that everyone loves a plot twist).

The entire section devoted to how people in "great" companies tend to be stay friends is what really ended up ejecting the CD however. It almost seemd to imply was almost that if you were only in a "good" company, you'll never make any friends.

My expectations are probably too high. Business vs. technology is largely analogous to art vs. science - and its damn hard to write about art (as compared to science). Its just too subjective.

Becoming a great businessperson is analogous to becoming a great techie. It simply takes some level of innate talent that can't be replaced by hard work (and after you have that, then you still need a lot of hard work). After that however, the tech stuff is arguably easier to document.

Now I definitely might be too hard on books but how I figure it, I only get so many days on this planet (and this planet is the only one I know with books). I really can't afford to waste time on any book I find anything less than insanely great (Influence by Cialdini).
Ah well, onto the next - maybe I'll read some Call of Cthulhu. Or even better, "How to run a business like Cthulu would" - I bet there'd be more than one idea in there.

Doing Wheelies

2007-06-18T23:19:00.000-07:00

In a vain effort to remedy the situation where my friends are starting to call me names like boring, settled, and overall rather linear; I attended a wheelie class this weekend. If that sounds odd, well it is. I don't think there are that many such schools in existence.

It was a one day, 8-hour class and let me tell you, by the end of the day I could have not been more tired.

The instructors definitely knew what they were doing. The bikes were outfitted with a dual-stage limiter. It had settings 1-5 each at a progressively higher angle. Once the limiter was hit, the center cylinder (of the 3 cylinder speed triple) was turned off. So you rose up, hit the limiter, and then the engine lost 1/3rd power usually sending you back down.

After that at level "6" another limiter engaged that hit the back brake. The bar you see on the back (btw, that pic is of Simon my classmate as it was sort of hard getting a pic of myself whilst wheelie-ing and all) is not a hard stop bar, its merely there to engage both limiters.

I flipped a dirtbike a few years back screwing around which always instilled a good deal of respect in me for wheelies. Now the limiter was there to not let me do it again. By the end of the day I was at level 5 with pretty consistent wheelies. I really did go from nothing to finding the balance point in one very tiring day (I can't believe how sore I am today).

If you think this all sounds dangerous, well it can be. While I was standing by the side of the run, one of the students came out of a wheelie and in the process of trying to stop, locked the front brake and washed the front tire. He and the bike hit the ground doing about 50mph. The bike went skidding on its side right off the cement into a field like a hockey puck. The rider tumbled awhile and came to rest with (luckily) just a broken wrist (we were all wearing head-to-toe leather armor plus helmet).

That was an unfortunate cap to the day. Although I do get to add wheelies to my ever-increasing list of possibly interesting but mostly useless skills. :)

Sprint Customer Support

2007-06-07T09:01:00.000-07:00

I've had my share of bad customer support experiences, but this one is special. :)

A few months back I logged onto sprint.com to turn off receiving text messages on my phone. I was simply getting too many spam texts. Not being able to receive friendly texts however eventually turned into a problem. At times, friends would text me and rely on the fact that I received it. Sprint doesn't notify the sender the message isn't delivered. This caused a few annoying instances.

Anyway, I decided I needed to turn texting back on and simply accept the spam (seems like spam would be relatively easy to stop on an SMS network, but then again phone companies also make money on that spam, so maybe they're not all that motivated to do so. Who knows - regardless, I was getting a fair bit).

I went to the website again (now a few months later) and tried to login so I could turn texting back on. Well, as I'm wont to do with websites I dont login to for months at a time, I forgot my password. I cheerfully clicked the "forgot your password?" link which asked for my phone number.

Ok.. I entered my phone number which then gave me a message - "We have sent you your password via text message!".

Um. Hey smarty-head - your database has a bit that says my text messages are turned off. Maybe you could, ya know, CHECK THAT BIT before you go off and send me my password via text message so that I could login with the sole purpose of turning my text messaging back on. (Hey btw... I have a new advertising campaign for you: "Don't have any access to a phone whatsoever but want one? Call us!")

So.... off we goto customer support. I dial their customer support number and funny enough the first thing the automated system does is to ask me is to enter my phone number.

Um. Dear Sprint - this is YOUR phone service. Maybe you should spring for caller ID for yourself and then check the incoming number against your database (you have this database thingie turned on right? Its the big pretty box that says "Oracle" on it) and then ask that given I'm on a Sprint number, maybe thats the number I'm calling about. You never know - it just might work.

From here I deftly navigate their convoluted automated phone tree (which consisted of just pressing 0 a LOT) and sat on hold for about 20 minutes.

Finally, I get a customer support person. She greets me... and then.. with what I perceived as a tint of "this is gonna be good" in her voice, she asks:

"What's your phone number?"

WTF. So.. you're Sprint. Its your line. You'd think you'd have caller ID. If not, You just made me enter my phone number 20 minutes ago (prior to hold) and the first thing the real live person does is ask me again?

If this system was designed to frustrate customers away from using it, its pure user interface art.

I was a Windows Vista user for like 2 minutes.. but not anymore

2007-04-23T09:54:00.000-07:00

So I bought a new laptop yesterday. Try as I mighted, I had to buy Vista along with it. I bought this laptop with the sole purpose of doing work on it (its replacing an older machine that was for that purpose).

What this means is that I wanted decent ram, decent CPU, but I really don't care about graphics performance. That is, I have no worry of ever playing games with this machine. Thus - if I don't need it for games, then I don't need windows either. I considered a Mac but to me Ubuntu is at least, if not more, functional as a mac (you might be different I understand - but for me, this is the truth) - and I get many many more choices for hardware possibilities.

Anyway, like I said, I was forced to buy Vista with no intention of using it. I got the laptop home and thought I might boot-up Vista just to see it before I wiped it clean. As it started up, I got visions of it asking for my personal info and despite the fact that I would not of course actually enter it, it would somehow still get my name, address, and food preferences sent into some database somewhere being tagged and locked in as a forever Vista user slated to have to pay over and over and again and again for.. um.. I dunno.. something that I didn't want but that all locked-in/slated people have to pay for.

Vista got as far as the "Preparing your computer for starting for the first time" message and my paranoia became too intense.

I shutoff the machine. Put in the Ubuntu CD and wiped the drive. Phew. Its really amazing that when I buy a laptop (desktops not as much given I usually build me own) it feels like I don't really own it. After Ubuntu was installed however, the laptop is now mine.

I think I'll leave the Windows Vista sticker on it though. It's pretty and I did pay a lot for it.

Digg!

A Few Book Reviews

2007-04-08T22:55:00.000-07:00

The very last book I completed was the California Driver's handbook. Man, what a snorer. I have to get my CA driver's license this week, so I figured I better know what the speed limit is in a 2-lane alley with a bike-lane on thursdays is. In any case, avoid this book like the plague - its only to be read as an aching reminder that driving is a privilege and the DMV is a perfect example of a system without competition (i.e., its inefficient, broken, and is barely preferable to getting hot pokers stuck in your eyes).

Apart from that, tonite I also finished Perfectly Legal: The Covert Campaign to Rig Our Tax System to Benefit the Super Rich--and CheatEverybody Else which does not disappoint.

On one hand its a basic consideration of what we all know. Want to avoid taxes? Get rich. It does however examine in detail some pretty amazing tax loopholes (and downright scams). From a surprising number of people that simply don't pay because they don't think they should (and the IRS having scant resources to catch them) to companies like Stanley Works and Ingersoll-Rand that try (or succeed) in moving their theoretical corporate headquarters to Bermuda to avoid US taxes.

In the end it's a pretty grotesque look at our tax system. If you're easily made mad, then by the end of this, you'll definitely be mad (if you're not in the top 1% of our country's wage earners, you'll be mad because of how much you pay and they don't. If you are in the top 1%, you'll be mad because you're bound to find some tax loopholes you're not taking advantage of).

In any case, I found myself looking forward to getting back to reading this book every time I had
to put it down.

A few weeks back I got done with a long read of
The Birth of Plenty : How the Prosperity of the Modern World was Created. Its an interesting book in that it basically qualifies as "economic history". A methodical study of why somewhere a hundred or 2 years ago, human civilization went from basic subsistence to spurt of radical productivity. The examination is done on a country-by-country basis and is a pretty great read.

Interestingly, the same author wrote The Four Pillars of Investing : Lessons for Building a Winning Portfolio (which I haven't read.. yet). He seems like he'd be an interesting guy to meet.

Its quite long but wonderfully researched. If economics or history interests you, its worth the time.

At the end of last year I got through about half of A Theory of Everything: An Integral Vision for Business, Politics, Science and Spirituality. It was recommended to me by a member of the board of my Ohio company Preemptive Solutions. Simply said, he's the kind of guy that if he recommends a book, you might just want to check it out.

Anyway, this is not a leisurely saturday afternoon read. Its dense and it makes you think with every section. I plan on getting back to it soon, but Chapter 2 alone was worth the price of admission (after I reread it a time or two).

It lays out a theory for levels of thinking. From the most basic levels concerned with food, water, sex, etc. to the highest levels that only (an estimated) 1-2% of our population functions at. Its really a fascinating way to consider simply how we think.

Oh.. and finally.. I read about half of Now, Discover Your Strengths before I fell into a reading induced coma.

This book purports to be an analysis of how to analyze people and play to their strengths. The one worthwhile message was that we tend to look to improve people's weaknesses (for example, if you are a manager, you might do this to an employee). However, this is misguided - you're better off to play to their strengths. If they're a great coder, let them be that. Encourage it - help it. Don't force them into management (for example).

Thats a fine idea but I found most of the rest of the book arbitrarily contrived. I really hate it when I see a bulleted list presented as fact thats clearly just someone's opinion. Such lists can be added to or deleted from and be just as correct.

In any case, I'm pretty done with that book. If you're interested, you can have my copy.

Notes from my Java Generics talk at SDwest

2007-03-27T10:28:00.000-07:00

Sorry - meant to put these up earlier.

They are Here.

Howto Pass a Silicon Valley Software Engineering Interview

2007-03-22T14:15:00.000-07:00

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