6 ms·

"I want to start a startup, but I don't know how to program. How long will it take to learn? I would guess a smart person can learn to hack sufficiently well i

"I want to start a startup, but I don't know how to program. How long will it take to learn? I would guess a smart person can learn to hack sufficiently well in 6 months to a year." Hmm... interesting take considering the source, especially when contrasted with the general mentality that programming and software development is the finest of all trades and takes a near preternatural mastery only found elsewhere in classical musicianship 300 years ago. I quite enjoy the feeling that I could be good in a year.

edanm 15y ago
Note: he means "good enough", not good. Which brings to mind patio11's constant reminders, that running a successful software business has very very little to do with programming well. Which means that pg thinks that 6 months is the level you need to be at to be able to start a startup. This seems intuitively right to me, especially these days.
- _delirium 15y ago
  In fact the usual advice is that you shouldn't be doing something technically virtuosic in a startup. If your startup's critical path includes writing something as technically impressive as the Glasgow Haskell Compiler, you might have trouble... Though there are a few people around here who've built software businesses around things that are also nontrivial technical advances; cperciva comes to mind.
  - edanm 15y ago
    I know that's a sentiment that's thrown around here, but I think it's simplistic. I live in Israel, where a very common path to an Exit is to build some sophisticated technology, then sell it after a few years to a larger company. So it is a very possible path you can take. It has its own advantages and disadvantages over the much more visible, much more HN-friendly, "Consumer Internet Startup".
    - bergie 15y ago
      The exit and valuation models for these two approaches are also different. In the former, some company buys you because they want to use your technology in their own products, in the latter, some company buys you to get your customers/users.
  - gbog 15y ago
    It seems all or most pg's articles just say the opposite: a startup should climb the highest hills, and can do so faster the big corporations because they are light-weight. If I'm not mistaking, "climbing" here do not mean find a genius idea or a disrupting design for a search field, it means developping something hard in software. The conclusion should be that a startups that is not doing something technically hard should be considered in trouble (because so easy to clone).
    - Aga 15y ago
      I think it does not have to mean "developing something hard in software", but more like "finding an unsolved problem and using software to solve it." It does not have to be hard to solve in the software side. I guess the hardest part is finding the right problem to solve!
    - wnight 15y ago
      What I think, for what you may think it's worth, is that you should climb the highest hills, that you'll have to climb, right away. Best to know you can do it before wasting time. But, that you should look for the easiest way to success. It'll take months for a large company to have the meetings to acknowledge your niche, let alone try to serve it. The only thing you have to fear is another startup and you're at the advantage is that situation. Building huge walls or picking a niche with a large cost to serve, is like wasting time on DRM for your game, instead of working on marketing and having someone actually buy it.
  - philwelch 15y ago
    The usual advice seems odd to me. There are two extremes: you can invent something technically trivial and take the market risk, or you can invent something that's technically challenging but with obvious marketability.
- tspiteri 15y ago
  Not exactly the same thing, but this does remind me of a quote from I'm Feeling Lucky: The Confessions of Google Employee Number 59: "I didn't trust Larry and Sergey as coders," said Craig Silverstein. "I had to deal with their legacy code from the Stanford days and it had a lot of problems. They're research coders: more interested in writing code that works than code that's maintainable." According to Jeff, one of the quirks in the early Stanford version of Google was that when something unusual happened the program would print out an error message without any explanation. The message read simply, "Whoa, horsey!"
  - aangjie 15y ago
    7 years ago i would have called myself similar.Though i was just graduating and could have hardly called it research. But 3 years working in the industry with Big blue and i see i have got OCD with maintainability. Heck, i wouldn't even have noticed, if i hadn't quit and went to do a master's. But 4 years since, and i still haven't quite undone the OCD, mitigated yes, but not back to the get shit done passion....I keep working on it...so, i will qualify that 6 months to start a startup, with something about the type of product you aim to build. - May be something along the lines of the impact you expect to make with it.
