What Knowledge Gaps Do Self-Taught Programmers Generally Have?

BeardedChimp writes "I, like many others here, have learned to program by myself. Starting at a young age and learning through fiddling I have taught myself C++, Java, python, PHP, etc., but what I want to know is what I haven't learned that is important when taught in a traditional computer science curriculum. I have a degree in physics, so I'm not averse to math. What books, websites, or resources would you recommend to fill in the gaps?"

Comments

Self-taught too.

[G2GAlone]

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

Re:Self-taught too.

[Anonymous Coward]

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.

[al0ha]

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

Re:Self-taught too.

[drtsystems]

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.

Completely agreed. I'm getting my degree right now in Computer Engineering and being a self-taught programmer, I am finding the programming classes teach a lot in terms of best practices, and how to use the OO model well. I'm sure you could learn these kinds of things yourself, but for me, when I am doing something for myself, I tend to just skip all the "stupid steps" like commenting, etc. and just hack together something that works. It takes discipline to force yourself to do the boring steps while self-teaching.

Re:Self-taught too.

[phantomfive]

The thing self-taught programmers really miss is the core of computer science, which is computational theory. A lot of them pick up parts of complexity theory because it is so useful (and some parts are intuitively obvious), but most miss computability theory because you can get through your day without it.

On the other hand, it is what Dijkstra is referring to when he says "Computers have nothing to do with computer science." It discusses what kinds of problems can be solved and what kind can never be solved, and what kinds of computers can be used to solve them. Fascinating, I think.

Re:Self-taught too.

[Anonymous Coward]

The socialist creed: From each, according to his success. To each, according to his laziness. ~Me

Re:Self-taught too.

[EricTheO]

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.

(i.e. : how to properly use the object-oriented model, etc.). ------ There fixed it for you. I wouldn't want the Anti-Anything -Microsoft /.'s attacking you for mentioning IE. ;-P

Re:Self-taught too.

[Pictish Prince]

The thing self-taught programmers really miss is the core of computer science, which is computational theory. A lot of them pick up parts of complexity theory because it is so useful (and some parts are intuitively obvious), but most miss computability theory because you can get through your day without it. On the other hand, it is what Dijkstra is referring to when he says "Computers have nothing to do with computer science." It discusses what kinds of problems can be solved and what kind can never be solved, and what kinds of computers can be used to solve them. Fascinating, I think.

I guess I'm really atypical. I'm self-taught, but I have read and thought about computability theory a lot (and I've read Goedel Escher Bach :))

Re:Self-taught too.

[Anonymous Coward]

I think the fastest route to learning good design (OO or otherwise) is simultaneously reading up on good design, while struggling through maintaining a pile of someone else's code---nothing drives the point of good design home like trying to figure out someone's crap design.

I think the academic curricula are of value, but especially for the formal things: classic algorithms and algorithm analysis, theory of computation, the construction and nature of programming languages. That is, teaching you how to do certain things *at all*. Learning to do things *better* needs practice, not school.

Re:Self-taught too.

[Anonymous Coward]

1) Complexity - Making programs efficient
  2) Algorithms - Library of problem solving. They love to re-invent the wheel.
  3) Logic (beyond && || and !)
  4) Object oriented programing - vs. Object Based
  5) Functional Programming - i.e. they think dynamic languages do magic
  6) Information Theory - Making data efficent
  7) Concurrency - Juggling many balls up in the air at the same time

Best memorable moment was when someone reinvented the stack in Java. I think it was called ObjectPile

testing and architecting

[Anonymous Coward]

testing and architecting (building frameworks) etc.

read your gamma and fowler...

Re:testing and architecting

[ThePhilips]

testing and architecting (building frameworks) etc.

Ironically, I have seen more self-taught architects. What I think reflects the fact that the architects with academic background tend to over-architect and over-design.

To testing, I would confirm that. At least in my experience, many self-taught developers have the attitude that their code works perfectly.

On my list the biggest gap is actually the little things. Most books and references often concentrate on answering the "how" part of question, but the much harder part of question "why" often goes unanswered. That leads to the effect that self-taught specialists tend to have more "it works that way" dark places in their code they do not understand why it actually works.

Re:testing and architecting

[sohp]

Testing and thinking like a QA person -- 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 and where to make the changes you need to make
* how to prepare for and conduct a code review
* writing a technical memo or as-built document for a program or key part of a program.

Re:testing and architecting

[sarlos]

Amen to that. One of the best things I pulled from my undergrad Comp Sci work was an appreciation for how different parts of the system interact, and how things work on the metal. Many self-taught programmers (my brother is especially at fault for this!) just care that the code works, as others have said, but when it doesn't, they don't necessarily have the tools to figure out why. As a very basic example, knowing the ramifications of only one process/thread being able to use a network adapter at a time is something I take for granted, but which cost my self-taught brothers weeks of performance debugging.

Design patterns

[metageek]

design patterns

Re:Design patterns

[wbren]

Self-taught programmers might not know design patterns by name, but they will likely stumble upon the more common ones on their own. When they finally learn about design patterns, they will understand the topic better because they "invented" some of the design patterns themselves. That's how it was for me at least. One day I was explaining something to another programmer, and after my long explanation he just looked at me and said "Oh, so you're using the visitor pattern." I tilted my head, went online, and learned a new name for something I had been using for years.

Re:Design patterns

[tgd]

Some people might consider that a good thing ...

Re:Design patterns

[Anonymous Coward]

first design. then design patterns.

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

Re:Design patterns

[eonlabs]

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

[eastsidephil]

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

[Anonymous Coward]

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

[Corporate Drone]

In my experience, though, (and I got out of Corporate I.T. about 3 years ago), is that self-taught programmers don't learn formal techniques; instead, they cobble stuff together until it "works". Then, since they built it from scratch, they get all defensive when you attempt to talk about more efficient techniques, etc.

Maybe I've just had bad experiences, but it was my experience that the folks who shouted the loudest had the code that sucked the hardest. (Now, on the other hand, another poster had it right: kids right out of school had little or no experience taking a project to successful completion, but they eventually tended to get the hang of it, since (putatively) they already had the background and just had to pick up the work ethic on-the-job. Lots harder to have the work ethic and try to pick up the theoretical background.)

In the context of wbren's remark, though, I thought I'd just say that, maybe he created something that worked like the visitor pattern, but without having the background to know how it works, etc, I wouldn't be so sure that there wasn't some sort of Rube Goldberg contraption under the hood -- as a black box, it "does" the visitor pattern, but when looked into, (and taking my (biased) experiences into account), there'd be some seriously crufty code that begged to be re-written under the hood...

Re:Design patterns

[Anonymous Coward]

Design patterns shouldn't be taught directly...

it should be taught in reverse...

first you find a problem and try to solve it... than you compare the solution to a known pattern.. just to label your work

Re:Design patterns

[Machtyn]

While working on a small project, I was figuring out the problems and solutions to "databasing" in text files. (avoiding collisions, indexing, etc.) And, yes, when I finally took a database class, those topics were much easier. Then I felt rather pleased with myself for figuring out the issues correctly.

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

[s2theg]

Study up on information systems theory, business process analysis and the like. You're software is only as good as your understanding of the problem.

Re:Design patterns

[ElmoGonzo]

I re-invented Proxy and Composite but I did it before GOF published DP

Re:Design patterns

[AnObfuscator]

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.

This has been my experience as well. Finally, a good friend of mine handed me the "gang of four" design patterns text, and it has been invaluable, both in coding and in interviewing. :) http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612

Re:Design patterns

[Anonymous Coward]

A self-taught programmer probably won't learn that multi-methods are more efficient than visitor patterns.

Re:Design patterns

[Anonymous Coward]

Some people might consider that a good thing ...

Hear! Hear!

Nothing like giving someone the design pattern of a hammer. Every damn thing looks like a nail after that.

Re:Design patterns

[Anonymous Coward]

So far everyone has forgotten the benefit of increased 'poon' factor when you leave the house whilst getting educated. I'm just saying.

Re:Design patterns

[psetzer]

I wouldn't put it in terms of a specific poster given that I haven't seen their code to judge it in the first place and one of the points of GoF is that the patterns are really just techniques that get reinvented over and over and over by people to solve common broad classes of problems. For a lot of programmers, learning big-O notation was really just formalizing an intuition we've had about the speed of nested loops. Education gave us a firmer grasp of what it really means as well as a vocabulary to express it to others.

However I've noticed that there's a contingent of self-taught programmers who learn some Turing complete subset of a procedural language plus some amusing anecdotes about systems programming from over 30 years ago and have therefore attained the status of Programming God. They're the only ones able to see through the perfumed lies of all those college educated frauds with their "event handlers" and "callbacks" and who understand the timeless elegance of a 50,000 line while(1) loop. In short they're so incompetent it hurts and they can't even tell it due to their inability to comprehend just how bad they are.

Re:Design patterns

[Volguus Zildrohar]

self-taught programmers don't learn formal techniques; instead, they cobble stuff together until it "works". Then, since they built it from scratch, they get all defensive when you attempt to talk about more efficient techniques, etc.

As a self-taught programmer currently attending University to work on a BSc, I can say that:

a) This is pretty close how I programmed when I started (between the ages of 6 and 10, using BASIC on micros).
b) This is still how at least half of my fellow students program now, even though the theory is that Uni will teach them differently (and make no mistake, these people WILL graduate)
c) I know of professionals with degrees and years of experience who still appear to work this way. No-one holds up their work as an example to others, but they exist and are still employed.

Re:Design patterns

[kairu]

I have to agree. I am a self taught php programmer for almost 10 years. When I went in for a programming job interview, the employer (who was a programmer turned middle-management) asked me about OOP structures and algorithyms. I really didnt know what to say because I wanted to show off my experiance, but I was a little embarrassed about my lack-of-textbook-knowledge. Self taught programmers all have unique skills and experiences, but I think the thing that all of them lack (including me) is formal and enterprise-level programming structures (for example, programming for others instead of programming for yourself). The self taught programmers may not have the prettiest code, but "gosh darn it, it works" (most of the time). I am all for learning code practices and structures through a classroom environment, but only IF the teachers are teaching CURRENT languages and practices in a way that the novice programmers can "invent" their own methods, then learn to apply what they already know to a solidified structure. Its just like learning a new language (like Japanese). If you're not emersed in it, or just study the book examples, you're not really learning. Its only when you can discover what you're doing and learn where and how to apply it instead of just following the examples that you can truly understand and apply what you know to future situations.

Re:Design patterns

[macs4all]

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.

You DO realize, of course, that to a large extent, that is EXACTLY how cars ARE engineered, right?

You take a starter from Nippondenso, brake calipers from TRW, tires from Firestone, etc, and "force them to work together".

That's what engineering in the REAL (as opposed to academic) world is all about.

Just because your experience includes mostly Posers, doesn't make it a universal truth.

The plural form of "anecdote" is not "data".

What it sounds like to me (not looking at the actual code), is that the Poser/Coder didn't know how to properly factor "granularity" and "modularity" in their overall design. Such an error can make an unmodifiable, unmaintainable mess out of even 100% custom-built code.

It isn't "reusing" stuff that is a bad idea (who wants to write a JPEG decoder, or a WiFi or TCP/IP stack from scratch?), and in fact is a very good way (often the only way) to meet cost and time targets. It just sounds like the devs. you happen to have worked with were substituting "search engine skills" for actual programming chops.

Re:Design patterns

[BikeHelmet]

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.

Pretty much the same for me - although I mostly code as a hobby.

I was trying to help a friend taking CS with some C# project. It was taking about 35 seconds to run, and I couldn't make heads nor tales out of it. I asked him what he wanted to do, several times, and he finally explained what his goal was. 10 mins later I sent him back some working code that did the task in about 20 miliseconds. (timer limitation)

He looked at the code and said it worked great - but it didn't really fit what he was supposed to do according to his instructions. I didn't understand, so he sent me his assignment. I couldn't make heads nor tales out of that - completely foreign terminology - so I wished him luck with whatever it meant. :P

I think I gained the skills necessary for that when I toyed around with a 24bit pallette system. I can't even remember why I wanted to manipulate a 24bit pallette, but I got it to the point where I could do millions of colour and index manipulations per second - in java. At that point it was fast enough that I considered it a success, so then I figured out how to compress it to roughly 1/8th the memory usage. (Guess)

What's it called? I have no clue! It's my fast low-mem 24bit pallette thingy! I can just imagine trying to explain that to an employer, or fellow programmer. :P

Re:Design patterns

[Pictish Prince]

design patterns

I have to agree with that a little. One of the main hurdles in my learning Cocoa was model-view-controller program design

Re:Design patterns

[aralin]

You came with your glass full.

Re:Design patterns

[Volguus Zildrohar]

Yeah, but it's ok, I had a sock handy.

Algorithms

[dionyziz]

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

Re:Algorithms

[paskie]

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

[ryanvm]

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

Re:Algorithms

[Anonymous Coward]

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

Re:Algorithms

[Anonymous Coward]

I've done all of this stuff. Art major >waves
I've implemented Djikstra's with weighted points along with a threshold setting which used the weights, in a 3d graph, using C first then converting it to a stored procedure. My ISP wouldn't let me compile :-/. It was instantaneously fast up to a certain number of points, then it slowed down really fast as the permutations rose astronomically. I dealt with this by subividing the space into sectors and defining border points. Learning stuff like graph theory and the algorithms to deal with it is a hobby of mine. Fascinating stuff. I do agree that while I don't use it directly in business logic programming, the optimization strategies I learn do come into play quite often when dealing with large datasets or datasets where I need to calc a lot of permutations.

Math and algorithms are good for you, even if you aren't a 3d game, or industrial/military software developer, mkay?

Re:Algorithms

[Anonymous Coward]

Every non-trivial program I've done has benefited from the use of Duff's device.

Re:Algorithms

[gangien]

I always have problems with interviews.. i might have to check it out.

Re:Algorithms

[Anonymous Coward]

Curiously, i've never needed to know any algos in interviews ... It's been more like practical hands-on experience that's mattered.

I'm self taught obviously, yet i tend to do the highest quality code on the office, or any of the projects i get my hands on, and i do code even for the goverment, and military.

Maybe, i'm just not Joe Average, but i've seen being self taught is a huge advantage. I know maintainable code, and i understand the business principles behind every project, and accordingly can adjust the coding style to fit the project in question. For example, for a tiny project i wouldn't bother with OO, or pretty much any design pattern other than Quick'n'dirty: It's tiny afterall, and it needs to be out today.

I find also all the public available open source frameworks quite bad, Zend Framework is excellent in some areas, but it's apparently designed by morons as well. I'm talking about the bloated Front Controller methodology (Stupidly bloated), breakage of MVC rules, stupid abstractions (Zend Form: Welcome SnailWeb!), bad documentation, breaking backwards compatibility in EVERY SINGLE release, in some UNDOCUMENTED area. (Yea, it was reeaaal fun to tackle with a mysqli UTF-8 problem for hours, just to realize that particular server had slightly older Zend FW installed and it lacked the set charset option for mysqli object). Zend_Db_Table seems also stupid useless integration. Zend_Cache_File is only cache object which has all the advertised features, BUT isn't splitting cache objects into subdirectories, causing SnailWeb effect when you hit say 100k files on a single directory. No low traffic sites needs cache, and cache is used to achieve better speeds, not to kill it by seeking overbloated directory. Funnily, one huge project was performing slow (Zend FW), and after i were done with it, the biggest bottleneck is Zend Cache ... And the project is database heavy (hundreds of millions of rows, tens of millions of fulltext search rows etc etc.), and the performance bottleneck is on the PHP side. Some are our multiple levels of abstraction to get complicated tasks done slightly differently in a multitude of places, but a lot (or most) of it is to do with Zend's Front Controller.

Re:Algorithms

[sonamchauhan]

"interview with Amazon a while back and in preparation bought the book "Programming Interviews Exposed"

I hope you didn't buy it off Amazon ;0)

Re:Algorithms

[Mabbo]

This, for sure. I took a 3-year diploma (non-degree) at a Canadian college in programming. I can code in many languages, learn new ones quickly, and grok someone else's code base fast. But until I got into my 2nd and 3rd year of my University Degree in Computer Science, I really didn't *get* algorithms the way I do now. If you want to see if someone is a Coder or a Computer Scientist, hand them the Facebook Careers Puzzles page. I started into it the other day, and as I read through them was able to simply say "Optimal sub-structure- use dynamic programming... that one is a variation of the stable marriage problem... this one is finding cliques in a graph, need an approximation algorithm... ". Showing the problems to my coder friends, they start trying naive approaches to the problems.

Re:Algorithms

[Vasheron]

When I started programming and messing around with technology I definitely questioned the value of learning about algorithms, mathematics, and the like. Ten years later and I'm now working on computer vision related problems. I use these algorithms, or invent variants all the time! Nearly all of my training in mathematics and computer science is beneficial in this field. Even the courses I took in abstract algebra seem helpful now because they primed my brain to be able to understand useful things like projective geometry with ease!

Re:Algorithms

[Anonymous Coward]

Good for you. In most jobs in the real world, though, that's all a bunch of bullshit. I could still probably outperform you and 2 of your friends in any typical 4 week business application development project.

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.

Re:computer architecture

[CubicleView]

I was introduced to all that at university and while I don't doubt that it's granted me a better insight, I can't say for sure that it's ever had an effect the code I've been paid to write. Most of these questions I read about what makes a "good" developer amount to so much navel gazing. There are of course a few basic things that every developer must be able to do, but beyond that it really depends on the persons goals, the job etc.

Re:computer architecture

[gangien]

I mean down to the falling/trailing edge of the voltage change.

that's overkill. Although i agree, exposure to asm is a very good thing.

Re:computer architecture

[Vasheron]

If you've never had to write real-time, parallel, computationally intensive code in a low-level language, then yes it won't make much of a difference.

Modeling

[Rhaban]

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

[tthomas48]

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

[Rhaban]

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

[dubbreak]

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

[tthomas48]

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.

Re:Modeling

[Anonymous Coward]

Man, I hate reading LISP.

Re:Modeling

[dubbreak]

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.

It wasn't part of the core classes where I attended (though it should be). There were 3rd and 4th year courses that focused on modeling such as: object oriented design and development, and system analysis and design.

Depending on what a student decided to focus on it was possible to completely avoid any courses that involved modeling. I worked as business/system analyst while in school which got me interested in design and also the business side of software.

One of the cool things being pushed at the uni I attended (midway through my degree) was interdisciplinary and/or combined degrees (CS/Chem, CS/Physics, CS/health science, CS/Music). Pure CS doesn't leave you very well rounded. I didn't end up doing any of those programs however I ended up doing a minor in business and took some other courses to round my degree out (e.g. a GIS course offered by the geography faculty which ended up being quite useful).

Re:Modeling

[socz]

