DR: If you can develop your startup's "product" without writing any code, then writing said code anyway would be a distraction.
The author gives a couple examples of startups that started off with a Google spreadsheet or an e-mail list. If that doesn't sound like your tech startup, well, then programmers will be kind of important.
The title is a little bit of hyperbole, and I know this is going to get a lot of comments saying things like "this is fucking stupid", but this is actually pretty insightful. Building stuff before you know you're building something somebody needs/wants is very risky and can be a total money/time/attention sink. To the extent that it's possible, it IS a good idea to try and validate the product idea BEFORE writing code.
If we've made one big mistake at Fogbeam over the years, I'd actually say that it's building too much of the actual product, instead of using mockups and dummied-up demos and what-not just to test the demand for the concept. Early on I had a lot of mindset of "We need to build a fair amount of this, so we can show it to people, so we can find out if they need/want it or not". But honestly, we could have done wireframes, mocks, backend-less demos that were totally dummied up, etc, just to test the concept in front of potential customers.
So yeah, I'd say, don't get too caught up in the headline, but read the article and really think about what the author is saying. IMO, there is some valuable truth here.
If you write as little code as possible you would still do it wrong. A working prototype won't follow DRY, etc.. So mostly it will end up with more lines than a good prototype would be.
I mean nobody is perfect, some design decisions are mostly wrong at the first days, but that doesn't change anything, as long as you can keep running and that's what running at scale means. Drive a car with 140 km/h and replace all parts while driving.
I'll offer a counter-thought to the carping about how stupid this is, the ad hominem attacks, etc.
The author is correct, at least for some ideas and some founders.
The author also points out several successful products that grew from decidedly low-tech, sub-optimal incarnations.
Technologists - and I consider myself a recovering technologist - are often distracted by the shiny, by the optimal, by the novel. Sometimes a product is a functional but ugly hack of adequate pieces assembled to prove whether or not an idea works, and, with a few very rare exceptions, is or should never be, at least not out of the gate, optimal.
Sometimes technologists have cool ideas they build out into eventual products that once in a while become the core of a business. That can be a very long cycle.
Business guys just keep doing business, much to the consternation of many of us tech guys.
Product people talk to users, spend money on surveys, hack shit together, and see if things work, if ideas stick.
Are we still fans of "fail fast" on HN? I haven't kept up. If you want to fail fast, do it for cheap, and do it low tech.
> The author also points out several successful products that grew from decidedly low-tech, sub-optimal incarnations.
I don't know if I would call Google spreadsheets low-tech and sub-optimal. It isn't very well optimized but it hits all of the important points for a prototype, cheap, scalable and high uptime.
I totally agree though, the idea that you shouldn't get distracted by the implementation you dream of is very solid and one that is purported as important here all the time (just phrased differently).
I think PeterWhittaker is saying that Nomad List's version that was running on Google Spreadsheet was a suboptimal one (a prototype if you prefer). It doesn't mean that Google spreadsheets is low-tech or suboptimal (it's not).
While the phrasing seems to be insulting to the demographic that this site cares too, I don't think he is wrong fundamentally. Also note that he is specifically talking about programmers doing actual work, not consulting/discussing ideas with programmers. Asking whether this platform idea could ever work is great, getting someone to write a website that gives you X, Y and Z features before you know whether those features are core is bad.
Put another way, he is saying to focus on prototyping in the most lean way possible. If Google spreadsheets can work to try out your idea, hiring a programmer is certainly not something to do before you have tried out your idea on the stable, free, always available platform.
And honestly the underlying idea might not be too far off for more technical minded problems. Figure out what your product is, then build stuff around it. More failures than can be counted are centered around technology that didn't work out and more importantly wasn't required for the core product.
It isn't that programming isn't important, it is the usual lean mindset, until you have a good idea of what your product is supposed to be, having a programmer working on structure for it is at best overly eager, at worst a complete waste of time.
You know what I consider a distraction? Fucking electrons. Seriously. Half the time, they seem to be killing people. You know that people who do nothing wrong sometimes get killed by electricity that comes from the fucking sky, like out of nowhere? It's like these prima donna electrons want to obey fundamental forces instead of build products!
We should seriously consider an electron-free lifestyle. I don't mean that we swear off electricity. I'm saying that we get rid of all of fucking chemistry (which is dominated by interactions of outermost electrons of atoms). It's a fucking distraction. We don't need it. Sure, our brains will need to use a different fundamental particle for neurons to signal each other with, and we'll have to evolve an exotic chemistry to replace our current composition, but you hear about pentaquarks every day. It can't be that hard, with all the modern science... oh, wait.
It's true that you shouldn't write any code before you have some sort of backing design planned. However, the role of a programmer is similarly important, even in the design phase. If you're making anything that has to do with computers, a programmer is usually the one who will tell you what is or isn't possible. That's important, no?
This piece of advice is either inadvisable or just poorly written. IMO: Design, prototype, clean up. If you can do that without a programmer, cool. But chances are that you'll need one, either to tell you that you're wrong, or to tell you how to do it better. Code isn't the only thing programmers produce.
This article was brought to you by "Tech Lead at SmartHires (YC S14)" apparently.
It should be noted that the contrarian article title ("Programmers are distraction for your startup") is deliberate, which is why there are so many comments in response. It's a linkbait title with plausible deniability.
Also a note to people who write blog article with such titles: HN has a flame war detector. It's not a smart idea.
Strongly disagree. If you have a really good idea and you start to attract users,youshoulddefinetely start coding. Otherwise, someone can launch a product and that users will start to use that product.
I think a lot of people don't get the idea of a tight startup. Most comments refer to the old lean aproaches. In a lean startup you would build an MVP and you might need programmers for that. The tight approach proves the business and innovation without actually knowing the product. Please refer to http://www.tightstartup.com. It is totally obvious that programmers are a distraction for a tight startup (in most cases).
20 comments
[ 3.2 ms ] story [ 50.9 ms ] threadThe author gives a couple examples of startups that started off with a Google spreadsheet or an e-mail list. If that doesn't sound like your tech startup, well, then programmers will be kind of important.
If we've made one big mistake at Fogbeam over the years, I'd actually say that it's building too much of the actual product, instead of using mockups and dummied-up demos and what-not just to test the demand for the concept. Early on I had a lot of mindset of "We need to build a fair amount of this, so we can show it to people, so we can find out if they need/want it or not". But honestly, we could have done wireframes, mocks, backend-less demos that were totally dummied up, etc, just to test the concept in front of potential customers.
So yeah, I'd say, don't get too caught up in the headline, but read the article and really think about what the author is saying. IMO, there is some valuable truth here.
I mean nobody is perfect, some design decisions are mostly wrong at the first days, but that doesn't change anything, as long as you can keep running and that's what running at scale means. Drive a car with 140 km/h and replace all parts while driving.
The author is correct, at least for some ideas and some founders.
The author also points out several successful products that grew from decidedly low-tech, sub-optimal incarnations.
Technologists - and I consider myself a recovering technologist - are often distracted by the shiny, by the optimal, by the novel. Sometimes a product is a functional but ugly hack of adequate pieces assembled to prove whether or not an idea works, and, with a few very rare exceptions, is or should never be, at least not out of the gate, optimal.
Sometimes technologists have cool ideas they build out into eventual products that once in a while become the core of a business. That can be a very long cycle.
Business guys just keep doing business, much to the consternation of many of us tech guys.
Product people talk to users, spend money on surveys, hack shit together, and see if things work, if ideas stick.
Are we still fans of "fail fast" on HN? I haven't kept up. If you want to fail fast, do it for cheap, and do it low tech.
IM(NS)HO, of course. YMMV.
I don't know if I would call Google spreadsheets low-tech and sub-optimal. It isn't very well optimized but it hits all of the important points for a prototype, cheap, scalable and high uptime.
I totally agree though, the idea that you shouldn't get distracted by the implementation you dream of is very solid and one that is purported as important here all the time (just phrased differently).
Put another way, he is saying to focus on prototyping in the most lean way possible. If Google spreadsheets can work to try out your idea, hiring a programmer is certainly not something to do before you have tried out your idea on the stable, free, always available platform.
And honestly the underlying idea might not be too far off for more technical minded problems. Figure out what your product is, then build stuff around it. More failures than can be counted are centered around technology that didn't work out and more importantly wasn't required for the core product.
It isn't that programming isn't important, it is the usual lean mindset, until you have a good idea of what your product is supposed to be, having a programmer working on structure for it is at best overly eager, at worst a complete waste of time.
We should seriously consider an electron-free lifestyle. I don't mean that we swear off electricity. I'm saying that we get rid of all of fucking chemistry (which is dominated by interactions of outermost electrons of atoms). It's a fucking distraction. We don't need it. Sure, our brains will need to use a different fundamental particle for neurons to signal each other with, and we'll have to evolve an exotic chemistry to replace our current composition, but you hear about pentaquarks every day. It can't be that hard, with all the modern science... oh, wait.
This piece of advice is either inadvisable or just poorly written. IMO: Design, prototype, clean up. If you can do that without a programmer, cool. But chances are that you'll need one, either to tell you that you're wrong, or to tell you how to do it better. Code isn't the only thing programmers produce.
This article was brought to you by "Tech Lead at SmartHires (YC S14)" apparently.
Also a note to people who write blog article with such titles: HN has a flame war detector. It's not a smart idea.
My experience with such companies is that their focus is on office decoration, rather then the product.
If you are not the engineer type, make sure you hire three of those to make up for it. :P
"Hey, we are 5 business guys with an idea and need you to build it!"