5 ms·

"Although your product may not be very appealing yet, if you're a startup your programmers will often be way better than the ones your customers have or can hir

"Although your product may not be very appealing yet, if you're a startup your programmers will often be way better than the ones your customers have or can hire." Is this really true? I'm very sceptical. Does anyone have any evidence to back this up?

jplahn 12y ago
I think, by and large, it likely is true. That's not to say that it always holds true and it might be swayed by the strength of programmers in YC, but I think it's definitely correct more often than not. It may also be based on the premise that if you're doing consultingish work, you're probably not doing it for one of the top tech companies, but more likely for a smaller company that doesn't have dedicated developers. From prior experience working at a consulting startup, this tended to be the case more often than not. Obviously, YMMV.
netcan 12y ago
Depends o the customers, but yes generally. This also assumes your customers are the kind that pay for custom code and have coders, which obviously only applies to a subset of startups.
tptacek 12y ago
Even if your customers are software companies, it's often the case that your programmers are better than the programmers that they can deploy to solve the kinds of problems you work on. For instance, if you have a clever solution to sales funnel optimization, chances are that even your savviest software customers aren't in a good position to deploy strong engineers on that problem; they're too busy making the things your customer wants to sell. This is true of a lot of business functions: marketing, sales, recruiting, integration testing, devops, project management, bug tracking, log management, reporting, email. Basically take every product anyone ever sold successfully to tech companies and there's a list of things tech companies aren't good at effectively deploying in-house talent on.
Natsu 12y ago
From what I've seen, "better than average" is a pretty low hurdle to clear. I've seen too much code in production that scares me. For example, have you ever seen someone statically allocate a million element array to hold ~1-2000 6-digit numbers? Did I mention the program had significant memory usage problems? Then again, after looking at that particular mass of 30-year-old goto-loving, copypasta C, maybe I should have been grateful they never once used malloc.
mamcx 12y ago
In the worst case? A startup already have developers, now. Don't forget how hard is to hire. Plus, a lot of custom work in software is not sophisticated. Customer mainly have basic needs (from the POV of software development) but many of them, in disorder. Working for them, is more about have patience ("pls move this 1cm to the left, not right, can you also do X?, no we decide after all don't do that" etc) than the kind of "raw skills" of a uber-developer.
mamcx 12y ago
In the worst case? A startup already have developers, now. Don't forget how hard is to hire. Plus, a lot of custom work in software is not sophisticated. Customer mainly have basic needs (from the POV of software development) but many of them, in disorder. Working for them, is more about have patience ("pls move this 1cm to the left, not right, can you also do X?, no we decide after all don't do that" etc) than the kind of "raw skills" of a uber-developer.
michaelbuckbee 12y ago
It would probably be fair to rephrase it as "specialized" instead of "better". If you're a company making widgets that spends $50,000 a month on Adwords - a startup building Adwords optimization products could likely build you a custom Adwords tool fasther+cheaper than an internal team.
michaelochurch 12y ago
Actually, it's more like this. There are good programmers in the enterprise (meaning, say, investment banks or large corporations or governments) but they generally fall, ambition-wise, into one of three categories: (1) those who want to become managers or software architects (or, in finance, quants and traders) and will define and oversee work but delegate the dirty bits. This would be fixable (they could oversee a team of mediocrities, who'd be grateful just to be employed) but they generally don't have the patience for that. (2) those who want to do highly-theoretical R&D work that doesn't necessarily solve any immediate problems of the business. (3) those who have a specialty (say, deep neural networks) and want to be in the umbrella of a large organization that can protect it. Pull them out of their specialties and they'll try to leave. In other words, these supposedly stodgy non-technology companies do, contrary to stereotype, have good programmers (I've worked in a few) but the ones who are at all decent have career strategies that they expect to be able to implement in their full-time work. They won't work on "just anything" and if you stick them with the random muck that comes from the line of business or zealous "product people", they'll either leave or slack in order to learn new skills on the clock, and the project will be done poorly or even abandoned mid-flight. The appeal of the $3000-per-day consultant is that he'll work on what he's told to do and he doesn't expect you to consider his career needs. He's not going to do a shitty job and leave after 6 months because the people allocating the work don't care about his career; that's what the money (4-6x typical salary) is for. He gets his education and career advancement on his own time and dime (but earns a premium to account for his unpaid work). And while he might not be a great (2.0+) programmer, he's better than anyone in-house who could actually be assigned a bad project without political friction or high departure risk. The average Bay Area startup programmer, like the average software consultant, isn't great; but he's far better than the corporate serfs who get sloshed around on the worst projects. He might be 1.4-1.5; so Goldman's R&D engineers and it top quant-coders will be better, but he's a relative colossus compared to the in-house peons (0.7-1.2) in back-office IT who'd get assigned to grody projects based on internal processes. (Of course, not all the work that consultants do is undesirable. You also have the specialists and those with elite levels of skill. My point is that a "mercenary" consultant will power through the ugly projects for the pot of gold, whereas in-house people expect investment in their careers.) In other words: yes, Goldman can hire great people. But if you want to hire someone great to do a project where 99% of the work is mediocre (and the 1% is extremely careful and requires an expert) you want the $3000/day consultant because Goldman can't get anyone good who's in-house (and not getting a consulting salary) to do the work. One might ask: why don't they pay an internal person $3000 per day, as they would a consultant? The answer is that it'd have him out-earning his boss and they'd often end up promoting someone not on traditional definitions of readiness (increasing scope, leadership) but because he took on an icky project.
InclinedPlane 12y ago
There are a couple factors at play here. First off, the average programmer is, honestly, not very good. The can just barely make anything useful, good luck having it also be well designed and coded, secure, robust, fast, etc. Second, programming is like wizardry to most non-programmers, it's hard enough for a professional software developer to judge another, it's nigh impossible for J. Average Businessperson to do so, even if they have a dire need for software development. In the average case you might have some contract go out which ends up being won by some enterprisey line of business app development house who poops out some horrible cobbled together tool based on Excel, MS Access, and a winform app somewhere in there to glue things together, and then bills the customer for 6 or 7 figures (I'm not even joking). Compared to that, your average startup is the dream team. And what's fantastic about funded startups from the perspective of a software muggle is that not only might they have a product already in existence that you can check out and find reviews from other customers but they've also been given the stamp of approval by investors, investors who are likely far more knowledgeable than the average software consultancy customer. Just look at the Obamacare website debacle as a case in point of how incredibly difficult it is to a: find a quality development shop who can actually deliver what you want, and b: do so within reasonable budget and time constraints. And the difference between finding a good development shop and a poor one isn't merely a better quality product, it's a factor of maybe 2x or more in development time (which is, of course, tremendously valuable) and a factor of 10-100x in cost.

jplahn 12y ago

I think, by and large, it likely is true. That's not to say that it always holds true and it might be swayed by the strength of programmers in YC, but I think it's definitely correct more often than not. It may also be based on the premise that if you're doing consultingish work, you're probably not doing it for one of the top tech companies, but more likely for a smaller company that doesn't have dedicated developers. From prior experience working at a consulting startup, this tended to be the case more often than not. Obviously, YMMV.

netcan 12y ago

Depends o the customers, but yes generally. This also assumes your customers are the kind that pay for custom code and have coders, which obviously only applies to a subset of startups.

tptacek 12y ago

Even if your customers are software companies, it's often the case that your programmers are better than the programmers that they can deploy to solve the kinds of problems you work on. For instance, if you have a clever solution to sales funnel optimization, chances are that even your savviest software customers aren't in a good position to deploy strong engineers on that problem; they're too busy making the things your customer wants to sell. This is true of a lot of business functions: marketing, sales, recruiting, integration testing, devops, project management, bug tracking, log management, reporting, email. Basically take every product anyone ever sold successfully to tech companies and there's a list of things tech companies aren't good at effectively deploying in-house talent on.

Natsu 12y ago

From what I've seen, "better than average" is a pretty low hurdle to clear. I've seen too much code in production that scares me. For example, have you ever seen someone statically allocate a million element array to hold ~1-2000 6-digit numbers? Did I mention the program had significant memory usage problems? Then again, after looking at that particular mass of 30-year-old goto-loving, copypasta C, maybe I should have been grateful they never once used malloc.

mamcx 12y ago

In the worst case? A startup already have developers, now. Don't forget how hard is to hire. Plus, a lot of custom work in software is not sophisticated. Customer mainly have basic needs (from the POV of software development) but many of them, in disorder. Working for them, is more about have patience ("pls move this 1cm to the left, not right, can you also do X?, no we decide after all don't do that" etc) than the kind of "raw skills" of a uber-developer.

mamcx 12y ago

michaelbuckbee 12y ago

It would probably be fair to rephrase it as "specialized" instead of "better". If you're a company making widgets that spends $50,000 a month on Adwords - a startup building Adwords optimization products could likely build you a custom Adwords tool fasther+cheaper than an internal team.

michaelochurch 12y ago

Actually, it's more like this. There are good programmers in the enterprise (meaning, say, investment banks or large corporations or governments) but they generally fall, ambition-wise, into one of three categories: (1) those who want to become managers or software architects (or, in finance, quants and traders) and will define and oversee work but delegate the dirty bits. This would be fixable (they could oversee a team of mediocrities, who'd be grateful just to be employed) but they generally don't have the patience for that. (2) those who want to do highly-theoretical R&D work that doesn't necessarily solve any immediate problems of the business. (3) those who have a specialty (say, deep neural networks) and want to be in the umbrella of a large organization that can protect it. Pull them out of their specialties and they'll try to leave. In other words, these supposedly stodgy non-technology companies do, contrary to stereotype, have good programmers (I've worked in a few) but the ones who are at all decent have career strategies that they expect to be able to implement in their full-time work. They won't work on "just anything" and if you stick them with the random muck that comes from the line of business or zealous "product people", they'll either leave or slack in order to learn new skills on the clock, and the project will be done poorly or even abandoned mid-flight. The appeal of the $3000-per-day consultant is that he'll work on what he's told to do and he doesn't expect you to consider his career needs. He's not going to do a shitty job and leave after 6 months because the people allocating the work don't care about his career; that's what the money (4-6x typical salary) is for. He gets his education and career advancement on his own time and dime (but earns a premium to account for his unpaid work). And while he might not be a great (2.0+) programmer, he's better than anyone in-house who could actually be assigned a bad project without political friction or high departure risk. The average Bay Area startup programmer, like the average software consultant, isn't great; but he's far better than the corporate serfs who get sloshed around on the worst projects. He might be 1.4-1.5; so Goldman's R&D engineers and it top quant-coders will be better, but he's a relative colossus compared to the in-house peons (0.7-1.2) in back-office IT who'd get assigned to grody projects based on internal processes. (Of course, not all the work that consultants do is undesirable. You also have the specialists and those with elite levels of skill. My point is that a "mercenary" consultant will power through the ugly projects for the pot of gold, whereas in-house people expect investment in their careers.) In other words: yes, Goldman can hire great people. But if you want to hire someone great to do a project where 99% of the work is mediocre (and the 1% is extremely careful and requires an expert) you want the $3000/day consultant because Goldman can't get anyone good who's in-house (and not getting a consulting salary) to do the work. One might ask: why don't they pay an internal person $3000 per day, as they would a consultant? The answer is that it'd have him out-earning his boss and they'd often end up promoting someone not on traditional definitions of readiness (increasing scope, leadership) but because he took on an icky project.

InclinedPlane 12y ago

There are a couple factors at play here. First off, the average programmer is, honestly, not very good. The can just barely make anything useful, good luck having it also be well designed and coded, secure, robust, fast, etc. Second, programming is like wizardry to most non-programmers, it's hard enough for a professional software developer to judge another, it's nigh impossible for J. Average Businessperson to do so, even if they have a dire need for software development. In the average case you might have some contract go out which ends up being won by some enterprisey line of business app development house who poops out some horrible cobbled together tool based on Excel, MS Access, and a winform app somewhere in there to glue things together, and then bills the customer for 6 or 7 figures (I'm not even joking). Compared to that, your average startup is the dream team. And what's fantastic about funded startups from the perspective of a software muggle is that not only might they have a product already in existence that you can check out and find reviews from other customers but they've also been given the stamp of approval by investors, investors who are likely far more knowledgeable than the average software consultancy customer. Just look at the Obamacare website debacle as a case in point of how incredibly difficult it is to a: find a quality development shop who can actually deliver what you want, and b: do so within reasonable budget and time constraints. And the difference between finding a good development shop and a poor one isn't merely a better quality product, it's a factor of maybe 2x or more in development time (which is, of course, tremendously valuable) and a factor of 10-100x in cost.