I can't talk for the parent, but one significant way I expect people with formal training and people without it to differ is in how the knowledge of data structures and algorithms affects their work.
If you stumble upon a problem that cries for a trie or a splay tree and you don't know they exist, you'll have a very difficult time solving the problem with adequate performance.
If you are lucky and dedicated and talented you might end up with something similar, but it'll take you a lot longer than one who already knew they were there and how and why to use them. Likewise, if you have been trained in developing algorithms, you know what are the important things and which aren't, and have a toolkit to select ideas from.
More than studying, learning a good book on data structures. That, and the intractable quality about learning to design systems and how invariants are involved in the design jerf talked about up there.
> I can't talk for the parent, but one significant way I expect people with formal training and people without it to differ is in how the knowledge of data structures and algorithms affects their work.
And how often in your experience you stumble upon these kind of problems? In my experience, the clever parts are about 5% to 20%. Of course, there can be projects where the clever parts outnumber the non-clever parts, but we are talking about norms, and as you said, exceptions don't prove rules.
The question posed was "how do they differ?" not "how important is that difference?". If you ask me the latter, I'd say that for many domains it's not that important (see the caveat below.) On the other hand, for Google and Facebook and similar companies it's certainly very important, which is why all their interviews are mainly about how well you can reason about algorithms and data structures.
Caveat: These problems might not happen often in less data intensive domains but, when they do happen, they are certainly very important in my experience.
> The question posed was "how do they differ?" not "how important is that difference?"
And the question arose from the claim that the formally taught and self-taught programmers take different approaches in general. It goes without saying that a problem that can be solved effectively using a trie will be approached in 2 different ways by someone who knows tries and someone who does not. The claim made in the OP was broad, and I am saying about 80% of the time, an auto-didact and a CS person will solve it the same way. Claiming that because sometimes a CS person can use insights which the non-cs guy doesn't have doesn't equate to different approaches.
The fact that 80% of the time the approach is not important to get the desired result because the task only operates over small n or similar does not mean that the approaches are equal.
It might not be needed, but it's about the approach. You don't need all the tools all the time, but knowing what patterns are available and having a good understanding of why you would or wouldn't use it means you approach a problem starting from a different place.
It's possible to get the same end result most of the time (especially if the end result doesn't require the "clever" solution), but I would also agree that there definitely is a difference in approach that is discernable by watching someone work.
If you stumble upon a problem that cries for a trie or a splay tree and you don't know they exist, you'll have a very difficult time solving the problem with adequate performance.
If you are lucky and dedicated and talented you might end up with something similar, but it'll take you a lot longer than one who already knew they were there and how and why to use them. Likewise, if you have been trained in developing algorithms, you know what are the important things and which aren't, and have a toolkit to select ideas from.
Of course, outliers do not invalidate the thesis.