This is gold. While I agree with most things the author mentions, I'm kinda meh on this statement.

> Write good code. Go back over older code and rewrite it. Then come back later and rewrite it again. Make it better.

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.

For the purposes of the article - "How to get people to work on your project" - won't tidier code (as in: it looks pretty when viewed on GitHub) - be more likely to attract potential contributors?

Getting the code to work as intended is obviously key - who wants to contribute to a project that doesn't even work? - but my personal view (with no data to support it) is that people are more likely to contribute if they think they can add something to the project, and the speed of being able to come to terms with the project's code base forms a good part of their calculations on how/where to spend (waste?) their spare time.

... Not that it's worked for my project. But then I'm also a poet and my need to make things look pretty on a page sometimes overtakes my need to make sure the code works. All poets know how to "Fail with motherfucking gusto"; we also know how to look stylish while doing it!

I'm not sure I understand the part about momentum. What's preventing you from rewriting code once it has been shipped?

Besides, while shipping a working version is crucial, it's perfectly possible to plan ahead and refactor early if you're confident that getting to a working version won't be a problem.

I see it as: If you've already shipped A, your user-base are using A. Your user-base are now requesting feature Z

You then need to balance Z with rewriting A to B. The workaround to that is to rewrite A to B while implementing Z but the caveat; is there a time-frame to where Z must be implemented? Because if you implement Z ahead of refactoring A to B you now got to rewrite A to B while not breaking Z while letting Z grow because they want feature Y. Not forgetting you need to recode Z because the old code is old code.

The "actually working on it" part is key.

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.

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.

"actually working on it" hurts so much. I have an idea. I think it will be amazing. I love thinking about it and talking to others about it. Yet every night I watch tv, play games, or anything else except working on the idea.

I can't tell if it's a subconscious fear of failure or just general laziness but I can't even write the first line of code and it's been 3 years since I got the idea.

For general laziness, in the order of importance: fix sleep (consistent wake up time), exercise, diet (cut out sugar and junk food like potato chips and ice cream, soda etc), vitamin D, blood tests, regulate stress, keep track of coffee, meditate, reduce alcohol, take breaks from social media, porn, addictive games, binge watching etc. Read physical books. Go out in nature without phones.

Such things can help immensely with vague laziness. Don't overthink it, there is no magic quick fix and it's not just about this one weird self help trick to fix your mindset. We tend to forget how much we are biological animals on the inside and the animal needs to be kept well.

Start with waking up at the same time and winding down in the evening early enough to sleep enough. It's much easier to get a grip on such concrete things as waking up at a particular time (or not eating added sugar) vs starting the big vague project, staring at the empty console. Once your routine is set up you will find you have more willingness to face and take on difficult tasks of many sorts.

I cannot stress this advice enough. I have ADHD so a healthy routine seemed like anathema to me and it felt like my entire soul would resist it at every turn.

Once I started getting up early at the same time every day, everything else flowed from that positive momentum. I get up meditate, eat, lift weights, then bike to work by 8. I, can crush work all day and I carry that positive momentum all the way till I go to sleep and accomplish many things after work. I have tamed that procrastinating distraction monkey on my back into a tenacious omnipresent will for self improvement.

I'm a classic procrastinator, and it probably is akin to fear of failure.

But more accurately, I find I'm anxious because I have grand ideas of what I want to accomplish, but when I try to do it my ability falls short of my ideals.

The only way to get better though is to just do stuff. So what helps me is giving myself permission to make mistakes and do mediocre work. The next iteration will be better, but for now I just need to make SOMETHING.

Here's what you need to do: ask yourself "what's the smallest thing I can do right now?" Do that thing. Then rinse and repeat.

You mention the first line of code, so I'm assuming you're talking about software. If you're having trouble getting started, it could be because your idea is not clear enough in your mind. How can you get to where you want to go if you don't know where you're going? Creating a low fidelity mockup will help with this. You'll start to have a better understanding of how your product might be used, and then you'll start to see how the domain objects in your project relate to each other. You'll start to see the data requirements and you'll start to see where user actions take place and where API calls should be made. It will be easier to know what to do next if you can get to that point. That mockup can serve as a tool for communication. You'll be able to divide up work and assign it to people. Most of us that decide to be a part of something are just happy enough to be along for the ride. People want to and enjoy helping other people. You just have to let them know how they can.

I have this problem in a big way, too. I haven't permanently cracked it, but I can crack it here and there. Basically when I get free time and notice I'm defaulting to "I'm gonna go <slack off> now", I immediately replace that with, "Actually I'm just gonna do this one thing on that project". Inevitably, I get sucked into the project until something breaks my flow. The more consistently you can do this, the easier it gets because then you develop a sort of "passive flow" where a perpetual background mental process gets pulled farther forward to where you can't wait to get back to working on the thing, whatever else you're actually doing.

And between failure and success, I'm far more scared of success. Failure is demoralizing but at least it means you can put a pin in the thing. Success means people probably now have expectations of you.

Don’t feel bad about not wanting to replace your relaxation time with more work. You enjoy thinking about this idea because thinking is an escape; a distraction from whatever you’re doing in that moment. Actually doing it is not an escape any more, it’s a new problem. Maybe you could test it out without writing any code? Or maybe not - maybe you just need to find a new job or something like that. Or maybe there’s nothing wrong with the occasional daydream?

That's classic subconscious fear of failure.

Just do something stupid that goes in the right direction. Do it this weekend. You know you want to.

Ideas aren't worth basically anything. Just start. http://www.paulgraham.com/start.html

If you can convince yourself of this, then what you have is really not worth anything unless you execute something on it.

If you send me an e-mail and tell me your idea, I'll write the first line of code for you for free to get you started! :)

Talk to your potential customers. Maybe you have doubts that are very real reasons you shouldn't start.

Summary:

1. Make a project

2. Work super hard at it but not to the point of exhaustion (stay optimal/healthy)

3. If you aren't already, become a good programmer yourself (you really need this, if I'm reading the author correctly)

4. Test your code

5. Be capable of dealing with anger, frustration and joy

6. Your biggest issue isn't time, it's your motivation

7. Dare to fail

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.").

---

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].

[1, Ask HN: Diverging products: fork codebase, create config file or other option?] https://news.ycombinator.com/item?id=23562286

I love this quote at the end:

“ Succeeding, like flying, is throwing yourself to the ground and missing.”

Cool article and definitely as someone else mentioned, very similar to a locker room pep talk.

You probably already know this, but the line is paraphrased from The Hitchhiker's Guide to the Galaxy, which is an amazing book if you like that style of humor.

This sounds like a coach's locker room speech, with a tad too much vulgarity for my taste.

I would summarize it as: work hard and frequently, test and refactor, embrace failure. Don't give up.

Pay them? It's complicated. Sometimes you just don't want anyone or someone but a special one.

> Put it up on Google Code, Rubyforge or something similar. Haunt the IRC channels..

I guess we'd be looking for "something similar" these days. Sad that there is so little competition in that space now (all github)...

Gitlab? Source Hut?

Zefrank's video on brain crack really summarizes the core idea of this article.