Sure, that's how many stores do operate, but why does a store have to operate that way? Read his account he turned down only about two dozen sales, and some of those kids came back and made purchases later after cleaning up their grades.
If he gets parents' support through his policies, that has potential to result in a net increase of sales -- two dozen transactions isn't that may in the larger scheme of things.
I don't allege conspiracy. I sited a lack of "truthiness" (the quality of sounding true) rather than a lack of truthfulness (the quality of actually being true). I have no information on which to base any claims as to the truthfulness of this news story; truthiness, on the other hand, anyone can judge.
This is coming from state-run media, it doesn't contain enough details for easy independent verification -- and the state has indicated that combating "Internet addiction" is one of its goals.
I ask again: If someone interrupted a discussion on OOP to ask you what a pointer was, would you dignify the question with a response? "Can not" and "will not" are entirely separate things.
I'll answer your pop quiz out-of-band -- phone me at +1.512.394.3516 should you be so inclined. You can be better assured that I'm not cheating under those circumstances, as well, and may provide an opportunity to clear up any miscommunication which might have added to our disagreements. That said, I will not stoop to being quizzed on such rudimentary knowledge in public.
I aced AP econ in high school, and went on to minor in business. Do you ask people with whom you're debating object-oriented design if they can tell you what a pointer is? (And the correlary: if someone asked you that, would you dignify the question with a response?)
See, it looks to me like you're arguing that there's downward pricing pressure impacting the market for American programmers, but I'm taking the position that while that may be true, it's not sufficiently so as to constitute the death of the profession. However, while I'm guessing that that's what you're trying to get at, it's hard to say -- because most of your actual communication consists of claiming that I've stated that older engineers "suck", arguing that working with Python is inherently unlike systems architecture, and inquiring as to my age, rate and skillset (while only making a single economic observation about the data returned -- and that with precious little context).
I'd like to have an intelligent debate -- but that's not going to happen if you have nothing to offer but handwaving, evasion and insults.
What is "this fact"? Which specific data points are you using?
Claiming that some subset of the set of concepts taught in macro economics 101 (which I'm well familiar with) supports your thesis in conjunction with some unstated members of the cloud of data thus far discussed is no argument at all, but merely handwaving. You've made any number of assertions throughout this thread, but have yet to even clarify which one represents the larger point which you suggest should be clear on its face.
It may well be that the overall thrust of your argument is something I don't dispute in the slightest -- but I won't know unless you tell me what it is.
Connect the dots again, please -- I don't understand how you're getting from the data points to the intended conclusion. Adjusting prices to compete with the rest of the world is hardly losing an industry. Losing a monopoly, sure, but that's inevitable.
(Not that I mean to deny the historical existence of a very substantial European software development market, but nonetheless the US has relied quite a bit on having a head start. To be sure, that's going away -- but it doesn't mean the American software industry is dead or even troubled).
that's a starting salary for a very junior BS graduate.
So? It pays for the mortgage and the wife's private school, and that's before the stock component and associated potential future gains. Just because a very junior graduate started at this pay grade seven years ago doesn't mean that that's what the fair market value should forever be fixed at -- and as long as I can keep food on the table and a roof over our heads, I'm fine with that. (It's certainly not starting salary right now; starting salary presently is in the $40-50K range, which is also enough to pay for housing, food and the like -- and thus adequate for anyone motivated by love of the profession rather than the pay). I've got a friend who has said on occasion that he could find me work for much, much more than my current pay -- but I'm working where I am because I like it; the flexibility is significant and I'm doing something important; thus, to the extent that I am working below market value (rather than working in a market with more competition, which -- hey -- legitimately happens), it's by my own choice.
Sure, starting at $40K isn't starting at $80K -- it means that, $DEITY forbid, both members of a two-parent household might need to get jobs! Oh, how horrid! American society has only been moving that way for the last decade or two; it's not like that's anything specific to the field. It might also mean that people might be financially motivated delay parenthood or to stop at one or two kids -- which is a damned good idea anyhow.
Python is a scripting language, not exactly the same thing as software architecture
The media company running their business off a bunch of (Python) code I designed and developed that's encrypting the movies, scheduling the ads their customers see, generating their web presence, managing communication with their DBMS (built around a schema I also developed) and communicating with the dedicated client software on the other end via a protocol I also designed doesn't view Python as "just a scripting language", nor my skillset as excluding architecture and design. Python is "[just] a scripting language" every bit as much as Java is "just an updated Z-machine" or C is "just portable assembler"; it has all the power of any serious conventional language, and attempts to diminish it thus need to be a little more serious than naming it "[just] a scripting language".
try to stop claiming that Senior engineers magically "suck"
...and where exactly did I claim that? I said that all the competent senior engineers I know are either happily employed, retired, or bumming around starting new businesses whenever they so fancy (and, obviously, are sufficiently financially independent as to be able to do so). As for the incompetent ones... well, I've met a lot more incompetent junior engineers than senior ones, and I'd thank you to respond to what I'm actually saying rather than what you'd prefer to think I am.
My larger point is that software development is a fine profession for people who aren't in it for the money. I still hold that this is true, even if the amount of money in the field continues to drop. People can live their lives giving haircuts as a profession; people will damned well be able to make a reasonable living writing software for the foreseeable future.
Between $75-$200/hr for consulting clients (not taking those on right now -- the salaried job eats up all my time), or starting around $65K/yr excluding additional non-cash pay for salaried work. In the latter case, I need to like an employer quite a lot to consider working for them at that rate.
your skill is?
I'm one of the better Python developers I know, a reasonably competent Asterisk admin, a SCM wonk, a sysadminny type, an interface to the open source community (hey, some companies need that!) and a general troubleshooter and geek-of-all-trades. I also do some security design miscellany, some systems design, and quite a bit of other miscellany; once upon a time I maintained a lot of other peoples' C and did a significant amount of packaging, but all that's been some time.
you age is?
Younger than I am old, but no longer quite that young. I'd buy the "old geeks can't find work" argument if I actually knew any old geeks who were competent but unable to find work -- if I did, I know plenty of employers who care more about skill level and getting things done on time than they do about a few gray hairs. That said, the only competent old geeks I know are to the best of my knowledge either happily employed or happily retired or bumming around starting new businesses whenever something strikes their fancy.
So, I've answered your questions... now, what's the point you're trying to make?
That's pure fiction coming from the dot con era....
Then why am I employed and constantly getting job offers, and needing to tell people "sorry, I don't know anyone good who's looking for work I can refer you to"?
From HR conducting interviews to people who are in a job and don't want someone coming in showing them up just being "good" isn't going to cut it in a lot of cases.
Yes, but screw HR at those places. There are plenty of employers out there who don't have their heads up their asses, and they're likely to be better places to work anyhow -- not to mention that companies which get hiring right are ones which are more likely to succeed, all other things being equal. (That said, having good communications skills is part of being good at what you do; if you can communicate effectively and come off as knowledgeable but not overly arrogant, that's going to make you more effective at the parts of your job that involve face-to-face communications... and those are the parts that are harder to outsource, so being good at those things is a win).
I said "there's plenty of work", not "you can have any employer you want". They're different propositions.
Just like a worker who picks fruit, most employers will consider you an interchangeable cog.
That's only true if you're in a big enough company to have interchangeable cogs. My last several years have been startups; anyone with the talent, drive, and complete lack of a family life can work their way into core-staff status. Sure, the whole company can go boom... but them's the breaks, and if that happens your former coworkers will be joining other employers while remembering your name and skillset; in the mean time, there's quite a bit of recognition (and lots of lottery tickets^W^Wstock options) available for the taking.
The best are payed what the merely good used to get, and the merely good get paid what the bottom used to get, and the bottom are gone. Its a race to the bottom.
Mostly true, though the best still make mad phat cash. That said, I'm not the best (I know only one person in that category; he lives in a Tokyo penthouse paid for by his employer) -- I'm merely good, and my present salary is indeed equivalent to starting pay for a full engineer with my old employer during the boom. (That said, this is Austin and that was Sunnyvale; it goes quite a bit further here).
But then... if you're getting to do something you love, and making enough to feed your family, isn't that good enough?
That's what airplanes and local offices full of L-1 visa holders are for.
To be sure -- but all of that is expensive. If you're running a large-enough-scale project, that overhead pays for itself -- but if you have a good enough team (and a tight communications loop with the customer is a force multiplier with respect to "good enough"), you can avoid needing so many people that the overhead costs involved in long-distance project management are balanced out by the per-headcount savings. Remember the whole axiom about the value of a good programmer scaling at a higher rate than their cost-to-hire? For many classes of project, a small, highly-skilled, local team is the way to go... and those projects are more likely than average to overlap with those which a highly-skilled individual would want to work on in the first place. Win/win!
That's the point where networking is useful. Knowing the right people (and being someone they think of when they're looking for someone with skills) is a much better way to get your foot in the door than resume polishing.
That said, you understate the amount of money one can make as a skilled kernel hacker. Seriously. I'm not one, but I know one of Linus's lieutenants -- not a household name among end-users, but very, very good at what he does -- and damn does he bring in the money.
(You also underestimate the amount of money one can make doing open source. The startup I work for is paying a guy who maintains a project we use for some of our infrastructure for bugfixes and extensions and a fixed monthly retainer for general support above and beyond what's generally available to the community -- his software touches confidential data, so anonymizing everything to go through community-based support channels would be more trouble than it's worth. He's working pretty cheap, from our perspective (which is good, because we're cash-poor) -- but you add up all his other consulting clients, and he's making a pretty nice living doing something he likes).
My advice to the poster: learn how to network. Work on class projects with different people and keep working with the smart people. Get into a co-op or intern at interesting companies (ask other people who have already interned and don't stop asking until you find someone who's (1) sharp and (2) gung-ho about their job). Go to the local language user group meetings and see if those people are any good. Ask to help out on other people's senior projects that seem interesting to you.
The more people who know that you're a badass problem solver, the more likely you are to find work you enjoy.
Just so. Getting to know local small business owners doesn't hurt either, with regard to getting early exposure to real-world-type problems.
(As for user groups, it doesn't need to be a language-focused user group; the folks who got me my first "real" tech job met me helping out at a LUG).
The fact is, people in cheaper countries don't have to be as good to outcompete us. Their housing is cheaper, their food is cheaper, their healthcare is cheaper. And it's not like they're unintelligent people, either.
All valid points -- but proximity to the customer counts for quite a lot; there's no substitute for sitting down with someone, interacting face-to-face and drawing on a whiteboard -- or being physically present to answer questions in a meeting with the suits.
For code-monkey positions, this may be moot; if you're implementing a nailed-solid spec someone else came up with, what does it matter where you're located? If you share responsibility for development of the spec as well as the implementation, it matters quite a bit.
High school + 4 years attending a state-funded (inexpensive) college is enough time doing open source work to get a useful amount of experience without spending a fortune bumming around as an adult. Beyond that -- some people have an innate proficiency for seeing a process and knowing the right algorithm or approach to use to address it. Those people have a lower barrier to entry by their nature.
I've never failed to hire anyone for not having "enough experience in enough languages"; one of the best experiences I've had with a coworker was with an intern with no prior industry experience whatsoever but a brilliant head for algorithms and an eagerness to learn. When I give the thumbs-down on someone, it's because they don't know things they think they know, or they don't have enough baseline knowledge to hit the ground running (this isn't a number-of-languages contest -- rather, it's knowing enough about the environment your programs operate in that you aren't going to be stymied the first time an abstraction you're relying on leaks), or they don't demonstrate good problem-solving skills (which is really based on knowing enough about your environment and then being able to work out how best to interact with it).
You'll have cause to seriously worry about outsourcing as competition for your job
People who say the profession is dead mean that the profession is no longer supporting as many gross incompetents as it did back during the boom. That's thankfully quite true.
The point: Don't go into software development as a profession if you're in it for the money. You won't want the profession, and the profession doesn't want you. If you're in it for something other than the money -- come on in, the water's fine.
Can you cite one sigificant case where it's "used even when only one form of IP is involved"?
I'm going to assert that such usage is blatantly widespread in press releases from technology companies and executive statements on similar topics. I'm not claiming that the executives and PR officers writing the staments are unaware of the distinctions -- but rather, that they are attempting to describe their rights and claims in as broad a manner as possible, and are being vague (and leading to reduced public awareness of the distinctions between those kinds of rights and claims) as an unintended consequence.
That said, this isn't a topic I care enough about to actually do the research. I've tried, in the post to which you just replied, to concede the bulk of my objection, which was admittedly ill-conceived; if you want to fight for the remaining shreds, you can have them -- I'm not playing that game over a statement which was made as a throwaway remark.
And can you reasonably show that such use had any negative consequences?
The consequences I'm alleging are in terms of public awareness of the distinctions. There's indisputably a lack of such awareness; the room for dispute is only with regard to its cause.
To be sure -- but that subordinate term should be used only when folks are talking only about multiple kinds of fruit in a lump -- in short, when it's needed. "Intellectual property" frequently gets used even when only one form of IP is involved; as such, it muddies the waters rather than clarifying them.
(That said, you're right -- it's not the term itself, but its overuse when something more specific is called for that's the problem).
(Might want to check your links in the future -- they're mostly bad. Doesn't matter so much in this case, though -- I remember Laches from my business law classes [IANAL, but I kept West's Business Law next to my bed in college], and Lemelson from various reading elsewhere).
"Dismissed the patent", or dismissed any ability to enforce the patent after waiting until the defendants are more liable than they would have been had the Lemelson Foundation acted promptly? There's a big difference here, inasmuch as the patent is still valid -- just not enforceable with respect to a significant class of defendants. (Anyone just now starting to infringe, for instance, would not necessarily protected by this defense -- as there existed no significant period in the past during which the patent holder could have attempted to mitigate damages by putting them on notice of the patent).
More to the point, simply putting a potential defendant on notice that one believes they may infringe a patent (and that prosecution may follow at some point in the future) would make it harder for Laches to apply -- the defendant would have opportunity after that point to reduce their dependency on the infringed technology, license it or take some other corrective action.
In Lemelson's case there were other defenses -- lack of enablement, etc. -- which went directly to the patents' validity, so I'm not arguing that the Lemelson patents could today actually be enforced against anyone; I'm instead arguing that claiming that the doctrine of Laches effectively constitutes a "use-it-or-lose-it" rule for patents, except in cases of unreasonable delay specific to the individual defendant.
Sure, that's how many stores do operate, but why does a store have to operate that way? Read his account he turned down only about two dozen sales, and some of those kids came back and made purchases later after cleaning up their grades.
If he gets parents' support through his policies, that has potential to result in a net increase of sales -- two dozen transactions isn't that may in the larger scheme of things.
Nuh-uh. I've watched my Colbert as well -- and the very definition of 'truthiness' is, as phrased by Wikipedia, 'things that a person claims to know intuitively or "from the gut" without regard to evidence, logic, intellectual examination, or actual facts'.
If it were intuitive enough to seem like this were true, we would not be questioning its actual truth, would we?
I don't allege conspiracy. I sited a lack of "truthiness" (the quality of sounding true) rather than a lack of truthfulness (the quality of actually being true). I have no information on which to base any claims as to the truthfulness of this news story; truthiness, on the other hand, anyone can judge.
If there were enough truthiness, we wouldn't be questioning the story's truthfulness... would we?
This is coming from state-run media, it doesn't contain enough details for easy independent verification -- and the state has indicated that combating "Internet addiction" is one of its goals.
There's a lack of truthiness here.
I ask again: If someone interrupted a discussion on OOP to ask you what a pointer was, would you dignify the question with a response? "Can not" and "will not" are entirely separate things.
I'll answer your pop quiz out-of-band -- phone me at +1.512.394.3516 should you be so inclined. You can be better assured that I'm not cheating under those circumstances, as well, and may provide an opportunity to clear up any miscommunication which might have added to our disagreements. That said, I will not stoop to being quizzed on such rudimentary knowledge in public.
I aced AP econ in high school, and went on to minor in business. Do you ask people with whom you're debating object-oriented design if they can tell you what a pointer is? (And the correlary: if someone asked you that, would you dignify the question with a response?)
See, it looks to me like you're arguing that there's downward pricing pressure impacting the market for American programmers, but I'm taking the position that while that may be true, it's not sufficiently so as to constitute the death of the profession. However, while I'm guessing that that's what you're trying to get at, it's hard to say -- because most of your actual communication consists of claiming that I've stated that older engineers "suck", arguing that working with Python is inherently unlike systems architecture, and inquiring as to my age, rate and skillset (while only making a single economic observation about the data returned -- and that with precious little context).
I'd like to have an intelligent debate -- but that's not going to happen if you have nothing to offer but handwaving, evasion and insults.
What is "this fact"? Which specific data points are you using?
Claiming that some subset of the set of concepts taught in macro economics 101 (which I'm well familiar with) supports your thesis in conjunction with some unstated members of the cloud of data thus far discussed is no argument at all, but merely handwaving. You've made any number of assertions throughout this thread, but have yet to even clarify which one represents the larger point which you suggest should be clear on its face.
It may well be that the overall thrust of your argument is something I don't dispute in the slightest -- but I won't know unless you tell me what it is.
Connect the dots again, please -- I don't understand how you're getting from the data points to the intended conclusion. Adjusting prices to compete with the rest of the world is hardly losing an industry. Losing a monopoly, sure, but that's inevitable.
(Not that I mean to deny the historical existence of a very substantial European software development market, but nonetheless the US has relied quite a bit on having a head start. To be sure, that's going away -- but it doesn't mean the American software industry is dead or even troubled).
Sure, starting at $40K isn't starting at $80K -- it means that, $DEITY forbid, both members of a two-parent household might need to get jobs! Oh, how horrid! American society has only been moving that way for the last decade or two; it's not like that's anything specific to the field. It might also mean that people might be financially motivated delay parenthood or to stop at one or two kids -- which is a damned good idea anyhow.The media company running their business off a bunch of (Python) code I designed and developed that's encrypting the movies, scheduling the ads their customers see, generating their web presence, managing communication with their DBMS (built around a schema I also developed) and communicating with the dedicated client software on the other end via a protocol I also designed doesn't view Python as "just a scripting language", nor my skillset as excluding architecture and design. Python is "[just] a scripting language" every bit as much as Java is "just an updated Z-machine" or C is "just portable assembler"; it has all the power of any serious conventional language, and attempts to diminish it thus need to be a little more serious than naming it "[just] a scripting language"....and where exactly did I claim that? I said that all the competent senior engineers I know are either happily employed, retired, or bumming around starting new businesses whenever they so fancy (and, obviously, are sufficiently financially independent as to be able to do so). As for the incompetent ones... well, I've met a lot more incompetent junior engineers than senior ones, and I'd thank you to respond to what I'm actually saying rather than what you'd prefer to think I am.
My larger point is that software development is a fine profession for people who aren't in it for the money. I still hold that this is true, even if the amount of money in the field continues to drop. People can live their lives giving haircuts as a profession; people will damned well be able to make a reasonable living writing software for the foreseeable future.
So, I've answered your questions... now, what's the point you're trying to make?
I'm in for five years on this latest one, and it looks like they might actually come out in the black.
I said "there's plenty of work", not "you can have any employer you want". They're different propositions.
But then... if you're getting to do something you love, and making enough to feed your family, isn't that good enough?
That's the point where networking is useful. Knowing the right people (and being someone they think of when they're looking for someone with skills) is a much better way to get your foot in the door than resume polishing.
That said, you understate the amount of money one can make as a skilled kernel hacker. Seriously. I'm not one, but I know one of Linus's lieutenants -- not a household name among end-users, but very, very good at what he does -- and damn does he bring in the money.
(You also underestimate the amount of money one can make doing open source. The startup I work for is paying a guy who maintains a project we use for some of our infrastructure for bugfixes and extensions and a fixed monthly retainer for general support above and beyond what's generally available to the community -- his software touches confidential data, so anonymizing everything to go through community-based support channels would be more trouble than it's worth. He's working pretty cheap, from our perspective (which is good, because we're cash-poor) -- but you add up all his other consulting clients, and he's making a pretty nice living doing something he likes).
(As for user groups, it doesn't need to be a language-focused user group; the folks who got me my first "real" tech job met me helping out at a LUG).
For code-monkey positions, this may be moot; if you're implementing a nailed-solid spec someone else came up with, what does it matter where you're located? If you share responsibility for development of the spec as well as the implementation, it matters quite a bit.
High school + 4 years attending a state-funded (inexpensive) college is enough time doing open source work to get a useful amount of experience without spending a fortune bumming around as an adult. Beyond that -- some people have an innate proficiency for seeing a process and knowing the right algorithm or approach to use to address it. Those people have a lower barrier to entry by their nature.
I've never failed to hire anyone for not having "enough experience in enough languages"; one of the best experiences I've had with a coworker was with an intern with no prior industry experience whatsoever but a brilliant head for algorithms and an eagerness to learn. When I give the thumbs-down on someone, it's because they don't know things they think they know, or they don't have enough baseline knowledge to hit the ground running (this isn't a number-of-languages contest -- rather, it's knowing enough about the environment your programs operate in that you aren't going to be stymied the first time an abstraction you're relying on leaks), or they don't demonstrate good problem-solving skills (which is really based on knowing enough about your environment and then being able to work out how best to interact with it).
If you aren't good, then:
- You won't enjoy it
- People who are good won't enjoy working with you
- You'll have cause to seriously worry about outsourcing as competition for your job
People who say the profession is dead mean that the profession is no longer supporting as many gross incompetents as it did back during the boom. That's thankfully quite true.The point: Don't go into software development as a profession if you're in it for the money. You won't want the profession, and the profession doesn't want you. If you're in it for something other than the money -- come on in, the water's fine.
That said, this isn't a topic I care enough about to actually do the research. I've tried, in the post to which you just replied, to concede the bulk of my objection, which was admittedly ill-conceived; if you want to fight for the remaining shreds, you can have them -- I'm not playing that game over a statement which was made as a throwaway remark.The consequences I'm alleging are in terms of public awareness of the distinctions. There's indisputably a lack of such awareness; the room for dispute is only with regard to its cause.
To be sure -- but that subordinate term should be used only when folks are talking only about multiple kinds of fruit in a lump -- in short, when it's needed. "Intellectual property" frequently gets used even when only one form of IP is involved; as such, it muddies the waters rather than clarifying them.
(That said, you're right -- it's not the term itself, but its overuse when something more specific is called for that's the problem).
(Might want to check your links in the future -- they're mostly bad. Doesn't matter so much in this case, though -- I remember Laches from my business law classes [IANAL, but I kept West's Business Law next to my bed in college], and Lemelson from various reading elsewhere).
"Dismissed the patent", or dismissed any ability to enforce the patent after waiting until the defendants are more liable than they would have been had the Lemelson Foundation acted promptly? There's a big difference here, inasmuch as the patent is still valid -- just not enforceable with respect to a significant class of defendants. (Anyone just now starting to infringe, for instance, would not necessarily protected by this defense -- as there existed no significant period in the past during which the patent holder could have attempted to mitigate damages by putting them on notice of the patent).
More to the point, simply putting a potential defendant on notice that one believes they may infringe a patent (and that prosecution may follow at some point in the future) would make it harder for Laches to apply -- the defendant would have opportunity after that point to reduce their dependency on the infringed technology, license it or take some other corrective action.
In Lemelson's case there were other defenses -- lack of enablement, etc. -- which went directly to the patents' validity, so I'm not arguing that the Lemelson patents could today actually be enforced against anyone; I'm instead arguing that claiming that the doctrine of Laches effectively constitutes a "use-it-or-lose-it" rule for patents, except in cases of unreasonable delay specific to the individual defendant.