What Knowledge Gaps Do Self-Taught Programmers Generally Have? 396
BeardedChimp writes "I, like many others here, have learned to program by myself. Starting at a young age and learning through fiddling I have taught myself C++, Java, python, PHP, etc., but what I want to know is what I haven't learned that is important when taught in a traditional computer science curriculum. I have a degree in physics, so I'm not averse to math. What books, websites, or resources would you recommend to fill in the gaps?"
Self-taught too. (Score:4, Informative)
testing and architecting (Score:2, Informative)
testing and architecting (building frameworks) etc.
read your gamma and fowler...
DP, Algorithms, OOP A&D, Threading, etc (Score:5, Informative)
Design Patterns: common "Template" solutions to regularly encountered problems/variations-on-that problem. Be careful when learning these that you don't fall victim to "when you have a hammer, everything is a nail". Also learn the Anti-patterns, wikipedia has a good list of anti-patterns.
Algorithms & Data Structures: Analysis, average running time Big O is most important, but understanding worst-case runtime is important too. Designing algorithms vs knowing when to leverage an existing one.
the C++ standard library provides a great many of these, it has a high efficiency sort (from ), it has good collection data structures (vectors, linked lists, maps, etc)
Objected Oriented Analysis And Design: Knowing when to make something an object, when and how to use inheritance and polymorphism, when to not make something an object. Plain old data objects. separation of responsibility: UI is not logic, logic is not UI.
Threading: proper thread synchronization techniques (mutexs, semaphores, conditions, etc), threading patterns such as Producer-Consumer, Inter-process communication
Automata & Computability: (Deterministic|Nondeterministic) Finite State Machines, Regular Languages, Turing Machines
Programming Languages: LL language parsing & rules authoring.
Computer Architecture: Processor design, pipelining, caching, function calling conventions, etc - how to use this knowledge to write more efficient programs
Algorithms, data structures, systems (Score:3, Informative)
If you know your algorithms and data structures, and have a firm grasp of the architecture of modern computer systems, you'll be way ahead of a depressingly large proportion of people with degrees in CS that come past me in interviews.
The most informative and entertaining book I can recommend on algorithms is Bentley's "Programming Pearls".
All the important stuff (Score:1, Informative)
Transactions and threads. People tend to think of these as boring concepts and therefore don't learn all about them and how they work. An engineer who hasn't internalized these concepts is dangerous.
Re:Algorithms (Score:4, Informative)
Proper code analysis (Score:2, Informative)
IMHO there are two things that I got from school. How to properly analyze code (in terms of processing time, memory usage,
The code quality, design, and ability to apply [insert new hot term of the day] correctly all come from real world experience. And I do think you have to get that experience in a professional setting (I would consider much of the open source world profession, just FYI), hobbyist work just won't let you grow the way you need to.
If you don't know where you've been... (Score:2, Informative)
I've been doing this for a few years and the one gap I'm seeing more and more of doesn't actually have anything to do with programming techniques, "design patterns" or anything else that's hugely technical. All of these things are pretty well-known and accepted by everyone, and you can always be sure that there'll be someone around pushing one or another of them as the be-all and end-all of Programming.
The one gap you might have as a self-taught programmer is in fact in the _history_ of computer science. There's a lot of stuff that has happened and in fact people keep finding and solving the same problems, never realizing that the problems have been encountered and solved many times. (An example that's particularly relevant to me at the moment has to do with extent-based file systems; ext4 has extents and so do a number of new file systems. Great idea, right, particularly for large file systems? Thing is, extent-based file systems have been used at least since the 70s in mainframe operating systems. Odd that it took 40 years to get it into Unix.)
But don't feel bad that your self-teaching has skipped the history of computing. It appears that most university computer science programs neglect that little bit of background as well, in favor of jumping straight into C++ or Java.
Maybe I'm an old fart but that half-semester of history I took back in 1981 made a small but significant improvement in my ability as a software engineer.
Re:O(n^2) (Score:3, Informative)
That kind of thing isn't necessary in most programming. Niche knowledge ftw.
I disagree. Maybe you don't need to understand FFT's in your line of work (I don't), but analyzing algorithms for efficiency is absolutely a real-world skill.
If you don't at least understand these concepts (, then you don't understand why one algorithm is crap in the real world and another algorithm is preferred. If you don't understand why one algorithm is crap and another algorithm is good -- even though both provide the correct results -- then you have no business writing code professionally. This is not just an academic exercise. I have seen programmers (and I'm using the term very, very loosely here) who could not get the concept that nesting for loops -- while conceptually simple -- was an exceptionally poor way to do what they were trying to do. Then they couldn't understand why all our user were complaining that "the network" or "the server" was slow, when in fact, the network and the server were fine; it was the developer's piss-poor code that made a snappy network and bleeding edge hardware appear to be so sluggish.
Re:Gotta disagree. (Score:3, Informative)
Computer Science is math. Many people confuse computer science and programming -- the two are not the same.
A programmer is not necessarily a good Computer Scientist.
A Computer Scientist should always be a good programmer -- it's one of the core skills in CS.
Doing research and writing compilers is not the only thing CS people do.
Knowing and understanding Assembly language can greatly improve the code you generate. That knowledge can be critical to optimizing the algorithms you use in your code, whether you actually code anything in assembly or not.
Re:Algorithms, data structures, systems (Score:1, Informative)
This country is not a meritocracy. The others probably had some pretty sweet connections. It took me 6 months to get a job with a PhD from a top school and a triple major.