(You have 28 days or so left, which is the original schedule for BCC plus twenty days.)

One thing you mention though resonates. You mention perfection. What is it they say? Perfect is the enemy of the good? I really dislike the work of the dilettante or amateur, my ideals are set pretty high and I see myself failing to meet my own exacting standards and this cripples me productively. Also I am a very indecisive person, plagued with doubt. This is great in that I make up my own mind about a lot of things and I don't fall prey to herd-think but it again is a bit of a productivity killer as I flit from technology to technology and methodology to methodology. For instance I've gone from DOS/Windows to Linux fanboy to Mac owner and from C and C++ to the LAMP stack to Ruby on Rails and from nothing to SVN to Git. It's exciting but tiring and their isn't a project out there that I can call my own and there's a directory full of half-baked ideas and scraps of code in ~/Code

It's surprising how often the extra bits you were worried about turn out to not actually occur, once you've learnt more from the initial version, you've understood it better and therefore designed a better approach.

The first version is to understand the problem. The next version (a rewrite) is to understand the solution. Call them "exploratory drafts" if you like.

http://www.joelonsoftware.com/items/2009/09/23.html

This question comes up in different forms time and time again and the answers are almost always the same: Just do it. The only thing stopping you doing it is you so stop procrastinating and get on with it or just admit you're actually not that bothered / committed / whatever.

Also, smarts don't matter. You can be the smartest person in the world, but until you do it. It doesn't matter, because you're just like the kid who hasn't read it all. Stop being a theorist and start being the guy in the arena[1].

[1] http://www.theodore-roosevelt.com/trsorbonnespeech.html

Love the idea of sharing and aiming for this target with others, bringing in accountability. Let me know how I can get in touch.

But underlying it all... Pick up the instrument every day. I think Paul Graham made a similar point about startups failing: That success was built on the foundation of not dying, of not stopping. It's far better to have an organized plan, to use Pivotal Tracker, to have a clearly articulated question you are trying to answer...

But if you do something every day, at least you won't come to a complete halt. So do something, no matter how small, every day.

I haven't figured out how to translate that to writing code or building a product. What would it be: Write a for-loop everyday on some code kata type stuff? Write down a business idea once a day?

You sound like you have a procrastination and/or executive function problem. I highly recommend reading a book called Procrastination [1]. The first step in changing your behavior is understanding why your behavior is the way it is. This is not a self-helpy book; it is written by two clinical psychologists relying on their lab work, patient work, and a wide breadth of historical research on the subject.

From the product page: "Based on their workshops and counseling experience, psychologists Jane B. Burka and Lenora M. Yuen offer a probing, sensitive, and at times humorous look at a problem that affects everyone: students and scientists, secretaries and executives, homemakers and salespeople. Procrastination identifies the reasons we put off tasks—fears of failure, success, control, separation, and attachment—and their roots in our childhood and adult experiences. The authors offer a practical, tested program to overcome procrastination by achieving set goals, managing time, enlisting support, and handling stress. Burka and Yuen even provide tips on living and working with the procrastinators you may know. Wise, effective, and easy to use, this new edition shows why for 25 years Procrastination has been an immediate must-have for anyone who puts things off until tomorrow."

[1] http://www.amazon.com/Procrastination-Why-You-What-About/dp/...

Yeah that looks really great. I've bookmarked it. I'll check it out soon. Maybe tomorrow ...

If you're stuck tinkering it might be best to get a real job for a year or two so you can learn to finish. Then when you start a startup you won't have to learn that particular lesson the hard way.

[Edit: reduce ambiguity]

I have similar problems to the OP, and don't have much of a portfolio. What I do have is boring stuff from my day job (the small amount I can share).

I desperately want to start my own venture or work for a small, early stage startup. And after seeing the HeyZap job ads yesterday, I got inspired. I planned out a small web app project for this weekend. I will have something launched by Monday morning, or else (I'm not sure what the `else` is, but it'll be bad).

EDIT: I do too! We can all use a reminder like this at some point or another....

Then, invariably, some of the details create unexpected problems, and I feel like I'm stuck on some tangential issue, far from the original concept.

What works for me is to focus on one small, specific aspect of your code: it could be a function or feature, but forget about everything else and get it done.

Do the same same for the next logical piece, and before long, you've gotten out of the rut.

Good luck.

I get stumped on issues that crop up along the way, can't figure them out, don't no how to ask for help. I think that my projects are too special to reveal details about even though I eventually would release the code for every single one of them. I get disheartened far too easily, put the task down saying that I'll come back to it and then six months goes by and I've forgotten the details and it takes me ages to get back up to speed.

2. Google the question exactly as is (surprisingly often this works)

3. Ask your question at http://stackoverflow.com (actually, open an account right now, so it's ready for when you need it).

Sometimes when I get really overpowered by one of these problems I tend to throw that out the window and it adds to my frustration in the end.

It's hard to tell yourself you didn't accomplish anything, when over the course of the evening you've got a couple dozen commits to show for it. Also it reduces any trepidation you have about getting in there and making a change, because you can easily roll back to where you were 5 or 10 minutes ago.

We're so much alike, it's scary. I, too, studied philosophy and math. I, too, am currently pursuing grad studies in the humanities (in my case, a philosophy PhD program). I, too, am a mostly self-taught programmer. And I, too, suffer from being unable to finish programming projects.