- enko 15y ago
  > Which brings to mind patio11's constant reminders, that running a successful software business has very very little to do with programming well That may be appropriate for patio11. Not to demean the guy but let's be clear, he runs an online bingo service. It's my understanding that he makes much more money from consulting gigs leveraged from this modest endeavour. Rest assured that if your ambition is to write the next Dropbox or, hell, any YC company, at least 50% of your founding team will need to be very good programmers indeed.
  - jcarden 15y ago
    What does "good" really mean here ?
  - tptacek 15y ago
    In one of his three (3) lines of actual- money- earning- businesses, he managed to factor the "product programming" component down to a kind of minima, allowing him to channel all his effort into engineering his marketing systems. As a result, he was able to use a program that can charitably be described as "Hello World" hooked up to a random number generate to eclipse his full time salary. If you can't see the pure hack value in that, you may be commenting on the wrong message board. The conclusion you think you can draw about Patrick and "programming" from the nature of his first product: you can't draw that conclusion. I'm writing this not to offend Patrick (he could care less about threads like this), but because you are taking exactly the wrong lesson about what Patrick did and then broadcasting it to the rest of the community. Stop, please? :| I'm a systems programmer, since 1995. The list of YC companies that involve "real programming" to me is pretty short. Dropbox qualifies, but how many from the rest of their class would? Which is to say: "technical impressiveness is both subjective and a stupid metric for a business".
    - deleted 15y ago
      [deleted]
ofca 15y ago
I am also fueled by his answer here. I guess that learning parameter depends on your teacher - the better the teacher, the better and faster you learn. I just started learning HTML, CSS, jQ, PHP recently , and I found myself advancing at surprisingly high pace (now watching jQ new_boston tutorials on youtube). Main problem for me is finding good material to learn from, since I only learn from the internet. You have any advice considering good online sources for a total beginner to learn coding really well ?
- wallawe 15y ago
  http://www.w3schools.com http://www.w3schools.com is pretty informative if you haven't already checked that out. The best thing to do, especially if you are on a budget is spend a few hours in a bookstore each week reading over various books on various subjects. I found this a lot more helpful.
  - barry-cotter 15y ago
    I would recommend htmldog.com above w3schools for HTML and CSS. For javascript eloquentjavascript.net is good, and sqlzoo.net is good for SQL (or so I have heard). No doubt there are also some spectacular books for all of these. Please reply with recommendations.
    - nzonbi 15y ago
      In my opinion, developer.mozilla.org has the best online documentation on common web technologies for programmers.
  - sadlyNess 15y ago
    Well, if you look at w3schools, you might want to look at w3fools.com first. It is a criticism of w3schools and recommends htmldog and dev.opera among others.
- chernevik 15y ago
  It has taken me considerably longer than a year. But I might not be smart. And I've tried to do it on my own, rather than taking a job (see prior sentence). Caveat: I'm not a developer, so my comments about learning how to program should be taken with considerable skepticism. But I have some opinions based my effort to learn. For me, programming syntax is less a problem for me than poorly organized code, poor grasp of problems and poorly thought out solutions. Design is a subtle and important topic that does not lend itself to the shorter coverage typical of internet material. Book-length immersion in the concepts is only a beginning to an understanding. So I think your "internet only" restriction is a severe constraint. But it isn't as if there are many design books for beginners. These generally target people who've mastered some languages and know the design-problem space. "Pragmatic Programmer" was a big help. I have found test-driven development an enormous help. It feels cumbersome, but you always know what problem you're trying to solve. "Test Driven JavaScript Development", Johansen, is an excellent overview of the approach. I'm also trying to work through Beck's "Test Driven Development By Example" doing the exercises in Ruby, but it's a side project that hasn't gotten much attention. I repeat: I'm not a developer. Hopefully this is thought-provoking, but I'm no authority.
