3 ms·
You aim too high. Is it because you are not convinced that aiming lower is the right thing to do; or do you believe it but you have trouble actually doing it?
by 10ren 16y ago
You aim too high.
Is it because you are not convinced that aiming lower is the right thing to do; or do you believe it but you have trouble actually doing it?
Perfectionism is common in programmers (perhaps because imperfect syntax doesn't work). It means that you compare your product with "perfection", instead of comparing it with "nothing" (ie. it not existing at all.) If you tend to be critical, and quickly notice faults and omissions, then you may be a perfectionist. It seems to me that perfectionism is the number one reason why many programmers aren't successful in business. It's very difficult to overcome, but one way to begin is simply try to find what does exist in your product (and elsewhere), and just acknowledge that it does. You might not yet be convinced that it matters, but just being aware of it is a start.
For me, a crucially motivating thing was people actually being interested: feedback. When I launched that 2-hour product, I wouldn't have continued if there was no feedback. But there was (a single email!). Feedback can help survive the gap you mention, to paying customer. Before then, just getting something that does something can be very motivating (see my GP comment).
BTW: don't do tdd for a MVP! It takes too long. The advantages of tdd don't really make sense for prototype.
EDIT Ask yourself how you could cut corners, and yet still deliver some of the essence of the thing. Work out what your one essential idea is, and try asking of a particular line of code: is is absolutely necessary for that essence? Some other questions:
- error checking? *cut*
- corner cases? *cut*
- "option to save your work"? *cut*
(unless it's a DB etc, whose essence is storage)
- cover the most common cases? *cut*
(just cover *one* case)
- documentation? *cut*
(except: the essence + how to run)
- debug? *cut*
(provided it mostly runs)
- integration test? *cut*
- define formats/interfaces? *cut*
A more extreme cut is possible... No Code:
- present slides of your product (Steve Blank)
- pretend to have a product, but you just:
post on HN
one webpage (optional: a survey on it + Skype chat)
(feels wrong to me, but can be done ethically)
- adwords campaign + landing page
Consider your PHP friend... did he aim high? What specific actions did he do that were different from your other friends?
Here's some essays that might help: "Mediocrity is underrated (or better is the enemy of good enough)" http://nayna.org/blog/?p=11 http://nayna.org/blog/?p=11
"Getting Real" [6 very short excerpts, I suggest read all esp the footnote/quotes, in this order:] http://gettingreal.37signals.com/ch02_Whats_Your_Problem.php http://gettingreal.37signals.com/ch02_Whats_Your_Problem.php http://gettingreal.37signals.com/ch09_Epicenter_Design.php http://gettingreal.37signals.com/ch09_Epicenter_Design.php http://gettingreal.37signals.com/ch06_Race_to_Running_Software.php http://gettingreal.37signals.com/ch06_Race_to_Running_Softwa... http://gettingreal.37signals.com/ch06_Shrink_Your_Time.php http://gettingreal.37signals.com/ch06_Shrink_Your_Time.php http://gettingreal.37signals.com/ch06_Done.php http://gettingreal.37signals.com/ch06_Done.php http://gettingreal.37signals.com/ch10_Less_Software.php http://gettingreal.37signals.com/ch10_Less_Software.php
and pg's 2008 essay (on HN 2 days ago): http://news.ycombinator.com/item?id=1525068 http://news.ycombinator.com/item?id=1525068
disclaimer I find it hard to cut corners on my present project. My excuses (which I'd like to overcome) are due to it being based on a new mathematical model:
- if the maths isn't realized correctly, it won't work perfectly
- showing off all its benefits (eg error checking) requires more work
- getting the foundation right will be easier to build on
- patenting (can't be done after release)
- deleted 16y ago[deleted]
- rmoriz 16y agoMy "PHP friend" has already done several profitable projects with the least amount of perfection. He knows how to do it right, has already the traction to bring already paying users over to his other new projects. Unfortunately he lives ~500km away. When I ask my developer colleagues about feedback for my "crappy alpha", I'm just getting totaly bullshit responses like "you need javascript input validation before the user sends his form" despite the real problem I try to resolve. So I asked serveral of my ~100 developer contacts on different projects, unfortunately feedback was kind of the same. But only few of them managed to release something in their spare time. So they probably have the same problem as I have. It's hard to get in contact with people that made it, some of them just tell you "I was lucky" which is cool, but not really helpful - It's easy to say that when you've made it :)
- 10ren 16y agoSo it sounds like you're convinced you should aim lower, but are having trouble actually doing it. Oh no, you don't ask for feedback from your colleagues - you get it from people with the problem you're solving. From users. Your fellow developers can't even know if you solved the user problem; the best they can do is point out things like grammatical errors which, as you say, is useless. EDIT I guess your PHP friend wouldn't have been able to bring over users for his very his first app, and I bet he remembers it vividly. You could email him, or talk on the phone. He's not the only person in the world to have shipped, but you know him, so he's an excellent person to start with. You could visit him. Consider: 500 km vs. 4 weeks. Sounds ridiculous, but if you take this journey, you won't forget his point of view.