[blah32497]

I never knew this was a problem in EE, but I know for a fact it's a huge issue in CS.

They don't want to teach any "tools" b/c CS professors find teaching people how to be good developers as beneath them. They honest to god think CS is an actually hard science on par with math and physics. You can sum up their attitude with: "It's not an associates degree goddamnit!" (even though it should be)

Another source of reluctance is that by the time we'd graduate it will be sort of outdated. I remember we learned subversion and Apache Ant. Everyone now uses git and I'm not even sure if anyone uses Ant

95% of students used std::cout for debugging and 95% of students never set up an IDE.

If I had spent a couple weekend properly learning to use Visual Studio, all of my programming assignment for those 4 long years would have been 10x easier.

[mandor]

CS prof. here.

We don't want to teach "tools" (e.g. IDE) because they are always changing. There is no point is knowing how to set up an IDE when the IDE will have a different GUI before the student graduates. We teach"unix tools" a bit more because they did not change much during the last decades.

My goal is to teach "concepts" (which is hard) and use tools as examples of these concepts. Dealing with the specifics of a particular IDE or tool is pointless. We are trying to give students general skills that will be useful for the whole life of the students, and not skills that the industry needs this year.

That said, I do my best to teach debugging (mainly using gdb and valgrind). The real issue with debugging is that it relies on a lot of experience, which students do not have, by definition.

[RogerL]

We aren't asking for vocational training, but for teachers that teach how to think, how to design, how to run experiments, and so on. So many schools (even the 'top' ones) turn out people that cannot do this, and I find it appalling. These things are foundational, they are not vocational. Unfortunately that does in fact meaning having to learn some tools which will become obsolete. So what? I did EE labs, and while resistors are the same none of the digital components really are. I learned how to design NPN junctions, which are now largely replaced with CMOS, but so what? It was the experience that mattered. You can't hand wave that away ('you' is global, not you mandor), teach the math of junction biases, and expect that anyone will be able to do anything with it once they graduate. But so many CS programs try to do exactly that. I walked out of undergrad knowing how to do recurrence relations, prove the complexity of graph algorithms, and so on, but with almost no clue about how to actually design an algorithm, how to structure and design software, and so on. It took grad school and some good teaching professors, to change that.

I've rewritten this three times or so - it is hard to address without sounding like I'm attacking you, which I am not. But I am truly dismayed about the skill sets of people graduating from CS programs. I'm not asking for Java vocational training, but for a recognition that 99% of the graduates will be asked to function as "engineers", not "scientists". The people that come out and that function well seem to do so despite the schooling, not because of it.

Incidentally, the best EE teacher, or any teacher, that I ever had, had worked in industry for many years, decided he wanted to teach, and went into teaching. His classes were practical and pragmatic. Oh, you were failing if you didn't master the math and theory behind the material, but he taught you how to design, how to think, how to manipulate all of this book learned stuff to make real things that worked. We had to cost out our projects, write design reports, and so on. Extremely hard courses, but absolutely fantastic, because of, not despite, the focus on what might be called 'pointless' things (who cares what the cost of a transistor was in 1986, after all?!)

Unfortunately, you cannot gain experience, and develop the process, without using tools. It needs to be part of the education. Just look at the post by the poor person you are responding to. Think of how much better his entire education would have been if in some freshman level lab he had been taught some of these basics. I shudder to think how much he probably spent for that education vs what he got.

[vitd]

I learned absolutely nothing from having to use horrid unix tools like gdb in college. The focus on unix tools, in my opinion, seriously degrades the ability of students to learn and unfortunately cements very very bad usability paradigms in their minds.

I learned a ton by debugging things on my Mac using Turbo Pascal, Think C, and even, when absolutely necessary, MacsBug. Those are all obsolete today, but it was well worth learning the skills regardless of the tool.

That said, we were also taught very little about debugging in class. I learned it all on my own (with help from friends). Most of my fellow graduates seriously didn't know how to set a breakpoint and step through code at the end of their college days.

[MichaelMoser123]

For really big programs you can't use valgrind; valgrind causes significant performance hit and the system often starts to choke under the the memory load. Also GDB really alters the timing of things, so it is bad at timing/multithreading bugs.

Mostly what helps is working through the logs & traces / following through the code along as you pass through the traces; Use a needle and a steady hand ;-)

