But if you may need the data 5 years or more from now, tape is clearly far superior.
You have much luck getting data back from a tape five years later?
First you have to find the tape. You can't have misplaced it and you can't have reused it due to the damn high cost of magnetic tape.
Then you have to find a drive that can read the tape. The one you wrote it with died two years ago, its no longer manufactured and oh darn none of the three you picked up off ebay use the same compression format.
Next you need the old backup software. You've been using Acme Archiver for the past three years; It doesn't understand the old SuperBackup format and unfortunately SuperBackup only ran in DOS with an 8-bit ISA SCSI card.
Finally you have to pray that the tape is still good. They're like floppy disks; they go bad just sitting on the shelf.
Buddy, I've been there. It ain't pretty. So for the last 7 years I've stored my backups on hard disks. No pain! No pain!
I can speak to this issue from the other side of the desk.
1. Yes, you are supposed to teach yourself. When I hire, I look for folks who are always learning, all day, every day. "Training" means I have to pay good money to have you absent from work for a week every couple months so that you can come back and spout off about the way X-Corp says it should be done instead of the way that would actually integrate into the system I spent years building. No thanks!
If you need a reference book, I'll buy it for you. If you want to take some night courses in computer science so that you can get a better grounding in the fundamentals then I'll help out in whatever way I can. Just don't waste my time or yours with these so-called training courses.
2. I expect that you'll spend a certain amount of time at work experimenting and gathering knowledge about the software and hardware you use to make my systems run. That's part of the job. You don't have to know everything ahead of time, you just have to know how to figure it out.
If you were a consultant it would be different. I'll pay a consultant twice what I pay you because I expect him to already have the answers when he hits my door. If HE doesn't know, he won't be invited back and if its bad enough he won't be paid. You, as an employee, have more leeway.
3. I expect that you'll spend a certain amount of time at home using similar technologies in the pursuit of your own hobbies. I expect that you'll learn things there that you apply to work just as you learn things at work that you'll apply to your hobbies.
Its not about taking your work home with you; its about getting paid to do work that you enjoy. This work I do was my hobby before it became my career. I enjoy it immensely and I want people around me who feel the same way. If you're just here for the paycheck then I hired the wrong guy. You won't deliver the standard of quality I want because when push comes to shove you just don't care.
Now, if you're like four out of five people out there then having read this you think I'm full of shit. And that's OK. There are plenty of suck jobs out there that will pay you well enough to drive a nice car and vacation at the beach. I wish you all the best in life and may you find your bliss.
But if you're the one out of five that finds the job worth working for its own sake then I want you working with me.
ATA and SATA drives are a great choice for online backup. Its pretty easy to put several terabytes worth in a box these days, software raid-5 them with Linux and then use tar and gzip. The price is not exceptionally higher than tapes either and the reliability (i.e. your success rate restoring data) is superior.
I'd be happy too. The top bracket on the $1 in salaried income is a twice what the top bracket is on the capitol gains tax they pay for the stock sale. If they pay even that... They could dodge by having a personal C-corp that holds the stock. As long as the corp reinvests the money elsewhere before the end of the fiscal year they don't pay any taxes on it at all. The personal corp could invest in lots of things... houses, cars, jewelry...
The irony here is that they don't need Google's records. Nearly every Federal agency has a firewall or http proxy that keeps logs of its users' web requests. I helped operate one back in '97 and you'd be astonished by what folks search for when they think they're in the office alone. If the Bush administration wants a lower bound on pornagraphy searches, they need only search the records they already have of Federal employees' activity.
Of course, that would mean admitting that some Federal employees do this kind of thing on the taxpayers' dime.
You are absolutely correct, but my comments re: Debian were targeted at the statement, "the differentiator for customers is [...] which vendor makes the patching and updating experience the least complex, most efficient and easiest to manage."
As you say, that's not one of Gentoo's goals -- they target the cutting edge. Smooth upgrades are one of Debian's goals, and my point was do one heck of a lot better job of it than Windows.
I was also dissing Red Hat and SuSE -- smooth updates are one of their goals too and they do a mediocre job of it, little better than Windows.
Just so. My experience with Red Hat, SuSE and Gentoo has been than there is a significant quantity of breakage associated with routine updates. Most of it is minor breakage (the update renames your config file and copies in the new upstream version) but its breakage nonetheless. In a way minor breakage is worse: having a mission critical server fail is bad, but having a mission critical server deactivate a security configuration or give out bad data is deadly.
My point about Debian is that during minor updates, there is almost never any breakage at all, minor or otherwise. I've had a problem on this score once in the decade I've used it on some 40 servers and even that one was trivial. You only see breakage during upgrades to new major releases and those only once every couple of years.
Wisely or not, Google wants to be a new sort of deus ex machina.
How exactly is Google's desire to build an AI that passes the turing test in any way a a deus ex machina?
Deus ex machina describes an event that an author artificially inserts into a story in order to move the plot in the desired direction. When the otherwise brilliant good guy does something out of character and incredibly boneheaded because he has to be down and out in the next chapter, that's a deus ex machina.
The term comes from Greek and Roman plays where wooden stage machinery was used to simulate the gods coming down from on high and making a major change to the course of events. When Zeus comes on stage and throws around a few lightning bolts its a deus ex machina.
Has nothing to do with machines in any modern sense of the word.
Huh, maybe that's why I can still see. I don't get out as much, but whenever I need to think something through I look away from the monitor and out the window, focusing on random distant objects.
So the PC knows if I'm pissed, so what? What's the point of the exercise? If I'm pissed at the computer its either A) crashing or otherwise malfunctioning or B) screwing up in a Do What I Mean (DWIM) situation.
In case A, the activity of yet another piece of software in the system is almost certain to make the situation worse, increasing my anger.
In case B, well, perhaps some sort of feedback mechanism can help the programmers figure out what parts of their user interface are pissing people off, but what good can it do on the spot? Pull up "clippy" to piss me off even more with some inane advice?
Generally they are situated that way to avoid tight, flow-reducing turns.
Okay, that's an argument I don't follow. You come in at 30 degrees from one side of the block and leave at 30 degrees on the other having passed directly over the CPU. Total turning radius: 60 degrees. How is that a tighter, flow-reducing turn than the 180 degrees needed to go straight down and then straight back up?
Once again the hoses come straight up off the CPU block. The one place that water coolers would be insanely useful is in 1U rackmount servers (1.75" tall). The hoses would have to come off the block at an angle to accomodate that though.
Of course [storing an second converted copy is] not [simplification]. It's easier to use, which is an entirely different thing.
You want to nitpick semantics? The point is it achieves the goal of improving the chance that future researchers can retrieve the data. I call that simplification. You can call it whatever floats your boat.
For easy stuff like word processor and spreadsheet documents, simply store a second copy that has been downconverted to ascii. For more obscure stuff (like CAD drawings) don't worry about it. An archivist can't possibly deal with every obscure data format out there, and clever hackers that can reverse engineer a format are relatively easy to come by should the contents of the document ever be desired. All you have to do is get them the bits and bytes on a media that they can handle.
Storing an additional version isn't "simplification".
Of course it is. You're giving the eventual retriever an easily read version he can get to conveniently as well as the original that he can dig in to if needed. Unless you can guarantee the the converted version is perfectly equivalent to the original (and you usually can't) you have to save the original anyway.
What you do for your own personal archives is, of course, a very different question. You may well find that the space savings justifies the loss of the original. While that may be appropriate for you personally its not reasonable for an organization charged with preserving the country's history.
an archivist doesn't have the freedom to simplify the format.
Sure he does. He shouldn't discard the original, but he has complete freedom to store an additional copy or copies in simplified and standardized formats. And given your comments on the relative size of the alternate versions, such additions would be relatively cheap.
What if the email is encrypted? What if the author wrote using code-words that only the recipient could understand? Answer: Don't worry about it. You take the common word-processor formats and store a second copy as ascii text. You take the commone spreadsheet formats and store a copy as ascii.csv files. Pick formats for graphics, audio and video where the primary criteria is its current ubiquity and store second copies of those too. Everything more obscure you simply store as is and don't sweat it. Tomorrow's computer experts will surely include folks competent at reverse-engineering as long as we can get them a raw copy of the data on a media they can read. Let them decide what's important enough to bother with.
And speaking of the storage media, don't overthink it. Its impractical to come up with some media that can last 200 years. Worse, its not cost effective. So, pick a media that can last 10 years with 5-nines reliability and plan on someone copying to a new media 10 years hence. How? COTS. Go out and buy some IDE hard drives. They're ubiquitous, cheap, and survive offline storage relatively well. They've been around for 15 years now and there's every reason to expect that computers 10 years from now will still be able to access IDE hard drives even if some other technology has overtaken them.
The 20 meg MFM drives of 1985 were obsolete in 1995, but you could still get the equipment to read them. The 500 meg IDE drives of 1995 are obsolete now, but even if your PC doesn't have PATA ports (most still do) you can get a $20 USB converter and read the old drive that way. As long as you plan on forward-converting the data every 10 years the media choice is simple: pick whatever is currently ubiquitous.
Even with substantial data recovery blocks (a la par2) you're still looking at a media cost of less than $1000 per terabyte for 10 years of storage with the expectation that in ten years a terabyte will only cost $100 for the following 10 years.
Seriously, this is not a hard problem. Look at past situations where data has become unrecoverable. They share some common characteristics:
1. Recovery was attempted too long after the media became obsolete, typically 20 years or more. Nobody is complaining about lost NASA data from the 1990's. Its the 1970's data they can't retrieve. Plan on forward-converting it all every 10 years and you won't lose it.
2. The storage media was some obscure magnetic tape format that never saw wide deployment so that it became unavailable at exactly the same time it became obsolete. That continues to be true of essentially all magnetic tape formats -- try recovering data from a DDS2 tape from just 10 years ago. Good luck finding a drive that matches the format used by the original. With the infamous '70s NASA data, for example, the chief problem isn't decoding the data (a good hacker could likely figure it out) but rather retrieving the data from tape. On the flip side, you still have folks around who fiddle with Commodore 64 data from 1985 -- widely available COTS equipment will win the longevity race every time.
3. No one left documentation (or the documentation did not survive) describing the data structures used to store the data on the media. So, make sure to store it in formats that are very well known such as RFC2822, ascii, and csv. Perhaps in a well documented FAT filesystem using open source tar, gzip and par2 (and store copies of the source code for that software with the data). These formats will be trivially understood 10 years from now, even if they're not then in common use.
electronic documents created today may not be legible on tomorrow's devices
ASCII text has been around for decades and oh by the way Internet-formatted email is 100% representable as ascii text since that's how its still transferred today.
This supposed problem is a real problem only for those with Exchange, Domino or Groupwise which creates email in custom, internal formats.
Re:Managers do need to be experts in their field
on
Java Is So 90s
·
· Score: 1
How, how, HOW in the world is the manager ever possibly supposed to [...] find and motivate good programmers, if he can't look at their code and figure out how good a programmer they are?
The same way managers have been managing for centuries: Look at the work product. A lawyer is measured by cases won. A doctor by his patients' health. If the result does what the customer wants then it has been done well. If it doesn't then it has been done poorly.
The problem with Java is that its trivial to hide poor craftsmanship behind a facade of apparantly working screens. Like a doctor prescribing a placebo until the patient dies. The manager doesn't know anything is amiss until he hands it to the customer who comes back two weeks later and says, "Why are the numbers wrong?"
Re:Managers do need to be experts in their field
on
Java Is So 90s
·
· Score: 1
I want a programming manager who knows how stuff is designed and coded *the best way*.
No you don't. You might think you do, but you'd hate his guts for constantly telling you to do it his way when you know perfectly well that your way is better. Programming is an art form. The notion of a "best" way is an illusion. It would be a soul-sucking work environment since he'd be too busy micromanaging to go schmooze the higher-ups and get the team the resources it needs.
Its not the manager's job to know the things you know. That's what he hired you for. Its his job to know all the things you don't.
Humans are wired to follow the requirements set by the Authority. The Authority is assumed to have a reason for those steps, even if its not apparent.
The thing is, if the process was set up by an expert, the non-obvious steps often do have importance. The guy on the assembly line drills a hole where he's told because that's what he was told to do. The fact that the hole is later an anchoring point for a strut is Somebody Else's Problem.
You might say the repetition of the steps designated by Authority is the foundation of our industrial and technological society. It enables cooperative labor without the individuals having to first understand the entire big picture.
Put another way, it means a team of human beings is greater than the sum of its members. A team of chimps isn't.
The problem with Java is the programmers
on
Java Is So 90s
·
· Score: 1
The problem with Java is that if you're a non-programming manager its very hard to tell the difference between a good java programmer and an incompetent java programmer. Both build software that displays a window on your screen which responds more or less correctly when you press the buttons. That the incompetent one simply caught and ignored all the exceptions isn't obvious until you're 18 months in to development with a product that can't be made to work. That the good programmer then says, "I told you so" is unhelpful.
Other languages are better about giving the manager indicators when the programmer is incompetent. For example, C crashes and burns while Perl drags along impossibly slow. A reasonably competent manager can look over the early prototypes and tell right off which of the team members know what they're doing. In Java, you don't know your programmers are digging you a hole until its too deep to get back out.
One might argue that the manager is incompetent if he can't tell the difference between good code and bad code, but that's really not the manager's job. The manager's job is to find and motivate good programmers (who know how to write good code). Java fails to provide the manager with the necessary tools to do accomplish that job.
Slashdot Mirror
But if you may need the data 5 years or more from now, tape is clearly far superior.
You have much luck getting data back from a tape five years later?
First you have to find the tape. You can't have misplaced it and you can't have reused it due to the damn high cost of magnetic tape.
Then you have to find a drive that can read the tape. The one you wrote it with died two years ago, its no longer manufactured and oh darn none of the three you picked up off ebay use the same compression format.
Next you need the old backup software. You've been using Acme Archiver for the past three years; It doesn't understand the old SuperBackup format and unfortunately SuperBackup only ran in DOS with an 8-bit ISA SCSI card.
Finally you have to pray that the tape is still good. They're like floppy disks; they go bad just sitting on the shelf.
Buddy, I've been there. It ain't pretty. So for the last 7 years I've stored my backups on hard disks. No pain! No pain!
I can speak to this issue from the other side of the desk.
1. Yes, you are supposed to teach yourself. When I hire, I look for folks who are always learning, all day, every day. "Training" means I have to pay good money to have you absent from work for a week every couple months so that you can come back and spout off about the way X-Corp says it should be done instead of the way that would actually integrate into the system I spent years building. No thanks!
If you need a reference book, I'll buy it for you. If you want to take some night courses in computer science so that you can get a better grounding in the fundamentals then I'll help out in whatever way I can. Just don't waste my time or yours with these so-called training courses.
2. I expect that you'll spend a certain amount of time at work experimenting and gathering knowledge about the software and hardware you use to make my systems run. That's part of the job. You don't have to know everything ahead of time, you just have to know how to figure it out.
If you were a consultant it would be different. I'll pay a consultant twice what I pay you because I expect him to already have the answers when he hits my door. If HE doesn't know, he won't be invited back and if its bad enough he won't be paid. You, as an employee, have more leeway.
3. I expect that you'll spend a certain amount of time at home using similar technologies in the pursuit of your own hobbies. I expect that you'll learn things there that you apply to work just as you learn things at work that you'll apply to your hobbies.
Its not about taking your work home with you; its about getting paid to do work that you enjoy. This work I do was my hobby before it became my career. I enjoy it immensely and I want people around me who feel the same way. If you're just here for the paycheck then I hired the wrong guy. You won't deliver the standard of quality I want because when push comes to shove you just don't care.
Now, if you're like four out of five people out there then having read this you think I'm full of shit. And that's OK. There are plenty of suck jobs out there that will pay you well enough to drive a nice car and vacation at the beach. I wish you all the best in life and may you find your bliss.
But if you're the one out of five that finds the job worth working for its own sake then I want you working with me.
price isn't much of an issue when the RAID fails is it?
The price is a huge issue. The cost of regenerating the lost data is enormous.
ATA and SATA drives are a great choice for online backup. Its pretty easy to put several terabytes worth in a box these days, software raid-5 them with Linux and then use tar and gzip. The price is not exceptionally higher than tapes either and the reliability (i.e. your success rate restoring data) is superior.
I'd be happy too. The top bracket on the $1 in salaried income is a twice what the top bracket is on the capitol gains tax they pay for the stock sale. If they pay even that... They could dodge by having a personal C-corp that holds the stock. As long as the corp reinvests the money elsewhere before the end of the fiscal year they don't pay any taxes on it at all. The personal corp could invest in lots of things... houses, cars, jewelry...
The irony here is that they don't need Google's records. Nearly every Federal agency has a firewall or http proxy that keeps logs of its users' web requests. I helped operate one back in '97 and you'd be astonished by what folks search for when they think they're in the office alone. If the Bush administration wants a lower bound on pornagraphy searches, they need only search the records they already have of Federal employees' activity.
Of course, that would mean admitting that some Federal employees do this kind of thing on the taxpayers' dime.
You are absolutely correct, but my comments re: Debian were targeted at the statement, "the differentiator for customers is [...] which vendor makes the patching and updating experience the least complex, most efficient and easiest to manage."
As you say, that's not one of Gentoo's goals -- they target the cutting edge. Smooth upgrades are one of Debian's goals, and my point was do one heck of a lot better job of it than Windows.
I was also dissing Red Hat and SuSE -- smooth updates are one of their goals too and they do a mediocre job of it, little better than Windows.
Just so. My experience with Red Hat, SuSE and Gentoo has been than there is a significant quantity of breakage associated with routine updates. Most of it is minor breakage (the update renames your config file and copies in the new upstream version) but its breakage nonetheless. In a way minor breakage is worse: having a mission critical server fail is bad, but having a mission critical server deactivate a security configuration or give out bad data is deadly.
My point about Debian is that during minor updates, there is almost never any breakage at all, minor or otherwise. I've had a problem on this score once in the decade I've used it on some 40 servers and even that one was trivial. You only see breakage during upgrades to new major releases and those only once every couple of years.
which vendor makes the patching and updating experience the least complex, most efficient and easiest to manage
Yeah, that would be Debian Linux: "apt-get update; apt-get upgrade". No reboot required and nothing breaks.
Wisely or not, Google wants to be a new sort of deus ex machina.
How exactly is Google's desire to build an AI that passes the turing test in any way a a deus ex machina?
Deus ex machina describes an event that an author artificially inserts into a story in order to move the plot in the desired direction. When the otherwise brilliant good guy does something out of character and incredibly boneheaded because he has to be down and out in the next chapter, that's a deus ex machina.
The term comes from Greek and Roman plays where wooden stage machinery was used to simulate the gods coming down from on high and making a major change to the course of events. When Zeus comes on stage and throws around a few lightning bolts its a deus ex machina.
Has nothing to do with machines in any modern sense of the word.
Huh, maybe that's why I can still see. I don't get out as much, but whenever I need to think something through I look away from the monitor and out the window, focusing on random distant objects.
So the PC knows if I'm pissed, so what? What's the point of the exercise? If I'm pissed at the computer its either A) crashing or otherwise malfunctioning or B) screwing up in a Do What I Mean (DWIM) situation.
In case A, the activity of yet another piece of software in the system is almost certain to make the situation worse, increasing my anger.
In case B, well, perhaps some sort of feedback mechanism can help the programmers figure out what parts of their user interface are pissing people off, but what good can it do on the spot? Pull up "clippy" to piss me off even more with some inane advice?
Generally they are situated that way to avoid tight, flow-reducing turns.
Okay, that's an argument I don't follow. You come in at 30 degrees from one side of the block and leave at 30 degrees on the other having passed directly over the CPU. Total turning radius: 60 degrees. How is that a tighter, flow-reducing turn than the 180 degrees needed to go straight down and then straight back up?
Once again the hoses come straight up off the CPU block. The one place that water coolers would be insanely useful is in 1U rackmount servers (1.75" tall). The hoses would have to come off the block at an angle to accomodate that though.
Of course [storing an second converted copy is] not [simplification]. It's easier to use, which is an entirely different thing.
You want to nitpick semantics? The point is it achieves the goal of improving the chance that future researchers can retrieve the data. I call that simplification. You can call it whatever floats your boat.
Just how many CAD drawings do you think are flying around in the White House email?
Yep except what about other documents?
For easy stuff like word processor and spreadsheet documents, simply store a second copy that has been downconverted to ascii. For more obscure stuff (like CAD drawings) don't worry about it. An archivist can't possibly deal with every obscure data format out there, and clever hackers that can reverse engineer a format are relatively easy to come by should the contents of the document ever be desired. All you have to do is get them the bits and bytes on a media that they can handle.
Storing an additional version isn't "simplification".
Of course it is. You're giving the eventual retriever an easily read version he can get to conveniently as well as the original that he can dig in to if needed. Unless you can guarantee the the converted version is perfectly equivalent to the original (and you usually can't) you have to save the original anyway.
What you do for your own personal archives is, of course, a very different question. You may well find that the space savings justifies the loss of the original. While that may be appropriate for you personally its not reasonable for an organization charged with preserving the country's history.
an archivist doesn't have the freedom to simplify the format.
Sure he does. He shouldn't discard the original, but he has complete freedom to store an additional copy or copies in simplified and standardized formats. And given your comments on the relative size of the alternate versions, such additions would be relatively cheap.
What if the email is encrypted? What if the author wrote using code-words that only the recipient could understand? Answer: Don't worry about it. You take the common word-processor formats and store a second copy as ascii text. You take the commone spreadsheet formats and store a copy as ascii .csv files. Pick formats for graphics, audio and video where the primary criteria is its current ubiquity and store second copies of those too. Everything more obscure you simply store as is and don't sweat it. Tomorrow's computer experts will surely include folks competent at reverse-engineering as long as we can get them a raw copy of the data on a media they can read. Let them decide what's important enough to bother with.
And speaking of the storage media, don't overthink it. Its impractical to come up with some media that can last 200 years. Worse, its not cost effective. So, pick a media that can last 10 years with 5-nines reliability and plan on someone copying to a new media 10 years hence. How? COTS. Go out and buy some IDE hard drives. They're ubiquitous, cheap, and survive offline storage relatively well. They've been around for 15 years now and there's every reason to expect that computers 10 years from now will still be able to access IDE hard drives even if some other technology has overtaken them.
The 20 meg MFM drives of 1985 were obsolete in 1995, but you could still get the equipment to read them. The 500 meg IDE drives of 1995 are obsolete now, but even if your PC doesn't have PATA ports (most still do) you can get a $20 USB converter and read the old drive that way. As long as you plan on forward-converting the data every 10 years the media choice is simple: pick whatever is currently ubiquitous.
Even with substantial data recovery blocks (a la par2) you're still looking at a media cost of less than $1000 per terabyte for 10 years of storage with the expectation that in ten years a terabyte will only cost $100 for the following 10 years.
Seriously, this is not a hard problem. Look at past situations where data has become unrecoverable. They share some common characteristics:
1. Recovery was attempted too long after the media became obsolete, typically 20 years or more. Nobody is complaining about lost NASA data from the 1990's. Its the 1970's data they can't retrieve. Plan on forward-converting it all every 10 years and you won't lose it.
2. The storage media was some obscure magnetic tape format that never saw wide deployment so that it became unavailable at exactly the same time it became obsolete. That continues to be true of essentially all magnetic tape formats -- try recovering data from a DDS2 tape from just 10 years ago. Good luck finding a drive that matches the format used by the original. With the infamous '70s NASA data, for example, the chief problem isn't decoding the data (a good hacker could likely figure it out) but rather retrieving the data from tape. On the flip side, you still have folks around who fiddle with Commodore 64 data from 1985 -- widely available COTS equipment will win the longevity race every time.
3. No one left documentation (or the documentation did not survive) describing the data structures used to store the data on the media. So, make sure to store it in formats that are very well known such as RFC2822, ascii, and csv. Perhaps in a well documented FAT filesystem using open source tar, gzip and par2 (and store copies of the source code for that software with the data). These formats will be trivially understood 10 years from now, even if they're not then in common use.
Seriously, its just not that hard.
electronic documents created today may not be legible on tomorrow's devices
ASCII text has been around for decades and oh by the way Internet-formatted email is 100% representable as ascii text since that's how its still transferred today.
This supposed problem is a real problem only for those with Exchange, Domino or Groupwise which creates email in custom, internal formats.
How, how, HOW in the world is the manager ever possibly supposed to [...] find and motivate good programmers, if he can't look at their code and figure out how good a programmer they are?
The same way managers have been managing for centuries: Look at the work product. A lawyer is measured by cases won. A doctor by his patients' health. If the result does what the customer wants then it has been done well. If it doesn't then it has been done poorly.
The problem with Java is that its trivial to hide poor craftsmanship behind a facade of apparantly working screens. Like a doctor prescribing a placebo until the patient dies. The manager doesn't know anything is amiss until he hands it to the customer who comes back two weeks later and says, "Why are the numbers wrong?"
I want a programming manager who knows how stuff is designed and coded *the best way*.
No you don't. You might think you do, but you'd hate his guts for constantly telling you to do it his way when you know perfectly well that your way is better. Programming is an art form. The notion of a "best" way is an illusion. It would be a soul-sucking work environment since he'd be too busy micromanaging to go schmooze the higher-ups and get the team the resources it needs.
Its not the manager's job to know the things you know. That's what he hired you for. Its his job to know all the things you don't.
Humans are wired to follow the requirements set by the Authority. The Authority is assumed to have a reason for those steps, even if its not apparent.
The thing is, if the process was set up by an expert, the non-obvious steps often do have importance. The guy on the assembly line drills a hole where he's told because that's what he was told to do. The fact that the hole is later an anchoring point for a strut is Somebody Else's Problem.
You might say the repetition of the steps designated by Authority is the foundation of our industrial and technological society. It enables cooperative labor without the individuals having to first understand the entire big picture.
Put another way, it means a team of human beings is greater than the sum of its members. A team of chimps isn't.
The problem with Java is that if you're a non-programming manager its very hard to tell the difference between a good java programmer and an incompetent java programmer. Both build software that displays a window on your screen which responds more or less correctly when you press the buttons. That the incompetent one simply caught and ignored all the exceptions isn't obvious until you're 18 months in to development with a product that can't be made to work. That the good programmer then says, "I told you so" is unhelpful.
Other languages are better about giving the manager indicators when the programmer is incompetent. For example, C crashes and burns while Perl drags along impossibly slow. A reasonably competent manager can look over the early prototypes and tell right off which of the team members know what they're doing. In Java, you don't know your programmers are digging you a hole until its too deep to get back out.
One might argue that the manager is incompetent if he can't tell the difference between good code and bad code, but that's really not the manager's job. The manager's job is to find and motivate good programmers (who know how to write good code). Java fails to provide the manager with the necessary tools to do accomplish that job.