Hey Junior Engineers! Few questions create more panic than: "How long will this take?"
If you've ever blurted out a number and immediately regretted it, you're not alone. The goal of estimation isn't to predict the future perfectly. It's to help the team make decisions with the information you have right now.
Core Concept: Good estimates are communication, not prophecy
Junior developers often assume an estimate is a single number you must be confident about. In practice, a strong estimate is a short explanation that includes:
What you think the work includes
What you're assuming is true
What could make it take longer (risks)
A range, not a point
Here's a simple method you can use even when you're new to the codebase.
The 4-box estimation method (works in minutes)
When someone asks for an ETA, quickly write four boxes (literally on paper if you want):
1) Steps (the work breakdown)
List the smallest steps you can name without opening a dozen files:
Find where the behavior lives
Add validation / logic change
Update tests
Update UI / API contract (if needed)
Run locally and verify
If you can't list steps, that's your signal you need a short investigation.
2) Assumptions (what must be true for this to be "small")
Examples:
The data is already available in the API response
There's an existing test pattern to copy
No migration is needed
No new permissions / auth changes
Assumptions are how you stay honest without sounding unsure.
3) Risks (what could blow it up)
Examples:
The logic is duplicated in multiple services
There's a legacy path still used by some users
The system has strict performance constraints
The test suite is slow/flaky
Naming risks builds trust. It shows you're thinking like an engineer.
4) Range (with confidence)
Give a range tied to the breakdown:
"If assumptions hold, I think it's half a day to one day."
"If we discover a migration or a second code path, it's more like 2–3 days."
This is the professional answer. It's specific and realistic.
The most useful phrase you can learn
If you're put on the spot, try this script:
"I can give a better estimate if I confirm two things: where this is implemented and whether there's already a test pattern. Give me 60 minutes to investigate, then I'll come back with a range and the risks."
That's not dodging. That's doing estimation correctly.
Career Growth Tip: Ask for "spikes," not permission to be uncertain
A "spike" is a short, time-boxed investigation (often 30–90 minutes) with a clear output:
Where the change should go (file/function)
What the smallest working change looks like
What could complicate it
A realistic range estimate
If you do this consistently, you'll build a reputation for being reliable — even before you're fast.
Resource Spotlight
Atlassian: Agile estimation — A clear overview of why teams use ranges/points and how to think about uncertainty
Mountain Goat: Planning Poker — Simple technique for discussing effort without pretending hours are precise
Shape Up (Basecamp) — Great mental model: shape the work first, then decide an "appetite" (time budget)
Junior Dev Q&A
Q: "What if I give a range and my manager insists on one number?"
A: Give the number and keep the range. For example: "If I must pick one, I'd say one day, but my actual estimate is 0.5–1 day assuming no migration. If we find a second code path, it becomes 2–3 days." You're meeting the request while still communicating reality. Over time, people learn your estimates are trustworthy because you explain the assumptions.
Next Steps
On your next ticket, try answering with: breakdown → assumptions → risks → range. It takes 30 seconds longer and saves days of confusion later.
Reply with a ticket you're estimating right now (just the summary, no private details). I'll help you break it into steps and pick a reasonable range.
