The first stop on my full-stack roadmap is the one nobody teaches, because it is not a project. It is the workshop the projects happen in: a terminal you are comfortable in, an editor set up the way you like, keys that let you push code without typing a password, and a Git routine you do not have to think about. A carpenter sets up the bench and sharpens the tools before the first cut. Skip it and every later stop is slower and more frustrating than it needs to be.
The terminal is a conversation with your computer
The terminal is a text-based way to talk to your computer, and the shell is the program inside it that reads what you type and runs it. Beginners avoid it because it looks unfriendly. It is worth getting over that early, because every tool from here on, from Git to deployment, is driven from it, and once it is familiar it is faster than clicking.
You need a small vocabulary to start: move between folders (cd), see what is in one (ls),
make one (mkdir), and run a program by typing its name. That is most of a working day. On a Mac
or Linux the default shell is fine; many developers switch to zsh with a helper like Oh My
Zsh for nicer prompts and autocomplete. A little Linux fluency (files, permissions, processes)
pays off later when you touch a server, because a server is just a Linux machine with no screen.
cd ~/projects # go to a folder
ls # what is in here
mkdir my-app # make a new folder
code my-app # open it in the editor
The editor, and the files that make it yours
Pick one code editor and learn it well. For most people that is VS Code: free, everywhere, and the one most tutorials and AI coding tools assume. Learn its shortcuts for finding files and searching across the project, because “find where this thing is used” is a task you do fifty times a day.
Your setup lives in dotfiles: configuration files whose names start with a dot, like
.zshrc for the shell or .gitconfig for Git, sitting in your home folder. The habit that pays
off: keep them in a Git repository, so a new machine gets your exact setup in minutes instead of a
day of remembering.
Keys, so you never type a password again
Pushing code to GitHub (or logging into a server) should not mean typing a password each time. It should use an SSH key: a matched pair of files, a private one that stays on your machine and a public one you hand to the service. When you connect, the two prove it is you, silently.
ssh-keygen -t ed25519 -C "you@example.com" # make the pair, set a passphrase
cat ~/.ssh/id_ed25519.pub # copy this public half to GitHub
CAUTION
The private key (id_ed25519, no .pub) never leaves your machine and never goes in a
repository. Protect it with a passphrase. The public one (.pub) is safe to share; that is its
whole job. Mixing these up is a classic first-week mistake.
The Git routine you stop thinking about
Git starts life as a save button: commit, push, done. Professional work uses it as a routine, and the routine is the same at nearly every company: work on a branch, not on the main line; open a pull request (PR) to propose the change; someone reviews it; it merges. Main always stays working, because nothing lands there without a second look.
flowchart LR B[Make a branch] --> W[Commit as you go] W --> P[Open a pull request] P --> R[Review] R --> M[Merge into main] M --> B
git switch -c fix-login-bug # new branch for this one change
git add . && git commit -m "fix: handle empty email on login"
git push -u origin fix-login-bug # then open the PR on GitHub
One more word you will hear: rebase. It replays your branch on top of the latest main so the history stays a clean straight line instead of a tangle of merges. Learn it after branches and PRs feel natural, not before.
TIP
Small branches, small pull requests. A change that touches one thing is easy to review, easy to revert, and merges in a day. A branch that grows for two weeks becomes something nobody wants to review. This one habit does more for your reputation on a team than any framework.
AI tools are part of the bench now
The last piece of a 2026 workshop is an AI coding tool, the kind that reads your project and edits files with you. It is standard equipment, not a cheat, and setting it up belongs here: install it, and give it a short context file describing your project and its rules, so every session starts briefed. How to actually work with one well is the first stop on the AI roadmap.
The tools you actually reach for
| Job | Popular tools | Note |
|---|---|---|
| Shell | zsh + Oh My Zsh, bash | Free; zsh is the common upgrade |
| Editor | VS Code, Cursor, Zed | VS Code is free and the default assumption |
| Dotfiles | A Git repo of your config | Free; symlink files into your home folder |
| SSH | ssh-keygen, ssh-agent | Built in; use ed25519 keys |
| Git hosting | GitHub, GitLab | Free for personal work |
| AI coding tool | Claude Code, Cursor, Copilot | Free tiers; a project context file makes them useful |
The bench is the work
The lesson from this stop is that setup is not a delay before the real work. It is the thing that decides how the real work feels for years. A familiar terminal, an editor that fits your hands, keys that just work, and a Git routine on autopilot are what let you spend your attention on the problem instead of on the tools. Every professional you will ever meet has done this. Do it once, properly, and keep it in a repository.
Sharpen the tools before the first cut.
Sources
- daily.dev: CLI basics for developers, commands and guide (2026) for the terminal, the shell, and the core commands
- DynamicBytes: how to set up a good beginner programming environment in 2026 for the editor choice and beginner setup
- g.p. anders: managing dotfiles with Git for keeping dotfiles in a repository
- GitHub docs: generating a new SSH key for the ed25519 key setup
- dev.to: a beginner-friendly Git workflow for developers for branches, pull requests, and rebase