Although I'm all for an "education" it's not what I chose to persue. My problem was with instructors telling me I had to do everything the same way everyone else did. Why? Especially when I had new ways of doing it. (Sometimes better which I later learned they didn't like).

A great example of how this transfers over to the real world is my use of ActionScript in flash. I made some pretty cool things with it - things which weren't its purpose. Aside from ActionScript I've also used flash for basic design - something people laugh at (the idea) but most who see the work don't care what it was designed with but what the finished product is.

But the common misunderstanding people take is that I say we shouldn't learn anything, which is not true. I still chose to learn a lot, just on my own and through reading and that's what I've continued to do. Learning is important, it's just that sometimes people aren't the best way to learn things.

Another point of view by learning things on your own is that you will bang your head for a while trying to figure out simple things, but along the way you'll learn a LOT of other things that are useless at the moment but will later be useful. That's something I pride myself on, being innovative (by using/doing things others would have never thought of using because that was not its intent nor purpose).

Re:Modeling

[Anonymous Coward]

I'll agree a little bit.

I think a formally educated programmer has a 1 to 2 year head start in this area, but that is about it.

As a self-taught schmuck who has spent the last 11 years cleaning up messes created by formally trained programmers, I can assure you that a few years of college aren't going to teach you much about database design.

The only real teacher in this regard is experience, and knowing how you (and other people) have blown it in the past, and what to look for in the future. And more importantly, know that every client, every manager, everyone is going to lie when they assure you that there will never, ever, ever be more than one customer attributed to an invoice, or employee on a benefits statement, or whatever other combination you can create. It's always a lie. Within a week of roll-out, you'll hear about "this one special exception."

Just plan for flexibility at the start.

Unfortunately, that comes with experience. And that experience is more valuable than theoretical knowledge.

Re:Modeling

[sjames]

True, but why are people assuming that self-taught people don't have foundation in theory? It is perfectly possible to learn the theory by self guided study of text books.

Many here seem to assume that self-taught = learned only as needed while doing when it can just as easily mean studied theory in one's spare time and then immediately applied it.

Learn C

[meridiangod]

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.

college?

[Anonymous Coward]

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.

Re:college?

[Anonymous Coward]

That's wonderful. As a follow on, I'd like to suggest that you go back to college and "open up" a basic textbook on English grammar. Then maybe you could have someone show you where the shift key is located on your keyboard.

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

[schlesinm]

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

[Sloppy]

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

[LordKazan]

Design Patterns: common "Template" solutions to regularly encountered problems/variations-on-that problem. Be careful when learning these that you don't fall victim to "when you have a hammer, everything is a nail". Also learn the Anti-patterns, wikipedia has a good list of anti-patterns.

Algorithms & Data Structures: Analysis, average running time Big O is most important, but understanding worst-case runtime is important too. Designing algorithms vs knowing when to leverage an existing one.

the C++ standard library provides a great many of these, it has a high efficiency sort (from ), it has good collection data structures (vectors, linked lists, maps, etc)

Objected Oriented Analysis And Design: Knowing when to make something an object, when and how to use inheritance and polymorphism, when to not make something an object. Plain old data objects. separation of responsibility: UI is not logic, logic is not UI.

Threading: proper thread synchronization techniques (mutexs, semaphores, conditions, etc), threading patterns such as Producer-Consumer, Inter-process communication

Automata & Computability: (Deterministic|Nondeterministic) Finite State Machines, Regular Languages, Turing Machines

Programming Languages: LL language parsing & rules authoring.

Computer Architecture: Processor design, pipelining, caching, function calling conventions, etc - how to use this knowledge to write more efficient programs

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

[mcd7756]

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

[spirality]

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

[Anonymous Coward]

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

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

[CodingHero]

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

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

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

[ubersoldat2k7]

I might add to this list: Recursion.

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

[coaxial]

No one cares about Turing machines. They're an abstraction,
Prog languages and architecture also don't really matter unless you're working on something very close to the metal.

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

[LordKazan]

that's misuse of DP you're talking about.

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

[goofy183]

Ouch, yeah I think that says something about the CS curriculum at that school. The list that the grand parent posted is pretty much the core classes that I had to go through in college. Really the only optional thing that I think everyone should have to take as well is a Sr. Design project type course set like most engineers do.

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

[LordKazan]

my school's core curriculum is actually how i crafted the list. Prior to high school I was a self taught programmer, in high school i was blessed to have a computer science class taught by a former lead developer from Apple (Newton platform).

I looked my university curriculum and deduced what i would have never properly learned as a self taught programmer.

Before my high school teacher educated me in the right ways to do things I was the worst type of BFI self-taught you'd ever seen: like the vast majority of self-taughts.

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

[Gouru]

I would add to your summary:

Writing Secure Code: Writing code that is robust and resistant to attack. Doing this right is neither easy nor obvious.

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

[CodingHero]

Ouch, yeah I think that says something about the CS curriculum at that school. The list that the grand parent posted is pretty much the core classes that I had to go through in college. Really the only optional thing that I think everyone should have to take as well is a Sr. Design project type course set like most engineers do.

As I said, I went through an engineering curriculum so I can't speak to what CS kids did or didn't have to take and thus what they did or didn't learn.

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

[LordKazan]

Secure code naturally comes from practicing good coding practices to start with in my experience.

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

[buchner.johannes]

Programming Languages: LL language parsing & rules authoring.

I would say they miss the understanding of logic oriented programming languages (such as Prolog/Datalog) and functional programming languages (such as Haskell).

These approaches and ways of thinking can be very useful even if you program in a OOP language. Newer scripting languages also have a lot of features that cross the borders (such as lambda).

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

[monkeySauce]

So what university did you go to? It would be useful for others to know which school to avoid.

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

[Anonymous Coward]

And all the other crap you'll never use after college.

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

[Anonymous Coward]

All of these are important things you need to understand before you should be allowed to call yourself a good programmer. Coming from an engineering background, before I decided to go back to school and get an additional degree in Computer Science, I can tell you that no matter what you think you probably don't know how to program well. I was always interested in computers and programming before going through CS and thought that I was pretty good and efficient at writing programs. Boy was I wrong. Engineers are probably the worst programmers out there, it's easy for an engineer to get carried away with trying to be efficient and then end up just doing the opposite. Compilers these days are quite well optimized. An engineer trying to write optimized code is probably just going to make it harder on the compiler. Until you have the basic theory and insight on what goes on behind the scenes you are dangerous.

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

[bullok]

This is an excellent list. I was self-taught from the age of about 12, and thought I was an excellent programmer until I was about 25. Having earned BS and MS degrees in Astronomy and Mathematics, I'd written a fair number of programs, and had a decent command of about 7 languages. Then I went to graduate school for Computer Science. And I found out that my knowledge was SEVERELY lacking, both in breadth and in depth. How much of my missing knowledge was relevant to day-to-day programming tasks? Well, perhaps not surprisingly, not much. However, when I come across some issue where my CS education is useful, it's HUGELY useful, and enables me to tackle a problem in far less time, and most importantly, implement a correct solution. It also lets me know when I need to turn over a portion of a project to a specialist. In other words, I'm now more aware of the things that will become a time sink, and increase uncertainty if I attempt them. This ability to do "project triage" is one of the benefits of a well-rounded CS education.

I think that this is the main reason that you'll hear a lot of people say that a university CS education isn't very useful. For about 98% of the things you work on, it really doesn't make you any better than someone who's self-taught. But that remaining 2%... it can mean the difference between blowing months of time on a crappy solution to a problem, or knowing how to put a good one together in a few days time. So, on the whole, a Uni education can make you a far better programmer, even though you won't necessarily find yourself pulling tricks out of your Uni bag every day.

As an example I'll add my 2 cents about only one of the topics mentioned above: Programming Languages. There are many cases where programmers try to develop a "simple" scripting language for embedding in an application. This is one thing that very few people (even uni-educated) should attempt. Proper language design and parsing is VERY difficult, and there are at least a half-dozen well-designed scripting languages that can be literally dropped in to an application with almost no effort when compared to the complexity of rolling your own. And yet, we see time and time again, people attempting to write one from scratch. One of the worst examples I can think of off the top of my head is LSL (Linden Scripting Language), used in Second Life. It's an absolute nightmare of a language. And yet, it made it into a large-scale product like Second Life.

There ARE many cases where a domain-specific language (DSL) can be incredibly useful, especially when the language does not need to be a general-purpose one. In my experience, it's rare for a programmer (no matter how their skills were gained), to create a good DSL without a strong grasp of at least a dozen programming languages or so. University-educated programmers tend to be a better judge of whether they are up to the task of designing and/or implementing a language(at least, after they've tried their hand at it once or twice).

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

[LordKazan]

I know you're just a dumb AC, but if you have a degree in CS and you're employed somewhere that isn't using at least some of the things i listed then i can tell you something about you're programming shop, or the code you produce:

one of them is utter garbage.

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

[LordKazan]

i'll give you an example of a well designed domain-specific language to juxtapose next to LSL

the "Simple Expression" (SEXP) system from the FreeSpace 2 engine. It is essentially Scheme in structure, but a much restricted subset.

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

[spinkham]

I'd also add relational algebra and database normalization, but you've got a pretty good list there.

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

[Hurricane78]

Or unless you want to optimize your programs. (A must for all professional software and games.)

This should be an eye-opener, if you don’t know it already:
http://www.infoq.com/presentations/click-crash-course-modern-hardware

This is definitely a huge point. Even for things like Java software for mobile phones!

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

[The End Of Days]

The point of design patterns is not to provide a catalog of common solutions, it is to formulate a common language to describe the solution space. They are not an implementation tool, they are a communication tool.

Understanding the purpose of the tools is the first step to using them correctly. Disparaging the tools because fools misuse them is just as foolish as misusing them.

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

[macs4all]

I might add to this list: Recursion.

I am a self-taught programmer, who was actually programming "out of my element" (I'm an embedded software/hardware dev. by trade), writing in C/AL (a 4th gen Pascal-like scripting language used in the financial/ERP package, Navision (now Microsoft Dynamics NAV), for the company I was working as an embedded dev. for at the time.

The task at hand was a function of do "exploding" of multi-level Bills of Materials (BOMs).

In about 3 lines of C/AL code, I designed and wrote a clean, recursive, data-driven function, that iterated down through the BOM levels. Worked perfectly the first time. I might add that I was also the "architect" on this project as well, so the "idea" of using a recursive function was my own as well, arrived at after about 10 minutes of "design analysis'.

By the way, even the experts at Navision had no idea that C/AL could even be used recursively, and they developed the language!

Moral to this story: A bad programmer is a bad programmer; conversely, a good programmer is a good programmer. Anything else is simply flapping of gums by all concerned (including me).

Incidentally, not only is my recursive "exploder" function still (since 1997) being used by my (now) former employer; but it also made its way into a paid "add-on" still being sold by a third-party Navision (MS NAV) developer.

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

[metaforest]

One of the worst examples I can think of off the top of my head is LSL (Linden Scripting Language), used in Second Life. It's an absolute nightmare of a language. And yet, it made it into a large-scale product like Second Life.

If you have problems with LSL then you are misusing it. It is a DSL and it's very good at what it was DESIGNED to do. Which is animate CSG link-sets. Using for anything else is asking way too much. Even Linden Labs has forgotten that it's not a generalized language. Abuses abound, including features added to the stdlib that should not be there without redesigning the language!

The crap that many people write in LSL is an example of trying to use a phillips screw driver to install every fucking fastener except phillips-head screws!!!

Programming in LSL has more in common with using an embedded micro-controller with an application specific library for motion control....

Working with LSL has been a kick. One example is building very efficient PID controllers... and other tasks that interact with virtually physical processes.

People that complain about LSL either don't get it, or are actively trying to make it operate in problem domains it was not designed to operate in.

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

[Pictish Prince]

I might add to this list: Recursion.

IMO, if you don't understand recursion before you learn to program, you have no business being a programmer.

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

[bullok]

Sorry. I have to disagree with you completely. No user defined libraries... only rudimentary argument passing between scripts, needing to use the API to access list elements, no arrays. Come on! It's a horribly-designed language, even for animating link sets. You can't even smootly animate prims with it, without making them physical. And the main problem is, that there's nothing else you can use to automate anything in SL EXCEPT for LSL. Yes, people try to write complex things that LSL wasn't designed for, but it's not because they don't understand it's limitations, it's because it's the only option. So, if anything, you've just proven my point. They developed an in-house language, and it miserably failed to meet the needs of it's users. How is that a well-designed language, exactly?

The issue is, that the problem domain was NOT well-understood by the designers. They thought they understood what people would need to automate in SL, and they were VERY wrong. Had they used lua, python, perl, scheme.. hell, ANYTHING else, they'd have done a better job. This is a case where the designers thought they could write a language from scratch, and they failed miserably. Anyone who's designed a DSL from scratch knows that people will push the boundary of the original intention. It's the designer's job to anticipate what the users want and need. I still call this an epic fail at Linden Labs.

And, yeah, I've done a lot work with microcontrollers, and cut my programming baby teeth on 6502 assembly. I know about "programming in the small".

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

[bullok]

Yes, you're right. I haven't worked with it much. But I remember it as being a pretty good design. I didn't say all DSLs were unnecessary, or bad. :) This one certainly blows LSL out of the water.

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.

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

[thePowerOfGrayskull]

These are all areas of weakness I've seen in university-taught programmers too. That's more a result of the general lowering of standards that our industry underwent in the 90s.

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

[Dixie_Flatline]

At my University (University of Alberta), the department is 'Computing Science'. The science of COMPUTING, not computers. The distinction is subtle, but important, as you're noting. 'Computational' science isn't a bad description, though.

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

[eiro]

Visit this link : How to become a programmer : http://www.wikihow.com/Become-a-Programmer

Purple Monkey

[Anonymous Coward]

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

[Anonymous Coward]

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

A job

[Anonymous Coward]

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

Some suggestions

[nicc777]

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

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

Re:Some suggestions

[obliv!on]

SIAM (Society for Industrial and Applied Mathematics) has several special interest groups related to computing/programming problems. The other major math and stat groups have excellent articles on computing problems from time to time as well like the AMS, MAA, or AMSTAT, but SIAM probably provides the most of these groups and a lot of coverage that compliments IEEE and ACM. Also depending on if you're working in a specific industry or if you're furthering your studies in a graduate program there may be other professional societies that deal with informatics or computational issues related to that focus.

Re:Some suggestions

[jpmorgan]

I want to emphasize the parent poster. I've been a member of the ACM in the past, but SIAM is a much better organization for the serious engineer, just poorly marketed.

Algorithms, data structures, systems

[ColonelPanic]

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

[LordKazan]

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

[dubbreak]

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.

Re:Algorithms, data structures, systems

[LordKazan]

communication skills:
with technical people about technical issues? extremely good
with non-technical people about technical issues? adequate

the other guy who had the same level of experience as me was actually my Automata and Computability TA, half the class credited him with their passing grades.

Re:Algorithms, data structures, systems

[Anonymous Coward]

This country is not a meritocracy. The others probably had some pretty sweet connections. It took me 6 months to get a job with a PhD from a top school and a triple major.

Know....ledge?

[Anonymous Coward]

I've been programming Visual Basic for years!

Software engineering

[m.alessandrini]

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

Practice practice practice...

[xkrebstarx]

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.

O(n^2)

[mosel-saar-ruwer]

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)

[Anonymous Coward]

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)

[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:O(n^2)

[Anonymous Coward]

Someone is way too impressed with himself. That kind of thing isn't necessary in most programming. Niche knowledge ftw.

Re:O(n^2)

[pengin9]

Don't worry, Fourier transforms are not taught to undergrad students either, but the advanced mathematics make for very efficient source codes.

Re:O(n^2)

[Korin43]

Learning to analyze algorithms is very helpful. Spending an entire semester is not. You could teach people all they need to know about big O and common algorithms in an afternoon. Not to mention teachers' obsessions with showing formal proofs. I'm not a mathematician, you can teach me the easy way and I'll just take your word for it that it works.

Re:O(n^2)

[nbates]

I disagree, I learned about big O notation and algorithms in college, I'm a Physics graduate. This is basic knowledge you need to have if you are working on numerical simulation.

On the other hand, what you don't need, is the capacity to create a reusable program. Just big number crunching programs that solve a specific problem.

What I see that I'm lacking is the capacity to create a complex system with a clean architecture. I'm not sure about design patterns for example, even if I know the basics.

Re:O(n^2)

[element-o.p.]

That kind of thing isn't necessary in most programming. Niche knowledge ftw.

I disagree. Maybe you don't need to understand FFT's in your line of work (I don't), but analyzing algorithms for efficiency is absolutely a real-world skill.

If you don't at least understand these concepts (, then you don't understand why one algorithm is crap in the real world and another algorithm is preferred. If you don't understand why one algorithm is crap and another algorithm is good -- even though both provide the correct results -- then you have no business writing code professionally. This is not just an academic exercise. I have seen programmers (and I'm using the term very, very loosely here) who could not get the concept that nesting for loops -- while conceptually simple -- was an exceptionally poor way to do what they were trying to do. Then they couldn't understand why all our user were complaining that "the network" or "the server" was slow, when in fact, the network and the server were fine; it was the developer's piss-poor code that made a snappy network and bleeding edge hardware appear to be so sluggish.

Re:O(n^2)

[Chuk]

The OP has a degree in physics, I don't think there's much if any math in programming that's going to require, say, tensor calculus. (Well, other than programming in fields where they use that kind of thing, like image analysis.)

Re:O(n^2)

[joshki]

No, not really. This is the difference between a coder and a Computer Scientist.

Re:O(n^2)

[Korin43]

I assume you're talking about my claim that formal proofs aren't needed? Why would anyone possibly need to? Answer this, if a program takes n^2 * 50 * 100000 * n * log(n) * sqrt(n) steps to complete, what's the big O? If you're working on a formal proof right now for something that's obviously O(n^2), I hope you never get hired because you'll be the slowest programmer to ever live. Not to mention that the formal proof doesn't tell you anything anything unless you're insane, while the intuitive "Big O is based on how fast execution time increases as a function of the number of things you're working with" tells you quite a bit.

Re:O(n^2)

[joshki]

Learning to analyze algorithms is a critical skill. I didn't say anything about formal proofs, but if you don't know how to do the formal proofs, you don't understand the underlying concepts.

Re:O(n^2)

[frosty_tsm]

Answer this, if a program takes n^2 * 50 * 100000 * n * log(n) * sqrt(n) steps to complete, what's the big O? If you're working on a formal proof right now for something that's obviously O(n^2),

Except that what you wrote is actually O(n^3). "log(n)" and "sqrt(n)" are irrelevant (too small in comparison), but "n^2 * n" is n^3.

I only wrote one or two formal proofs in an entire semester. They are an academic exercise only.

Re:O(n^2)

[sbeckstead]

Even in Image analysis, you really only need the basics of calculus. If you know how to construct a problem you are well on your way to solving the basics of the problem. There you do need to know how to apply an FFT or construct a series of transforms, and matrix manipulations but not that intense really.

Re:O(n^2)

[drummerboybac]

Fourier transforms are taught to EE undergrads where I went to school, but not in the CS program.

Re:O(n^2)

[Korin43]

Actually you're right, and wrong. I was writing quickly. It's actually O(n^3 log(n) sqrt(n)) (and all of those are relevant). I meant to do +'s.

Re:O(n^2)

[Zumbs]

The point of using "an entire semester" is not to tell students what big O notation is all about, nor is is to show them a handful of common algorithms. The first point is to teach students how to analyze algorithms for a multitude of information. Aside from run-time complexity, you may also be interested in how much storage it uses, when and if it terminates, correctness, identify border cases (not identifying these can give you some quite spectacular bugs), all of which can be used to gauge if a given algorithm is appropriate for the task at hand. The second point is to show students a multitude of ways and techniques to solve a given problem on an abstract, which can be used to solve similar problems. This gives students a toolbox which can be used to devise new algorithms to solve other problems.

Re:O(n^2)

[Anonymous Coward]

Actually you're right, and wrong. I was writing quickly. It's actually O(n^3 log(n) sqrt(n)) (and all of those are relevant). I meant to do +'s.

When "n" becomes very large, n^3 dwarfs log(n) and sqrt(n) to the point that they don't matter. Plus, having an O() expression that long makes it meaningless (since who knows off the top of their head what n^3 * log(n) * sqrt(n), and is it better or worse than n^3 * sqrt(n) * cubed-root(n)).

Re:O(n^2)

[Darinbob]

I'd add data structures to the list. I've seen a lot of people re-invent hashing schemes or trees, or use a naive unbalanced tree, or assume that any sort of mapping construct built into a language or library is sufficient.

When you start working with smaller embedded systems, and sometimes with multithreaded programs, you also run into operating systems issues. Like deadlocks, priority inversion, synchronization, etc. But this is true for many formally trained programmers as well.

Re:O(n^2)

[Darinbob]

The majority of most college courses are about teaching the student to think abstractly and logically, and to drill the student so that the principles aren't forgotten when the finals are over. So yes, you can learn the basics in less than ten weeks. But it can take longer than that to think about the problems the right way, or to internalize what you've learned.

Then there's the harder stuff beyond the basics. Like why is quicksort fast on average even though it's an O(n^2) algorithm? Is your nifty new algorithm to calculate a route just another NP complete problem, or is it polynomial?

Re:O(n^2)

[geezer nerd]

For a lifetime of computer programming, one does not need to know Fourier transforms, unless one is programming an analysis program that uses them. The point of the discussion is that of appreciating algorithm complexity and the "big O" properties of algorithms. The fast Fourier transform algorithm is a beautiful example of how effective algorithm design can be in dropping complexity and computation time to calculate the Fourier transform, which in its original form is based on continuous mathematics of some complexity.

Re:O(n^2)

[Anonymous Coward]

All you need to understand is polynomials. This online book has an excellent explanation in chapter 2 ("Divide-and-conquer algorithms"): Algorithms Book

Re:O(n^2)

[Kjellander]

...or any program that uses mp3s, or mpeg video, or any jpeg.

Usually it is hidden behind libraries though, but fourier transforms (and its pals cosine transforms) are very common. It isn't just used in analysis.

Re:O(n^2)

[BugHappy]

The problem with O(n^2) estimations is that academics count high-level operations as an atomic unit rather than basing efficiency evaluations on the CPU cycle count of each CPU instruction (this is considered "vulgar" by an academic world in love for abstraction, as each instruction's CPU cycles are different for each CPU).

Worse, they act in their optimization strategies just like if computers were 'perfect' machines -waving real-world issues such as CPU caches, DMA overhead, or the memory wall.

As a result, while not totally pointless, academic research is too often far away from reflecting real-world conditions.

No wonder why companies like MICROSOFT (who hire and fire young graduates mainly for the associated tax-breaks) design and implement products that miss so extraordinary well their target.

The difference between theory and practice is larger in practice than it is theory...

"Do not worry about your difficulties in Mathematics. I can assure you mine are still greater."
"Intellectuals solve problems, geniuses prevent them."
"Information is not knowledge. The only source of knowledge is experience."
"Truth is what stands the test of experience."
"Imagination is more important than knowledge."
(Albert Einstein)

Re:O(n^2)

[laerad]

I have got to disagree. Sure, Fast Fourier Transforms are a tad on the tricky side, but that does not excuse ignoring the basics that anyone should be able to understand. And if you cannot, in my opinion you have no business writing computer programs professionally, because there's a good chance you're the reason the job can get tough for the rest of us. Average quality of computer programmer is very low in my experience, and an understanding and appreciation of these concepts would help to change that. To say Advanced Calculus is necessary is completely disingenuous. I escaped a large chunk of the Math's I was taught at University, but got by with the algorithms classes. Certainly some of the highly acadcemic algorithms (going into N log log N etc.) that you do not use in every day life can be difficult to calculate the complexity of, however at least an intuitive understanding of what causes complexity to spiral and how to avoid it is IMHO one of the most important pieces of knowledge for a computer programmer.

Re:O(n^2)

[MrKaos]

The difference between theory and practice is larger in practice than it is theory...

Priceless.

Re:O(n^2)

[Anonymous Coward]

And what does someone get by knowing the mathematical foundations for FFTs?
Sure, if you are the genius that invents FFTs you need the foundation in maths.
A good programmer goes to wikipedia, adapts the formula to C syntax and forgets about the maths.
I did a lot of 3d vectors and transformation at school when I actually needed them I didn't remember shit. I googled for 3d this 3d that and I got the program going in no time.
Basic algebra knowledge and common sense is all a programmer needs.

Re:O(n^2)

[kill-1]

I like this version even better: "In theory, theory and practice are the same."

Re:O(n^2)

[cbiltcliffe]

And what does someone get by knowing the mathematical foundations for FFTs?

They get to call fellow programmers "%&^#&%$ n00bz"

Re:O(n^2)

[TerranFury]

Ditto. Damn near all of (undergrad!) electrical engineering (outside of digital logic stuff) is built around Fourier/Laplace transforms, thanks to the convolution theorem...

Re:O(n^2)

[Anonymous Coward]

I don't mean to sound like a jerk, but you really need to get off your high horse of Fourier transforms and infinite sets.

He has a degree in physics. More than likely, he knows just as much as Fourier transforms as you, if not more. You use it in many areas of physics, especially quantum mechanics--one of the bread and butter courses of a physics degree. More than likely he's taken computational physics and implemented FFT.

Re:O(n^2)

[Dixie_Flatline]

I've always considered it this way: if your algorithm needs to be analysed for its complexity, it's too complicated. Trash it, start over.

Until you're actually in a position where you need optimisation done, you should be able to quickly identify only a few classes of algorithms: O(n), O(n^2), > O(n^2), O(n^2). In general, anything worse than O(n^2) needs to be rewritten and anything better can be kept. That's it. The higher level compartmentalization will get you pretty far.

After that, only optimise what's necessary. Early optimisation is the root of all evil. ie., If you don't know what's slow and what's not, don't fix things arbitrarily. Figure out what's slow FIRST, then fix THAT. Local maxima in limited instances aren't as important as fine tuning code that's called more often.

To return to the original question, Computing Science (and that's a term I consider important; this is the science of COMPUTING, not COMPUTERS. I can do my computing and algorithmics on a piece of paper if I need to) as taught formally is about forming the basis of what's important to think about. You say you're a physicist, so I'm sure you can understand what I'm talking about on a more general level. There are details and minutia that are important to know very rarely, but you can make jumps and generalisations more quickly because you've learned those details and techniques.

So, if you want to fill in your knowledge gap, I'd pick up three things:

1) a book on general algorithmics. It doesn't have to be big or complicated. Some familiarity with complexity is essential;
2) a book on programming languages. Not *A* language, but one that talks about languages in general; and
3) a book on design. Whether it's a book on UI design specifically, or Donald Norman's 'The Design of Everyday Things' is largely irrelevant. What's important here is that you learn how to think of usability in a fundamental sense. Most CS grads can't even do this, and I think it's a giant waste.

