Perhaps not truly life-altering, but I’m currently somewhat regretting not having taken a formal course in Computer Science to complement my physics education. The problem with being self-taught isn’t so much that there are gaps, but that you don’t know where the gaps are, and you don’t have the language to discuss (or Google) them easily.
Turning from myself to others, I see many physics graduate students who would benefit vastly from just one introductory formal course in programming—not computer science per se, just basic programming concepts. Flow control, scope, pass-by-name versus pass-by-reference, what’s an object, what’s the difference between a class definition and an object instantiation, what does it mean to call a method on an object. These are all things that it’s possible to pick up by osmosis, especially for people as smart as physics grad students tend to be (although, admittedly, this is not an invariable rule...), but you can flounder quite a bit in the year it takes you to do so. A quarter, even a semester, of organised instruction would save time overall.
Undergraduate formal computer science education isn’t that impressive, there isn’t really anything similar to the mathematics fluency you need to painfully build up when studying physics. Software engineering does have an analogous coding fluency skill you can have, but formal education doesn’t seem to really know how to drill that into you yet.
If you want to patch up a missing CS degree, just go read CLRS for algorithm analysis, SICP for general programming insight and the Cinderella Book for the theory of computation.
Then read K&R, because just about everything is C at the bottom and The C++ Programming Language (make sure to pick the latest C++11 edition), just to see all the insane complexities the pressures of backward compatibility, large-scale program architecture and high-performance programs will have you thinking about in real-world software engineering.
Looking at data structures more algebraically, as abstract types characterized by their introduction and elimination forms is another topic that’s present in some standard CS sequences and can make one a better programmer. This breaks the habit of projecting intended interpretation of the data to its representation in computer memory, giving more freedom to design data structures for sparse data, that don’t look like the data (which is their interpretation), but play its role (for example, binary decision diagrams). This is related to the statement/model distinction in logic, but the point of view of type theory is intuitively closer to programming practice. (SICP goes some of the way in this direction, but not in sufficient detail.)
A standard treatment of (in particular) this aspect of type theory is [Pierce] or [Harper], which would go easier after something like [Girard, Lafont & Taylor]. Related intuitions can be developed by learning a language like Haskell [Lipovaca] and some category theory [Lawvere & Schanuel]. References:
Seconding the type theory recommendation. The formal CS education I had contained almost nothing about this, so it was all independent studying from textbooks for me anyway.
The problem with being self-taught isn’t so much that there are gaps, but that you don’t know where the gaps are, and you don’t have the language to discuss (or Google) them easily.
Not a problem with “self-taught” per se, as hypothetically you could read all of the textbooks covering the respective major (which would be faster and easier than if you were still a student and knew less).
Perhaps not truly life-altering, but I’m currently somewhat regretting not having taken a formal course in Computer Science to complement my physics education. The problem with being self-taught isn’t so much that there are gaps, but that you don’t know where the gaps are, and you don’t have the language to discuss (or Google) them easily.
Turning from myself to others, I see many physics graduate students who would benefit vastly from just one introductory formal course in programming—not computer science per se, just basic programming concepts. Flow control, scope, pass-by-name versus pass-by-reference, what’s an object, what’s the difference between a class definition and an object instantiation, what does it mean to call a method on an object. These are all things that it’s possible to pick up by osmosis, especially for people as smart as physics grad students tend to be (although, admittedly, this is not an invariable rule...), but you can flounder quite a bit in the year it takes you to do so. A quarter, even a semester, of organised instruction would save time overall.
Undergraduate formal computer science education isn’t that impressive, there isn’t really anything similar to the mathematics fluency you need to painfully build up when studying physics. Software engineering does have an analogous coding fluency skill you can have, but formal education doesn’t seem to really know how to drill that into you yet.
If you want to patch up a missing CS degree, just go read CLRS for algorithm analysis, SICP for general programming insight and the Cinderella Book for the theory of computation.
Then read K&R, because just about everything is C at the bottom and The C++ Programming Language (make sure to pick the latest C++11 edition), just to see all the insane complexities the pressures of backward compatibility, large-scale program architecture and high-performance programs will have you thinking about in real-world software engineering.
Looking at data structures more algebraically, as abstract types characterized by their introduction and elimination forms is another topic that’s present in some standard CS sequences and can make one a better programmer. This breaks the habit of projecting intended interpretation of the data to its representation in computer memory, giving more freedom to design data structures for sparse data, that don’t look like the data (which is their interpretation), but play its role (for example, binary decision diagrams). This is related to the statement/model distinction in logic, but the point of view of type theory is intuitively closer to programming practice. (SICP goes some of the way in this direction, but not in sufficient detail.)
A standard treatment of (in particular) this aspect of type theory is [Pierce] or [Harper], which would go easier after something like [Girard, Lafont & Taylor]. Related intuitions can be developed by learning a language like Haskell [Lipovaca] and some category theory [Lawvere & Schanuel]. References:
Benjamin C. Pierce, Types and Programming Languages
Robert Harper, Practical Foundations for Programming Languages
Jean-Yves Girard, Yves Lafont, Paul Taylor, Proofs and Types
Miran Lipovaca, Learn You a Haskell for Great Good!: A Beginner’s Guide
F. William Lawvere, Stephen H. Schanuel, Conceptual Mathematics: A First Introduction to Categories
Seconding the type theory recommendation. The formal CS education I had contained almost nothing about this, so it was all independent studying from textbooks for me anyway.
Not a problem with “self-taught” per se, as hypothetically you could read all of the textbooks covering the respective major (which would be faster and easier than if you were still a student and knew less).