Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

What Knowledge Gaps Do Self-Taught Programmers Generally Have?

ScuttleMonkey posted more than 4 years ago | from the mind-the-gap dept.

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

cancel ×

396 comments

Self-taught too. (4, Informative)

G2GAlone (1600001) | more than 4 years ago | (#31199298)

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.

O(n^2) (1)

mosel-saar-ruwer (732341) | more than 4 years ago | (#31199670)

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.

The problem is that you need to know just an incredible amount of graduate level mathematics to even get a sense of what the Fourier Transform is all about before you can have any sense of awe at how a Fast Fourier Transform would be an improvement over a [naive] "Slow" Fourier Transform.

Heck, I don't know if you can even get a good feeling for the structure of a fast sorting algorithm without having a really strong grounding in infinite series, and that probably requires at least a couple of semesters of Advanced Calculus.

Re:O(n^2) (0)

Anonymous Coward | more than 4 years ago | (#31200428)

Wow, I wrote business logic for 20 years and all that time I should have know wtf a Fourier Transform was. What the hell are you talking about?

Re:O(n^2) (4, Insightful)

frosty_tsm (933163) | more than 4 years ago | (#31200532)

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:Self-taught too. (1)

lorenzo.boccaccia (1263310) | more than 4 years ago | (#31199688)

two things overlooked are computational complexity and standard algorithms. true, those are seldom used in the real world, but understanding them provides lots of insight when designing bigger systems, even when you're not actually using complex algorithms or calculating the performance of every row of code.

Most of the botched implementation of pagination/lazy loading of data come from the lacking of this knowledge. Most performance problem comes from "stuff A works" and if I need to do a lot of A operation I just put them in a loop, without thinking of what the common part of task A are and how those could be not looped - one example would be to display a table with a drop down for selecting colors, fetching the color list from the database for every row even if it's the same for all of them (ok, this is something everyone could have avoided, but I see lot of similar albeit subtler cases).

also "security" is something that you usually couldn't "pick up as you go" but requires dedicated effort to learn. There are lots of self made "experts" that claims the weirdest thing as hashing the password before sending it to the backend.

Re:Self-taught too. (0)

Anonymous Coward | more than 4 years ago | (#31199852)

uh whats a row of code? Do you mean a line of code? a statement? Your points are very valid though. Especially the one about security. I'm definitely glad I started doing security and counterhack and moved on to programming later on. By the time I even started picking up programming I was pretty familiar with most of the security pitfalls. However, I've certainly fallen victim to bad loops, especially when I was starting. Thank god for unit testing. :)

Re:Self-taught too. (1)

lorenzo.boccaccia (1263310) | more than 4 years ago | (#31199982)

line of code, sorry.

Re:Self-taught too. (1)

al0ha (1262684) | more than 4 years ago | (#31200542)

>> There are lots of self made "experts" that claims the weirdest thing as hashing the password before sending it to the backend. Haha, that reminds me of Yahoo mail a few years back.

testing and architecting (2, Informative)

Anonymous Coward | more than 4 years ago | (#31199300)

testing and architecting (building frameworks) etc.

read your gamma and fowler...

Design patterns (2, Insightful)

metageek (466836) | more than 4 years ago | (#31199310)

design patterns

Re:Design patterns (5, Interesting)

wbren (682133) | more than 4 years ago | (#31199448)

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.

Predating Design Patterns (1)

geek2k5 (882748) | more than 4 years ago | (#31200056)

My initial programming experience predated the Design Pattern concept. At the same time, I knew about pattern language, the concept behind design patterns, because I had heard about the architectural version by Christopher Alexander.

Think of a pattern language as being a conceptual construct that does a specific job, be it an entry way for a house, a menu for an application or the splash page for a web site. Certain activities occur in that 'space' and if you know what those activities are, based on past history, you can effectively design for them. You might even have a set of solutions that you can copy and modify, which can save time and money.

Once the specs have been made, you can build it with the appropriate tools, be they construction materials or bits and bytes.

Thinking about it, I would say that good programmer and analysts were already looking for design patterns long before Design Patterns became formalized.

Re:Predating Design Patterns (1)

david.emery (127135) | more than 4 years ago | (#31200182)

>Thinking about it, I would say that good programmer and analysts were already looking for design patterns long before Design Patterns became formalized.

I agree. A lot of what appears in the Design Patterns book struck me as "obvious - that's how I've always done it". But again coming from the Ada community, the language and the culture encouraged the kind of bigger-than-just-a-subroutine approach that is also codified in Design Patterns.

The other comment I'd make is that people who haven't carefully read the Design Pattern literature, particularly the original "Gang of 4" book, miss the fact that a pattern comes with 'qualifying conditions'. Too many people apply a Design Pattern because they think they have to or it's a good thing, without reading -and reasoning about- the definition of the pattern to see if it's applicable/appropriate. And that behavior is equally true of formally trained and self-trained developers.

Meta-comment: Computer Science/Software Development is very trendy! (and that's not meant as a compliment...)

Re:Design patterns (1)

eastsidephil (691985) | more than 4 years ago | (#31200328)

I agree that design patterns are good to know and they are definitely one of the things that you'll get asked in interviews, however, I think there is a bit of obsession with talking about design patterns themselves and not what's really important which is code quality. In short, if your code is written with good code qualities eg. Testable, loosely coupled, cohesive, open to extension/closed to modification etc, then design patterns will emerge naturally. In day-to-day coding you rarely ever have to implement a design pattern, most places where you need actually need a named design pattern there is already an implementation available, but your code should always have good code qualities. I work with lots of smart people who can talk about design patterns all day, yet often I find myself needing to modify others code, and not only are there no unit tests, (so I don't know if I'm breaking anything), but also there are often a lot of internalized dependencies that make unit testing or refactoring much more difficult than need be.

Re:Design patterns (0)

Anonymous Coward | more than 4 years ago | (#31200606)

The same thing happens to professional programers. Design patterns are also about convention and standardization. By the way, many professional programmers I know were self taught before college/university. Doing a 5000 program by one/two persons is easy. Try to scale that to a groupp of 15 and you have a tottaly diferent beast. Check an old paper called "there is no silver bullet". Enlist yourself in a software company, and you will be amazed by how start the people happen to be, and still: the big/large software seems to advance so slow... who knows?... maybe we need more physicists...

Re:Design patterns (3, Insightful)

tgd (2822) | more than 4 years ago | (#31199508)

Some people might consider that a good thing ...

Re:Design patterns (1)

eonlabs (921625) | more than 4 years ago | (#31199640)

Design patterns are useful, but if you can't arrive at the need for them on your own, and assume that every piece of code written must be fit into the patterns you know of, you overlook some fast and powerful solutions. Granted, there's always a risk of vastly increasing clutter in systems that don't make proper use of design patterns. I agree with the sibling post in that there is value in not knowing them first, but learning them after you've recognized walls that are difficult to tackle.

Re:Design patterns (1, Insightful)

Anonymous Coward | more than 4 years ago | (#31199628)

first design. then design patterns.

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

Algorithms (5, Insightful)

dionyziz (736817) | more than 4 years ago | (#31199314)

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 (1)

paskie (539112) | more than 4 years ago | (#31199746)

Yes, I think if you are self-taught, you are already great at the practical matters (probably including stuff like design patterns), but you might get in trouble when trying to devise effective algorithms and data structures for a particular problem that might not be difficult _technically_, but computionally quite so.

It's important to have a basic concept of time/space complexity (the O-notation) and understand at least couple of basic algorithms (my picks from the whole spectrum would be QuickSort, depth-first/breath-first searches, Dijkstra graph search, Knuth-Morris-Pratt string search, and Minimax/alpha-beta pruning) and data structures (linked lists, basic kinds of hashes, heaps - you are probably familiar with all of those). You should find all of the algorithms above (and their complexity!) obvious and quite trivial to have a good understanding of algorithmization.

Re:Algorithms (3, Informative)

ryanvm (247662) | more than 4 years ago | (#31199812)

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:Algorithms (0)

Anonymous Coward | more than 4 years ago | (#31200070)

Amazon makes data structures and algorithms a big part of their early interview process.

computer architecture (1, Insightful)

Anonymous Coward | more than 4 years ago | (#31199372)

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.

Modeling (1)

Rhaban (987410) | more than 4 years ago | (#31199428)

Creating a good database (or object) model, or code structure is not something trivial and usually self-made programmers are not the best in those fields.

Re:Modeling (1)

tthomas48 (180798) | more than 4 years ago | (#31200054)

I find the same is true of most college educated programmers as well. To a certain extent that's something that has to be learned through experience.

Re:Modeling (1)

Rhaban (987410) | more than 4 years ago | (#31200142)

true.
But (like being taught) experience alone is not always enough. Often being taught something then get (a good amount of) experience with it is the only way to truly understand something.

Re:Modeling (0)

Anonymous Coward | more than 4 years ago | (#31200312)

Man, I hate reading LISP.

Re:Modeling (1)

dubbreak (623656) | more than 4 years ago | (#31200236)

Experience helps, but if you don't have a foundation of theory you are going to start wrong in the first place.

The biggest issue is that the person doing the model knows there is actually a wrong way and that they want to seek the correct way of doing things. Yes there may be many correct solutions (each with their own trade-offs), but there are solutions that are just outright wrong. In my opinion not doing the wrong thing takes education and interest. Experience helps you choose the correct solution with the best trade-offs for your intended application the first time around.

Re:Modeling (1)

tthomas48 (180798) | more than 4 years ago | (#31200260)

Maybe CS degrees have change since most of the people I work with got their degrees, but I don't think they got much in the way of data modeling theory.

Learn C (1)

meridiangod (940552) | more than 4 years ago | (#31199446)

As a self-taught programmer myself, learning standard C has given me a whole new outlook on how I code. I also thought it would be good to know where a lot of the more modern languages were derived from.

What physics do I need to know? (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#31199450)

I'm a self-taught user of physics. I can throw and catch a ball, accelerate my car, and I use electronics on a regular basis. I have a degree in Computer Science, so I'm not afraid of math and I have decades of experience as a programmer. What websites or resources should I visit in order to build myself a backyard nuclear reactor to power my hobbiest space shuttle?

college? (0)

Anonymous Coward | more than 4 years ago | (#31199458)

go to college sir, or at least try to follow the courses they have. before i went to college, i did embedded development(fiddled with my phone, did some java apps), php, perl , linux scripting, high level C++, complicated algorithms ( acm, ace.delos.com, etc.. ), but college really opened it up to me.

Working with others.. (2, Insightful)

QuantumRiff (120817) | more than 4 years ago | (#31199480)

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:Working with others.. (1)

schlesinm (934723) | more than 4 years ago | (#31199716)

Yes. The biggest problem I have in my job is that people who are working on the same system and don't talk to each other. I end up with duplicated functions and systems that don't work together. Communication is essential on any multi-person project and probably more important than coding skills.

Re:Working with others.. (1)

Sloppy (14984) | more than 4 years ago | (#31200190)

I'd have to totally disagree on that. What you're talking about, is something (almost) any programmer is going to learn, simply in the course of having a job. It doesn't even have to be a programming job.

DP, Algorithms, OOP A&D, Threading, etc (5, Informative)

LordKazan (558383) | more than 4 years ago | (#31199482)

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 (1)

mcd7756 (628070) | more than 4 years ago | (#31199694)

Excellent summary. My bachelor's was in Physics and after several years of coding I got my Master's in compsci. Understanding state machines (via Automata & Computability) helped with untangling complicated conditions and process. The analysis of data structures was also a big deal. I blush at some of the algorithms I wrote.

The only thing I would add to the list above is mathematical logic as applied to programming. While I'm not wild about program correctness techniques, preconditions and postconditions are useful for deciding if a piece of code is correct and has applications in unit testing among others.

Basically, what I got from my CompSci degree is that I finally really understood what I was doing. It made getting the degree a series of aha! moments.

Re:DP, Algorithms, OOP A&D, Threading, etc (1)

spirality (188417) | more than 4 years ago | (#31199796)

Yeah, these are the things that simply "programming" won't teach you. Not that you couldn't learn these things yourself.

As a practicing software engineer, I think my limited knowledge of computer architecture has proven quite valuable over the years.

Also agreed on theory. Having the ability to identify NP Complete problems is useful.

I would add the following to your list:

Basic Operating System Design, although you do encompass that in some of your other categories - threading, architecture

Functional Programming: Scheme, LISP, ML, etc... Most people who are "just programmers" don't learn such languages and thus don't typically think functionally, which can be useful when solving some problems. Sadly many computer science programs don't even teach this.

Math Generally: calculus, linear algebra, statistics, combinatorics, logic

Re:DP, Algorithms, OOP A&D, Threading, etc (0)

Anonymous Coward | more than 4 years ago | (#31199864)

I would agree with most of it except for the design patterns. In my earlier workplace I had a horrible time rewriting ("refactoring") codes left by the former "Software Architect" who sprinkled design pattern wonders all over his Java codes.

The classes were all abstract! Without methods! For 3 or 4 layers! All without methods!

For your information I am an algorithms major, PhD, and consider myself a theoretical computer scientist. Our kinds don't get along with those "Software Architects". I would appreciate it if you don't list our methods with "Design Patterns".

Finite State Machines (0)

Anonymous Coward | more than 4 years ago | (#31199996)

I'll second Finite State Machines.

More times than I can count, I've drawn a finite state machine on paper and gone on to implement it in a high level language. Though I feel awfully old fashioned when I do it, they're great for parsing stuff and handling incoming data streams. The results are typically high performance and bullet proof.

Re:DP, Algorithms, OOP A&D, Threading, etc (3, Insightful)

CodingHero (1545185) | more than 4 years ago | (#31200134)

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:DP, Algorithms, OOP A&D, Threading, etc (1)

ubersoldat2k7 (1557119) | more than 4 years ago | (#31200224)

I might add to this list: Recursion.

Purple Monkey (0)

Anonymous Coward | more than 4 years ago | (#31199538)

you can be a self taught coder.

but to be a Software Developer you need to study for years, and build upon it with experience.

like people before me said, design patterns, modelling, and algorithms.

I've worked with both, and you can tell.

Everything (0)

Anonymous Coward | more than 4 years ago | (#31199556)

Theory and practice of software development and computer science, plus whatever isn't covered by what i already mentioned.

A job (0)

Anonymous Coward | more than 4 years ago | (#31199558)

I've learned more in the right job than from any book or course.

Some suggestions (5, Insightful)

nicc777 (614519) | more than 4 years ago | (#31199566)

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.

Algorithms, data structures, systems (2, Informative)

ColonelPanic (138077) | more than 4 years ago | (#31199572)

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

Re:Algorithms, data structures, systems (2, Interesting)

LordKazan (558383) | more than 4 years ago | (#31199636)

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.

Re:Algorithms, data structures, systems (1)

dubbreak (623656) | more than 4 years ago | (#31200556)

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.

That is a great argument for cooperative studies. At the school I attended engineering students were forced to do "full coop" (4 terms of actually working in something related to their field). That wasn't a requirement for CS (despite being in the same faculty). I ended up doing a partial coop (2+ semesters) because I saw the value in it. I found that course work was significantly easier when I had some real world experience I could apply coursework to. Ideas stuck because I could immediately think of real world uses. Best part was I had a gov't contract job right out of university (the gov't agency I worked for during a coop term wanted to keep me on).

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.

How well do you interview? How are your communication skills? You may be a leg up experience wise, however you have to be able to express that in an interview and show you have the ability to clearly express yourself in day-to-day business. I was involved in hiring of some jr type positions and experience was not our first concern, ability to communicate well was. Experience can be gained on the job, and if they did well in school they will pick up the technical skills as needed, however communication skills aren't picked up as easily. If we found someone that did well in their technical writing courses, had a well prepared resume and conducted themselves well in an interview then experience was just the icing on the cake.

If you find a good cake you can always ice it yourself. Crappy cake is crappy cake regardless of how much icing is on top.

Know....ledge? (0)

Anonymous Coward | more than 4 years ago | (#31199630)

I've been programming Visual Basic for years!

Software engineering (1)

m.alessandrini (1587467) | more than 4 years ago | (#31199662)

Good software engineering practices (this is my personal experience). This is a problem when managing middle-to-large projects.

Practice practice practice... (1)

xkrebstarx (1703372) | more than 4 years ago | (#31199664)

What did you miss in school... practice. A student's full time job, for 4 years, is to practice CS technique and theory. That's it. Mystery solved.

All the important stuff (1, Informative)

Anonymous Coward | more than 4 years ago | (#31199686)

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.

I'm Interested in the Opposite View (2, Interesting)

moore.dustin (942289) | more than 4 years ago | (#31199704)

What gaps do schooled programmers have that self-taught programmers don't? While a self-taught programmer might go about getting the job done differently, I can almost always count on him to get it done. Programmers coming out of school often still have a horrible worth ethic, especially when compared to their self taught peers. Granted, I have a very limited experience, so I wouldn't cast that judgment over all, but I would be curious to here what others think.

Re:I'm Interested in the Opposite View (2, Insightful)

RationalRoot (746945) | more than 4 years ago | (#31200024)

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

bdwlangm (1436151) | more than 4 years ago | (#31200510)

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

Not at my school either, typically 50% is a pass, and you need an average of 65+ in required courses to stay in the program.

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

Because it's unnecessary for the small projects you do in school and is orthogonal to the concepts they're teaching you typically. Also, it's very easy to pick up on your own.

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.

+1 Insightful

Re:I'm Interested in the Opposite View (2, Interesting)

david.emery (127135) | more than 4 years ago | (#31200068)

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.

Re:I'm Interested in the Opposite View (1)

SurgeryByNumbers (726928) | more than 4 years ago | (#31200110)

In my experience, the culture shock for new grads wears off in about 6 months to a year. Either they get with the program and start doing the work real-world right or they find a way to disappear into a giant corporate environment. Those that get with the program quickly become more valuable than self-taught programmers who don't understand the fundamentals well.

Maintenance programming (2, Insightful)

geek2k5 (882748) | more than 4 years ago | (#31200206)

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

BadKneeDad (1749298) | more than 4 years ago | (#31200372)

In my experience, it is a gut feeling of how to get something done. CS majors tend to design for days while the self taught tends to get it done, tested and moves on to the next thing. This can be a problem with large code bases; although the CS major can also stumble here as well.

A balance between the two is nice!

Organisation, Algorithms (0)

Anonymous Coward | more than 4 years ago | (#31199722)

I think my biggest problem with being a self-taught programmer, is not really knowing how to organise code into physical files so that it makes sense, and when is it a good time to commit ones code to version control, and should one branch to do this or do it on the main branch.

I guess I'm also lacking some of the standard algorithms, as a self taught programmer I started out by coding to solve some real world problem I had rather than some contrived exercises involving how to code the basic algorithms such as linked lists, stacked based recursion and recursive algorithms

If you want to learn some compuational theory.... (1)

spottedkangaroo (451692) | more than 4 years ago | (#31199768)

I highly recommend Lewis' Elemtns of the Theory of Computation. Garey's Computers and Intractability seems to get quoted a lot as well. I'm not sure how important this stuff is in every day computing, but if you want to learn computability, these two cover everything.

Re:If you want to learn some compuational theory.. (1)

AlgorithMan (937244) | more than 4 years ago | (#31200430)

"Computers and Intractability" is more like a list of problem-reductions among NP-complete problems + references.
If you want to write "Problem XYZ is NP-complete", it is a good book to quote, but it's not at all a book, that teaches you anything...

Big-O. No, not *that* big O. (1)

hobb0001 (989441) | more than 4 years ago | (#31199790)

I went to college to get a comp-sci degree after I already had several years of experience in the real world. The one thing that I took away from that education that I had not stumbled upon naturally was Big-O notation. Specifically, how it describes the time and space efficiency of different data structures and algorithms. It really comes in handy when trying to optimize. There have been several where I had become focused on optimizing the crap out of an inner loop, only to realize that if I switched to a different data structure I'd get much faster O(log n) performance.

Other than that, many people only experience low-level C and assembly programming while at school. But you mention that you have C++ experience, so you're probably already well familiar with segfaults and buffer overflows.

Lastly, Structure and Interpretation of Computer Programs (SICP) is a great read. The levels of recursion and abstraction that it employs will often blow your mind. Sadly, I can't use that kind of coding in the real world because I have to write "maintainable" code and most corporate programmers don't want to have their mind blown.

Re:Big-O. No, not *that* big O. (0)

Anonymous Coward | more than 4 years ago | (#31200264)

These days Python and Java are more common that low-level code.

Use Google to fill the gap (1)

somejeff (825047) | more than 4 years ago | (#31199842)

IMO, those who are not self-taught (and spent months in some "History of the Abacus" class) can search the Interweb for code samples and tinker around. One day, they'll fill the gap and catch up to us.

algorithms, code design, proper use of objects (1)

Satis (769614) | more than 4 years ago | (#31199850)

I am/was self taught as well, mostly web-based to start with... PHP, then javascript, then C# over many years and up to using OO in all three. A year ago I started taking c++ classes in college and I can say I picked up a few very helpful things.

1. C++ gave me a look into pointers and how stuff runs at a lower level than any of the other languages.
2. Object use. I used objects before, but I didn't leverage them quite as heavily as I could have, including inheritance and polymorphism. What I learned in C++ has greatly affected how I code in PHP and C#.
3. One of my C++ classes was about efficiency in algorithms... so I learned a bunch about how stuff is done deep down and how to write efficient code. Very helpful for some of the stuff I do in PHP and javascript when working with large data sets.
4. Code design is a big one... before, I just put all my methods into a single class and called them there. The class ended up being more of a repository for functions and data than a real class. Now I have a better grasp of breaking stuff into parts and either creating child classes or whatever is appropriate.

It's still a learning process. I'm only on my 4th c++ class and haven't even taken the data structure class yet, but I've learned a tremendous amount, even in just the first intro to c++ class. My suggestion... take at least intro to c++ at a community college.. you'll probably be surprised how much you'll learn. As an added bonus, being familiar with programming makes getting an A a breeze, so you can concentrate on actually writing decent code and learning stuff.

Proper code analysis (2, Informative)

smbell (974184) | more than 4 years ago | (#31199868)

I have a CS degree from a major university. I have to disagree with most of the comments I've seen so far. Things like design patterns, proper object modeling, even advanced data structures and algorithms can be picked up on your own with a bit of effort as you need them, and experience building real production used software is the key to hone those skills.

IMHO there are two things that I got from school. How to properly analyze code (in terms of processing time, memory usage, ...) so that I could accurately predict how it would behave under different conditions (especially when some of those conditions can't easily be tested). And an introduction to a large swath of computer science terms and facets, so that years later something comes up and I have a faint understanding of where to start looking.

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.

Re:Proper code analysis (1)

SurgeryByNumbers (726928) | more than 4 years ago | (#31200158)

I have a CS degree from a major university. I have to disagree with most of the comments I've seen so far. Things like design patterns, proper object modeling, even advanced data structures and algorithms can be picked up on your own with a bit of effort as you need them, and experience building real production used software is the key to hone those skills.

The "with a bit of effort" portion is key, and from what I've seen more people will not go back and fill in the gaps in their skills (or at least well). Industry experience is also very valuable, but will rarely cover the same ground as someone with a formal education and a couple years experience.

If you don't know where you've been... (2, Informative)

fmayhar (413222) | more than 4 years ago | (#31199902)

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.

Algoritms (0)

Anonymous Coward | more than 4 years ago | (#31199904)

Ability to estimate memory and computing power consumed by different algorithms. Or maybe you learned it too. But most self-taught programmers I met just learned syntax.

Design and Adaptability (3, Insightful)

Temujin_12 (832986) | more than 4 years ago | (#31199914)

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.

more than just code (1)

Sbones (1344935) | more than 4 years ago | (#31199920)

Memory allocation and management. Design patterns. Data structures. Search and Big O calculations.

Physic Majors/Programmers Unite! (1)

ViViDboarder (1473973) | more than 4 years ago | (#31199922)

I just wanted to shout out to a fellow Physics major programmer.

I did happen to get a CS minor so I did get a chance to dabble in Big O, Algorithms and Datastructures. While you probably won't miss them normally you may run into a situation where you'll be wondering how you can do something faster or better and these would be your answers.

ComSci is mostly about how to approach problems (1)

thaig (415462) | more than 4 years ago | (#31199934)

So it's not as much about the gaps in your knowledge as a gap in the way you think about things. the way you make simple models and use them to reason about basic properties of any system that you are proposing to build. You can get the general outline logically correct before you try to make the details perfect.

Having said that, the subjects that opened my mind were:

Functional languages - make you think differently. You realise that there is another way and maybe you realise when and why you'd choose it.

Complexity is the most obvious thing that I find non-CS people don't understand. They optimize rather than choosing a good algorithm. Understanding various algorithms and how they scale (even why) is very useful in all work that I did later on.

Automata - finite state machines, non -deterministic finite state machines etc etc. This has always helped me to think about very complicated bits of logic in real programs.

Security - I remember learning a notation that helped you calculate how much information you had given away to someone else in a communication. It helped you to analyse a protocol to see if you were exposing information that could be useful to an attacker before you had created adequate trust. This was awesome and it made me think a lot about how insecure everything really is and how you need many layers and grades of security because some are bound to be penetrated.

Architecture - we studied the MIPS architecture i enough detail to feel that we really knew what happened inside a CPU to a very fine level of detail. This was probably an illusion but it was still eye opening and is the basis of so many decisions that I make nowadays that it's frightening. Nothing direct - it's all background but it is immensely useful.

Persistent databases - made me impatient with Relational DBs and it's one reason why I never want to write another line of SQL or use a Relational DB ever again.

Cheers,

Tim

Re:ComSci is mostly about how to approach problems (1)

OakDragon (885217) | more than 4 years ago | (#31200534)

Persistent databases - made me impatient with Relational DBs and it's one reason why I never want to write another line of SQL or use a Relational DB ever again.

Please forgive my ignorance - I searched quickly on Google, but only found things about "persistent database connections" - what is a persistent database?

Size Matters (1)

Dark_Matter88 (1150591) | more than 4 years ago | (#31199952)

My problem wasnt with any part of the languages' syntax, it was more with the size of projects. Just looking at an even relatively small project filled me with dread

Self-Taught (2, Interesting)

LCValentine (982220) | more than 4 years ago | (#31199956)

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.

Great question! - a list from my experience (1)

david.emery (127135) | more than 4 years ago | (#31199990)

I'm about 3/4 self-taught, I had some CS courses in college (before there was even a CS minor in the school) and a couple of grad school courses (which I can't say I got all that much from.)

But here's my list, based on what I've experienced over the last 30 years:

      analysis of algorithms, "Big O" and similar things. If you've read a basic data structures book, you -might have- seen this stuff. But it's really important theory to understand. I'd rate this as the #1 gap; people who don't have this knowledge have a real hard time reasoning about or discussing performance, etc.

    AI - not an interest of mine, so I've never bothered to learn it. But that's a big hole in my own knowledge. That includes knowledge representation, reasoning systems, etc.

    multiple programming paradigms - In this case I'm "OK", I've learned and applied several different programming languages (most of which are not popular/politically correct these days...) I've said I'd never hire a mono-lingual programmer, and that's because learning different languages has given me other ways to look at problems. (See http://en.wikipedia.org/wiki/Sapir-whorf [wikipedia.org] - which applies to programming languages as much as natural languages!)

    numeric analysis - That's one of 2 post-grad courses I took where I actually learned a lot, and it seems that numeric analysis is somewhat of a dying art. But a lot of what we do is still 'calculating', so this is important to know.

    concurrency - Here I'm personally in good shape because it is an interest, and I've done a lot of work in Ada which provides a very strong concurrent programming model. But things like race conditions, deadlock, consensus algorithms, etc. are growing in importance due to multi-core CPUs. Nancy Lynch's "Distributed Algorithms" is The Book to read here, too bad it's so expensive (http://www.amazon.com/Distributed-Algorithms-Kaufmann-Management-Systems/dp/1558603484)

    compiler theory - it's worth knowing how language processing tools work, and with compiler theory (parsers, etc), I'd add knowledge of machine languages. If you ever have to go down to assembly language to find a compiler optimization bug (something I've had to so several times - ain't fun), you MUST know this stuff.

    optimization/operations research mathematics - I'm not sure how much this gets taught in CS departments, but I was fortunate enough to get -2- Operations Research courses as a math major (at 2 different schools...) Understanding linear programming, integer programming (things change when you can only deal in whole numbers), PERT/CPM, etc, has proven to be valuable for both hard-core programming and for systems design (and even project management.) I'd also add graph theory to this list, a lot of problems I've worked on are graph problems (they show up in compiler construction, too...)

    I've learned -a lot- just by reading other people's code, too. Remember, a program is written once, but read many times during its lifetime. Reading code gives you both an appreciation for how others attack a problem, and the need to make your own code more understandable. This is where the Open Source movement has been a Godsend. (I'll note in passing the Ada community was very good about sharing source code back in the '80s when this wasn't as popular as it is today.)

Finally, a "meta-comment": Although my formal education in CS itself was weak, I've invested a lot in learning on my own. I'm sure my professors would argue they taught me how to learn, and there's some truth to that. But not everyone will snuggle up to a textbook on graph theory on a snowy winter night :-)

Usability studies (0)

Anonymous Coward | more than 4 years ago | (#31200004)

This is a must for programmers - And soooo few know how to do it. It's all fine and dandy that you can find your way around the interface that you designed, but you need to realize that not everyone thinks like you. I was fortunate enough to take a course in it while studying, and I think I was one out of a handful that didn't say "This is useless" and in some cases people were even outright hostile to the idea of usability. It applies not only to UIs, but also to APIs and code, too. Usability is about how you grease your work so it runs smoothly for everyone, not just you. In the case of coders it lets them become fluid in your API easier.

What I look for when I hire (1)

jjhplus9 (654212) | more than 4 years ago | (#31200034)

As well as a broad range of basic skills, there are a couple of Comp. Sci. skills that I like to see, and without these I tend to be more cautious: - Compiler Construction - Formal Methods - Parallel Programming These broad heading are the general indicator of what I am looking for, I think they give the kind of depth that you will come back to again and again in a career. So I look at what options my prospective employee has taken in their Comp. Sci. Degree. If I see optional courses taken that fall into the categories above, they go to the top of the list. If they have instead taken lots of multimedia, web or softer options instead I will be more cautious (unless of course I am looking for these particular skills)

Goto (1)

gmuslera (3436) | more than 4 years ago | (#31200102)

Was fun even 15 years ago to see Pascal programs full of goto loops, from people that learnt plain basic by themselves and then "upgraded" to a more serious language. The very thinking of how is the flow of a program, independant from the language used, was wrong because that "programmer" never understood some basic programming concepts. Programming has evolved with time, and chances for doing it all wrong because missing or not fully understood key concepts are bigger now.

Depends... (0)

Anonymous Coward | more than 4 years ago | (#31200104)

Depends on how you're self taught. School teaches you primarily from books. Self taught people, most of the time, learn things from books. The difference is that self taught people don't get the benefit from the great teachers with years of knowledge and wisdom. They also don't have to deal with idiotic teachers who don't even understand what they're teaching (and YES, they DO exist even at the masters level of instruction).

You haven't learned... (1)

kungfugleek (1314949) | more than 4 years ago | (#31200108)

cynicism, hopelessness, futility, frustration, despair, indignation, indentured servitude, the gut wrenching emptiness that hits when a project you've poured your heart and soul into gets canned right when it's almost ready to release just because the ceo read some article about how everything should be done in some new sexy framework...

Things I found usefull (1)

utnapistim (931738) | more than 4 years ago | (#31200140)

Here are some things I found usefull in university:

- study of algorithms (big-O notation with case studies on sorting algorithms); This one completely changed the way I view program efficiency

- formal languages / compiler theory (grammars and parsing have never been the same for me since). This is something you will look at when you write any low-level parsing/validation: XML, functional / expression editors and even program parameters parsing in some cases.

- language classes (this was not the actual name of the course and I don't remember what it was actually), but we went through query languages (SQL), unstructured languages (BASIC), procedural and functional (C, pascal), OOP (CPP, java) and declarative (prolog). Prolog was something that made me see differently how the language changes the way you think about programming.

All that said, the academical medium has never been accused of being very practical minded, and I learned at least as much in working in programming as I learned in university. Don't dismiss one in favor of the other as each will show you things the other simply doesn't.

Learn by example (1)

subanark (937286) | more than 4 years ago | (#31200152)

I find that many self-taught programmers learn by example. They copy a bit of code here, and modify it to suit their needs. The problem with this is they often do not understand why the code segments work the way they do. For example, I see a lot of Java programmers with the misconception that the 'import' statement is equivalent to C's #include statement (rather than the using statement). They know that if I 'import java.util.*' I can use the classes in the java.util package. Instead what they should say is: I can write the short form of classes in java.util.

For this same reason, I find a lot of beginner programmers confused on instance methods vs static or global methods. As Java does not have global methods, the simpler to understand static methods require an additional keyword to use. Many Java programmers will start out with applets, where the starting point is an instance method, and then try to transition to applications where the main method is static and wonder why they can't call instance methods from their main method.

Passion (1)

N0t4v41l4bl3 (1677348) | more than 4 years ago | (#31200160)

Self-taught = passionate = "talent" not teachable in class I know who I'd rather hire

Fundamental CS, algorithms etc. (1)

eastsidephil (691985) | more than 4 years ago | (#31200194)

Self taught also, Mechanical Engineer by training. I've found my biggest gap to be fundamental CS stuff, I'm currently working my way through a book on algorithms: http://www.amazon.com/Introduction-Algorithms-Third-Thomas-Cormen/dp/0262033844/ref=sr_1_1?ie=UTF8&s=books&qid=1266595707&sr=8-1 [amazon.com] While the practical implications of knowing this stuff is limited, it's always good to have a deeper understanding, and it will help if you're ever in an interview with hard core CS types.

physicicts and code... (0)

Anonymous Coward | more than 4 years ago | (#31200212)

Wel many maths and physics people cross over to become programmers. Especialy in firms that work in a mathamatical of physical feild.

I have worked in a mining software firm that did this and can offer some insight. I have also taught tertiary students so I know roughly where the imprtant gaps are.

Firstly in terms of code quality.
-you may lack of expose to maintaining software and be acusted to math using single letter variables. The absolute importance of descriptive variable names for any thing not self explanitory (i, x, y) is often lost.
Other code quality issues like use of comments ect have not been forced in by experince.

Remember always that you are probably going to code complicated things on a subject matter that the rest of the programming staff only have a general knolede in. But it falls to the rest of the staff to maintain and debug your code. You must write all physics code with that in mind.

I found that a lot of code writend by non-programmer expers is very costly and difficult to maintain.

You may find that some pure comp sci stuff is missing. Can you do predicate calculus? work in lisp, train neural networks, optimise evolutionary algorithems, optimise code using a vast array of obscure data structurs.
Probably not. But most of the industry jobs don't require this.

Important knowledge gaps may also exist in code related sujects. Database design and SQL are a artform that self taught programmers will generaly not tough because it is not interesting. But it is important in the workforce.

Beyond that a tertiary education only deos so much. Time spent programming and industry experience will improve your code more than reading a few undergraduate level books.
The true strengh up a comp sci degre is often the amount of free time students have t practice programming.

Hope this helps.

Grads don't necessarily grasp abstract concepts (0)

Anonymous Coward | more than 4 years ago | (#31200232)

I can't say that people graduating have a good grasp of the more abstract concepts of programing like polymorphism and recursion but they do get taught along with some of the more difficult data structures (B*Tree or Graphs). I could also point to standards documentation forms like UML relational diagrams, timing diagrams etc.

It really comes down to experience with real code for most things.

Functional Programming and Complexity Theory (2, Interesting)

Lemming Mark (849014) | more than 4 years ago | (#31200248)

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.

Programming vs. Computer Science (1)

BadKneeDad (1749298) | more than 4 years ago | (#31200300)

As someone who was in exactly your position a few years back I might have some insight into this.

First off I have a BS in physics with a minor in Mathematics and my physics department was HEAVY into computational physics. My grad work is in a different field altogether! As an undergrad, we coded for almost every class after our intro courses but we were never required to take programming classes; most all of us were self taught. I had started to code on a Commodore as kid (self taught) so I was comfortable with programming, but programming is not computer science!

A few years back I took a position at a software company as a developer (still there, still coding, although now a little more senior) and my tech lead was a computer scientist (versus a programmer or engineer). I had the good fortune to work with him for a few years and I quickly learned that programming is not computer science.

As others have pointed out, you may have missed good OOP design (talked a lot about but rarely done), design patterns and big O notation (I had a numerical analysis course in college so I had seen that before); these are easy to learn as needed (e.g. The Art of Computer Programming, Google, etc.). Perhaps the biggest thing I had to learn was the whole development process; customer requirements, functional specifications, technical specifications, QA cycle, learning to do what is needed versus what is requested, defensive coding, future anticipation coding, etc. Another thing that you might be missing is a fundamental understanding of why a computer does what it does (e.g. why you shouldn’t compare two doubles for equality, race conditions in parallel work, etc). Again, my physics program was computationally heavy so I covered some of this but your history may be different.

I’d say that should cover what you’d find you’re missing (for your first 2-3 years as a professional at least). I might add to this the fact you under estimate how little new code you actually get to write; meetings, documents, technical support, design and maintenance take up a lot of your time (both low level and senior developers).

I think the biggest help was coming to terms with the famous quote “Computer science is no more about computers than astronomy is about telescopes.” (Edsger Dijkstra).

Find a mentor (1)

azadrozny (576352) | more than 4 years ago | (#31200402)

Don't overlook the knowledge to be gained by working with someone who's already been there. Try to find someone who does (or did) the same kind of programming that you do and open a dialog with them. Swapping war stories with someone who has 10 or 15 years more experience can help you decide what kind of things you still need to learn, and what direction you want your career to take.

Project management, no doubt. (0)

Anonymous Coward | more than 4 years ago | (#31200412)

As you, I am a self-taught programmer. I started at young age with a ZX Spectrum 48K, and after finishing high school, I had the good luck to have an opportunity to work at a software house as a programmer. I know now that what I knew about programming at that time was really close to nothing. Currently, I "write code" for a living as a freelance professional (though what I actually "sell" is always an end product or service to meet specific needs).
What I learned through the years by experience, is that the practice of project management is crucial when writing code and has an enormous impact on the end product's quality and meeting deadlines. The fact that a person has developed the habit of looking at a project (no matter how small) from a top level perspective makes him or her make better decisions when writing code or designing models.
Getting the work done and well done, in time and within the budget is always all that matters. That's why I believe that PM is the most important discipline for any programmer, much more than being highly specialized in a specific technology or area. It gives the individual the ability to see the whole, articulate better with other collaborators, understand the ramifications of his decisions and the purposiveness of his work.

Algorithm Analysis (1)

zimage (6623) | more than 4 years ago | (#31200448)

One of the biggest ones I've seen is that self-taught programmers tend to not think about algorithm efficiency. Learn how to determine the big-O of your functions and learn how to code more scalable algorithms.

http://en.wikipedia.org/wiki/Algorithm_analysis [wikipedia.org]
http://en.wikipedia.org/wiki/Big_O_notation [wikipedia.org]

Lack of Broadness (1)

Sloppy (14984) | more than 4 years ago | (#31200460)

IMHO it's not going to be specific gap; the gap is going to be quantitative. Formally taught programmers will have fewer of them, because they're "forced" to work on stuff that doesn't interest them or otherwise wouldn't ever come up in their projects (or doesn't appear to them, to come up in their projects). You can be self-taught and have a shitload of professional experience, and yet that experience can be very narrow, whereas a CS graduate is going to have most of the bases covered.

So it's not so much a matter of self-taught people not knowing design patterns or algorithm complexity analysis; it's that they're just generally less likely to know them, and even less likely to know both. That's why I think a lot of peoples' suggestions here will ring true at first, except that for any of them you're also going to realize there are a lot of counter-examples, where self-taught programmer x actually does know about complexity analysis. But keep adding and adding to the list, and you'll see that the CS guys know almost all of it, and the self-taught ones know less of it. It's not this item or this item; it's the count.

Multiple axis (0)

Anonymous Coward | more than 4 years ago | (#31200524)

There is a confounding variable in this which is the level of expertise needed for a particular job. A programmer doesn't need a degree. Someone that just writes code doesn't need advanced knowledge. Developers need some experience and knowledge. Software Engineers need a higher level of experience and knowledge. Even more so for Software Architects. In essence, the self taught programmer isn't missing anything. They know what they need to know. The self taught Software Architect is a whole other story. At this last level, it's important to be able to envision how you want a whole system to work, how others might want it to work, figure out which algorithms are important, what qualities it should possess, which patterns and anti-patterns are the solutions toward your goals, be able to re-envision an entire sub system and how it works to best fit your goals as various test implementations fail, how to combine problems to find a more universal solution, how to break down a problem to define the various different pieces of what you're dealing with, etc.

This all assumes the knowledge of Patterns, Anti-patterns, Algorithms, Data structures, OO, Threading, Computability, Automata, Language design, Usability, Business & Risk Management, and computer architecture (etc, etc) to have in your tool set to solve the problems of designing and coding a system. Gaining the knowledge of this tool set is very hard without formal training. The ability to think logically about these problems is also enhanced by the knowledge and experience of having to think about these things.

foundations and attitude (1)

plcurechax (247883) | more than 4 years ago | (#31200568)

In my experience the biggest problems are caused by self-taught programmers who lack the humility to realize that computer science and computing a large field, in which they are not domain experts of all of it. Seriously, I'm saying this not to be an insult, but as a plea for self-taught programmers to take their blinders off, and admit to themselves there is a lot of knowledge about computer science and computing (or IT), which has a rich if relatively short history. The ones who get pass the chip-on-their-shoulder defense often become very good to great programmers. The ones who don't tend to become isolated, confrontational, unable to handle constructive feedback or criticism, and tend to be poor team players.

The other big weakness they can have, is they seem more apt to have problem with NIH-syndrome (not invented here). Anything they didn't do or create is crap. Again this seems to be a self-defense mechanism gone astray.

If these two psychological factors are dealt with, the technical knowledge gaps are in comparison trivial to deal with.

In your case, exposure to higher education including post secondary mathematics, helps with the building the experience of abstract thinking which is a excellent trait or training for programmers, to deal with programming in both the concrete and abstract terms.

A programmer who knows and understands the fundamentals of computer science, including data structures, algorithms, number systems, boolean logic, at least a basic understanding of computer architecture in my experience tends to be more flexible and adaptable to change in computing / IT in general as well as able to less stressful to change development environments including languages. Structure and Interpretation of Computer Programs [mit.edu] , Structured Computer Organization [pearsonhighered.com] , and Introduction to Algorithms [mit.edu] are excellent resources for any self-taught programmer looking to fill gaps in the knowledge.

Also professional computing / IT society memberships might be worth considering (especially if your employer will pick up the tab), for example the ACM [acm.org] , and the IEEE Computer Society [computer.org] . Both have a bent towards academia, but they largely due to the self-interest of authors in academia to publish (for their own career success), as opposed to a conscience focus away from the "real-world" programming in the trenches.

For any new professional programmer, texts like The Pragmatic Programmer, Code Complete, Peopleware, and The Mythical Man-Month are strongly recommended reading matieral.

Grammar (1)

michaelmalak (91262) | more than 4 years ago | (#31200576)

By getting a college degree, you are ensuring a literacy level of at least what would have been a seventh-grade education 30 years ago. With just a high school diploma, one's literacy level would only be at about a third grade level 30 years ago.

Computer programming is of little value without the ability to communicate.

I have to hire college graduates to change diapers at the school I run -- to ensure that when they do speak to the children, they do so with correct grammar.

Database design; low-level system architecture (1)

cduffy (652) | more than 4 years ago | (#31200582)

Of my four years of formal education, two classes stand out:

Database design - If you don't know the formal procedure for database normalization, you shouldn't be designing a schema -- not because you'll necessarily use that procedure, but because you know the factors to take into consideration.

System architecture - I think the one most useful class I ever took was the one that stopped the CPU from being a black box. I had an old-school professor, and he went deep -- we started off with digital logic, Karnaugh maps and the like, and by our final could draw the extra data paths needed to be able to implement a new instruction on a MIPS chip.

...and then there are the opportunities one gets access to as a result of having been at school; much of what I know I learned at my internship (being one of the few userspace developers in MontaVista Software's sea of Linux kernel programmers around the tail end of the boom), not an opportunity I'd have acquired on my own.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...