Maybe my vision is coloured because I'm a techie who's been a manager, and went back to an intra-company consulting role to act as the translator / mediator between the techies and management.
Management here actually has a clue, or rather, they know that technically they don't have a clue and will defer to the people who *do* know.
So you think the techies that have taken the time to explain all the reasons *why* something needs to be done are stupid.
What percentage of techies take the time to explain the reasons why something needs to be done, in a way that a non-techie or less-techie can understand? Usually a non-techie with more bacon on the line than the techie themselves?
In my experience, without guidance or training, the percentage is way below 10%.
I can understand the troll GP's position - though it really serves no purpose to call people who are doing their best to deliver a quality project "stupid".
In my experience the techies that "won't listen" or "won't explain" aren't being stupid, they are usually just being myopic failing to understand that they have to make their case a little more solidly than "because we have to!" or "because I say so!". Anything that potentially costs extra time or money in a business project needs to be justified with a business case. A good tech manager knows what to listen for with her techies, and how to coax the right info out of them, but there needs to be some push from the techies themselves.
Techies: your manager simply can't take your word for granted until you make a solid business case for what you want to do. After a while, you may build up trust that just your saying so is enough, but you'll have to put some work in the first few times.
Maybe I missed something, but there's nothing in the summary that says they have to block anything. They are simply not allowed to block something lawful. Which seems to mean (in the context of the parent, GP and other posts): the only way to be sure without breaking a bunch of laws is to not block ANYTHING.
I wasn't saying that it was against the law. In fact, I disagree with TI's use of DMCA takedown notices.
However, I said that I understood why TI wanted to not allow custom OS's. There are certain (though very few) technology devices that can be fundamentally hurt by customization.
Citation needed.
Which devices are hurt by customization?
This is what both online banks that I use do.
Every transaction has to be re-verified with a code from the passcode calculator (a separate piece of hardware).
In one case, the password calculator needs your debit card to be inserted, to verify your PIN code at least, and perhaps using more information off the card chip to generate passcodes. The calculator itself is not unique, but you need the debit card and the PIN code to be able to do anything with it.
In the other case, the calculator itself is unique and has a serial number.
We did run the smoke tests, and saw the problem the very day the update came out.
Unfortunately, with all the third party dependencies in our projects and confusion on what had actually happened, plus the delay in the update in VCRedist on the MSDN site, it actually took us a lot more time to get all our installers to work right again across all systems.
We gained some understanding in merge modules and VC internals, and are less reliant on such things as the VCRedist exe download, so we did learn something.
But I still believe Microsoft should have put out a big "how-to" after knowingly breaking a LOT of builds with an update.
For me the kicker was the last paragraph, where Joel admits that only developers that have the innate ability to make the right short-cut decisions are actually good duct-tape programmers.
All you need to do is vary the definition of "working", and suddenly everyone is a good programmer.
And I WISH I was kidding, but you all know it's true. You just tone down what "working" means and feel you have an excuse to ship steaming piles of shit.
Slashdot Mirror
Nintendo really is dead as company. They have so little to offer. The Wii is a disaster hardware and software wise.
I'd love to have a few disasters like that....
Maybe my vision is coloured because I'm a techie who's been a manager, and went back to an intra-company consulting role to act as the translator / mediator between the techies and management.
Management here actually has a clue, or rather, they know that technically they don't have a clue and will defer to the people who *do* know.
So you think the techies that have taken the time to explain all the reasons *why* something needs to be done are stupid.
What percentage of techies take the time to explain the reasons why something needs to be done, in a way that a non-techie or less-techie can understand? Usually a non-techie with more bacon on the line than the techie themselves?
In my experience, without guidance or training, the percentage is way below 10%.
I can understand the troll GP's position - though it really serves no purpose to call people who are doing their best to deliver a quality project "stupid".
In my experience the techies that "won't listen" or "won't explain" aren't being stupid, they are usually just being myopic failing to understand that they have to make their case a little more solidly than "because we have to!" or "because I say so!". Anything that potentially costs extra time or money in a business project needs to be justified with a business case. A good tech manager knows what to listen for with her techies, and how to coax the right info out of them, but there needs to be some push from the techies themselves.
Techies: your manager simply can't take your word for granted until you make a solid business case for what you want to do. After a while, you may build up trust that just your saying so is enough, but you'll have to put some work in the first few times.
That'll start working when chairs fly.
Hold on, I think I've figured out what Balmer's working on!
Maybe I missed something, but there's nothing in the summary that says they have to block anything. They are simply not allowed to block something lawful. Which seems to mean (in the context of the parent, GP and other posts): the only way to be sure without breaking a bunch of laws is to not block ANYTHING.
void DeleteCall(Call *ip_call) { ip_call->SetVisibleFlag(false); SendCallToEchelonServer(ip_call); };
ROFL! Well played :)
For the last 5 years the evolution in mainstream PC gaming has been all around fancy new graphics.
Even starting with Wolfenstein, the evolution in mainstream PC gaming was ALWAYS around fancy new graphics.
Real-time programming trying to add features to a live system while someone else is demoing the not-yet existing features to a customer.
Mod parent up as FUNNY..
It's a lot more fun if you share some surface with the girl.
(or so I hear).
Or the Lightmaid.
Just don't flick the switch from "suck" to "blow".
Troll? Did the Slashdot Dry Sarcastic Humor detector break again?
Yes I agr...
Wait a minute, I just got an e-mail.
I wasn't saying that it was against the law. In fact, I disagree with TI's use of DMCA takedown notices. However, I said that I understood why TI wanted to not allow custom OS's. There are certain (though very few) technology devices that can be fundamentally hurt by customization.
Citation needed.
Which devices are hurt by customization?
This is what both online banks that I use do. Every transaction has to be re-verified with a code from the passcode calculator (a separate piece of hardware).
In one case, the password calculator needs your debit card to be inserted, to verify your PIN code at least, and perhaps using more information off the card chip to generate passcodes. The calculator itself is not unique, but you need the debit card and the PIN code to be able to do anything with it.
In the other case, the calculator itself is unique and has a serial number.
Oh, we didn't fire the person doing the backups.
We fired the person doing the restores.
That would look a lot like the iPod advertising. So I guess the answer to your question is "yes".
I ahve nveer doen ayntihng stpuid.
Well, she *is* Dutch. They have something with dykes.
We did run the smoke tests, and saw the problem the very day the update came out.
Unfortunately, with all the third party dependencies in our projects and confusion on what had actually happened, plus the delay in the update in VCRedist on the MSDN site, it actually took us a lot more time to get all our installers to work right again across all systems.
We gained some understanding in merge modules and VC internals, and are less reliant on such things as the VCRedist exe download, so we did learn something.
But I still believe Microsoft should have put out a big "how-to" after knowingly breaking a LOT of builds with an update.
Sane people wouldn't write software.
It's a good thing for the rest of us that some of us aren't sane.
Grandparent was correct. That's the ancient spelling.
Kind Regards,
Cthulhu.
For me the kicker was the last paragraph, where Joel admits that only developers that have the innate ability to make the right short-cut decisions are actually good duct-tape programmers.
All you need to do is vary the definition of "working", and suddenly everyone is a good programmer.
And I WISH I was kidding, but you all know it's true. You just tone down what "working" means and feel you have an excuse to ship steaming piles of shit.