--- title: "Ask Better Questions: The Skill That Saves Your First Month" author: "Harry" published: 2026-10-31T04:49:27.644Z updated: 2026-10-31T05:08:07.772Z category: "Career & Teams" tags: [] canonical: "https://fxblog.dev/posts/how-to-ask-good-questions-at-work" --- # Ask Better Questions: The Skill That Saves Your First Month ## Key takeaways - Staying stuck in silence for days costs more than asking; a time box of 15 to 30 minutes tells you when to stop and ask. - A good question says what you tried, what you saw and what you need, with the exact error message. - Asking in the team channel instead of a direct message lets anyone answer and leaves the answer for the next person. - Saying "hello" and waiting before asking wastes a round trip; put the question in the first message. - Writing the answer into the docs turns your question into something the whole team keeps. > **TL;DR** Staying stuck in silence costs you days on a problem a colleague could answer in two minutes, and your lead finds out from a ticket that stopped moving. How to ask good questions at work: try for a set time, then ask once, in the team channel, with what you tried, what you saw and what you need. Then write the answer down. > > **Do this:** Next time you are stuck, set a timer; when it rings, post what you tried, what you saw and what you need in the team channel. Part 1 ended with Pip's plan agreed and a build error she hadn't told anyone about. Day 12, 19:40. The office is empty and the same red line is still in her terminal. _Everyone looks busy. I'll try one more thing._ She has been trying one more thing since Tuesday. **Dev Voyage: Calm Sea, in five parts:** 1. **Your First 90 Days: How to Join a Crew Without Sinking** 2. **Ask Better Questions: The Skill That Saves Your First Month** (you are here) 3. **Make Friends on the Ship: Working Happily With Colleagues** 4. **When You Break Something: Owning a Mistake Without Losing Trust** 5. **Pass Probation on Purpose** ## Two days against two minutes Pip's reason for staying quiet felt kind. Everyone was busy, and a question interrupts them. But Brock, the senior engineer, would have needed two minutes. Pip spent two days, the discount ticket slipped, and Kit only noticed because it sat in "in progress" all week. "Bother us," Kit told her. "A ship where nobody shouts 'rock!' hits the rock." > **Warning** > > Silence doesn't save your colleagues any time. It moves the cost to later, when the ticket is late and someone has to ask you why. ## Set a timer first Before you ask, try on your own for a fixed time: read the docs, search the error, check the logs, try the obvious fix. Fifteen to thirty minutes on a small problem is a common rule of thumb, not a law. Agree the number with your lead, since a problem that blocks others deserves a shorter one. The timer cuts both ways. It stops you asking what one search would answer, and it stops two days disappearing into something a colleague knows by heart. ![Before asking: search and try for a time box; if still stuck, write tried, saw and need with the exact error, ask in the team channel, then write the answer down](https://fxblog.dev/media/01a1904a-568d-72bb-8b12-24082420bfe3/1600) _The whole loop: try, ask well, ask in public, write it down_ > **Tip** > > Use a real timer. "One more thing" is how twenty minutes becomes an afternoon. ## Tried, saw, need When Pip finally asked, she asked like this: ```text Um, the build doesn't work? ``` Brock's reply was four words: "What did you try?" Another hour gone. Then Bun, the crew's tester and cook, showed her a better shape: ```text Tried: npm install twice, on a clean clone of checkout-service. Saw: it fails on the sharp package: "sharp: Installation error: Expected Node ^18.17 || >=20.3" I'm on Node 16.20. Need: which Node version the project uses, and where that's written down. ``` Brock answered in one line: "Node 20. It's in `.nvmrc`." The format answers the helper's first questions before they ask them. Julia Evans gives the same advice in _How to ask good questions_: say what you already know, and ask a question whose answer is a fact. Often, typing out what you saw shows you the answer. That version number was sitting in the error the whole time. ## Ask where the next person can see it Ask in the team channel, not a direct message. Anyone who knows can answer, and the answer stays there for whoever hits the same error next month. Put the question in your first message, too. "Hi Brock" and then waiting costs a round trip; the short pages _no hello_ and _Don't ask to ask_ exist to make exactly that point. The last step is the one people skip. Pip added two lines to the README that afternoon: ```markdown 1. Use the Node version in `.nvmrc` (currently 20): `nvm use` 2. Run `npm install`. If `sharp` fails, check `node -v` first. ``` Nobody joining the Red Fox will lose a day to that error again. ## Try it Next time you're stuck: 1. Set a timer for the time box your lead agreed. 2. When it rings, write tried, saw and need, with the exact error pasted in. 3. Post it in the team channel, question in the first message. 4. Once it's solved, put the answer in the README or the thread. Pip is unstuck and the discount ticket is moving. But Brock's reply was one line long: no "hi", no smiley, nothing. Pip reads it three times and wonders if he is annoyed with her, and whether the crew likes her at all. Part 3, **Make Friends on the Ship: Working Happily With Colleagues**, is what Bun tells her about Brock over lunch. ## Read this with your AI ```text Read the post "Ask Better Questions: The Skill That Saves Your First Month". 1. I'll paste a question I want to ask my team. Rewrite it as tried, saw, need. 2. Tell me what I should have tried before asking it. 3. Suggest where in our docs the answer should go once I have it. ``` > **Success** > > You know when to ask, and how to ask so people can answer in one line. Next: **Make Friends on the Ship: Working Happily With Colleagues**. ## FAQ ### How long should I try before asking for help? A common rule is 15 to 30 minutes of real effort on a small problem: reading the docs, searching, checking logs. Agree the number with your lead; some teams prefer you ask sooner on anything that blocks others. ### Is it bad to ask too many questions as a new developer? No, if each question shows what you tried. Repeating the same question is the problem, which is why writing the answer down matters as much as asking.