What Knowledge Gaps Do Self-Taught Programmers Generally Have?

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?"

Comments

Self-taught too.

[G2GAlone]

Being self taught myself, I think the biggest downside is some of the strategies and standards that are taught in the mainstream curriculum (IE: how to properly use the object-oriented model, etc.). Especially when I first started out, my code may get the job done, but it wasn't the cleanest or best approach. Luckily, I think it will come to you in time if you focus on improving your code.

Algorithms

[dionyziz]

Although in practice most of the time advanced data structures and algorithms are not used, it is useful to study them and implement them yourself at least once. Dijkstra's algorithm, Prim's, Kruskal's, maximum flow, and other basic graph-operating algorithms are a good example.

Re:Algorithms

[ryanvm]

Seconded. As a self taught programmer, classic algorithms are always my weakest link when I do an interview. Unfortunately, it's also the most glaring, since they usually teach that kind of stuff early on in COMP SCI. I had an interview with Amazon a while back and in preparation bought the book "Programming Interviews Exposed". It's a pretty good resource for getting your hands dirty with all the algorithms that a general programmer should know.

Re:Design patterns

[wbren]

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.

DP, Algorithms, OOP A&D, Threading, etc

[LordKazan]

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

Re:DP, Algorithms, OOP A&D, Threading, etc

[CodingHero]

To be fair, I got BS degrees in Computer and Software Engineering, but if we consider only the required courses from both these curriculums, I gained:
- NO education on design patterns
- A very limited understanding of how to apply big O analysis to an algorithm (although I do understand what it represents)
- Almost NO attention to "proper" OO analysis and design. Any knowledge of this I have is from personal experience during school and professionally
- only a cursory look at threading.
- A good understanding of state machines
- Exposure to language construction (via a required course on compilers)
- A good understanding of computer architecture

What one learns in an academic environment is very much dependent on the core curriculum the school has and thus a self-taught programmer may not be at much of a disadvantage at all.

Re:Design patterns

[tgd]

Some people might consider that a good thing ...

Some suggestions

[nicc777]

I was learning and coding on my own steam for about 15+ years. Then I joined the ACM (two years now) and my eyes opened. I am now about 1/3 though a B.Sc in CS (part time) and I'm also following a CPD program at another University. I have also joined the IEEE as I required access to more material for my studies. What I realized was that I should have done it from the start. So my advice is simply this: start to follow some part time programs and get the theory as well. I have learned in the last two odd years a lot on subjects like modelling, quality assurance, frameworks and architectures which I otherwise would not have known. I also found that the quality of my code has greatly improved since I now work in a much more structured way.

Experience helps, but the real killer deal is experience backed by a CS/Eng. degree.

Design and Adaptability

[Temujin_12]

I've found that self-taught programmers can actually be quite productive. However I've noticed (in general) the following deficiencies which I think are both rooted in the fact that the need to memorize seemingly arbitrary facts about a system is inversely proportional to deepness of understanding of that system (see graph):

-Design Patterns (noted earlier by others): There is a tendency of self-taught programmers to follow a design pattern more doggedly than others. This can be tied back to the fact that for the self-taught a particular design pattern represents what programming is to them. They memorize a series of facts that support the design pattern they use rather than understand the nature of a design pattern itself. They tend to have steeper learning curves when presented with new structures and design patterns because using a new design pattern requires the abandonment of the facts they've memorized and starting anew with memorizing a new set of facts.

-Adaptability: Self-taught programmers tend to reach a certain level of comfortableness with technology (ie: languages/libraries/etc.) and attach themselves to it. The thought of using a different language, library, or system is daunting (or even aggressively resisted) since, again, changing requires a new memorization of facts around the technologies (see graph).

Much of what you should learn formally from a CS degree is WHAT a programming language is or WHAT a design pattern is, not merely HOW to program or HOW to use a particular design pattern.

That said, there's nothing stopping a self-taught individual from learning these things on their own. It's just that when you're teaching yourself a trade you, naturally, immediately (and sometimes exclusively) focus on things that allow you to compete on a particular level or with a particular technology. Learning design patterns or what programming is in the abstract doesn't seem to have an immediate payoff (clients aren't going to ask you about those things). But they are skills which allow you to be competitive across technologies or design patterns which is especially important in the rapidly changing world of computers.

Re:O(n^2)

[frosty_tsm]

I'd say you need to learn enough mathematics to get an appreciation for what goes into the discovery of an O(nlog[n]) algorithm -vs- its [naive] O(n^2) counterpart.

This is a gap I've seen with self-taught programmers: they didn't take algorithms classes where you analyze algorithms for efficiency and write complicated algorithms for (mostly) academic problems. Even amongst university-taught programmers, most people see this class as a waste of time. I've taken it twice (undergrad and graduate level) and find it helps me in my job.

Gotta disagree.

[mosel-saar-ruwer]

You could teach people all they need to know about big O and common algorithms in an afternoon.

Sorry, but I gotta call B.S. on that one.

You need YEARS of mathematical training to grok this stuff.

Have you ever tried teaching college level programming to recent American high school graduates?

I have had young adults [some already with bachelor's degrees who were coming back to school to brush up] who couldn't reliably compute anything in Base-16 [hexadecimal].

They need the better part of a decade's worth of intensive mathematics training to get to the point that they could really grok the difference between what goes into a "slow" O(n^2) algorithm and its "fast" O(nlog[n]) counterpart.

And let's face it, lots of people doing basic HTML or VBA [Visual Basic for Applications] probably don't have sufficiently high IQs to make that transition.

And even if they do have sufficiently high IQs, then summoning the self-discipline [not to mention just the spare time] to tackle this stuff is going to require a really formidable application of the will.

Which is not to say that it can't be done, but the odds are definitely stacked against them.

Re:Gotta disagree.

[Korin43]

Intensive math training = Knowing that n^2 grows faster than n * log(n)? You don't even need to understand math for that (Wolfram Alpha or a calculator will tell you). Figuring out if a program/function completes in O(n), O(n^2) or O(c^n) time is something that anyone with a basic understanding of loops and jr high math could do. O(log(n)) or O(nlog(n)) are slightly harder, but that's only because most people don't deal with logs in everyday life.

And one more thing.. what's the big deal about teaching people hexadecimal? What's the purpose? I can do it, but I've never once thought of a reason I'd want to. Isn't the whole point of the compiler that it does that stuff for you?