What programming tasks should you be able to accomplish to be considered an "A" ranked Hacker?
I'd like to know where I rank against my peers. How can you figure out if you're at the top, middle, or bottom of your field?
* Write a compiler of any kind (native code, bytecode, HLL-to-HLL, whatever).
* Write an ACID storage engine.
* Write a trivial OS, including the bootloader.
* Write any non-trivial component of a real OS kernel.
* Design a CPU or a microcontroller.
* Write a rendering loop for a 3D game.
* Design a secure cryptosystem out of existing cryptographic primitives.
I give you an A- if you can do one of these, and an A+ if you can do two or more.
* build a non-trivial and well-performing interpreter
You hit neat stuff like call overhead of the base language.
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.
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.
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)
Those are a few good questions.
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.
If that's not apparent to you, then perhaps you need to find some better peers. :)
Just remember, the CS field is broad and not every has the same knowledge.
Greater Hacker: Richard Stallman.
Lesser Hacker: Paul Graham.