Job adverts describe responsibilities. They almost never describe the shape of a day, which is the thing you actually live in.
This lesson is the shape: what a developer's Tuesday looks like, how the same day differs for QA and product roles, and what a two-week sprint feels like from the inside.
Learning Objectives
After this lesson, you will be able to:
Describe a realistic working day for a developer, and how it differs for QA, business analyst and delivery roles
Follow the rhythm of a two-week sprint from planning through to retrospective
Explain why focus time is protected, and what fragmenting it costs
Recognise the unwritten communication rules that nobody states on your first day
Managers live the opposite life, in back-to-back calls, because their work is the coordination. This is a common source of friction between the two, and understanding that both patterns are correct for their respective jobs removes most of it.
The skill worth building early is protecting deep work while staying responsive enough that nobody is blocked waiting for you. Those pull against each other, and finding your own balance takes a while.
A representative day on a product team running two-week sprints.
Time
What is happening
9:00 – 9:30
Triage: messages, review requests, and whether anything broke overnight
9:30 – 9:45
Stand-up. What you did, what you are doing, what is blocking you
9:45 – 12:30
First focus block. The sprint story you are actually building
12:30 – 13:30
Lunch
13:30 – 14:30
Reviewing teammates' code, and responding to comments on your own
14:30 – 15:00
Backlog refinement or a design discussion, a couple of times a week
15:00 – 17:00
Second focus block. Fixing defects, writing tests, pairing on something tricky
17:00 – 17:30
Update tickets, note where to resume tomorrow, final message sweep
Layered on top: sprint ceremonies every fortnight, a weekly one-to-one with your manager, the occasional production incident that displaces everything else, interviews if the team is hiring, and in some teams an on-call rotation every month or two.
Two things typically surprise people. The first is that only around five hours of an eight-hour day is hands-on building, and that is a good day rather than a bad one. The second is that reviewing other people's work is a scheduled, expected part of the job.
A QA engineer starts at stand-up, then works through the stories that moved into testing, logging defects with evidence, verifying yesterday's fixes, and extending the automated test suite. In release weeks the regression run dominates.
A business analyst, or a product owner, spends far more of the day in conversation: answering the team's questions about what a requirement means, talking to stakeholders, writing and refining upcoming stories, and checking finished work against its acceptance criteria.
A delivery manager lives in status: unblocking dependencies, updating the risk log, preparing the client report, watching the budget, and handling escalations.
A support engineer works a queue rather than a sprint. Tickets arrive with priorities attached, and the day is shaped by response-time commitments rather than by a plan made two weeks ago.
What Do You Think?
A developer's calendar shows six 30-minute meetings spread across the day, with 45-to-60-minute gaps between them. Total meeting time is three hours out of eight. How much productive building time is left?
Most teams run one or two week cycles. On a two-week sprint the shape is fairly consistent.
Two weeks, start to finish
🗓️🗓️
PlanningDay 1: pick the work, set the goal
1
⌨️⌨️
BuildDays 2-4: heads-down, first PRs merge
2
🔎🔎
RefineMid-sprint: shape the next sprint's stories
3
🧪🧪
TestDays 5-8: QA picks up finished stories
4
🩹🩹
StabiliseDays 9-10: fix defects, stop starting new work
5
📽️📽️
ReviewDemo what is genuinely done
6
💬💬
RetroWhat to change next sprint
7
Two moments are worth knowing about in advance.
The first is that raising a problem on day three is routine and raising the same problem on day nine is a crisis. The work has not changed; the room to react has. New joiners consistently wait too long, usually out of a wish to solve it themselves first.
The second is that the retrospective is the one meeting where changing how the team works is explicitly on the agenda. It is frequently under-used, and a new person's observations are genuinely valuable there precisely because everything is still visible to you.
Nobody explains these, and they are what people quietly form opinions on.
Decisions made in a call do not exist until they are written down. If four people agree something on a video call and nobody posts it, the decision will be made again in a fortnight.
Update your ticket before you are asked. The status board is how everyone else sees whether the team is on track, and a board that is out of date makes the whole team look worse than it is.
Say you are blocked early and loudly. "I have been stuck on this since yesterday" said today is a normal conversation. Said on Friday, it is a problem someone now has to escalate.
Answer review requests promptly. A pull request waiting for review is a colleague who cannot move on. Reviewing quickly, even to say "I will look properly this afternoon", is one of the cheapest ways to be valued.
Ask questions in a channel rather than a direct message where the answer might help someone else. Direct messages are private by default, which means the answer is lost by default.
The shape below is what a team with a working onboarding process tends to expect. Check it against your own situation rather than assuming it applies, because two things commonly change the timeline and neither is about you. If you joined a services firm through campus hiring you may spend the first weeks in a training programme and then wait for allocation, so the ninety days start when you join the project rather than the company. And in regulated settings, background checks and client access approvals can take a month or more before you can see the real codebase at all.
In the first month you are learning: the codebase, the domain, the people, the tools. Shipping something small and real is the goal, not shipping something impressive. Many teams deliberately give new joiners a tiny first ticket so the whole path from branch to production gets walked once while the stakes are low.
In the second month you should be taking normal tickets and needing less help on each one. This is usually when the domain starts making sense, which is the part that takes longer than the technology.
By the third month you are expected to be contributing at roughly the level the role implies, and to be the one answering some questions rather than only asking them.
If that feels fast, it is worth knowing that almost everyone finds the first month disorienting and almost nobody says so at the time.
Quick Check1 / 3
You are blocked on day three of a two-week sprint and think you can probably work it out yourself. What is the best move?
Roughly five hours of hands-on building in an eight-hour day is normal, not a failure.
Scattered meetings cost far more than their duration, because short gaps cannot hold deep work.
The sprint has a shape: plan, build, test, stabilise, demo, reflect. Problems raised early are routine; the same problem raised late is a crisis.
Reviewing other people's work is part of the job, and responding promptly is one of the cheapest ways to be useful.
A decision that is not written down will be made again.
Next: Engineering Practices — the machinery that turns a ticket into running software, from code review through the environment ladder to what happens when production breaks.