i guess that's what they should practice in school as part of learning the trade. On the other hand its a trade off - school needs to teach the general principles of programming, with regards to debugging it is hard to distill universally applicable principles; it all depends on what you are doing.

Here is my take:

- unit testing is cool, it allows to catch problems in isolation; so it would be useful to teach this as a discipline

- for most GUI programs and application logic the debugger is really helpful

- traces and log analysis as mentioned earlier as the last resort

Also they should teach how to formulate the problem, analyse problem source and ways of fixing a defect; here you have to understand the trade offs: when to choose a local fix, when is a local fix no longer appropriate; how to quickly test a fix - so that it does not break the system in any way.

If i remember correctly then some of that they do teach in software engineering courses.

[fredophile]

Valgrind is fine for teaching students. I would probably use something faster and more sophisticated (and probably more expensive) in a professional setting but that doesn't mean there's nothing to learn from using it.

Adding logging also changes timing. Those aren't just NOPs you're throwing in. Also, changing timing isn't always a bad thing. Sometimes you can get a bug from a race condition to happen more often with the debugger.

[MichaelMoser123]

Valgrind can't be fast, it has to track/color each memory location, it also has to check each pointer reference; also its memory overhead for larger footprints can be considerable.

Once upon a time it was really slow, but then they added just in time compilation.

logging/tracing can be selectively enabled;

[blah32497]

I'm so glad you replied!

I've heard versions of what you've said hundreds of times and honestly, you academics are missing the point!

Yes, the particular tool you learn will become obsolete, but debugging between Eclipse, gdb, Visual Studio etc. is all basically the same. The knowledge you get is transferrable, just like they have a head start if you teach them C++ and they end up in a Java shop.

Teach them tools that are going to be obsolete! Stop worrying about that.

You have no idea how much time your students are wasting hitting their heads against walls that shouldn't exist trying to debug their crappy code instead of actually working on understanding the underlying concepts. I'd say it's a 9 to 10 ratio of brain-numbing debugging to actual concept implementation.

I really strongly encourage you to set up your students with IDEs. Have a few seminars on how to set up a Visual Studio environment, and how to debug a large codebase. It abstracts a lot of the fluff that stands between them and the underlying concepts. The command line and its tools are great in the right context, but you're making the barrier to entry a lot larger than it needs to be. You can transition to command line tools in more advanced courses, but don't hamper their learning from the get-go.

[wolfgke]

> I really strongly encourage you to set up your students with IDEs. Have a few seminars on how to set up a Visual Studio environment, and how to debug a large codebase.

You can find lots of information about that using a search engine of your choice. Any student should be able to use Google. So there's no reason to waste teaching ressources for that purpose.

[Illotus]

That is a bit weird thing to say. Lots and lots of things can be found using a search engine, but it doesn't mean they shouldn't be taught.

[rpedela]

The tools for debugging have changed yes. But the high-level process is the same whether it is fixing a NAND gate, figuring out the cause of a segfault, or finding a the location of the leak in a water pipe.

There is a problem. Many of the interns and recent CS grads I have worked with or hired have struggled with debugging. On a day to day basis, debugging is one of the most important skills. I would argue it is also an important skill in research settings, not just industry.

I don't know the answer, but maybe somehow integrating debugging into every CS class over the four years would help. Because you are right, it also requires a lot of practice/experience to get good at it so it is unlikely that just adding a class would solve the problem.

That is what the Purdue psychology program (I have a minor) does in its undergraduate program. The first 2-4 weeks of every class is spent on research methods often specific to the particular topic of the class. After taking the 4-5 classes to complete the minor, how to reduce bias in surveys, usability tests, etc was beaten into my brain.

[analog31]

Thanks for the comment. I agree that tools go obsolete quickly. But it occurs to me that debugging is both a set of tools but also a knack.

I'm curious what you think about how to teach the knack.

[wolfgke]

How to teach the knack:

Write lots of code that uses the most sketchy language features available. The chance is high that soon you'll get code that doesn't work. Now go through each line (source code or assembly) using a debugger of your choice and get it to work again.

Do this until there is nothing that will scare you anymore.

[Illotus]

Also, do lots of maintenance programming. Finding bugs in code someone else wrote is generally much more difficult (and in my opinion valuable in learning sense), because you aren't familiar with it.

[jarvic]

>They don't want to teach any "tools" b/c CS professors find teaching people how to be good developers as beneath them. They honest to god think CS is an actually hard science on par with math and physics.

