As a contractor, I've always felt sorry for the salaried employees who worked tons of overtime while I was limited to 40 hours per week because companies did not want to pay my billing rate for more than 40 hours per week. At my billing rate I made roughly twice what the regular employees made. The other thing though is I produced more during my 40 hours per week than the poor boobs who worked 60 hours per week. I didn't do more work, but I did very little rework....fixing bugs is all rework and it's productivity = zero. If you go from a 40 hour work week to a 60 hour work week, more work is produced for 3 weeks. The fourth week results in the same amount of work accomplished as the 40 work week. After that less work is performed in 60 hours than used to be done in 40 hours. I know that everyone thinks they are doing all kinds of work and they are. But most of the work they do is fixing mistakes they made due to fatigue and has zero productivity.
Industrial Engineering studies on productivity show that when someone who works 40 hours a week goes to 60 hour work weeks they get more work accomplished for 3 weeks. The fourth week they get as much accomplished as they did when they worked a 40 hour work week. After that they accomplish less in absolute terms. They reason is not because they're not working. It's because more and more of their work is rework fixing things that they screwed up due to fatigue. In Industrial Engineering, the productivity of rework is always zero. I haven't met a manager yet who actually believes that. ------------------------------------
I suppose you're right...assuming that you can find and eliminate all the backdoors that the government's security apparatus is going to have included in every version of the OS. ------------------------------------
OK, OK...I guess slashdotters are entitled to the truth. Actually the Mars lander put down in the middle of the compound of the advanced base set up to coordinate the invasion of Earth. The main fleet is still several years out, but will arrive soon enough the chiliasticists will view it as the return of Christ. You can recognise this as the same "God returning" scam that Cortez used on the Aztecs. However, it would not have done for the Mars lander to have sent back pictures of the "chariot of fire" being constructed for the Jesus clone to drop out of the sky on. ------------------------------------
I suppose you're not as paranoid as I am. I would not use any OS whose development was controlled or mandated by any government. ------------------------------------
One of the things that I learned in my Industrial Engineering days is that people who work long hard hours every week are less productive in absolute terms. That is, they accomplish less work than people who put in a productive 40 hours per week. This isn't because they work less as they get tired, it's because more of their work is rework and the productivity of rework is always zero. Think how much programming time is spent fixing bugs that shouldn't have occurred in the first place. Now....I haven't meant a manager yet that believed that. I've always noticed that the hard workers who spend 70 hour weeks fixing the code that they didn't get right the first, second or third time generally have bright futures. ------------------------------------
Yes...I agree that when you're actually cutting code, you do not need someone hanging over your shoulder. The design by committee is not necessarily bad. Usually, when it fails, it's because someone has a big ego or a different agenda (such as showing how commanding a leader he or she is). I'm very familiar with having a good idea shot down merely because some Alpha gorilla wanted to demonstrate they were the biggest guy on the block.
It's typical of the "penny wise; pound foolish" mentality to ignore the benefits part of two eyes and just say the costs are unaffordable. I have often identified coding errors in 30 seconds after someone has worked for three weeks on their own trying to find them. (I have also been on the other end). People who work solo often spend a lot of time figuring something out that someone else already knows.
Actually, it works the opposite. Programmers who only work on their own never learn better programming techniques and algorithms beyond what they can think up just by themselves. Also, beginners don't have their bad coding practices corrected if a more knowledgeable programmer doesn't mentor them. The projects where I've worked on teams have always had better results than the projects where everyone worked independently. ---------------------------------------------
Programming in pairs is one way to accomplish something I've believed in for years. Peer review of code is often considered optional. One result of non review is that Junior programmers never get their bad coding practices corrected. I wouldn't be concerned about New Year's except for all the crappy code I've been skipping over as I fix Y2K bugs.
You live in the same fantasy world that I live and work in...needless to say, while I've survived in the IS world for a long time due to the fact that my code always works, I've never had what could be considered a successful career.
Hooray for some sanity. Let's hear it for keeping things simple and clear. There is no excuse for writing complex cludgy convoluted code when if you just take the time to do some THINKING, you can generally design a program to be simple and easy to understand and follow. Any extra time you spend on thought will pay dividends on the test and debug. Of course, if you don't do any testing I guess it's wasted time, isn't it?
I guess I know why I spend so much time finding bugs and fixing shitty code. I've known for a long time that it's better for a career to supply buggy crap on time than to supply stuff that works all the time but is occaissionally late. Then, of course, you get to be the hero when you fix your crap. About the only people who complain are the users and who cares about them. I resigned one place because the programmer who completed every project on time, but always spent 3 weeks fixing production problems, was the fair haired annointed destined for greatness. The only person who expressed dismay was the operations manager who got called at 3 AM every time this bozo's stuff crashed. He told me that I was the only analyst who could put something into production without him worrying about being awakened in the middle of the night. But on one project I was 2 weeks late due to a technical problem that took 2 weeks to solve. I knew I didn't have a future there. But it's certainly my belief that Bozo's rule in this field, especially when I come along behind bozo's like this guy.
Slashdot Mirror
As a contractor, I've always felt sorry for the salaried employees who worked tons of overtime while I was limited to 40 hours per week because companies did not want to pay my billing rate for more than 40 hours per week. At my billing rate I made roughly twice what the regular employees made.
The other thing though is I produced more during my 40 hours per week than the poor boobs who worked 60 hours per week. I didn't do more work, but I did very little rework....fixing bugs is all rework and it's productivity = zero.
If you go from a 40 hour work week to a 60 hour work week, more work is produced for 3 weeks. The fourth week results in the same amount of work accomplished as the 40 work week. After that less work is performed in 60 hours than used to be done in 40 hours.
I know that everyone thinks they are doing all kinds of work and they are. But most of the work they do is fixing mistakes they made due to fatigue and has zero productivity.
Industrial Engineering studies on productivity show that when someone who works 40 hours a week goes to 60 hour work weeks they get more work accomplished for 3 weeks. The fourth week they get as much accomplished as they did when they worked a 40 hour work week. After that they accomplish less in absolute terms. They reason is not because they're not working. It's because more and more of their work is rework fixing things that they screwed up due to fatigue. In Industrial Engineering, the productivity of rework is always zero. I haven't met a manager yet who actually believes that.
------------------------------------
I suppose you're right...assuming that you can find and eliminate all the backdoors that the government's security apparatus is going to have included in every version of the OS.
------------------------------------
Tang was on the market before NASA ever decided to poison the astronauts with it.
------------------------------------
OK, OK...I guess slashdotters are entitled to the truth. Actually the Mars lander put down in the middle of the compound of the advanced base set up to coordinate the invasion of Earth. The main fleet is still several years out, but will arrive soon enough the chiliasticists will view it as the return of Christ. You can recognise this as the same "God returning" scam that Cortez used on the Aztecs. However, it would not have done for the Mars lander to have sent back pictures of the "chariot of fire" being constructed for the Jesus clone to drop out of the sky on.
------------------------------------
I suppose you're not as paranoid as I am. I would not use any OS whose development was controlled or mandated by any government.
------------------------------------
All I need for Y2K is an AK47 and plenty of ammo. Anything else I need....I'll just take.
------------------------------------
One of the things that I learned in my Industrial Engineering days is that people who work long hard hours every week are less productive in absolute terms. That is, they accomplish less work than people who put in a productive 40 hours per week. This isn't because they work less as they get tired, it's because more of their work is rework and the productivity of rework is always zero. Think how much programming time is spent fixing bugs that shouldn't have occurred in the first place. Now....I haven't meant a manager yet that believed that. I've always noticed that the hard workers who spend 70 hour weeks fixing the code that they didn't get right the first, second or third time generally have bright futures.
------------------------------------
Yes...I agree that when you're actually cutting code, you do not need someone hanging over your shoulder. The design by committee is not necessarily bad. Usually, when it fails, it's because someone has a big ego or a different agenda (such as showing how commanding a leader he or she is). I'm very familiar with having a good idea shot down merely because some Alpha gorilla wanted to demonstrate they were the biggest guy on the block.
AMEN!!!!!
It's typical of the "penny wise; pound foolish" mentality to ignore the benefits part of two eyes and just say the costs are unaffordable. I have often identified coding errors in 30 seconds after someone has worked for three weeks on their own trying to find them. (I have also been on the other end). People who work solo often spend a lot of time figuring something out that someone else already knows.
Actually, it works the opposite. Programmers who only work on their own never learn better programming techniques and algorithms beyond what they can think up just by themselves. Also, beginners don't have their bad coding practices corrected if a more knowledgeable programmer doesn't mentor them. The projects where I've worked on teams have always had better results than the projects where everyone worked independently. ---------------------------------------------
Programming in pairs is one way to accomplish something I've believed in for years. Peer review of code is often considered optional. One result of non review is that Junior programmers never get their bad coding practices corrected. I wouldn't be concerned about New Year's except for all the crappy code I've been skipping over as I fix Y2K bugs.
You live in the same fantasy world that I live and work in...needless to say, while I've survived in the IS world for a long time due to the fact that my code always works, I've never had what could be considered a successful career.
Hooray for some sanity. Let's hear it for keeping things simple and clear. There is no excuse for writing complex cludgy convoluted code when if you just take the time to do some THINKING, you can generally design a program to be simple and easy to understand and follow. Any extra time you spend on thought will pay dividends on the test and debug. Of course, if you don't do any testing I guess it's wasted time, isn't it?
I guess I know why I spend so much time finding bugs and fixing shitty code. I've known for a long time that it's better for a career to supply buggy crap on time than to supply stuff that works all the time but is occaissionally late. Then, of course, you get to be the hero when you fix your crap. About the only people who complain are the users and who cares about them. I resigned one place because the programmer who completed every project on time, but always spent 3 weeks fixing production problems, was the fair haired annointed destined for greatness. The only person who expressed dismay was the operations manager who got called at 3 AM every time this bozo's stuff crashed. He told me that I was the only analyst who could put something into production without him worrying about being awakened in the middle of the night. But on one project I was 2 weeks late due to a technical problem that took 2 weeks to solve. I knew I didn't have a future there. But it's certainly my belief that Bozo's rule in this field, especially when I come along behind bozo's like this guy.