Pushing secrets to GitHub
Why this is dangerous
Once a secret is pushed to GitHub, it's in the git history forever. Bots constantly scan public repos for API keys and will find yours within minutes. You could wake up to a massive cloud bill or compromised accounts.
Your .env file should never be committed. It contains your API keys, database passwords, and secrets. Always add .env to your .gitignore file.
Never hardcode keys like const API_KEY = "sk-...". Even if you delete the line later, it stays in git history. Use environment variables instead.
# Search for secrets in your git history
git log -p | grep -i "api_key\|secret\|password"
# Use a tool like git-secrets or trufflehog
trufflehog git file://./- Immediately revoke/rotate the exposed key in your provider's dashboard
- Don't just delete the file - the secret is still in history
- Use
git filter-branchor BFG Repo Cleaner to rewrite history - Force push to overwrite the remote (coordinate with your team)
Use git-secrets as a pre-commit hook. It automatically blocks commits containing potential secrets. Set it up once and never worry again.
Ignoring terminal errors
Why this is a problem
That wall of red text isn't decoration - it's your computer telling you exactly what went wrong. Ignoring errors leads to hours of confusion debugging the wrong thing.
Terminal colors are meaningful: Red = error, Yellow = warning, Green = success. When you see red, stop and read it.
1. Start from the bottom - The actual error message is usually at the end
2. Find YOUR code - Look for file paths in your project, not library code
3. Note the line number - The stack trace tells you exactly where it broke
4. Read the error type - TypeError, SyntaxError, etc. tell you what kind of problem
Something changed. Check: Did you update dependencies? Did someone else push code? Did an API change? Did your environment variables expire? Use git diff to see what changed.
Copy the exact error message and paste it into your AI assistant. Include the full stack trace. This is the fastest path to a solution.
Not understanding localhost
Why this confuses people
localhost means "this computer only." It's not on the internet. Your friend in another city cannot see your localhost:3000 no matter what URL you send them.
localhost is your computer talking to itself. To share your site, you need to deploy it (Vercel, Netlify, GitHub Pages) or use a tunnel service like ngrok.
localhost:3000 = Your machine only
mysite.vercel.app = Anyone on internet
The number after the colon (like :3000) is the port. Think of it as an apartment number in a building.
localhost:3000 and localhost:8080 are different "apartments" on your computer.
If you see "port already in use," another app is using that port. Either stop it or use a different port.
Use npx ngrok http 3000 to temporarily share your localhost with others. Great for demos and testing webhooks.
Dependency hell
Why this is a nightmare
Your project depends on packages that depend on other packages. When versions conflict, everything breaks. The error messages are cryptic and nothing makes sense.
Package A needs react@17, Package B needs react@18. Now you have a conflict. Check package.json for version mismatches.
This usually means different dependency versions. The package-lock.json file locks exact versions. Always commit it and run npm ci (not npm install) in CI/CD.
# The nuclear option - when nothing else works
rm -rf node_modules package-lock.json
npm install
# Or use npx for a cleaner approach
npx rimraf node_modules
npm installTry this when: weird errors after pulling changes, after switching Node versions, or when updates behave strangely.
Use nvm (Node Version Manager) to switch between Node versions. Different projects may need different versions. Run nvm use in each project.
Not reading error messages
Why this wastes time
Error messages are written by developers to help you fix problems. They literally tell you what's wrong. Reading them carefully can save hours of guessing.
Cannot read property 'x' of undefined = You're accessing .x on something that doesn't exist
Module not found = You need to install something or your import path is wrong
Unexpected token = You have a syntax error (missing bracket, comma, etc.)
Error at line 47 means go to line 47. Your code editor shows line numbers on the left. The bug is at or near that line.
/src/components/Button.js:47 tells you exactly which file. Click on it in your terminal (if supported) to jump there.
Before asking for help, read the error message out loud. Often, saying it makes you realize what it means. "Cannot find module './button'" - oh, the file is named 'Button' with a capital B.
Asking AI vague questions
Why this gets bad answers
AI can only help with what you tell it. "It doesn't work" gives AI nothing to work with. The more context you provide, the better the answer you'll get.
"My code doesn't work, can you fix it?"
"I'm getting 'TypeError: Cannot read property map of undefined' on line 23 of UserList.jsx when I try to render users from my API. Here's my code..."
1. The exact error message - Copy and paste it
2. The relevant code - Not your whole project, just the part that's breaking
3. What you expected - "I expected it to show a list of users"
4. What actually happened - "Instead I get a blank screen and this error"
5. What you've tried - "I checked that the API returns data and it does"
Mention: What framework (React, Vue, Next.js)? What language version (Node 18, Python 3.11)? What OS? Browser console or terminal? These details matter.
Use Claude Code or Cursor to give AI direct access to your codebase. Then it can see the full context automatically. Just say "look at this file" and share the error.
Skipping the docs
Why this causes problems
Documentation exists because the tool creators know you'll have questions. Guessing how something works leads to subtle bugs that are hard to track down later.
Guessing takes 5 minutes and leads to bugs. Reading docs takes 5 minutes and gives you the right answer. Choose wisely.
Random blog posts may be outdated. Start with official documentation. It's maintained by the people who made the tool.
Every repo has a README for a reason. It tells you how to install, configure, and use the project. Read it first.
1. Quick Start / Getting Started - Get it running first
2. API Reference - When you need specific function details
3. Examples / Tutorials - See how pieces fit together
4. Troubleshooting / FAQ - When something goes wrong
Use the search function in docs. Press Ctrl/Cmd + K on most doc sites to search. Looking for "authentication"? Search it instead of scrolling through 50 pages.
Not using version control
Why this is dangerous
Without git, one wrong delete and your work is gone forever. No undo. No recovery. Hours, days, or weeks of work - vanished. Git is your safety net.
This sentence is said thousands of times a day by people who didn't use git. Your laptop can die. Your hard drive can fail. Your cat can walk across the keyboard. Git protects you from all of it.
# Start every project with git
git init
git add .
git commit -m "Initial commit"
# Commit after every working change
git add .
git commit -m "Add user login form"
# Push to GitHub for backup
git push origin mainWant to try something risky? Create a branch. If it works, merge it. If it doesn't, delete the branch. Your main code stays safe.
git checkout -b experiment/new-feature
# Try risky stuff here...
# If it works:
git checkout main && git merge experiment/new-feature
# If it fails:
git checkout main && git branch -D experiment/new-featureUse GitHub Desktop or GitKraken if the command line feels intimidating. Visual git clients show you exactly what's happening. Once you're comfortable, the CLI is faster.
TL;DR - THE SURVIVAL CHECKLIST
1. Add .env to .gitignore before your first commit
2. Read error messages - they tell you what's wrong and where
3. Localhost is local - deploy to share with others
4. When in doubt, delete node_modules and reinstall
5. Give AI context - error messages, code, environment
6. Read the docs - especially the Getting Started guide
7. Commit early and often - git is your undo button