What I'd Do Differently in My First Week at a New Engineering Job (After Doing It 4 Times)

I've started at 4 different companies. Each time, I did the first week slightly better than the last. Here's the playbook I wish I'd had from the start. Day 1: Don't Try to Contribute Your instinct is to prove yourself immediately. "I'll fix a bug on day one!" Don't. Day 1 priorities: Get your dev environment working. Follow the README. When it doesn't work (it won't), document what you had to fix. That documentation is your first contribution. Meet your team. Not in standup — 1:1. "Hey, I'm new. What do you work on? What should I know about the codebase?" 10 minutes each. Read, don't code. Open the main entry point. Trace one request from API to database. Don't understand it all — just get a map of the territory. Day 2-3: The Codebase Tour Don't read everything. Read strategically: # Find the most-edited files (these are where the action is) git log --pretty = format: --name-only | sort | uniq -c | sort -rg | head -20 # Find the biggest files (these usually need attention) find src -n