4 ms·

Ask HN: How fast can you go from idea to first line of code?

• stray 15y ago
  (defclass idea () ()) ; 6 seconds
• bbhacker 15y ago
  I think the question is not how fast you can go from idea to first line of code but how long until you find out that your ideas is worth a line of code. That is an interesting question in itself and would start a whole discussion how easily you could test the feasibility of an idea without writing a single line of code.
• scottyallen 15y ago
  I don't think it's so much a matter of how fast CAN you go from idea to first line of code, but rather, how fast SHOULD you go from idea to first line of code. Starting writing code for an idea is often as simple as opening your text editor or IDE. So on the order of single to double digit seconds? That doesn't mean that jumping straight into writing code is a good first step. Figuring out what you're building, why you're building it (is there demand?), how it will work from a user perspective, and how you will architect it, are often useful questions to answer before diving in.
• vishnumenon 15y ago
  I usually spend about a day considering my idea's merit, then I get started. I use ruby (I prefer Sinatra to Rails), on OS X, and Chrome as my browser. I use Sublime Text 2 as my text editor.
• rick888 15y ago
  I usually spend time in a research phase. Writing out the main goals/ideas, writing pseudo-code, then actually coding. I find it works much better than the hack it all out approach, but takes a little longer before I actually start coding. Many people don't like this because it takes some of the fun out of it. But, I usually end up with less re-writes and bugs in the end.
• rachelbythebay 15y ago
  That all depends on exactly what popped into my head. Let's say it's a pretty obvious idea that's almost fully formed, like "let's wrap a web form around OpenSSL so the support techs can make certificate requests". That comes together as a couple of blocks in my head. One block is "have a basic FORM as the UI" - basic HTML, no big deal, easily done. The second block is "have something to handle the incoming POST data" - libraries I had already written, so again, no big deal. The third block was "somehow pass it to OpenSSL and get back the data". This is where all of the unknowns lurked. I had to actually play with it to see if it had a reasonable way to be controlled by another program. It turned out that it could be done without too much trouble, and with that known, the third block was considered possible. Finally, the fourth block would be to take the results and render them on the page returned by the POST handler. That's just a bit of HTML and other CGI magic - easy enough. When the idea first comes to me, 1, 2, and 4 are fully-formed in my head, and 3 needs elaboration. A few minutes of poking on 3 convinces me it's possible, and thus with everything seeming reasonable, I start in on it. Total time elapsed from "hey, we need this" to "hey you, try this thing I just wrote" was about 25 minutes. I only know this because it happened with a nicely timestamped chat log, and I worked backwards to figure it out. That's not quite an answer to "how long until first line of code", but it does give you a window: under 30 minutes, if it's a situation like this. As for the tools, back then: C, pico/nano, home-brewed CGI helper libraries, Linux, Apache. These days, it's the same, only with (a specific subset of) C++ in place of C. I can elaborate on which bits if you really care. Use whatever language works for you. Workflow is basically this: open two xterms or similar. Open an editor in the top one, write code. Open bottom one, use it to "make && ./prog". Open other windows as necessary for research or experimentation (like fiddling with the OpenSSL stdin hookup, reading man pages, etc). The whole workspace (fluxbox) is nothing but terminals. Browsers and other stuff go off to another workspace. My chat window stays on another screen/system, and is sometimes hidden when uninterrupted cycles are needed for a short burst. Hope this helps.
  • cotsog 15y ago
    Great answer! Thanks for your insights.
• Andi 15y ago
  The question should be: How good is this first line of code and for how long will it stay?
• ahsanhilal 15y ago
  It really does depend on the idea, but I think a good rule of thumb is to try to have something in the hands of users between 2-3 months. 1. Map put all the ideas for the product on paper 2. Build a basic form of a UI through wireframes (Balsamiq etc.) 3. Analyze the product roadmap and trim down the product features to something that is achievable in 2-3 months. 4. Make two graphical layouts for the UI, one which should be as simple as possible, and one which is pretty to look. The reason is good design takes time and can often hinder the project. That is why a simple graphical layout is good to have while coding so that the basic functionality is there. 5. Start programming towards the specific trimmed down feature set 6. Make it pretty 7. Rinse and repeat
• ianpurton 15y ago
  cd projects rails new myidea cd myidea rm public/index.html git init git add . git commit -m"Initial Commit" vim config/routes.rb
• mootothemax 15y ago
  Too fast. Concentrate on your marketing plan first; it's a crying shame if you let your talent go to waste on a failed project.
  • freehunter 15y ago
    On the other hand, I've had a few projects where I spent a lot of time building up documentation and marketing presentations and by the time I got around to writing the code I realized that the project really had no legs. It's very easy to hype yourself up to create a project and convince yourself of everything it's going to do, but before you do you need to understand if the project will work out. I've had a lot of "wow, I don't know how to implement this" or "this isn't nearly as interesting as I thought" moments. Marketing tends to focus on the best aspects of the project, getting down to coding it makes you understand the challenge you're actually facing.