Why These Tools

Before touching an installer, you need to understand what problem each tool solves. If you don't know the problem, the tool feels arbitrary — just another thing to install because someone told you to.

Both of these problems will feel familiar. You have experienced both in your CA practice.

---

Why Node.js

Scenario: Your App Lives Only on Your Laptop

Imagine you've built a useful tool — a GST reconciliation checker that takes two Excel files, finds the mismatches, and flags them. You built it using modern JavaScript and React. It works perfectly on your laptop.

Your colleague in another office wants to use it.

So you email them the code files.

They open the folder. Nothing runs. They double-click some files. Nothing happens. They ask you how to open it. You say "just run it." They don't know how to "just run it."

The problem: JavaScript code cannot run directly on a computer the way a .exe file can. Your web browser can run JavaScript — that's how every website works. But standalone JavaScript files, outside a browser, have nowhere to go. The computer doesn't know what to do with them.

Node.js is the solution. It gives your computer the ability to read and execute JavaScript files directly — no browser required. When you install Node.js, your computer gains a new capability: it can now run JavaScript the same way it runs Python scripts or executable programs.

Every modern JavaScript tool — React, Vite, Next.js, TypeScript, the Claude Code CLI itself — is built to run on Node.js. Install it once and your computer can work with any of them.

Scenario: Consistent Environment Across 20 Laptops

Imagine running this training program but you're responsible for making sure every one of the 10 trainees can run the same project, with the same behavior, on their own laptops. Some have Windows 10, some Windows 11. Some have older hardware, some new.

If JavaScript ran differently on different computers, or required different installation steps on each machine, you'd spend the first week of every training batch just troubleshooting environment issues. Every minor version difference would cause a different error on a different machine.

Node.js solves this with version management. When we say "install Node.js 20 LTS," everyone gets the same version, the same behavior, the same npm. A project that runs on your Node.js 20 will run on everyone else's Node.js 20 identically.

The LTS designation — Long Term Support — means this version has been declared stable, tested extensively, and will receive security updates for three years. It is the version you use for serious work. Not the newest version (which might have unstable features), and not an old version (which might have security gaps). LTS.

---

Why Git

Scenario: The Client Wants Friday's Excel Model Back

You've been building a complex financial model for a client. Three months of work. You've been updating it every week.

On Wednesday, the client calls. They need to file something with a regulatory body, and they want the version of the model from Friday — the one with last week's figures, before you updated the assumptions on Monday.

You search your computer. You find:

• Final_Model.xlsx
• Final_Model_v2.xlsx
• Final_Model_v2_REVISED.xlsx
• Final_Model_v3_USE_THIS.xlsx
• Final_Model_v3_USE_THIS_copy.xlsx
• Final_Model_v3_actual_final.xlsx

You genuinely don't know which one is "Friday's version." The names mean nothing. The dates on the files got corrupted when someone copied them to a USB drive and back. You spent the next two hours comparing columns trying to reconstruct which version had which numbers.

This is not a problem with Excel. This is a problem with manual version management. Without a proper system, humans create chaos — files named "final," "actual final," "really final" — and then can't recover the version they need when they need it.

Git is the solution. With Git, instead of saving different copies with different names, you take a commit — a named snapshot of the entire project at a specific moment. Every commit has:

• A message you write: "Updated tax assumptions for Q4"
• A timestamp: exact date and time
• Your identity: who made this change
• A complete record of everything that changed

When the client asks for Friday's version, you type one command and see a list of every snapshot ever taken, with messages and dates. You pick Friday's. Done.

Scenario: Three People Editing the Same Excel File

Now extend that scenario. You, your colleague, and a junior staff member are all working on the same model simultaneously. You're working on the P&L sheet. Your colleague is updating the balance sheet. The junior is entering raw data.

You're all emailing the file back and forth. Or worse — you put it on a shared drive and try to coordinate over WhatsApp. Someone saves over someone else's work. You don't know whose changes are in the current version. Someone's formula got deleted and nobody knows who did it or when.

Git eliminates this class of problem. Each person works on their own branch — a separate copy of the project where their changes are isolated. When they're done, they merge their branch back in. If two people changed the same part, Git highlights the conflict clearly and asks a human to resolve it. Nothing is lost silently.

In a CA firm context:

• The model itself is one project
• Each engagement team member works on their own branch
• Merging brings all work together without overwriting anything
• Every change is signed with the name of the person who made it — full accountability

Scenario: You Don't Know What Changed

Six months after a project goes live, you get a client complaint. Something that used to work — a report calculation — is now giving wrong numbers.

You look at the code. You have no idea what changed between the working version and now. Multiple people have worked on it. There's no changelog, no record.

Without Git, you're investigating a crime scene with no evidence.

With Git, you run one command and see every single change made to the codebase in the last six months — what changed, when, and who changed it. You can compare any two points in time to see the exact difference. You can pinpoint the specific commit where the calculation broke. You revert that change, and it works again.

Every professional codebase uses Git. GitHub, GitLab, and Bitbucket are all services built on top of Git. You will never work on a serious software project that doesn't use it.

---

The Mental Shift

Here is the most important thing to understand before you install these tools:

You are not backing up files. You are taking intentional snapshots.

The difference matters. Backups are defensive — you make them in case something goes wrong. Snapshots are intentional — you make them to mark a meaningful moment: "this feature is complete," "this is the version I showed the client," "this is the state before I tried something experimental."

Git is a time machine for your work. Every commit is a moment you can return to, compare against, or build from. The more meaningful your commit messages, the more useful your history becomes.

When you learn to think in snapshots, version control stops feeling like overhead and starts feeling like superpower.

---

Summary

Now install them.