Helping students adjust to using industrial-strength IDEs

Question

Something I've often observed is that many students find it challenging to figure out how to use full-fledged IDEs such as Eclipse, Netbeans, Visual Studios, IntelliJ, and PyCharm.

From what I can tell, this is due to a variety of factors:

1. The UI is often visually complex and intimidating for beginners. This is exacerbated in cases where your IDE unexpectedly changes appearance (for example, after running anything in Eclipse).
2. Setting up new projects and running even a simple "hello world" program is often non-trivial (you have to pick between several different "project templates", need to adapt to working in this new folder layout, sometimes need to configure your IDE to point to your compiler or editor...)
3. The IDE can sometimes be unexpectedly initially laggy. For example, IntelliJ will need to "index" your files/your standard library (with minimal visual cues that this process is taking place). This will cause functionality to be mysteriously laggy or missing for about a minute after first using your IDE.
4. The IDE often introduces several new "metaphors" that need to be explained. (For example, Eclipse has this notion of a "workspace" -- it's not immediately obvious this is actually a folder on your filesystem). This problem is further exacerbated by the fact that a small minority of students don't seem to have a firm grasp of what a filesystem is (which is disconcerting).
5. It's easy to accidentally screw up the appearance of your IDE. If you accidentally click a small button or drag-and-drop something by accident, you can remove an essential part of your view without an obvious way of getting it back.

In light of these factors (and other ones I may have missed), what is the best way to help students adapt to using IDEs?

I briefly thought about demoing how to install and use an IDE in class, but that seemed like a poor use of class time. My current idea is to provide handouts guiding students through their installation process, but I'm curious to see if there are more creative or effective solutions other people have come up with.

For the purposes of this question, we can assume students have completed at least CS 1, maybe CS 2, and have prior experience using either a text editor or a minimal IDE (such as BlueJ or JGrasp). I'd welcome both language-specific and language-agnostic answers.

Answer 1

IDEs are tools that are designed to solve specific problems.

They're great for stuff like:

• Compiling multiple projects that contain a bunch of classes.
• Dealing with dependencies on multiple libraries.
• Handling stuff related to coding, like starting up servers.
• Packaging and deploying your application.

If the students haven't encountered these problems, then honestly they probably aren't ready to use an advanced IDE. They don't have a need for it, and they should probably stick with whatever works for them.

Another consideration is that students need to understand what's going on "behind the scenes" before jumping into using an IDE. At a bare minimum, they need to understand:

• Basic command line interaction: How do you navigate over directories? How do you run programs?
• System Path: How does your computer know how to locate Java? How can you change this?
• Compiling and Running code: How do you compile a .java file via the command line? How do you run a .class file? What is the difference?
• Classpath: How do you use a library from your code, from the command line?
• Errors: What is the difference between a compiler error and a runtime error? How do you read a stack trace?
• Documentation: How do you consult the docs to figure out what functions a class has?

I say they need to understand this, because too often I see students who don't understand what the difference between path and classpath is, or who don't know what the red squiggly lines in their IDE are telling them, or who rely on auto-complete and copy-paste for everything.

All of that being said, I think you should start with a very basic text editor and the command line. Spend some time there and make sure they understand the basics. Then as their projects get more complicated, they'll naturally see the benefits of using an IDE.

Present the IDE as a solution to the problems that they're already experiencing.

• "Who here is sick of specifying the classpath argument whenever they compile their code?"
• "Does anybody wish it was easy to see what functions a class has without needing to do read through the docs?"
• "Now that we know how to export our application via the command line, let's see a quicker way to do that."
• "Now that we've learned how to debug using a piece of paper and a pencil, let's see a way to do that automatically."

Then introduce the IDE and point out specific ways to solve their specific problems. Throwing them in the interface and saying "here are 100 different things this can do" is going to be overwhelming. Build on what they already know, and solve the problems they're already experiencing with a more basic editor.

This makes sure that they understand what's going on behind the scenes, which helps demystify the process. It also gives them a good reason to use an IDE, by framing it as a tool that helps make their lives easier, which is what it should be.

Answer 2

Maybe I'm misunderstanding the question or maybe I keep skipping over a line, but it seems like the question is more about how to help students figure out how to actually use IDEs (what buttons to click, etc) rather than about how to convince them that IDEs are helpful.

How you help students adapt to an IDE depends on which IDE it is, but a "cheat sheet" of some features and potentially unfamiliar terms will help. If you can, you could also have an additional non-lecture session (e.g. regular or extra professor or TA office hours held group-style, a lab) held for students to attend if they want help setting up and navigating an IDE.

I'm currently a CS undergraduate student and TA. A few anecdotes behind my answer:

---

A lot of the CS classes I've taken have had an extra non-lecture session at the beginning of the semester for installation and troubleshooting help. For classes with lab sections, the extra session was a lab; for other classes, it was an extra office hours session or even just the first regular office hours. The professors don't even have to be there if there are TAs (although usually the professors are there).

---

I had to use Eclipse in one of my CS 2 classes (so this anecdote isn't as relevant). That was so confusing to understand (why won't drag-and-drop work the same?! Why can't I delete files from my system from right inside Eclipse like I could with jGrasp?! and other grievances), and even after reading who knows how many pages about what the heck workspaces even are (yes, including this one; to an early CS student--a.k.a. in everyday vernacular--"project" and "application" sound pretty interchangeable, but they're clearly used differently in that top answer...), I didn't quite figure out workspaces.

Everything you said about Eclipse resonated so strongly with me, but especially #2.

Eclipse also seemed excessive for the assignments we were doing in this early CS class, and we were never given anything that would make any of the seemingly extra features that were also required seem reasonable. (Still haven't in my classes. I'm half-expecting to get a wake-up call or crash course in the future once I'm out in the Real World.) I never did quite overcome my frustration with Eclipse enough to actually understand how to properly use it.

I managed to get by with some explanations provided by the professor and TAs about how Eclipse works so that I could at least submit working project files.

---

Last year (2018), I downloaded Visual Studio Code. This was so much easier to get used to. I don't remember how much I needed to do when I first installed it, but I definitely am not bothered every time I open it up like I am with Eclipse. To me, it works like a very enhanced text editor/file manager, no extra features shoved in my face (although they're there if I want to use them).

There's a commenter who said Visual Studio pretty much works "out of the box". I can only speak from experience for VS Code, but I agree.

Answer 3

The simple answer is don't:

Keep it simple. The IDE will amplify their productivity and their confusion.

Consider the difference between education and training.

Are you teaching the IDE, because you need to train them for work, or because it will help with their education. Your role at a university is education, not training. If you educate them (teach them how to learn), then they can train themselves.

When to introduce IDE

Therefore once the students can program, knows their file-system and operating-system, (don't run before you can walk) and it is of educational value, then you can introduce the IDE.

Customising

You could provide a customised configuration file, that simplifies the IDE, by removing items that are not needed, and adding those that are. Provide a procedure for restoring this configuration (as they will break it).

Answer 4

This is a good opportunity to offer a workshop on using the IDE. The workshop could be useful for multiple courses and classes so that other educators could also benefit from this. On top of it, it could allow the students who already have knowledge with the IDE the opportunity to teach a workshop session and to help other students.

The workshop can be offered by the department, and it can be offered similar to writing tutorial sessions or office hours.

Keep the IDE tutorial separate from the course itself. As you said, they're industrial-strength and should not eat into the material of the course.

Answer 5

I have experienced the same problem and I found a pretty easy solution by dividing the lecture into two parts: Theory (usually taught on the board) and Practical Demonstration (on IDE).

Now I come to the important point in your question (I had similar views to yours) on:

I briefly thought about demoing how to install and use an IDE in class, but that seemed like a poor use of class time

I saved the time by not slowing down too much during demonstration (to show them how to use every feature of the IDE) but recorded all the work (using Screen-Recorder software) and it really worked.

If there is a better approach than that, I hope someone would enlighten us here about that too but my experience with this methodology was excellent one.

Answer 6

You have said that they have already completed CS1 and CS2, so my approach would be slightly more aggressive but still focused on the basics.

Start with a simple analogy for an IDE. My personal favourite is that the IDE is like a kitchen in a house. Imagine that the dish/food/consumable item you want to prepare is Pizza. A good kitchen will have everything that you would need to prepare Pizza.

Similarly, you are trying to build a software/console or command line application. A good IDE is something that allows you to build an entire application, everything from a simple command-line 'hello, world' to world-changing software.

With the analogy done, lets tackle your points one by one.

• IDE appearance. I find that Eclipse is living in an unfortunate space between the old and the new. So, if possible, get rid of Eclipse because it's confusing, even for a pro like me. Try using more modern IDEs built with the modern student in mind. I am talking about Visual Studio, Android Studio or Xcode (if you are on Mac). If you are using Java, I might also suggest you try Netbeans which is a little more modern.
• Project Templates...okay, that is always a problem. In my case, I still go ahead and uninstall all the irrelevant templates from the machine. I mean, I ask the lab assistant to do it, but you get what I mean. This way, when the IDE launches, only the required one or two is available for the student.
• Screwing up the view. There is almost always a way to 'reset' the IDE to its initial state.

The other things, the minimal visual cues, and loading times...ah well, there is no getting around that. In my case, I simply have a 'time to grow up' talk with all the students. I tell them that they are no longer in their 1st year of college, and this is life now. The IDE, the complexity, the plethora of options, the imposing appearance, it is all part of their trade.

Its like eating vegetables. You don't have to like them, but you eat them anyway.