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

Design patterns

[metageek]

design patterns

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.

computer architecture

[Anonymous Coward]

Knowing exactly how it works, and I mean down to the falling/trailing edge of the voltage change.
Though most 'proper' trained developers have these days the same problem, especially if they never had to learn any assembler.

Working with others..

[QuantumRiff]

No, I'm not being a smart ass.

Others have slightly different styles and conventions, and ways of solving problems. Working on something like a large open source project could teach you about working on a team, where one person can't "own" a whole part of a program. (And cleaning up others code will greatly help you learn about documenting and formatting your own code.) One good team assignment we got, Each person work on a part of a program. Away from computers, we had to, on a whiteboard or whatever, decide inputs and outputs, etc between parts, then code separately. Grade on that assignment was how well the program behaved when the teacher, in front of the class, compiled the separate parts, and ran it for the first time combined.

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 [acm.org] (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 [ieee.org] 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.

Re:Design patterns

[Anonymous Coward]

first design. then design patterns.

though truth be told, this is a problem of most university taught programmers also.

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 [typepad.com]):

-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:I'm Interested in the Opposite View

[RationalRoot]

1) in the real world 40% is not a pass

2) why don't many school even mention source code control?

3) error handling is not an exercise left to the reader, it needs to be structured, organised, and it really helps if you know what you are trying to achieve with the error handling.

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.

Maintenance programming

[geek2k5]

I'd say that formally taught programmers may not have much experience with maintenance programming, especially with legacy systems that have been running for years. They are used to 'blank sheet' programming assignments that allow them to control the entire project from start to finish. They don't have to deal with code that has been modified dozens of times over the years, often without much documentation.

I got my professional start in programming doing maintenance programming under the supervision of a senior programmer who had spent years working with the systems as they evolved. While I had done some programming in college, all 'blank sheet' stuff, doing maintenance programming was much more educational. You had to make sure that things were done right, otherwise you could cause big, real world problems.

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.

Re:testing and architecting

[sohp]

Testing and thinking like a QA person [amazon.com] -- there are great resources out there for how to write tests that really have a chance to find and exercise bugs, it requires a knowing a bit about the most common programming errors.

Anything not specifically related to churning out "working code:
* proper use of source control
* how to debug effectively and debugging without leaning on the debugger as a crutch, e.g. the "binary search" strategy
* choosing the right tools for performance analysis and improvement
* how to read and understand existing code [amazon.com] and where to make the changes you need to make
* how to prepare for and conduct a code review
* writing a technical memo [amazon.com] or as-built document for a program or key part of a program.

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:Design patterns

[es330td]

This has been my experience as well. Though I don't have a CS degree, I had enough formal programming work as an Engineering major to understand how to do it mostly right. When I was lead Internet developer for a computer sales company I ran into a large number of developers who excelled at finding things online that could do part of their overall goal and then massaging the outputs to be able to string them together. Yes, the solutions worked but looking at the code reminded me of a car built by collecting parts from every manufacturer and forcing them to work together with a bunch of adapter kits.

The worst problem with these solutions is that they are virtually unchangeable. The code from each has been so massaged to feed output to the next piece that all flexibility to extend or change is lost. Asking the "developer" to change his solution is effectively asking for a complete rewrite.

Re:Gotta disagree.

[mopower70]

Wow. With teachers like you out there, I'm surprised anyone ever learns anything. You denigrate an entire generation of students as well as programmers of 2 languages, then justify it by boasting that it took you YEARS to learn something most of us picked up in a semester or two?

I'm not saying someone couldn't learn from someone like you, 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?

Re:I'm Interested in the Opposite View

[SoftwareArtist]

My experience is that the best predictor of programming ability (among professional programmers) is whether someone learned to program before college. The best programmers are the people who were introduced to programming when they were 10 and fell in love with it, not the people who got to college, decided CS seemed like a good career path, and so took an intro programming class. If you love doing something, you'll learn to do it well, and if you just see it as a job, you likely won't. In fact, the biggest problem with many CS majors is that they think they know how to program well, not realizing that computer science and software engineering are actually very different subjects.

That said, self taught programmers definitely have holes they need to fill. Lots of other people have said this already but I'll add yet another vote for it: algorithms and data structures. Get a good book on them. Learn them. This is bread and butter stuff that a professional programmer really needs to understand, and if you haven't studied it, you probably don't realize just how much you don't know.

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

[CodeBuster]

I have BS in Information and Computer Science and I must say that my experience was remarkably similar to the parent's. One problem, IMHO, is that the major is called "computer science" when it should really be called "computational science" instead. People assume that the degree is all about computers and their use but this is a misnomer. It is more correct to say that "computer science" is a specialized study of mathematics as it relates to computation and its complexity with some practical high level computer engineering concepts thrown into the bargain; computers are merely the tools that we use to investigate the theories in practice. Almost everything that I actually use in my day to day software engineering jobs was learned after graduation through working. IMHO, It would do a better service, both to students and industry, if universities would break up the curriculum so that software engineering, "computer science", and computer engineering were more clearly distinct majors. There would be commonalities of course, particularly in the lower division courses, but right now too many students go into "computer science" without really understanding what they are getting themselves into before they have almost enough courses to minor.

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

[metaforest]

I cut my teeth on Z-80(Sinclair Zx-80/81) and 6502 when I was 11. I am only now working towards my first BS and your earlier comments about the %2 gap (more like 10% for me) are quite salient. Though at my age I am not going to go for CS. I am going for business admin and project management, as I think this is an area I can best apply my experience with new training.

I don't disagree with the conclusion on LSL: That is LSL is fail. I do think that the intern who designed and implemented LSL did an admirable job considering LL had no idea what users would do with SL. They also needed to keep the execution environment for scripts light-weight, and memory constrained. It does quite well in that regard. I regularly see 4-8K scripts running in a Sim, with only a few % lag over an empty sim. On the other hand, I have seen what happens when some asshat figures out how to get a few hundred scripts to make a sim useless, without attacking the physics engine. Giving the general public execution privileges on a service like SL is not an easy problem to solve. In that context maybe LSL isn't all that bad for what it DOES do.

The issues with manipulating Non-Phys prims are actually related to the way the Havok physics engine handles them, not LSL. Those issues would exist no matter what language were driving the property inputs.

It does need to be replaced. Rebuilding the language on the MONO VM was the first major step in eventually supporting a broad range of languages; possibly even allowing 3rd party compilers.

----

Funny you should mention Lua... I am currently in the process of modifying Lua to run on PIC32MX series micro-controllers. The intent is to provide a development environment for these amazing controllers that is easier for an enterprising 11 year-old to get their head around than embedded C or raw assembly.