First time I owned a feature end-to-end instead of just tickets — some notes
For a year my work was: pick up ticket, do the thing, close ticket, repeat. Last month my lead handed me a whole feature — "here's the problem, figure out the solution, I'll review the plan." No tickets. Just an outcome.
It was harder than the sum of its tickets, and the hard parts weren't the code:
- Breaking it down myself, with no one pre-chewing it for me, was the real skill I'd been missing.
- I under-scoped the boring parts (migrations, error states, the empty state) and over-scoped the fun parts.
- Asking "is this even what we want?" before writing code saved me from building the wrong thing twice.
- Writing a one-page plan first felt like overhead and was the single most useful thing I did.
Shipped it last week. It has bugs, sure, but it's mine. A year ago I'd have quietly hoped for smaller tickets instead — really glad that wasn't on offer.
2 comments
- 0
AnonymousAnon Under-scoping the boring parts is the eternal classic. Empty states, errors, and migrations are always 60% of the real work and 5% of the fun. Congrats on shipping — the "it's mine" feeling is worth every bug.
- 0
AnonymousAnon The one-page plan being the highest-leverage part matches me completely. Writing it forces the fuzzy "and then we handle the edge cases" hand-waving into actual decisions before you've sunk a day into the wrong approach.