This is gold. While I agree with most things the author mentions, I'm kinda meh on this statement.<p>> Write good code. Go back over older code and rewrite it. Then come back later and rewrite it again. Make it better.<p>IMO, just making it work initially is what matters the most. Ship it, get the bug reports, and fix the kinks. While fixing the kinks, maybe refactor a bit here and there. Some could say, yeah but refactoring makes it easier for others to work on the code with you. My response to that is, yes... but this is a chicken, egg problem. You can write the prettiest code in the world where even a toddler can start hopping on and writing code. But, none of that matters if you never ship, pick up some momentum, and actually have people who want to work on the project with you.
The "actually working on it" part is key.<p>I'm doing a startup idea with a semi-technical guy I knew from high school. Most of that time that last statement would be a red flag -- most of the time you want technical co-founders -- but this guy has already invested tens of thousands of dollars of his own money building out a product, and already has interested clients.<p>I'm not going to invest my time if the other party isn't invested and expects me to do all their work for them. If they're working their ass off to make it happen, though, I just might join them.
Summary:<p>1. Make a project<p>2. Work super hard at it but not to the point of exhaustion (stay optimal/healthy)<p>3. If you aren't already, become a good programmer yourself (you really need this, if I'm reading the author correctly)<p>4. Test your code<p>5. Be capable of dealing with anger, frustration and joy<p>6. Your biggest issue isn't time, it's your motivation<p>7. Dare to fail<p>So basically: build a project and talk to people. He writes about it epic/coach-like way (e.g. "Fail hard. Fail with motherfucking gusto. Succeeding, like flying, is throwing yourself to the ground and missing.").<p>---<p>I might need to become good at getting people to work on my project, as I might need to split my codebase in 2 and I would like your input on how to go about it [1].<p>[1, Ask HN: Diverging products: fork codebase, create config file or other option?] <a href="https://news.ycombinator.com/item?id=23562286" rel="nofollow">https://news.ycombinator.com/item?id=23562286</a>
I love this quote at the end:<p>“ Succeeding, like flying, is throwing yourself to the ground and missing.”<p>Cool article and definitely as someone else mentioned, very similar to a locker room pep talk.
This sounds like a coach's locker room speech, with a tad too much vulgarity for my taste.<p>I would summarize it as: work hard and frequently, test and refactor, embrace failure. Don't give up.
> Put it up on Google Code, Rubyforge or something similar. Haunt the IRC channels..<p>I guess we'd be looking for "something similar" these days. Sad that there is so little competition in that space now (all github)...