Despite what you (and a lot developers that I've talked to) seem to think, CS is a hard science. However, CS and software development are not the same thing. Most CS programs are taught by professors who have research degrees in Computer Science, not by people who have ever been (or probably ever claimed to be) professional software developers, so there is a fundamental disconnect between what you seem to think you should be learning and what is actually being taught.

The professional software developer is a fairly new occupation in the grand scheme of things. The people who are most qualified to teach it are people who have actually worked as developers in the industry, but that is difficult because 1) most universities are reluctant to hire (and students can be reluctant to take classes from) adjunct/non-PhD faculty, and 2) it is hard for schools to offer enough to lure many of them away from industry anyway.

[blah32497]

"CS is a hard science"

Hahaha. As someone who did a degree in physics, computer "science" is a joke when it comes to math. They took one of the easiest field of mathematics and rolled it in to a half-assed degree. Sure you learn some logic and some graph theory (yeah, lets try to avoid numbers as much as possible...) but it's not at a very high level. I seriously doubt CS professors are making significant contributions to mathematics.

"there is a fundamental disconnect between what you seem to think you should be learning and what is actually being taught"

Yeah. That was the point of what I wrote. There is also a disconnect between what academia wants to teach, and the tools that the students need to actually learn the concepts.

It's like teaching an Literature class without actually teaching people how to write. Code is our primary tool for expressing algorithms and concepts. If you hamper people's ability to write code, you are shooting yourself in the foot.

[fredophile]

Why do you say CS takes one of the easiest fields in mathematics? People have been studying CS since long before we had computers and there are still famous open problems. If the math is so easy perhaps you'd like to give a proof for P=NP (or P!=NP) and claim your million dollars? Do you really think CS is all discrete math and graph theory? I don't go around claiming physics is easy because Newtonian mechanics are simple. I'd also argue that math only gets interesting once you take the numbers away. If all you're doing is number crunching you should probably just write some code instead. Computers are good at that sort of thing.

In my experience the real disconnect with CS degrees is expectations about what is and what should be taught. A lot of students want a vocational program. Universities end up teaching a hodgepodge of topics such as how to write code in a particular language, program design/software engineering, algorithms and complexity, discipline specific specialties (e.g. AI, OSes), computability, etc.

When I was in university I was taught how to debug my code with ddd and gdb. Was this a waste of my time because I no longer use them? Of course not. Everything I learned with them carries over to the debuggers I use everyday. My degree also covered several languages that I've never used outside of classes. The skills I learned learning them help me any time I want to pick up a new language and start coding.

Code is not a primary tool for expressing algorithms and concepts. Code is how I tell the computer what to do. If code was so good for communicating concepts and algorithms to other people I wouldn't need to write comments. I also haven't seen any algorithm books that include real code. The closest you'll get there is MIX. Good luck programming a real application in that.

[mkartic]

Why the bitterness against CS?

As jarvic says,

> However, CS and software development are not the same thing.

A lot of schools offer a separate degree in Software engineering as opposed to CS (or at least separate tracks). So the distinction is pretty clear. Where I studied, there are separate degrees for CS and IT. You seem to be fudging the two. Do you expect physics majors to be mechanical engineers automatically?

CS degrees teach you algorithms, not how to write code in Java. Doesn't matter what IDE/language you're using, bubble sort is going to be slower than quicksort for large lists.

Yes, unfortunately most people who do CS end up becoming IT drones. That's the nature of the industry, not the CS program's fault. As a matter of interest, what do most physics majors become? I'm sure there aren't enough professorships available.

Or in the words of E.W.Dijkstra: “Computer science is no more about computers than astronomy is about telescopes.”

[blah32497]

Sorry if I came off as bitter. I'm a couple of years out of college and honest I felt that the CS department was pretty self entitled and misguided.

"CS degrees teach you algorithms"

Yeah it does. And it doesn't feel like it's really enough. There isn't a feeling by the end that you've learned only a small fraction of the algorithms and I guess it felt like there wasn't all that much science.

I went to a school with a decent department (I think top 20 in the US) but I never felt like they were actually doing any real, interesting, groundbreaking research.

In contrast, the Physics department is doing all sorts of stuff. Quantum computing, CERN related stuff, building new astronomical sensors, string theory stuff etc. etc. They've got their own problems, but at least it's something you can point to.

