If you have a new idea you want to succeed, what is your approach? about ama

[developit]

Thanks for the questions! I should preface my answers here with the caveat that I have ADHD, and it plays a major role in my decisions (or avoidance of them).

Ideation: I usually have ideas before becoming super invested in them succeeding. I am really easily sidetracked by ideas, so I have a sort of system where I write out my thoughts in a task on my task list. For larger ideas I will write up a document outlining my rationale and describing the idea at a high level (what would it accomplish, what would it look like), and often throw some untested example code in a Gist as a way to jog my memory later.

Prototyping: Once I've gotten around to an idea - or more realistically, once I've nerdsniped myself into working on it - I start by prototyping. This is intentional, though maybe not for the obvious reason: I prototype quickly because I work best when I have a very short feedback loop. It's also a way that I combat the fact that most of my initial prototyping happens by accident - getting a minimally-viable prototype done as quickly as possible helps avoid spending loads of time on something I usually hadn't planned to spend time on in the first place.

Feedback: I am lucky enough to have a pretty huge network of people who I can get feedback from. From the Preact team (we have a preact slack!) to my co-workers at Google, I'm able to post a question or a short document describing an idea and I'll usually get some feedback and constructive criticism. Another way I sometimes look for feedback on ideas is by tweeting questions or previews that get at the crux of the idea, and gauging responses to get a sense of whether folks understand it as well as how many people seemed interested.

Marketing: Once a project gets to the point where it seems compelling and I'm at least a little invested in seeing it through, I do start to think about marketing. The two main things I do on most projects:

• Ensure the README describes why something is different/good/noteworthy in as concise of language as possible. For multifaceted projects this usually ends up being a list of features, for single-purpose projects this is more about coming up with a one-liner "elevator pitch". The goal isn't to sell folks something they don't want, it's to make sure that anyone who comes across a project can immediately understand what the benefits are.
• Post graphical (and ideally video) explanations of the thing on Twitter. I usually try to do this a little bit leading up to a launch so that things don't seem to be coming out of nowhere, which also helps gauge interest early on. I find that screencast-style videos generate the most "buzz", but a clear annotated "code sample" style graphic designed specifically for Twitter is generally the thing that developers seem to notice, and certainly generates the most feedback. The image approach does tend to draw the most negative feedback, I think because folks respond to the heavily summarized image without looking at the thing it links to.

Interest: I'm not perfect about it, but my goal is usually to release projects as early as I can. I do this because it lets folks kick the tires, and that tends to help surface any fundamental issues or redundancies that would cause a project to be uninteresting. In cases where I'm passionate about something but it doesn't seem like anyone else is, I usually just keep things to myself. After a few years of doing most of my work in public, it can be refreshing to work on something purely for my own needs without worrying about re-usability/overlap/maintenance.

Losing Interest: I've certainly had a bunch of projects end up being things I wasn't interested in pushing forward anymore. Software doesn't always have to grow though, and in at least a few cases I still rely on projects I haven't touched in years. The fact that stuff like this can keep working without maintenance highlights how awesome the web's backwards-compatibility is - projects I've stopped maintaining that are coupled to userland frameworks generally don't fare as well.

Relieving some of the maintenance burden I have is something that has been on my mind for a while. I have something like 300 GitHub repositories, and it would be infeasible to give each of them the attention they require. I'm taking some time off this month and one of the things I'm planning to do is to archive a lot of my old repositories. Maybe I'll be able to get my unread GitHub notifications back down from 1000 again, who knows!