
About this episode
This story was originally published on HackerNoon at: https://hackernoon.com/running-out-of-ideas-we-got-chu.
You’re not out of ideas; you’re discarding them too early. How tech writers find endless material and why unfinished work makes the best writing.
Check more stories related to writing at: https://hackernoon.com/c/writing.
You can also check exclusive content about #writing, #blogging, #tech-blogging, #build-in-public, #content-creation, #writing-tips, #writing-for-developers, #hackernoon-top-story, and more.
This story was written by: @editingprotocol. Learn more about this writer by checking @editingprotocol's about page,
and for more stories, please visit hackernoon.com.
You’re not out of ideas; you’re discarding them too early. How tech writers find endless material and why unfinished work makes the best writing.
Get every episode summarized
Each time Writing Tech Brief By HackerNoon publishes, we email you a written briefing from the transcript — the topics, who appeared, and any specific claims, with the ad reads skipped.
Email me new episodesFree for 3 shows. No card needed.
Hosts & guests
Transcript ready
72 searchable segments. Every word is indexed and playable.
Full transcript
Writing Tech Brief By HackerNoon — Running Out of Ideas? We Got Chu.. Machine-transcribed; use the interactive transcript above to jump the player to any line.
This audio is presented by Hacker Noon, where anyone can learn anything about any technology. Running out of ideas? We got chew, by editing protocol. Let me tell you one thing right off the bat. You are not out of ideas. Maybe you're too busy rejecting them before even giving them a proper chance. Don't do that to yourself. As simple as it might sound, what I just said is a real problem for a lot of writers. Idea drought is normal, and it's easier to get out of that rut than you think, because no, your head is not empty. Let us elaborate. It might be a perception problem. Try this experiment. Go ask a developer what they could write about and see what they tell you. Normally, it's a shrug, because it is like that. But try and ask the same person what they've been working on, say, last week, and you'll get a full 30 minute TED talk. You see, everything they mentioned, each one of them is publishable. Why? Because the difficulty one experienced is itself evidence that there's a need for explanation. If the answer is easy to find and well documented,
they wouldn't have lost so much time looking into it. The frustration in solving a problem is concrete proof of gaps in public record. And what is a gap in public record? An article idea? What stops these ideas from being written is the assumption that an article, once written, must be finished, impressive, and unique to be able to exist. And when you look closely, those three criteria have nothing to do with whether or not the published piece would be useful to somebody. Your ideas are being measured by a standard you placed on yourself, and has never been tested in the real world. Therefore, the first tip is not, unlike people might guess, generating more ideas. The first tip of ideation in writing is to catch ideas that might have gone past your head. Keep a journal first. This one is simple. Keep a note. To be more specific, a running note somewhere you will open and revisit regularly. It can be as simple as adding one single line per entry without editing. So what are some things worth opening the journal for? One. Anything that took you more than an hour to work out. Two. Any moment you realize something
is not the way you think it is. Three. Any tools you tried an abandoned? Remember to ask yourself why? Why did you abandon it? Four. Any question someone came up and asked you more than one time. This works only when you separate recording events and judgment. Don't judge right away. Let the ideas sink in, think about it, research more, and try to find relevant information. After two weeks, you'll find that you have too much to write about, and they just keep coming, write about the unfinished thing. This is the part most writers appear to need explicit permission for, so here I just, you do not have to wait until the thing works. The half-built project, the migration you are still in the middle of, the APP that currently crashes on launch. None of these are disqualified as subjects, and there is a specific reason they are frequently better than the finished version would be. Once you know how something turned out, you reconstruct the path backwards as though it had always been logical, and in the process you quietly delete the wrong turns, the assumptions that proved false, and the hours spent on approaches that led nowhere.
Those deletions are exactly the parts that would have helped somebody currently lost in the same place. A completed write-up can tell a reader what eventually worked, which is useful but replaceable. Something written while you are still inside the problem can tell them what the decision actually felt like from within it, which is both much harder to fake and genuinely impossible to reconstruct afterwards, because be the time you have finished, you have honestly forgotten what confused you. Three prompts for when you're genuinely stuck. What did I get wrong? Corrections consistently outperform what their authors expect of them, and the mechanism behind that is straightforward. A reader has no easy way to verify how expert you are, but they can directly observe that you were willing to publish something which made you look worse, and that willingness is costly enough to be believable in a way that confident assertion never is. What did I have to assemble from six open tabs? If the complete answer did not exist in any single place, then you have both located a gap and already done the research required to close it, which means the hard part of the article is finished before you start writing. What would I tell myself three months ago? Anything you know
now and did not know then is, almost by definition, useful to somebody standing where you were standing, and you are unusually well placed to explain it clearly because the memory of not understanding it is still recent enough to work with. Start a new story today, a reason to start this week. If the argument above needs a deadline attached before it becomes real, the hashtag ShepationWritingContest is running right now through HackerNune and RevenueCat, with $2,500 prizes for builders documenting a real app. It is constructed on the same premise as this article. The rule stayed directly that there is no need to wait until your app is finished. Participants are encouraged to publish at several stages rather than saving everything for a single launch post. Build logs, technical deep dives, product pivots, growth experiments, and lessons learned all qualify. Reminder, these prizes are separate from Shepation's official awards, which include over $1 million in official prizes, and growing. Times Square Billboard features, flights to New York for the Shippee's and RevenueCat app growth annual.
Coverage on 9-5 Mac and 9-5 Google, investor exposure through the Shepation Growth Fund, read more about the hashtag ShepationWritingContest here, HTTPS colon slash slash HackerNune. Come, building for Shepation 2026 share your journey on HackerNune and compete for an extra 2,500. Embedable equals true contest closes on September 30, which leaves roughly three weeks enough time to turn something half built into something published, and considerably marathon you need to open a note and write the first line. Want to sharpen the rest of it? Finding the idea is only the first step, and if you want help with everything that follows it, HackerNune's blogging course runs to eight modules built by working writers and editors, including how to find your voice and ideal writing workflow. How to write great articles that people will read, CO plus storytelling, write content that ranks and resonates. Sign up for the HackerNune blogging course today. Until next time, hackers. Thank you for listening to this HackerNune story, read by artificial intelligence. Visit HackerNune.com to read, write, learn and publish.
More episodes
More from Writing Tech Brief By HackerNoon

Meet the Writer: HackerNoon Contributor Swapneswar Sundar Ray, AI Systems Engine...
Writing Tech Brief By HackerNoon

Meet the Writer: Hacker Noon's Contributor Radu Constantin, Software developer
Writing Tech Brief By HackerNoon

Tomorrow, I Will Fly
Writing Tech Brief By HackerNoon

Startup Founder Interview: Building AI That Works Beyond the Demo
Writing Tech Brief By HackerNoon