Your Development Environment

In the last lesson you opened a terminal and typed a command. In the next one you will be asked to run git init. In between, one piece of information is missing: what has to be on your machine for any of that to answer at all?

The answer is not one big program you buy. It is four small parts — and the fastest way in runs through a different question. Not "what do I download", but "which question does this part answer".

Your agent uses the same four parts: it runs in the terminal or inside the editor and reaches for the same runtime and the same git you do. So this is not background knowledge. It is what lets you check its work.

What you will not find here: a click-by-click installation walkthrough. It looks different on every system and will be wrong in six months. It lives on the official pages linked below.

What a development environment actually is

A development environment is not a product. It is the sum of four parts: a place to read, a place to command, something that actually runs the code, and a way back to a state that worked. None of them contains the others.

Two practical things follow from that: you can find out in under a minute what you are missing — and you can recognise what you only talked yourself into needing.

Four parts, four questions

You can already picture the editor: a window with text in it, coloured and searchable. It is the place where you read and check — and the less you type yourself, because an agent has taken over part of the writing, the more that place matters.

You know the terminal from the last lesson. Only one thing is new here: it belongs to the basic kit, and you do not install one. Every operating system ships with one.

That leaves the part most beginners overlook, because you never lay eyes on it. An editor displays text, a terminal takes commands — neither of them executes anything.

That holds even if you never write a line yourself: the project's own tooling needs the runtime before you type anything. A major web framework lists a minimum version of it in its installation page, purely so the project can be started.

One misunderstanding is worth losing early: the package manager — the program that pulls ready-made code building blocks written by other people into your project — is not a second download. It normally arrives with the runtime; on some systems the distribution ships it separately. And which installation route you take is not this article's call but the package manager's own installation guide — it points at a version manager, for permission reasons.

The fourth part is git, the way back. What git does is the next lesson's subject; what counts here is that it is a separate program you install yourself, and that its entire mandatory setup is two configuration lines: name and email address, once per machine.

Example: four questions, four answers

Your setup is not a mood, it is four yes-or-no answers. You type the following queries into any terminal — your system's own or the one inside the editor, which is the same thing anyway.

Two of the answers look identical and mean different things. "Command not found" means either: not installed. Or: installed, but the command line cannot find it. Even the official guide of a major programming language knows the second case: it treats the search-path entry as its own, explicitly optional step.

The comfort that actually counts

Three conveniences of the editor are more than cosmetics, and one of them hides a trap.

Auto save exists, but it is off out of the box. You can switch it on in three ways: after a short delay, when you leave the file, or when you leave the window. Until then "it is in the editor" and "it is on the disk" are two different statements; once git joins in, a third one appears. Why unsaved text is gone after a crash is something you already know from step 1 of this learning path.

The diff view puts old and new side by side. It is the one genuinely useful thing on screen when an agent has rewritten files you did not watch being written.

And the built-in terminal is not a different terminal: every command from the terminal lesson works in there unchanged.

The shortcut: renting an environment

There is a route where you install none of it: a cloud development environment. That is a machine somebody else keeps ready, reachable in a browser tab, with all four parts already on it.

What it takes off your hands is the installation. Nothing more. The four parts are still there, you just operate them on somebody else's machine. Which is why this section comes after the first one and not before it.

Think of a rented workshop rather than your own basement. You rent time and space at somebody else's bench, the clock runs while you work, and when your time is up you are out. Your only copy is best not left lying there.

Example: the arithmetic behind the free allowance

Two free tiers, two opposite shapes. One of them counts in core hours, and that is the whole point: the provider works it out on its own product page using a two-core machine — and there, half of the monthly allowance survives as real run time. On a machine with twice as many cores it halves again.

The second tier is the inversion: more hours per week, less persistent storage, a hard cap per session and a rule that forgets. That is not a ranking, it is a choice.

The thing to remember is not a number at all but a calculation: divide by the core count. It holds for every provider, including the ones that do not exist yet.

"In the cloud I need nothing" is not quite true: you need a browser and an account. And the browser-only editor from the deep dive above is explicitly not an environment — without a terminal and a runtime you can read and edit, but you cannot run anything and cannot check anything.

"Whatever is in the cloud stays there" is even less true. One provider deletes the home directory after the period of inactivity named in the tier box above and states that the files cannot be recovered. The other blocks usage once the allowance is exhausted — and, in the same documentation, names exporting your work-in-progress to a branch as the way out.

That is where the analogy breaks, and it breaks in your favour: from a rented workshop you carry the workpiece home, here it moves into a repository that any new workshop can open again. The environment is the perishable part, the repository is what persists — and it lives in a third place, neither in the rented workshop nor in your hands.

What you do NOT need

This section is not an opinion about tools. It is a count.

Example: what the official guides actually require

Take the installation pages of real projects and write down what they list as required. A major web framework carries four points: a runtime in a minimum version, a text editor, a terminal — and, fourth, an add-on tool for the editor that it explicitly only recommends. Three of them are required; the fourth is advice. A second one names two under "System requirements". Git's own book asks for two configuration lines, once per machine. The editor asks for the hardware in the box above.

Now the second count: what appears on none of those lists? A full IDE, a graphical git program, a container runtime, a Linux subsystem as a requirement, a new computer. This list is longer than the first, and everything on it is something somebody added themselves.

The packing list is written by the destination, not by the shop. What you have to take with you is decided by where you are going — not by how well prepared you would like to feel. That is exactly why one page requires three things and the other two: the difference comes from the projects, not from you.

And here is the limit of a packing list: it names the floor, not the ceiling, and it is written per destination. The documented case is the Linux subsystem on Windows. The vendor recommends it under an explicit condition — if your software is going to run on Linux servers, or your tooling is Linux-based. If neither applies, it is an option and not a rite of passage.

"I need a new computer" is settled by the box above: the floor documented there sits far below what any device that still boots brings with it today.

"Without a graphical git program I will never understand git" gets it backwards: git's own book records that such programs can do nothing the command line cannot. The one genuinely useful view you already have in the editor.

There is now a category of editors with a built-in agent. For the minimal setup you do not need one: any editor plus a terminal will do.

An open departure

The same documentation we owe the "install it when you need it" rule to also tells beginners not to worry about version control yet. We depart from that one item, and we would rather say so than quietly trim the source: its advice is written for somebody typing HTML by hand. You work with an agent that changes files you have not read.

What now?

Four questions, four parts: where do I read? How do I command? What executes? How do I get back? Three of them you now have as far as you need them for a start.

The fourth has earned a lesson of its own. The cloud provider's way out from earlier — get your work into a branch — only helps if you know what a branch is.

Which is exactly what the next article is about.