Your Tools — the Terminal, the Editor, and Knowing Which to Reach For

The first morning

Arjun's first morning at the company was a Monday in July. He had graduated three weeks before from an engineering college in Vijayawada. The HR person walked him to a desk, handed him a laptop, said welcome, and disappeared. On the laptop's desktop was a sticky note with three things written on it. His email password. The Wi-Fi password. And a line that read: ssh [email protected].

Arjun knew what a terminal was. He had used Command Prompt in his networking lab to ping things. He had run javac from a command line for his second-year Java assignments. He had a vague memory of someone in his class mentioning SSH during a cloud computing elective.

What he had never done was live in a terminal. The terminals he had seen were places you opened, ran one command, and closed. The line on the sticky note implied that the terminal was not a tool for one command. It was where his actual work was going to happen. He typed the line into Command Prompt. The response was an error he had never seen before. He tried again, more carefully. Same error.

He sat very still for two minutes, feeling the small panic of a fresher who realises, in the first hour of the first job, that the gap between what college taught and what work requires is wider than anyone had warned him about. He had spent three years writing Java in an IDE and running things from a Run button. He had used a terminal maybe twenty times in those three years, never for more than a single command.

What Arjun did not know yet is that the answer was twenty minutes of reading, a small piece of software called WSL, and a shift in mental model. By the end of his first week, the terminal would feel like home. But on that first morning, sitting at a desk in a quiet office in Hyderabad with a sticky note he could not act on, the gap felt like a chasm.

This chapter is for Arjun. And it is for you, before your first morning.

1. Your tools are not neutral

Two engineers, asked to solve the same problem, will reach for different tools. The first might open VS Code, write code in a fresh file, and run it from the editor's play button. The second might open a terminal, write the same code in vim, and run it from a shell command. They will produce different code. They will hit different bugs. They will think slightly different thoughts along the way. The tool shapes the work.

Most students never think about their tools deliberately. They use what was installed in the college lab. They use what their senior recommended. They use what looks easiest, which usually means the tool that hides the most. This is the wrong way to choose, because the tool that hides the most is also the tool that teaches you the least.

This chapter is not going to make you abandon your IDE. IDEs are good. They save time. They catch mistakes. They are how working engineers ship work in the real world. But to use them well, you have to know what they are hiding from you, and you have to be comfortable in the layer below when you need to be. That comfort, almost always, lives in the terminal.

2. The terminal is not scary, it is just unfamiliar

A terminal is a text-based conversation with the operating system. That is all it is. You type a line. The OS does what you asked. The OS shows you the result. You type the next line. There is no magic. There is no danger that you cannot recover from with a few minutes of careful thought. The terminal only does what you tell it.

The reason it feels intimidating is not that it is hard. It is that it is unfamiliar, and unfamiliarity feels like difficulty even when the underlying thing is simple. The terminal is not harder than driving a scooter. You just need someone to sit behind you for a few hours while you wobble.

Before you type any of what follows, make one folder to practise in — something like mkdir ~/sandbox and then cd ~/sandbox — and do all of your experimenting inside it for now. Most of the commands below only ever look at things and cannot hurt you. A few change or delete things, and this book will say so explicitly the first time each one appears. Having a sandbox folder means that even if you get one of those wrong while you are still learning, the only thing that happens is that your sandbox folder gets messy, not anything you actually care about.

Here are the first ten commands. Learn them by using them, not by memorising them. Most of these only look — they cannot change or delete anything.

pwd tells you which folder you are currently in. Print working directory. Useful constantly. The terminal does not show you your location on the screen the way a file explorer does. You have to ask.

ls lists what is in the current folder. The Linux and Mac version of double-clicking a folder to see what is inside.

cd folder-name changes your current folder to the one you named. cd .. goes up one folder. cd ~ goes to your home folder. cd / goes to the root of the whole filesystem. The four of these together will take you anywhere on the machine.

mkdir new-folder-name makes a new folder. touch new-file-name.txt makes a new empty file. Together they let you create the entire structure of a project from the command line in seconds. Both of these create something new — safe, but worth noticing that you have crossed from looking to changing.

cat file-name prints the contents of a file to the screen. Useful for small files. Painful for large ones. This one only looks.

cp source destination copies a file — the original stays put, so this is low-risk. mv source destination moves it, which means the file no longer exists at its old location once you run this — read the destination carefully before you press enter. The same command, mv, is also how you rename a file, because renaming is just moving it to a new name in the same folder.

rm file-name deletes a file. This is the command in this section to be genuinely careful with. There is no undo. There is no Recycle Bin. The file is gone. We will come back to this in a moment.

man command-name shows the manual for any command. man ls will show you the manual for ls, which is long and intimidating but contains every option the command supports. Working engineers do not memorise these manuals. They look them up when they need them. The skill is knowing that the manual exists.

