1. Be good. Be very good. Don't be the "front-end guy" or the "back-end guy", or some other "guy". Once you know what you want to build, building software is about five things: algorithms that solve your problem, programming languages that express your algorithms, computer architecture that makes your algorithms run efficiently on real hardware, the practical toolchain, and the management of complexity of real software. So study algorithms, and then graduate algorithms, and then advanced graduate algorithms. Do every challenge problem online. Study programming languages to express those algorithms. You can get away with three: C, Lisp, Haskell. Everything else is crud. Study computer architecture and compilers to see how your programs run efficiently. Learn great tools (Emacs/Vim/Visual Studio/bash/Linux/OS X/Windows whatever - just great ones that you're damn good at). Learn how complexity is managed. Look at lare open source projects, study how they're organized, and contribute patches to understand how small changes can effect a large system.
2. Learn what to build. Once you get really good, your time starts to be more valuable than gold. There will be very few people in the world who are as good (the internet will bias you to think that the world is full of great people - this ain't so, there isn't enough of 'em). You owe it to people and to yourself not to bother with improving something by 1% or 10% because you're wasting time in opportunity cost and could be improving something by 1000%. Make sure what you're building is worth building, and make sure every line of code you write is worth writing, otherwise you will fail. Break the NIH syndrome in yourselves now (all good people have it, phenomenal people that build successful companies broke it in themselves). Learn to infer what people want.
3. If you're that good, you will easily get a $100k job after graduation (probably more by then), and grow to $180k in a few years. That's very, very comfortable. It's not worth busting your ass 16 hours a day to build another CRM tool when you can have a $180k job. So don't start a business to start a business. Start a business to bring a meaningful change in the world. A huge change. A 1000% change. There are lots of hugely successful companies out there that do what's not meaningful to you - ignore them. But do make sure that what's meaningful to you is also meaningful to millions (hopefully billions) of others. You won't get rich writing Lisp compilers.
This is what matters. Most everything else is fluff.
I challenge anyone to name 5 successful entrepreneurs who followed this formula. It sounds to me like a recipe for becoming comfortable with $180K and unwilling to take risks, and it seems very narrowly focused on a small class of highly algorithm-oriented problems.
Another way to look at it is that most successful entrepreneurs follow something similar to this formula. 'Being very good' == professionalism and high standards == domain specific binary search == solving problems in logarithmic time == orders of magnitude more productivity == orders of magnitude more value == ??? profit.
I agree with advice 1 ("Be good. Be very good."). But do you really believe you have to be -that- good to start an online business?
Also, I believe breadth of knowledge is also good (not only depth) - I've studied and worked in networking and most of the parts of the software platform, so when something fails I have a decent idea of where to start looking (I guess you cover that base with "Don't be the "front-end guy" or the "back-end guy"").
And you very likely won't get that knowledge from college - you have to learn it in the "real world" I agree with the other advice here about working in a challenging environment like another startup.
Also, point 2 - "the internet will bias you to think that the world is full of great people - this ain't so", I suspect that it's true as well.
Which brings me to point 3 - I'd do what's more comfortable for you and the way you want to live your life.
What I don't entirely agree is with not being worthwhile to start your own business unless your change is that dramatic.
I know this is a fluff comment, but I would upvote point #3 many more times. I see a big movement with everyone jumping onto the entrepreneurial bandwagon similar to the dot com era of yore. Many ideas are pretty solid, but don't start a business to "get in on a good thing" if you don't have a passion for what you're doing. You might hit a very THIN margin of luck, but chances are more likely that you'll fail. I believe passion drives innovation above all else.
> Start a business to bring a meaningful change in the world. A huge change. A 1000% change.
I know it might be heretical to say this on HN, but establishing and growing the kind of organization that can create this kind of change in the world will require a lot more than just technical and/or academic chops. Ultimately, what you'll need to make a difference in the world is a lot more intangible than that: vision, leadership, ambition, tenacity, etc. My advice would be to focus on society and find a way to "hack" it in a novel way that is mutually beneficial to both your organization and to society as a whole--this is how you can really make a huge change in the world.
I agree with most you said except a small detail: how is C good at expressing algorithms? There are far more expressive languages in the C family. The point of learning C I would argue is to have at least one low level language in your toolbox.
Fundamental algorithms can't be expressed sanely in anything other than C. How the heck do you implement a hash table in perl, for example?
Sure, higher-level languages provide some data structures; but they're not always going to have the internal tradeoffs required to make them a good fit for your problem space. A few weeks ago I had to rewrite malloc (well, technically I added a caching layer in front of it) in order to get a 4x speedup to my code -- you're never going to do that in a language which doesn't even admit that malloc exists.
I'd argue that it teaches you how to express the algorithms in an imperative manner, which most of the world will use. That way, you'll be able to more easily read the code the rest of the world writes.
Or perhaps it's to teach you how poorly some languages express algorithms.
The parent said _understanding_, not writing your own.
To take an example of a web startup (just because the are the most common), here are some question that require understanding the basics of operating systems:
1) "why is my database cache constantly being swapped out to disk when there's enough memory in my machine"
2) "why are the pages taking so slow to load, even though I'm only serving a few hundred hits a second"
3) "what is my webapp doing that's making python/ruby take up 100% of the cpu" (to find this out, you'd likely be using gdb, ltrace and strace which very explicitly require at least a passing familiarity with C and POSIX)
4) "why is there a process showing up in ps/top that I can't kill even with kill -9"
Finally, you certainly have to be a good programmer to start a startup: not the best one, not a "10x programmer", but a good one (irrespective of what sort of applications you write). You can't be a good one without understanding how your programs work.
 That said, I had my hands dirty in Linux source code when debugging an issue while working in (of all places) an email security company.