That's the short version, anyway. I suppose there's no replacement for a full education, though. You're not going to be able to fill in a degree's worth of knowledge without doing a degree's worth of work.

Re:O(n^2)

[Halotron1]

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

I would agree with that specifically on the "all they need to know" part.

I got my BSCS, and I can say that having a little knowledge about how the big O or big theta stuff works can help you understand what makes a chunk of code more or less efficient, but learning how to exactly properly calculate things like that aren't really necessary for 90% of the programming jobs out there.
Maybe if you're writing hardware level programs or something and efficiency is a big deal.

Lots of the CS degree is more focused on the science of computing, than on how to be a good programmer.
I've been a full time programmer for over a decade now, and I've never had to determine if any of my algorithms were turing compliant, or use BCNF for database design.
That doesn't mean there isn't a use for that knowledge, just that for the masses it will not make you a better or worse programmer.

Here are the things from my CS degree experiences that I would say have actually useful been useful to me in the business world:
- Programming Languages: we reviewed different types, from functional languages to OO, etc and what makes a language
- Networking: Learned a lot about the topic, and even wrote some TCP/IP programs
- Operating systems: Learn how different operating systems work and what's under the hood a little. Not super helpful as it was more theoretical than practical, but still interesting
- Non-CS classes: Honestly the BS classes that people complain about, like social studies and arts focused classes did a world of good for me. Improved my writing and presentation skills, and gave me a much broader view of the world than I would have had if I never left the podunk town I grew up in.

All the important stuff

[Anonymous Coward]

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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

I'm Interested in the Opposite View

[moore.dustin]

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

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

[david.emery]

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

[SurgeryByNumbers]

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.

Re:I'm Interested in the Opposite View

[BadKneeDad]

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!

Re:I'm Interested in the Opposite View

[bdwlangm]

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

[RationalRoot]

SCC and Software engineering walk hand in hand. Everything from how useful unit tests can be after merging code to how to design code so that you large teams can work on the code without stepping on each others feet.

Like chess, playing is easy. Being good takes a while.

Re:I'm Interested in the Opposite View

[Corporate Drone]

Self-taught folks tend to have less in their toolkits -- when all you've learned is a hammer, everything looks like a nail. Then, when trying to do something different, they try to take their hammer and "invent" a screwdriver out of it.

kids right out of school aren't ready to take practical problems and successfully solve them -- that work ethic tends to take a year or two to get down (and rightly so, since CS programs aren't I.T.-drone-cookie-cutter factories), but at least they know enough about the landscape to recognize what tools to use.

Re:I'm Interested in the Opposite View

[phallstrom]

Not understanding the business reasons behind the decisions being made. The PHB's don't care what language you use or algorithm or any of that (usually). What they do care about is that it's on time, has the features they want, and gives them a high return on investment.

I've sat in meetings were a programmer will go on about why a certain feature can't/shouldn't be done for a variety of technical reasons and gets no where. And right after that another programmer will mention that the feature can't be done as it would cost $$$ and delay the project and not provide any ROI. And the feature is canceled.

And, no, I'm not suggesting programmers should pull the ROI trick out of the bag when they don't want to do something, but if you want to convince management, speak their language.

Re:I'm Interested in the Opposite View

[bdenton42]

Generalizing... Self-taught usually means that the person has a technical interest in programming. You're likely to find more of them to be competent as they've spent the time scouring the manuals to figure out how the thing works. From there you have to find out what else they have... do they have good business fundamentals to understand how to apply programming to what you need for your business, or good math fundamentals if your need is complex scientific programming?

With Schooled you'll get some of the people as above who really have a technical interest in programming, but you also get a bunch of yahoos who are just there to learn enough about programming to get by and land a job. The former will be both good programmers and will have either a rudimentary business or mathmatical foundation taught to them as well. The latter are probably more likely to end up in management...

Re:I'm Interested in the Opposite View

[Anonymous Coward]

This was exactly my first thought. All the education in the world can't compensate for lack of interest. There's nothing I fear more at work than somebody who really doesn't care about the code.

Re:I'm Interested in the Opposite View

[Anonymous Coward]

items no 2 and 3 are not Computer Science

they are Software engineering...

even thou they are taught together, they are very different beasts

since SE is so new, it's not very well understood, delimited and solidified...

Re:I'm Interested in the Opposite View

[moore.dustin]

This is what I was thinking myself. The self-taught programmer has already demonstrated enough passion in the field to know there is genuine interest in their work. I cannot stress how highly I value that drive as I feel anything is possible so long as the drive is there.

With people coming out of school, you are going to have to sift through quite a bit to find those few who have true passion for their work. Moreover, the grads tend to have this attitude out of school that they know what they are doing - they don't. The self-taught people tend to be confident themselves as well, but it manifests itself through production, whereas the schooled people like to talk about 'theory' much more than making those theories a reality.

Re:I'm Interested in the Opposite View

[LordKazan]

all these things were taught at the university I went to.. in my (admittedly limited) experience the people who don't get taught all these things [and others things mentioned elsewhere in this thread as being lacking from university] are those who went to community college. The Community Colleges here have computer programming programs, that teach absolute garbage.

Then again: I'm in Iowa, and I went to Iowa State University (where the automatic digital computer was invented)

Re:I'm Interested in the Opposite View

[Tablizer]

Agreed. Both sides can learn from each other. Knowing theory tells you what's possible and street knowledge tells you what's practical. Theory cannot fully substitute for street knowledge and vise versa. (By the time you master both, you get carpel-tunnle and move into management ;-)

Re:I'm Interested in the Opposite View

[Anonymous Coward]

Schooled programmers != programmers just out of school. The problems you indicate are endemic to all inexperienced young employees, but that's not what we're discussing here...

Re:I'm Interested in the Opposite View

[Anonymous Coward]

I think it would be instructive if you mentioned which industry you are in. Of the four programmers I knew before college, three have degrees. Two do embedded work, one works for THQ, and the other one makes ASP sites. Programming is a technical field, and going into it without an education severely limits the kind of work you are qualified to do.

I doubt that there are any gaps an educated programmer has that can't be filled with experience. But working grappling with messy codebases is an area which the HS grads will have at least a four year head start on, which needs to be taken into account.

Re:I'm Interested in the Opposite View

[Anonymous Coward]

In my experience, students coming directly out of college CS programs are really weak in debugging, managing code across multiple files, CVS/source control, and keeping things simple. I've been in several situations where code was so over-engineered with the latest CS approaches, that it was a monumental pain in the butt for people to actually use the system. I've also seen a lot of students hanging on to a particular language they took a class in, rather than embracing several languages and using the one most appropriate for the task at hand.

Re:I'm Interested in the Opposite View

[plcurechax]

I think the biggest difference can be in the motivations. Many of the self-taught programmers I've met or worked with their legacy (code), enjoy what they are doing. The dot-com boom increased the numbers of both CS post-secondary enrollment as well as the "self-professed" programmers who were merely motivated by the money. The "self-professed" tend to be more transparent about it, so are quicker to be weeded out, I suspect.

coming out of school often still have a horrible worth ethic

It's opinion, but I conjecture that it may have more to do with maturity than knowledge or experience. For many it isn't until they are out of college before they have to make their own decisions, and so are facing a large amount of growing up at the same time.

Both can be good, both can be lame.

Re:I'm Interested in the Opposite View

[Anonymous Coward]

Databases.

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

[fishexe]

Like chess, playing is easy. Being good takes a while.

If that's true of chess, how come my wife still can't learn the rules?

Re:I'm Interested in the Opposite View

[jeff4747]

I'm mostly self-taught with a couple CS classes.

IMO the big thing the new CS grad is missing "Engineering".

The problem with CS is that it's science. It really needs to be broken up into "the researchers" and "those that apply the research". A little like the difference between Materials Science and Civil Engineering.

The vast majority of people who get CS degrees would be better served by some sort of "Software Engineering" degree. They need to know how to put the Legos together well, they won't be creating new Legos.

In a similar vein, new CS grads seem to lack the training on how to work on projects of significant size with a several people (why have source code control, what the 'test' department really does, and so on). This isn't surprising since the vast majority of CS courses consist of making a bunch of small programs to illustrate a particular technique and then immediately abandoning them once it's time for the next lesson/course. At best you have a "Final Project" with 4 people in it working on a relatively contrived problem. I can't really blame the schools on this one though. There really isn't time to build a large and complex system within a normal college curriculum.

Which leads to maintainability. If you're just doing little programs for a single course, you don't have to worry about maintenance of the code. Then they get their first 'real job'. Then they're desperately trying to remember the details of some clever trick they put in a year ago that is now causing a defect. The complex implementation looked really nice when they wrote it, and it saved 250ms so it's a huge optimization....problem is it's saving 250ms per hour and a bug somewhere in it is corrupting customer data.

You won't remember why your optimizations were optimizations, and you won't remember what the tricks were. Comment liberally and don't over-optimize - be 'tricky' only when it counts, and brute force it the other 95% of the time.

Lastly, not understanding scheduling. When your boss tells you to do something impossible, the best response is "That's impossible in the remaining schedule", not frantically working 18 hour days for 2 weeks until you produce something that still blows up 30% of the time because you were so exhausted by the end.

Pulling all-nighters makes you appear heroic in College. Your boss thinks it looks like you don't know how to schedule. There will _ALWAYS_ be "crap that appears out of nowhere". Put some slack in your estimates.

Re:I'm Interested in the Opposite View

[macs4all]

Self-taught folks tend to have less in their toolkits -- when all you've learned is a hammer, everything looks like a nail. Then, when trying to do something different, they try to take their hammer and "invent" a screwdriver out of it.

...and when all you're taught is algorithms, everything tends to look like a math problem.

In other words, what's your point, exactly? There are good and bad self-taught and degreed programmers alike. Having a degree (or lack thereof) is absolutely no guarantee that you will or will not get working, well-designed, well-factored code in either case.

The breadth of the slashdot crowd should have enough collective experience to realize that the incredible range of applications negates the practical usefulness of such blanket assumptions as "Degree good, self-taught bad", or vice-versa. Things just aren't that simple.

Re:I'm Interested in the Opposite View

[sjames]

Enlarging on 3, when an error cannot be recovered from, it MUST be logged with a short sweet and exact error report that can be reliably conveyed back and then terminate unambiguously. Error code 7876sd6w34ui13489sdgh is not acceptable, some poor sap will end up having to copy it down by hand, will inevitably transpose characters and you'll be looking at entirely the wrong part of the program for the problem. (I'm talking to YOU Microsoft!)

I'll add point 4, POLISH! In the real world we're not all that interested in toy programs that prove that you understand the basic concepts, that's the prerequisite. We are interested in polished programs that don't crash. We're also interested in programs that can be maintained by others.

That leads to 5. We do not care if you save 3 CPU cycles per year with your 3 lines of incomprehensible cyphertext. Half a page of straightforward code is much better for the next guy. However, if you can get a SIGNIFICANT speedup, do so and see point 6:

Point 6, save comments for the non-obvious. In a for statement, I *KNOW* i is the index, what I'd like to know is why it goes from 0 to log((j+2)/3 +6). I especially want to know if it seems like it should be log((j+2)/3 +5) but that didn't work so you made it +6 without understanding why.

7) DO use other people's work! This is not a test, it is not cheating. However, don't copy/paste it, ask that it be moved to a utilities module and call it.

8) learn when to bend the rules. Somewhere between the formal academic answer of NEVER! and the cowboy coder's ALWAYS! lies the correct balance. Only experience and taste can tell you where that point is.

Organisation, Algorithms

[Anonymous Coward]

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

[spottedkangaroo]

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.

Big-O. No, not *that* big O.

[hobb0001]

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.

[Anonymous Coward]

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

Use Google to fill the gap

[somejeff]

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

[Satis]

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

[smbell]

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

[SurgeryByNumbers]

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.

Re:Proper code analysis

[LordKazan]

"Can be picked up on your own" and "were picked up on your own" are rarely the same thing. I was a self taught programmer until high school, where there was CS class (And later AP CS) taught by a former Apple Newton platform lead developer. As a self taught, I was fairly typical from everything I read.

He took that raw talent, and enthusiasm, and turned them into real talent.

Are there truly wizard self taught programmers? Absolutely
Are most self taught programmers just practicing BFI? Absolutely.

If you don't know where you've been...

[fmayhar]

I've been doing this for a few years and the one gap I'm seeing more and more of doesn't actually have anything to do with programming techniques, "design patterns" or anything else that's hugely technical. All of these things are pretty well-known and accepted by everyone, and you can always be sure that there'll be someone around pushing one or another of them as the be-all and end-all of Programming.

The one gap you might have as a self-taught programmer is in fact in the _history_ of computer science. There's a lot of stuff that has happened and in fact people keep finding and solving the same problems, never realizing that the problems have been encountered and solved many times. (An example that's particularly relevant to me at the moment has to do with extent-based file systems; ext4 has extents and so do a number of new file systems. Great idea, right, particularly for large file systems? Thing is, extent-based file systems have been used at least since the 70s in mainframe operating systems. Odd that it took 40 years to get it into Unix.)

But don't feel bad that your self-teaching has skipped the history of computing. It appears that most university computer science programs neglect that little bit of background as well, in favor of jumping straight into C++ or Java.

Maybe I'm an old fart but that half-semester of history I took back in 1981 made a small but significant improvement in my ability as a software engineer.

Re:If you don't know where you've been...

[fusiongyro]

Second that, emphatically. Simply knowing who the main contributors to CS and what their achievements were would get most anyone a long way forward.

Algoritms

[Anonymous Coward]

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.

Re:Algoritms

[macs4all]

But most self-taught programmers I met just learned syntax.

I said it before, and I'll say it again: The plural form of "anecdote" is not "data".

Design and Adaptability

[Temujin_12]

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

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

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

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

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

Re:Design and Adaptability

[Anonymous Coward]

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

Wow, how wildly far you are off from the truth! I mean really WOW.

From experience, as a self taught, that might seem like it. I persevere with design patterns, but not because "that's what it is for me" (i can just as easily write MVC or Q'n'D style, just as well as "regular relational" or EAV, just task matters), but because that is the superior, most productive way to accomplish a task. And no, i do not remember a series of seemingly arbitrary facts, quite the contrary. Those learning the seemingly arbitrary, irrelevant and out-of-context, facts are the schooled people. Why i so strongly speak for say MVC? Because implemented correctly, with the understanding of WHY means productive does not just increase few percentage, but potentially many times over. Hell, when my colleagues started to talk about MVC i was just like "Oh, that ancient design paradigm? Yeah, who cares", and colleagues was like "hey, this is the newest, latest and greatest in web development", "oh so what? Whats so great about it then?", "Well model view and controller are separated they handle this and that tasks", "Oh, i've been doing like that, but simplified further, for past 7 years. So what's the big deal now with it?". And that's from our actual conversation, i didn't initially connect the dots between MVC and the design pattern i used for larger projects. Why? It was better, i didn't care about the irrelevant information.

Sure, that sometimes makes for funnily controversial, or confused conversations. But that Programmaticus Greatis Algoritmis what's oooh so academic like, just tell me what it is in real english language, and most likely i've seen, used and conquered already in the past. Just different terms.

I work in a smallish office, where some people have over 10 years of web development expertise, and coded way more than me, in terms of hours spent coding and in terms of LOC. Yet, it's a known fact in the office that i'm the most productive, and produce the easiest code to maintain, and if needed also the best performing. Did you need architecture of the system, or low level optimization, i'm the guy you talk to. Oh and my colleagues are all well schooled, we are all about the same age, and from roughly the same area (within 30km or so radius). I'm the only self taught guy in our company,and the only one with practically no school, and were practically with no professional development expertise. Now? I'm one of the executives, handle the biggest projects, and besides coding also handle our web hosting services and ISP side of business in executive role. Just 1½yrs later ...

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

Again quite the contrary. I'm having really hard time to make the most schooled, supposedly the most intellectual person in our office to break his bad coding habits, such as no commenting what so ever, or close to 10 function calls in a single line INCLUDING initial data fetch, copy paste code, mixing and mashing of business logic, UI and data operations.

Re:Design and Adaptability

[Anonymous Coward]

About adaptability: What you don't get is that some self-taught people are true scientists in disguise. They stick to some metodologies/tools not because they are lazy. Have you considered that they have tried them all and are sticking with the best one, which combined with (as I said) a scientific soul, I mean, someone who is honest and wants to understand everything down to the little -and very important- details make the best analyst/programmers you could hope to hire. Of course, they could be delusional idiots who think they are good, but those are easy to weed out, much more easy than the morons that come with a gazillion of 'certifications' by Microsoft and Cisco that your HR dept will think are any good. In any case, the surefire way to hire some sheep that will never excel at anything, is to go to the 'programming schools'

