You know, it's a funny thing. When IntelliJ sees a type error or syntax error in your Java code, it offers a little yellow light bulb. You click on it and it helpfully offers several things that might fix your problem.

Well, one of the students in my class, in like the second of week of class when they're still learning the language, helpfully took one of those suggestions. What happened? The student was trying to add something to a list. They passed in a whole list rather than just a single thing. (Type error!) The suggested fix? Rewrite the list.add() function to always take a list. This change ripped throughout the code, the interface, everywhere, causing a giant stack of syntax errors. The student, needless to say, required assistance to set things right.

It might not *look* like a Clippy, but it can sure *act* like a Clippy.

Where I work, we just upgraded from VS 2013 to VS 2015. One of the new things in VS 2015 is a light bulb thingy like you describe.

I have yet to see the light bulb *ever* offer the correct suggestion. Each one of the suggestions has always been something which would have had the same kinds of terrible ripple effect in our code that you described in your anecdote. Luckily none of our interns has ever taken any of those suggestions. Yet.

Which is why lesson one in software classes should be source control

Indeed.

My class is (for most of these students) their very first exposure to any sort of version control system. Ever. To that end, we settled on using Subversion. Why?

- Clever students can't just edit their history and insert bogus timestamps (as in Git).

- We can set up a single server with different ACLs on each directory. (Trivial in Subversion. Not really a feature that Git easily supports.)

- And Rice already has a campus Subversion server along with scripts to build these sorts of configurations.

- Lower conceptual overhead and pain. (Do you really want to try explaining what a "detached HEAD" is and how to deal with it?) Note that we're using Subversion without any tagging or branching. Just a linear history. Likewise, we won't have any "oops, I committed it but I didn't push my changes" problems (although IntelliJ kinda papers over this issue with its internal VCS frontend).

The place where Subversion turns out to be causing us pain:

- One student used the web frontend, downloaded a zip file of the contents, and then couldn't figure out how to upload them again. (This despite ten pages of instructions of how exactly to get it set up properly.)

- I give them a new subdirectory every week which is an IntelliJ project with holes that they fill in. Some of them always manage to do the checkout at the wrong level of the hierarchy, so nothing works right. Just throw it away and start over again...

Sigh.

This week (the fourth week of the class) is when I'm starting to wean them from asking a question whenever there's the slightest ambiguity or compiler error. "Why yes, you'll need to solve that problem. Make a decision and document it."