Spend a real evening using these ten commands. Make a folder. Make some files. Move them around. Copy them. List them. Open them. Delete them. Do this until each command feels less like a sequence of letters and more like a verb you know.

The next ten commands change the game.

grep "word" file-name searches a file for a word and shows you the lines that contain it. Combined with other tools, this is the closest thing the terminal has to a superpower. Every engineer uses grep more than they expect to.

find /some/folder -name "*.py" finds all files in a folder tree that match a pattern. You will use this in your first real job, almost certainly in the first week.

wc file-name counts the lines, words, and characters in a file. Word count. Pleasingly old-fashioned. Surprisingly useful.

head -20 file-name shows the first twenty lines of a file. tail -20 file-name shows the last twenty. tail -f file-name follows a file in real time and prints new lines as they appear, which is exactly what you do to watch a log file while debugging.

less file-name opens a file in a scrollable view that does not load the whole file into memory. Press q to quit. Press / to search. The right tool for any file larger than your screen.

ps shows the processes running on your machine. ps aux shows them all, with details. Combined with grep, this is how you find a specific running program.

kill 12345 stops the process with the given ID. kill -9 12345 stops it more forcefully. This one changes something running on your machine, not a file, so it is a different kind of risk — read the process ID twice before you send it. You will need this on your first day that you accidentally start a script that does not stop on its own.

df -h shows how much disk space is used on each mounted drive, in human-readable form. Useful when something stops working because the disk is full.

top shows a live view of the processes consuming the most CPU and memory. You met this command in the last chapter. It will become a friend.

Twenty commands. That is enough to live in the terminal for the rest of your career. Everything else, you will pick up by need, by accident, and by reading other people's commands and asking what they do.

A word about rm -rf, because every engineer has a story. The -r flag means recursive, which means delete this folder and everything inside it. The -f flag means force, which means do not ask, just do it. Together, rm -rf on the wrong directory has erased databases, lost weeks of work, and, in at least one famous case, taken a startup offline for a full day. The rule for the first year of your career is simple. Before you press enter on any command that starts with rm -rf, stop. Read the path. Read it again. Then press enter, or do not. The two-second pause is the cheapest insurance in the field.

3. Pipes, and the original "compose small things" idea

Here is the moment the terminal stops being scary and starts being interesting.

Each command in the terminal does one thing. ps lists processes. grep filters lines. wc counts things. None of these, on its own, is impressive. But you can connect them. The output of one command can become the input of the next. The pipe character, |, is how.

Try this. Open a terminal and type:

ps aux | grep python | wc -l

This says: list all processes, then keep only the lines that mention python, then count how many lines are left. The result is the number of Python processes currently running on your machine. You did not write a program to do this. You composed three tools into a new tool, on the fly, in one line. The Unix world calls this piping. It is, in my view, the single best idea computer science has ever given working engineers.

The implication is enormous. Once you see pipes, you start to see them everywhere. Every command becomes a Lego block. The tools that are easy to compose together are more valuable than the tools that try to do everything themselves. This is the philosophy behind everything good in the terminal world, and it is worth one slow read of the original 1978 statement of it (which is the read for this chapter).

4. Environment variables, PATH, and the source of half of all "it works on my machine"

This is the part of the terminal that nobody teaches and that bites every fresher in their first month.

When you type a command like python in your terminal, the terminal has to find the actual Python program somewhere on your disk and run it. How does it know where to look? It looks in a list of folders called your PATH. The PATH is a long string of folders separated by colons (or semicolons on Windows), and the terminal searches them in order. The first one it finds with a program called python wins.

This is why your senior can run a command and you cannot, even on the same machine. Your PATHs are different. They have different folders. The program is there, but the terminal does not know where to look.

The PATH is one environment variable. There are many others. Programs read them to learn things about their environment. The classic ones include HOME (your home folder), USER (your username), and increasingly OPENAI_API_KEY or ANTHROPIC_API_KEY (which configure AI tools). The rule, learned the hard way by every engineer eventually, is that environment variables are how you tell a program something without writing it in the code itself. Secrets, configurations, locations, all live in environment variables.

You set an environment variable in your terminal by typing something like export MY_VAR=hello on Linux, Mac, or inside WSL. But these only last for the current terminal window. To make them persist, you put them in a file — usually .bashrc or .zshrc, living in your home folder.

A specific note for "Windows," because that word actually hides three different shells with three different syntaxes, and mixing them up is exactly the kind of thing that cost Arjun his first confused morning. Command Prompt (the classic black window, cmd.exe) sets a variable with set MY_VAR=hello. PowerShell, a newer and more capable shell that also ships with Windows, sets the same thing with $env:MY_VAR = "hello" — different syntax entirely, even though both are technically "the Windows terminal." WSL, the Windows Subsystem for Linux this chapter keeps recommending, gives you a real Linux shell running alongside Windows, and inside it you use the same export MY_VAR=hello syntax as any Linux machine. Three shells, three syntaxes, one operating system. If a command you copied from the internet does not work on Windows, check which of the three it was written for before you assume you typed it wrong.

