2026-04-05

You grind for six hours on a flaky test your teammate could fix in six minutes. That gap is the tax of ego coding.

Ego coding isn’t arrogance; it’s the quiet impulse to solve everything solo so you look competent. It feels noble. It’s often wasteful.

The quiet costs of ego coding

  • Time: Hours lost on known issues others solved last sprint.
  • Quality: Workarounds and brittle code born from partial context.
  • Burnout: Long solo slogs sap energy and creativity.
  • Team learning: Knowledge stays siloed; bus factor stays high.

A practical rule-of-thumb (20/40/90)

  • 0–20 minutes: Local triage. Read the full error, logs, stack trace, recent diffs.
  • 20–40 minutes: Broaden search. Docs, repo issues, Slack history, minimal repro.
  • 40–90 minutes: If still blocked, ask for help. Sooner if it’s blocking others or a release.

If the path forward is unclear or you’re outside your expertise, ask earlier.

Decision tree: Should I ask now?

  • Is this blocking a release or another person? Ask now.
  • Am I in unfamiliar territory (new service, infra, library)? Ask within 20–40 minutes.
  • Do I suspect ownership outside my team? Ask for a pointer immediately.
  • Have I tried two distinct hypotheses without progress? Ask.
  • Is my estimate-to-solve-alone > 1 hour while a teammate likely knows the answer? Ask.

Pre-ask self-help checklist (do this in <30 minutes)

  • Reproduce minimally (ideally a small script or a failing unit test).
  • Capture exact versions, environment, commit SHA, feature flag state.
  • Read the error fully. Search the codebase and issue tracker for the message.
  • Check recent merges/rollouts and changelogs.
  • Try two different angles (config vs. code, local vs. CI, old vs. new version).
  • Write a 5–10 line summary (rubber-duck). Often you’ll unblock yourself here.

How to ask great questions (templates)

Make it easy to help you. Be specific, show work, and state the help you want.

Slack/Teams example:

Subject: Help with staging 500 on payment webhook after deploy 2026-04-01

Context: Staging only. After deploy 3b2c7e, webhook /v1/payments/callback returns 500.
Expected: 200 from payments-service with "processed": true.
Actual: 500 with stack trace in payments-service (link below).

Repro:
1) Enable flag payments_v2
2) POST payload X (curl link)
3) Observe 500

Tried:
- Rolled back to 2f8d1a: passes
- Tail logs show NullPointer in FraudCheck (line 148)
- Checked config: FRAUD_URL set correctly in staging

Suspect: Recent changes in FraudCheck introduced null on missing score.
Artifacts: logs, diff, dashboard links
Ask: Can someone from payments/fraud confirm expected behavior for missing score? Is default score required? Will pair for 15 mins if you’re free.
Time-box: Release blocks in 2 hours.

GitHub Issue/Discussion template:

Title: Staging 500 on payment webhook after 3b2c7e
Environment: staging | payments-service 1.14.2 | fraud-service 0.9.0
Repro steps: ...
Expected vs actual: ...
What I tried: ...
Suspected owner/code area: FraudCheck.java#L148
Help needed: Clarify expected default for missing fraud score; review NPE path
Impact: Blocks release 2026-04-01
Attachments: logs, metrics, minimal repro test link

Tips:

  • Ask for a specific kind of help ("pointer to owner", "sanity check", "pair 15m").
  • Include time pressure and impact.
  • Offer a minimal repro or failing test; it signals rigor and speeds help.

The help ladder (escalation without noise)

  1. Self-help (checklist above)
  2. Ask a peer who owns the area or has recent commits
  3. Team channel with a clear subject and impact
  4. Office hours / on-call for that domain
  5. Cross-team channel with owner mention
  6. Tech lead/EM for unblocking or re-scoping

Move up the ladder every 30–60 minutes if blocked and impact is rising.

Remote/async tips that 2x your success rate

  • Share a 2–5 minute screen recording showing repro and logs.
  • Push a branch with a failing test or a minimal repro repo.
  • Paste exact error text, versions, and timestamps.
  • Propose a next step (“If no answer by 3pm, I’ll revert X”).

A simple ROI test for asking

  • Personal burn rate per hour: your hourly cost (or just use 1 unit)
  • Opportunity cost: delay to others or to revenue (estimate)
  • Expected solo time left vs. expected time with help

If (solo_time_left − time_to_get_help) > 1 hour, or if your block delays 2+ people, ask now. Even 15 min saved across a team pays back quickly.

Example: You expect 3 hours alone. A teammate likely solves in 20 minutes, and you’ll wait ~20 minutes for them. Delta ≈ 2h 20m saved → ask.

Red flags you’re in the ego trap

  • You’re avoiding posting because you “should know this.”
  • You’ve rewritten something you barely understand to dodge asking.
  • You’re changing the problem to fit what you know.
  • You won’t push a WIP branch because it’s “messy.”

Reframe: Asking is senior behavior. It accelerates delivery and spreads knowledge.

Team and lead playbook (build an ask-friendly culture)

  • Define an “Ask SLA”: first response within 15–30 minutes in core hours.
  • Create #help-<domain> channels with rotating weekly DRI.
  • Add office hours and pairing blocks to calendars.
  • Add “First time we asked for help” to postmortems and celebrate early asks.
  • Track MTTFA (mean time to first ask) in retros; aim to reduce it.
  • Provide a Help Request template in your handbook and issue tracker.
  • Leads model it: publicly ask for reviews and pointers; praise good questions.

Open-source etiquette (when asking outside your org)

  • Read CONTRIBUTING.md and past issues first.
  • Provide a minimal repro repo or failing test.
  • State versions, platform, and expected vs actual behavior.
  • Be patient and kind; maintainers are volunteers with limited cycles.

One-week experiment to break the habit

  • Set a 40-minute “ask timer” for any new block.
  • Log: problem, when you asked, time saved guess.
  • End-of-week retro: total hours saved and any repeated knowledge gaps to document.

Pocket checklist (print or pin)

  • Repro minimal + capture versions/links
  • Two hypotheses tried
  • Summarize in 5–10 lines
  • Ask with context, impact, and a specific request
  • Escalate on a schedule, don’t silently grind
  • Document the answer for the next person

Help Request Canvas (copy/paste)

Context:
Problem statement:
Impact (who/what is blocked, deadlines):
Repro (steps, env, versions):
Expected vs actual:
What I’ve tried (2+ attempts):
Suspected area/owner:
Specific ask (pointer/pair/review/decision):
Artifacts (logs, diffs, repro test, dashboards):
Time-box/next step if no reply:

TL;DR: Optimize for team throughput, not solo heroics. Time-box, ask early with signal, and turn every answer into a shared artifact. That’s senior engineering.