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?"
Re:Design patterns (Score:5, Interesting)
Self-taught programmers might not know design patterns by name, but they will likely stumble upon the more common ones on their own. When they finally learn about design patterns, they will understand the topic better because they "invented" some of the design patterns themselves. That's how it was for me at least. One day I was explaining something to another programmer, and after my long explanation he just looked at me and said "Oh, so you're using the visitor pattern." I tilted my head, went online, and learned a new name for something I had been using for years.
Re:Algorithms, data structures, systems (Score:3, Interesting)
As a recent CS grad (dec 2008, but that was "school 2 years", "break work in field 2 years", "school 2 years") I can attest to the lack of skill of some of the people who only retain information for the duration of the class they're in. What was even more disturbing was in my graduating class (only 8 of us) the two of us with the most experience: academic, open source, professional full time work in the field were the LAST to get jobs.
I'm Interested in the Opposite View (Score:3, Interesting)
Self-Taught (Score:2, Interesting)
As a self-taught PHP and C# Developer, the biggest trouble has already been outlined as limited exposure to new concepts. The bigger question, however, is how to gain exposure.
#1 - User Groups I personally don't attend user groups because I have 2 jobs, and 2 kids, however, the Ruby community has shown again and again that it works, not just for the new stuff, but for the old stuff. They just overhauled Rails and as long as the community keeps talking, they'll do it again and again to perfection.
#2 - Contracting It's a large assumption, but if you have the time to learn a language, you've got time to find small contracts, and hopefully ones that will introduce you to knew people with difference foci (focuses?). Also, digging unto other people's code helps you think outside of the structures that you taught yourself - you might even get some extra cash. Check out craigs list, elance, etc
#3 - Open Source Not as good for your wallet up front, but if you think you have a unique perspective that is applicable to an existing project, donate some code. Bug fixes are just as valuable as new features.
#4 - Publications I use this in the loosest sense of the word possible. I "camp" PHP.net because there are new functions popping up all the time. Their search database is fairly decent, so when you're thinking like a PHP dev, put a word or two in and see what pops up. MSDN isn't too bad either, but the naming conventions vary, and it's so large that simply search for keywords is a challenge (They have an "OrderedDictionary, but not a UniqueList...?)
#5 - Inspiration (& Perspiration) Nothing develops with out the the will power and simply getting things done. Going back to #3, you can simply start your own project or feature. Lots of things are pluggable these days, and if your desired functionality doesn't exist, don't cry about it - build it! PHP doesn't have events, because events don't make a lot of sense on the Web.... HOWEVER, if you're writing a PHP-JS-AJAX framework, then they make a LOT of sense. Noone says you HAVE to release your code either... managing a repo is a lot of work. The point is to build something, find the pain points, then ask yourself "Is there a better way to do this?" Find the better way, build it, and make your life easier... then share it if you can.
Re:I'm Interested in the Opposite View (Score:3, Interesting)
That's a good question, too.
I'd suggest
a. Debugging techniques (but then I strongly prefer design/language approaches that minimize debugging in the first place)
b. Programming-in-the-large, including (i) program structure; (ii) maintenance/documentation considerations (That's true for programmers who have worked on large, well-run projects.)
c. MAYBE multiple programming languages - As I wrote in another posting on this thread, I will not hire a mono-lingual programmer. Too often people coming out of schools have been exposed to one programming language, the popular language-du-jour. If you've been around long enough you've probably worked in several different languages and seen how each language points you towards a certain set of solutions.
d. Understanding of the non-coding aspects, such as design documentation, etc. Again that's true for people who have worked in well-run shops. The rate of illiteracy among programmers isn't getting any better, and in any project > 5 people you'll spend as much time doing reading, writing, talking, etc, as you will in front of a computer typing in code.
Functional Programming and Complexity Theory (Score:3, Interesting)
You almost certainly already have some grasp of Complexity Theory since it governs why e.g. mergesort is faster than bubblesort. I personally found it a somewhat dull topic but it is probably worth delving into a bit for "self improvement" purposes.
Functional programming is worth playing around with. US universities tend to focus on Lisp, I think. ML and Haskell are often used in the UK and have a very interesting type system (proponents say that it's about the most advanced one out there) that it's also worth being aware of. Haskell is also a lazy language, which is interesting although you're unlikely to encounter it anywhere else! Some of my ML programming course dealt with how to build lazy data structures without explicit language support, which was potentially a useful technique.
Others have mentioned design patterns. I guess it's worth looking at those since even though you might instinctively know some, it's easier in an interview if you can *name* them so they know you know what you're talking about.
Re:DP, Algorithms, OOP A&D, Threading, etc (Score:2, Interesting)
This is an excellent list. I was self-taught from the age of about 12, and thought I was an excellent programmer until I was about 25. Having earned BS and MS degrees in Astronomy and Mathematics, I'd written a fair number of programs, and had a decent command of about 7 languages. Then I went to graduate school for Computer Science. And I found out that my knowledge was SEVERELY lacking, both in breadth and in depth. How much of my missing knowledge was relevant to day-to-day programming tasks? Well, perhaps not surprisingly, not much. However, when I come across some issue where my CS education is useful, it's HUGELY useful, and enables me to tackle a problem in far less time, and most importantly, implement a correct solution. It also lets me know when I need to turn over a portion of a project to a specialist. In other words, I'm now more aware of the things that will become a time sink, and increase uncertainty if I attempt them. This ability to do "project triage" is one of the benefits of a well-rounded CS education.
I think that this is the main reason that you'll hear a lot of people say that a university CS education isn't very useful. For about 98% of the things you work on, it really doesn't make you any better than someone who's self-taught. But that remaining 2%... it can mean the difference between blowing months of time on a crappy solution to a problem, or knowing how to put a good one together in a few days time. So, on the whole, a Uni education can make you a far better programmer, even though you won't necessarily find yourself pulling tricks out of your Uni bag every day.
As an example I'll add my 2 cents about only one of the topics mentioned above: Programming Languages. There are many cases where programmers try to develop a "simple" scripting language for embedding in an application. This is one thing that very few people (even uni-educated) should attempt. Proper language design and parsing is VERY difficult, and there are at least a half-dozen well-designed scripting languages that can be literally dropped in to an application with almost no effort when compared to the complexity of rolling your own. And yet, we see time and time again, people attempting to write one from scratch. One of the worst examples I can think of off the top of my head is LSL (Linden Scripting Language), used in Second Life. It's an absolute nightmare of a language. And yet, it made it into a large-scale product like Second Life.
There ARE many cases where a domain-specific language (DSL) can be incredibly useful, especially when the language does not need to be a general-purpose one. In my experience, it's rare for a programmer (no matter how their skills were gained), to create a good DSL without a strong grasp of at least a dozen programming languages or so. University-educated programmers tend to be a better judge of whether they are up to the task of designing and/or implementing a language(at least, after they've tried their hand at it once or twice).
Re:No, Learn C++ (Score:3, Interesting)
I wanted a multiparadigm language to help me learn different approaches to coding.
And for that, you chose C++? Really?
Not Ruby, not Python, not even Javascript? C++?
learn C++ at an adequate level and then most other computer languages should be easy to comprehend.
Except Lisp. And purely-functional languages, like Haskell. And interesting things like Erlang -- immutable, non-shared memory plus message-passing. And...
Learn one language well, and other languages will be easier to pick up, yes. But calling C++ "multiparadigm" is like calling Java "Object-Oriented". It makes you sound smart, and it even makes sense when you know a little about the subject. Then you learn what the term actually means, and you see a language which actually does that successfully -- Ruby is object-oriented in a way Java can only dream of.