Programs read text and write text, and the shell moves that text around. > sends output to a file, < reads from one, and | feeds one program's output into another's input. This is where a command stops being one step and becomes a pipeline you can read left to right.
About 1 min of reading
Build a pipeline one stage at a time.
Stage one
Before you run it, say out loud what it will print. Then open the answer.
Add the filter
Before you run it, say out loud what it will print. Then open the answer.
Add the count
Before you run it, say out loud what it will print. Then open the answer.
Run the first stage, then add the next, then the next. Each stage's output is visible, so a wrong answer is found at the stage that introduced it rather than guessed at the end.
2> sends errors to a file and 2>&1 folds them into the normal output. A pipeline that produces nothing may have failed loudly on the error stream, which is why capturing both is worth the extra characters.
ls > list.txt writes the listing into a file instead of the screen. The program does not know about the file; the shell arranged the connection. That separation is why the same program works in a pipeline and on the terminal.
cat data.txt | grep ERROR | wc -l counts the error lines. Read it as a sentence: take the data, keep the errors, count them. Each stage is a normal command and can be run alone to check it.
A single arrow replaces the file, including truncating a file that had content. Two arrows add to the end. The difference is one character and it decides whether a log survives a run.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.