Take a look at the series of hello-worlds at the end of the Arc tutorial. That's actually where the challenge problem came from. It was just the first hello-world I wrote that did anything.
I had to do half of these to get a CS degree 10 years ago, and I can assure you that the vast majority of my class was not what I would call an A-list hacker.
It doesn't count if you have a professor holding your hand every step of the way and giving you a framework suited to exactly the project you're working on and no other.
Nonetheless, which half do you mean? In my OS class we just worked with a toy MINIX derivative and never got down to anything nearly as nitty-gritty as a bootloader, and the people who didn't drop my compilers class were A-list hackers. I never did any of the others as an undergrad, though I could have and didn't take the class where you build a CPU.
I wrote a compiler (for a Java-like language) that compiled to x86 instructions. The last week, we were writing nontrivial programs in this language, compiling them, linking the result with a GUI library the instructor wrote, and seeing it put graphics on the screen. It was not a required class, but one of a fairly small set of which a certain number (3 of 5?) were required. It was easily both the best and hardest class I took.
I wrote the guts of an ACID database (basically every part of a simple RDBMS except the query language). Again, this particular course was optional, but among the small set which were required.
The OS course, by the time I took it (1999?), was no longer having students write an entire OS, sadly. But we did have to implement several major components. I'm not sure I'd call any component of a real kernel "non-trivial" -- there's no black magic here -- but I did have to deal with many real issues. Required course.
I had to design and implement a CPU (at the gate level) for a pipelined MIPS-like instruction set. This was a required course, and in fact the big weed-out course for the computer science department. The last week, we got to actually put it on an FPGA and let it run real code, which probably would have seemed pretty cool if I had gotten more than 15 hours of sleep that week.
The ones I didn't do:
I took the first half of a graphics course (which involved writing things like rendering loops), but dropped it because it was just too boring. The graphics geeks I lived with ate that stuff up, and they did some amazing things, but I just couldn't get excited about it.
I never did anything with crypto in school. I don't even know if it was offered, but it doesn't really interest me, on a technical level, so I wouldn't have taken it, anyway.
I don't think any of these could be described as "a professor holding your hand". The professors at my school were, overall, notoriously bad. In some classes, there was no point in going to lectures. Even when the lectures were good, they were just about the theory; you still how to derive how to build the sucker yourself. Think "an hour discussing the differences in power between LR/LL/LALR/...; OK, now here's the BNF for a language, write a parser for it by Thursday, bye".
I guess some will take this to mean that it's not worth going to school for computer science. For me, at that age, though, the learning experience was (a) having hard deadlines, and (b) being surrounded by other young people interested in learning the same thing. I might never have written a compiler on my own, though it helped me as a programmer immeasurably.
Hmm, how long is a piece of string. It's a difficult question to answer. Why not ask your peers? If you trust them and they trust you they will be honest and you will learn. If you don't trust them leave.
For fun you can look at http://projecteuler.net/. Project Euler poses a series of problems for you to solve using a language of your choice. Of course you'll need to get your peers to do it as well but the different approaches to each problem can be very revealing. You can learn a lot about your abilities by reading the comments in the forums which are unlocked when you complete a task.
As a side note remember that the power of most programmers is unlocked within a team. Some 'lesser' programmers shine within a team and fail on their own. The reverse is true also. I know many excellent programmers that are near useless inside teams of non-programmers and a few that can't work with anyone.
In the long run, the more important factor is whether you are gaining faster than your peers.
The younger ones often lack perspective and breadth and depth, the older ones often stop learning or dramatically slow down.
If you continually study timeless fundamentals, current technology, as well as industry trends, then over time you will naturally lead tend to lead the pack.
A wiser adult once convinced me that the entire theory of capitalism is based on overpaying you when you're young and underpaying you for the next 40 years...
When it comes to programming, I believe some of the most capable programmers outsource the programming to the junior programmers who are still all about the latest technology/acronym and haven't grokked the underlying fundamental patterns/architectures/commonalities/integration. By the time programmers gain enough experience to see that it's all the same, they might be starting to look at starting their true legacy, a family (not code that lives on)
It's not reasonable to ask to be ranked. The best programmers are those who know there is an answer to every problem. The worst ones are the ones that care about salary, lines of code, and other meaningless crap.
Just remember, the CS field is broad and not every has the same knowledge.
You need to be less subjective if you want a reasonable answer. Metrics are out there for things like salary, number of users, lines of code written (for open source stuff at least), number of appearances on David Letterman..
I find this very amusing. Something about it implying the bold statement that no hacker is lesser than Paul Graham, and then audaciously posting it on Paul Graham's site.
