I'd like to know how fast you can go from a startup/side-project idea to its first line of code?
And what language, IDE, framework, tools, software, OS etc. you are using to do so?
Would be great if some of you could describe their workflow.
Thanks!
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.
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.
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.
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
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.
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.
rails new myidea
cd myidea
rm public/index.html
git init
git add .
git commit -m"Initial Commit"
vim config/routes.rb