If I wrote an article with the same title I would only include one thing to remember when coding and that is to write code with the expectation that others will have to read your code. (This of course assumes you're not an ass who wants to make people's lives more difficult!)
I find that statement to generally sound good, but there are lots of nasty details that are often overlooked. Taken to it's extreme, it leads to overly commented code that tries to explain to non-programmers what a program is doing. I find my time better spent than doing that for all code I write. Then there's the question of who the expected reader is? Some future version of you? Some coworker or successor in the same field, expected to be at relatively the same level in the relevant areas? Some beginner in those some fields. A programmer without experience in the relevant areas, or not yet comfortable in the chosen language and able to understand it's idiomatic usage?
Don't get me wrong, I'm in favor of the concept, I just find that most people seem to put very little thought into what it means in practice.
I always learn better if I write things down. I also remember better if I wrote down what my code does as detailed as possible. Also improves the search-possibilities when I need to find something three years later :-)
Comments are not "code". Your code should, when written impossibly well, explain itself through variables, function names and composition. Better code equals less comments needed.
I think this is exactly the sort of position that leads to problems later when people find their implicit assumptions don't match with those of others.
I can write perfectly idiomatic code in Perl, using map, grep, simple postconditionals, taking advantage of built in functions that topicalize, knowledge of when items are passed by reference or copy (or a sort of alias), and the code will be very succinct and readable to Perl programmers. Should I forego some of that to make the code more readable to general programmers? Doing so will necessarily make the code slightly less readable to those expecting idiomatic Perl.
I'm not espousing one way over the other, just that it should be thought about with regard to the purpose of the code, who owns it, and who will be looking at it in the future. The exact answer may differ in different situations.
If you return to your code a couple weeks or months later, chances are you'll be in the 'others' category too. So by writing readable code, you're doing yourself a favor most of all.
Nice execution. We had a similar idea called http://www.pinchthelook.com but for women. The feedback was great and people 'loved' the site but ultimately we couldn't get to a scale where there was enough traffic and clicks to make it worthwhile. Engagement isn't fantastic since it's more of a quick browse and if I like something click away from site.
Perhaps this idea will work better for Men as they probably need a bit more help in piecing together a look (more often than not) ;)
Nice looking site. As far as traffic goes, perhaps you might want to re-consider your page titles/headers as well as include more content with targeted keywords. I can't imagine many people are searching using terms like "short and sweet". Also, your content is quite sparse when it comes down to it, which means there's really not a whole lot for search engines to index.
We tried to launch pretty much the same concept a few years ago (dating through friends of friends on Facebook) but it didn't work out. It was called 'Trustcircle' and we still own the domain (www.trustcircle.com) in case you are interested in buying it! It might be a better option than tomonotomo! Just sayin' :)
Nice. Just signed up and created an application. Excited to see what may come out of this. I'm more interested in pairing with somebody who's better than me rather than working on a specific problem of my choice so hopefully someone can help!
I think it's hard to argue with a lot of the points he raises. Certainly the 'lack of virility' is an issue and it's much harder to get significant gains now without resorting to a few hacks. The most concerning point I think has to be the case where Facebook denies advertising to competing products. That would suck if it happened!!!
Again hard to argue with many of the points raised, but with that said I think there's still opportunity - just not the same as before where the likes of Zynga and iLike were able to get shed loads of traffic for virtually nothing.
Perhaps "any publicity is good publicity" - at the end of the day, he's had two posts about Betapunch on the front page of HN as a result of all this, and I doubt people will remember this whole episode in a few weeks.
I attended the last meet up in Boston whilst visiting and I have to say this Ruby group is pretty special. I will, for sure, be watching via Hangouts when it goes live!
Which is what I'm guessing as well. Since it's not a product-issue, Kevin's not-coding didn't hurt. Which was the point I was trying to get at. Even if he could code, that wouldn't help solve the market-fit problem.
Great post and a lot of useful information. Particularly relevant for me as I'm a noob starting out on my first project, much like described in the post.
I've followed a very similar roadmap in learning bits of html/css (highly recommend the Head First book), javascript, version control, ruby and doing Hartl's, 'Rails Tutorial'.
I didn't get a job at Pivotal Labs in SF like the author (which I'm guessing would be a pretty awesome learning environment) but I've managed to convince the 'Pivotal Labs' of the Philippines to take me in & provide mentorship ;) If anyone is interested I've just started keeping a log of each step along the way at http://www.ralphy.tumblr.com. (Will update with more posts soon).
So far, it's been tough and I'm realizing how little I know in the whole spectrum of Rails, let alone web development. Having said that I'm already building stuff on the web I can actually see and show my friends, which is kinda awesome.
