I tried that, and I'm not sure I'm willing to do it again. Apologize is another way to saying that it is my fault, which puts the blame back on me.
Sorry to hear that. When that happens, and I agree it does, I think it's an indication that the corporate culture is too unhealthy to stay with long-term.
My feeling is that work is too big a part of your life to spend it doing things you hate.
Actually, that jibes with my limited experience working with Europeans business people in an American multinational. I wonder how much of it may be do to having to typically do more with less, however. The US office often threw $money$ at problems; the attitude was 'I want it yesterday; screw the cost; we'll just pass it on to the customer'. The Europeans were -much- more willing to give more time (personal or calendar) in exchange for reduced costs, with correspondingly better results (mostly; some of them also had an irritating habit of failing to mention problems until long after they discovered them. 'Oh, we've known about that since the begining of last quarter.')
If you do, apologize. Even if it might not be -really- your fault, apologize, and do it sincerely.
> 2) Don't add negative value. Remember that you are being paid to help your group/company make money. If this is not kosher, move on and join the Peace Corps.
Or other organization. I recently turned down an interview with a legal firm where I would have had to design software to more effectively screw people with the legal system. A week or two later I got an interview with a non-profit organization, doing something useful.
> 2) Avoid sending e-mails whenever possible. If you must, keep them extremely neutral. Use phone calls and personal conversations for any type of discussion or criticism--technical or otherwise.
Excellent point. Also, just get in the habit of using the phone; most non-techies prefer it. Follow up by email to confirm understanding of points discussed.
> 4) Disabuse yourself of the ridiculous concepts of "Customer Requirements" and "Use Cases." They will not come.
Don't entirely agree. Don't expect that requirements will be fixed in stone or even right the first time, though. They -will- evolve during development.
> 5) Innovate. Do "cool stuff" (prototypes, new concepts, algorithms, research) whenever there is a lull. If you do not do this, you will either get replaced or doom yourself to a life of mediocrity--probably both. Leverage the "cool stuff" at an opportune time to help your group.
Excellent advice. Another thing that often meets this cool/fun/innovative part is programming tools and utilities.
Even anonymously reporting abuse to authorities carries problems. There was a story some years ago about someone with a grudge who anonymously reported a neighbor for child abuse. Every week for years. And this required child protection services to investigate every report, really harassing the poor folks. Child services could not refuse to investigate; that's the law. They refused to do anything to get proof of the caller's identity for fear of compromising the effectiveness of the anonymous line. I have no solution to present; just the fact of the problem.
Yes; I've only felt comfortable adding Crystal Reports to an application for user-defined reporting requirements twice in the last 10 years. Both times the company was already using Crystal in this way, and had people in place to create these reports for users.
re: GUI application font support. Again, a rare few get this right, but most of them have this big conglomeration of font types, and no unified font access system. Windows 3.0 had a beter font subsystem than what some Unicies have.
Actually, getting this right this was -much- more complicated and expensive in Windows than most people imagine. Font support in Windows required MS to spend, spend, spend, and -really- lean on application vendors.
And there are still fairly large defects.
re: Printing. Again, some Unicies have done a good job, but far too many still don't have a good unified printing subsystem.
Also much more expensive in Windows than most people expect, -and- required leaning on hardware vendors, -and- buggier than most people think.
But both font support and printing are important enought that the problem should at least be recognized better, even if the funds don't exist to fix it quickly.
re: Desktop access APIs. Even with KDE and Gnome, there still isn't an API to call...
I agree. In general, there needs to be a unified abstraction layer for these kinds of things. It will never be done correctly by application programmers until they can just call a simple API to do it. It's not -that- complicated; I'm sure it could be worked out fairly quickly.
As others pointed out, man pages tend to have major defects and inaccuracies covered by disclaimers like "this isn't being maintained" or "see info/html/other".
In addition, a huge amount of Unix documentation lacks structure. There is a huge amount of raw data, but no tables of contents (or at least no -accurate- ones), and poor or nonexistent indexes.
A lot of Unix documentation tends to address the esoteric needs of the few, and ignores the more common needs of the many.
re: To solve the personal space issue, employ a bit of technology yourself: carry around a jammer.
While not unreasonable, is it really appropriate to require people to invest in technology in order to get -away- from technology? That's sort of like requiring someone who wants to have a cell-phone without internet access to buy the web-enabled version, and get a special peripheral to disable the web acess part.;>
re: 1. If your device generates sound - wear earphones in a public setting.
This only helps the least intrusive cases. The people who are most intrusive are yelling back at the device, or at least talking loudly. Think about it: is the most annoying part of someones public cell-phone conversation the remote speaker, or the one who is right there?
You're absolutely right that this is just a special case of behavior that needs to be modified. But it's an uphill battle.
Speaking as someone not opposed to this, but definitely not enthusiastic, I would say people are probably against this because they perceive that people who will use this service will probably be the same kinds of inconsiderate folks who play loud obnoxious music in family tent-camping areas, race ATVs up and down hiking paths, and bring other intrusive and obnoxious technology-related habits to the campgrounds.
It's not about controlling what other people do; it's about personal space. A lot of people who are real fans of being "always connected" are extremely insensitive about personal space, and regularly infringe on other people. They don't seem to need much personal space, and can't comprehend those who need more space.
Yeah, I can choose not to use the service, but I'd feel more comfortable about it if there were designated "no wi-fi" areas. Also, i leave my notebook and cell phone at home when I go camping. I prefer that my coworkers have the perception that I am completely inaccessible.
And yes, I get a -lot- of weird looks from my geek friends when I tell them I left my notebook at home for 2 weeks.;>
While -most- developers should not need root access to their machines, there are very definitely cases where some -need- it. If the developers are designing software that needs to run on a server, and need to test features common users do not have access to, they have to have admin access on their own boxes in order to unit test.
They should not be running as admin most of the time, but it is needed sometimes. Other common reasons are to test server-side install processes, test automated upgrade features, and test agressive failure scenarios (mimic attacks, that sort of thing).
Additionally, in about 50% of the shops I've been in, I needed to set up PCs for developers. In-house tech support couldn't handle it; they only know how to install a few user applications.
Also, local admin access in Windows just gives them total control of their PC. If they log on as local admin, they have no special rights on servers or network filesystems.
People like Ms. McDonald just don't understand that technology doesn't magically happen. It requires people to do their jobs correctly.
Ms. McDonald says you can trust the government, but the issue isn't just trust. Even if you accept the idea that the government will not deliberately misuse this information, you have to recognize that PEOPLE MAKE MISTAKES!
It doesn't matter to the poor S.O.B. whose SSN was incorrectly associated with a child molester with a similar name that it was an honest mistake; he still has his life screwed up.
Considering the truly _massive_ numbers of plain old painful screw-ups made each year by public utilities, driver's license bureaus, tax offices, public assistance offices, child welfare offices, school systems, credit bureaus, etc. etc., it is an act of truly _monumental stupidity_ to believe that if the government builds the largest collection of information ever, they will miraculously stop making the same kind of ordinary human mistakes that have defined all public databases since the beginning of written records.
Even without the legitimate concerns about deliberate misuse, this alone is enough to make any _reasonably_ sane and intelligent human being demand more accountability from the government on this issue.
Slashdot Mirror
I tried that, and I'm not sure I'm willing to do it again. Apologize is another way to saying that it is my fault, which puts the blame back on me.
Sorry to hear that. When that happens, and I agree it does, I think it's an indication that the corporate culture is too unhealthy to stay with long-term.
My feeling is that work is too big a part of your life to spend it doing things you hate.
Good luck to you.
Actually, that jibes with my limited experience working with Europeans business people in an American multinational.
I wonder how much of it may be do to having to typically do more with less, however. The US office often threw $money$ at problems; the attitude was 'I want it yesterday; screw the cost; we'll just pass it on to the customer'.
The Europeans were -much- more willing to give more time (personal or calendar) in exchange for reduced costs, with correspondingly better results (mostly; some of them also had an irritating habit of failing to mention problems until long after they discovered them. 'Oh, we've known about that since the begining of last quarter.')
A few comments:
> 0) Don't Tick Anyone Off.
If you do, apologize. Even if it might not be -really- your fault, apologize, and do it sincerely.
> 2) Don't add negative value. Remember that you are being paid to help your group/company make money. If this is not kosher, move on and join the Peace Corps.
Or other organization. I recently turned down an interview with a legal firm where I would have had to design software to more effectively screw people with the legal system. A week or two later I got an interview with a non-profit organization, doing something useful.
> 2) Avoid sending e-mails whenever possible. If you must, keep them extremely neutral. Use phone calls and personal conversations for any type of discussion or criticism--technical or otherwise.
Excellent point. Also, just get in the habit of using the phone; most non-techies prefer it. Follow up by email to confirm understanding of points discussed.
> 4) Disabuse yourself of the ridiculous concepts of "Customer Requirements" and "Use Cases." They will not come.
Don't entirely agree. Don't expect that requirements will be fixed in stone or even right the first time, though. They -will- evolve during development.
> 5) Innovate. Do "cool stuff" (prototypes, new concepts, algorithms, research) whenever there is a lull. If you do not do this, you will either get replaced or doom yourself to a life of mediocrity--probably both. Leverage the "cool stuff" at an opportune time to help your group.
Excellent advice. Another thing that often meets this cool/fun/innovative part is programming tools and utilities.
Good points, cowtamer.
Even anonymously reporting abuse to authorities carries problems. There was a story some years ago about someone with a grudge who anonymously reported a neighbor for child abuse. Every week for years. And this required child protection services to investigate every report, really harassing the poor folks.
Child services could not refuse to investigate; that's the law. They refused to do anything to get proof of the caller's identity for fear of compromising the effectiveness of the anonymous line.
I have no solution to present; just the fact of the problem.
Yes; I've only felt comfortable adding Crystal Reports to an application for user-defined reporting requirements twice in the last 10 years. Both times the company was already using Crystal in this way, and had people in place to create these reports for users.
re: GUI application font support. Again, a rare few get this right, but most of them have this big conglomeration of font types, and no unified font access system. Windows 3.0 had a beter font subsystem than what some Unicies have.
Actually, getting this right this was -much- more complicated and expensive in Windows than most people imagine. Font support in Windows required MS to spend, spend, spend, and -really- lean on application vendors.
And there are still fairly large defects.
re: Printing. Again, some Unicies have done a good job, but far too many still don't have a good unified printing subsystem.
Also much more expensive in Windows than most people expect, -and- required leaning on hardware vendors, -and- buggier than most people think.
But both font support and printing are important enought that the problem should at least be recognized better, even if the funds don't exist to fix it quickly.
re: Desktop access APIs. Even with KDE and Gnome, there still isn't an API to call...
I agree. In general, there needs to be a unified abstraction layer for these kinds of things. It will never be done correctly by application programmers until they can just call a simple API to do it. It's not -that- complicated; I'm sure it could be worked out fairly quickly.
As others pointed out, man pages tend to have major defects and inaccuracies covered by disclaimers like "this isn't being maintained" or "see info/html/other".
In addition, a huge amount of Unix documentation lacks structure. There is a huge amount of raw data, but no tables of contents (or at least no -accurate- ones), and poor or nonexistent indexes.
A lot of Unix documentation tends to address the esoteric needs of the few, and ignores the more common needs of the many.
Good points, but...
;>
re: To solve the personal space issue, employ a bit of technology yourself: carry around a jammer.
While not unreasonable, is it really appropriate to require people to invest in technology in order to get -away- from technology? That's sort of like requiring someone who wants to have a cell-phone without internet access to buy the web-enabled version, and get a special peripheral to disable the web acess part.
re: 1. If your device generates sound - wear earphones in a public setting.
This only helps the least intrusive cases. The people who are most intrusive are yelling back at the device, or at least talking loudly. Think about it: is the most annoying part of someones public cell-phone conversation the remote speaker, or the one who is right there?
You're absolutely right that this is just a special case of behavior that needs to be modified. But it's an uphill battle.
Speaking as someone not opposed to this, but definitely not enthusiastic, I would say people are probably against this because they perceive that people who will use this service will probably be the same kinds of inconsiderate folks who play loud obnoxious music in family tent-camping areas, race ATVs up and down hiking paths, and bring other intrusive and obnoxious technology-related habits to the campgrounds.
;>
It's not about controlling what other people do; it's about personal space. A lot of people who are real fans of being "always connected" are extremely insensitive about personal space, and regularly infringe on other people. They don't seem to need much personal space, and can't comprehend those who need more space.
Yeah, I can choose not to use the service, but I'd feel more comfortable about it if there were designated "no wi-fi" areas. Also, i leave my notebook and cell phone at home when I go camping. I prefer that my coworkers have the perception that I am completely inaccessible.
And yes, I get a -lot- of weird looks from my geek friends when I tell them I left my notebook at home for 2 weeks.
While -most- developers should not need root access to their machines, there are very definitely cases where some -need- it. If the developers are designing software that needs to run on a server, and need to test features common users do not have access to, they have to have admin access on their own boxes in order to unit test. They should not be running as admin most of the time, but it is needed sometimes. Other common reasons are to test server-side install processes, test automated upgrade features, and test agressive failure scenarios (mimic attacks, that sort of thing). Additionally, in about 50% of the shops I've been in, I needed to set up PCs for developers. In-house tech support couldn't handle it; they only know how to install a few user applications. Also, local admin access in Windows just gives them total control of their PC. If they log on as local admin, they have no special rights on servers or network filesystems.
People like Ms. McDonald just don't understand that technology doesn't magically happen. It requires people to do their jobs correctly.
Ms. McDonald says you can trust the government, but the issue isn't just trust. Even if you accept the idea that the government will not deliberately misuse this information, you have to recognize that PEOPLE MAKE MISTAKES!
It doesn't matter to the poor S.O.B. whose SSN was incorrectly associated with a child molester with a similar name that it was an honest mistake; he still has his life screwed up.
Considering the truly _massive_ numbers of plain old painful screw-ups made each year by public utilities, driver's license bureaus, tax offices, public assistance offices, child welfare offices, school systems, credit bureaus, etc. etc., it is an act of truly _monumental stupidity_ to believe that if the government builds the largest collection of information ever, they will miraculously stop making the same kind of ordinary human mistakes that have defined all public databases since the beginning of written records.
Even without the legitimate concerns about deliberate misuse, this alone is enough to make any _reasonably_ sane and intelligent human being demand more accountability from the government on this issue.