Role Reality: A Day in the Life
Welcome — you're about to begin something genuinely life-changing, and we're going to do it together, one clear step at a time. Before any code, let's understand the job you're aiming for so everything you learn later has a place to live.
A full-stack developer builds both the part of an app you see in the browser (the front end) and the part that runs on a server and stores data (the back end). "Full-stack" just means "comfortable across the whole stack" — the layers from screen to database.
Read these first (curated & annotated)
Open each link, skim 5–10 minutes, and notice the things in the What to look for note.
- [The Odin Project — "How this path works"](https://www.theodinproject.com/paths/full-stack-javascript) — [Workflow] [Career Growth] — A realistic map of what learning (and doing) full-stack involves. What to look for: how much time goes to building vs. reading.
- [r/cscareerquestions — "What does a junior dev actually do all day?"](https://www.reddit.com/r/cscareerquestions/) — [Workflow] [Team Dynamics] — Search that phrase; read several answers. What to look for: how much of the day is meetings, code review, and small bug-fixes vs. writing brand-new features.
- [r/webdev](https://www.reddit.com/r/webdev/) — [Tools Used] [Frustrations] — Sort by Top → This Year. What to look for: which tools keep coming up, and what people complain about (this is gold for empathy and interviews).
- [freeCodeCamp blog — developer stories](https://www.freecodecamp.org/news/) — [Career Growth] [Incident Examples] — Search "career change developer". What to look for: how long real career-switchers took, and what got them hired.
- [Stack Overflow Developer Survey](https://survey.stackoverflow.co/) — [Tools Used] [Career Growth] — What to look for: the most-used languages, frameworks, and tools — your shopping list for what's in demand.
- [GitHub — explore real projects](https://github.com/explore) — [Workflow] [Tools Used] — Open any popular web project and look at its README and folders. What to look for: what a professional repository looks like (you'll build ones like this).
- [The Pragmatic Engineer blog](https://blog.pragmaticengineer.com/) — [Team Dynamics] [Career Growth] — What to look for: how engineering teams actually operate day to day.
A typical week (plain English)
- Monday: Team "stand-up" (a 15-minute call where everyone says what they're working on). Pick up a ticket (a small unit of work) from the team's board.
- Tuesday–Thursday: Write code for your ticket, ask questions, open a pull request (a request to merge your change), respond to code review (teammates suggesting improvements), fix bugs.
- Friday: Wrap up, write notes, maybe a "retro" (a short meeting on what went well/badly). Lots of small wins, not one big dramatic moment.
The most common recurring tasks
- Turning a design or a written request into working screens and features.
- Fixing bugs reported by users or teammates.
- Reading other people's code (you'll do this more than you expect).
- Writing and reviewing pull requests.
- Talking with designers, product managers, and other developers.
The most common frustrations (so they don't surprise you)
- "It works on my machine" but breaks elsewhere — environment differences.
- Vague requirements — half the skill is asking good questions.
- Old code you didn't write ("legacy") that's hard to change.
- Tooling/setup friction. (We dedicate Project 0 to making this painless.)
How the role works with others
You'll interact with designers (who give you the look), product managers (who decide what to build), other developers (who review your work), and sometimes QA/testers and DevOps (who help ship and run it). Communication is a core skill — not a side one.
✅ Do this now
In a notes file, write 5 things that surprised you from the reading. You'll reuse these in your Phase 2 blog and in interviews ("Why software development?").