My work is garbage

Not an untypical predicament you're in. Best advice is to minimize features and release something to someone asap. That takes a lot of discipline to do, but starting simple and iterating has lots of benefits. Just a few: 1. Instant feedback, so you can validate your assumptions about the product. (see: Lean Startup, Eric Ries) 2. It's easier to keep releasing once you've already released. 3. With a simple, limited feature set, your product is easier to understand to your early adopters.

<a href="http://en.wikipedia.org/wiki/Technical_debt" rel="nofollow">http://en.wikipedia.org/wiki/Technical_debt</a><p>Note that the first cause listed (At the time of writing) is business pressure. This happens quite often. Sometimes you have to produce slop code to get anything out the door at all.<p>As an example; this whole demo is a hack of the worst sort:<p><a href="http://www.youtube.com/watch?v=K_y3cbIV-Xg" rel="nofollow">http://www.youtube.com/watch?v=K_y3cbIV-Xg</a><p>There was a series of posts on the Bungie website about the development of halo2 outlining just how hackish this thing was.<p><a href="http://www.escapistmagazine.com/news/view/99883-Halo-2s-Development-Was-a-Gigantic-Mess" rel="nofollow">http://www.escapistmagazine.com/news/view/99883-Halo-2s-Deve...</a><p>And some interviews.<p>For the sake of disclosure, I've never done a startup. But if I've been reading the right authors than the right thing to do in this situation is to go ahead with it and fix it later once you're off the ground.<p>EDIT: I also like jeffbcross's advice if that is at all possible.

It depends.<p>If you feel like you're close to product/market fit or if your runway is short on your startup, you might want to continue the way you've been doing things.<p>On the other hand, as a self-taught programmer, I imagine there are a lot of skills that you can improve on. The danger of writing spaghetti code is you can't reuse it, and if you continue to write spaghetti code, it be becomes a habit. In the long term, your best investment is in yourself. Time spent on getting good at your craft may help you to get your product to market faster.<p>Also think about how much time you expect to use on revising/debugging old code. If you expect to extend or build on top your code, it is usually worth spending time revising it. I like to believe there are different degrees in quality for code. Spend more time on more vital or core components and less on others.

How is your crappy code affecting your customers? Is it delaying adding new features? is it affecting performance in a meaningful way? do you have scaling issues? is the code buggy?<p>Are your customers providing feedback on too many bugs? slowness? new features not being added fast enough?<p>How much is it going to cost to clean up the code? Can that time be spent on something that's going to add more value to the customer?<p>Also each code change you introduce adds risk/time for testing, developing, debuging, release. make sure your adding value.<p>If your in the code fixing something else clean it up a little bit. Otherwise it seems to me your wasting time on vanity.

Well, the best way to take out the garbage is to actually identify one - very first. Good that you have accepted this with complete humility.<p>Now, think over it, work hard, improve day by day.

This, of course, only works when I will continue in the project. I once had to hand over a project with some code I had put together the previous week, to a just hired, more expert employee who was going to "perfect" the project, and it was not a pretty situation. By that time I knew the data very well, and the new person did not, but had to be made busy. I felt not just embarrassed, but also that the whole thing had been a waste of time for everybody.

"but we're still attempting to find product/market fit"<p>Then find the product/market fit <i>first</i>. If the code works, you can clean it later.