Physics majors are sorta screwed. Physics is sorta the opposite of CS. When you're done you feel like you've only learned a tiny bit and that there is so much more to understand. If you're not trying to go to grad school, the department doesn't really care about you. You end up having no marketable skills and your selling point is "I-went-through-a-insanely-difficult-degree-and-i'm-good-at-problem-solving". Most people can sorta code in Python, and sorta can do some circuit stuff. It's pretty bad.

People end up teaching, or working in unrelated jobs. Or going to grad school in related disciplines. One of my buddies ended up picking grapes with illegal immigrants.

[jarvic]

Disclaimer: I'm a CS PhD student that did pure math in undergrad, so I probably have a different perspective on these things than someone who did CS only.

CS, at a graduate level, is a much more varied field than most people, even CS undergrads, realize. In fact, a lot of the main research groups in my department (graphics, vision, image analysis, robotics, VR, visualization) are things most CS undergrads don't even get exposed to.

In math or physics, a lot of the undergrad courses are kind of basic, entry-level things that give you a feel for some of the different fields of research without going too far in depth. This isn't really the case with CS, because CS departments have to cater to several different audiences who tend to fall into one degree. They have to come up with a curriculum that balances programming/development concepts for people who want to be developers, networking/administration stuff for people who want to be IT (although this is more and more being moved into a separate program), and theory for people who actually want to be computer scientists. Even then, this theory is mostly relegated to computation theory, which is only a small part of what research computer scientists do.

Personally, I'm in medical image analysis, which is a field which is a collision between a ton of different areas, including physics, statistics, operations research[1], numerical analysis, image processing, differential geometry, and medicine. I don't know that I would consider any of those fields to be the "easiest branch of mathematics" (what does that even mean, anyway?)

This post has kind of gotten off the rails a little bit, so I'll end with this: I think, if you just look at a CS undergrad program and try to project that to what actual CS research is like, you end up getting a much narrower and incomplete picture than if you do the same thing to a math or physics department, partly because CS research tends to be much more interdisciplinary than others (I have many more collaborators in many more areas than some friends of mine in math/physics/biology do).

--

[1] http://en.wikipedia.org/wiki/Operations_research

[jiggy2011]

The purpose of a CS course is not necessarily to teach people to become developers. Indeed it would be interesting to know what % of CS grads even work as programmers post graduation, probably less than HN would imply. Based on the people I keep in touch with from my graduation class, I would put it somewhere near 30%.

[bjoernd]

That's a common thing I didn't understand about my fellow CS majors. Many of them did not want to become developers and even took pride in the fact that they made it until the final exams without ever having to hand in a single programming assignment they did themselves.

Yes, these people have amazing careers in management and consulting ahead. Is this good for the industry? I doubt it.

For me, the purpose of a CS course is to make people reasonable at programming with an advanced knowledge about the remainder of the field. It's easier to teach a programmer formal CS methods than to teach a formal methods guy to program.

[jiggy2011]

Funny, I always thought it the other way around. I struggle whenever I try to teach myself any formal/theoretical stuff because without the aid of a teacher checking my work I'm never sure if I really understand or not.

I never had a problem learning programming languages on my own by following examples though.

[lstamour]

I think you'll find that in CS, there's often if not always a way to implement or approximate the theory in code. To me, that's the more interesting part, but it requires self-learning because there are very few teachers who can blend theory into practical terms. Like the original EE intuition examples, perhaps it's something you appreciate after 10 years in the field.

[woebtz]

Ouch. Does that imply that finishing in the top 80% of your class then put you somewhere near the bottom 33% of developers?

[superuser2]

You are assuming that the best CS majors must obviously want to be commercial developers.

People go to grad school in other disciplines (sciences, stats, etc.) which can take advantage of computation, for one thing.

[jiggy2011]

Wouldn't that depend on the correlation between class grades and developer skill? I have no idea about that.

[socillion]

I'm curious - what do the remaining 70% do?

[jiggy2011]

Various things, a common aspiration was to try and fast track to a management position at a consultancy or blue chip where things were are more about spreadsheets than code. Others do technical work, but not strictly development like Q&A or technical support.

Some went into academia and some did other things altogether, I know at least one person who became a tree surgeon and another who is a session musician.

[msh]

Tech support and CS degree?!? It might just be me but I cant really see a person with a bachelor or masters in CS work in tech support.

[jiggy2011]

