Ask HN: As a programmer do you have ups and downs and periods of intense doubt?

As everyone else has said - the doubt is normal. My advice would be to try and strip the product into parts more & tackle them one by one.

Creating a total product end to end in one go, that's scary. Creating a user model, easy. Creating an authentication level on that model, easy. And so on. Take it one step at a time.

> As a result I have numerous half baked personal projects.

Every decent developer has dozens of half-baked personal projects. Some get finished, some don't. All eventually get abandoned.

They are never a waste.

If you go through your codebase, you will find that you re-use code and techniques that you learned on your next project. This is how we learn.

What you're experiencing is entirely human, and I would venture all developers experience this at given points, unless they are just working through a queue of bugs in a backlog tracker or some such. Now, being a software engineer, I'm not really interested in working harder or just telling myself to get over it. I'd rather use software and a process to hack my own behavior to keep pushing forward. Here is how I've had a little success with this.

For a given product, I have a Trello board that tracks the entire machine I am trying to create. (A business is a machine that accepts money and/or time as inputs and outputs a sufficiently interesting amount of more money: the profit.) I'll have lists like Lead Generation, Conversions, Upsells, and Churns. Every project I want to work on within the product needs to fit into one of those lists; it's an easy way to remind myself to not build or work on things that don't matter.

Within the lists I have cards for initiatives. These are the projects I would assign to an executive if I had a team of VPs. For example, "Launch ZenDesk with help articles."

Within the cards I have checklists of specific milestones or tasks. "Sign up for ZenDesk." "Add CNAME."

When I don't have much energy after a full day's work, I can look at my cards and find something I do have the energy to take care of. When I'm wide awake and excited after a good night's sleep, I can add more tasks or initiatives to the Trello board, but the lists help ensure the initiatives are actually pushing the business forward.

Finally, I'd look for projects within your product that make sense to open source. One, that makes the projects easier to use on future projects; two, you can show them off when trying to get work in the future; and three, it gives you a really nice sense of satisfaction and a milestone you can point to along the way of building your product.

I spent about a year alone building a fairly complex server tool. Some days were great. Many were hard. I'm 40 now, and have enough experience with myself and software that I got it done and enjoyed almost all of it. Here some things that worked for me.

* Kept the initial push of code very simple, and doing something useful from day one. The software needed to always "work" so that I could be adding features, tuning or bug fixing. If it wasn't working, I was UNHAPPY.

* Tried to ship every day

* Which meant I was disciplined about drilling features down into coding efforts of about a day.

* I kept a notes.txt file, and wrote down any ideas and thoughts; features would get drilled down into component steps, and I would work through them one by one.

* I resisted all urges to 'rewrite the whole codebase', this would have kept me from having working code for weeks, an absolute no go.

Overall, I'm happy with what I (and later a friend) built. It took discipline, but the discipline is just there so that I could do mostly the fun stuff -- build something new that people thought couldn't be built.

The worst two weeks for me were a terrible bug-hunting expedition that ended with filing a compiler bug. I was tetchy and annoyed the entire time. For me at least, I like having working code that does something useful. :)