The reason this matters is that, in your first few months at work, when something does not work for you that works for everyone else, the answer will, more often than you would believe, be an environment variable. A missing one. A wrong one. A path that is set differently on your machine. Knowing this will save you hours of confused debugging.

A small honest note. Do not edit your .bashrc or .zshrc carelessly. Every line you add to it runs every time you open a new terminal. A typo in one line can mean that all your terminals stop working until you fix it. The convention among working engineers is to back up your .bashrc before editing it, every time, and to comment every change you make with a note about what it does and why. Future you will thank present you.

5. SSH, and the basics of remote work

Eventually you will need to get into a server that is not on your desk. The way you do this is called SSH, which stands for secure shell.

The mental model. SSH is a secure tunnel that lets your local terminal talk to a terminal running on another machine, anywhere in the world. You type a command at your laptop, the command is encrypted, sent over the network, decrypted at the other end, and run on the remote machine. The output comes back the same way. To you, it feels exactly like a normal terminal. It just happens to be on a server in Mumbai or a virtual machine in Singapore.

The command to open an SSH connection looks like this:

ssh username@server-address

You type it. If everything is set up, you are now logged into the remote machine. Type ls, and you see the files on that machine, not yours. Type pwd, and you see your location on that machine. Everything you have learned in this chapter works exactly the same on the remote machine as it does on your laptop. The terminal is the terminal.

A short note on authentication. There are two ways to prove you are you when SSHing into a server. The old way is a password. The new way is a key pair: a public key you copy to the server, and a matching private key that stays only on your own laptop. After that, the server recognises your laptop and lets you in without a password. Almost every working engineer has stopped using passwords for SSH, for a good reason: passwords can be guessed or brute-forced over the network, and a key pair cannot be attacked that way at all. This is not the same as saying a key pair is unbreakable — it is safer than a password, not magical. Your private key file is only as safe as the laptop it lives on. If someone steals your laptop, or copies your private key off it, or you generate a key without a passphrase on a machine other people also use, the key can be misused exactly like a stolen password could. Set a passphrase on your private key when you generate it, keep the key file itself off any shared or public machine, and treat "I have SSH keys set up" as a floor to build good habits on, not a reason to stop thinking about who can reach your laptop. The setup takes ten minutes and you do it once. Look up "how to set up ssh keys" the day before you need them, and never type a password into an SSH prompt again.

One more thing about SSH and remote machines, particularly for your first year. Most servers you will SSH into are shared. Other engineers are also working on them. The directories you can write to are limited. The commands you can run are limited. And, critically, there will be one special user called root whose access is unlimited. The unwritten rule of the first year is: do not log in as root unless you have to, and do not run commands as root unless you are sure. A wrong rm -rf as a normal user might delete your own files. The same command as root might delete the company's files.

6. The editor and IDE spectrum

You will spend more hours of your career inside a text editor than in any other piece of software. Choosing one well, and learning a second one, is a real investment.

The honest map of choices, from least to most opinionated.

On the least opinionated end are the simple terminal editors. nano is the friendliest. It opens, you type, you save with Ctrl-O and exit with Ctrl-X. The keyboard shortcuts are listed at the bottom of the screen. There is no learning curve. For quickly editing a config file on a remote server, nano is perfectly fine. Many engineers use it for years.

