The real test is whether you can discover new questions.
Ok, what the heck is going on in that Arc Challenge? I just can't make any sense of the flow in it.
What programming tasks should you be able to accomplish to be considered an "A" ranked Hacker?
21–26 of 26 posts
Re: What programming tasks should you be able to accomplish to be considered an "A" ranked Hacker?
#22It'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.
Re: What programming tasks should you be able to accomplish to be considered an "A" ranked Hacker?
#23The real test is whether you can discover new questions.
Ok, what the heck is going on in that Arc Challenge? I just can't make any sense of the flow in it.
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.
Re: What programming tasks should you be able to accomplish to be considered an "A" ranked Hacker?
#24Hmm, 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.
Re: What programming tasks should you be able to accomplish to be considered an "A" ranked Hacker?
#25Earlier quoted context omitted.
I'd add: * build a non-trivial and well-performing interpreter
Depending on how loosely you define well-performing, that probably entails my definition of a compiler.
Agreed. But I was thinking more of dealing with the interesting runtime and caching issues that interpreters run into.
You hit neat stuff like call overhead of the base language.
Re: What programming tasks should you be able to accomplish to be considered an "A" ranked Hacker?
#26Earlier quoted context omitted.
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 a…
What I did in college:
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.