more than just code

[Sbones]

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

Physic Majors/Programmers Unite!

[ViViDboarder]

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.

Re:Physic Majors/Programmers Unite!

[GrantRobertson]

All the physicists I know are now programmers.

ComSci is mostly about how to approach problems

[thaig]

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

[OakDragon]

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?

Re:ComSci is mostly about how to approach problems

[thaig]

My terminology is poor. Sorry. Try Object Oriented Database Management Systems OODBMS.

e.g.
http://www.25hoursaday.com/WhyArentYouUsingAnOODBMS.html
http://www.service-architecture.com/object-oriented-databases/
http://www.ozone-db.org/frames/home/what.html

Basically you write a normal program and you say what data structures you wish to be persistent. (e.g. the object representing your addressbook in an email program for example). That's really all you have to do. The next time you run your program that data structure and it's children start off with the values that they had when your program last ran.

i.e. there is none of the garbage that you have to deal with when you try to convert some in-memory data structure to fit into tables.

Your in-memory structure simply persists.

There are "checkpoints" and issues with versions (i.e. how old data is converted when you update your classes) but it is all really the kind of stuff that you'd have to deal with in any other database.

IBM AS/400s have one of these and they have enduring popularity as midrange servers.

Re:ComSci is mostly about how to approach problems

[OakDragon]

Thanks for the info.

Size Matters

[Dark_Matter88]

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

[LCValentine]

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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Great question! - a list from my experience

[david.emery]

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 - 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 :-)

Finite State Machines

[Anonymous Coward]

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:Finite State Machines

[kirillian]

Agreed...because I work for a small company that tries to do more than it really is capable of, I find myself with another project dropped into my lap that needs to be done yesterday that I can only conceivably complete by temporarily adding another state or condition to the code that I already have (in small companies, scalability is NEVER a concern - only accomplishing the task...it sucks...but it is reality). Finite State Machines are my friends. I probably have an entire stack of papers floating around my desk full of my state machine drawings that I used to organize various problems that I've had to solve over the course of my time here.

As for the original post, being a half university taught and half self-taught programmer, I would say that it definitely depends on the person. I don't know how it works exactly, but the BEST and brightest programmers (i.e. problem solvers) I've met have all worked for small companies or doing contract work. However, the best code-writers all seem to work for the big corporations (obviously this is based only on anecdotal evidence...). I guess it makes sense though - the corporations need the good code writers to maintain their scalability and the small companies definitely need the good problem solvers to deal with the daily emergencies that just evolve from the natural overconfidence of a small company with growing pains. Maybe people just kinda gravitate where their skills are most useful.

Usability studies

[Anonymous Coward]

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

[jjhplus9]

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)

Predating Design Patterns

[geek2k5]

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

[david.emery]

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

Goto

[gmuslera]

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.

Re:Goto

[Anonymous Coward]

Goto may create hard to follow "spaghetti code", but also consider this:

The function/procedure call is the GoSub and the return is, well the Return. The evolution of programming really didn't change the GoSub/Return concept made easy to understand in the BASIC language, it just added complexity and obscurity to it.

Really, are the newer languages actually enabling people to program their computers with the most functionality/least amount of lines of code possible or are the languages becoming more and more complex and obscure such that one might as well revert back to assembly language or even machine language?

Depends...

[Anonymous Coward]

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

[kungfugleek]

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

Re:You haven't learned...

[Anonymous Coward]

You mean the in's and out's of project management? The look and feel for the entire software life-cycle? The fact that when you present your effort estimate to the boss, he's going to cut it in half and tell you you're fired if you can't do it?

That stuff?

Things I found usefull

[utnapistim]

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

[subanark]

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

[N0t4v41l4bl3]

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

Re:Passion

[Tablizer]

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

Passion to make "cool" eye-candy or passion to make systems maintainable by other people?
   

Re:Passion

[mini me]

What is the difference? The absolute most important aspect of maintainable code is the visual aesthetics of the code. If the code looks appealing and inviting at first glance people will want to work on it. On the other hand, code with a theoretically perfect architecture, but without visual appeal will not be fun to work on at all. This is basic human nature.

If you are unable to make "cool" eye-candy, you probably are unable to write maintainable code either. They are of the exact same discipline.

Re:Passion

[Tablizer]

Novelty wears off after a few days and users start to care about having it work right and effectively beyond shiney spinning red toys.

Re:Passion

[macs4all]

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

Are you hiring (seriously!)?

Fundamental CS, algorithms etc.

[eastsidephil]

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

Re:Fundamental CS, algorithms etc.

[Anonymous Coward]

It's an excellent textbook, although perhaps not that gentle an introduction.

Whether it's practically useful or not depends a lot, it will potentially teach you a lot of tricks and ideas to use if you encounter a new technical problem you need to solve (although in reality, that doesn't happen so much with most business software). I was originally self taught and a lot of the earlier programs I wrote I did things in very suboptimal ways simply because I didn't realise that there should be a better way.

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:Maintenance programming

[Anonymous Coward]

I'm a code monkey (not even glorified), self taught on the job. I've a coworker that is fresh out of college. It's just the two of us plush our boss. This "blank sheet" idea perfectly describes his though process. We have code in our system going back 20+ years. It's ran, relatively error free for all this time and has been fairly well debugged. He comes in and scraps it and replaces it with a brand new program done "his way". And now we have bugs out the ass in our systems.

I think I'm going to start looking for a new job as a ditch digger.

physicicts and code...

[Anonymous Coward]

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

[Anonymous Coward]

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

[Lemming Mark]

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

[BadKneeDad]

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

Re:Programming vs. Computer Science

[Jane Q. Public]

If "meetings, documents, technical support, design and maintenance take up a lot of your time", then you are doing old-school programming and should be thinking about going Agile (if your company will let you). Agile is a methodology designed, in part, precisely to make sure that meetings, documents, etc. do not eat up all your time. There is a lot more to it than that, but that is one of the driving forces of its existence.

It is as likely as not that OP is already past the old-school "waterfall" programming paradigm and working in an Agile environment.

Re:Programming vs. Computer Science

[BadKneeDad]

if your company will let you

Like I said, meetings, documents, technical support, etc will take up a lot of your time. :-)

Find a mentor

[azadrozny]

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.

Re:Find a mentor

[plcurechax]

This reminds of a series of books Robert Glass published in the 1980s, that I read as a kid. It served as a fun way to learn a bit of computing history, and gain experiences in the reading RISKS digest (comp.risks) sense.

• The Universal Elixir and Other Computing Projects Which Failed (1977)
• Computing Catastrophes (1983)
• Computing Shakeout (1987)

They are fun, short reads, but learning from other's failures can save you time. :)

Project management, no doubt.

[Anonymous Coward]

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.

Re:If you want to learn some compuational theory..

[AlgorithMan]

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

Algorithm Analysis

[zimage]

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
http://en.wikipedia.org/wiki/Big_O_notation

Re:Algorithm Analysis

[macs4all]

One of the biggest ones I've seen is that self-taught programmers tend to not think about algorithm efficiency

Speak for yourself. As in the vast majority of the "negative" comments to this article, what people are REALLY complaining about is BAD programmers.

As a self-taught embedded hardware/software developer (100% self-taught on both fronts), with 30 years of experience, specializing in real-time control and instrumentation systems (often with pretty puny computational power), I can assure you that "algorithm efficiency" is something I learned early, and well.

Lack of Broadness

[Sloppy]

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

[Anonymous Coward]

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

[plcurechax]

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, Structured Computer Organization, and Introduction to Algorithms 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, and the IEEE Computer Society. 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

[michaelmalak]

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

[cduffy]

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.

SQL, SQL and more SQL

[Neeperando]

I am about half self-taught and half college-taught. I am currently looking for jobs, and despite having 10 years programming experience and knowing more than a handful of languages, understanding OO and algorithms, I don't have the minimum requirements for most jobs I'm looking at. Why? I don't know SQL well. It's one thing if you're looking to work at a major, kickass place like Google or Microsoft, but a lot of the smaller shops are looking for people who can write client-server code in Java and SQL. If you don't have that, 80% of the jobs on Monster are off the table.

Re:SQL, SQL and more SQL

[Unordained]

Don't feel too bad.

In my experience, at least half of the programmers with degrees don't grok databases at all, and should never be given access to the database. It's not just SQL, either. Sure, they can muddle their way through a select, maybe a group-by, they might even attempt a few joins -- but they have absolutely no clue how to design a database properly, what NULL is for, what foreign keys are for, what cascade rules are for, what triggers are for, what views are for, what LEFT vs. RIGHT vs. INNER do (those are the ones they use -- they also have no idea about FULL OUTER, but luckily don't use it, except by accident, in an unqualified join). They're a terror upon the database, and should be kept out until tutored. And then you can teach them about transactions, isolation levels, connection pools, savepoints ... It's a whole new world to most programmers, even the ones who *think* they know databases. As far as they're concerned, what their database class taught them, databases are just blind repositories for data, a convenient replacement for some other datastructure like a list, vector, map, or set. Ugh. Maybe it's because they're taught all database systems are the same, and taught the absolute bare-minimum / common-denominator stuff. Maybe it's because they're taught file i/o first, and databases are an after-thought. I don't know why it's so rare to see anyone with a clue.

Re:SQL, SQL and more SQL

[Neeperando]

Well that's exactly my point. I am a good programmer, even great when I'm in my element. But you have (almost creepily) described exactly my knowledge about databases and exactly my gaps. Everything I know about SQL I learned from hacking around with web programming and Android using SQLite on my own time.

But in the real world, how much software DOESN'T use a database in some form as its backend, if you look at it as a percentage of all the software being written? How many jobs are out there that require C++ and Linux (like I and all my college-educated CS buddies know), vs. how ones that require Java, ASP .NET or C#, and 3-5 years experience administering a SQL or Oracle database?

I wish I would've learned databases at school, so at least I could plausibly CLAIM I knew something about databases. Now I'm just screwed unless I start writing my own websites or something, which I really just don't have time for.

Re:SQL, SQL and more SQL

[Unordained]

I wish I could point you to a good book on the subject. Date & Darwen are too theoretical, Celko is too tricksy. You're not an idiot, you're just ignorant, you don't need an idiot's guide; you want to come fully up to speed, no just get your feet wet, you don't need a "in 24 hours" book; you want to know how to use it, not every last option available, you don't want a "complete reference." Looking at the list of books on amazon, none stand out as useful. Maybe I'll just have to write it.

I'm trying to find out what book it was I (permanently) lent to a fellow programmer way-back; when I find out, I'll at least respond. I'm pretty sure it didn't cover "active database" features (triggers, procedures) though. I wish there were a good, database-agnostic way of teaching those, too (for the fundamentals).

Re:SQL, SQL and more SQL

[Unordained]

Better late than never? The book we handed to new-hires was "A Guide to SQL, third edition" by Philip J. Pratt. It appears it's gone through quite a few editions since then, and it's been years since I looked at it -- the Amazon reviews may be accurate, it may suck. Sorry!

Re:SQL, SQL and more SQL

[Neeperando]

Thanks very much, I'll look into that!

Repositories, code reviews, flexibility

[Fastolfe]

1. Learn how to use source code repositories (including branching, merging, and resolving conflicts), and how organizations do releases
2. Learn how to do code reviews, and how to adapt to local practices and style guides.
3. Learn how to be flexible.
4. Be humble.

Self-taught programmers frequently develop and religiously stick to their own favorite practices, code formatting, programming languages, IDEs, etc. When you're part of a team, though, your code needs to be readable, understandable and maintainable by other members of the team. This means learning how to be flexible and work effectively outside of your favorite language/environment. Some of this you can get by participating in some open source projects, and active participation in open source projects is something I look for on resumes when a candidate seems to be self-taught.

Relational database design

[Anonymous Coward]

Heck, I think students who didn't opted for that RDBMS design class would design tables in complete different ways than one who does. For example, I tend to design and interpret tables with relationships (one-one, one-many, many-many) first, and then fill in the PK/FK later, while some colleagues just start with table and keys at the same time. Or, I can look at a set of tables designed by someone else and find that it makes no sense when you draw out the tables using "chicken feet" diagrams.

Both Self-Taught and School-Taught Have Gaps

[Phleg]

Both self-taught programmers and school-taught programmers have gaps. I feel like I got pretty good exposure to both scenarios, since I was self-taught but did go to college, where I had some of those gaps filled in (and also took plenty of courses where I learned precious little).

Some things that self-taught programmers often lack are,

• an intuitive notion of algorithm running-time (i.e., big-O)
• design patterns, and how to create new ones.

There's others (compiler theory, AI, whatever), but in practical software development those are the two that come up most often. But I find that self-taught programmers are often better at what they do than school-educated ones, because they are sensitive to the gaps they have, and they know how to learn things on their own.

School-taught programmers on the other hand have far, far more gaps in my experience. They often lack

• understanding of and experience with version control
• the ability to write software for others to use or maintain
• the ability to teach themselves new languages or tools.

In my opinion the main problems with current Computer Science curricula are that the professors themselves are heavily isolated from real-world application development. Courses on version control (especially newer tools like git or mercurial as opposed to CVS) are virtually nonexistent. Courses that teach students how to structure code for others to use (ex., writing code as a library for others to link against) don't exist. Because Computer Science courses are isolated from real-world needs like maintenance and working with others, the only criteria students' code is judged on is whether or not it produces correct output.

Students learn one or two languages, but virtually always languages that share roughly the same syntax (e.g., C++ and Java). Very little time is spent on highly-productive scripting languages like Ruby, JavaScript, or Python. And students are never taught to adapt their solutions to the strengths of different languages. If they learn Java first, every program they write will try to solve it the "Java way". Not to pick on Java — the point is simply that nobody is taught to identify and use the strengths of languages, or learn their common idioms, so they just write everything like it's their Language of Choice.

Re:Both Self-Taught and School-Taught Have Gaps

[Udigs]

Couldn't agree more. The most valuable skill in a programmer is really the ability to quickly master new things---and to think creatively about them. Technology changes so far, fundamentals are very important, but not at the cost of not being able to adapt.

No, Learn C++

[Kensai7]

I'm learning C++ using Stroustrups's 2009 "Programming -- Principles and Practice Using C++" textbook. This book is huge, but well-written for both first-semester college students and self-taught programmers.

I opted for C++ instead of C because I wanted a multiparadigm language to help me learn different approaches to coding. The procedural paradigm is strong and useful to learn how computers work in low level, but I C++ provides with other useful paradigms as well which might come handy when you jump to another language. Afterall, learn C++ at an adequate level and then most other computer languages should be easy to comprehend.

Nevertheless, programming is expressing some ideas in code. To get these ideas and put them down in useful algorithms is another story. Perhaps in a formal Computer Science or Software Engineering course they learn about how to design the algorithms by practicing elegant abstraction techniques.

Re:No, Learn C++

[SanityInAnarchy]

I wanted a multiparadigm language to help me learn different approaches to coding.

And for that, you chose C++? Really?

Not Ruby, not Python, not even Javascript? C++?

learn C++ at an adequate level and then most other computer languages should be easy to comprehend.

Except Lisp. And purely-functional languages, like Haskell. And interesting things like Erlang -- immutable, non-shared memory plus message-passing. And...

Learn one language well, and other languages will be easier to pick up, yes. But calling C++ "multiparadigm" is like calling Java "Object-Oriented". It makes you sound smart, and it even makes sense when you know a little about the subject. Then you learn what the term actually means, and you see a language which actually does that successfully -- Ruby is object-oriented in a way Java can only dream of.

Re:No, Learn C++

[Kensai7]

And for that, you chose C++? Really?

Not Ruby, not Python, not even Javascript? C++?

Yep. Why not? :)

C++ is multiparadigm, powerful, alive and kicking (waiting for the new standard actually), and had a new textbook for beginners from its original implementer. It also has many libraries that emulate programming paradigms not directly supported by C++ such as logical or functional, among many many other.

Except Lisp. And purely-functional languages, like Haskell. And interesting things like Erlang -- immutable, non-shared memory plus message-passing. And...

Hey, give me a break. I used the word most for a reason. Of course you can find exceptions. No language is perfect, but some are simply more powerful and supported than others. D is probably better than C++, but I wouldn't invest on learning it.

Learn one language well, and other languages will be easier to pick up, yes. But calling C++ "multiparadigm" is like calling Java "Object-Oriented".

I call Java object-oriented without problem. :)

It makes you sound smart, and it even makes sense when you know a little about the subject. Then you learn what the term actually means, and you see a language which actually does that successfully -- Ruby is object-oriented in a way Java can only dream of.

Whatever. The thing is Java is being taught as a first-language to academic departments for a reason, because it's easy and object-oriented. Ruby not so often. I chose C++ for technical reasons and specifications, not because I was searching a hobbyist language to learn programming. In my field C++ and Python are the tools.

If I had to learn a language simply for hobby I would probably pick something high-level such as Scala.

Re:No, Learn C++

[SanityInAnarchy]

C++ is multiparadigm,

Well, this is the part I was challenging. Basically, C++ can be procedural or pseudo-OO in the same way Java is.

I used the word most for a reason. Of course you can find exceptions.

How about Lua, Scheme, Smalltalk, OCaml, Forth, Ada, Bash, Io...

I mean, sure, there's C, C++, Java, simplistic Ruby and JavaScript, and a few languages which do fit the model, but I'd hardly say "most".

No language is perfect, but some are simply more powerful and supported than others.

The question is, which is more important, power or support? And how much does the support actually matter?

For example, you mention many libraries that emulate programming paradigms not directly supported by C++. Using a language which supports those paradigms natively eliminates the need for those libraries. What libraries do you have in C++ which can't be accessed elsewhere?

It seems to me that most libraries will expose some sort of decent C API, so if nothing else, you should be able to write a binding yourself relatively easily if you know C. From past experience, the number of times I've even been tempted by that is so small, I'd say productivity gains in the actual code I'm writing far outweigh them.

I call Java object-oriented without problem. :)

Maybe this will help: "I invented Object-Oriented Programming, and C++ is not what I had in mind." -- Alan Kay.

The thing is Java is being taught as a first-language to academic departments for a reason, because it's easy and object-oriented.

I don't think that's the reason. The course I'm taking now used to be taught in Scheme -- I suspect they switched to Java because people will hire someone who knows Java, because they're either using Java or something slightly similar -- they're not using Scheme.

I think that's a profound mistake. I want an actual education. If I just wanted technical training, I'd go to a technical school.

Ruby not so often.

Not so often chosen, sure. Or are you saying it's not often easy?

Really? I mean, think about your first day as a computer science student. Which do you want to try to understand:

#!/usr/bin/env ruby
puts 'Hello, world!'

or, hey, I'll give you Python:

#!/usr/bin/python
print 'Hello, world!'

Or how about this one:

class Hello {
  public static void main(String [] args) {
    System.out.println("Hello, world!");
  }
}

And it better be in a file named Hello.java (case sensitive!) or it won't work. And yes, they actually tried to explain everything in that program.

I chose C++ for technical reasons and specifications,

In other words, because your boss told you to? That's a fair reason, but not a reason to tell someone to learn C++. Learn what will make you a better programmer, or learn what you like. There are plenty of Ruby jobs, even a few Erlang serious erlang jobs.

In my field C++ and Python are the tools.

May I ask which field?

If I had to learn a language simply for hobby I would probably pick something high-level such as Scala.

Ruby isn't high-level enough? Not that I'm against Scala, I honestly haven't seen enough of it, though I do tend to react badly to complex languages...

Re:No, Learn C++

[SanityInAnarchy]

I think I should justify the "Java is not OO" bit. Here's a short list:

Java uses primitive types like 'int'. These can be wrapped in objects (like Integer), but the primitive types are still floating around.

Java is strictly typed. Technically, this doesn't disqualify it, but I think it gives people the wrong idea of what OO actually means -- for instance, classes are not required at all for OO.

Java allows public member variables, and these are accessed differently (complete with different syntax) from public methods. Contrast to Ruby -- you communicate with an object by sending messages. -- if you want something to be public, you define an accessor, and it's much easier to do than in Java. Even Erlang is closer than Java, if you consider a process to be a strange sort of object.

I think those are the main objections to it being object-oriented. Other objections include the lack of proper closures and the sheer verbosity of the language. Static typing is bad enough, the way they implemented generics is just gross...

When I rip into Java, the response I usually get is that "no language is perfect". Granted, but I can point to languages which are better than Java in pretty much every way I care about, and the only way I can possibly see anyone preferring Java is if they love static types, and I've very rarely met anyone who's actually done real work in a dynamically-typed language and prefers static types.

Re:No, Learn C++

[Kensai7]

Gee, you have some free time to respond point-to-point to my quote-to-quote answers! :p

Ok, the field is Computational Neuroscience and most toolkits you will find for simulations are in C++ and Python.