(I say this because I don't have a whole lot of advice to offer, but I am glad you asked the question, and I will eagerly follow the answers that others post. I wonder how many others like us there are here on HN?)

In addition to what others have said about setting arbitrary deadlines for yourself, here are a few ideas:

1) Get a job that has involves doing some programming. It doesn't have to be at a startup. Since you are in academia, a good place to look would be in labs. (I used to work in a psych lab, myself -- psychologists seem more willing to hire people with philosophy degrees.) I don't know what your research is on, but if there's a way you could connect it with empirical studies, there are probably many labs that would give you a chance to work on it in exchange for working in the lab. And labs always need better programmers. (My guess is that, if you have any sense of code aesthetics, you will be shocked and horrified by the code you find in any working lab. The effort involved in debugging it will be motivation enough to write your own, improved version.)

2) Become reliant on one or a few pieces of Free software. (For me, these are Emacs and Org Mode.) If they are totally indispensable to how you work, you'll notice problems more frequently, and you'll be motivated to fix those problems -- all the way to the end. Lots of people say, "if you want to learn to code, work on an open source project," but for me, that's hard advice to follow in the abstract. It's much easier to follow through when I know the fix will actually help me solve a problem.

Wow. A clone of me floating in cyberspace. You know I used to get funny looks from my philosophy classmates when I answered their question, "so what's your other subject?" (you take two subjects at degree level where I'm from). Nearly everybody combines philosophy and literature or philosophy and sociology or philosophy psychology, you get the idea. But math? What has philosophy go to do with math? I dunno, ask Bertrand Russel. Ask Frege. Ask Descartes. Ask Leibniz. :) And then I'd tell them that I used to work in IT as a software tester and developer and they'd look at me as if I had two heads. In some parts of the world this is considered a lot stranger than other parts. In Spain (where I've had the good fortune to have lived) people think you are _really strange_ if you study one discipline and work at something else. You get less funny looks in northern Europe.

I wonder what your PhD program is? I'm pursuing a Master (in Digital Culture as I mentioned elsewhere here) at the moment. For my thesis I'm combining my love of IT and math and philosophy by researching open source (free software I mean) mathematical tools. Like Richard Stallman I see free software as an ethical issue, which is how I rope philosophy into it :) For my Bachelor's degree I wrote a paper on the philosophy of the infinitesimal calculus and intuitionism! So I always manage to draw together the various intellectual pieces that make up the puzzle of ... whatever the puzzle is. Right now what gets me very excited is intuitionistic type theory and the Curry-Howard correspondence because again this area of logic/epistemology can be looked at through comp-sci glasses, philosophical glasses and mathematical glasses.

I realize all this is totally unrelated to my original question - apologies to all for that but it's not everyday one meets one's clone in cyberspace.

Well, I haven't got a specific focus or dissertation topic yet. (Not sure how it works in Europe, but here in the U.S., a Ph.D. typically involves doing coursework first, which is where I'm at.) But I will probably do something in philosophy of language and/or philosophical logic.

Like Richard Stallman I see free software as an ethical issue, which is how I rope philosophy into it

Me too. So far, I haven't had a whole lot of luck convincing other philosophers that there is an ethical issue to be examined, though. Mostly, they see me as getting inexplicably cranky due to my esoteric interests...

For my Bachelor's degree I wrote a paper on the philosophy of the infinitesimal calculus and intuitionism! ... Right now what gets me very excited is intuitionistic type theory and the Curry-Howard correspondence

Sounds fascinating. I have been thinking about intuitionism a bit lately too. I'm on the fence: classical logic clearly proves too much; but doesn't intuitionism prove too little? :)

I think (but am not 100% sure) that by the time your PhD comes around you have all your coursework out of the way and only attend department seminars for PhD candidates, post-docs, professors and the like.

I'll send my research into the matter as it goes forward where I take a proper look at the ethical nature of free software. It's not just some philosophers and programmers and business managers who don't see it as an ethical issue. But this is the case for a lot of social conventions that aren't widespread, like vegetarianism.

"classical logic clearly proves too much; but doesn't intuitionism prove too little?"

I've never seen the difference formulated like this. But I see what you mean. Intuitionism restricts your proofs (in mathematics anyhow) to constructive proofs so, for instance, proof by contradiction is generally not permissible. But my feeling is that classical proofs don't tell you very much. For finite models they both work, where potential infinities (or stuff with recursive properties) are involved I feel that intuitionism stops you coming to needlessly silly conclusions. Sorry if this is all a bit vague. I'd have to show you what I mean by addressing it to a particular area.

My advice: plan more. Don't just jump in. I know "ship" sounds like you should just jump in. But it doesn't. It means plan, execute, and ship.

Planning means thinking about what the smallest, simplest, easiest path from where you are now to shipment is. Execute means doing it according to plan. Shipping just means put it out there whether you like it or not.

It's so easy to tinker and get lost in a project, especially if you like it. That always gets me. But when I plan it, I have focus. And I usually see that it's not that much work to just pull it all together.

Sure, lots of features get left out, but I'll get to them when I have time. But at least I ship something in the meantime.

To toot my own horn a little: http://www.lispcast.com/software-engineering/how-to-write-so...

Given your background, I'd scratch all these "big picture" or "overly ambitious" ideas and return to a domain you're more confident in, pick something (axiom, rule, theorem, etc.) specific, and see if you can express or simulate an example of the "thing" in action.

For me the real problem is that when I am done with a task and don't know what to work on next, I tend to lose steam. If you have enough work lined up for a week, you will probably keep going. If you stop to think about what to do next after every small task, you will have a tough time keeping up the momentum.

http://wingolog.org/archives/2008/07/10/how-to-choose-betwee...

-- Charlie Parker