답글 플레이북 · Coding
What developers post on X, the reply angles that get a dev to answer, six sample post and reply pairs, and the mistakes that get you ignored.
Developer X is mostly working engineers posting what happened today: a bug that ate an afternoon, a library they switched to, a take on code review, a screenshot of a terminal. Indie hackers building in public and open source maintainers are in the mix too, and most of them read their replies.
Replies work here because developers respect specifics. A reply that names the flag, the version or the edge case that bit you reads like a peer talking, and peers get answered. Vague praise and generic advice get skipped. The bar is high, but one precise line clears it.
01
"Six hours on this. It was a timezone." The author wants recognition for the pain and a laugh at the punchline. A reply with a matching scar does well.
02
"X is overrated", "we moved from A to B". Strong opinions invite a detail from your own migration, good or bad.
03
Code review, interviews, estimates, on-call. Here experience counts for more than technical depth, and juniors read the replies closely.
04
A side project, a benchmark, a snippet, a demo GIF. The author wants proof that someone actually opened it.
01
If the post says caching fixed it, ask what invalidates the cache. One precise case shows you read the post closely and know where these things break.
02
One sentence about the time it happened to you, with the detail that made it painful: the version number or the env var nobody documented.
03
Every switch costs something. Most replies ask what got better, so ask about build time, bundle size, hiring or the one feature they lost. Authors enjoy answering it.
04
When someone posts a big solution and a one-line alternative exists, ask whether they tried it. A question lets them explain without being corrected in public.
05
The commit message, the variable name, the 3am timestamp in the screenshot. Jokes about the specific thing land. Jokes about developers in general do not.
이 페이지를 위해 쓴 예시 게시물이에요. 실제 계정이 아닙니다.
게시
spent 4 hours debugging why our cron job ran twice on sunday morning. it was daylight saving time. it's always daylight saving time.
답글
the spring version is worse: it runs zero times and nobody notices until the monthly report is missing a day
게시
Hot take: most teams don't need microservices. A well-structured monolith will carry you further than you think.
답글
agree. what forced the split for us was two teams wanting to deploy the same binary on different schedules, long before any scaling problem. did you hit that one?
게시
Swapped our test runner this week. CI went from 11 minutes to 4. Should have done it a year ago.
답글
how much of the 7 minutes was the new runner and how much was finally deleting the snapshot tests nobody updated? asking because ours was mostly the second
게시
Code review tip: if you're leaving more than 10 comments on one PR, the PR was too big to review. Ask for a split before you start.
답글
we added a soft limit in CI at 400 changed lines. it only posts a comment, never blocks. PRs got smaller within a month and nobody had to argue about it
게시
Built a tiny CLI that renames my screenshots by the text in them. Weekend project, about 200 lines. Link in the replies.
답글
what does it do with a screenshot of a code editor? I'd end up with 40 files named after an import statement
게시
Junior devs: when you get a stack trace, scroll until you find the first line that points at a file you wrote. That's usually where to start.
답글
and if no line points at your code at all, that's an answer too: you're passing something bad into a library. took me embarrassingly long to learn that