Then there is vim. Vim is the editor that everyone has a feeling about. It is famously hard to exit (the joke is that some engineers' careers began by accidentally opening vim and not being able to leave). The reason vim has a reputation is that it has modes. You are either in normal mode (where typing letters does not insert them but moves the cursor and runs commands) or insert mode (where typing letters actually types them). This is genuinely confusing for the first hour and genuinely liberating after the first week. Vim is faster than any other editor in the hands of someone who knows it, because every action is a single key press, not a mouse click.

I want to be honest about whether you should learn vim. The argument for: one day, you will SSH into a server that has no internet access, no GUI, and only vim installed. You will need to edit a file. If you do not know vim, you cannot do your job. This is rarer than vim evangelists claim but more common than vim sceptics claim. The minimum useful vim is: how to open a file, how to enter insert mode (press i), how to leave insert mode (press Esc), how to save and quit (type :wq and press enter), and how to quit without saving (type :q! and press enter). Five things. That is enough to survive any vim encounter for the first three years of your career. Learn these. Skip the rest until you want to.

In the middle of the spectrum are modern code editors. VS Code is the dominant one as of writing this book. Sublime Text, Zed, and several others are in the same category. These editors are smart. They highlight your code by language. They autocomplete as you type. They run commands in a built-in terminal. They have extensions for everything. They stay out of your way most of the time. If you are starting a new project and have free choice, this is where to start.

At the most opinionated end are the full IDEs. The JetBrains family (IntelliJ for Java, PyCharm for Python, WebStorm for JavaScript, and others) is the leader in this category. Visual Studio for C# and C++. Android Studio for Android. Xcode for iOS. These IDEs do everything for you. They run your code, they manage your project, they refactor across files, they debug step by step, they generate boilerplate. They are heavy. They start slowly. They use a lot of memory. In return, they make complex, long-lived projects significantly easier to work in.

The right answer for a student in 2026 is: pick one editor from the middle spectrum (VS Code is the safe choice, Cursor is a close cousin we will discuss in the next section), learn the minimum survival vim listed above, and reach for a full IDE only when you actually need it. Most likely, you will end up using VS Code or Cursor for everything for the first two years of your career, vim for emergencies, and a full IDE only if you join a team that has standardised on one.

7. The AI-assisted editor in 2026

This is the section the chapter exists for. The landscape has changed faster than any other part of the developer tooling world over the past two years, and the change is not done.

AI assistance is now baked into editors at three different depths. Understanding the three layers is more useful than knowing the names of the specific tools, because the names will change. The layers will not.

The lightest layer is autocomplete on steroids. As you type code, the editor predicts the next few lines and offers them in grey text. You press Tab to accept. GitHub Copilot popularised this in 2021. Tabnine and a handful of others do similar things. The tool is fast, ambient, and low-friction. It is the easiest way to begin using AI in your daily work, and it is the layer at which the risk of dependency is highest because the tool helps you without you actively engaging it. You will accept suggestions without reading them. This is, in my view, the most dangerous layer for a junior engineer.

The middle layer is conversational assistance. You highlight a piece of code, ask the editor to explain it, refactor it, or write a new piece of it, and you have a back-and-forth conversation. Cursor's chat panel, GitHub Copilot Chat, and most modern code editors now ship some version of this. The tool is genuinely useful for learning, because the conversation forces you to articulate what you want and to read what the model produced. The risk is lower than the autocomplete layer because the action is deliberate. The benefit is higher because the tool can do bigger things.

The deepest layer is agentic mode. You describe a goal, possibly several sentences, and the tool plans the work, runs commands on your machine, edits multiple files, runs tests, iterates on what it finds, and reports back when it thinks it is done. Claude Code, Cursor's agent mode, and Windsurf's cascade are the canonical examples as of writing this book. The tool's capabilities at this layer have grown faster than at any other layer over the past year. What used to take an experienced engineer a full day, an agentic AI can sometimes do in fifteen minutes. The risk is that you have outsourced not just the typing but the thinking. You are no longer the engineer. You are the manager of an engineer who never explains itself and whose mistakes you will inherit.

How to choose, in plain practical terms. As of writing, in early 2026, the recommended setup for a student or junior engineer is: VS Code or Cursor as your everyday editor (they are nearly interchangeable, Cursor ships AI integration out of the box), the survival-vim mentioned above for emergencies, the system terminal (with WSL on Windows), and one AI assistant of your choice, used deliberately at the conversational layer and only cautiously at the agentic layer until you have your own judgement to bring to its output.

I want to flag, in writing, that the specific tool names in this section will likely have shifted by the time you read this. The three-layer model — autocomplete, conversational, agentic — will not. It is the mental map. The tool names are placeholders.

9. Where this shows up

Arjun's first morning ended, in the end, with the senior at the next desk noticing his stillness, walking over, and saying "first time on a real terminal?" He nodded. She showed him WSL in twenty minutes. By Friday, he was SSHing into the dev server without thinking about it. Six months later, he was the one who showed the next batch of freshers. The gap between not knowing and knowing was not a chasm. It was twenty minutes of someone caring enough to bridge it.

This chapter has been about that twenty minutes.

The terminal, the editor, and the AI assistant are not topics that live only in one corner of engineering. They are everywhere. A DevOps engineer at 2 AM responding to a production incident is in a terminal, SSH'd into three servers at once. A data scientist working on a remote GPU server is doing the same. A backend engineer adding a feature, a frontend engineer debugging a build failure, an SRE chasing a memory leak, a security engineer reviewing logs — all of them, every day, live in the tools this chapter has described. The specific commands change with the domain. The mental model does not.

Learn this layer well now, while you have the time, and you become the person who is calm in the moments when others freeze.

10. A quick check before you move on

1. What does the PATH environment variable actually do, and why can two engineers on the same machine run different python commands?
2. What is the difference between logging in with an SSH password and logging in with an SSH key, and why has almost every working engineer stopped using the first?
3. Name the five vim commands this chapter said were enough to survive an emergency. If you cannot, that is exactly the gap Section 6 was trying to close.