If you apply to any job without having at least one other person proof it, you're insane.
But then it is no longer a fair assessment of good a CV you can write.
No, but nobody else's is either.
Although the quality of writing on a CV today may no longer indicate how effectively an applicant can write, a poorly written one nonetheless sends a message that the individual behind it is unconcerned with getting the details right and willing to cut corners (such as skipping the expected step of having a 3rd party proof their CV).
Of course, I know how to read and write. That didn't help me keep the jobs, of course, because firing people for no reason (see the recent AOL story for an example) apparently doesn't require competency with the written word.
A touch bitter, eh? Well, it gets worse. Getting fired generally comes down to (1) your choice of employers, or (2) you. Arguably, your choice of employers in and of itself reflects on you, making the core issue in job retention... well, you.
Working for a company such as AOL -- large enough that the CEO can say "fire N people" without knowing each of those N people whom he's dismissing -- is arguably a mistake. Working for a small company under management that doesn't care about their employees is a mistake, too. Publicly blaming anyone but yourself for your problems -- any kind of problems -- is likewise a mistake, because it's less than endearing to those who care about personal responsibility. I don't know you beyond what you've posted here on Slashdot, but the responsibility-disclaiming attitude present in your posts has gotten on my nerves -- and I'm senior tech staff, involved in hiring decisions. (And yes -- I've been fired too, even by places for which I did good work. Nonetheless, it was my fault every time, and I've taken steps not to make the same mistakes again)
Stop blaming other people, and look at what you can do yourself to improve your own lot in life. It's one heckuva lot more effective, and less annoying to the bystanders.
The fact that you, someone with no knowledge of the situation, were able to do that rewrite suggests that the email was indeed "readable" despite its poor gramatical construction.
For some minimal value of "readable".
Folks who know how to speed read are more effective when reading content which is clearly written. Forcing your reader to expend effort to interpret something that should come naturally to them (presuming that they're a sufficiently proficient reader) is severely unkind.
Further, folks who fail to expend that effort or who have insufficient context may interpret the intended message incorrectly -- potentially far worse than no communication at all.
On the other hand, if the intended recipient is "careless", and by "careless" you really mean lazy or too busy to write in complete sentences, but the intended recipient still understands the message then who cares?
The recipient, for one.
I may be able to interpret poorly written English, but that's not to say it's enjoyable. Presentation errors not only make the individual committing them look bad, but also take away focus from the actual content.
I expect people communicating with me in a business context to make a reasonable effort to communicate clearly in much the same way that I would be offended if a coworker chose to give me messages scribbled in sloppily written crayon: Poor presentation distracts from the content. The scribbled memo would needlessly require extra time to read and interpret; likewise do poorly spelled messages.
Another aspect that falls out of the above is one of respect. Since comprehending sloppily-written messages takes more time and effort, writing well is nothing less than displaying respect for the value of the time of one's readers, whereas writing poorly is stating that your time and effort is more valuable than that of the individual to whom you send your message. I make a serious effort to do this when writing material for others' consumption; consequently, I find it only reasonable for others to respond in kind.
Thankfully those silly social norms have not yet been applied to emails yet.
They should and do. People who send poorly written email (particularly mass mailings) are genuinely and rightly offensive, for all the reasons above.
You know that GPG keys are identified and signed by their MD5 hashes? Suppose that I can generate a GPG key that would be identified as yours, and distributed it.
Finding a collision is one thing. Finding a collision that happens to be a member of a valid GPG keypair is quite another. (IOW: Let's say you came up with a valid public key that has the same md5sum -- that doesn't net you a private key that matches it, or a way to make one).
And humans have no purpose or intent -- our purpose is only to behave in a manner consistant with the physical laws that govern the behaviour of our component parts.
Right?
You also forget that the fitter generally crowds out the less-fit when fighting for limited resources (which is traditionally the case).
I'm not going to argue on the topic (google can find plenty of statistically-backed arguments better than those I could make off the top of my head), but I'm curious:
Do you have different nicks to use when posting on controvercial topics?
My current employer uses and contributes to open source software, although we're a proprietary software company -- using OSS tools for infrastructure functions saves us money, and contributing back reduces our software maintenance costs. My last employer is a member of the above list. They survived the bust, and I've heard rumors that they've started turning a profit.
Coming from this background, I didn't find this article suprising at all. There's plenty of money in OSS, as long as you're smart about making it.
If there's some GPL'd code available that does everything a company needs, then they can just reduce the programming staff.
Yup. Most people consider reducing cost centers to be a Good Thing.
If not, why would they GPL their own internal development so that their competitors can save money on their own staff?
So that they can save money on maintenanace, of course. My company uses a GPLed, 3rd-party VPN solution, and some GPLed 3rd-party software to make it easier to use. We made our own modifications. If we wanted, we could have kept those to ourselves (since the GPL only requires us to distribute our modified source to the people we distribute the binaries to, and the source stays internal). That would be stupid, though: It'd mean that every time a new upstream version came out, we'd need to port our patches up to play with it. That gets expensive -- especially if you're hiring someone like Timesys to do it for you. (Additionally, since we submitted our patches upstream [except for some very small changes we're keeping in-house] we've had 3rd-party bugfixes and improvements submitted; if we'd kept our patches to ourselves, we'd still have these bugs).
The idea that a world where all software is licensed under the GPL is not going to negatively impact the economics of the programming profession is very difficult to believe.
The idea that the economics of the programming profession aren't going to change dramatically anyhow is pretty damn hard to believe, too.
I loved the Demotivators poster on consulting: "If you aren't part of the solution, there's good money to be made in prolonging the problem". Sure, that money spent prolonging the problem (of expensive maintenance of internal infrastructure code) is going to go away in part -- but I'm part of the solution, thank you much, and screw 'yall if you can't keep up.
Despite the clearly stated beliefs of the leaders of these two movements, the terms "Open Source" and "Free" software are often used interchangably and I'm guilty of doing so here.
Given the extent to which you claim to pride yourself on correctness, I'd hope that you'd stop that.
I don't believe there is any ethical difference between Open, "Free" or Closed software.
...thus excluding you from the Free Software movement but leaving you quite welcome in the Open Source crowd, or of course the proprietary world.
But you don't know what your competitors are going to do, so the smart move is to not release your source code.
Irrelevant. You're fighting a strawman, not the position I actually take.
As I said in black and white: I don't think that releasing one's core product as open source necessarily makes sense, but that releasing infrastructure not tied to one's competitive advantages is The Right Thing. Releasing code for our core product would be a needless risk[1], but we're not doing that -- there's no reason to! Releasing code for infrastructure components that have nothing to do with our core business makes great sense, though, because it cuts software maintenance costs. This is all by-the-book, if you go read ESR.
[1] - Although, for the reasons mentioned in this thread, I'd argue a fairly minimal risk; building something not innovative or different and trying to compete with us would be hard for the reasons I mentioned before: Staff, knowledge (of both the product and the domain in general), business connections, and so forth.
Once they start making exceptions they lose the "higher moral ground" they believe exists.
You're conflating the open source crowd with the Free Software crowd.
The Free Software crowd believes that all software should be Free because anything else is morally corrupt. The Open Source crowd believes that open source should be used in a wide variety of (but not necessarily all) situations because it's economically and technically advantageous. Read ESR's essays to see the Open Source perspective; read the FSF's documents to see the Free Software perspective.
Releasing your source code will make it more likely that your competitors business plan will pass the ROI test.
If their business plan is building a cheap knockoff of your product that you could build and market more cheaply (because you already have the technical staff, knowledge, business connections, etc. in place), sure. If their business plan is building something innovative and different, it's less likely that they'll be able to pull that off.
That said, I'm a member of the Open Source crowd, not the Free Software crowd. I don't think that releasing one's core product as open source necessarily makes sense, but that releasing infrastructure not tied to one's competitive advantages is The Right Thing. If you've met folks who claim to represent the open source movement but say differently, they're actually Free Software zealots in disguise.
Read the papers by each organization, and see for yourself where they stand.
Entering a market where financially stronger competitors can match your product feature-for-feature in six months doesn't sound like the path to success.
There aren't all that many markets where that isn't true. Microsoft, IBM -- they're in a huge number of markets, and have enough resources that they can fund a losing project just to gain {market,mind}share if they want to. (And btw, I said eight months, not six, for the code. Eight is pushing it, hard. Six is simply impossible if there's going to be any kind of QA cycle whatsoever).
SLOCcount estimates that our code would take 38 developers 3.4 years to write, at a cost above $17 million. A "dream team" with past experience writing similar software, given the ability to poke at our app (or read detailed specs written by someone who did) and access to a well-written (architected and implemented to be truly reusable) codebase with all the basic (non-competitive-edge) features already implemented could get to where we are (while avoiding our user-visible mistakes and misfeatures) in 8 months. (The non-competitive-edge features, like the others, aren't algorithmically difficult -- but like all code, they take time to write and time to QA and time to integrate with the rest of the system and, when appropriate, to integrate with outside products and systems). Said team and code would, of course, also cost a lot more (but for at least some of our larger competitors, they've probably already sunk a good chunk of the involved costs). Likewise, they could afford to buy technologies we've had to build in-house. Nothing I've discussed above is difficult -- just time-consuming, and thus expensive.
Given that our competitors have that kind of money, and have access to preexisting codebases (albiet, given that this is the real world, probably not architected and implemented for effective reuse without some work) -- yes, they can implement our software's features if they set their hearts on it. Thing is, reproducing our features won't give them our product, which is more than just a bunch of code, in a timeframe even remotely approaching the above. The code we've managed to rewrite ground-up in about two years of near-solid crunch time (after we brought on a dev lead who fired the bad coders and threatened everyone else with a baseball bat until they started writing unit tests), but the data it operates on has been in development for over five years and can only really be created by a team of competant MDs with good taste, who are in general considerably more expensive and hard to come by than coders. We pay ours in equity and in the excitement of being part of building a product with potential to substantially impact their field (our CEO, a MD himself, is very good at imparting this excitement). I'd be suprised if our larger competitors could reach similar arrangements -- and even if they could, that's years of development time for the data. (I haven't mentioned the artwork yet -- suffice to say that there's a lot of it, and we have a graphics artist who puts out simply amazing work at a rate more consistent with a team of four or five).
But then, our competitors can hire graphics artists; let's say they also manage to fork out the cash and hire a team of MDs five or so times larger than ours (and a team of pharmacists -- they actually make up more of our company than any other group -- though they might just decide to buy rather than build the pharmaceutical data). They might be able to get done in a year -- but suddenly, they're not just spending real money; they're spending lots of real money, but the lion's share of the expendatures are on something having nothing to do with development of the code itself!
So... if these financially stronger competitors decide they want our product's capabilities enough to throw real money (which we don't have) at it... why not buy us? That makes us happy (particularly those of us who've been around for a while and own a lot of stock) and makes them happy (because they get a pro
...I take considerable comfort in being absolutely correct.
Understandably so.
In any case, I find the argument that the source code isn't needed to be a strange one for open source advocates to make.
You're oversimplifying a bit. The argument here is that observing an app's user-visible design is generally sufficient for a well-funded and determined opponent to reproduce it. However, frequently the value of using OSS components is in the ability to make small modifications or fixes -- in short, to produce not a rewrite (in which case the source of the original is often more a hindrance than a help) but a lightly modified version which has had some needed bugfix or feature enhancement -- a case where source access is generally critical.
With this distinction made, perhaps the positions no longer seem so contradictory?
(As an aside: I work for a company building a piece of specialized closed-source application software -- but we use and contribute to a number of open-source projects which aren't directly relevant to our core business, and considerably reduce our costs by doing so).
I find the "exception that proves the rule" argument to be one the dumbest ever (no offense).
None taken, I used to think that too. It's a fairly subtle argument to appreciate -- on face value, it's certainly absurd.
Roughly, in this context, it expands out to something akin to the following: "If you had to pick something which as much of a fringe element as [FOO] to find an exception to the rule which I'm trying to assert, then the rule presumably holds for more common cases".
The point is that the post I was responding to stated that competent programmers "can replicate every single feature..." so finding a single case where it's not true blows that argument away.
Yes, the parent post was obviously hyperbole. Trying to determine whether the parent's argument is factually true in all cases (as opposed to true in most cases) is simply pedentry as far as I'm concerned -- arguing over the corner cases while it's the common cases that are interesting.
but in doing so you have to admit that there are cases where closed source makes better sense.
My understanding was that this discussion was with regard to the extent to which competitive advantages in general (covering both those based on better underlying algorithms and those based on better design requirements) can be reasonably maintained by closed-source software in a competitive environment. I've scanned the parent posts several levels back, and you're the first to mention anything about which model "makes better sense". That's a separate discussion, and one that's liable to involve less light and more heat; consequently, let's resolve the first issue, and leave the other for later.
Okay, "can be trivially created, given a well-funded development team".
Happy?
My employer is a late-stage startup with a commercial software product targeted at a quite large and lucerative market which is only now starting to see real penetration. We have a damn good product. We worked a long time to get it that way.
We're under no illusions that our competitors couldn't recreate our code in 1/4 the time. Thing is, it's not just the code that makes us competitive -- we *assume* the competitors will figure out how all our nifty bits work, or buy an off-the-shelf implementation of parts we did in-house, and so forth. Because we're not relying on difficulty of reproducing our software as a competitive edge, we'll be in much better shape after its best features do get reproduced by our competitors (which they will, after we do a general release, because they're so damn much better than what's out there right now, and our competitors have the cash to hire the folks they need, whereas we've been operating on a shoestring).
Sure, it'll take some money and manpower, but to the kinds of people who are angling for this market, throwing a 150-person team (including management and support staff) at the problem for 8 months is indeed trivial. Counting on competitors being unable to reproduce our features is a sure way to fail.
Speech recognition is a special case. Very little commercial software involves algorithmically difficult problems; you're picking at one of the quite few exceptions.
I work at a startup making a piece of commercial software in a fast-growing market with quite low penetration. Our product is arguably best available except for maturity issues -- yet the only "secret sauce" we have that our larger competitors couldn't easily recreate isn't code or algorithms at all, but data!
Know the "exception that proves the rule" bit? Speech recognition is one of those.
Oh, bullshit. There are good coders and there are bad coders -- give them the same tasks, and one will get a solution of suitable quality completed in less time than the other. That might be because one of them has better design sense, or pays more attention to detail, or whatever else -- but Coder A still gets the project finished quickly while Coder B goes over deadline and comes up with a flaky half-solution. Hence, productivity.
Working in post-boom startups (which I've been doing since the crash), one doesn't have the whole universally massively clueless management thing -- if more than just one or two members of management are clueless, the company goes under. It's results that get product finished, and product that gets funding. Consequently, the kind of mediocrity and related bullshit you refer to doesn't survive (except on a quite small scale), because it can't.
If your work environment sucks, go find one that doesn't -- they're out there. If they aren't, perhaps it's you and not the environment that needs adjusting.
And when did the guy who was five times more productive actually get paid five times more anyway?
When he was paid by number of finished pieces.
Re:There's a preventive vaccine already
on
HIV Vaccine
·
· Score: 1
what is to prevent the bonobo's actions from being part of the error (and by extension, all of mankind's sexual perversions from being part of the error as well, since they all showed up long after we gained enough intelligence to start messing with evolution of our own species by growing food and letting the weak survive)?
Well... theory would be that errors generally don't propagate far (unless they're paired with other mutations sufficiently beneficial as to make up for the decrease in survivability they cause -- a pretty likely thing, since effects of genetic changes tend to clump). That exception being a large enough one to drive a tanker truck through, I thus cede the point.
('Twas an interesting discussion; I hope you think likewise).
I take it you mean they pump out 100x more lines of code than another person.
Not necessarily. A very good programmer can find elegant, simple solutions to a problem that a bad programmer would try to solve via brute-force. Compound this with the very good programmer doing it right the first time and needing vastly less debugging/QA time, and you've got a massive difference in overall productivity.
I've worked with a fellow who could look at a white paper and churn out a graphics driver inside a few hours -- such that the driver would actually work the first time in about 80% of cases. I heard a year later that he was taking contracts doing kernel work for major corporations (he was the MIPS and SH Linux kernel maintainer, so getting such contracts wouldn't have been a problem for him) and finishing multi-month contracts in mere hours. I've also worked with a fellow who used hundreds of thousands of lines of code (almost all machine-generated) and six months of his time to do what could have taken a moderately competant programmer (me) just two weeks and about 3-6 klocs. And I've worked with plenty of folks between. (And then you've got the folks whose designs reinvent the wheel and involve months of extra development for functionality they could have just reused).
I've also seen projects where one person has implemented in about a year better functionality than a 10-person team over a 5-year period, simply on account of that one person having vastly better design sense.
The productivity (not LOCs, but actual project-completion-time productivity) difference between very very good coders and average coders is certainly huge enough to justify the "100x" generalization -- if not entirely correct, it's certainly on the right order of magnitude.
Slashdot Mirror
Although the quality of writing on a CV today may no longer indicate how effectively an applicant can write, a poorly written one nonetheless sends a message that the individual behind it is unconcerned with getting the details right and willing to cut corners (such as skipping the expected step of having a 3rd party proof their CV).
Of course, I know how to read and write. That didn't help me keep the jobs, of course, because firing people for no reason (see the recent AOL story for an example) apparently doesn't require competency with the written word.
A touch bitter, eh? Well, it gets worse. Getting fired generally comes down to (1) your choice of employers, or (2) you. Arguably, your choice of employers in and of itself reflects on you, making the core issue in job retention... well, you.
Working for a company such as AOL -- large enough that the CEO can say "fire N people" without knowing each of those N people whom he's dismissing -- is arguably a mistake. Working for a small company under management that doesn't care about their employees is a mistake, too. Publicly blaming anyone but yourself for your problems -- any kind of problems -- is likewise a mistake, because it's less than endearing to those who care about personal responsibility. I don't know you beyond what you've posted here on Slashdot, but the responsibility-disclaiming attitude present in your posts has gotten on my nerves -- and I'm senior tech staff, involved in hiring decisions. (And yes -- I've been fired too, even by places for which I did good work. Nonetheless, it was my fault every time, and I've taken steps not to make the same mistakes again)
Stop blaming other people, and look at what you can do yourself to improve your own lot in life. It's one heckuva lot more effective, and less annoying to the bystanders.
The fact that you, someone with no knowledge of the situation, were able to do that rewrite suggests that the email was indeed "readable" despite its poor gramatical construction.
For some minimal value of "readable".
Folks who know how to speed read are more effective when reading content which is clearly written. Forcing your reader to expend effort to interpret something that should come naturally to them (presuming that they're a sufficiently proficient reader) is severely unkind.
Further, folks who fail to expend that effort or who have insufficient context may interpret the intended message incorrectly -- potentially far worse than no communication at all.
I may be able to interpret poorly written English, but that's not to say it's enjoyable. Presentation errors not only make the individual committing them look bad, but also take away focus from the actual content.
I expect people communicating with me in a business context to make a reasonable effort to communicate clearly in much the same way that I would be offended if a coworker chose to give me messages scribbled in sloppily written crayon: Poor presentation distracts from the content. The scribbled memo would needlessly require extra time to read and interpret; likewise do poorly spelled messages.
Another aspect that falls out of the above is one of respect. Since comprehending sloppily-written messages takes more time and effort, writing well is nothing less than displaying respect for the value of the time of one's readers, whereas writing poorly is stating that your time and effort is more valuable than that of the individual to whom you send your message. I make a serious effort to do this when writing material for others' consumption; consequently, I find it only reasonable for others to respond in kind.
They should and do. People who send poorly written email (particularly mass mailings) are genuinely and rightly offensive, for all the reasons above.That's a separate issue -- namely, trimming quoted material -- and is relevant whether top or bottom posting is in effect.
You know that GPG keys are identified and signed by their MD5 hashes? Suppose that I can generate a GPG key that would be identified as yours, and distributed it.
Finding a collision is one thing. Finding a collision that happens to be a member of a valid GPG keypair is quite another. (IOW: Let's say you came up with a valid public key that has the same md5sum -- that doesn't net you a private key that matches it, or a way to make one).
It's bad, but not that bad.
And humans have no purpose or intent -- our purpose is only to behave in a manner consistant with the physical laws that govern the behaviour of our component parts.
Right?
You also forget that the fitter generally crowds out the less-fit when fighting for limited resources (which is traditionally the case).
I'm not going to argue on the topic (google can find plenty of statistically-backed arguments better than those I could make off the top of my head), but I'm curious:
Do you have different nicks to use when posting on controvercial topics?
Your assumption that there are plenty of other profitable open source companies is wrong.
Timesys. MontaVista Software. Trolltech. SuSE. IBM's Linux ventures.
My current employer uses and contributes to open source software, although we're a proprietary software company -- using OSS tools for infrastructure functions saves us money, and contributing back reduces our software maintenance costs. My last employer is a member of the above list. They survived the bust, and I've heard rumors that they've started turning a profit.
Coming from this background, I didn't find this article suprising at all. There's plenty of money in OSS, as long as you're smart about making it.
This will be your failure. ... Always use the right tool for the job.
So he only accepts jobs where Linux is the right tool. Problem solved.
Per request, a link.
The idea that a world where all software is licensed under the GPL is not going to negatively impact the economics of the programming profession is very difficult to believe.
The idea that the economics of the programming profession aren't going to change dramatically anyhow is pretty damn hard to believe, too.
I loved the Demotivators poster on consulting: "If you aren't part of the solution, there's good money to be made in prolonging the problem". Sure, that money spent prolonging the problem (of expensive maintenance of internal infrastructure code) is going to go away in part -- but I'm part of the solution, thank you much, and screw 'yall if you can't keep up.
As I said in black and white: I don't think that releasing one's core product as open source necessarily makes sense, but that releasing infrastructure not tied to one's competitive advantages is The Right Thing. Releasing code for our core product would be a needless risk[1], but we're not doing that -- there's no reason to! Releasing code for infrastructure components that have nothing to do with our core business makes great sense, though, because it cuts software maintenance costs. This is all by-the-book, if you go read ESR.
[1] - Although, for the reasons mentioned in this thread, I'd argue a fairly minimal risk; building something not innovative or different and trying to compete with us would be hard for the reasons I mentioned before: Staff, knowledge (of both the product and the domain in general), business connections, and so forth.
The Free Software crowd believes that all software should be Free because anything else is morally corrupt. The Open Source crowd believes that open source should be used in a wide variety of (but not necessarily all) situations because it's economically and technically advantageous. Read ESR's essays to see the Open Source perspective; read the FSF's documents to see the Free Software perspective.
If their business plan is building a cheap knockoff of your product that you could build and market more cheaply (because you already have the technical staff, knowledge, business connections, etc. in place), sure. If their business plan is building something innovative and different, it's less likely that they'll be able to pull that off.That said, I'm a member of the Open Source crowd, not the Free Software crowd. I don't think that releasing one's core product as open source necessarily makes sense, but that releasing infrastructure not tied to one's competitive advantages is The Right Thing. If you've met folks who claim to represent the open source movement but say differently, they're actually Free Software zealots in disguise.
Read the papers by each organization, and see for yourself where they stand.
Entering a market where financially stronger competitors can match your product feature-for-feature in six months doesn't sound like the path to success.
There aren't all that many markets where that isn't true. Microsoft, IBM -- they're in a huge number of markets, and have enough resources that they can fund a losing project just to gain {market,mind}share if they want to. (And btw, I said eight months, not six, for the code. Eight is pushing it, hard. Six is simply impossible if there's going to be any kind of QA cycle whatsoever).
SLOCcount estimates that our code would take 38 developers 3.4 years to write, at a cost above $17 million. A "dream team" with past experience writing similar software, given the ability to poke at our app (or read detailed specs written by someone who did) and access to a well-written (architected and implemented to be truly reusable) codebase with all the basic (non-competitive-edge) features already implemented could get to where we are (while avoiding our user-visible mistakes and misfeatures) in 8 months. (The non-competitive-edge features, like the others, aren't algorithmically difficult -- but like all code, they take time to write and time to QA and time to integrate with the rest of the system and, when appropriate, to integrate with outside products and systems). Said team and code would, of course, also cost a lot more (but for at least some of our larger competitors, they've probably already sunk a good chunk of the involved costs). Likewise, they could afford to buy technologies we've had to build in-house. Nothing I've discussed above is difficult -- just time-consuming, and thus expensive.
Given that our competitors have that kind of money, and have access to preexisting codebases (albiet, given that this is the real world, probably not architected and implemented for effective reuse without some work) -- yes, they can implement our software's features if they set their hearts on it. Thing is, reproducing our features won't give them our product, which is more than just a bunch of code, in a timeframe even remotely approaching the above. The code we've managed to rewrite ground-up in about two years of near-solid crunch time (after we brought on a dev lead who fired the bad coders and threatened everyone else with a baseball bat until they started writing unit tests), but the data it operates on has been in development for over five years and can only really be created by a team of competant MDs with good taste, who are in general considerably more expensive and hard to come by than coders. We pay ours in equity and in the excitement of being part of building a product with potential to substantially impact their field (our CEO, a MD himself, is very good at imparting this excitement). I'd be suprised if our larger competitors could reach similar arrangements -- and even if they could, that's years of development time for the data. (I haven't mentioned the artwork yet -- suffice to say that there's a lot of it, and we have a graphics artist who puts out simply amazing work at a rate more consistent with a team of four or five).
But then, our competitors can hire graphics artists; let's say they also manage to fork out the cash and hire a team of MDs five or so times larger than ours (and a team of pharmacists -- they actually make up more of our company than any other group -- though they might just decide to buy rather than build the pharmaceutical data). They might be able to get done in a year -- but suddenly, they're not just spending real money; they're spending lots of real money, but the lion's share of the expendatures are on something having nothing to do with development of the code itself!
So... if these financially stronger competitors decide they want our product's capabilities enough to throw real money (which we don't have) at it... why not buy us? That makes us happy (particularly those of us who've been around for a while and own a lot of stock) and makes them happy (because they get a pro
With this distinction made, perhaps the positions no longer seem so contradictory?
(As an aside: I work for a company building a piece of specialized closed-source application software -- but we use and contribute to a number of open-source projects which aren't directly relevant to our core business, and considerably reduce our costs by doing so).
Roughly, in this context, it expands out to something akin to the following: "If you had to pick something which as much of a fringe element as [FOO] to find an exception to the rule which I'm trying to assert, then the rule presumably holds for more common cases".
Yes, the parent post was obviously hyperbole. Trying to determine whether the parent's argument is factually true in all cases (as opposed to true in most cases) is simply pedentry as far as I'm concerned -- arguing over the corner cases while it's the common cases that are interesting. My understanding was that this discussion was with regard to the extent to which competitive advantages in general (covering both those based on better underlying algorithms and those based on better design requirements) can be reasonably maintained by closed-source software in a competitive environment. I've scanned the parent posts several levels back, and you're the first to mention anything about which model "makes better sense". That's a separate discussion, and one that's liable to involve less light and more heat; consequently, let's resolve the first issue, and leave the other for later.Okay, "can be trivially created, given a well-funded development team".
Happy?
My employer is a late-stage startup with a commercial software product targeted at a quite large and lucerative market which is only now starting to see real penetration. We have a damn good product. We worked a long time to get it that way.
We're under no illusions that our competitors couldn't recreate our code in 1/4 the time. Thing is, it's not just the code that makes us competitive -- we *assume* the competitors will figure out how all our nifty bits work, or buy an off-the-shelf implementation of parts we did in-house, and so forth. Because we're not relying on difficulty of reproducing our software as a competitive edge, we'll be in much better shape after its best features do get reproduced by our competitors (which they will, after we do a general release, because they're so damn much better than what's out there right now, and our competitors have the cash to hire the folks they need, whereas we've been operating on a shoestring).
Sure, it'll take some money and manpower, but to the kinds of people who are angling for this market, throwing a 150-person team (including management and support staff) at the problem for 8 months is indeed trivial. Counting on competitors being unable to reproduce our features is a sure way to fail.
Speech recognition is a special case. Very little commercial software involves algorithmically difficult problems; you're picking at one of the quite few exceptions.
I work at a startup making a piece of commercial software in a fast-growing market with quite low penetration. Our product is arguably best available except for maturity issues -- yet the only "secret sauce" we have that our larger competitors couldn't easily recreate isn't code or algorithms at all, but data!
Know the "exception that proves the rule" bit? Speech recognition is one of those.
Okay, then.
When he's a contractor paid when he completes his project milestones.
Oh, bullshit. There are good coders and there are bad coders -- give them the same tasks, and one will get a solution of suitable quality completed in less time than the other. That might be because one of them has better design sense, or pays more attention to detail, or whatever else -- but Coder A still gets the project finished quickly while Coder B goes over deadline and comes up with a flaky half-solution. Hence, productivity.
Working in post-boom startups (which I've been doing since the crash), one doesn't have the whole universally massively clueless management thing -- if more than just one or two members of management are clueless, the company goes under. It's results that get product finished, and product that gets funding. Consequently, the kind of mediocrity and related bullshit you refer to doesn't survive (except on a quite small scale), because it can't.
If your work environment sucks, go find one that doesn't -- they're out there. If they aren't, perhaps it's you and not the environment that needs adjusting.
And when did the guy who was five times more productive actually get paid five times more anyway?
When he was paid by number of finished pieces.
what is to prevent the bonobo's actions from being part of the error (and by extension, all of mankind's sexual perversions from being part of the error as well, since they all showed up long after we gained enough intelligence to start messing with evolution of our own species by growing food and letting the weak survive)?
Well... theory would be that errors generally don't propagate far (unless they're paired with other mutations sufficiently beneficial as to make up for the decrease in survivability they cause -- a pretty likely thing, since effects of genetic changes tend to clump). That exception being a large enough one to drive a tanker truck through, I thus cede the point.
('Twas an interesting discussion; I hope you think likewise).
I take it you mean they pump out 100x more lines of code than another person.
Not necessarily. A very good programmer can find elegant, simple solutions to a problem that a bad programmer would try to solve via brute-force. Compound this with the very good programmer doing it right the first time and needing vastly less debugging/QA time, and you've got a massive difference in overall productivity.
I've worked with a fellow who could look at a white paper and churn out a graphics driver inside a few hours -- such that the driver would actually work the first time in about 80% of cases. I heard a year later that he was taking contracts doing kernel work for major corporations (he was the MIPS and SH Linux kernel maintainer, so getting such contracts wouldn't have been a problem for him) and finishing multi-month contracts in mere hours. I've also worked with a fellow who used hundreds of thousands of lines of code (almost all machine-generated) and six months of his time to do what could have taken a moderately competant programmer (me) just two weeks and about 3-6 klocs. And I've worked with plenty of folks between. (And then you've got the folks whose designs reinvent the wheel and involve months of extra development for functionality they could have just reused).
I've also seen projects where one person has implemented in about a year better functionality than a 10-person team over a 5-year period, simply on account of that one person having vastly better design sense.
The productivity (not LOCs, but actual project-completion-time productivity) difference between very very good coders and average coders is certainly huge enough to justify the "100x" generalization -- if not entirely correct, it's certainly on the right order of magnitude.
- Adventure games and RPGs from the 90s and late 80s
- Modern interactive fiction
Both of these do much better at plot, story and humor than what's coming out today.