Startup blogs and gurus often give the sense of false urgency. But if you keep your burn rate low and stay on course, you'll probably get there just as well. Worrying about competitors beating you to market seems silly to me in most cases. Definitely in mine anyway.
You have to find time to sip your coffee, play with your kids, read HN, and maybe even pull the guitar off the stand once in a while. Did I mention the wife in there? Life is not something you'll starting living after you make it rich.
Definitely— but that seems like maybe it's going too far the other way.
Or to put it another way— It's not a race. There's room enough on this big ol' internet for patient folks who keep up a steady pace for years, and for insatiably driven folks who hammer out a for-profit app over the weekend.
The only thing that matters are your individual goals— is reading Hacker News too much stopping you from launching when you want to? You should probably cut down. Just the same thing as if reading Hacker News too much is stopping you from hugging your baby enough.
I definitely recommend the slow and measured approach. Started working on my startup as a side project while still employed at BigCo. Launched, waited until $app_income >= $salary_income, then quit to do it full time. I'd argue the only reason to rush and launch something is if you have or are looking to get funding.
Since I've started to frequent HN, I've learnt a lot about stuff I wasn't initially very familiar with (mostly the non-technical stuff posted here). Recently, however, I find that more and more of what I read is slight variations of what I read before; I don't learn as much anymore. I think that this is not HN but me, and I think it's good.
Basically, for me, it may very well be that reading HN for the first few months is launching, but reading HN for over a year isn't.
Needless to say, it looks like I'm not launching anytime soon.
The combination of the ambiguous word "is" and the mixed capitalization styles in the title is interesting. When I first read the title, I saw it as:
ReadingHackerNews.is_going_to_launch? # false
And wondered who the Reading Hacker News team was, and why they decided to scrap their launch. After a couple seconds I saw the forest for the trees and realized it said:
ReadingHackerNews !== Launching # true
Now, what's interesting is the interplay between:
- capitalization conventions in human language
- capitalization conventions in programming languages
- the author's specification of [Reading Hacker News]
in the article, that indicates that he is referring
to it as an object in itself
- the requirement for him to use brackets instead of
merely case to indicate this, because he needed to
capitalize "Reading", and "Hacker News" to be proper
english anyway.
- the way the brackets were left of in the submission
title
- the fact that programmers often use things like
CamelCase in english to communicate concepts
analogous to those found in programming, like
object-ness.
- the existence of a lot of third party HN tools, such
that one of them could conceivably be called "Reading
Hacker News"
There is a lot of stuff going on in this title for the brain to process. I wouldn't have noticed it at all except that my brain glitched and produced the wrong answer for a second or so.
It's crazy to think about (1) how many difficult background questions our minds silently get right, and (2) how many of these questions our minds silently get wrong.
"Garden path sentences are less common in spoken communication because the prosodic qualities of speech (such as the stress and the tone of voice) often serve to resolve ambiguities in the written text."
Another random and crazy thought: people have experimented with textual and graphical programming languages -- I wonder what an aural programming language would be like? It's almost certainly impractical, but the idea is intriguing nonetheless.
Maybe slightly more practical would be some kind of aural complement to conventional sight-based programming systems...
Greek, for example, is quite a bit less ambiguous than English. We don't have anything close to the number of homographs in English, and parts of speech are very distinct (a word can almost never be both a verb and a noun).
In English, "right" can mean any number of things, it can be an adjective, a noun, an adverb or a verb. In Greek, that would almost never happen.
I think you might be running into native speakers' bias. (I'll grant you I know nothing about Greek, just going off Wikipedia here, so forgive me.)
Greek is classified as a fusional language, essentially meaning that it's an agglutinating language with a more complex inflectional scheme that's harder for linguists to figure out. Naturally there's going to be less lexical ambiguity than in an isolating analytic language like English, since grammatical information we're used to inferring from context or marking lexically you're encoding as an affix. By contrast, we find your system of affixes complex and difficult.
The important thing to understand here is that a native English speaker treats words the way a native Greek speaker treats affixes. When we read a sentence, we automatically filter the words on the basis of the context, just the same way when you read a Greek sentence, you're automatically filtering affixes on the basis of context. The "ambiguities" you perceive — "right" can be an adjective, noun, or verb — are effectively the same as, say, an ambiguous -o suffix which marks a tense on verbs, but a case on nouns. For native speakers, they simply never notice.
(Of course speakers of all stripes make mistakes and need to clarify ambiguities— no matter how they're encoding information.)
And it goes the other way too. Take a native Californian language like Eastern Pomo, in which verb stems describe relationships of energy and motion which are difficult to describe in English. Copying from notes here: For example, the stem pa-qá-t(-ki-) has the root meaning "to apply pressure", the instrumental prefix implying from kinetic energy, and an intensifier, semelfactive and stative suffix. This stem means both "to pry abalones loose from rocks with an iron bar" and "for high flood water to come down a creek and wash something away." Remember, this is a polysynthetic language— nearly every word has this sort of variance in meaning. We perceive that as horrifically ambiguous, and nigh impossible to parse without concerted effort, but a native Pomoan would never mistake them.
I see what you mean, but I disagree about the bias. I'm pretty handy with English, yet parsing some headlines is a challenge sometimes, like the poster above noted. I have yet to encounter parsing trouble in Greek.
The example you give about the -o affix, while valid at first glance, is actually not, simply because verbs end in omega while neuter nouns end in omicron. Thus, they could never be mistaken.
I'm not saying Greek is easier (approximately zero foreigners can make sense of our affixes, always choosing one and tacking it onto every word when they try to speak Greek), but I am saying it's less ambiguous :) For the record, I had no trouble parsing this title, and, in fact, was unaware of alternate interpretations until the poster above pointed it out.
Whoop, that's carelessness (or extraordinary good fortune?) on my part. I didn't mean to imply an actual Greek suffix, I was using -o as a theoretical example.
However, just glancing again at Wikipedia I see that "In Modern Greek Ω represents the same sound as omicron". So actually this is a perfect example of the native speaker's bias I'm talking about. You can't tell those suffixes apart in speech because of spelling, you can tell them apart because of context— but you're so used to conceptualizing them as fundamentally different, it didn't even occur to you that to a non-native they sound the same.
It's also worth noting also that headlines follow their own peculiar grammar rules which make them unusually prone to forming garden path sentences— lots of native speakers get confused sometimes too. ESL courses cover headlines specifically, since their grammatical structure is so opaque: http://www.esl-lounge.com/student/reading/4r46-headline-engl...
Don't take any of this as a criticism of your broader point— I'm willing to grant there are levels of ambiguity, and English with its highly lexicalized grammar — and especially Headline English with its nearly absent explicit grammar — is definitely up there on the scale. I just wanted to point out that no matter how we analyze them, all languages are natural to parse for native speakers and awkward to parse for non-native speakers— that's not related, or is only vaguely related, to their intrinsic ambiguity.
I definitely agree with your broad point, especially about headline grammar. I disagree on this being mostly a native vs non-native speaker issue, though. I'm sure you will agree that a language where most words can be used as multiple parts of speech is more ambiguous than one where they cannot.
Oh, like I said, I'll totally grant that if we're talking about lexical ambiguity. Words in isolating languages accumulate extra meanings, just like morphemes in inflecting languages do.
But again, that's just because of highly lexicalized grammar; it's practically no different from having an "ambiguous" system of inflection, or bizarre energy-focused polysynthesis, which a native speaker would never mistake. That's where I'm saying someone who grew up with a strongly inflected or polysynthetic language would be biased.
And I hope you don't take this as a criticism of your English— you're obviously perfectly fluent! There's simply a basic level of intuitive understanding of a language which is impossible to get without growing up with it from infancy. That's why in linguistics we don't talk about fluency as much as native vs. non-native speakers. It's where you can really separate the meat from the bone, if you will.
To be just a little contrarian to this post, I've become at peace with the idea that you should probably always spend a great deal of time, and maybe or probably even more time than you feel totally comfortable with, learning about all aspects of something new that you're trying to understand and do something with, and maybe even mentally iterate through different ideas and through a wandering exploration of the idea space while you're building your understanding of it, before you try doing the something with it.
That said, I also love the post and I've bookmarked it to look at again on the committed date to see what they've come up with.
Yeah, blogging about launching and posting it on HN is not actually launching either. But still worthwhile! Talking about launching is silver, launching is gold.
what is launch then? telling on a big conference with big fanfares?
i really want to know because i announced our project here and was ignored, so i know for sure that writing on HN is not launch
telling on blogs and forums is a way to test how needed is your solution.
my unnoticed launch maybe is gold, but massive discussion of it, testing of our technology, emerging of fans and haters - that would be, i dont know, platinum :)
I was pondering this myself as I posted my short comment. Good question.
BTW, can I offer any help on getting you some attention? It is not magic, just some routine work we could do together. I have a fair bit of experience from getting my own startup established the past five years.
did @antirez of Redis do those things? i guess the audience just liked his project and that's all. if my work is BS and we get some attention with some tricks (edit: in a good sence of the word!), we would just agonize longer before everyone including me understands that my work is unneeded.
let it be as naturally as it is but thanks anyway
(addition: be us a consumer web startup we would agree. our audience is hacker and web engineering crowd, so the help would be just upvote my posts :)
There is such a thing as deserved attention and it doesn't come by itself to the rest of us. PR is not smoke and mirror, it is plain work. Still, it's the part of 'launching' that few have worked out how to do just because they don't take the time to do it.
If web development could be reduced to 'just sit down and write a program and put it on the web' then PR could be reduced to 'just find out what journalists and bloggers have readers that would be interested in your stuff and ask them to write about it'.
It is as simple as that and as with programming, it only takes a couple of years to get a good grasp of.
(addition in response to your addition: so make sure I get to know when you post something you'd like me to upvote. See, then you're doing PR work. If you think attention will come by itself, then you could sit in front of your TV and expect your software write itself as well)
Antirez was a known quantity. He was known for hping, way back before Redis was a glimmer in anyone's eye.
Going from awesome to further awesome is easy. To mix metaphors there - the first million is hard.
ive found i learn the most from just experimenting and DOING. I can read learn python the hard way all day, but when it comes down to it, trying to do your own thing is the best teacher.
I've found that sometimes, but have also found the opposite, where 30 minutes of reading has cleared up many, many hours of confusion borne of experience. Most often it takes the form of: 1) run into variants of some minor difficulty on and off, develop a solution or workaround; 2) run into another edge case that breaks my solution, patch it, start wondering if this problem is more subtle than I'd first thought; 3) try to determine if what I'm doing is an instance of something more general that has a name; 4) finally find a chapter in Knuth that exactly explains why I've had the problems I've had, in addition to giving me a solution that covers a more general case I hadn't even run into yet.
(On the other hand, having run into the problem in various forms 'irl' probably did make reading the description/solution in Knuth more intelligible and well motivated, compared to if I had just sat down and read every one of his books first.)
"On the other hand, having run into the problem in various forms 'irl' probably did make reading the description/solution in Knuth more intelligible and well motivated, compared to if I had just sat down and read every one of his books first."
That's definitely the case for me. I find that I don't have the internal motivation to sit down and read a lot about a given subject until I've been faced with some real- world problem that turns out to be really hard without more knowledge of that subject.
I like to speed read/scan books like Knuth's just so I have some mental map of what's in them, even if I don't grok it right away. That way when I do hit a problem I'm working on, I'm more likely to remember I saw it already solved in a book somewhere.
In fact, I just assume from the start that every single problem I face in programming, no matter how large or small, has already been found and solved by someone else, and written about in a book or posted about on the internet. It's not like I'm trying to create real AI or prove P=NP or anything, just building apps.
But if you're reading Learn Python the Hard Way and actually doing what it says, you are doing a bunch of coding exercises including experimenting and not just reading.
I agree with this post with one caveat, I've done this, I've shipped many times, all failed projects or what I consider temporary embarrassments. Shipping is not enough. People must want what you are offering, and you must have a means to reach those people. I've learned a thing or two reading hacker news, some sort of balance is important. Taking a break from news feeds to focus on your work is a good idea, but don't think launching is enough.
When it comes to the kinds of businesses we are dealing with here, operating and researching not only can be done concurrently, but they are often more valuable together. Particularly with tech businesses, we are often pushing some boundaries somewhere, and the only way to really figure out whether what we are reading is valid and useful is to actually put things in action. By having a business in motion, you have direct context in which to interpret information, as your research is also informed by the additional information that can only be obtained by operating in some capacity.
All of this is why the minimum viable product approach can be so valuable. In many cases, you absolutely do not need to make a huge number of decisions before operating. Treat the business as a largely blank canvas. There's a core idea, so put that out there and start experimenting.
Don't worry that you don't have all the features of a similar or competing business that's been operating for a couple years. Don't worry that you don't have everything figured out. In the kinds of business we most frequently discuss here, it really doesn't matter. You will make mistakes (and even your most competent competitors will, too). You will tweak. You can pivot. Most importantly, you can grow.
I sometimes keep myself from this site and others I habitually frequent though DNS, too. Handy to have an automatic script to do it! But that might be too easy. Editing /etc/hosts by hand is clunky enough that it's a commitment to do so, and takes more than a second.
All things in moderation, though. Visiting discussion sites 30 times a day, any time your attention span breaks, is not helpful. Reading once or twice a day is perfectly healthy and does help you get things done, through what you learn.
I'm at the same point now, though. I unblocked this site, Reddit and picked up another forum again a few months ago, and I feel about as the author regarding not getting things done. I've posted on social networks, I've read blogs and absorbed the essence of the zeitgeist. Time to build some products, polish 'em up and make some money.
I suppose you can read all the startup stories you like but in the end you won't learn anything unless you just jump in, see how it goes and iterate from what you learn.
I think Hacker News has taught me a lot though, i'm not saying learning from others isn't important, it is. But in the end you have to launch something and learn your own lessons.
There is nothing wrong with reading sites like Hacker News. Just do it when you need a break. i.e after you've done a whole lot of work. I'm on the couch writing this on my iPad after coming off a 10 hour coding session. Code first, hacker news second.
Like most procrastinators, 90% is done in the last night. A good way to give you this boost is to tell someone about your X you are building and you will show them tomorrow or next week or whatevers. Now you have to get it up and at least decent so you don't look like a fool. It will probably put you on overdrive.
God, I can't wait for this era of wannabe yuppies to end, yuppies reading about launching startups and talking about startups and thinking about everything in terms of startups. It's got to be the most boring tech news of all time, and I have no idea how anyone could be interested in it.
May I ask why on earth you are here? This is HN, which used to be called Startup News and is run by a noted venture capitalist who works with startups night and day.
You can join the startup crowd yourself or not, as you prefer, but if you're going to voluntarily hang out in their space please refrain from trolling them.
Startup blogs and gurus often give the sense of false urgency. But if you keep your burn rate low and stay on course, you'll probably get there just as well. Worrying about competitors beating you to market seems silly to me in most cases. Definitely in mine anyway.
You have to find time to sip your coffee, play with your kids, read HN, and maybe even pull the guitar off the stand once in a while. Did I mention the wife in there? Life is not something you'll starting living after you make it rich.