There are more jobs available, especially in places without software companies. Or people take those jobs temporarily while they look for other jobs, get promoted and end up following a different career track.

[cema]

If Q&A is QA then it should be considered development, in a specialized domain.

[Datsundere]

except you just click things on a GUI there.

[redblacktree]

I'm fond of developer-QA folks that automate most of their pointing and clicking. There is, absolutely, a skill in finding bugs by exploratory testing, but someone who can combine that with automating previous tests (thus building up a regression suite) in a way that's maintainable is a real keeper.

[cema]

I think you mean "except when..." As others said, QA automation is a serious endeavor, and an important one.

[bcbrown]

Unless you're writing test automation.

[m_mueller]

The debugger should be a concept to be taught, just like the compiler, linker, interpreter, assembler and so on. There should be at least a few lab hours where students are given existing programs and need to go for a bug hunt. This should include strace and valgrind, two essential tools that will probably not be outdated for quite a while.

Now, where I disagree is the IDE part. I have nothing against IDEs per se and I think everyone should be able to choose the tools he can work with best once (s)he starts a professional career. (hence why I like the concept behind cmake btw.). But I think it's a bad idea to start off with this as a student. An IDE comes along as an non separatable entity and it's hard to distinguish between the essential components behind it if that's the only thing you practice developing with. Students should learn what those components do from scratch and that's easier when you can see them as Lego bricks in front of you. IMO it's also a more satisfying learning experience than having MS, the Eclipse Foundation or anyone else holding the hand for you when you do your baby steps.

[vitd]

I see this as completely backwards. Tools like cmake are often worse for beginners because they have no idea how to understand them, and it involves learning another new language in addition to whatever programming language they're learning. Looking at something like Xcode or Visual Studio or Eclipse, where they can see "these are the source files that comprise my project," is much easier.

I do agree that learning the difference between the editor, compiler, the linker, and various other pieces is important, but I think there are better ways to do it than trying to understand the unix build tools right off the bat.

FWIW, my first exposure to all of this was in high school where we were taught Turbo Pascal on DOS. It was essentially a text-based IDE, but the teacher still taught us about the editor, the compiler, the linker, etc. and it made perfect sense. When I went to use the unix tools in college, it was quite confusing.

[blah32497]

I think it's important to hit the ground running using the best tools available.

"Students should learn what those components do from scratch"

Yeah, they will eventually. When they take a compilers class, they'll understand how the compiler works. It's okay to have that be "magic" in the mean time. They should be focusing on learning about OO principles, and data structures, and algorithms and not futzing with command line tools.

[Perseids]

> They honest to god think CS is an actually hard science on par with math and physics.

Theoretical computer science is a branch of mathematics. Don't dismiss the whole field just because your university chooses to under represent the theoretical side.

[wging]

Plenty of people still use ant. It's the path of least resistance where I work since we have a lot of tooling and preexisting code that use it.

[grayarea]

On that note plenty of people still use svn for the same reasons.

[lstamour]

As an update Gradle's easier to use Maven is gradually replacing Ant and has its sights on Make next. See Android for example.

[Mvandenbergh]

It also gives a huge advantage to students who've been coding for a few years, especially if they've been involved in open source projects. I used source control tools for my programming classes at uni (not a CS major) and it made me 50% more productive, easily.

[ygra]

We didn't even learn what source control is, let alone a tool like Subversion. We used it because some of us were familiar with it, but tools in general weren't taught.

[mnw21cam]

I was taught version control. In fact, university made very sure to emphasise proper source control in our second year group project, even to the extent of making one person in each group the "code librarian", responsible for making sure the code of the various members fitted together, was properly controlled, and safely backed up (which was me).

And of course the nightmare situation occurred. The project manager (read: no !*&^£ clue) "accidentally" deleted the entire source control repository. Reconstructed from backups from three hours previously, plus changes from peoples' working copies within half an hour.

[scott_s]

Print statements for debugging is not necessarily a bad thing: http://www.scott-a-s.com/traces-vs-snapshots/

[henrik_w]

Agreed! In the same vein, I recently wrote about both debugging vs logging [1] and about session-based logging [2].

[1] http://henrikwarne.com/2014/01/01/finding-bugs-debugger-vers...

[2] http://henrikwarne.com/2014/01/21/session-based-logging/

[scott_s]

Neat, we hit on many of the same points.

[henrik_w]

Yep!