It’s a good start, but I notice a lack of actual programming languages on that list. This is a very common mistake. A typical CS degree will try to make sure that you have at least basic familiarity with one language, usually Java, and will maybe touch a bit on a few others. You will gain some superpowers if you become familiar with all or most of the following:
A decent scripting language, like Python or Ruby. The usual recommendation is Python, since it has good learning materials and an easy learning curve, and it’s becoming increasingly useful for scientific computing.
A lisp. Reading Structure and Interpretation of Computer Programs will teach you this, and a dizzying variety of other things. It may also help you achieve enlightenment, which is nice. Seriously, read this book.
Something low-level, usually C.
Something super-low-level: an assembly language. You don’t have to be good at writing in it, but you should have basic familiarity with the concepts. Fun fact: if you know C, you can get the compiler to show you the corresponding assembly.
You should take the time to go above-and-beyond in studying data structures, since it’s a really vital subject and most CS graduates’ intuitive understanding of it is inadequate. Reading through an algorithms textbook in earnest is a good way to do this, and the wikipedia pages are almost all surprisingly good.
When you’re learning git, get a GitHub account, and use it for hosting miscellaneous projects. Class projects, side projects, whatever; this will make acquiring git experience easier and more natural.
I’m sure there’s more good advice to give, but none of it is coming to mind right now. Good luck!
Sorry if I wasn’t clear. I intended the list to include only skills that make you a more valuable programmer that aren’t explicitly taught as part of the degree. Two Java courses (one object-oriented) are required as is a Programming Languages class that teaches (at least the basics of) C/C++, Scheme, and Prolog. Also, we must take a Computer Organization course that includes Assembly (although, I’m not sure what kind). Thanks for the advice.
In school you are typically taught making small projects. Make a small algorithm, or a small demonstration that you can display an information in an interactive user interface.
In real life (at least in my experience), the applications are typically big. Not too deep, but very wide. You don’t need complex algorithms; you just have dozens of dialogs, hundreds of variables and input boxes, and must create some structure to prevent all this falling apart (especially when the requirements keep changing while you code). Also you have a lot of supporting functionality in a project (for example: database connection, locking, transactions, user authentification, user roles and permissions, printing, backup, export to pdf, import from excel, etc.). Again, unless you have structure, it falls apart. And you must take good care of many things that may go wrong (such as: if the user’s web browser crashes, so the user cannot explicitly log out of the system, the edited item should not remain locked forever).
To be efficient at this, you also need to know some tools for managing projects. Some of those tools are Java-specific, so your knowledge of Java should include them; they are parts of the Java ecosystem. You should use javadoc syntax to write comments; JUnit to write unit tests; Maven to create and manage projects, some tools to check your code quality, and perhaps even Jenkins for continuous integration. Also the things you already have on your list (HTML, CSS, SQL, git) will be needed.
To understand creating web applications in Java, you should be able to write your own servlet, and perhaps even write your own JSP tag. Then all the frameworks are essentially libraries built on this, so you will be able to learn them as needed.
As an exercise, you could try to write a LessWrong-like forum in Java (with all its functionality; of course use third-party libraries where possible); with javadoc and unit tests. If you can do that, you are 100% ready for the industry (the next important skill you will need is leading a team of people who don’t have all of these skills yet, and then you are ready for the senior position). But that can take a few months of work.
There is another aspect of working on big projects that seems equally important. What you are talking about I’d call “design”, the skill of organizing the code (and more generally, the development process) so that it remains intelligible and easy to teach new tricks as the project grows. It’s the kind of thing reading SICP and writing big things from scratch would teach.
The other skill is “integration”, ability to open up an unfamiliar project that’s too big to understand well in a reasonable time, and figure out enough about it to change what you need, in a way that fits well into the existing system. This requires careful observation, acting against your habits, to conform to local customs, and calibration of the sense of how well you understand something, so that you can judge when you’ve learned just enough to do your thing right, but no less and not much more. Other than on a job, this could be learned by working a bit (not too much on each one, lest you become comfortable) on medium/large open source projects (implementing new features, not just fixing trivial bugs), possibly discarding the results of the first few exercises.
I’ve TAed a class like the Programming Languages class you described. It was half Haskell, half Prolog. By the end of the semester, most of my students were functionally literate in both languages, but I did not get the impression that the students I later encountered in other classes had internalized the functional or logical/declarative paradigms particularly well—e.g., I would expect most of them to struggle with Clojure. I’d strongly recommend following up on that class with SICP, as sketerpot suggested, and maybe broadening your experience with Prolog. In a decade of professional software engineering I’ve only run into a handful of situations where logic programming was the best tool for the job, but knowing how to work in that paradigm made a huge difference, and it’s getting more common.
It’s a good start, but I notice a lack of actual programming languages on that list. This is a very common mistake. A typical CS degree will try to make sure that you have at least basic familiarity with one language, usually Java, and will maybe touch a bit on a few others. You will gain some superpowers if you become familiar with all or most of the following:
A decent scripting language, like Python or Ruby. The usual recommendation is Python, since it has good learning materials and an easy learning curve, and it’s becoming increasingly useful for scientific computing.
A lisp. Reading Structure and Interpretation of Computer Programs will teach you this, and a dizzying variety of other things. It may also help you achieve enlightenment, which is nice. Seriously, read this book.
Something low-level, usually C.
Something super-low-level: an assembly language. You don’t have to be good at writing in it, but you should have basic familiarity with the concepts. Fun fact: if you know C, you can get the compiler to show you the corresponding assembly.
You should take the time to go above-and-beyond in studying data structures, since it’s a really vital subject and most CS graduates’ intuitive understanding of it is inadequate. Reading through an algorithms textbook in earnest is a good way to do this, and the wikipedia pages are almost all surprisingly good.
When you’re learning git, get a GitHub account, and use it for hosting miscellaneous projects. Class projects, side projects, whatever; this will make acquiring git experience easier and more natural.
I’m sure there’s more good advice to give, but none of it is coming to mind right now. Good luck!
Sorry if I wasn’t clear. I intended the list to include only skills that make you a more valuable programmer that aren’t explicitly taught as part of the degree. Two Java courses (one object-oriented) are required as is a Programming Languages class that teaches (at least the basics of) C/C++, Scheme, and Prolog. Also, we must take a Computer Organization course that includes Assembly (although, I’m not sure what kind). Thanks for the advice.
In school you are typically taught making small projects. Make a small algorithm, or a small demonstration that you can display an information in an interactive user interface.
In real life (at least in my experience), the applications are typically big. Not too deep, but very wide. You don’t need complex algorithms; you just have dozens of dialogs, hundreds of variables and input boxes, and must create some structure to prevent all this falling apart (especially when the requirements keep changing while you code). Also you have a lot of supporting functionality in a project (for example: database connection, locking, transactions, user authentification, user roles and permissions, printing, backup, export to pdf, import from excel, etc.). Again, unless you have structure, it falls apart. And you must take good care of many things that may go wrong (such as: if the user’s web browser crashes, so the user cannot explicitly log out of the system, the edited item should not remain locked forever).
To be efficient at this, you also need to know some tools for managing projects. Some of those tools are Java-specific, so your knowledge of Java should include them; they are parts of the Java ecosystem. You should use javadoc syntax to write comments; JUnit to write unit tests; Maven to create and manage projects, some tools to check your code quality, and perhaps even Jenkins for continuous integration. Also the things you already have on your list (HTML, CSS, SQL, git) will be needed.
To understand creating web applications in Java, you should be able to write your own servlet, and perhaps even write your own JSP tag. Then all the frameworks are essentially libraries built on this, so you will be able to learn them as needed.
As an exercise, you could try to write a LessWrong-like forum in Java (with all its functionality; of course use third-party libraries where possible); with javadoc and unit tests. If you can do that, you are 100% ready for the industry (the next important skill you will need is leading a team of people who don’t have all of these skills yet, and then you are ready for the senior position). But that can take a few months of work.
There is another aspect of working on big projects that seems equally important. What you are talking about I’d call “design”, the skill of organizing the code (and more generally, the development process) so that it remains intelligible and easy to teach new tricks as the project grows. It’s the kind of thing reading SICP and writing big things from scratch would teach.
The other skill is “integration”, ability to open up an unfamiliar project that’s too big to understand well in a reasonable time, and figure out enough about it to change what you need, in a way that fits well into the existing system. This requires careful observation, acting against your habits, to conform to local customs, and calibration of the sense of how well you understand something, so that you can judge when you’ve learned just enough to do your thing right, but no less and not much more. Other than on a job, this could be learned by working a bit (not too much on each one, lest you become comfortable) on medium/large open source projects (implementing new features, not just fixing trivial bugs), possibly discarding the results of the first few exercises.
I’ve TAed a class like the Programming Languages class you described. It was half Haskell, half Prolog. By the end of the semester, most of my students were functionally literate in both languages, but I did not get the impression that the students I later encountered in other classes had internalized the functional or logical/declarative paradigms particularly well—e.g., I would expect most of them to struggle with Clojure. I’d strongly recommend following up on that class with SICP, as sketerpot suggested, and maybe broadening your experience with Prolog. In a decade of professional software engineering I’ve only run into a handful of situations where logic programming was the best tool for the job, but knowing how to work in that paradigm made a huge difference, and it’s getting more common.