It’s been a while since I had a side project going, so I’ve been itching do to something creative. But I’ve been in the developer’s equivalent of writer’s block for a while, hung up on a lack of ideas or at least a lack of good ideas.
I think I’ve now replenished the idea supply, thanks to this exercise.
I spent a few hours tonight generating 101 ideas for software projects. Half or more of them will never become anything. A few are absolute garbage. A bunch of them might be good afternoon projects, possibly worth sharing, but aren’t especially inspired.
A few seem actually good, and they’re what the exercise is all about.
If you’re in a creative rut, especially if (like me) you’re fairly young or early in your career, I highly recommend this.
Here’s how I did it:
- Pick a number, let’s say N. I picked N=101 because it’s (in this context) a big number that would be a stretch. I also like that it’s JUST over 100, so your 100th isn’t a complete fluke.
- Open a notes app, spreadsheet, word processor, text file with line counters, dead-tree notepad, etc.
- Start writing your list of N items.
- Fill the list in one sitting exactly, if at all possible. (You can always revisit this!)
- Put it down afterward. I just finished mine and don’t intend to look it over until at least tomorrow. I want to see it with fresh eyes to choose the best prospects.
I suggest these criteria for whether to add an idea to the list:
- Be specific…: An item should be a short but complete description of a project. One sentence or phrase is enough if it tells you everything you need to know.
- … but vague enough: Stay away from describing programming languages, environments, web servers, etc. – those questions can come if you decide a project is worth actually implementing.
- Make the project scope appropriate for team size: I was thinking up individual side projects, so I wanted ideas I could implement on my own using mostly the Internet for external information. A group/team/company project would be different.
- Otherwise reserve judgment: If you must, add a parenthetical statement afterward on the problem (e.g., a few of my ideas raised concerns about copyright, but I added them anyway because as a technical matter they would be doable). You can also bold an idea you feel especially good about in the moment. If possible don’t get any more judgy than that.
- It can be based on something you’ve seen, but modify it and be mindful of law and ethics: Inspiration is inevitable, especially at the idea stage. Be sure to make it your own, though, or it’s not much of an “idea”. Worry about copyright, terms of use, etc., if you ever consider publishing or distributing what you make. For now, add the idea if you think it would work for you given your context and purpose.
Fundamentally, this is about quantity not quality.
This is my first time doing such an exercise in the context of software, so by all means change the rules to whatever works for you. These worked for me, though, so I suspect they may work for others.
A final cautionary note: I worked alone, and I suspect I would have created a totally different list working in a group (i.e. brainstorming). Your mileage may vary there.