   Software engineering in a CS degree
  How important are software engineering courses in a computer science degree? I'm currently simultaneously working on my bachelor's and master's degree in CS due to having a somewhat accelerated schedule and have to more or less choose courses as I go along. For my master's, I'll be specializing in "foundations of computing, algorithms and logic," which is basically a fancy way of saying algorithms and languages, but I still have to choose a few more courses. So far my courses are primarily in my specialization, embedded/systems and functional programming.I'm currently looking at software engineering courses, and I was wondering how important those are for an algorithm guy? Are courses in the discipline completely essential to avoid either having your job shipped to India or doing webapp code monkeying for the rest of your life? Is it something you have a hance to learn in the workplace if you don't have it in your degree?As an aside I also plan to finish up my bachelor's degree in Japanese (basically a course on classic Japanese and a thesis and I'm done,) if that might be relevant in some way; I don't know, I'm just doing it because it's fun.   
  I would think that, generally, the fact that you have completed a CS degree is of more interest to a prospective employer than the individual classes you took - any CS graduate applying for an SE job is expected to be an able developer and once in an interview you will have a chance to demonstrate your ability. In some ways a CS-centric set of classes can impede a developer as important practical concepts like source control are often barely mentioned.So essentially I would choose the classes which interest you and develop the skills you want to develop. Asking "how important are SE courses in a CS degree?" is the wrong question - instead consider "how important are SE courses in career X?".You ask if a SE course is important for "an algorithm guy"... Being "an algorithm guy" is a rather vague aspiration - to me an "algorithm guy" is somebody working in academia studying computability and complexity, developing new sorting, graph or scheduling algorithms. In this case SE probably isn't important at all as you will be dealing with abstract mathematical concepts, not producing usable software.   ;Quote:Original post by WavyVirusany CS graduate applying for an SE job is expected to be an able developerNot necessarily. I've seen quite a few companies who will largely prioritize SE graduates over CS graduates, as the latter are considered all abstract theory, without any practice in software engineering, whether justified or not. Some time ago I met the head of HR of a very large international software company at a conference. We briefly talked about the difficulties of finding competent candidates for even entry level positions nowadays, and he told me that his company stopped recruiting CS graduates for engineering positions, because they were too expensive to "deprogram and retrain".YMMV.   ;Quote:Original post by Yann LWe briefly talked about the difficulties of finding competent candidates for even entry level positions nowadays, and he told me that his company stopped recruiting CS graduates for engineering positions, because they were too expensive to "deprogram and retrain".You don't hire mechanical engineers to work the assembly line. Any large enough company that does development internally will have all the modern QA processes in place making advanced training redundant. So all that's left is general aptitude for programming and respect for the process.Despite fancy names, majority of programming today *is* assembly line. There is Jira (or similar) which delivers small and simple tasks, opaque workers take each item, fiddle with it, then put it back on.Second improvement is realization that "if it builds, ship it" is good enough. Except that build today includes automated tests. If those pass, cool. If a new defect is found, make a new test, and it will roll down the Jira conveyor belt.And considering performance is either irrelevant or provided by third-party libraries, advanced CS skills are detriminial. And big issues are again resolved via conveyor belt.Finally, knowledge sharing. Many places today support developers always knowing entire code base. This implies that the most complex piece of code is subject to lowest common denominator (aka the most incompetent developer).So why not just ship this in some faraway country where it costs 10 times less to do the same...Agile and other techniques are not adequate indicator, many complex and demanding projects use same methodologies (Google for one). But in most other places there really is no need for any advanced skills beyond a couple of weeks of programming - and if there is, process can often be improved.I'm sometimes shocked at what the US wages are for certain types of jobs. I've seen companies in Europe complain that they must sometimes pay the interns that run such projects (vs. unpaid positions). And not (just) because companies would be exploiting students, but because the skills really are that trivially obtained and in such abundance.Another thing to keep in mind - the above process hasn't stopped. Every year half of last year's cutting edge is replace by an open source library that anyone half-literate can use effectively.In the end, it's like car industry. There are a handful of designers and engineers that work in R&D of select few companies, the remaining several tens of millions are greasemonkeys and sleazy sales-people. A CS going for SE job will increasingly often find themselves overqualified. Just like repair shops explicitly want technicians, not electrical engineers. You don't want someone with advanced degree to solder wires and replace fuses.As an addition to CS these days, business, economy or law is often preferred or something medical or more scientific (physics/math) or perhaps something completely unrelated, even liberal arts.   ;  In North America I find the degree completely irrelevant. Competency is not about what the degree teaches, its about what the student learns. I see people coming out with CS degrees and no understanding of basic calculus, and people coming out with SE degrees and no understanding of *actual* software engineering. Good developers are able to learn the skills and knowledge they need, and they will have started doing that even before their degree is finished.Anyway we had a few SE classes in my CS degree, but looking back they seemed pretty irrelevant. Individual assignments and theories can hardly prepare you to engineer an architecture that 200 developers will work on. Experience and talent wins the day.   ;Quote:In some ways a CS-centric set of classes can impede a developer as important practical concepts like source control are often barely mentioned.You don't say... Getting other people on a project to understand the utility of source control tends is a major source of frustration. Not that those people grasp the CS parts, but anyway.Quote:You ask if a SE course is important for "an algorithm guy"... Being "an algorithm guy" is a rather vague aspiration - to me an "algorithm guy" is somebody working in academia studying computability and complexity, developing new sorting, graph or scheduling algorithms. In this case SE probably isn't important at all as you will be dealing with abstract mathematical concepts, not producing usable software.If I define it as "someone who actually gets to work on interesting problems now and then," does that make it clearer? Academia isn't out of the question, but anything with interesting problems is fine by me.Quote:So why not just ship this in some faraway country where it costs 10 times less to do the same...Well, that's sort of what I wanted to avoid.Quote:As an addition to CS these days, business, economy or law is often preferred or something medical or more scientific (physics/math) or perhaps something completely unrelated, even liberal arts.So basically, that Japanese degree would look better on my resumé than a bunch of SE courses?Quote:Original post by SteadtlerIn North America I find the degree completely irrelevant. Competency is not about what the degree teaches, its about what the student learns. I see people coming out with CS degrees and no understanding of basic calculus, and people coming out with SE degrees and no understanding of *actual* software engineering. Good developers are able to learn the skills and knowledge they need, and they will have started doing that even before their degree is finished.Anyway we had a few SE classes in my CS degree, but looking back they seemed pretty irrelevant. Individual assignments and theories can hardly prepare you to engineer an architecture that 200 developers will work on. Experience and talent wins the day.So, assuming that I'm not a delusional egomaniac but actually do have some aptitude for this and am a fast learner, not having two or three SE courses wouldn't be that much of an impediment?   ;Quote:Original post by Antheus[...]While there is certainly truth to this, it isn't generally applicable. In fact, it has become increasingly difficult finding competent developers on todays IT job market. There's a huge surplus of bad and mediocre graduates out there, but the really good ones become more and more rare. And due to the unbalanced supply and demand situation, the top tier developers have become really expensive. Not sure who is to blame here, but companies have to adapt. Adapting means automating the dev process as much as possible, so that low quality personel can still be used for the main work, while reducing the amount of ever-more expensive top people to the minimum.Seriously, it's been some time now I'm out of HR (thankfully), but the occasional shifting through interview notes for some SE/CS graduates, my god...   ;Quote:Original post by ValdermanIf I define it as "someone who actually gets to work on interesting problems now and then," does that make it clearer? Academia isn't out of the question, but anything with interesting problems is fine by me.Scuba divers get to work on interesting problems now and then, and there are plenty of uninteresting algorithms./devils advocate