Before the Startup

He does mention that there are certain things you can't do if you start a successful company at a young age, but to me the main point was that when you take on a startup you have to be completely invested, and if you're still in school it will be very hard to find time work on both the company and maintain your grades.

Management consulting probably has more opportunities for gaming the system than startups do, and I concur. However, my friends who work at management consultants, from what I can tell based on anecdotal evidence, mostly perform value adding work for their clients, including performing managerial duties in for fast grown firms that do not have the talent at hand, performing macroeconomic research and factory floor optimization. My friends are mostly of engineering background, though, so that probably affects the sampling quite a bit.

I would rephrase the dichotomy of not being about adding value vs. gaming the system but about creating something new versus optimizing and tinkering with an established system.

As an example all the protagonists in "The art of profitability" (http://www.amazon.com/The-Art-Profitability-Adrian-Slywotzky...), for instance, deal mostly in a similar problem space as described by my friends' professional war stories.

"It is said that one of the highest-level and most awe-inspiring of rationalist skills is Sitting And Thinking About Something For Five Minutes.

The sitting part isn’t that difficult. It’s not even that hard to…how should I put it…apply mental effort at the problem. But that mental effort tends to be spent rehearsing the solutions already thought up, retreading worn paths, ruminating on how difficult the problem is.

Coming up with entirely novel ideas is really, really hard."

In other words, if we set out deliberately to "come up with a startup idea" or (in a completely different context) "plot for a short story" we're likely to fall into the "gaming" trap, that is coming up with what _sounds like_ a great idea and could potentially even convince others, e.g., professors in a "Creative Writing" class or investors that it is one.

I've been applying this same tactic when dealing with "once in a million" (which at -- I hate to use this term, but it's actually a good one -- webscale can easily happen once an hour) Heisenbugs: fire up five processes in gdb (as to force contention around network, disk, and CPU), add a bunch of log statements, pepper the code with random usleep()s, and set assertions or watch/break points in "impossible" places -- as opposed to a more rookie approach of rewriting any suspect code ("let's put a lock around this just to be sure...") and hoping the problem goes away.

Some of my best work and graduate school assignments had started off by being handed an RFC (or a language, or a third party library, or a paper, etc...), asked to become an expert on it, and then implement it (or in the case of a library to re-factor old NIH-y code to use that library, etc...). Learning isn't useful as preparation for something else, but it's extremely rewarding in it of itself.