8 ms·

So, I agree with this article in spirit. Lots of programmers could've benefitted from a more programming centric approach rather than a CS approach. However, th

So, I agree with this article in spirit. Lots of programmers could've benefitted from a more programming centric approach rather than a CS approach. However, this bit gave me pause. " I cannot tell the difference by watching them develop software." I can't disagree with this more. While this may be true of students who were middle of the road students in CS programs. I can't definitely tell the difference between people with a formal cS background and those without in my daily work. I work with a handful of extremely talented self taught programmers but there is definitely a difference between the way they attack problems and think about coding versus the CS folks. Not to even mention the programmers I've worked with who have EE degrees. Those guys think about things and code in an entirely different third way. All of these people / approaches are necessary... and none of them are better than the others... but pretending like they don't do things different because you want to feel like you don't need a CS degree is disingenuous.

gnaritas 14y ago
I'm curious about what you think those differences are, and how you think it hurts or helps.
- jerf 14y ago
  It is hard to answer this because a lot of the trite answers are indeed false. A computer science student may be more able to tell you whether an algorithm is O(n^3) or O(2^n), but the normal (and experienced) programmer will be able to tell you either is "slow" and fix it just as quickly. But there is a style of thinking that can come out of a study of computer science that can be very difficult to obtain on your own, and enable you to build larger and better systems than all but the very, very, very best of self-taught programmers, and while it's hard to put that difference into words, it's mostly the study of maintaining invariants in the code from both a theoretical and a practical standpoint. Or, if you prefer, a way of thinking that helps create and enforce a mathematically-strong form of conceptual purity in your code. Those who don't have this background, and I very much include people who took the courses but just sort of skated through without absorbing anything, will often have problems with any API I create that requires certain constraints, such as being careful at what point they access local information vs. remote information. Their use of the APIs will be sloppy and hacky, because they don't really understand how they work or what they are for. The constraints I am thinking of are purely technical, a particular server/client split, so when I say you can not do X it is not merely me being an academic prick, it is because it is actually impossible to do X because at the time your code runs you are literally in the wrong place. Explaining this fact is easy, but explaining how the system conceptually wraps around this constraint and works the way it does is a challenge. And APIs designed by such people, while they may get the job done, tend to be very brute force (for lack of a better term) and to lack any sort of firm foundation, such that the moment a requirement even slightly changes we have to make massive (and often hacky) changes to them. Unfortunately, it is impossible to provide examples in the scope of a single post, because all small examples will not show the issue. It's a larger pattern of issues that tend to start interacting with each other, which is where the real problems emerge. It is also the case that a proper path chosen through a computer science program will take you through some eminently practical theory that will make you a vastly more powerful programmer, and is very hard to pick up on your own. By far the biggest example of this is compiler theory. If you are currently in college and still have the opportunity to take your local compiler course, take it. I don't write very many "compilers", but I have now written quite a few "interpreters" and it has enabled me to complete projects that could not have been completed any other way. Getting a formal grounding in signal processing is also a good idea, that one can be hard to pick up later and has surprisingly useful intuitions for a lot of high-speed networking tasks. A formal grounding in networking can be good, though a lot of courses unfortunately seem to just march through TCP and the OSI model, which you could relatively easily just read about. The fastest way to obtain this basic understanding if you are a good programmer but lack the formal education is one of really, honestly working through SICP (and not just reading it), or becoming fluent in idiomatic Haskell, with special concentration any time someone talks about "enforcing invariants via types". (Personally, I believe Haskell has completely supplanted Lisp as "the language to learn to expand your mind even if you have no intention of using it", but be sure you stick with it for a bit. Learning how to string together a couple maps and a fold is not where the interesting stuff is, it's what the interesting stuff is made out of.) Also, break yourself of the subconscious idea that academic === useless. As someone who tends to straddle the border I will completely agree it isn't all useful, but it isn't by any means all useless either. And just let me reiterate as my closing point that it is absolutely possible to go through even a very good Computer Science program and fail to absorb the useful lessons it has. Presumably these are the people claiming it's "useless". I have to admit I tend to not have a high opinion of people who managed to go through a solid program and come out with nothing. (There are also some complete wastes of programs, so YMMV.)
  - cantankerous 14y ago
    Very, very insightful post. Thank you! To add a little personal bit, I use Haskell daily in my research. I also do web programming on the side in Rails. After figuring out Haskell, and then learning idiomatic Haskell (along with monads, monoids, functors and friends) my way of writing Ruby became much different. I'm more cognizant of patterns in Ruby as they relate to Haskell (as they relate to formalisms in computation). For example, handling nils in Ruby can follow patterns of the Maybe monad in Haskell. This isn't to say that Haskell is the only mind-expanding language out there, but it sure is good and it worked for me. I think it makes it especially easy in this regard over ML or Lisp in the "mind-expanding" game because it has so many formalized computational concepts that are first-class and upfront. That's not to say that you can't expand your mind in other languages, but Haskell can really help you out if you're willing to roll with the learning curve.
    - jerf 14y ago
      I would add that part of the reason I think Haskell has supplanted Lisp is that so many of the concepts of Lisp have been absorbed into mainstream languages that the distinctiveness is greatly reduced. Macros are still mindblowing, but much less so if you've used Ruby or Python or Perl than if you're a pure C programmer. In 20 years, I suspect modern Haskell will be "less mindblowing" for the same reason. It's not that Lisp has gotten less good or anything, it is that it has mostly won.
      - BrandonM 14y ago
        Macros are still mindblowing, but much less so if you've used Ruby or Python or Perl than if you're a pure C programmer. I disagree with this statement. Python's introspection, first-class functions, magic methods, and duck-typing add a lot of the dynamism of Lisp, but every time you run up against something that needs to be a macro, it's a dead end. C has a rudimentary macro system that can get you a little past that point; for example, it's not too difficult to add a foreach construct to C that looks like this: queue *q = queue_new(); queue_add(q, 1); /* ... */ foreach (int i, q) { printf("%z\n", i); } On a sidenote, it's kind of sad that a programming layer just above assembly language created 4 decades ago has better macro support than some of the most popular modern languages.
Flenser 14y ago
I'm curious. In what ways do they attack problems differently?
- koide 14y ago
  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. Of course, outliers do not invalidate the thesis.
  - tseabrooks 14y ago
    Ah yes. This is right on.
  - ams6110 14y ago
    Studying a good book on data structures would probably cover about 80% of what a practicing programmer really "needs" from a CS degree.
    - koide 14y ago
      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.
  - irahul 14y ago
    > 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.
deleted 14y ago
[deleted]
irahul 14y ago
Add me to the list of people who are curious and don't agree at all with your claim that people with CS background approach regular problems in a fundamentally different way. The only times when the CS folks' approach differ is when they can reduce the unknown to a known - finding the least wasteful way to cut raw materials(knapsack); modelling problems as graphs/trees and then applying well known, efficient algorithms etc. From what I have seen, the ratio of non-clever to clever code in a typical software is 80:20(I am being conservative. It's more like 95:5). The 80% doesn't need cleverness - it needs a lot of discipline and proper abstractions. CS doesn't teach you discipline or proper abstractions. Most of the projects in a CS curriculum are small, done in small teams or solo and are thrown away as soon as the course requirements are met. The higher level CS projects exist just to prove a point(research), or doesn't exist at all except in theory.
- SomeCallMeTim 14y ago
  Something that no one is acknowledging here is that a "CS" program isn't a uniform thing, and that people who come out of a "CS" program have not uniformly learned what it did have to teach. I never took the full CS program, but I hit most of the core classes while studying Cognitive Science. By far the most valuable class sequence I took was compiler design; learning HOW a compiler takes code and turns it into assembly language was a revelation to me, and I was able to "see" the relative optimization of algorithms much better after taking that course. Will I ever need to write a compiler? Probably not, though I have written several small interpreted scripting languages/DSLs. But taking the class expanded my mind in a way that grants me insights a LOT of self-taught programmers I've worked with never seem to have. Does everyone who takes a compiler design class gain those insights? No, certainly not. It's possible to muddle through just about any class without REALLY understanding it and pass -- some more easily than others. The weeder classes in CS at my college were tougher than many, though, including one that actually required each student to write non-trivial programs in assembly language. But back to your comment: It's not that all code needs to be "clever." A friend of mine once CRITICIZED a piece of code for being "too clever," and he was right. "Clever" isn't a goal. But sometimes the straightforward approach made by someone who is good, but self-taught, isn't as good as the equally straightforward approach by the self-taught AND CS-educated programmer. >The higher level CS projects exist just to prove a point(research), or doesn't exist at all except in theory. Real higher-level CS projects frequently involve interesting graphics research, which (also frequently) ends up working its way into commercial game development. I don't have any clue what you mean by "doesn't exist at all except in theory," since even if you're building advanced data structures that you could otherwise pull from a library, you're building something "real" that could actually be used.
calinet6 14y ago
This could not be more true. A formal CS background gives people a very valuable toolset with which to program. It's something you can't fake, and if you know what to look for, it's instantly recognizable. But if you don't have a CS background, yeah, I could see why it would all look the same to you. A CS person can easily learn programming; it's second nature to them. But a programmer does not learn deeper theory as easily. Of course it can be learned, but that's why they teach CS at universities and not just programming—it's a much more difficult and more fulfilling subject, in my humble opinion.
- gaius 14y ago
  A CS person can easily learn programming This is not true, if you've ever seen academic code...
  - lordlicorice 14y ago
    Academics are notorious for their code, but I suspect the parent was talking about people in industry with a CS background.
    - gaius 14y ago
      It would be like saying an Art History major could "easily" learn to paint. The skills just aren't transferable.
      - bnegreve 14y ago
        > The skills just aren't transferable. Not all comparison are good. I agree that playing music requires skills that you probably don't have if you only studied art history, but this is absolutely not true when it comes to CS and SE. CS and SE both have to do with abstraction, languages, logic, models ...
        gaius 14y ago
        The skills of "programming in the large" are hard-won through experience. There is no good "theory" that will help you structure a large program (despite many languages from academia making the claim of good structure). That's just one example. In my experience, it's easier to teach a programmer CS theory than the other way round. At least the programmer knows what he doesn't know.
wizzard 14y ago
Same here. I think the idea of a BSc in Software Development is excellent, and I think some colleges are starting to think along those lines. For instance, the SaaS class from Berkeley on Coursera would have been far more useful to me than the circuit design and formal theory classes I had to take. However. There is definitely something to be said for SOME kind of structured education for developers. The author's anecdotal evidence notwithstanding, I have met many aspiring self-taught programmers who just don't have it. There seems to me to be a strong correlation between a person's drive to learn something and their willingness to pursue a formal education... not surprising if you think about it. I also know an absolute genius programmer who is 99% self-taught. But just because people like Wozniak exist doesn't mean they're the norm.
- tikhonj 14y ago
  For what it's worth, Wozniak actually did EECS at Berkeley ;). In regards to the SaaS class: I know a bunch of people who took it before it was offered online. Perhaps surprisingly, most of them did not find it useful. The issue is that they picked up everything taught there either on their own or in internships; they really didn't need to waste a whole course on it. That said, the particular people I talked to are some of the better EECS majors who tend to have significant projects of their own and good internships, so there is certainly some bias.
jff 14y ago
EE programmers are fun... just model it as a state machine! The best part about writing your code as a state machine is that you can then easily translate it into VHDL for implementation on an FPGA, or even into silicon.
thenonsequitur 14y ago
No need to limit it to self-taught/trade-taught programmers, CS people, and EE people. I once worked with a brilliant programmer who was studying Classics and English Literature and he had an entirely novel approach too, and brought real value to the team. That's the cool thing about programming -- it's an abstract thinking skill, so anybody with any sort of formal training will bring their specific ways of working and thinking into the game.

gnaritas 14y ago

I'm curious about what you think those differences are, and how you think it hurts or helps.

jerf 14y ago
It is hard to answer this because a lot of the trite answers are indeed false. A computer science student may be more able to tell you whether an algorithm is O(n^3) or O(2^n), but the normal (and experienced) programmer will be able to tell you either is "slow" and fix it just as quickly. But there is a style of thinking that can come out of a study of computer science that can be very difficult to obtain on your own, and enable you to build larger and better systems than all but the very, very, very best of self-taught programmers, and while it's hard to put that difference into words, it's mostly the study of maintaining invariants in the code from both a theoretical and a practical standpoint. Or, if you prefer, a way of thinking that helps create and enforce a mathematically-strong form of conceptual purity in your code. Those who don't have this background, and I very much include people who took the courses but just sort of skated through without absorbing anything, will often have problems with any API I create that requires certain constraints, such as being careful at what point they access local information vs. remote information. Their use of the APIs will be sloppy and hacky, because they don't really understand how they work or what they are for. The constraints I am thinking of are purely technical, a particular server/client split, so when I say you can not do X it is not merely me being an academic prick, it is because it is actually impossible to do X because at the time your code runs you are literally in the wrong place. Explaining this fact is easy, but explaining how the system conceptually wraps around this constraint and works the way it does is a challenge. And APIs designed by such people, while they may get the job done, tend to be very brute force (for lack of a better term) and to lack any sort of firm foundation, such that the moment a requirement even slightly changes we have to make massive (and often hacky) changes to them. Unfortunately, it is impossible to provide examples in the scope of a single post, because all small examples will not show the issue. It's a larger pattern of issues that tend to start interacting with each other, which is where the real problems emerge. It is also the case that a proper path chosen through a computer science program will take you through some eminently practical theory that will make you a vastly more powerful programmer, and is very hard to pick up on your own. By far the biggest example of this is compiler theory. If you are currently in college and still have the opportunity to take your local compiler course, take it. I don't write very many "compilers", but I have now written quite a few "interpreters" and it has enabled me to complete projects that could not have been completed any other way. Getting a formal grounding in signal processing is also a good idea, that one can be hard to pick up later and has surprisingly useful intuitions for a lot of high-speed networking tasks. A formal grounding in networking can be good, though a lot of courses unfortunately seem to just march through TCP and the OSI model, which you could relatively easily just read about. The fastest way to obtain this basic understanding if you are a good programmer but lack the formal education is one of really, honestly working through SICP (and not just reading it), or becoming fluent in idiomatic Haskell, with special concentration any time someone talks about "enforcing invariants via types". (Personally, I believe Haskell has completely supplanted Lisp as "the language to learn to expand your mind even if you have no intention of using it", but be sure you stick with it for a bit. Learning how to string together a couple maps and a fold is not where the interesting stuff is, it's what the interesting stuff is made out of.) Also, break yourself of the subconscious idea that academic === useless. As someone who tends to straddle the border I will completely agree it isn't all useful, but it isn't by any means all useless either. And just let me reiterate as my closing point that it is absolutely possible to go through even a very good Computer Science program and fail to absorb the useful lessons it has. Presumably these are the people claiming it's "useless". I have to admit I tend to not have a high opinion of people who managed to go through a solid program and come out with nothing. (There are also some complete wastes of programs, so YMMV.)
- cantankerous 14y ago
  Very, very insightful post. Thank you! To add a little personal bit, I use Haskell daily in my research. I also do web programming on the side in Rails. After figuring out Haskell, and then learning idiomatic Haskell (along with monads, monoids, functors and friends) my way of writing Ruby became much different. I'm more cognizant of patterns in Ruby as they relate to Haskell (as they relate to formalisms in computation). For example, handling nils in Ruby can follow patterns of the Maybe monad in Haskell. This isn't to say that Haskell is the only mind-expanding language out there, but it sure is good and it worked for me. I think it makes it especially easy in this regard over ML or Lisp in the "mind-expanding" game because it has so many formalized computational concepts that are first-class and upfront. That's not to say that you can't expand your mind in other languages, but Haskell can really help you out if you're willing to roll with the learning curve.
  - jerf 14y ago
    I would add that part of the reason I think Haskell has supplanted Lisp is that so many of the concepts of Lisp have been absorbed into mainstream languages that the distinctiveness is greatly reduced. Macros are still mindblowing, but much less so if you've used Ruby or Python or Perl than if you're a pure C programmer. In 20 years, I suspect modern Haskell will be "less mindblowing" for the same reason. It's not that Lisp has gotten less good or anything, it is that it has mostly won.
    - BrandonM 14y ago
      Macros are still mindblowing, but much less so if you've used Ruby or Python or Perl than if you're a pure C programmer. I disagree with this statement. Python's introspection, first-class functions, magic methods, and duck-typing add a lot of the dynamism of Lisp, but every time you run up against something that needs to be a macro, it's a dead end. C has a rudimentary macro system that can get you a little past that point; for example, it's not too difficult to add a foreach construct to C that looks like this: queue *q = queue_new(); queue_add(q, 1); /* ... */ foreach (int i, q) { printf("%z\n", i); } On a sidenote, it's kind of sad that a programming layer just above assembly language created 4 decades ago has better macro support than some of the most popular modern languages.

Flenser 14y ago

I'm curious. In what ways do they attack problems differently?

koide 14y ago
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. Of course, outliers do not invalidate the thesis.
- tseabrooks 14y ago
  Ah yes. This is right on.
- ams6110 14y ago
  Studying a good book on data structures would probably cover about 80% of what a practicing programmer really "needs" from a CS degree.
  - koide 14y ago
    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.
- irahul 14y ago
  > 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.

deleted 14y ago

[deleted]

irahul 14y ago

Add me to the list of people who are curious and don't agree at all with your claim that people with CS background approach regular problems in a fundamentally different way. The only times when the CS folks' approach differ is when they can reduce the unknown to a known - finding the least wasteful way to cut raw materials(knapsack); modelling problems as graphs/trees and then applying well known, efficient algorithms etc. From what I have seen, the ratio of non-clever to clever code in a typical software is 80:20(I am being conservative. It's more like 95:5). The 80% doesn't need cleverness - it needs a lot of discipline and proper abstractions. CS doesn't teach you discipline or proper abstractions. Most of the projects in a CS curriculum are small, done in small teams or solo and are thrown away as soon as the course requirements are met. The higher level CS projects exist just to prove a point(research), or doesn't exist at all except in theory.

SomeCallMeTim 14y ago
Something that no one is acknowledging here is that a "CS" program isn't a uniform thing, and that people who come out of a "CS" program have not uniformly learned what it did have to teach. I never took the full CS program, but I hit most of the core classes while studying Cognitive Science. By far the most valuable class sequence I took was compiler design; learning HOW a compiler takes code and turns it into assembly language was a revelation to me, and I was able to "see" the relative optimization of algorithms much better after taking that course. Will I ever need to write a compiler? Probably not, though I have written several small interpreted scripting languages/DSLs. But taking the class expanded my mind in a way that grants me insights a LOT of self-taught programmers I've worked with never seem to have. Does everyone who takes a compiler design class gain those insights? No, certainly not. It's possible to muddle through just about any class without REALLY understanding it and pass -- some more easily than others. The weeder classes in CS at my college were tougher than many, though, including one that actually required each student to write non-trivial programs in assembly language. But back to your comment: It's not that all code needs to be "clever." A friend of mine once CRITICIZED a piece of code for being "too clever," and he was right. "Clever" isn't a goal. But sometimes the straightforward approach made by someone who is good, but self-taught, isn't as good as the equally straightforward approach by the self-taught AND CS-educated programmer. >The higher level CS projects exist just to prove a point(research), or doesn't exist at all except in theory. Real higher-level CS projects frequently involve interesting graphics research, which (also frequently) ends up working its way into commercial game development. I don't have any clue what you mean by "doesn't exist at all except in theory," since even if you're building advanced data structures that you could otherwise pull from a library, you're building something "real" that could actually be used.

calinet6 14y ago

This could not be more true. A formal CS background gives people a very valuable toolset with which to program. It's something you can't fake, and if you know what to look for, it's instantly recognizable. But if you don't have a CS background, yeah, I could see why it would all look the same to you. A CS person can easily learn programming; it's second nature to them. But a programmer does not learn deeper theory as easily. Of course it can be learned, but that's why they teach CS at universities and not just programming—it's a much more difficult and more fulfilling subject, in my humble opinion.

gaius 14y ago
A CS person can easily learn programming This is not true, if you've ever seen academic code...
- lordlicorice 14y ago
  Academics are notorious for their code, but I suspect the parent was talking about people in industry with a CS background.
  - gaius 14y ago
    It would be like saying an Art History major could "easily" learn to paint. The skills just aren't transferable.
    - bnegreve 14y ago
      > The skills just aren't transferable. Not all comparison are good. I agree that playing music requires skills that you probably don't have if you only studied art history, but this is absolutely not true when it comes to CS and SE. CS and SE both have to do with abstraction, languages, logic, models ...
      - gaius 14y ago
        The skills of "programming in the large" are hard-won through experience. There is no good "theory" that will help you structure a large program (despite many languages from academia making the claim of good structure). That's just one example. In my experience, it's easier to teach a programmer CS theory than the other way round. At least the programmer knows what he doesn't know.

wizzard 14y ago

Same here. I think the idea of a BSc in Software Development is excellent, and I think some colleges are starting to think along those lines. For instance, the SaaS class from Berkeley on Coursera would have been far more useful to me than the circuit design and formal theory classes I had to take. However. There is definitely something to be said for SOME kind of structured education for developers. The author's anecdotal evidence notwithstanding, I have met many aspiring self-taught programmers who just don't have it. There seems to me to be a strong correlation between a person's drive to learn something and their willingness to pursue a formal education... not surprising if you think about it. I also know an absolute genius programmer who is 99% self-taught. But just because people like Wozniak exist doesn't mean they're the norm.

tikhonj 14y ago
For what it's worth, Wozniak actually did EECS at Berkeley ;). In regards to the SaaS class: I know a bunch of people who took it before it was offered online. Perhaps surprisingly, most of them did not find it useful. The issue is that they picked up everything taught there either on their own or in internships; they really didn't need to waste a whole course on it. That said, the particular people I talked to are some of the better EECS majors who tend to have significant projects of their own and good internships, so there is certainly some bias.

jff 14y ago

EE programmers are fun... just model it as a state machine! The best part about writing your code as a state machine is that you can then easily translate it into VHDL for implementation on an FPGA, or even into silicon.

thenonsequitur 14y ago

No need to limit it to self-taught/trade-taught programmers, CS people, and EE people. I once worked with a brilliant programmer who was studying Classics and English Literature and he had an entirely novel approach too, and brought real value to the team. That's the cool thing about programming -- it's an abstract thinking skill, so anybody with any sort of formal training will bring their specific ways of working and thinking into the game.