I don't think Adobe's in any position to say Apple didn't give them plenty of warning.
Adobe's just a civilian casualty in an internal war in Apple. If the writing were so obviously on the wall, then why would iTunes still be a Carbon app?
Early on in the merger (circa WWDC 97), the NeXTies believed that everybody would quickly convert to what is now Cocoa, because it was obviously superior. To them, anyhow. But a lot of people were perfectly happy with the way they were doing things, and that included many of the developers inside Apple. The way I read it, the war went on for TEN YEARS, which is why you saw them promising 64-bit Carbon. And then the Carbon side finally lost, explaining the sudden cancellation.
As somebody who helps hire programmers in the Bay Area, I agree that you should not be looking for a short coding job.
In hiring somebody with a CS degree but not lot of professional experience, there are three things I look for, in increasing order of importance:
academic understanding - This is the stuff that your professors think is important. If I can trick you into telling me that you can write a program that will tell whether another program will terminate, or if you aren't comfortable with big-O notation, I'll suspect that you didn't take your classes very seriously. I don't actually care much if you know those things, but I do care if you're a slacker, or are in the profession more for money than love of the topic.
practical experience - The biggest resume positive on this one is participating actively in, or -- better yet -- starting an open-source product I can look at your code, look at your mailing list participation, and look at the project itself to see whether or not you can successfully code in the real world. It can be small, and in fact that may be better, as it shows a little humility and it's easy to evaluate. But I need to believe you can accomplish more than just a rushed end-of-semester project that nobody ever actually used.
understanding the business - Coding is definitely what it's all about, but I have dealt with a number of prima donnas, brilliant idiots, and uncompromising idealists that caused enough trouble that they were of net negative value to a team, despite amazing talent. I am much more likely to hire somebody that understands that we are there to be responsible professionals serving the needs of our employers and users, and knows enough about the business of software to work smoothly with their colleagues. That way I won't have to beat them to death and hide their body, a situation I try to avoid.
So definitely look at jobs that give you maximum insight into the whole process. QA is indeed a good place to see what's going on. Product planning, user research, and server operations also have plenty of grunt work, and valuable perspectives that are often neglected. You would also learn a ton from tech support, but that can look a little inglorious on a resume, so only do that in a shop small enough that tech support is just one of those things that programmers or product managers do as a sideline.
I also strongly encourage you to look for a shop that is as agile as possible. Some companies, especially startups, are doing one-week iterations and weekly releases. Many are doing two-week iterations and monthly releases. Your internship will be much more valuable to you if you can see 8 weekly release cycles, rather than 1/3 of a 6-month release cycle.
Oh great. Then I consider myself a driving expert as I've written off lots of cars.
It's a common observation among social scientists that academics often choose their field of study to match what they're bad at. One of the best lectures I had in college was a guy who studied human mating behavior for a living. He was quite frank that he went into it because he couldn't get dates and didn't understand why.
Having car accidents isn't enough on its own to make you an expert on driving. But if you have a bunch of car crashes, the pain involved may drive you to think very, very hard about why that is. That can indeed make you a driving expert.
Well, look at Slicehost and you can get [...] WITH persistent storage
The Amazon machines offer storage that persists for the life of the virtual instance. That's until you kill the instance or until the hardware fails. (It does persist through reboots and OS crashes.) And unless Slicehost is running some crazy magic beyond the RAID-10 setup they mention, a hardware failure could still wipe out your data, and will certainly cause downtime during which you will have an opportunity to wonder when and whether your data is coming back.
If you run some stats, it could well be that the Slicehost "persistent" storage does indeed persist longer. That'd be my guess. But it's possible that the Amazon "non-persistent" storage is actually more stable. That depends on the quality of hardware and maintenance at both companies, factors that you cannot know. Meaning that if reliability is really important to you, you must plan for either kind of storage eventually failing. And if reliability isn't that important to you, then you're planning to depend on your backups anyhow, in which case Amazon doesn't seem so bad either.
I think the main difference between Amazon and the more typical providers regarding persistence is that Amazon's experience has taught them to assume that everything fails, and so you should engineer for that. EC2 and S3 are built around that, and are very frank about what they provide. It seemed weird at first, but now I like it better.
"Science progresses one funeral at a time." - Max Planck
Software might be slightly better, as Moore's Law has been prodding us forward. On the other hand, given the number of us working in C-like languages (35+ years old), maybe with an OO twist (25+ years), to do web stuff (15-ish years), one funeral at a time might be more than we can manage. Legacy code, alas, can outlive its authors.
What's so hard about typing "poorest neighborhood" instead? That phrase seriously threw me when i read it.
Because that might not be true?
Postal code zones are well defined, and for many places map well onto census data. So you can easily find out what the poorest postal code is. Neighborhood names and boundaries, on the other hand, are notoriously variable. If they said "poorest neighborhood" when they couldn't prove it and when there were other good candidates, some pedant much like your own good self would have griped about it.
I agree with most of your comments, and especially the spirit of keeping everything shipshape and avoiding the endless game of "who can be blamed". Two minor improvements:
Any error handling through error return codes, probably to be replaced by exceptions, unless it turns the calling code into a wild mass of try/catch blocks. Sometimes instead of return codes, there are other good options. For example, you can spin a state machine out into an object, which in effect keeps the return codes safely in one place until you want to check them. In some cases, I love the Null Object Pattern. And sometimes it makes sense to have a request object and a response object, with the response carrying possible error-related info.
Anything that *doesn't* belong together should be split into separate files (but don't make a file for just a single function - instead create a file with "leftovers"). For functions, maybe. But a lot of good objects really can have just one method. Ruby does that all the time with anonymous methods, for example, and sometimes that pattern is worth using in a more explicit language.
Also, more generally, I feel like unit tests are a much better place to store knowledge than comments.
What's wrong with reading until you get to the end of the file? That's how the idiom seems to be done in every other language I've used. Why is that an exception in Java? It's not. The typical Java idiom for reading lines from a file looks like this. (Actually, in production, you would actually handle the errors in that exception block rather than swallowing them. I would personally put the close() call in a finally block, not the main try block, as you still want to close even if a read fails. But you get the idea.)
As you can see, you read until it comes back empty, and then you're done. No exceptions will be used except when things are exceptional.
That's still slightly ugly, but that should rarely matter in Java or in any well-built OO system. You never read files for the sake of it; you're always up to something specific. Even when I'm dealing with files all the time, I almost never write code like this, because I'm reading XML or reading a properties file or something where all the details are taken care of in a method that I almost never see.
I love the way the article uses the complete rewrite of Netscape as an example of why you shouldn't rewrite from scratch. Cause we all know how big a failure Firefox is </sarcasm> Firefox is not Netscape.
The Netscape browser, like the company that made it, indeed ended up a failure. And my pals who were there at the time tell me that the poor code quality was a major factor in the inability to get anywhere. How long did it take between the last decent release of Netscape and the 1.0 release of Firefox? Four years? Six? I guess it depends on what you consider the last decent release. No matter how you count it, though, there were years of thrashing trying to get something based on the old code out the door. Eventually, they just gave up.
Firefox is a big success now, but Netscape was a giant crater of a failure during a crucial period, leaving Microsoft effectively unopposed in their attempts to take over the browser market.
it's your job as the programmer to understand and document all of the tweaks, bug fixes, edge conditions, and obscure environments.
And in my view, it's my job as a programmer to document all of those things in readable automated tests. Only a programmer can check that a comment or a document has been followed. Automated tests mean that the computer can do the dirty work. And I'm all for that.
I really really hate this pattern that Java (and perhaps from elsewhere) has foisted upon us where we get frickin exceptions because we reached the end of the file. That is technically an error condition in the reader function, but it is not exceptional and it shouldn't require me to write the "wild mess of try/catch blocks" just to read in data from a file. Exceptions say "we are really in a mess and have to abort this operation, and potentially the program. They do not say "could not find element x in array".
If you're writing in Java, I couldn't disagree more. Trying to read past the end of a file, trying to reference elements in an array that aren't there? That should not happen, making them exceptional conditions. If you are doing them, that means that you messed up, and things should indeed blow up.
If you're writing in a DWIM language like Perl, then yeah, nothing should really blow up ever. Reference something that doesn't exist? Sure, you must have meant for that to exist, so we'll create it. And return you an nice undefined value, that other things will handle gracefully. And give you a cookie, just 'cause Larry Wall loves us all.
Note also that in Java those catch blocks for reading a file are not for the usual case, or generally even the retarded-programmer case. You have to catch IOException when trying to read a file because IO can always fail. You may be writing a program where it's ok to sail on past a disk or network failure, but some of us read and write data that people actually care about.
In that kind of coding, I'm me grateful for a well-designed set of checked exceptions: it makes me consciously think about and explicitly handle all of the weird little failure cases that I would rather pretend were impossible.
Wait, so a web business being cross-platform is being altruistic? and a hardware manufacturer developing for one platform is evil?
Good and evil are things you brought to this.
The guy I was responding to claimed that the article's core thesis, that Apple likes closed platforms when most of their neighbors like open ones, was wrong. You and I seem to agree that the article got that right, so I don't know why you're being snippy at me.
I'm not saying it's bad in this case. Good's a hard thing to measure. I'm just saying that the guy I was responding to is wrong: his examples don't prove that the article's thesis is wrong. I think it stands: Apple's relationship with its users is indeed very different than the current mood in Silicon Valley.
The author seems blissfully unaware of Apple's free software use. GCC, Darwin, Khtml and what not punch a few large holes in their central thesis.
And for which of those has Apple created an open, cross-platform ecosystem?
*sound of crickets chirping*
That's right, none of them. OpenDarwin is dead, they forked KHTML, and they use GCC because there wasn't any benefit in writing a compiler from scratch. Whereas I could name a half-dozen Google open source efforts without a pause to think, and a number of landmark papers describing their technical innovations.
Well, much the same thing can be said about diets, vitamins, string theory...
Diets are not so bad to test. They're all pretty prescriptive, saying, "Do X, Y, and Z and you will lose weight." So you can test that. And a lot of them have a explicit models of the body. E.g., eating fat makes you fat. Where I think they really fall down is in their implied models of things like motivation, hunger, and sustainability, and along with those implied models there are a lot of implied claims.
Testing vitamin claims can also be ok. Scientific American had a nice article on Vitamin D not so long ago, for example. But the some "take X, Y, and Z for optimum health" schools are untestable, and many more untested.
String theory I know zero about, but Wikipedia appears to agree with you: "String theory as a whole has not yet made falsifiable predictions that would allow it to be experimentally tested, though various planned observations and experiments could confirm some essential aspects of the theory, such as supersymmetry and extra dimensions. In addition, the full theory is not yet understood."
Agreed, but you'll have to place them in different positions to be effective:
I agree that to the extent your team specializes, specialist knowledge is useful. But my view is that treating creative work like assembly-line work is a regrettably common error, and that software development should always be creative work. (When it's not, people almost always just buy a copy rather than coding a duplicate from scratch.)
In a creative work, seemingly minor changes can have systemic effects. In fact, they should have systemic effects; if a developer spends a day coding and it has no effect on end users and the business, it's probably a wasted day. Given that, the more a developer understands about the context, the better they are able to achieve product/market fit. So along with a solid CS grounding, a liberal education is essential.
Even if you follow a strongly specialized model, however, people will still need the basics to integrate well. Unless I understand a bit about psychology, a designer's requests will seem retarded to me. Without some understanding of business, I won't be able to give product management good cost/benefit tradeoffs. Without an inkling of the law, I may not know enough to ask my project manager about libraries I'm including. And so on.
If you have a person that spent time taking macrame and ice fishing in college, do not expect that person to be able to solve driver problems, most likely does not have the knowledge or the inclination to fix it in the first place.
Could be. Depends on the person, really. One of the most important characteristics in a good programmer is intellectual curiosity. This often leads people on strange paths. I'm much more afraid of the applicant who got a narrow, vocational CS degree as the quick path to a good job than I am one who has a CS degree plus a lot of apparently unrelated coursework. In my experience, the former often turn out to be clock-punchers. The latter group, if you can get them hooked on the job, will be reading things in the off hours just for the fun of it.
So your grumbling boils down to a) Flash and b) your comparative lack of familiarity with the Discovery Channel sites.
No, my point is that Wikipedia is easier to get information out of. That's because they understand that fancy design reduces utility. Further, their only reason for existence is to provide answers, whereas the Discovery Channel has different purposes, like promoting their show, reinforcing the fan base, and selling my attention to advertisers.
And suggesting that it's somehow more efficient to become familiar with every primary-source site on the web rather than just one? You can't expect to be taken seriously with statements like that, can you?
it is silly to use Wikipedia when there are better/more direct sources. Basic critical thinking skills will allow you to see that.
Basic critical thinking skills? Yes, please use them before posting. It will save us all some time.
More direct sources are very rarely better for a quick overview, which is why I have shelves of dictionaries, almanacs, concordances, indexes, encyclopedias, guides, maps, analyses, abstracts, and literature surveys. I also have plenty of primary sources, and go to them when needed. But the whole point of an encyclopedia, on-line or off-, is to make basic info more conveniently available than primary sources. Which is what 99% of people want as a starting point. If you don't, fine. Post your little link and move along.
Mind giving a link/reference to that reading by Derren Brown? I think I'd enjoy reading more about it.
I haven't seen anything on line, but see his book Tricks of the Mind, "Cold Reading", page 320 and forward. It contains the full text of the reading. Fabulous book, BTW; I paid to have it shipped from England, and it was totally worth it.
I think if you're in that situation you're in trouble.
That depends. Startups need people now; they really can't afford to wait two years to train a bunch of experts. New projects are often in a similar situation.
I find it curious that experienced managers who understand that not everything can go your way in every other area of their business suddenly get the deer-in-the-headlights look when they optimistically set their goals too high in recruiting. If you need 10 seasoned J2EE programmers in a short period of time, you probably are going to be out of luck.
Here I completely agree with you. Any company that has a bunch of programmers and expects to need more should be building them.
What is the point of linking to the Dirty Jobs entry on Wikipedia? What's wrong with the actual Discovery Channel site?
Well, I looked at your link and I see some ads and a big Flash thingy. (I'm using FlashBlock so I have to click to view Flash. Wonderful!) If I load the Flash, I see some fancily designed animated cruft with a bunch of buttons that may or may not lead to actual information. Much of text is at slightly random skewed angles, and there's no obvious place to find basic facts.
When I look a the Wikipedia article, on the other hand, I see no ads, no Flash, and some nicely formatted text, written to give quick answers, laid out in tidy sections, all using a standard format that I'm familiar with from a bunch of previous visits.
possibly through DNA influences at the quantum level [...] . Ignoramouses....
One, it's "ignoramus". Next time try "idiot"; it's shorter. Two, you should take your own advice, and read some actual science books. Ones with math. And problem sets. "Possibly through DNA influences at the quantum level" indeed.
I have had only one reading done in my life which was very interesting and informative.
And you know why that is? It has zero to do with planets, and everything to do with the complexity of the human mind. Which you are, alas, just blowing on by.
The astrologers I've talked to often have a deep intuitive understanding of human psychology, and so can say some pretty insightful things. But all the planet mumbo jumbo? That's the functional equivalent of ink blot tests. With a little structure and a little random noise, you can unlock the subconscious skills that were there all along.
Many are also skilled cold readers, which can give the impression of wisdom and knowledge without actually knowing anything. They need not be doing this intentionally. FBI profilers also don't know jack, but are apparently sincere.
And of course, astrology subjects are unwittingly complicit in this. Confirmation bias plays a big role, as do other cognitive biases. Derren Brown, a UK magician, did an astrological reading for three different groups of 5 people. After getting birthdates and one personal object each, he gave them a 4-page written document about their personality, history, and ambitions. 80% gave very high marks for accuracy, and were shocked at how detailed and personal the reading was. One person thought he had somehow gained access to her private journal. At the end, he revealed he had given everybody the exact same reading.
So I'd say that you should take your own advice, and learn something about the topic before running your mouth. If people think a fake reading is real 80% of the thime, then a personal anecdote about a supposed good reading tells us bupkis. And that's true even when somebody sprinkles some sciency mumbo-jumbo on top.
For example, we know that the phases of the moon do influence mood and some other behaviour.
Evidence? My understanding is that the one study that suggested this had a disproportionate number of weekends with full moons, and that it is actually weekends that effect behavior. Which I kinda already knew.
OK, the random crap in GirlsMag is not a model, but true astrology is. It is based on the idea that gravity and other forces influence our lives.
Two thoughts here:
One: Basing something on an idea is not a model in the sense he's talking about. Maybe you've got one, in which case, read on.
Two: If there are real, serious astrologers out there who actually have a predictive model, you guys need to run the crap ones out of business. Denounce the frauds just like doctors or scientists do. If you leave your profession's messes to be cleaned up by skeptics, they will continue assume that all astrologers are idiots, as that's all they see.
Slashdot Mirror
I don't think Adobe's in any position to say Apple didn't give them plenty of warning.
Adobe's just a civilian casualty in an internal war in Apple. If the writing were so obviously on the wall, then why would iTunes still be a Carbon app?
Early on in the merger (circa WWDC 97), the NeXTies believed that everybody would quickly convert to what is now Cocoa, because it was obviously superior. To them, anyhow. But a lot of people were perfectly happy with the way they were doing things, and that included many of the developers inside Apple. The way I read it, the war went on for TEN YEARS, which is why you saw them promising 64-bit Carbon. And then the Carbon side finally lost, explaining the sudden cancellation.
I'll be off to update mine today. It's the best improvement on tcpdump I've ever used.
Amen to that. "Assemble TCP Stream" alone is a glorious thing, and there's so much more.
Still, I'm a little sad that it's now v1.0. It seemed much more advanced when it was 0.9.99.9921 or whatever the last prerelease version was.
In hiring somebody with a CS degree but not lot of professional experience, there are three things I look for, in increasing order of importance:
So definitely look at jobs that give you maximum insight into the whole process. QA is indeed a good place to see what's going on. Product planning, user research, and server operations also have plenty of grunt work, and valuable perspectives that are often neglected. You would also learn a ton from tech support, but that can look a little inglorious on a resume, so only do that in a shop small enough that tech support is just one of those things that programmers or product managers do as a sideline.
I also strongly encourage you to look for a shop that is as agile as possible. Some companies, especially startups, are doing one-week iterations and weekly releases. Many are doing two-week iterations and monthly releases. Your internship will be much more valuable to you if you can see 8 weekly release cycles, rather than 1/3 of a 6-month release cycle.
Oh great. Then I consider myself a driving expert as I've written off lots of cars.
It's a common observation among social scientists that academics often choose their field of study to match what they're bad at. One of the best lectures I had in college was a guy who studied human mating behavior for a living. He was quite frank that he went into it because he couldn't get dates and didn't understand why.
Having car accidents isn't enough on its own to make you an expert on driving. But if you have a bunch of car crashes, the pain involved may drive you to think very, very hard about why that is. That can indeed make you a driving expert.
Well, look at Slicehost and you can get [...] WITH persistent storage
The Amazon machines offer storage that persists for the life of the virtual instance. That's until you kill the instance or until the hardware fails. (It does persist through reboots and OS crashes.) And unless Slicehost is running some crazy magic beyond the RAID-10 setup they mention, a hardware failure could still wipe out your data, and will certainly cause downtime during which you will have an opportunity to wonder when and whether your data is coming back.
If you run some stats, it could well be that the Slicehost "persistent" storage does indeed persist longer. That'd be my guess. But it's possible that the Amazon "non-persistent" storage is actually more stable. That depends on the quality of hardware and maintenance at both companies, factors that you cannot know. Meaning that if reliability is really important to you, you must plan for either kind of storage eventually failing. And if reliability isn't that important to you, then you're planning to depend on your backups anyhow, in which case Amazon doesn't seem so bad either.
I think the main difference between Amazon and the more typical providers regarding persistence is that Amazon's experience has taught them to assume that everything fails, and so you should engineer for that. EC2 and S3 are built around that, and are very frank about what they provide. It seemed weird at first, but now I like it better.
"Science progresses one funeral at a time." - Max Planck
Software might be slightly better, as Moore's Law has been prodding us forward. On the other hand, given the number of us working in C-like languages (35+ years old), maybe with an OO twist (25+ years), to do web stuff (15-ish years), one funeral at a time might be more than we can manage. Legacy code, alas, can outlive its authors.
What's so hard about typing "poorest neighborhood" instead? That phrase seriously threw me when i read it.
Because that might not be true?
Postal code zones are well defined, and for many places map well onto census data. So you can easily find out what the poorest postal code is. Neighborhood names and boundaries, on the other hand, are notoriously variable. If they said "poorest neighborhood" when they couldn't prove it and when there were other good candidates, some pedant much like your own good self would have griped about it.
Also, more generally, I feel like unit tests are a much better place to store knowledge than comments.
Other than that, I agree completely!
As you can see, you read until it comes back empty, and then you're done. No exceptions will be used except when things are exceptional.
That's still slightly ugly, but that should rarely matter in Java or in any well-built OO system. You never read files for the sake of it; you're always up to something specific. Even when I'm dealing with files all the time, I almost never write code like this, because I'm reading XML or reading a properties file or something where all the details are taken care of in a method that I almost never see.
The Netscape browser, like the company that made it, indeed ended up a failure. And my pals who were there at the time tell me that the poor code quality was a major factor in the inability to get anywhere. How long did it take between the last decent release of Netscape and the 1.0 release of Firefox? Four years? Six? I guess it depends on what you consider the last decent release. No matter how you count it, though, there were years of thrashing trying to get something based on the old code out the door. Eventually, they just gave up.
Firefox is a big success now, but Netscape was a giant crater of a failure during a crucial period, leaving Microsoft effectively unopposed in their attempts to take over the browser market.
it's your job as the programmer to understand and document all of the tweaks, bug fixes, edge conditions, and obscure environments.
And in my view, it's my job as a programmer to document all of those things in readable automated tests. Only a programmer can check that a comment or a document has been followed. Automated tests mean that the computer can do the dirty work. And I'm all for that.
I really really hate this pattern that Java (and perhaps from elsewhere) has foisted upon us where we get frickin exceptions because we reached the end of the file. That is technically an error condition in the reader function, but it is not exceptional and it shouldn't require me to write the "wild mess of try/catch blocks" just to read in data from a file. Exceptions say "we are really in a mess and have to abort this operation, and potentially the program. They do not say "could not find element x in array".
If you're writing in Java, I couldn't disagree more. Trying to read past the end of a file, trying to reference elements in an array that aren't there? That should not happen, making them exceptional conditions. If you are doing them, that means that you messed up, and things should indeed blow up.
If you're writing in a DWIM language like Perl, then yeah, nothing should really blow up ever. Reference something that doesn't exist? Sure, you must have meant for that to exist, so we'll create it. And return you an nice undefined value, that other things will handle gracefully. And give you a cookie, just 'cause Larry Wall loves us all.
Note also that in Java those catch blocks for reading a file are not for the usual case, or generally even the retarded-programmer case. You have to catch IOException when trying to read a file because IO can always fail. You may be writing a program where it's ok to sail on past a disk or network failure, but some of us read and write data that people actually care about.
In that kind of coding, I'm me grateful for a well-designed set of checked exceptions: it makes me consciously think about and explicitly handle all of the weird little failure cases that I would rather pretend were impossible.
Thanks! I had read about this, but not seen the video. That's delightful!
Wait, so a web business being cross-platform is being altruistic? and a hardware manufacturer developing for one platform is evil?
Good and evil are things you brought to this.
The guy I was responding to claimed that the article's core thesis, that Apple likes closed platforms when most of their neighbors like open ones, was wrong. You and I seem to agree that the article got that right, so I don't know why you're being snippy at me.
Since when is forking a bad thing?
I'm not saying it's bad in this case. Good's a hard thing to measure. I'm just saying that the guy I was responding to is wrong: his examples don't prove that the article's thesis is wrong. I think it stands: Apple's relationship with its users is indeed very different than the current mood in Silicon Valley.
The author seems blissfully unaware of Apple's free software use. GCC, Darwin, Khtml and what not punch a few large holes in their central thesis.
And for which of those has Apple created an open, cross-platform ecosystem?
*sound of crickets chirping*
That's right, none of them. OpenDarwin is dead, they forked KHTML, and they use GCC because there wasn't any benefit in writing a compiler from scratch. Whereas I could name a half-dozen Google open source efforts without a pause to think, and a number of landmark papers describing their technical innovations.
Well, much the same thing can be said about diets, vitamins, string theory...
Diets are not so bad to test. They're all pretty prescriptive, saying, "Do X, Y, and Z and you will lose weight." So you can test that. And a lot of them have a explicit models of the body. E.g., eating fat makes you fat. Where I think they really fall down is in their implied models of things like motivation, hunger, and sustainability, and along with those implied models there are a lot of implied claims.
Testing vitamin claims can also be ok. Scientific American had a nice article on Vitamin D not so long ago, for example. But the some "take X, Y, and Z for optimum health" schools are untestable, and many more untested.
String theory I know zero about, but Wikipedia appears to agree with you: "String theory as a whole has not yet made falsifiable predictions that would allow it to be experimentally tested, though various planned observations and experiments could confirm some essential aspects of the theory, such as supersymmetry and extra dimensions. In addition, the full theory is not yet understood."
Agreed, but you'll have to place them in different positions to be effective:
I agree that to the extent your team specializes, specialist knowledge is useful. But my view is that treating creative work like assembly-line work is a regrettably common error, and that software development should always be creative work. (When it's not, people almost always just buy a copy rather than coding a duplicate from scratch.)
In a creative work, seemingly minor changes can have systemic effects. In fact, they should have systemic effects; if a developer spends a day coding and it has no effect on end users and the business, it's probably a wasted day. Given that, the more a developer understands about the context, the better they are able to achieve product/market fit. So along with a solid CS grounding, a liberal education is essential.
Even if you follow a strongly specialized model, however, people will still need the basics to integrate well. Unless I understand a bit about psychology, a designer's requests will seem retarded to me. Without some understanding of business, I won't be able to give product management good cost/benefit tradeoffs. Without an inkling of the law, I may not know enough to ask my project manager about libraries I'm including. And so on.
If you have a person that spent time taking macrame and ice fishing in college, do not expect that person to be able to solve driver problems, most likely does not have the knowledge or the inclination to fix it in the first place.
Could be. Depends on the person, really. One of the most important characteristics in a good programmer is intellectual curiosity. This often leads people on strange paths. I'm much more afraid of the applicant who got a narrow, vocational CS degree as the quick path to a good job than I am one who has a CS degree plus a lot of apparently unrelated coursework. In my experience, the former often turn out to be clock-punchers. The latter group, if you can get them hooked on the job, will be reading things in the off hours just for the fun of it.
Don't forget the feeling of smug self-satisfaction.
On Slashdot? No worry that will get forgotten. Here we all worship at the church of Laziness, Impatience, and Hubris.
So your grumbling boils down to a) Flash and b) your comparative lack of familiarity with the Discovery Channel sites.
No, my point is that Wikipedia is easier to get information out of. That's because they understand that fancy design reduces utility. Further, their only reason for existence is to provide answers, whereas the Discovery Channel has different purposes, like promoting their show, reinforcing the fan base, and selling my attention to advertisers.
And suggesting that it's somehow more efficient to become familiar with every primary-source site on the web rather than just one? You can't expect to be taken seriously with statements like that, can you?
it is silly to use Wikipedia when there are better/more direct sources. Basic critical thinking skills will allow you to see that.
Basic critical thinking skills? Yes, please use them before posting. It will save us all some time.
More direct sources are very rarely better for a quick overview, which is why I have shelves of dictionaries, almanacs, concordances, indexes, encyclopedias, guides, maps, analyses, abstracts, and literature surveys. I also have plenty of primary sources, and go to them when needed. But the whole point of an encyclopedia, on-line or off-, is to make basic info more conveniently available than primary sources. Which is what 99% of people want as a starting point. If you don't, fine. Post your little link and move along.
Mind giving a link/reference to that reading by Derren Brown? I think I'd enjoy reading more about it.
I haven't seen anything on line, but see his book Tricks of the Mind, "Cold Reading", page 320 and forward. It contains the full text of the reading. Fabulous book, BTW; I paid to have it shipped from England, and it was totally worth it.
I think if you're in that situation you're in trouble.
That depends. Startups need people now; they really can't afford to wait two years to train a bunch of experts. New projects are often in a similar situation.
I find it curious that experienced managers who understand that not everything can go your way in every other area of their business suddenly get the deer-in-the-headlights look when they optimistically set their goals too high in recruiting. If you need 10 seasoned J2EE programmers in a short period of time, you probably are going to be out of luck.
Here I completely agree with you. Any company that has a bunch of programmers and expects to need more should be building them.
What is the point of linking to the Dirty Jobs entry on Wikipedia? What's wrong with the actual Discovery Channel site?
Well, I looked at your link and I see some ads and a big Flash thingy. (I'm using FlashBlock so I have to click to view Flash. Wonderful!) If I load the Flash, I see some fancily designed animated cruft with a bunch of buttons that may or may not lead to actual information. Much of text is at slightly random skewed angles, and there's no obvious place to find basic facts.
When I look a the Wikipedia article, on the other hand, I see no ads, no Flash, and some nicely formatted text, written to give quick answers, laid out in tidy sections, all using a standard format that I'm familiar with from a bunch of previous visits.
Other than that, no reason.
possibly through DNA influences at the quantum level [...] . Ignoramouses....
One, it's "ignoramus". Next time try "idiot"; it's shorter. Two, you should take your own advice, and read some actual science books. Ones with math. And problem sets. "Possibly through DNA influences at the quantum level" indeed.
I have had only one reading done in my life which was very interesting and informative.
And you know why that is? It has zero to do with planets, and everything to do with the complexity of the human mind. Which you are, alas, just blowing on by.
The astrologers I've talked to often have a deep intuitive understanding of human psychology, and so can say some pretty insightful things. But all the planet mumbo jumbo? That's the functional equivalent of ink blot tests. With a little structure and a little random noise, you can unlock the subconscious skills that were there all along.
Many are also skilled cold readers, which can give the impression of wisdom and knowledge without actually knowing anything. They need not be doing this intentionally. FBI profilers also don't know jack, but are apparently sincere.
And of course, astrology subjects are unwittingly complicit in this. Confirmation bias plays a big role, as do other cognitive biases. Derren Brown, a UK magician, did an astrological reading for three different groups of 5 people. After getting birthdates and one personal object each, he gave them a 4-page written document about their personality, history, and ambitions. 80% gave very high marks for accuracy, and were shocked at how detailed and personal the reading was. One person thought he had somehow gained access to her private journal. At the end, he revealed he had given everybody the exact same reading.
So I'd say that you should take your own advice, and learn something about the topic before running your mouth. If people think a fake reading is real 80% of the thime, then a personal anecdote about a supposed good reading tells us bupkis. And that's true even when somebody sprinkles some sciency mumbo-jumbo on top.
For example, we know that the phases of the moon do influence mood and some other behaviour.
Evidence? My understanding is that the one study that suggested this had a disproportionate number of weekends with full moons, and that it is actually weekends that effect behavior. Which I kinda already knew.
OK, the random crap in GirlsMag is not a model, but true astrology is. It is based on the idea that gravity and other forces influence our lives.
Two thoughts here:
One: Basing something on an idea is not a model in the sense he's talking about. Maybe you've got one, in which case, read on.
Two: If there are real, serious astrologers out there who actually have a predictive model, you guys need to run the crap ones out of business. Denounce the frauds just like doctors or scientists do. If you leave your profession's messes to be cleaned up by skeptics, they will continue assume that all astrologers are idiots, as that's all they see.