Slashdot Mirror


User: Handyman

Handyman's activity in the archive.

Stories
0
Comments
107
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 107

  1. Re:Varying the question... on How Many Hours Do You Work in a Week? · · Score: 1

    I guess anything that contributes to getting the job done can be considered "work", but they've got to have to have some relatively objective measure to see how much you've accomplished. In the industrial age people would do physical work, and then the hours really were an objective measure of the amount of work people did. I guess they still hang on to this system because (among other reasons):

    1) The whole law system is based on this: You can't be fully paid by the function point or something, or otherwise you must legally become a freelancer, not an employee. When you're an employee, you have to get at least minimum wages, so you MUST be payed by the hour for at least that part!

    2) Otherwise they'd have to think up some other measure of amount of work, and because almost everybody does different jobs nowadays, this would mean that everybody got their work measured in a different way. This would cause a lot of jealousy.

    3) Programmers vary much less in hours they work than in the amount of work they get done. If you would start paying programmers by the amount of work, the salary differences would rise to factors of 100, leading to enormous amounts of jealousy! Also, the top guys would be paid so much that they would leave and start their own company because they had the money to invest. And the worst guys would leave because they wouldn't get paid at all - I know some people who would probably earn a NEGATIVE income if their productivity were measured objectively! :-)

    Another thing: I recently saw some statistics in a newspaper in which were compared the total productivity per person and the productivity per hour per person of a number of countries. The statistics showed that European people had a much higher productivity per hour but had the same overall productivity as Americans. The reason? They work shorter hours, but get the same amount of work done! I've seen the same thing in other articles: people can't seem to put in more than about 6 hours of productive work a day. So whether you work 11 or 8 hours, it doesn't really matter in the long run. Working 11 hours will just wear you out sooner.

  2. Numeric keypads & double half keyboards on Non-Traditional Keyboard Reviews · · Score: 1

    I could see a use for a half keyboard like that, if I could just have 2 of them, one for each hand!

    But seriously, I'm always troubled by the presence of the numeric keypad on the right side of my keyboard. When I want to sit straight in front of the alphabetic part of the keyboard my mouse is too far away to use comfortably. This conflicts with my physical therapist's instructions to keep my mouse close to my body to reduce the strain. When I sit correctly to use my mouse, my keyboard is slightly to my left. I don't move my keyboard to the middle just to type three words, so this usually results in me having both my mouse too far away and my keyboard slightly to my left, increasing the strain on my hands needlessly because I could very well do without the numeric section on the keyboard. That's why I would like to have two of these half keyboards, but I'd rather have just one keyboard without the numeric section.

  3. Pragmatism & methodologies on Do You Buy Into Management Methodologies In IT? · · Score: 1

    A big problem that I've seen is that people use the methodology as a standard of all that could possibly be done to do the trick, not as guidelines of a minimum amount of things you could do, as a baseline for the rest of the work. People start thinking that if they obey all the rules, they won't loose their jobs even if they don't even think about things at all anymore! They can just point to the methodology, say they followed the rules, and they're not to blame.

    Methodologies should be practised pragmatically, using it when it's appropriate, doing more than the standard requires when it is needed and doing less when following the standard would be overkill and would just lead to bureaucracy. A little cherry-picking isn't bad at times!

  4. Methodologies are bad. on Do You Buy Into Management Methodologies In IT? · · Score: 1

    In general, I think that methodologies are bad. They might be born out of a good thing, and people tried to capture that good thing into a "standard", but eventually most Good Things that people do depend more on the state of mind of the people than the actual things you see them do. (The Programmer's Stone is an enlightened discussion of this.)

    Methodologies usually lead to the people in the right state of mind being repressed by the people following the methodologies; all new ideas are pushed into the straightjacket of the methodology, killing all fun in work for the more pragmatic workers, who also happen to be the brightest ones usually.

    A friend of mine used to say that a methodology is a systematic way to overlook reality.

  5. What about faulty fixes as a problem? on Y2K Bugs: The Year In Review? · · Score: 1

    What about fixes that caused new problems, or only fixed the problem for a limited amount of time?

    As an example, I just got an email from my mother, who owns a 486DX2/80 from a couple of years ago. I installed a Y2K patch for her some time ago, supplied by the motherboard manufacturer, which was supposed to fix the Y2K problem on the system clock (the clock would switch to 2094 instead of 2000!). Now, in 2001, it turns out that she has been caught in a year-2000 time loop! The computer will not work in ANY year 20xx except 2000...

    This is just an example of what effects faulty quick fixes can have. These kinds of problems SHOULD be part of the Y2K aftermath I think.

  6. Does anybody know anything about speed of DACs? on DVD Hack Delays DVD Audio · · Score: 1

    (Maybe this is offtopic, but could somebody please answer my question?)

    I don't know how DACs work, but I would like to know how the difference between two digital input signals influences the time before the output signal is accurate. For instance, if the input sample s(n) = 0, s(n + 1) = 65535, does it take a 16-bit DAC longer to reach an accurate output signal than when, say, s(n) = 0, s(n + 1) = 256? If this is true, it could have quite an influence on the sound.

  7. Responsibility for 'Educational' viruses on Who is Responsible? The Developer? The User? · · Score: 1

    When you write viruses for 'educational' purposes you will not spread them, at least not intentionally. I think the one who should be held responsible for damage done by such viruses is the person who actually "let the virus out of it's cage", e.g. compiled and ran it/sent it to someone. I can well imagine a student prankster trying to use a sample virus written by a teacher to tease a fellow student, not realizing that the virus might also infect every other system in the universe! However, a student can also set a virus free with the intent to destroy the world.

    A person is always responsible for the damage his/her actions cause, whether he/she intended it or not. However, this only affects the amount they (or their insurance providers) have to pay in damages. For the criminal justice system there is a completely different thing: I think there is a ratio involved, the intended amount of damage compared to the actual amount of damage done. In general, you cannot punish someone for something he/she didn't intend to do and could not be expected to have known to be doing.

    This is all very well, theoretically speaking, but it does not address the big problems:
    * How do you find out who set something free?
    * How do you find out reliably what he/she intended?

    So, in the end, probably the writers of the virus will be punished instead of the people who caused the virus to be set free. Just because it's much easier to find them and because there's much more "hard" evidence. Just like it's easier to find out who manufactured the bullet than who pulled the trigger. Sigh.