An IDE, and what it is doing for you

An IDE is an editor that understands your code rather than treating it as text. That single difference is worth a great deal, and it is also why relying on it without knowing what it does leaves you helpless the first time you are on a server with nothing but vim.

#What it is actually doing

It builds an index. When you open a project, the IDE parses every file and every library and builds a model: which classes exist, what they contain, what calls what. That model is why "find every use of this method" is instant on a codebase with four thousand files, and why the IDE is briefly slow when you first open one.

It compiles continuously. Errors appear as you type because it is running a compiler in the background — the same checks javac does, just constantly. This is why a red underline is a real error and not a guess.

It refactors safely. Renaming a method by typing over it changes one word. Renaming it as a refactor changes the declaration and every call, and knows the difference between your close() and an unrelated close() on another class. That distinction needs the index.

It inspects. Beyond errors, it flags things that compile and are suspect: an unused variable, a null check that cannot fail, a resource never closed. Some are noise; most are worth reading.

#The parts worth learning deliberately

Most people use perhaps a tenth of an IDE and would benefit from four things.

Learn the keyboard shortcuts for the first two. They are the two you will use hundreds of times a day, and reaching for the mouse each time is a real tax on how far you follow a thought.

These are the four, in the three editors you are likely to meet:

#The auto-import, shown

The most common IDE injury is one keystroke. You type List, the IDE offers to import it, you accept without reading, and it imports the wrong one:

import java.awt.List;
import java.util.ArrayList;
 
public class Names {
    public static void main(String[] args) {
        List<String> names = new ArrayList<>();
        names.add("ana");
        System.out.println(names);
    }
}

Names.java:6: error: type List does not take parameters
        List<String> names = new ArrayList<>();
            ^
1 error

Read that error as a beginner would. It says nothing about imports, nothing about java.awt, and points at line 6 when the mistake is on line 1. java.awt.List is a graphical list widget from 1995 and it is not generic, so List<String> is meaningless to it.

The lesson is not "turn off auto-import". It is that the IDE offered you a choice, you did not read it, and the error appears somewhere else entirely. When an error makes no sense at the line it names, look at your imports first.

#What it is not doing

It is worth being precise, because the gap is where confusion lives.

• It is not the compiler. It runs one. javac on the command line produces the same result, and your CI will use that. "It compiles in the IDE" is not the same claim as "it compiles".
• It is not the build. Maven or Gradle decides your dependencies and how the artifact is assembled. The IDE reads that configuration and can disagree with it — which is the usual cause of "it runs in IntelliJ but the build fails".
• It is not the runtime. It launches a JVM for you and picks a working directory and a classpath while doing so. Those choices are often different from the ones your deployment makes, and that difference is a whole category of surprise.

#The runtime difference, shown

That last point is worth a demonstration, because it is the one that costs whole afternoons. A program that reports where it was started:

public class Where {
    public static void main(String[] args) {
        System.out.println("working directory: " + System.getProperty("user.dir"));
    }
}

Same class, same classpath, two places to start it from:

$ java -cp out Where
working directory: /w
 
$ cd sub && java -cp ../out Where
working directory: /w/sub

Nothing about the program changed. Your IDE makes this choice for you when you press Run — usually the project root — and your deployment makes a different one. Every relative path in your code is resolved against whichever it happens to be, which is why "it finds the config file in IntelliJ" is not evidence that it will find it in production.

#Which one

IntelliJ IDEA is the default for Java and its Community Edition is free and sufficient. Eclipse and VS Code both work; VS Code with the Java extensions is lighter and more common if you also write other languages.

The choice matters much less than people argue. What matters is learning one properly — its shortcuts, its debugger, its refactorings — rather than using three at ten per cent.

#What to be able to do without it

Not as asceticism. Because the machine where things are broken usually has none of it.

• Compile and run from the command line
• Read a stack trace without clicking on it
• Find text in a directory tree with grep
• Edit a file over SSH well enough to change one line

Each of these takes an afternoon to learn and turns "I cannot look at production" into "let me look".

#Misconceptions

• "The IDE fixed my code." It suggested and you accepted. Read what it changed; auto-imports in particular will happily import the wrong List.
• "Red underline means it will not run." Usually. But an IDE can be out of sync after a dependency change — if the error makes no sense, build from the command line before believing it.
• "Using the terminal instead is more hardcore." It is slower for writing code, and the index is genuinely useful. The point is not to avoid the IDE; it is not to be stranded without one.