By any means, C++ and Java are object-oriented languages even if they are not the best or most pristine OO languages out there. (I read your post about Java not OO below). C is ok, but I don't like it because it doesn't support at all OO. Maybe Objective-C if you want to learn proprietary Apple languages.

Anywho, I think C++ is a powerful language that you can do almost anything with it: from writing device drivers and embedded programs to high-level software developing using GUIs (with Qt) or HTML/CSS/JavaScript (with Wt), among other libraries and frameworks. In fact, I don't have to choose between Power and Support because C++ has them both. :)

It is true that it is a difficult language to learn (and even more to master!) but most of its concepts and perks have found one way or another to other languages it has influenced after C++ was invented. And there are many: even Google's last-year Go! I will not try to convince you anymore, you are entitled to have your opinion about C. For me C is the "grandpa" of it all, but I wouldn't want to use it for a new project rich with GUIs and Internet stuff. C should be praised for its syntax.

This thread is about self-taught programmers and their gaps. Well, by learning C++ (with Stroustrup's book at least) your programming gaps will be minimized to the few mainstream paradigms C++ is not covering directly and, of course, all those theoretical notions (maths, algorithms, etc) a CS course offers.

C++ is a great intellectual investment to any software developer, amateur or professional s/he is. From there, anything else is downhill.

As Steve Yegge puts it: GO UGLY EARLY!

Re:No, Learn C++

[Harik]

I prefer static types, because when I deal with a project in maintenence mode it's a serious PITA to hunt down every caller and see what types they can possibly call the broken method with.

Runtime typechecking is more accurately "crashtime type checking", good luck managing to keep a system completely operational after you throw an exception deep within a legacy library.

I suppose it depends on what you're doing, I see more usage of dynamic typing in webwork than anywhere else.

Re:No, Learn C++

[SanityInAnarchy]

By any means, C++ and Java are object-oriented languages even if they are not the best or most pristine OO languages out there.

I suppose the problem is that the main selling point of C++ and Java is their object-orientedness, but it's not that they aren't the best -- they're some of the worst. There are even things I like about Perl's OO over C++ and Java.

C is ok, but I don't like it because it doesn't support at all OO.

Nope, you can do OO in pretty much any language, the question is how easy it is. C supports structures and function pointers.

Maybe Objective-C if you want to learn proprietary Apple languages.

There are free implementations of Objective-C, including one for GCC. I don't know how you'd call it "proprietary" at this point.

C++ is a powerful language that you can do almost anything with it

Well, yeah, it's Turing-complete, but you're going to have to be very specific about what you mean by "power".

from writing device drivers and embedded programs

You've got me there, though I would suggest that C might be better for that purpose, and Google's Go certainly looks interesting.

to high-level software developing using GUIs (with Qt)

The backflips Qt has to go through, and the sheer verbosity, just make me cringe. Have you used Shoes, in Ruby? I'm not saying that's necessarily "better", but it might help you understand why C++ wouldn't be my language of choice for a GUI.

or HTML/CSS/JavaScript (with Wt),

At which point, why bother with C++?

In fact, I don't have to choose between Power and Support because C++ has them both. :)

Again, you need to be much more specific about what you mean by "power". Lisp is powerful. I could make a case that Ruby is powerful, and Javascript is powerful. C++ is not powerful -- your definition of "power" seems to be "I can use it for a lot of different things", which is also true of assembly language. The question is whether it's anywhere close to a good fit.

It is true that it is a difficult language to learn (and even more to master!)

I would argue that it's impossible to "master", and that the people who have come closest are the people who deliberately limit themselves to a subset of C++. I mean, someone even proved the template declaration system itself is Turing-complete. Contrast to C, which is almost simple enough for the syntax to be taught on the back of a napkin.

For me C is the "grandpa" of it all, but I wouldn't want to use it for a new project rich with GUIs and Internet stuff.

Neither would I, other than to connect to the libraries I need (which are likely written in C), but nor would I want to use C++. I see C++ as C plus Java-like OO (and I hate Java), plus a ridiculous amount of complexity that makes Java's generics look like a cakewalk.

Yes, I have written C++ code. I'm not trying to claim that it's impossible to use. My point is, rather, that this complexity and shoddy design means that there are much better choices for most applications. The one exception is speed, and even Java beats C++ in some benchmarks -- it seems like if you want speed, you optimize the tight loops and replace them with C (if you started in a scripting language), and then with assembly (if you're in C) -- it doesn't make a lot of sense to use C++ throughout.

This thread is about self-taught programmers and their gaps. Well, by learning C++ (with Stroustrup's book at least) your programming gaps will be minimized to the few mainstream paradigms C++ is not covering directly

Well, closures are huge, and you're going to need them in Javascript, which you're going to need if you do any web work. Prototypal inheritance is jus

Re:No, Learn C++

[SanityInAnarchy]

I prefer static types,

I guess the next question is, how much real work have you done in a dynamically-typed lanugage?

it's a serious PITA to hunt down every caller and see what types they can possibly call the broken method with.

Why would you want to? This is why I ask what work you've done -- I can't recall ever, in all the Ruby or Javascript work I've done, seeing a method called with the wrong type, or wondering what type a method should be (or is being) called with.

And I was doing crazier things than you seem to be suggesting -- in JavaScript, I can quite literally pull a method out of one object and insert it into another object, on the fly. Yet somehow, proper design meant I never had type issues.

Runtime typechecking is more accurately "crashtime type checking",

Or, if you've done your job right, test-time checking. Static type checking could be seen as a subset of unit testing.

good luck managing to keep a system completely operational after you throw an exception deep within a legacy library.

Yep, but that applies to things other than type issues, and it would again likely be caught by proper testing. Type checking won't save you from these sorts of issues. Testing won't necessarily save you, but it'll be much more likely to do so than type checking.

In other words: If you test properly, type issues probably won't hurt you. If you don't test properly, type checking won't save you.

I see more usage of dynamic typing in webwork than anywhere else.

I think that has to do with two things -- the need to get to market first, and the choice of hardware platform. If you wrote a new video game in Ruby, and your competitors used C++, your framerate would suck relative to theirs, and you can't exactly tell your users to buy ten times the hardware to make up for it. But if you wrote a new webapp in Ruby, and your competitors used C++, you'll hit the market before they have a working prototype, and you can buy ten times the hardware if you need to.

Re:No, Learn C++

[Anonymous Coward]

If you haven't implemented an immutable, non-shared memory plus message-passing model in C++, then you're not doing anything interesting.

Corollary: most people who know C++ have never done anything interesting.

I don't confess to know C++, but I've done all those things and more in C. I'm not afraid to use a domain-specific language when necessary, but I am often wary of the commitment it takes to wed a project to such languages unless I know it's the absolute right thing to do. When I need a language that does cool things I tend to use Lua+C, which makes it rather easy to use all sorts of patterns and paradigms, including functional ones.

Re:No, Learn C++

[SanityInAnarchy]

If you haven't implemented an immutable, non-shared memory plus message-passing model in C++, then you're not doing anything interesting.

Well, you can also do object-oriented code in C, and you can do OSes in assembly. You can also write C compilers that target the JVM, or Ruby interpreters in Javascript, or...

You can do anything in any Turing-complete language. That doesn't mean you should, and it helps immensely when the language is helping you out rather than getting in the way.

As far as I know, Erlang is written in C, so again, you're technically right. That doesn't mean I want to do that in C when I could do that in Erlang instead, any more than I'd want to add concepts like functions, arrays, and structures natively into assembly when I've got C already.

Re:No, Learn C++

[Anonymous Coward]

Why not learning Java??
C++ is only C with an OO wrapping, while Java is a language with OO in mind from the start.

Re:No, Learn C++

[Dixie_Flatline]

It is true that it is a difficult language to learn (and even more to master!)

I would argue that it's impossible to "master", and that the people who have come closest are the people who deliberately limit themselves to a subset of C++. I mean, someone even proved the template declaration system itself is Turing-complete. Contrast to C, which is almost simple enough for the syntax to be taught on the back of a napkin.

I remember about 8 years ago, there was some excitement because someone finally proved that the language specification didn't have a bad recursion in it somewhere, and it was, in fact, possible to write a parser that fully encompassed the full specification.

8 years ago! This language has been around for an awfully long time for them to only just discover that it wasn't BROKEN.

This is why C++ ends up so non-portable. Different companies implement different parts of the specification based on what they think is most important. And we're talking about really smart people here. Say what you want about Microsoft, they've got a bunch of clever dudes working there and an awful lot in the way of resources, and even THEY weren't implementing the full specification.

And Templates, well, like you said, they're a Turing complete language in and of themselves. Ultimately, they're an answer to a question that should NEVER HAVE BEEN ASKED. It's a patch bolted onto the side of C++. Ask even a hard-core C++ fan and they'll admit that a number of the things really interesting about the language are DISCOVERED. They weren't planned, they just cropped up.

The language is brutal. Nobody leverages the whole thing because it's well nigh on impossible, and ultimately unnecessary. I work in the games industry and nobody uses the really esoteric parts of the language. We stick to a well known subset of the language because it's easiest to maintain and modify.

A friend of mine once said that because the core tenet of C++ is that you don't pay for anything you don't use, ultimately, there's nothing worth paying for.

Re:No, Learn C++

[Harik]

I prefer static types,

I guess the next question is, how much real work have you done in a dynamically-typed lanugage?

Mostly cleanup of other people's work. Most of my work is in systems or embedded level, and as you pointed out below, that's not something you can generally throw 10x the hardware at. I'm most fluent in the C-syntax languages (C, C++, Java, PHP which is... well, PHP), although I've hit a good chunk of the procedural languages over the years (Python, ruby, lisp being the big names).

Is sendmail.cf considered turing complete? :)

it's a serious PITA to hunt down every caller and see what types they can possibly call the broken method with.

Why would you want to? This is why I ask what work you've done -- I can't recall ever, in all the Ruby or Javascript work I've done, seeing a method called with the wrong type, or wondering what type a method should be (or is being) called with.

And I was doing crazier things than you seem to be suggesting -- in JavaScript, I can quite literally pull a method out of one object and insert it into another object, on the fly. Yet somehow, proper design meant I never had type issues.

It's probably because most of my work on dynamically typed languages are when someone DIDN'T properly design, and I get to fix it. Or more commonly, someone did design it properly, but they went on to bigger and better things, and someone else made some changes that seemed to work, until another piece somewhere else came online and.... The normal bitrot you see on projects.

Runtime typechecking is more accurately "crashtime type checking",

Or, if you've done your job right, test-time checking. Static type checking could be seen as a subset of unit testing.

"testing" gets pre-empted by "deadlines". You don't get called in to panic-bugfix a system when they implemented "testing" properly.

I see more usage of dynamic typing in webwork than anywhere else.

I think that has to do with two things -- the need to get to market first, and the choice of hardware platform. If you wrote a new video game in Ruby, and your competitors used C++, your framerate would suck relative to theirs, and you can't exactly tell your users to buy ten times the hardware to make up for it. But if you wrote a new webapp in Ruby, and your competitors used C++, you'll hit the market before they have a working prototype, and you can buy ten times the hardware if you need to.

That honestly depends on a lot of things, I wouldn't write a 3d rendering engine in ruby, but it might be the right call for the slower-paced scripting of game events. Right tool for the job and all that. Back to dynamic typing - what's a specific thing that you can do (in a well-designed system) with a dynamic type that you can't do with polymorphism or templating? I've always found that testing was simpler when you could outright reject so many bad usages of methods at compile-time.

Re:No, Learn C++

[SanityInAnarchy]

Is sendmail.cf considered turing complete? :)

I don't want to know! :O

It's probably because most of my work on dynamically typed languages are when someone DIDN'T properly design, and I get to fix it. Or more commonly, someone did design it properly, but they went on to bigger and better things, and someone else made some changes that seemed to work, until another piece somewhere else came online and....

I see. In other words, the problem wasn't the language, but it was amplified by the language.

"testing" gets pre-empted by "deadlines".

Until you learn it well enough, and can demonstrate to your boss that you're actually saving time. Even schools are teaching this now -- I went back to school, and with my last assignment, the one showstopper, hard-to-reproduce, hell-to-debug problem was a bug in the one class I didn't unit test, because it had looked hard. Yes, it may have taken an hour or two to write tests for it -- instead, I spent the better part of a day (in and out of class) trying to figure out WTF was going on.

It can be a hard sell, but it's generally a good policy (which I've seen in several open source projects) that every change should contain a test which demonstrates what the new feature is (and why it's needed), or demonstrates the bug (to prove it's broken). Exceptions are allowed, but the rule is, even if you don't test-first yourself, you should include tests with your code, and you should see them as necessary.

I wouldn't write a 3d rendering engine in ruby, but it might be the right call for the slower-paced scripting of game events.

I don't know if I'd do it in Ruby, but I'd probably do it in Javascript, IO, Erlang...

The bottleneck in a 3D rendering engine is probably not the CPU -- it's probably the video card. The exceptions to this are likely things like physics engines, which would be the kind of specific thing that you isolate and rewrite in C -- like ImageMagick is to web apps.

Back to dynamic typing - what's a specific thing that you can do (in a well-designed system) with a dynamic type that you can't do with polymorphism or templating?

If you assume a well-designed system, I'm not sure there is a specific thing you can't do -- but if you assume a well-designed system, static types are equally useless.

First, think of every interface you've ever defined in Java, or anything similar you've done in C++ -- like, oh, those giant header files. That's whole files you can just nuke from your source. IIRC, there are some studies which show that errors per LOC are constant across languages, so anything you can do to improve conciseness is helpful. Dynamic typing is going to do that all over the place, but it's most obvious there.

Second, you do generic by default, which is what you want most of the time. The C++ template system is Turing complete, and Java Generics aren't much better, so it seems like there'd be a tendency to avoid generic systems when you can.

Finally, with less code to write and less strictness, prototyping is a lot faster -- it's much easier to play with your class hierarchy, rearrange things -- so it's helpful as a design tool. One possibility is to rapidly-prototype the thing in Ruby, then convert it to Java -- but you've already got an executable version in Ruby, and the biggest change that will happen when you convert it to Java is you'll be surrounding everything with type declarations and boilerplate irritation.

But really, I think it comes down to high-level vs low-level. Yes, you can do pretty much anything, and most likely anything useful, in a statically-typed system. You can also do OO code in PHP4, or write game engines in assembly. The question is, do you really want to?

I've always found that testing was simpler when you could outright reject so many ba

Re:No, Learn C++

[Harik]

I've always found that testing was simpler when you could outright reject so many bad usages of methods at compile-time.

Maybe you're testing the wrong thing?

First, why do you need to see what happens when you call a method the wrong way? Call it the right way.

Now, how do you know you're calling it the right way, if you don't have a compiler or IDE telling you so? Because you test the point at which you're calling it.

In other words, test the behavior you actually expect, which is more or less the same kinds of tests you'd do in a strictly-typed language anyway. Ignore types. If there's a type issue, it should throw an exception at some point during testing. If it doesn't, your tests aren't thorough enough and you're going to be bitten, sooner or later, by another, non-type-related issue.

See, that's the exact problem, I reject the concept of testing code via an audit of all it's callers. You can't test a future callsite when you write your code now, especially when it may be someone else doing it. Yes, you can throw a runtime error, but then the same guy who used your interface incorrectly ALSO has to handle an exception correctly, and you're asking a lot of a junior programmer doing piddly work. In a typed language, it's impossible to get a method you're not explicitly expecting (and can test for).

I'd honestly be happier without a lot of the boilerplate in C++ (and doubly so in java!), but at the same time I don't want someone accidentally sending an object representing the database table of employees to the network.Serialize() method because they used a CamelCase variable name instead of an lower_underscores somewhere. It gets doubly bad when it's in an unlikely error handler that they didn't test properly - I don't want the validity of MY code depending on someone else implementing their tests perfectly, that's the antithesis of encapsulation.

Re:No, Learn C++

[SanityInAnarchy]

You can't test a future callsite when you write your code now, especially when it may be someone else doing it.

No, but you can test that future callsite when you write it. If you do need to change the behavior of the code in question, you have (hopefully) a comprehensive test suite of all the behavior you already expect. So you're testing at a high level, but that's what you really care about anyway, that whatever you changed or fixed, it didn't break the behavior at a high level.

Yes, you can throw a runtime error, but then the same guy who used your interface incorrectly ALSO has to handle an exception correctly,

Nope, if we're talking about the same thing -- a potential type error -- then an exception is fatal. You don't want that exception to ever happen in live code. Your test suite will handle reporting what caused that exception, and again, if it's not triggered during testing, either it works or your tests are incomplete.

I don't want someone accidentally sending an object representing the database table of employees to the network.Serialize() method because they used a CamelCase variable name instead of an lower_underscores somewhere.

I'm curious how that could actually happen -- I can't remember ever seeing issues like that.

I don't want the validity of MY code depending on someone else implementing their tests perfectly,

Well, it's still you writing tests. If you're writing an entirely standalone library, then yes, you'd test at a lower level -- but in the real world, you don't develop libraries in a vacuum. Even if you do have separate tests for the libraries, if you've done your job right, the tests appear as clear specifications of what the library expects -- and if someone tries to do something unusual, it's their job to make sure it works.

Let me turn it around -- to what extent do you trust your libraries and other tools to behave as expected? Say you're writing a database-driven web app -- doesn't it make sense to have at least some tests that work with both a real database and a real web request, so as to test the entire stack you've put together? Or would you take pains to isolate your code from platform and library code, thus ensuring your tests are the farthest thing imaginable from the real environment it runs in?

A long bureaucratic process too

[perpenso]

Having worked with great programmers who were university educated or self-taught I agree that advanced data structures and algorithms is an obvious gap. However I think there are some more general gaps:

1. Underlying theory. The more general case of your point I suppose.

2. A common vocabulary. For example I can say thats NP and a university grad is more likely to understand.

3. The ability to complete a long, boring and bureaucratic process. Seriously this is an asset, it demonstrates that one has the potential to stay with a project until completion. Some people coming from the self-taught camp bailed out of the more traditional university path because of the time and bureaucracy. That is a liability for some projects. How many open source projects founder because there are plenty of volunteers for the fun parts but few or none for the boring parts?

--
Perpenso Calc for iPhone and iPod touch, scientific and bill/tip calculator, fractions, complex numbers, RPN

It depends on the student...

[Anonymous Coward]

It really depends on the person and the exposure. I've been writing code for more than 25 years and over that span I've developed projects in nearly every language/platform imaginable. The young people I mentor and mange are not getting much benefit from college as I far as I can tell. Most of the colleges seem to be behind in technology. Being taught by professors that either have never worked in the field or did so 20 years ago and have lost touch with today's scene. Most of my best employees have the hunger to learn. It's not what they're learning in school, but what they're teaching themselves. All anyone needs is a library card (or Google these days) and a strong desire to succeed.

Its the study materials, not being self-taught

[perpenso]

Gaps between those that are self-taught and those who are university educated are primarily due to their study materials. Those going down the university path have an advantage due to broader and more in-depth coverage (particularly with the underlying theory and math). I've found solutions to problems coming from topics I never expected to be relevant and topics I may have never studied on my own. However I have a friend who is primarily self-taught and who is blessed with the intelligence and motivation to read a broad collection of university textbook level materials on his own. For such an individual there is really no gap.

So if you want to be a video game programmer do not go to your local shopping mall's Barnes and Noble bookstore and buy books on C++ and OpenGL. Go to your local college/university bookstore and buy *textbooks* on Data Structures and Algorithms, Computer Architecture, Computer Graphics, Databases, Networking, ... Doing so will vastly improve your odds of making it.

--
Perpenso Calc for iPhone and iPod touch, scientific and bill/tip calculator, fractions, complex numbers, RPN

Re:Its the study materials, not being self-taught

[Zumbs]

There is another important source of the gap: Interaction with teachers and other students. Interaction with teachers gives you the benefit of having a more knowledgeable person review and comment your work, pointing out strengths and weaknesses. Interaction with students can give another perspective on the curriculum, making you note the portions you may have missed.

Read What the Classes Use

[MrTripps]

Ours uses ADTs, Data Structures, and Problem Solving with C++ Second Edition by Larry Nyhoff. It may be too simplistic for an accomplished amateur, but it does go beyond basic control structures. You can get previous editions of used text books fairly cheap. There usually isn't much new in a new edition. It is mostly a scam to enrich text book producers.

So much emphasis on Software Engineering...

[Unoriginal_Nickname]

There's way too much emphasis on Software Engineering in these comments. Multithreading? Self-taught programmers are the only people who ever have the time to study IA-32 and associated errata to the point where they're able to write a reliable threading library. Object-oriented design? Computer architecture? Design patterns? All of this is easily within the reach of a self-taught programmer.

Here's my answer: self-taught programmers will not learn computability theory, complexity (incl. real analysis), classical algorithms/data structures, discrete math, combinatorics or numerical methods. Other than that, a self-taught programmer will probably be much better at the purely mechanical part.

