Agree with a lot of the opinions already stated in this thread, but didn't see this one so I will add it: I find it's pretty important to know the kind of thin

Agree with a lot of the opinions already stated in this thread, but didn't see this one so I will add it: I find it's pretty important to know the kind of thing (what it does, the 1000ft view, the basics of the area that it's attacking) and then the differences between the (generally guaranteed to exist) alternatives/other products that do the exact same thing. Long Example: Databases - You should know what a database is. How have people done databases in the last 50 years? 40? 30? 20? 10? now? (while that seems like a lot of research, it's generally not - as much as some things change, a lot have not changed for a long time in CS). What are the big theories that propel most of the solutions? ( for databases you might find stuff like mmap, b-trees, indexing, hashing) Then, there is the question of what is the difference between Postgres & MySQL? MSSQL & Oracle? RBDMS & NoSQL? RethinkDB/Mongo & Neo4J? I generally find that knowing stuff in those frames is more than enough. Personally, this approach works but I am embarrassed when I have to look up things like "how to list all the tables in mysql" on Google, but I'm starting to think that's not such a big deal. Yes, I don't know every oracle/microsoft/mysql/postgres command, but I think it would be more ridiculous to take the time to try hard to memorize stuff like that, and then completely miss out on the benefits of NoSQL databases, for example. Also -- do tons of side projects.