crgt 15y ago
I've been inspired by Gladwell's more general answer from the book Outliers: "Gladwell repeatedly mentions the "10,000-Hour Rule", claiming that the key to success in any field is, to a large extent, a matter of practicing a specific task for a total of around 10,000 hours." http://en.wikipedia.org/wiki/Outliers_(book) http://en.wikipedia.org/wiki/Outliers_(book) At an average of 50 hrs/week this means it would take you close to 4 years to achieve mastery. pg is certainly correct that you can be productive before this point, but I do believe mastery is much less a function of calendar time, and much more a function of how many coding hours you can get under your belt as the days fly by.
- kragen 15y ago
  Like most of Gladwell's ideas, it falls apart under the least examination. Consider a neurosurgeon. Perhaps after ten thousand hours of surgery she was an expert in surgery. But perhaps only a quarter of that time was spent performing neurosurgery. Does that mean she's not an expert neurosurgeon? Perhaps, then, after ten thousand hours of neurosurgery she has become an expert neurosurgeon. But maybe only 5% of that time consisted of excising glioblastomas from the anterior cingulate cortex. Does she need to spend ten thousand hours doing ACC glioblastomectomies in order to be an expert at that task? In short, because what we normally mean by "tasks" or "fields" can be broken down into smaller tasks or fields, the statement is self-contradictory if they mean what they normally means. But if we search for a definition of "task" that makes the statement true, we can trivially find a circular one: a "field" is something that a talented person can achieve mastery of in about ten thousand hours of practice. Once reformulated that way, it becomes clear that this is not a statement about human expertise or expert performance, but about the economic structure of current society, and in particular our degree of specialization: most people (within the professional class Gladwell finds interesting, anyway) work in jobs that require about ten thousand hours of focused practice by a talented person to reach mastery. (I should point out that this occurred to me when I saw Jeff Fox (RIP: http://groups.google.com/group/comp.lang.forth/browse_thread/thread/622263caccba35b5 http://groups.google.com/group/comp.lang.forth/browse_thread...) claiming that the research Gladwell summarized meant that you needed about ten thousand hours of programming in Forth to be good at programming in Forth, so you shouldn't put too much stock in the opinions of experienced programmers who didn't have much Forth experience.) Once stated this way, we can formulate interesting hypotheses about the cause: perhaps when a field starts to require substantially more than ten thousand hours of practice to master it, its practitioners start to specialize in a part of it, so that they can reach mastery sooner.
dforeman 15y ago
I think that question was included ironically- I.e., he's only been asked a handful of times. His sample size reflects the dearth of "learning how to program to build a viable webapp" stories and comments here. I don't even know if noob questions are accepted here- I've never seen one. I don't post them because I feel I should be finding answers on google rather than degrading the quality of this board. The decision to learn enough programming to build what I want stemmed from the realization that understanding how my webapp will work at the technical level significantly refines my vision for the product- bringing it much closer to reality. Whereas before I was talking to recommendation engine people because I wanted "recommendation features like Hunch," now I'm working in PHP/SQL and getting exactly what I want. My current strategy is to talk to the CTO's and creators of similar webapps to understand their technology and language choices (e.g. GAE or MAMP, SQL or Solr), go as far as I can on my own, and then work with a tutor for an hour or two to get momentum and correct my architecture mistakes.

edanm 15y ago

Note: he means "good enough", not good. Which brings to mind patio11's constant reminders, that running a successful software business has very very little to do with programming well. Which means that pg thinks that 6 months is the level you need to be at to be able to start a startup. This seems intuitively right to me, especially these days.

_delirium 15y ago
In fact the usual advice is that you shouldn't be doing something technically virtuosic in a startup. If your startup's critical path includes writing something as technically impressive as the Glasgow Haskell Compiler, you might have trouble... Though there are a few people around here who've built software businesses around things that are also nontrivial technical advances; cperciva comes to mind.
- edanm 15y ago
  I know that's a sentiment that's thrown around here, but I think it's simplistic. I live in Israel, where a very common path to an Exit is to build some sophisticated technology, then sell it after a few years to a larger company. So it is a very possible path you can take. It has its own advantages and disadvantages over the much more visible, much more HN-friendly, "Consumer Internet Startup".
  - bergie 15y ago
    The exit and valuation models for these two approaches are also different. In the former, some company buys you because they want to use your technology in their own products, in the latter, some company buys you to get your customers/users.
- gbog 15y ago
  It seems all or most pg's articles just say the opposite: a startup should climb the highest hills, and can do so faster the big corporations because they are light-weight. If I'm not mistaking, "climbing" here do not mean find a genius idea or a disrupting design for a search field, it means developping something hard in software. The conclusion should be that a startups that is not doing something technically hard should be considered in trouble (because so easy to clone).
  - Aga 15y ago
    I think it does not have to mean "developing something hard in software", but more like "finding an unsolved problem and using software to solve it." It does not have to be hard to solve in the software side. I guess the hardest part is finding the right problem to solve!
  - wnight 15y ago
    What I think, for what you may think it's worth, is that you should climb the highest hills, that you'll have to climb, right away. Best to know you can do it before wasting time. But, that you should look for the easiest way to success. It'll take months for a large company to have the meetings to acknowledge your niche, let alone try to serve it. The only thing you have to fear is another startup and you're at the advantage is that situation. Building huge walls or picking a niche with a large cost to serve, is like wasting time on DRM for your game, instead of working on marketing and having someone actually buy it.
- philwelch 15y ago
  The usual advice seems odd to me. There are two extremes: you can invent something technically trivial and take the market risk, or you can invent something that's technically challenging but with obvious marketability.
tspiteri 15y ago
Not exactly the same thing, but this does remind me of a quote from I'm Feeling Lucky: The Confessions of Google Employee Number 59: "I didn't trust Larry and Sergey as coders," said Craig Silverstein. "I had to deal with their legacy code from the Stanford days and it had a lot of problems. They're research coders: more interested in writing code that works than code that's maintainable." According to Jeff, one of the quirks in the early Stanford version of Google was that when something unusual happened the program would print out an error message without any explanation. The message read simply, "Whoa, horsey!"
- aangjie 15y ago
  7 years ago i would have called myself similar.Though i was just graduating and could have hardly called it research. But 3 years working in the industry with Big blue and i see i have got OCD with maintainability. Heck, i wouldn't even have noticed, if i hadn't quit and went to do a master's. But 4 years since, and i still haven't quite undone the OCD, mitigated yes, but not back to the get shit done passion....I keep working on it...so, i will qualify that 6 months to start a startup, with something about the type of product you aim to build. - May be something along the lines of the impact you expect to make with it.
enko 15y ago
> Which brings to mind patio11's constant reminders, that running a successful software business has very very little to do with programming well That may be appropriate for patio11. Not to demean the guy but let's be clear, he runs an online bingo service. It's my understanding that he makes much more money from consulting gigs leveraged from this modest endeavour. Rest assured that if your ambition is to write the next Dropbox or, hell, any YC company, at least 50% of your founding team will need to be very good programmers indeed.
- jcarden 15y ago
  What does "good" really mean here ?
- tptacek 15y ago
  In one of his three (3) lines of actual- money- earning- businesses, he managed to factor the "product programming" component down to a kind of minima, allowing him to channel all his effort into engineering his marketing systems. As a result, he was able to use a program that can charitably be described as "Hello World" hooked up to a random number generate to eclipse his full time salary. If you can't see the pure hack value in that, you may be commenting on the wrong message board. The conclusion you think you can draw about Patrick and "programming" from the nature of his first product: you can't draw that conclusion. I'm writing this not to offend Patrick (he could care less about threads like this), but because you are taking exactly the wrong lesson about what Patrick did and then broadcasting it to the rest of the community. Stop, please? :| I'm a systems programmer, since 1995. The list of YC companies that involve "real programming" to me is pretty short. Dropbox qualifies, but how many from the rest of their class would? Which is to say: "technical impressiveness is both subjective and a stupid metric for a business".
  - deleted 15y ago
    [deleted]

ofca 15y ago

I am also fueled by his answer here. I guess that learning parameter depends on your teacher - the better the teacher, the better and faster you learn. I just started learning HTML, CSS, jQ, PHP recently , and I found myself advancing at surprisingly high pace (now watching jQ new_boston tutorials on youtube). Main problem for me is finding good material to learn from, since I only learn from the internet. You have any advice considering good online sources for a total beginner to learn coding really well ?

wallawe 15y ago
http://www.w3schools.com http://www.w3schools.com is pretty informative if you haven't already checked that out. The best thing to do, especially if you are on a budget is spend a few hours in a bookstore each week reading over various books on various subjects. I found this a lot more helpful.
- barry-cotter 15y ago
  I would recommend htmldog.com above w3schools for HTML and CSS. For javascript eloquentjavascript.net is good, and sqlzoo.net is good for SQL (or so I have heard). No doubt there are also some spectacular books for all of these. Please reply with recommendations.
  - nzonbi 15y ago
    In my opinion, developer.mozilla.org has the best online documentation on common web technologies for programmers.
- sadlyNess 15y ago
  Well, if you look at w3schools, you might want to look at w3fools.com first. It is a criticism of w3schools and recommends htmldog and dev.opera among others.
chernevik 15y ago
It has taken me considerably longer than a year. But I might not be smart. And I've tried to do it on my own, rather than taking a job (see prior sentence). Caveat: I'm not a developer, so my comments about learning how to program should be taken with considerable skepticism. But I have some opinions based my effort to learn. For me, programming syntax is less a problem for me than poorly organized code, poor grasp of problems and poorly thought out solutions. Design is a subtle and important topic that does not lend itself to the shorter coverage typical of internet material. Book-length immersion in the concepts is only a beginning to an understanding. So I think your "internet only" restriction is a severe constraint. But it isn't as if there are many design books for beginners. These generally target people who've mastered some languages and know the design-problem space. "Pragmatic Programmer" was a big help. I have found test-driven development an enormous help. It feels cumbersome, but you always know what problem you're trying to solve. "Test Driven JavaScript Development", Johansen, is an excellent overview of the approach. I'm also trying to work through Beck's "Test Driven Development By Example" doing the exercises in Ruby, but it's a side project that hasn't gotten much attention. I repeat: I'm not a developer. Hopefully this is thought-provoking, but I'm no authority.

crgt 15y ago

I've been inspired by Gladwell's more general answer from the book Outliers: "Gladwell repeatedly mentions the "10,000-Hour Rule", claiming that the key to success in any field is, to a large extent, a matter of practicing a specific task for a total of around 10,000 hours." http://en.wikipedia.org/wiki/Outliers_(book) http://en.wikipedia.org/wiki/Outliers_(book) At an average of 50 hrs/week this means it would take you close to 4 years to achieve mastery. pg is certainly correct that you can be productive before this point, but I do believe mastery is much less a function of calendar time, and much more a function of how many coding hours you can get under your belt as the days fly by.

kragen 15y ago
Like most of Gladwell's ideas, it falls apart under the least examination. Consider a neurosurgeon. Perhaps after ten thousand hours of surgery she was an expert in surgery. But perhaps only a quarter of that time was spent performing neurosurgery. Does that mean she's not an expert neurosurgeon? Perhaps, then, after ten thousand hours of neurosurgery she has become an expert neurosurgeon. But maybe only 5% of that time consisted of excising glioblastomas from the anterior cingulate cortex. Does she need to spend ten thousand hours doing ACC glioblastomectomies in order to be an expert at that task? In short, because what we normally mean by "tasks" or "fields" can be broken down into smaller tasks or fields, the statement is self-contradictory if they mean what they normally means. But if we search for a definition of "task" that makes the statement true, we can trivially find a circular one: a "field" is something that a talented person can achieve mastery of in about ten thousand hours of practice. Once reformulated that way, it becomes clear that this is not a statement about human expertise or expert performance, but about the economic structure of current society, and in particular our degree of specialization: most people (within the professional class Gladwell finds interesting, anyway) work in jobs that require about ten thousand hours of focused practice by a talented person to reach mastery. (I should point out that this occurred to me when I saw Jeff Fox (RIP: http://groups.google.com/group/comp.lang.forth/browse_thread/thread/622263caccba35b5 http://groups.google.com/group/comp.lang.forth/browse_thread...) claiming that the research Gladwell summarized meant that you needed about ten thousand hours of programming in Forth to be good at programming in Forth, so you shouldn't put too much stock in the opinions of experienced programmers who didn't have much Forth experience.) Once stated this way, we can formulate interesting hypotheses about the cause: perhaps when a field starts to require substantially more than ten thousand hours of practice to master it, its practitioners start to specialize in a part of it, so that they can reach mastery sooner.

dforeman 15y ago

I think that question was included ironically- I.e., he's only been asked a handful of times. His sample size reflects the dearth of "learning how to program to build a viable webapp" stories and comments here. I don't even know if noob questions are accepted here- I've never seen one. I don't post them because I feel I should be finding answers on google rather than degrading the quality of this board. The decision to learn enough programming to build what I want stemmed from the realization that understanding how my webapp will work at the technical level significantly refines my vision for the product- bringing it much closer to reality. Whereas before I was talking to recommendation engine people because I wanted "recommendation features like Hunch," now I'm working in PHP/SQL and getting exactly what I want. My current strategy is to talk to the CTO's and creators of similar webapps to understand their technology and language choices (e.g. GAE or MAMP, SQL or Solr), go as far as I can on my own, and then work with a tutor for an hour or two to get momentum and correct my architecture mistakes.