Re:So much emphasis on Software Engineering...

[LordKazan]

"Can be learned" and "Often learned" is two different things

the vast majority of self-taughts are BFI bogon sources.

I speak from experience (Before i was taught to do things the right way).

Gotta disagree.

[mosel-saar-ruwer]

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

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

You need YEARS of mathematical training to grok this stuff.

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

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

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

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

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

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

Re:Gotta disagree.

[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:Gotta disagree.

[joshki]

Again, coder vs. Computer Scientist.

Hex is how you represent machine language, it's also critical for doing anything in Assembly.

If you don't have at least a basic understanding of how both work, you're missing out on a significant part of the field.

Re:Gotta disagree.

[Korin43]

I suppose the problem is that a "computer science" degree (something which should only be useful to people doing research or writing compilers) is required for pretty much every programming job (where writing your own compiler or using assembly would be idiotic).

Re:Gotta disagree.

[sbeckstead]

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

Yes, yes I have.

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.

To quote another poster "most people don't deal with logs in everyday life." and in everyday programming, even intense DB and Graphics programming you don't need to "Grok" it.

Yeah I pretty much got this stuff across in less than a semester. Didn't require an IQ higher than 110 to handle it either.

Oh by the way I'm self taught too and don't have a degree in anything. But I do have a good deal of practical experience in programming at most levels. That I believe is what is required to teach others. It sounds to me like you may be locked into academia rather than practical applications.

Re:Gotta disagree.

[joshki]

Computer Science is math. Many people confuse computer science and programming -- the two are not the same.

A programmer is not necessarily a good Computer Scientist.

A Computer Scientist should always be a good programmer -- it's one of the core skills in CS.

Doing research and writing compilers is not the only thing CS people do.

Knowing and understanding Assembly language can greatly improve the code you generate. That knowledge can be critical to optimizing the algorithms you use in your code, whether you actually code anything in assembly or not.

Re:Gotta disagree.

[nabsltd]

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.

Although nowadays most debuggers will translate for you within a running program, if you are looking at data (like a hex dump of file), knowing how to translate from hexadecimal gives you a small boost which can help you tell right from wrong by eye.

I tend to look at a lot of output from tcpdump, and although there are good decoders for the basic packet, the data within still has to be decoded by hand most of the time, since it's not worth it to write a decoder when often the data is proprietary and changes format often.

Re:Gotta disagree.

[gangien]

A Computer Scientist should always be a good programmer -- it's one of the core skills in CS.

not really. Let's quote Dijkstra:

"Computer Science is no more about computers than astronomy is about telescopes."

Computer Science is math. you don't have to be a programmer to be good at math. But being good at math, is a strong positive in programming, obviously.

Re:Gotta disagree.

[Rasperin]

A Computer Scientist should always be a good programmer -- it's one of the core skills in CS.

Good, no. Able to program? Yes. For example I had a coworker who just got his masters in CS develop a text parser. Instead of simply doing a loop that iterates every line, he argued with me it would be impossible without a character that delegated the end of a line. After I told him that was the '\n' character, he broke it down character by character and parsed it to find the \n character, where he then stored it into a double character array. It was quite a bit slower (exponentially) and after that I would not longer trust him to do anything. That was kinda a big deal. So again, Good? No by no means necessary.

Re:Gotta disagree.

[Anonymous Coward]

Knowing it goes faster isn't enough, knowing how to look at code and getting its complexity might be...

Re:Gotta disagree.

[Anonymous Coward]

It's not knowing that "n*log(n) is better than n^2" - but if in the training you see, analyze, and implement different O-complexity solutions for the exact same problem, then that gives you practice and insight for a) what complexity some random algorithm you see or make will be; b) what common things that you might do will hugely decrease performance, and c) what are the different approaches that allow the "classic" best algorithms to do the same thing in a much more efficient way than the naive algorithms.

This is valuable experience that is not easily acquired by just writing various applications on your own, but can be quite easily gained by analyzing "masterpieces" - just as in many other arts and crafts.

Re:Gotta disagree.

[Anonymous Coward]

Again, coder vs. Computer Scientist.
Hex is how you represent machine language, it's also critical for doing anything in Assembly.
If you don't have at least a basic understanding of how both work, you're missing out on a significant part of the field.

Learning how hex and machine language work is important. Knowing how to calculate in hex...again, why would you need that skill?

Re:Gotta disagree.

[CTalkobt]

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

Hexadecimal ?

I've used it - for embedded, machine language type stuff.

In addition it serves as a good foundation for the understanding of number systems - especially binary and most logic courses do have a section / approach of using binary numbers / true / false to deal with logical equations.

It's all related ... you just need to squint your eyes together when looking at it all.

Re:Gotta disagree.

[Anonymous Coward]

Here class, is a perfect example of 'professional arrogance.'

Re:Gotta disagree.

[Darinbob]

Hexadecimal is critical even without assembler. I use it daily. I get debug info showing hexadecimal values. I have to enter IPv6 addresses with hexadecimal. I can figure out at a glance the value of a group of bits in a word if it's in hexadecimal. Not knowing hexadecimal is nearly as limiting as not knowing binary.

Re:Gotta disagree.

[Darinbob]

Some is easy to pick up, some is hard. I'm surprised at times when things that seem completely obvious to me are inscrutable to other intelligent people.

I remember a long time ago a physicist, smart person, was convinced that either the compiler or the computer was broken, because his program wasn't finishing. He had several nested loops to manipulated 5 dimensional array. His program finished in a few minutes if the size of each dimension was 100. But for his production he increased the size to 1000 and after several hours the program hadn't finished yet.

Re:Gotta disagree.

[pla]

Intensive math training = Knowing that n^2 grows faster than n * log(n)?

No. You need the math background to understand why/how a given algorithm performs in O(n log(n)) rather than O(n^2). You need math to know when your O(n log(n)) actually degrades to O(n^2) (quicksort, as the classic example, does this in the worst case). You need math to know when to deliberately use an O(n^2) algorithm over an O(n log(n)) (again with quicksort, it has enough overhead that for sorting a few dozen items, you'll do it faster with a good ol' fashioned O(n^2) bubble sort. Not every algorithm you'll ever use comes in cookbook-form complete with a pre-calculated description of its worst/mean/best case efficiency.

You need math to understand when your algorithm exhibits stability, and when it trends off to +/- infinity. When it gives meaningless but apparently reasonable answers. When you can extend it to related systems (complex or multivariate cases, for example). Why some phrasings of an equation work in code and others fail miserable (arctangent as a good, if simplistic, example). When your hash function counts as secure vs good enough (MD5 no longer counts as "secure", but it still works 100% as good as ever in situations where "deliberate attack" doesn't apply). When you can deterministically optimize a system of equations, or can safely use a gradient descent method, or need to resort to simulated annealing (or similar local-minima avoiding techniques)

Finally, after analyzing dozens or hundreds of common algorithms, you will at the very least know of them and when to use them. When a well-known (in CS circles) problem comes up on a job, you won't spend two months trying either to reinvent the wheel or to squeeze Shuttle Crawler tires on a Vespa. This alone, regardless of your ability to actually create or analyze new algorithms, often means the difference between a hack and a good programmer.

So yes, I will agree with several other posters here - The difference between a self-taught programmer and a university trained one comes down to a single resounding answer, "Math".


And one more thing.. what's the big deal about teaching people hexadecimal? What's the purpose?

I could give a lot of answers to this, but one seems entirely too fitting to the topic - Because it lets you instantly see when an O(n log(n)) algorithm will suddenly take twice as long as the same algorithm on n-1.

Re:Gotta disagree.

[bzipitidoo]

I've been thinking CS should be called "Computation Science". Algorithms are the core of CS.

I learned a lot on my own, by hacking games on the Apple ][. It would have been faster to have read up on it rather than rediscover the hard way all this material that turned out to be rather basic. But maybe I learned it better by doing it.

Some examples: there was this simple text based galactic conquest game which generated a random map at the start. The algorithm they programmed was a stupid O(n^2) one that stored each random location in a list. Each time it randomly generated a new location for the next star, it would go through the list to make sure the location was not already occupied. Took about 30 seconds. I changed it to an O(n) one to use an array that contained 1 element per location. For each star the program checked one element of this array, instead of a long list. Galaxy generation that way took less than 1 second. Another was Dark Forest, a territorial conquest game with two kinds of territories: castles, and ordinary. During a turn, a player was given 1 man per territory that could trace a route through territories owned by that player to a castle owned by that player. The algorithm to compute the number of men was slow, and sometimes wrong. Hacking into the game, I found that the programmer had done a crude job. Did 4 passes through all the territories in a forward order. If a player had territories a,b,c,d,e all in a line, and the castle was adjacent to any of a,b,c, or d, it was correct. But if the castle was adjacent only to e, the player got 4 men for that string of 5 territories. I replaced the loop of 4 with a stack, which made it correct, and a lot faster. Just basic Graph Theory, though at the time I didn't know that.

Later, I observed that a number of programs had terrible shortest path algorithms. Microsoft Streets and Civilization II both got this elementary algorithm wrong. How is that possible? As best as I could tell, MS's algorithm was to pick whichever roads were nearest a straight line between the endpoints. Whoever programmed that garbage may have known their C/C++ or Visual Basic, but they didn't know their CS. Unfortunately, employers focus on languages and mostly ignore this crucial part of programming. Sometimes they won't even ask for a CS degree or even an MIS degree for a programming position but will take something totally off the wall like a History grad, as long as that person knows the computer language that is wanted. It's akin to taking anyone who can write in a particular language such as English, for a story writing position. There are many people who can write words down, but they can't tell a good story. But there's some justification, in that some CS students manage to graduate without knowing algorithms.

My most recent employment experience was almost no programming at all. I had to spent almost all my time on system administration to keep this creaky website from completely falling apart, while the hotshot web programmers made matters worse with totally boneheaded, slapdash programming and stupid demands. For instance, they wanted to be able to post a magic message to the website that the system would take as instruction to compile and install the latest code they just checked in. I told them it was unnecessary-- the system automatically checked for updates. They still wanted it so they could force an update without having checked in anything new. I pointed out that they could do a trivial check in, just change a comment. I also showed them this miracle known as the command line, where they could enter in just one command to start an update, but they still wanted me to set them up with a web page interface way. Could have done that with a magic button, but no, they wanted to cause it with a specific text string entered into a particular forum. With that command I gave them I thought surely these web programmers could just do the rest themselves, but no, too busy. Arrggh! I was forever cleaning up their

Re:Gotta disagree.

[Anonymous Coward]

you sound like the guy in good will hunting that memorizes some obscure text and spews it back to make himself feel smart.

Re:Gotta disagree.

[Anonymous Coward]

Came here to repeat parent. Understanding O and o is not that hard. The definitions are quite simple.

Its making the jump to connecting the idea to real life work (i.e. applying it) which is the hard part. But then, it is only hard if you skip the textbook exercises (I skipped them too...)

Who cares if sin(x)=O(x)? You do if you need to contain a sinusoidal curve within a box whose sides join perpendicularly. A bridge should be high enough to clear the water level for all time, so Tide(t) = O(Bridge(t)).

Re:Gotta disagree.

[NoSleepDemon]

So *you're* the guy who pitted his army of battle tanks against my 5 terminator marines the first time I ever played Warhammer 40k, and laughed when I lost. Damn man, how have you been?

Re:Gotta disagree.

[BillX]

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.

Or a stopwatch :-)

Regarding hex, it depends on the type of programming. I'm an embedded systems developer (various mixes of C and assembler for 8- and 16-bit microcontroller driven gadgets, plus enough PC-side coding as required to talk to the gadget); I use/require hex notation liberally in my day-to-day coding. Some specific cases this comes in handy are bitwise operations (AND, OR, XOR, etc.) and many operations which operate against a mask (e.g. addressing specific bits in a register, constraining the value of a variable, translating variable formats, parsing data from a binary file), or where the requirements/documentation from your upstream application follow hex notation (e.g. the entire documentation of the FAT12/16/32 file system). It's a much more efficient and mentally "clear" way of thinking of the organization of data in the computer's memory. (Yes, some languages e.g. Java go to great pains to forcibly isolate the coder from the underlying implementation of what they have coded, but where efficiency counts at all, understanding of the underlying details is important!)

Re:Gotta disagree.

[Anonymous Coward]

This is not an issue specifically to do with CS but jobs in general. Put bluntly firms will prefer gentlemen to people who would usually be referred to derisively as "tools", i.e. you should at least pretend to be able to do something without labouring or special effort.

This is seen in a lot of areas. Why else would you see law graduates in non-legal management jobs or physics grads in refugee advocacy? Hiring CS grads to do just programming is no different. Sure, you can program. But you're not a "mere" "programmer" but a "CS grad".

Re:Gotta disagree.

[Anonymous Coward]

I don't think that knowing n^2 grows faster than nlogn is what he was getting at, it's the tricky subtleties of reducing the order of growth in clever algorithms that you need a bit more math background to get. There are some really clever algorithms out there for simple problems which you wouldn't realise have a lower asymptotic complexity without a bit of sophistication. E.g. try to work out how to select the median of a list of n numbers in worst case O(n) time. The algorithm is far from obvious and the analysis is a bit tricky. Or try to find the two closest points in 2d space in O(n log n)

Re:Gotta disagree.

[macs4all]

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?

If you want to be a high-level "applications" developer, then maybe (just maybe) you'll never need to mess with hex (and/or binary). However, if you are an embedded developer (like me, for the past 30 years), you will find DAILY applications for being able to "think in hex".

Conversely, in embedded development (most of my experience is in real-time control systems), I have NEVER had to even consider which sort algorithm is more efficient, since I never need to sort more than a handful of anything, and quite frankly, only rarely have had to actually SORT anything!

So, from my point of view, hex is much more important than a lot of the stuff that is taught in a CS curriculum.

Re:Gotta disagree.

[macs4all]

But being good at math, is a strong positive in programming, obviously.

This is one of the longest-held misconceptions regarding programming.

Programming is about LOGIC FLOW. By an huge margin, pure "math" has VERY little to do with actual "programming".

Remember, to a computer, there are but two numbers: One and Zero.

EVERYthing else is just smoke and mirrors.

Being good at LOGIC (not the same as being good at MATH, obviously), is what is REALLY important in programming (most of the time!).

I SUUUUUUCK at math; but, unless the PROBLEM is actually a pure-math one (and very few actually are), I'll put my programming skills up against the best of 'em. Oh, and I am self-taught, and have been making a fairly decent living doing embedded hardware and software development for the past three decades.

Have there been times when I wish I had more math chops? Sure, but those times have been few and far between, and in the long run, that lack of knowledge more often caused me to re-approach a "math-heavy" problem, breaking it down into what turned out to be a much more cycle-efficient (and often even more code-efficient) algorithm for the (simple-minded, like me!) CPU/MCU.

Re:Gotta disagree.

[gangien]

http://en.wikipedia.org/wiki/Discrete_mathematics

Re:Gotta disagree.

[Pictish Prince]

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.

This wasn't my experience but I guess I'm atypical. I'm self-taught, but in 1987 I bought the 3 extant volumes of Knuth's Art of Computer Programming. You don't need calculus to understand the math, just limits. I can't imagine its taking YEARS for the average person to learn the concept of limits

Re:Gotta disagree.

[Pictish Prince]

A Computer Scientist should always be a good programmer -- it's one of the core skills in CS. Good, no. Able to program? Yes. For example I had a coworker who just got his masters in CS develop a text parser. Instead of simply doing a loop that iterates every line, he argued with me it would be impossible without a character that delegated the end of a line. After I told him that was the '\n' character, he broke it down character by character and parsed it to find the \n character, where he then stored it into a double character array. It was quite a bit slower (exponentially) and after that I would not longer trust him to do anything. That was kinda a big deal. So again, Good? No by no means necessary.

I had a simlar experience. I worked with a guy with a PhD in nuclear physics. He wrote a really ingenious program to optimize photographic plate usage for composite images. This he did in Visual BASIC. I was given the job of translating it to C. I found no fewer than 15 places in the code where he wanted to interpret a single character input by the user. Here's what he did (each time!):

IF C == 'A' || C == 'a' THEN x = 1 ELSE IF C == 'B' || C == 'b' THEN x = 2 ELSE ... etc.

Even cutting & pasting this would have made me vomit.

Re:Gotta disagree.

[Pictish Prince]

I had an interesting problem: Port the unzip program to OS9. Looks easy - change all the system-specific stuff, compile it and ... it crashed. I finally figured out that the original code was written for an Intel CPU, which is low-endian but I was on a Motorola M68030 so everything came out with the nybbles reversed.

I didn't need to know hex to solve the problem but I did have to look at a hex dump of the output to discover the reversal.

Re:Gotta disagree.

[Anonymous Coward]

Ok, I'll give you that, and touché.
 
  But the GP seemed to be implying that college-level "advanced" math was important to programming, and it actually seldom is.
 
Having said that, I do enjoy having a good "floating point package" in my compilers!

My overall comment regarding a good grasp of "logic" being more important than a good "math" background stands. Although you make a good point, and I guess I really have been applying the concepts of "discrete mathematics" (which seems to include "logic") for the past 3 decades myself without naming it as such.

In my defense, when I started programming in 1976, I don't think there was a bunch of discussion about "discrete mathematics", per se.

Re:Gotta disagree.

[joshki]

I said CS is math.

A Computer Scientist who can't program is lacking in his education and crippled in his field.

Re:Gotta disagree.

[joshki]

Being self-taught, you've missed our entire discussion on math.

Nobody's talking about adding and subtracting numbers here.

Re:Gotta disagree.

[joshki]

calculation of offsets and addresses in Assembler?

Just the first thing that comes to mind.

Re:Gotta disagree.

[RocketRabbit]

He's just worried about his job.

After all, if everybody knew you could learn everything a university can teach you, from books, for 1/100th the cash and in 1/10th the time, he'd be straight out of a job.

Re:Gotta disagree.

[Anonymous Coward]

OK. So who's supposed to program the compiler if we don't teach people hexadecimal?

Re:Gotta disagree.

[Nutria]

As BillX commented, use (the computer version of) a "stopwatch". That's what I do.

If the linear increase in rows of data (I'm a DBA, formerly a DP programmer, even though my degree says Comp Sci) shows a power increase in time, that's bad. Anyone with half a clue can see that.

Face it: 99% of people who get CompSci degrees do not become scientists. We become programmers.

Re:Gotta disagree.

[Nutria]

"Computer Science is no more about computers than astronomy is about telescopes."

I guess that's where idiocy like Object Orientation and all that crap comes from.

MS Excel 2003 loads (on my XP Pro laptop) in 10 seconds, but OOo Calc 3.2 loads in 30 seconds.

The very first topics in my (otherwise horrible) COBOL-74 textbook (where they made you jump through hoops to not use GOTO) were...

• cohesion - each module does one thing, and one thing only (be highly cohesive) - IOW, abstract the process,
• coupling - don't inadvertently impact another module (be loosely coupled) - IOW, encapsulate process, and
• size - don't make the module too big.

Re:Gotta disagree.

[macs4all]

Being self-taught, you've missed our entire discussion on math.

Nobody's talking about adding and subtracting numbers here.

Could your comment be more effete?

BTW, your arrogance is only exceeded by your ignorance.

Perhaps you'd like to tell him, or him that they would "miss" an "entire discussion on math", eh?

Re:Gotta disagree.

[gangien]

So CS is math. then all mathematicians should be good at programming according to your logic. IN reality, you can do a lot of stuff in CS without programming, and even andrew tanenbaum mentioned that a few of his fellow professors can't even program.

Re:Gotta disagree.

[gangien]

I guess that's where idiocy like Object Orientation and all that crap comes from.

if it weren't for OO you won't have excel or OO in their current states, as of yet anyways.

Re:Gotta disagree.

[joshki]

LOL

There aren't a whole lot of people out there like the two you refer to.

The poster I was replying to didn't understand what CS is. It's a common misunderstanding among people who haven't been taught -- they can write programs all day long, but don't understand what they're doing or how it works. Or why math is so important.

And "effete" doesn't mean what you think it means.

Go back and hide under your bridge.

Re:Gotta disagree.

[joshki]

Any mathematician should be able to learn to program.

I would never take a CS course from a professor who couldn't code.

Re:Gotta disagree.

[Nutria]

or OO in (it's) current state

Maybe it would boot faster???

Most (all?) of the benefits of OO programming can be gained by

• private struct members,
• immutable function pointers in structs,
• initialization/destruction on malloc/free.

IIRC, later (but pre-Delphi) versions of Turbo Pascal had most of those features.

Re:Gotta disagree.

[maxwell demon]

And I'd also say that an astronomer should know quite a bit about using telescopes.

Re:Gotta disagree.

[maxwell demon]

You seem to have a very wrong conception of what math is about. Hint: It's not about calculating numbers (although the definition of numbers and the corresponding operators is a genuinely mathematical topic). Being good at logic is a very large part of what it means to be good at math.

Re:Gotta disagree.

[maxwell demon]

For example, it allows you to write your bitmasks without performing the tedious binary->decimal conversion.

Re:Gotta disagree.

[gangien]

Then, since we both agree, CS is math, you should never take a math course from a math teacher who can't code.

Re:Gotta disagree.

[joshki]

I take it you're pretending to be dense.

CS is a branch of mathematics, it is not the sum total of all math.

There are mathematicians who don't work in the branch of mathematics we call Computer Science.

Re:Gotta disagree.

[gangien]

i'm not pretending at all. You really don't understand how you don't need to be able to program to do much of computer science? How does it follow, that CS is math, but you need to program to do, what we both agree, is math? Did your (assuming you took CS) teachers spend most of their time showing code in front of students? Mine spent most of their time talking about theories, and logic and stuff. rarely was actual code shown (past the first few classes).

and like i said, andrew tanenbaum even stated as much. so unless you're gonna say he (and probably many others) don't know what computer science is, i think it's you that's wrong about this.

Re:Gotta disagree.

[joshki]

Theories are generally illustrated with code, in class or in lecture notes.

Knowledge of those theories is generally tested by proving ability to write code that uses them. At least that has been my experience in undergraduate CS.

Maybe it's different in grad school -- but I doubt it. My point was that it's assumed a CS professor can code -- it's pointless to discuss theories you don't know how to use.

Re:Gotta disagree.

[Anonymous Coward]

I'm a College student studying Computer Engineering. With micro assembly programming, I use hexadecimal every single day. And if you use C it is useful to know hexadecimal as well.

Even "Experts" Struggle with OOP

[Tablizer]

Knowing when to make something an object... when to not make something an object.

This is something even experts struggle with. As a long-time skeptic of OOP[1], I've tried to find a consensus about the "proper" way to architect an app using OOP so that I have something consistent to dissect and publicly analyze besides "toy" examples, but found the OOP author/proponents' answers either vary widely per practitioner or are too open-ended.

They pretty much say, "I know good OO when I see it, but I cannot write down solid rules for recognizing and/or creating it". It's difficult to dissect and analyze the benefits of techniques if they are a moving target or non-describable.

[1] It has its place, but for the most part is over-hyped. It's one of many tools
   

Re:Even "Experts" Struggle with OOP

[LordKazan]

my "rule of thumb" for "object or not?" tends to be this:

Is this a concept with both data and functions associated with it? If Yes: Good candidate for object
Is this a linear task (A->B conversions, etc)? If Yes: poor candidate for object (though the data it is working on might be a good candidate)

Re:Even "Experts" Struggle with OOP

[Tablizer]

But the problem is that one can view one as the other and vise versa. There are gajillion ways to do the same thing (same results) and people tend to prefer the path that best matches how they internally think about it, which varies per individual. Are we modeling the external world or our own heads' view of the external world?
   

Re:Even "Experts" Struggle with OOP

[Skal Tura]

OO is one of the most important tools in the bag. It's kind of like providing namespaces for functions if you have to oversimplify it. That alone, is such a powerfull notion makes OO justified in most tasks.
Ofc, a 50 liner, which does a single non-dynamic task would be a disadvantage to use OO.

OO excels in dynamic situations, and pursuing a huge array of features in the most minimal time.

Re:Even "Experts" Struggle with OOP

[gbjbaanb]

partly... though C programmers had the 'namespace' for years - you just put your C functions in a separate C module. Simple, easy, effective.

What OO gives you, besides encapsulation of methods - is encapsulation of data too. That and inheritance. Inheritance, Encapsulation are the 2 features of OO that make it work. and Polymorphism.

So. The 3 great parts of OO are: Encapsulation, Inheritance, Polymorphism and a fanatical devotion to Alan Kay.

Take a look at Project Euler

[dbdweeb]

• If you like solving problems...
• If you like looking at sample code...
• If you like learning new techniques...
• If you have a need to prove your smarts...
• If you program in multiple languages and like to compare them...
• If high performance gets you all sweaty...
• If functional programming doesn't turn you on...

Take a look at Project Euler

I don't know what I don't know.

[Dragnl0rd]

Being self taught, one of the major revelations I had was that the more I tried to teach myself, the more I realized I knew just a FRACTION of what it took to become a good developer. In the beginning when I thought I understood what i was doing, writing oop programs, when in fact I was writing procedural code with objects scattered around it. Regular Expressions were (to me) among the arcane arts known by masters, engines were something to be licensed from those same masters, and I didn't even hear the words "design pattern" until I'd been trying to work professionally for over a year. Many of the things I know today, I wouldn't have even known to ask/research/learn about back then, because I couldn't conceive of its existence. Heck, I'll probably be saying that forever! To quote a friend of mine: "I cannot grasp the depth of my own ignorance." However, while doing the 'self taught' thing, I have seen other threads like this recommending the staple books like the Petzold book for windows programming, the O'Reilly series, the Stroustrup book for C++, and the "Head First Design Patterns" book. However since i still have google up when doing the vast majority of my coding, I've actually found that more and more I've been bookmarking blogs by developers more experienced and skilled than myself. Moreso than most books, the blogs I keep bookmarked tend to have prefaces at the beginning of each article explaining exactly what programming obstacle the blogger had encountered, thus providing a concrete application for the code to follow in that article.

Comments, and Efficiency

[PerfectionLost]

I think one thing schools teach is to comment. In schools, comments are generally how you explain to your professor what you were doing. In the work place, comments is how you explain to your co-workers, and predecessors what was going on in your mind. It's also how you learn what your predecessors and co-workers were thinking when they wrote code you are inheriting. Generally speaking , people who learn by them selves don't comment, because they don't expect anyone else to read their code. Personally I find commenting a great way of explaining to myself how I am going to go about solving a problem as well.

The second big topic is efficiency. Anyone can write code that gets the job done, but how efficient is the code you write? Does your code complete in constant time, exponential, or logarithmic? With small, low volume projects this doesn't matter, but how well your application scales to serving large numbers of people or utilizes vast quantities of data it matters immensely. Google Big O for more information on this topic.

Finally at college you learn to use a lot of programming laguages, many of which you will never use again. While you might think this is a wasted effort, it helps you learn how to learn new programming languages. You seem to have a lot of programming languages under your belt, so you probably have this covered.

Bean counting vs Engineering or Science

[geek2k5]

If you are doing basic bean counting software, you don't really need that much math. Calculus is overkill.

Heck, in some instances, you need to know how to interpret legal documents more than you need advanced math. I remember a case where I had to tweak an asset ledger system in order to help it meet IRS standards for depreciation after a change in ownership.

At the same time, if you are doing engineering or scientific programming, it can be extremely useful to know Advanced Calculus because that is what the engineers and scientists are using. You may be even better at the topic then they are because you have to translate the calculations into code.

Code Management

[Beardo the Bearded]

One thing that you're going to be seriously lacking in knowledge is code management.

You've got to use something like CVS or Subversion to keep track of your code. (Both tools are free) If you aren't using a CMS, then you don't have code, you have a bunch of text files that happen to compile. You can check differences, make rollbacks, and use a lot of great tools to track what's been going on in your codebase. You can try something new and then either integrate it or dump it. I used TortoiseCVS as the front-end client for CVS for years. (When I moved into PLCs, I couldn't find a tool that would work, which was quite terrible.)

Nobody teaches you that, even if you go to school.

You'll also want to learn some scripting, like Tcl / Tk, so you can run automatic tests. Nothing shows your edge conditions like a mindless script.

Learn how to comment and be consistent in your code. Use good and obvious variable names with consistent syntax. If you want to use CamelCasing, that's fine. If you want to use ALL_CAPS_WITH_UNDERLINES, that's weird but okay. Here's the stumbling block: The code should obviously tell you WHAT it is doing. The comments should tell you why it's doing that. I wrote a Viterbi decoder that was about 30 lines of code. With the comments, it was closer to 130 because it was a weird and intricate system that required a lot of explaining. Trust me, when you go back in five years and wonder what in the hell you were thinking five years ago, those comments will save you a lot of grief. People who say they don't have to comment are either terrible programmers or terribly inexperienced, NO EXCEPTIONS.

As Tolstoy said

[oren]

"Happy families are all alike; every unhappy family is unhappy in its own way". Same for self (or partially) taught developers. Each will have a different gap. It depends on the developer's interests, project history, etc. A self-taught game developer may have a solid grasp of 3D and analytic geometry, while a self-taught web developer may have a solid grasp of database theory. Presumably, a developer who went through academic training will know at least something about both (and many other issues) - depending which school he went too, but that's another discussion. So, bottom line is, "it depends".

Depends on how long you've been at it

[bill_kress]

The longer you work at it, the more you will be exposed to, but you'll learn a bit more over the first few years. I'll list a few that come to mind.

Modeling--UML. You really should know sequence diagrams, they rock. Seriously. When you need them, you NEED them.

O notation. O1, On, ... Just helps you articulate some concepts that you intuitively know but might have trouble discussing with others.

Data Structures--what to the insides of a hash table or heap look like?

State Machines--They can replace threading in many scenarios, would you automatically know when and how to use one?

Low level crap--how are variables stored? how do references work? how do operating systems work? Could you dive in and write a parser for a DSL if it was prudent?

There are also many areas that a self-taught person would have more in-depth knowledge then someone who decided to specialize in computer science after a year or two of college just due to his passion.

A lot of it, too, is simply communication. If you take a class on Design Patterns, nearly everything they teach should be DAMN OBVIOUS to you, however if someone comes up and says that should use the Memento, Flyweight, Bridge or Builder pattern, would you know what they were saying? When you need a pattern you should be able to derive it just through being a programmer, but how long does it take you to describe it without knowing the names? Get a book on design patterns, by the way. One on Refactoring wouldn't hurt either.

A good foundation

[Calsar]

I may be somewhat biased since I have a BS and MS in Computer Science. Computer Science gives you a good foundation to understanding what is going on behind the scenes. More understanding is better. There are libraries and built in functions for just about everything these days which anybody can use, but you are better able to diagnose problems when something goes wrong if you have a deeper understanding of how they work.

A recent CS grad and a self taught developer with 4 years of experience are not at the same level. The self taught person is generally going to be better at writing applications. However, in the long run a person with a CS degree will surpass the self taught person. This of course assumes equal levels of talent. About 10% of developers are just better than the rest by an order of magnitude or more.

I learned a lot in school that isn’t particularly useful for my job. For instance, no one has asked me to write an application to solve differential equations. I did have to write a quick sort in basic when I first graduated. I also ran into an issue recently where a client had some equations they wanted coded into an application for reporting. I had a self taught developer who just looked at it and had no clue. I coded the equations into a function for him so he could finish the report.

would you recommend to fill in the gaps?

[Anonymous Coward]

Nothing.. keep doing what you are doing.. I'm a self taught programmer myself and fiddling with the code seems to bee and will always be the bet way do learn...
because you are not just learning "what to write" (copy&paste like).. but you are learning "why to write".. what work and how it works.. and that will always give you a more deep understanding of the platforms and technologies..

Of course reading a bit about general concepts.. will help you generalize and will give you the tools to "abstractly" design and application.. but in the end it's always about implementation.. and that is what you need to know about.. And if it works.. well,fast and with out bugs.. who cares if is a "standard design" or just something you just cooked up.. if other is team dot understand.. then its them that need to get practical...

Not to seem to full of myself.. but if I compare with other guys in my company.. they may know all theory behind designs.. and may know a lot of buzz words.. but in the end.. I'm the one that does cleaner, simple working code.. and I'm the one, they all come to when they need to understand how the framework works or to make some kind of "tricky" code

Keep at It

[Plekto]

There are two main types of computer people in this world - those who know theory and books and those who know from experience. If I was running a company, I'd want 100% self-taught and capable programmers and not a bunch of cookie-cutter designers. Sure, the formally taught employees might get the job done a bit faster most of the time, but thinking laterally and outside of the box as well as cleaning up and fixing problems and emergencies, well, that's something that self-taught people have to do or have done many times in the past. It's a different type of thinking, really. And it's something that a lot of college educated students just don't have skills in or have to spend years learning.

Perhaps another example would be those 100-in-1 electronics kits that a lot of us had growing up. We may replace components now instead of fixing the actual parts that broke, but there's a world of difference between an engineer or even a PC tech who understands and knows why the stuff works from using/making it themselves versus just what they were taught somewhere. One knows why it failed and will likely fail again, and the other knows how to use a screwdriver. (and yes they still make those kits, so get your kids one!)

Plus, most college courses require you to take tons of useless classes to GET to the more advanced stuff that you could just as easily go out and buy a book on Linux and save yourself 1-2 years of classes. Of course, your education matters, since if for no other reason than to get that interview, but programming should be something you know and learn and not necessarily what you actually got your degree in. IMO, the smart CIS major switches to Math, Physics, or Engineering instead and does programming as a skill they happen to know.

There are all kinds

[agentultra]

I'm a self-taught programmer.

I know algorithms, complexity theory, and lots of math: linear algebra, discrete maths, etc.

What does a good programmer need to know though? Fundamentals. Everything else is specialization. You'll need to know hardware, compilers, interpreters; abstractions, and a solid foundation in scientific principles. You need to be able to hypothesize, implement, test, and evaluate. A basic understanding of algorithms and complexity theory naturally comes into play when theorizing about computer problems which is why most courses integrate them into the curriculum. Beyond a very principled but fundamental understanding however, an in-depth and broad education in such subjects isn't necessary.

I taught myself a lot of maths because that's what interests me. I wanted to know how to write ray tracers, how to optimize them; how to use statistical analysis and discreet mathematics to sort through and find interesting facts about large sets of data. Do I need to know any of that to write a piece of software, compile it, and have it run efficiently? No. I learned that stuff for the kinds of programs I was writing.

The only real difference I find between myself and my university-trained colleagues is that I haven't suffered under the same financial burden as they for the knowledge I've acquired. Yet they talk about it like it's a serious advantage! Of course, there really isn't a serious difference between us that matters when the software ships. It's just a matter of perspective.

The stigma engendered to self-taught programmers however, is the hurdle I find most difficult to overcome and also easiest to ignore. Difficult because people assume things about you when you tell them that you learned on your own. Easy because once they realize that you are competent and capable, the stigma is removed. What many people don't seem to realize is that there are some great programmers out there who were self-taught. Just read through some of the interviews in "Coders at Work" by Peter Siebel. If the autodidacts among us are to be taken seriously, this generalization that self-taught programmers are backyard hacks has to stop. A bad programmer is a bad programmer whether they are self-taught or university taught.

After all, I could just turn around and generalize by saying that university trained programmers are privileged snobs who think "real-world" programming is beneath them. But that wouldn't be fair would it?

It takes all kinds and to each their own.

If you think you need to know something to solve the problem you're having, learn it. Move on.

Grok vs apply

[geek2k5]

If you grok the math enough to understand the difference, you would probably be working for vendors that create the hardware and software that everybody else uses. Or you would be doing software design and development for engineers or scientists. In either instance, you need to grok the math in order to write the software and design the hardware/firmware.

If you are just trying to learn enough to apply various algorithms, an afternoon or so would suffice. That or a cookbook on the 'best' algorithm for a given circumstance. It is kind of like driving a car. You don't have to know how the mechanical system works in order to get acceptable results. The results may not be as good as they could be though. You run into a trade off between the time spent finding the 'perfect' algorithm and the time it takes to get the job done.

It would be interesting to do a study on the costs of using the right algorithms versus the costs of using something that works. If it is something that is life and death, or you are dealing with big impacts in terms of time, money or other resources, you need the right algorithms. But if it is something relatively trivial, you need to ask yourself the question if the cost of implementing the 'right' algorithm is more than the cost of getting the job done quickly.

Math

[kenp2002]

Understanding Linear Algebra and Calculus allows for Mathematical solutions that can drastically cut down on the amount of coded recursion, looping, and needless flow control (if-then-else, case,select,switch,etc...)

Here's what's missing.

[John Sokol]

You can learn the theory, semantics and grammar of programming, you can learn everything in the books, and in actuality be a better programmer.

But here is what you miss. A culture and a type of group think that the university pound in to the students.

This is one where they are taught to produce mounds of myopic code. They are taught not to ask questions and to be OK not understanding the bigger picture and how it all comes together.

At the same time more attention is given to every dam minute detail of a language and with trivial logic puzzle during the interviews that these guys get through better. While at the same time, produce mostly marginal bloating and inefficient code that will almost never take in to account future growth paths.

Being self taught myself, I find it's getting increasingly harder to get in to corporate jobs because of this.

I have also run several startups and had many programmers working for me and have a hard time working with formally educated programmers unless they were self taught before they went to school.

This is again because with the self taught programmers I just have to share my goals and view, and they will plan with me.
With the "educated" ones, they just put out brittle code that lacks insight.

I guess it's like an English major vs. a best selling novelist who probably never needed to study English in college to get to where he is.

Oh that's an easy one

[NotSoHeavyD3]

How full of bullshit your superiors are. I mean you'll deal with professors and administrators who are completely full of shit. This will prepare you for your bosses who will be so full of shit that the only way they could be more full of shit would require the use of a pump, a hose, and a bag of manure.

I would REALLY recommend watching these

[themoneyish]

This U.C. Berkeley Data Structures class would help a lot:

http://www.youtube.com/view_play_list?p=4BBB74C7D2A1049C&search_query=berkeley+cs+61b&rclk=pti

You could probably go through all the lectures in a month and you would know a lot more than most programmers in the industry!

Complexity

[renoX]

One interesting thing to learn is about algorithm which are O(n), O(n2), etc.
It's not difficult and it can help optimising a program..

Also the way to proof that the program is correct (there's a introduction about it in programming's pearls*), it's not used often but it can be very useful for 'tricky' algorithms.

*Funnily the sort program with the proofs has still bugs: it computes the middle of a range with middle:=(x + y)/2 which can overflow!!

That etc. is Huge

[DannyO152]

Functional Programming, unless your etc. did include Lisp/Scheme or OCaml or Haskell.

Some assembly wouldn't hurt.

Why? Different ways of thinking about solutions and it will feed back positively into what you do with the imperative C-like languages you did list.

My opinion

[stonecypher]

Algorithms and datastructures are an enormous gap in most autodidacts' knowledge sets. The NIST DADS is a great place to fight that, or alternatively an algorithms book like CLRS or Knuth 2.

...the knowledge of how useless a CS degree is...

[AndyGasman]

I've found most formal training fairly useless. This is also what I've heard recounted by most of my community and profession peers. I think this is the same whether it is CS, ElecEng (software) or my own personal choice, industrial design. This is from a sample of several hundred software developers, and web developers in the UK, USA and Australia. It has also been my experience as an developers being responsible for looking after new graduate employees. There is real value in learning how to learn. An in this sense post-grad courses can be of more practical use I'd say, though they still have potential to be as useless. I realise this is a broad brush stoke, and I would confess my own degree has given me useful skills in team working, usability and an understanding of what a waste of time formal education is, well 95% of it anyway.

Definitely

[mbessey]

Complexity analysis sometimes evades the college-educated, too, but it's a particular weakness among the self-taught programmers I have known. It's a little sad to see someone trying to micro-optimize the heck out of a very inefficient algorithm, when f they just used a BST or a hash table instead of a list, they'd have vastly better performance.

Algorithms, design patterns and data structures

[Anonymous Coward]

Get some good books on Algorithms, design patterns and data structures. This will give you more breadth to your knowledge. My first book was Knuthe's "Sorting and Searching Algorithms". I of course couldn't understand everything in it, but just reading about the different algorithms made me aware of all of the work that had been done that I could pull from if I needed something.

I always remember my first boss who was an engineer and a self taught programmer looking at my complicated and efficient quick sort program and telling me that it was ridiculous because you could write a sort program in 3 lines of code. ( I think he had seen a print out of a bubble sort in Byte magazine.) I of course wanted to use the system sort program built into the VMS on our VAX, but he wanted me to write a custom sort program.

Inductive reasoning

[pikine]

I concur.

Recursion and inductive reasoning is typically not self-learned, but once you learn it, it's much easier to reason about your program's correctness when you write recursive functions than when you use for-loop or while-loop. Recursion is also key to understand divide and conquer algorithms. Not many people understand that modern computers are designed to run divide and conquer algorithms well. That's because the memory hierarchy exploits locality of reference, which is a property observed from running divide and conquer algorithms. That's because programmers tend to divide a problem into smaller subproblems, and focus on one subproblem at a time.

Furthermore, I would add data structure to this list as well. Many people advocate learning about running time using the big-O notation (you can analyze space usage such as stack depth using big-O as well), but data structure is a big motivation behind the big-O notation.

Freethinking...

[Anonymous Coward]

Freethinking is the most important thing to teach yourself: see all the "design patterns" hints here and people modding them +5. That's terrible "groupthink". Design patterns are mostly workaround 3GL defects, probably 75% of them yet who understands that? Who knows what a 3GL is? I'm self-taught and started with 2GL, eat that youngster ;)

When you read things like "Java doesn't support multiple inheritance", take it with a grain salt. Exercise freethinking. Is inheritance only "subclassing+subtyping inheritance"? Of course not. So maybe that multiple interface inheritance is inheritance after all: multiple subtyping inheritance + delegation is all that is needed to translate *any* OOA/D to OOP. etc.

Most books s*cks big fat azurean mega donk*y dick.

A book on design patterns that doesn't start by acknowledging that most design patterns are workarounds specific 3GL defects isn't worth your time.

When you read something "accepted" then think "oh, that's what they *think*, why do they think that?". Don't take what you read for granted.

Read Knuth if your math oriented. That's "all" you need to know. All the rest is just the latest fluff du jour and as long as you have sound basis there's not a single buzzword technology that cannot be easily mastered.

Exposure to different styles of programming

[mbessey]

> I have taught myself C++, Java, python, PHP, etc

Depending on how deeply you "know" each of those languages, you may be lacking experience in some very different ways of doing things. You ought to at least add one functional language (Scheme or Haskell), and do some really low-level programming (in assembly language, or C). If you haven't looked into C++ templates yet, that is another very different paradigm worth learning.

All the little details...

[Dilligent]

...you ignore when learning things on your own. Seriously, if you teach yourself a language it's usually by developing a project of your choice (mostly for the fun of it, as it has been for me). What people do is, they go for the fun bit of hacking things together to get a working piece and pick one of two choice: * Try to use all the language features even if this means overkill for simple situations. * Go on to piece it together and leave a horrible mess. I used to do the latter >10 years ago in that situation, starting out in the mess that Visual Basic itself is, never really realising just how bad it was. I was proud of what I'd achieved! Looking back, I can't believe I published any of that. It's when people go for the first choice and start realising how software is meant to look like from the source that they learn to be a competent programmer. There's all these intricate details like Garbage-Collection, String-Manipulation, Floating-Point Math (the point being that it is unlike mat taught at school !) and many more things like Memory-Management and some such that one *can* get to work sloppily, but it's only when one realises how to utilise these things in the correct way that i would agree self-teaching is the way to go. I'm a self taught programmer, still in university (3rd year with an average mark of 1.8), employed as a software engineer and I'm 100% certain I wouldn't have been able to achieve 1 quarter of these things without teaching myself how to program. ....Yeah... it is at this point that people can rightfully say they *do* waste quite some time in university.

the point of teaching hex

[Anonymous Coward]

I'm guessing that working direction with hex is just optimal in some situations especially in graphics, eg:

a BYTE data type =0...255, whereas an int data type = -127...127 ...

a bitwise shift is especially useful when you're working with binary:

given BYTES (r,g,b): r16+g8+b = DWORD (hex_color_code)

Some tips I can give you

[Anonymous Coward]

Get a good book on Algorithms and Data Structures. Then look at some Computer Science curriculums and work from their. (You can read some classic books like SICP, these should help)

Once you've done that you need to show you understand these things, maybe a portfolio of example code could help you here.

However, you're basically trying to prove that you're a Computer Scientist without a CS degree, in the long run you may want to study for a CS degree just for the accreditation.

Infrastructure knowledge

[realeyes]

I have found that a lot of programmers don't understand the infrastructure of computers and networks. They learn to read and write buffers without knowing what happens to the data next. This has both performance and security implications.

From a performance perspective, a program that works well on a standalone system or even a LAN might be a dog over the web. There is also the issue of scalability. When you start pumping huge amounts of data into an app, it should not grind to a halt if the algorithms are as efficient as possible. BTW, you can learn a lot about writing efficient code by working in assembler.

From a security perspective, you should not only be validating inputs and outputs based on the underlying infrastructure, but you should also provide the admins of your app with all the info you can to help them safely configure and maintain it.

Unfortunately, this is not limited to the self-taught. I have not met anyone who took a course devoted to secure programming. And the level of detail in various CS programs is all over the map.

Later . . . Jim

I made the same journey

[James Youngman]

My list:

- complexity theory (and some 'concrete' mathematics)
- functional programming
- lisp
- domain specific language design
- concurrent systems design and implementation
- graph algorithms
- large-scale OO design (i.e. how to design a framework rather than a program)
- DFAs

That's after I eliminated the things I already knew I didn't understand when I graduated in 1993 (language parsing, compiler design and implementation, database theory, unit testing, ...).

well..

[jasno]

What do you want - to be an effective programmer, or to understand CS theory that you may, depending on your specialty, never get to use?

I'm biased - I came into programming as an EE who landed a job as an embedded software engineer. I tend to work on low-level driver issues(race conditions, improper locking, buffering issues), but I've done contract work on VB6, python, C++, bash scripts, Java, OpenGL, digital video, etc... Beyond a good understanding of locking, buffering(be able to implement a circular buffer in your sleep), and how computers function(down to boolean logic, although I find comfort in knowing how to bias a transistor), I don't think you need most of what a CS guy spends his time on.

I barely know what turing complete means, and I couldn't give a shit about the towers of hanoi or a traveling salesman. None of that has ever come up in my line of work. If you don't already know about that stuff, chances are that you're not smart enough to land the type of job where you would use it.

Object oriented design took me a few years to really get. You just need to apply it, and apply it again, and apply it wrong, and see how other people have applied it wrong(no good definition of wrong here, but you'll know it when you see it). Eventually you'll get a better feel for it. I still can't architect as well as some CS friends of mine, but I consider those guys geniuses, in contrast with a lot of CS educated morons.

Write a multi-tasking OS. I wrote a simple one for the 68HC12 a few years back and it taught me a lot about what you need, and what you don't. You could probably find an emulator so you don't have the added challenge of bringing up a development board, but you really should be able to bring up a development board(write mem tests, exercise the hardware(serial ports, gpio, timers, etc)).

Do it all when you're young. Life catches up with you by the time you're 30.

There are some general differences

[wienerschnizzel]

Each individual is different and I've met some great self-taught programmers as well as poor programmers with with CS degree.

There are some general rules of thumbs though:

- a lot of the self-taught coders are actually college drop-outs that might be technically good but have a poor work ethic
- there are self-taught programmers with a degree from a different field (Electrical engineering for instance). Those can generally do a good job as coders if they spend enough time researching the new (computer science) field tackling coding problems
- open source participation is probably the best way to distinguish a good self-taught coder from a bad one - if a person demonstrably does a lot of work in OS projects he/she can easily become the most resourceful, enthusiastic and helpful colleague

My recommendations

[jon3k]

To cover 95% of the work done by your average programmer just go to a local university and see if you can audit a data structures class. This is assuming you're already competent in general.

University is about learning how to learn

[vtavares]

One thing I haven't seen mentioned is what the whole university experience is supposed to be fundamentally about learning how to learn. Yes, in Computer Science/Software Engineering you will get a broad brush of skills and training, from computing concepts, mathematics, and sciences. But you will also be exposed to other knowledge domains at a high level - economics, business, psychology, philosophy, languages - no, not programming but spoken, etc.

Some of the best programmers I have ever worked with had little to no real training in daily programming skills. Instead, they had degrees in other fields that allowed them to be free thinkers. This helps with solving complex problems, thinking "outside the box" and having a broad experience in things other than programming language details. Anyone can read books on advanced C++ techniques and other "learn how to program in 21 days" types of books and do a decent job at coding. However, I want people who have been through a difficult university program and not only survived, but excelled and had a broad experience. Sure, they might take a bit longer to get up to speed on the "design patterns" and "agile programming" methodology du jour, but they will probably be more likely to excel in a challenging, free thinking, problem solving work environment. Sure, some exceptional, self-taught people can also be amazing, but that's usually the exception.

If you just need coders that write php code to spec, stick to self-taught or community college grads - they are cheaper.

The best afterburner boost I ever had...

[Hurricane78]

...was learning Haskell! Even if you do it just for the sake of learning it. (Especially since that great new book came out last year.)

My code is on a whole different level now, since I have seen the Matrix. :)

Next step: QED, by Richard Feynman. (Should be a piece of cake now. ^^)

Hash tables

[Anonymous Coward]

After about 10 years of learning by just reading specs and figuring things out on my own I began a study. And that's when I heard about hash tables the first time. I would have never come up with hash tables on my own. It was like they were introducing in something occult.

Finding the desired record in giant amounts of data INSTANTLY on average.

Strong cryptography.

[DamnStupidElf]

It seems like too many people think encryption is only about scrambling data until it looks hard to recover. This isn't just a knock against self taught programmers, but I do tend to see it slightly more often in self taught individuals (including myself; when I was a kid I thought repeatedly XORing a password with plaintext was a great idea until I figured out how to automatically recover the passphrase from the ciphertext with statistical analysis a few years later). Anyone who's looked even slightly deeper knows that cryptography is seriously hard and involves knowing advanced mathematics and learning about every advanced published attack before attempting to design a cipher. Even if you pick trusted cryptosystems, there are timing attacks, watermarking attacks, man in the middle attacks, side channel attacks, and any number of other security problems that have to be addressed in the system using the cryptographic primitives. General security is hard, but secure cryptography is arguably even harder. You might think that a general programmer won't run into problems involving cryptography very often, but how many programs or web sites need to manage users and permissions? Store passwords that aren't vulnerable to rainbow tables? Transfer data over the Internet to another trusted host or user? Securely store and process credit card numbers?

hard to believe you

[r00t]

Assuming 32-bit floats, the "small" array is 40 gigabytes. It's fairly uncommon to have that, but not entirely implausible.

The large array is 4 petabytes. There are very few computers in the world that can handle such a thing even today, never mind "a long time ago". The memory allocation would fail. For normal FORTRAN 77 arrays, the program wouldn't even start.

I guess I could see it with C++ using a sparse array class, but your "long time ago" physicist wouldn't be doing that. He'd be using FORTRAN 77 or older.

Re:hard to believe you

[Darinbob]

Had the number of dimensions wrong, it was probably 3 (time to turn in my geek card). It was 80's on a VAX. I do remember that he was just changing the size of each dimension by 10 though. For 3 dimensions that would be 1000 times the memory and more than 1000 times in runtime (because of paging).

The point was that this guy, though intelligent and well versed mathematically, didn't understand that a small change in a parameter would cause that huge a change in runtime. Even after I explained it he took awhile to catch on.

not so avoidable!

[r00t]

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

Programmers often work in teams on large projects. They may even work for different employers, supplying libraries to a 3rd party who puts them together.

Programmer X does an array index operation to get the color name. He's assuming that this is really fast.

Programmer Y overloads operator[] so that he can internationalize the code. In all the usage examples he's ever seen, nobody looks up color names in a loop. He's assuming that this isn't done.

Math

[konohitowa]

Perhaps I missed some comments due to my filter settings, but I didn't see anyone directly recommending Discrete Math/Finite Math. That's a pretty important topic -- I did see it sort of mentioned in passing as part of other topics, but having a deep understanding of discrete would help a lot. Boolean logic topics like DeMorgan's theorem & Carnot maps can help you considerably with optimization and even just reviewing the logic portions can help you avoid those "if/else/oops" scenarios wherein you forget to consider one of the cases of a logic statement.

Linear Algebra can also be extremely helpful for a fair number of problems that arise and it can also lead you into linear optimization topics.

Although more of an applied math topic rather than math itself, Digital Design can have a tremendous impact on your understanding of the system -- particularly when dealing with hardware or a compiler bug.

And to toss in some non-math, Operating Systems is another great topic -- as well as Compiler Design. You'll see lots of methods for doing things that you have to do regularly anyway while gaining a deeper understanding of the "behind the scenes" operations.

Try this

[WhiteHorse-The Origi]

Discrete maths(1 book http://www.cimt.plymouth.ac.uk/projects/mepres/alevel/alevel.htm) and wikipedia(1 list http://en.wikipedia.org/wiki/List_of_computer_programming_topics). I also have a physics degree and taught myself programming. It's important to realize you'll never be a member of "the in crowd" until you have a piece of paper from an overpriced university. It's the only way unintelligent people can distinguish between programmers and it gives them an easy out if you suck.

Often lack the science

[Anonymous Coward]

To properly design a complex computer system, you need to know the science behind it: discrete mathematics, logic etc.
Most self-taught figure out the necessary craft, such as design patterns, but they often lack the science.

Huge skill deficits

[HW_Hack]

- Don't have the training to survive multiple 2-4hr meetings every week
- Have not been forced to work with coding morons
- No skills in creating weasel-word specifications or slide sets

- And the biggest of all - Will not be able to hang by the water cooler and compare the college you went to with the other geeks

Learn LISP

[Zoko Siman]

I just hosted Richard Stallman at my university (http://csee.wvu.edu/rms video coming soon). After the lecture was finished a student asked him "What can I do to be a better programmer" to which he responded "Learn LISP."

I can say from my experience with the language, that RMS, ESR, and PG are all right. Learn LISP. It will change how you think.

If we ask a job recruiter...

[Anonymous Coward]

A job recruiter would say, "You don't have at least 7 years experience in Microsoft SQL Server 2008... I'm sorry but you're not a fit at this organization. Best of luck!"

Experience

[seangee]

Applies to both self and institution taught. I came through the self taught route and have been developing software (and employing developers) for 20 years. Theory is great but a natural developer will absorb that even if self taught - and I do believe developers are born rather than made. Many of the mediocre developers are simply doing the wrong job and will never excel because they don't have the right mindset. In the real world I am far more interested in someone who will deliver the required solution than what formal training they have had. And that (usually) means somebody with a track record of successful delivery

What Knowledge Gaps Do Self-Taught Programmers G..

[stuckinphp]

What Knowledge Gaps Do Self-Taught Programmers Generally Have?

The same ones us taught programmers have. The ones we need and haven't learned yet.

Sounds like you're a far outlier...

[mosel-saar-ruwer]

This wasn't my experience but I guess I'm atypical. I'm self-taught, but in 1987 I bought the 3 extant volumes of Knuth's Art of Computer Programming. You don't need calculus to understand the math, just limits. I can't imagine its taking YEARS for the average person to learn the concept of limits

Off the top of my head - as a first-order approximation - I'd guess that you have an IQ of 140+ [certainly at least 135; very doubtful that it's any lower than 130].

We're talking about trying to teach this stuff to people with IQs down around 120 - maybe even as low as 115 [in a worst-case scenario].

Those folks can't teach themselves Knuth - they have to have it spoonfed to them, over the course of many, many semesters.

And even then, it's doubtful that they'll ever get much beyond HTML or Visual Basic.

Actual engineering.

[Cerebus]

'Nuff said.

By far the biggest issue I see is ...

[Robb]

Many self-taught programmers lack even a basic understanding of algorithmic complexity. This is the single biggest issue I run into in industry and should be one that isn't too hard to fix. Again and again I find people have written some algorithm that just doesn't scale to larger amounts of data because it is n^3 or n^4 instead of linear. After that I would say it is a good grasp of some of the ideas in functional programming particularly recursion. There are a lot of other things I run into but I never noticed that self-taught programmers were more prone to them than others.

Self-taught is good. Self-important is not.

[Anonymous Coward]

In my experience, self-taught programmers lack humility, in that they tend to think they know more than they do, and generally assume that they are not missing out on anything that a formal education in computer science / electrical engineering could have taught them. They also tend to perform poorly in a team environment. This second observation is most troublesome, as there is not a complex software project that can be successful without a strong team. Some of these problems may be more of a reflection on the chip they carry around on their shoulders if they have to work with people with more credentials on their resume. Or they may really be as neurotic as you perceive them to be. If they perceive they might be shown up they become overly defensive of their ideas, even though all good engineers know there is usually more than one way to solve any given problem. They also tend to seek out positions of authority, even though they usually have no business managing people. In short, good luck working for them. They tend to be everywhere.

Oh, and the algorithm crap is a complete waste of time. Most software projects have so many more important problems to deal with every day than saving a few clock cycles on a modern 4 GHz quad core. I'm not saying go ahead and write 'tard code and make stuff that is slow just because you're lazy. It's just not as important as making sure you allocated enough buffer space and actually validated that user input stream. And what's the point of saving those extra clock cycles if you continuously have to fix buggy code that was rushed out the door and that wasn't needed in the first place because some poor excuse for a product manager keeps asking for the wrong features from the engineers? Software sucks. If you are motivated enough to self-teach, get out your math texts and get a real job doing anything other than software.

Code Complete

[minstrelmike]

Get the book "Code Complete." I started reading it after a survey in ComputerWeek or TechRepublic asked what the best programing book was. They chose that one.

It covers real world programing, issues over commenting and variable names and standards and conventions vs getting things done vs maintenance down the road.

SICP

[jknapka]

Read "Structure and Interpretation of Computer Programs" by Abelson and Sussman. Do as many of the exercises as you can make time for. You will end up a better programmer than most CS graduates.

That book does two things that I found revelatory:

1) Exposes you to functional programming and important features thereof (such as referential transparency) from the very beginning.

2) Starts with a very high-level, functional model of computation (the Scheme language, which is essentially lambda calculus), and proceeds toward increasingly low-level models of computation, culminating in a Scheme evaluator based on a traditional stack machine. Many programming books tell that story in reverse, starting with memory and registers and instruction sets, and then explaining how high-level language constructs map onto those low-level concepts. By starting at the functional level and elaborating increasingly detailed models of physical computation, Abelson and Sussman drive home the point that computation is an abstraction that can be implemented, and thought about, in lots of different ways.

It really is a mind-blowing experience. I read it after 15 years as a professional programmer in languages from assembly through C to Lisp and Prolog, and I learned A LOT from it.

Two words:

[Anonymous Coward]

Normalization Theory.

Seriously, the percentage self-taught programmers who slap together databases without the faintest clue is very close to 99.99999% I have seen far too many databases "designed" by these folk with data being duplicated, triplicated, split into 2, 3 or 5 tables (I kid you not!) - collecting their money and walking away. Then some poor slob (like me) has to go in and try to untangle the mess and rescue the data.

Sigh.

Try Dijkstra or Hofstadter

[jastram]

I consider the basic crucial, as they provide a solid foundation. Along those lines, I found Gödel Escher Bach extremely useful and entertaining to read at the same time (mind you, it's not an easy read). In the book, Hofestadter develops some simple programming languages and talks a lot about the properties of formal systems.

Another excellent read is A Discipline of Programming (Dijkstra), which goes to the core of the issues in programming.

In fact, the above List on Wikipedia may give you some more ideas.

this might be almost interesting

[Anonymous Coward]

anecdote:
via maxxed PDP-8/i and the free-for-the-asking DEC PDP8 & 11 books I learned programming around 1975.
But at first I couldn't properly conceive of nested loops. "linear thinking" ?
So I wrote an klugey/bruteforce/hack sort algorithm as part of a particular dice game for ASR33, using just one BASIC FOR/NEXT loop.
It's in the creative computing magazine jan/feb 1978. In case you have one of those lying around, please feel free to
scan/post/criticize it and perhaps consider me a Slightly Less Anonymous Yet Still Embarassed Coward.

formal = (a) re-use, (b) big picture

[MessyBlob]

Formally-schooled programmers tend to think 'bigger-picture' and code for wider issues, whereas self-taught take pleasure in the engineering, will adopt minimalist solutions and tend to re-invent the wheel in fragments (as opposed to methods from a large library). As such, the self-taught solutions are likely to be more 'magical' and innovative - not necessarily good for deployment, but could be useful for prototyping and proof-of-concept.

Science and Engineering

[turgid]

I come from a very similar background to yours and am largely self-taught as well.

As far as Computer Science goes, the important things in addition to what you have already studied are Algorithms (Knuth, Sedgewick) and Functional Programming (scheme is nice and simple and mature). I wish I'd known about Functional Programming 20 years ago...

In the world of work, if you understand and can implement basic algorithms in C and C++ you will be miles ahead of 90% of people.

What's really important for work is good engineering practice. You should learn about design and testing. Test Driven Development is a really powerful technique and quite easy to pick up if you are a hands-on learner. Your code will be so much better as a result. Again. you'll be miles ahead of most other people.

Learn about Combinatorial Testing. See the NIST website.

Do code reviews. Review code written by people better and more experienced than yourself. That's a very powerful way to learn what works and good style.

Befriend some grey-beards and heed their words.

Continuous integration, refactoring, ... it's a lifetime's challenge but it's great fun and very rewarding.

Finally, knowing Bourne shell (or bash) scripting is as very useful skill to have. It opens many doors and can make you a very valuable team member since many people only know GUI tools (Visual Studio).

Don't over-emphasise the PHP. It leads to dead-end jobs that are way beneath you.