Well, the first part of your comment, while interesting, isn't very compelling. We can argue about root causes and trade theories all day, but that isn't data. In order to make a social policy determination, a statistical causal connection has to be established between the process you are describing and measurable changes in societal behavior, hopefully with multivariate analysis such as multiple regression, where we can throw as many variables as we can think of into the mix to see which one really matters. As Huckleberry Finn once said, "You can reckon till the cows come home, but that don't prove nothin'."
Will pr0n cause some sicko to get sicker? Maybe. I don't think anyone has the data to make that claim. Hell, for all we know, pr0n helps the sicko sublimate his sicko desires.
As far as the correlations between toking/drinking/smoking and coke/heroin addiction are concerned, one could argue that drinkers and smokers should be actively converted to tokers! Correlation is not causality, as you point out.
1) Do you really think that sex on TV, or women wearing tighter or more revealing clothing, causes more illegitimate children and more sex crimes? Where are the data to support this? I recall reading that illegitimacy is actually on the decline at the moment. 2) Why don't you also complain about violence on TV? People have been dying like flies on TV shows and movies since the 50's. Are we more violent because TV shows and movies are making us violent? People have tried to make this argument, but the data don't support it. 3) Hey, maybe it's all the fault of our local TV news programs! That's what Michael Moore suggests ("Bowling for Columbine"). Maybe we should prevent the local news from carrying sensational stories about murders and stabbings, so we'll all feel safer and for some reason stop killing each other (there are no data to support this, either).
You seem like a well-meaning person. Unfortunately you have drawn a conclusion that isn't supported by any data. The pinups of the 40's, for example, hardly seem racy today -- but back then, a glimpse of thigh was big big news, indeed. Had you been around back then (were you?), you probably would have joined the ranks of the outraged at seeing the famous Betty Grable leg shot.
Just checking -- how do you feel about recreational drugs, like marijuana? Do you think that marijuana starts people down a slippery slope to crank, coke, heroin, and so forth? No evidence for that, either, I'm afraid.
There is a difference between sales and marketing. As you point out, salespeople have to be reigned in and controlled, because they will sell anything. Many software salespeople truly don't understand the limitations of their product, and will try to put a square peg in a round hole if they can get the sale, even if that means shipping an engineer with every unit.
What the article was talking about was a Marketing organization that wasn't thinking straight. There is a profound difference. In this case, Marketing was out of control, not Sales. I have seen this many times. They made one of the most common mistakes that marketing organizations make, namely checklist selling against the competition. This is a no-win situation. First one product is "ahead", then the other, wake me up when you have something new to say.
In order to really make a dent in a market, you have to change the playing field, not just tweak the product. Microsoft is scary/dangerous not because they release new versions of Office occasionally, but because from time to time they do really profound things like boot everyone else out of the Office business by betting on Windows when everyone thought Windows was a non-starter. Remember when Excel used to ship with its own Windows shell, before Windows was available? No? Well, I do. I remember the difference between that early Excel and Lotus, too. Lotus had more checklist features for a long time, but Excel -- it was just plain beautiful and fun to use. Once you used it, you couldn't go back to Lotus, even if it had some bullshit statistical function that Excel didn't have (yet).
Now THAT'S product marketing -- long term perspective, vision, eye on the goal line, pick your cliche of the day.
Funny, but this person is not far off from what would thoroughly discourage the Chinese authorities. What if everyone starts sending bullshit revolutionary messages? Let 'em try to lock the whole country up.
They should be much more worried about tight little cells that are already speaking l33t-equivalent, except it's a l33t that nobody knows but the conspirators.
Note that this system is infinitely better than the radio "traffic reports," like those in Boston on 1030 WBZ. The announcers already know from experience where all the slowdowns are likely to be, so they just repeat the same B.S. every morning, true or false, until they get lucky and their helicopter spots something, or the State Police radio in an accident.
I used to commute the Mass Pike eastbound from 495 into 128/95, and I can count on the fingers of one hand the times that the "traffic report" was actually accurate.
As far as people paying attention to the web site and changing their route based on 30 minute or 60 minute advanced prediction, thus screwing up the "prediction," that's only an issue if you need advance warning before you leave the house. What's really needed is a real-time decision when you come up against a junction point. Which way? Tell me now. Should be easy enough to do with a real-time feed from your car to the model.
Not that there's that many obvious alternate route choices around Boston anyway, but it sure would be helpful to have precise information on the jam-ups for those of us who know the back roads.
Good point. However, a lot of things that Slashdot trolls have been complaining about since '98 continue to be true today. How about the XP dispatcher? Still can't get smooth performance without a second CPU. Corbato et al solved this problem in 1961. There is no excuse.
I refuse to use this piece of software, period. Redmond are pulling their usual stunt of releasing crap just for the publicity, so all their shills can say, "Golly wow, Microsoft's gonna have a much better search engine real soon now."
I'm so sick of this strategy I could puke. The best way to mess with their heads is to totally ignore them. So many good companies have been killed by these people, why help them at all, even by helping them debug their system, or driving up their click rate.
Just wait: the next news release will boast about "how many millions" of search requests they've "already serviced" and how quickly they'll grow to surpass Google, etc. etc. etc. -- all so they have more Pablum to feed to the clueless army of MSCE IT slaves looking in every corner for justifications for keeping Microsoft around.
Correction, I have written millions of lines of code. I started coding in 1970, and I have never stopped, even when I held senior management positions.
If you think you can write code for one company and take it to another, have a look at your employment agreement. Nobody will probably ever catch you. But someday they might, like they think they've caught this asshole. And then you will sink yourself, and your colleagues, and your company.
Maybe you don't care -- after all, it isn't YOU they'll go after, you probably don't have anything worthwhile to get. But some day when you put your own money and sweat into your own company, as I have done three times since 1980, and am doing right now, you think about these things. You think very hard indeed.
Not odd at all. You're the one who got all PC on the parent, telling someone to lighten up who was actually being quite moderate with his criticism. But, since you insist, let's drill down on it. What is this a "proof of concept" (your words) for, exactly?
1) Sensor technology? Nope, been done. 2) Control systems for steering, throttle, brake? Nope, been done. 3) Putting it all together to autonomously navigate a vehicle? Nope, been done. 4) Doing something "via Linux" (whatever that means)? I doubt that Linux had much to do with the code that's running this thing, other than *not* providing hard-real-time response to interrupts, which makes it a questionable choice (for other than a student project) to begin with, but never mind.
No, this is just a cute little undergrad robotics project, and the kids probably learned a lot. Maybe their advisor even raised some money from Ford/Volvo for it. Kudos to everyone. But there is nothing new here.
Now, if the car had been autonomously parked in a really tight space, as the parent poster pointed out, that would have been much more impressive. It certainly would have impressed the hell out of my wife, who flunked her Bermuda driving test three times (parallel-parking in a space just a bit longer than the car). However, it still wouldn't have proved much, other than someone took the time (as these folks clearly did not) to work out an algorithm to do it.
As far as your analogy is concerned ("parking in the real world"), the idea that such a system would ever be trusted in the real world is really far-fetched to begin with. Sensors fail, computers freeze up, etc. What manufacturer would accept liability for failure? Is there someone lying down behind the car? Is one of the parked cars about to move, or moving? What about the blind guy about to intersect our path who isn't in sensor range yet, but we better nail the brake NOW or our momentum will kill him? How about the car behind us that just changed lanes and has only realized in the last few milliseconds that we are backing into a space, and we better stop NOW so he has more distance to react? And so on.
I'll buy you a beer, that's better than Valium. Peace.
Happens all the time. You must be clean if you hire developers from the competition. Keep programming notebooks, write everything down, code from scratch. Nothing can be re-used.
Take a Valium. The post you're criticizing was being charitable. The turning radius that they chose was obviously way too gentle for a real situation, hence the huge parking space. And at the end of all this, the car didn't end up parallel to the curb. If I stack the deck and can't even win the hand, is that a proof of concept?
It was a cute senior project, they made a nice movie, and they graduated. Good for them. But this isn't a proof of anything.
I lived in Nashua for a lot of years (not anymore), I'm with you, no way would I have done that Route 3 commute even if it wasn't torn up. Maybe with the 3 lanes it will be better someday, but I doubt it.
Can't talk about what we're doing, but we'll be out of the closet in a year or so, along with Gates's 60,000 CS grads (jesus). Ciao.
A few years ago I moved a guy like that into a position where he could do no more harm. He had written about 6 inches of Oracle SQL which we ultimately replaced with a couple of streamlined programs and MySQL. To the end of his tenure with the organization, he never admitted that his approach was flawed, and he never owned up to the fact that his "solution" would have put us out of business.
Along with DBA-ness comes "processor vendor-ness." Just as a DBA is deeply motivated to continue to flog his particular experience niche, so the "processor vendor maven" is deeply motivated to continue to flog his favorite hardware. In Our Hero's case, it was Sun. Sun could do no wrong. Even after we ripped out the Sun boxes and replaced them with Linux Intel boxes that were demonstrably faster and cheaper, this guy continued to preach Sun to whomever would listen. People finally stopped listening.
Sure, and it's also possible to get great performance from SQL Server, Essbase, SAP Data Warehouse, or a dozen other ROLAP, MOLAP, or HOLAP products. Problem is, mere mortals like that poor finance guy aren't going to be able to get there from here. The accounting system vendor drops Crystal Reports in his lap, tells him to "write any report you want," and then he sits there for hours wondering why his first join hasn't finished yet.
Thanks for the note! I guess Pascal and Date will solve all these problems for us, so no worries...;-)
Your finance guy is having the same problem that everyone has with database performance when the row count gets high. Commercial database products do not perform efficiently on many millions of records, no matter what they claim.
Pascal and Date wave their hands at this, blaming vendors for failing on the implementation side - "if only they really understood what they were doing," blah blah blah. Pascal of course then admits, "I'm not a programmer." Pascal sees nothing in relational theory that presupposes that a database should slow down when there are millions of rows. Instead, he blames vendors for "mixing physical and logical models," which is evidently the "fault" of SQL.
I'm not smart enough to know if he's right or wrong. I am smart enough, though, to figure the chances of a database company starting from scratch and flogging a new query language. "Not good," would be my assessment, unless the product could do something remarkable, like provide reasonable join performance on huge datasets.
Don't get me wrong: I find Pascal and Date amusing, useful, and precise. I love Date's dismantling of UML and OO terminology. I enjoy Pascal's digs at idiots who clearly don't understand anything. But it's put up or shut up time for both of these guys, and Darwen as well. Let's see them take their ideas into practice. I'd love to see an RDBMS with OLAP performance, for example. If it's so easy, bring it on!
In the meantime, we'll suffer with what we've got, I guess. Maybe if I make a bazillion bucks someday I'll throw a few million Pascal's way and see what happens. Whatever comes out of it, it's likely to be amusing!
I personally hired six people in the Boston area 2001-2002, at high salaries: 1 CS degree, 2 EE+CS degrees, 1 EE, 1 PhD math, 1 PhD physics.
I have two CS degrees myself.
Either you and your friends didn't apply, or we didn't find you. Sorry.
I wouldn't discourage people from studying other topics. And (as you see) I'm not averse to hiring those people for CS jobs, if they're smart, skilled, and motivated -- as long as there are CS people to monitor them to make sure they don't charge down the wrong path, which they tried to do on several occasions.
You may think "sorting is evil," but I have to worry about sorting algorithms on a daily basis in my current gig. Sorting and searching -- and hashing -- are, as you point out, tools of the trade. You know them or you do not. If you don't, you are less valuable, period.
I don't know for sure whether our universities have trained too many CS graduates, but I suspect not. Programming is hard, and the IQ bell curve suggests that only some people will be able to do it effectively. Sure, at the moment there are a lot of people who think they are programmers, who got some dot-bomb job writing HTML or PHP or something, or who landed some IT job fixing people's PC's or configuring firewalls, and who are now unemployed, but so what? Like the COBOL drones of the 60's and 70's, they aren't programmers, and never will be.
I've been in the business for 27 years, and I have the luxury now of only working with great programmers. There never were that many great programmers out there, and I don't see a lot of evidence that this has changed. We certainly weren't overwhelmed with qualified CS people applying for our positions, despite the condition of the economy at the time. If Gates is experiencing the same phenomenon in Redmond, I understand his concern.
One doesn't have to pass an arbitrary test -- including ours -- to be effective.
But, my experience has been that promising applications have failed in production because the coding team did not understand basic things, like choosing correct algorithms when sorting and searching, or recognizing the implications of programming decisions that impact memory management, or structuring the application properly by creating EJB's instead of diving into the database all over the place directly from servlets. To the question raised by the parent post, a CS degree is helpful because it exposes its holder to the notion that certain key algorithms and decisions require very close examination and thought.
Sorry, I'll have to agree with Gates on this one. CS degrees -- good ones -- mean that the graduate should understand important fundamentals. Algorithms. Data structures. Computer architecture. Compiler design. Operating system design. Digital logic design.
Too many people, sometimes even people like yourself with "35 years in the computer field," don't know very basic things, things that can make them less effective than properly-trained CS graduates.
There are a relatively small number of interview questions for candidates that help us to drill down on this:
"Walk up to the whiteboard. Diagram a hash routine. Describe why and how it works."
"Pick a processor, any processor, real or imaginary. Go up to the whiteboard and write 5-10 lines of code, including an if-then statement, in any language you please. Hand-compile those lines of code into the machine language for your chosen processor. Identify optimizations that you would expect a modern compiler to have made."
"Go up to the whiteboard and diagram a sort routine. Explain how it works, and estimate its expected performance as a function of the length of the list to be sorted."
"Fifteen UARTs interrupt a processor randomly, at intervals of less than 1 millisecond. Go to the whiteboard and diagram the code needed to handle this without losing data."
"List as many circumstances as you can think of where a virtual memory operating system needs to keep one of its pages in real memory."
There are many more of these questions, of course, but one doesn't have to ask them all in order to make a quick and accurate assessment.
I have found over 17 years as a hiring manager that non-CS graduates often have troubling gaps in their knowledge base. Not everyone has the intellectual curiosity to cover, completely on their own, all the topics introduced in a rigorous 4-year degree program. And, on-the-job experience appears to be a poor substitute.
I wouldn't have been impressed, either, if you had spelled "experiance" that way on your resume.
Here's a tip: don't give me a reason to throw you on the "reject" pile. It's very difficult to distinguish one recent grad from another, and I'm basically looking to winnow down the big pile of paper as quickly as I can. Those reasons include poor spelling and bad grammar.
I've learned in my long career as a hiring manager that people who can write well (and spell) are more effective and better programmers than people who cannot. This is a very high correlation --.8 or.9, I would say.
A correlation is not, of course, a causal relationship. I'm sure there are people who spell and write incredibly badly who could code circles around me. I'm just saying it's rare, and when I'm faced with 300 resumes to go through, and no time to read them, I have no choice but to perform triage with the techniques that have worked for me over time.
Circa 1985 there was a big push by a handwriting biometrics company in the UK. They claimed to be able to reduce a signature to a few hundred bytes that could be stored on a (then state-of-the-art) smart card.
Their "big insight" was to measure not only the relative shapes etc. of the signature, but also the speed with which each part of it was written. This was claimed to deliver really super terrific results.
We set up their system and ran some testing. Results were random. If you made it sensitive enough to seem secure, you had to sign about 50 times before you "got it right."
Obviously this technology didn't go anywhere, because nobody is flogging biometric signature scanning anymore (at least as far as I know).
The article, plus my experience, makes me wonder how much testing these guys do before they set the Marketing Drone Exaggeration Bit "on". Hell, what am I saying, I already know the answer. Not much.
The real information that you need is, "Can this person lead our team effectively?", not "Am I going to be a happy little camper?".
Leadership means promoting stars, firing incompetents, backing the right technical strategies, ensuring that Marketing and Sales are kept honest and under control, taking responsibility for mistakes, shielding the team from political wars, and so on.
It also means producing good products that work and that succeed in the marketplace, whilst doing all of the above.
A lot of the interview is instinct. Some of it is references (get some). Most of it is track record.
In my opinion, the person should know A LOT about technology. You should be able to explain to him/her what you do. S/he should be able to understand it, perhaps not in gory detail, but well enough to comprehend the basic principles of what you are doing, why you are doing it, what you hope to achieve, what the obstacles are, and where you think you are on the timeline.
Very little will be accomplished by asking artificial or general questions or proposing test scenarios. I wouldn't ask any of the above questions, for example.
Just my opinion. I've been a software manager for 21 years.
Hmmm, comparing Brooks to Fenimore Cooper is a little harsh, too, my friend. Remember Twain's demolition of Cooper and the "Cooper Indian?" Fred Brooks deserves better.
Brooks had to build an operating system for a modern computer (yes, the 360 architecture is still thriving today) with stone knives and bear skins. His tools were Xerox machines, file cabinets, secretaries, and punch cards. His insights on the process -- what worked and what didn't -- are remarkable, and they are worth reading today.
However, I certainly agree that Brooks' conclusions about the optimum way to run a software project (the "surgeon," etc.) were unconvincing then, and remain unconvincing today. We should look to Brooks not for solutions, but for very clear statements and characterizations of the problems (and immutable rules) facing a large development team.
As far as what Brooks accomplished, remember that the basic concepts of OS 360 live on, 40+ years later, in most every IBM mainframe operating system, except for VM derivatives. Sure, we don't run OS/MFT any more, but all the stuff I remember from the 70's, which was the same as it was in the 60's, is STILL AROUND. I could walk into an IBM mainframe shop tomorrow, put together a JCL deck using what I remember from 1975, and it will work. That is, bluntly, amazing.
It seems to me that the Mythical Man-Month is still a "must read." The XP-centric musings of the newbie reviewer are irritating and puerile, and in about 10 years he'll be very sorry he wrote the piece. But, then again, what human being doesn't wish he could apply today's wisdom to what he did 10 years ago? So I won't join the critics in lambasting him.
If your average PHB reads just the first few chapters -- which is easy -- s/he will be a far more effective manager. Anyone in the field who hasn't read this book should do so. Period.
Slashdot Mirror
Looks like the wired article has copy-pasted and not done any real work.
And... this is a surprise to you?
Well, the first part of your comment, while interesting, isn't very compelling. We can argue about root causes and trade theories all day, but that isn't data. In order to make a social policy determination, a statistical causal connection has to be established between the process you are describing and measurable changes in societal behavior, hopefully with multivariate analysis such as multiple regression, where we can throw as many variables as we can think of into the mix to see which one really matters. As Huckleberry Finn once said, "You can reckon till the cows come home, but that don't prove nothin'."
Will pr0n cause some sicko to get sicker? Maybe. I don't think anyone has the data to make that claim. Hell, for all we know, pr0n helps the sicko sublimate his sicko desires.
As far as the correlations between toking/drinking/smoking and coke/heroin addiction are concerned, one could argue that drinkers and smokers should be actively converted to tokers! Correlation is not causality, as you point out.
Hmmm, where to begin?
1) Do you really think that sex on TV, or women wearing tighter or more revealing clothing, causes more illegitimate children and more sex crimes? Where are the data to support this? I recall reading that illegitimacy is actually on the decline at the moment.
2) Why don't you also complain about violence on TV? People have been dying like flies on TV shows and movies since the 50's. Are we more violent because TV shows and movies are making us violent? People have tried to make this argument, but the data don't support it.
3) Hey, maybe it's all the fault of our local TV news programs! That's what Michael Moore suggests ("Bowling for Columbine"). Maybe we should prevent the local news from carrying sensational stories about murders and stabbings, so we'll all feel safer and for some reason stop killing each other (there are no data to support this, either).
You seem like a well-meaning person. Unfortunately you have drawn a conclusion that isn't supported by any data. The pinups of the 40's, for example, hardly seem racy today -- but back then, a glimpse of thigh was big big news, indeed. Had you been around back then (were you?), you probably would have joined the ranks of the outraged at seeing the famous Betty Grable leg shot.
Just checking -- how do you feel about recreational drugs, like marijuana? Do you think that marijuana starts people down a slippery slope to crank, coke, heroin, and so forth? No evidence for that, either, I'm afraid.
If The Gimp has a security issue a Linux vendor will issue an alert for it.
If Photoshop has a security issue, MS won't inform you.
This is exactly the point. All such comparisons are apples to oranges, and are fundamentally meaningless.
There is a difference between sales and marketing. As you point out, salespeople have to be reigned in and controlled, because they will sell anything. Many software salespeople truly don't understand the limitations of their product, and will try to put a square peg in a round hole if they can get the sale, even if that means shipping an engineer with every unit.
What the article was talking about was a Marketing organization that wasn't thinking straight. There is a profound difference. In this case, Marketing was out of control, not Sales. I have seen this many times. They made one of the most common mistakes that marketing organizations make, namely checklist selling against the competition. This is a no-win situation. First one product is "ahead", then the other, wake me up when you have something new to say.
In order to really make a dent in a market, you have to change the playing field, not just tweak the product. Microsoft is scary/dangerous not because they release new versions of Office occasionally, but because from time to time they do really profound things like boot everyone else out of the Office business by betting on Windows when everyone thought Windows was a non-starter. Remember when Excel used to ship with its own Windows shell, before Windows was available? No? Well, I do. I remember the difference between that early Excel and Lotus, too. Lotus had more checklist features for a long time, but Excel -- it was just plain beautiful and fun to use. Once you used it, you couldn't go back to Lotus, even if it had some bullshit statistical function that Excel didn't have (yet).
Now THAT'S product marketing -- long term perspective, vision, eye on the goal line, pick your cliche of the day.
Funny, but this person is not far off from what would thoroughly discourage the Chinese authorities. What if everyone starts sending bullshit revolutionary messages? Let 'em try to lock the whole country up.
They should be much more worried about tight little cells that are already speaking l33t-equivalent, except it's a l33t that nobody knows but the conspirators.
Right.
Note that this system is infinitely better than the radio "traffic reports," like those in Boston on 1030 WBZ. The announcers already know from experience where all the slowdowns are likely to be, so they just repeat the same B.S. every morning, true or false, until they get lucky and their helicopter spots something, or the State Police radio in an accident.
I used to commute the Mass Pike eastbound from 495 into 128/95, and I can count on the fingers of one hand the times that the "traffic report" was actually accurate.
As far as people paying attention to the web site and changing their route based on 30 minute or 60 minute advanced prediction, thus screwing up the "prediction," that's only an issue if you need advance warning before you leave the house. What's really needed is a real-time decision when you come up against a junction point. Which way? Tell me now. Should be easy enough to do with a real-time feed from your car to the model.
Not that there's that many obvious alternate route choices around Boston anyway, but it sure would be helpful to have precise information on the jam-ups for those of us who know the back roads.
Good point. However, a lot of things that Slashdot trolls have been complaining about since '98 continue to be true today. How about the XP dispatcher? Still can't get smooth performance without a second CPU. Corbato et al solved this problem in 1961. There is no excuse.
I refuse to use this piece of software, period. Redmond are pulling their usual stunt of releasing crap just for the publicity, so all their shills can say, "Golly wow, Microsoft's gonna have a much better search engine real soon now."
I'm so sick of this strategy I could puke. The best way to mess with their heads is to totally ignore them. So many good companies have been killed by these people, why help them at all, even by helping them debug their system, or driving up their click rate.
Just wait: the next news release will boast about "how many millions" of search requests they've "already serviced" and how quickly they'll grow to surpass Google, etc. etc. etc. -- all so they have more Pablum to feed to the clueless army of MSCE IT slaves looking in every corner for justifications for keeping Microsoft around.
Correction, I have written millions of lines of code. I started coding in 1970, and I have never stopped, even when I held senior management positions.
If you think you can write code for one company and take it to another, have a look at your employment agreement. Nobody will probably ever catch you. But someday they might, like they think they've caught this asshole. And then you will sink yourself, and your colleagues, and your company.
Maybe you don't care -- after all, it isn't YOU they'll go after, you probably don't have anything worthwhile to get. But some day when you put your own money and sweat into your own company, as I have done three times since 1980, and am doing right now, you think about these things. You think very hard indeed.
I advise you to do the same.
Not odd at all. You're the one who got all PC on the parent, telling someone to lighten up who was actually being quite moderate with his criticism. But, since you insist, let's drill down on it. What is this a "proof of concept" (your words) for, exactly?
1) Sensor technology? Nope, been done.
2) Control systems for steering, throttle, brake? Nope, been done.
3) Putting it all together to autonomously navigate a vehicle? Nope, been done.
4) Doing something "via Linux" (whatever that means)? I doubt that Linux had much to do with the code that's running this thing, other than *not* providing hard-real-time response to interrupts, which makes it a questionable choice (for other than a student project) to begin with, but never mind.
No, this is just a cute little undergrad robotics project, and the kids probably learned a lot. Maybe their advisor even raised some money from Ford/Volvo for it. Kudos to everyone. But there is nothing new here.
Now, if the car had been autonomously parked in a really tight space, as the parent poster pointed out, that would have been much more impressive. It certainly would have impressed the hell out of my wife, who flunked her Bermuda driving test three times (parallel-parking in a space just a bit longer than the car). However, it still wouldn't have proved much, other than someone took the time (as these folks clearly did not) to work out an algorithm to do it.
As far as your analogy is concerned ("parking in the real world"), the idea that such a system would ever be trusted in the real world is really far-fetched to begin with. Sensors fail, computers freeze up, etc. What manufacturer would accept liability for failure? Is there someone lying down behind the car? Is one of the parked cars about to move, or moving? What about the blind guy about to intersect our path who isn't in sensor range yet, but we better nail the brake NOW or our momentum will kill him? How about the car behind us that just changed lanes and has only realized in the last few milliseconds that we are backing into a space, and we better stop NOW so he has more distance to react? And so on.
I'll buy you a beer, that's better than Valium. Peace.
Happens all the time. You must be clean if you hire developers from the competition. Keep programming notebooks, write everything down, code from scratch. Nothing can be re-used.
Take a Valium. The post you're criticizing was being charitable. The turning radius that they chose was obviously way too gentle for a real situation, hence the huge parking space. And at the end of all this, the car didn't end up parallel to the curb. If I stack the deck and can't even win the hand, is that a proof of concept?
It was a cute senior project, they made a nice movie, and they graduated. Good for them. But this isn't a proof of anything.
I lived in Nashua for a lot of years (not anymore), I'm with you, no way would I have done that Route 3 commute even if it wasn't torn up. Maybe with the 3 lanes it will be better someday, but I doubt it.
Can't talk about what we're doing, but we'll be out of the closet in a year or so, along with Gates's 60,000 CS grads (jesus). Ciao.
Beautiful post, I loved it.
A few years ago I moved a guy like that into a position where he could do no more harm. He had written about 6 inches of Oracle SQL which we ultimately replaced with a couple of streamlined programs and MySQL. To the end of his tenure with the organization, he never admitted that his approach was flawed, and he never owned up to the fact that his "solution" would have put us out of business.
Along with DBA-ness comes "processor vendor-ness." Just as a DBA is deeply motivated to continue to flog his particular experience niche, so the "processor vendor maven" is deeply motivated to continue to flog his favorite hardware. In Our Hero's case, it was Sun. Sun could do no wrong. Even after we ripped out the Sun boxes and replaced them with Linux Intel boxes that were demonstrably faster and cheaper, this guy continued to preach Sun to whomever would listen. People finally stopped listening.
Sure, and it's also possible to get great performance from SQL Server, Essbase, SAP Data Warehouse, or a dozen other ROLAP, MOLAP, or HOLAP products. Problem is, mere mortals like that poor finance guy aren't going to be able to get there from here. The accounting system vendor drops Crystal Reports in his lap, tells him to "write any report you want," and then he sits there for hours wondering why his first join hasn't finished yet.
;-)
Thanks for the note! I guess Pascal and Date will solve all these problems for us, so no worries...
Your finance guy is having the same problem that everyone has with database performance when the row count gets high. Commercial database products do not perform efficiently on many millions of records, no matter what they claim.
Pascal and Date wave their hands at this, blaming vendors for failing on the implementation side - "if only they really understood what they were doing," blah blah blah. Pascal of course then admits, "I'm not a programmer." Pascal sees nothing in relational theory that presupposes that a database should slow down when there are millions of rows. Instead, he blames vendors for "mixing physical and logical models," which is evidently the "fault" of SQL.
I'm not smart enough to know if he's right or wrong. I am smart enough, though, to figure the chances of a database company starting from scratch and flogging a new query language. "Not good," would be my assessment, unless the product could do something remarkable, like provide reasonable join performance on huge datasets.
Don't get me wrong: I find Pascal and Date amusing, useful, and precise. I love Date's dismantling of UML and OO terminology. I enjoy Pascal's digs at idiots who clearly don't understand anything. But it's put up or shut up time for both of these guys, and Darwen as well. Let's see them take their ideas into practice. I'd love to see an RDBMS with OLAP performance, for example. If it's so easy, bring it on!
In the meantime, we'll suffer with what we've got, I guess. Maybe if I make a bazillion bucks someday I'll throw a few million Pascal's way and see what happens. Whatever comes out of it, it's likely to be amusing!
I personally hired six people in the Boston area 2001-2002, at high salaries: 1 CS degree, 2 EE+CS degrees, 1 EE, 1 PhD math, 1 PhD physics.
I have two CS degrees myself.
Either you and your friends didn't apply, or we didn't find you. Sorry.
I wouldn't discourage people from studying other topics. And (as you see) I'm not averse to hiring those people for CS jobs, if they're smart, skilled, and motivated -- as long as there are CS people to monitor them to make sure they don't charge down the wrong path, which they tried to do on several occasions.
You may think "sorting is evil," but I have to worry about sorting algorithms on a daily basis in my current gig. Sorting and searching -- and hashing -- are, as you point out, tools of the trade. You know them or you do not. If you don't, you are less valuable, period.
I don't know for sure whether our universities have trained too many CS graduates, but I suspect not. Programming is hard, and the IQ bell curve suggests that only some people will be able to do it effectively. Sure, at the moment there are a lot of people who think they are programmers, who got some dot-bomb job writing HTML or PHP or something, or who landed some IT job fixing people's PC's or configuring firewalls, and who are now unemployed, but so what? Like the COBOL drones of the 60's and 70's, they aren't programmers, and never will be.
I've been in the business for 27 years, and I have the luxury now of only working with great programmers. There never were that many great programmers out there, and I don't see a lot of evidence that this has changed. We certainly weren't overwhelmed with qualified CS people applying for our positions, despite the condition of the economy at the time. If Gates is experiencing the same phenomenon in Redmond, I understand his concern.
One doesn't have to pass an arbitrary test -- including ours -- to be effective.
But, my experience has been that promising applications have failed in production because the coding team did not understand basic things, like choosing correct algorithms when sorting and searching, or recognizing the implications of programming decisions that impact memory management, or structuring the application properly by creating EJB's instead of diving into the database all over the place directly from servlets. To the question raised by the parent post, a CS degree is helpful because it exposes its holder to the notion that certain key algorithms and decisions require very close examination and thought.
Too many people, sometimes even people like yourself with "35 years in the computer field," don't know very basic things, things that can make them less effective than properly-trained CS graduates.
There are a relatively small number of interview questions for candidates that help us to drill down on this:
There are many more of these questions, of course, but one doesn't have to ask them all in order to make a quick and accurate assessment.
I have found over 17 years as a hiring manager that non-CS graduates often have troubling gaps in their knowledge base. Not everyone has the intellectual curiosity to cover, completely on their own, all the topics introduced in a rigorous 4-year degree program. And, on-the-job experience appears to be a poor substitute.
I wouldn't have been impressed, either, if you had spelled "experiance" that way on your resume.
.8 or .9, I would say.
Here's a tip: don't give me a reason to throw you on the "reject" pile. It's very difficult to distinguish one recent grad from another, and I'm basically looking to winnow down the big pile of paper as quickly as I can. Those reasons include poor spelling and bad grammar.
I've learned in my long career as a hiring manager that people who can write well (and spell) are more effective and better programmers than people who cannot. This is a very high correlation --
A correlation is not, of course, a causal relationship. I'm sure there are people who spell and write incredibly badly who could code circles around me. I'm just saying it's rare, and when I'm faced with 300 resumes to go through, and no time to read them, I have no choice but to perform triage with the techniques that have worked for me over time.
Sorry, you still have no attractiveness of which you are aware. Whatever that means.
Circa 1985 there was a big push by a handwriting biometrics company in the UK. They claimed to be able to reduce a signature to a few hundred bytes that could be stored on a (then state-of-the-art) smart card.
Their "big insight" was to measure not only the relative shapes etc. of the signature, but also the speed with which each part of it was written. This was claimed to deliver really super terrific results.
We set up their system and ran some testing. Results were random. If you made it sensitive enough to seem secure, you had to sign about 50 times before you "got it right."
Obviously this technology didn't go anywhere, because nobody is flogging biometric signature scanning anymore (at least as far as I know).
The article, plus my experience, makes me wonder how much testing these guys do before they set the Marketing Drone Exaggeration Bit "on". Hell, what am I saying, I already know the answer. Not much.
The real information that you need is, "Can this person lead our team effectively?", not "Am I going to be a happy little camper?".
Leadership means promoting stars, firing incompetents, backing the right technical strategies, ensuring that Marketing and Sales are kept honest and under control, taking responsibility for mistakes, shielding the team from political wars, and so on.
It also means producing good products that work and that succeed in the marketplace, whilst doing all of the above.
A lot of the interview is instinct. Some of it is references (get some). Most of it is track record.
In my opinion, the person should know A LOT about technology. You should be able to explain to him/her what you do. S/he should be able to understand it, perhaps not in gory detail, but well enough to comprehend the basic principles of what you are doing, why you are doing it, what you hope to achieve, what the obstacles are, and where you think you are on the timeline.
Very little will be accomplished by asking artificial or general questions or proposing test scenarios. I wouldn't ask any of the above questions, for example.
Just my opinion. I've been a software manager for 21 years.
Hmmm, comparing Brooks to Fenimore Cooper is a little harsh, too, my friend. Remember Twain's demolition of Cooper and the "Cooper Indian?" Fred Brooks deserves better.
Brooks had to build an operating system for a modern computer (yes, the 360 architecture is still thriving today) with stone knives and bear skins. His tools were Xerox machines, file cabinets, secretaries, and punch cards. His insights on the process -- what worked and what didn't -- are remarkable, and they are worth reading today.
However, I certainly agree that Brooks' conclusions about the optimum way to run a software project (the "surgeon," etc.) were unconvincing then, and remain unconvincing today. We should look to Brooks not for solutions, but for very clear statements and characterizations of the problems (and immutable rules) facing a large development team.
As far as what Brooks accomplished, remember that the basic concepts of OS 360 live on, 40+ years later, in most every IBM mainframe operating system, except for VM derivatives. Sure, we don't run OS/MFT any more, but all the stuff I remember from the 70's, which was the same as it was in the 60's, is STILL AROUND. I could walk into an IBM mainframe shop tomorrow, put together a JCL deck using what I remember from 1975, and it will work. That is, bluntly, amazing.
It seems to me that the Mythical Man-Month is still a "must read." The XP-centric musings of the newbie reviewer are irritating and puerile, and in about 10 years he'll be very sorry he wrote the piece. But, then again, what human being doesn't wish he could apply today's wisdom to what he did 10 years ago? So I won't join the critics in lambasting him.
If your average PHB reads just the first few chapters -- which is easy -- s/he will be a far more effective manager. Anyone in the field who hasn't read this book should do so. Period.