|
It was pointlessly pedantic, yes, but slightly less so than you're thinking. (And semantics is concerned with meaning, so arguing over semantics is not by any means automatically something to be dismissive of, given that the meaning is often the whole point.) Granted it is a somewhat silly objection, but why is it a little less silly than you're thinking? Because your original claim is kind of oddly put together. The original statement you made (loosely) takes the form of a logical argument that's actually based on interpreting "brain is a muscle" in a fairly literal fashion, and falls apart into meaninglessness if you do not.
Here's what you said:
"The brain is a muscle. And like any other muscle, it can be overworked and destroyed."
So you are essentially making this logical argument:
1. The brain is a muscle.
2. Muscles can be overworked and destroyed.
3. Therefore, the brain, being a muscle, can be overworked and destroyed.
In other words, whatever you meant to say, you didn't actually say "The brain is kind of like a muscle in that it can be overworked and destroyed." Instead you implied that the brain's capability for overwork and destruction actually comes from its being a muscle. This in turn implies either a mistaken understanding of the biology involved, or, if the original premise is meant to be symbolic, it is a case of the logical fallacy known as "argument from analogy" ("X is like Y in one respect, and therefore it is like Y in some other respect as well."). (Unless the only similarity referred to in the first claim is nothing more than its capacity for overwork and destruction, in which case you basically said "The brain can be overworked and destroyed. And like anything else that can be overworked and destroyed, it can be overworked and destroyed.")
How's that for pedantic overanalysis? 
|
|
|
|
|
No no, true words coming from a self employed man 
However, all joke aside, I think your right. But I also think it matters what you do, a research project it might be a bit different than in a boring this must be done as fast and correct as possible thing.
|
|
|
|
|
Not necessarily: when you are "fresh" you make less mistakes, so you don't have to go back so much and fix them - which can take more time than getting it right in the first place.
See? I said it was counter-intuitive!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
They do make mistakes, but people like Euler won't care anyway. It seems like the couldn't stop, as they really couldn't imagine doing anything else. He is describing doing maths when his grandchildren sat in his lap.
While most of us do things that we know what to do, its just to get it done. After work we generally want to do something completely different, like solving CCC or whatever. 
|
|
|
|
|
OriginalGriff wrote: So I found myself working 09:00 to 17:00 (13:00 on Fridays) even after I was given the key to the building with a full hour off for lunch. And b*gg*r me! I was getting more done...
Well said. I have never known that not to be the case.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Nope. NOT counter-intuitive. Some years back I read an article about productivity. The author said we should schedule our work efforts at 60% of our total time. The "free" time allows us to relax, to think about what we are doing, to work "smarter", and to improve both our products and our processes. In the short term it appears to be a productivity drain, but in the long term the company gets more results from us.
Problem is too many managers don't understand results, they understand butts-in-seats. By this superficial mentality, 70 hours/week is a performer, 40 hours/week is a slacker.
After reading that article I started scheduling all my projects at 60% utilization. I took a LOT of flack from clients who believed that a 160 estimate for one person meant that the product would be delivered in 4 weeks.
The end result? Better products delivered exactly when promised. Lower defect rates, less hours, and happier people. This doesn't mean we didn't have crunch time, but we had a lot less of it, and people feel better about putting in the extra hours when necessary.
|
|
|
|
|
I've long advocated for a system where, at review time, effort is rewarded differently than accomplishment.
In my system, at the end of the year/quarter/whatever, the company would have a policy that says you get x% of any overtime worked back as a 'time-off' bonus (because effort should be recognized).
However, when it comes to raises and so on, it's all about what you accomplished. Don't care if you worked 90 or 30 hour weeks; did you accomplish less than, equal to, or more than what would be expected of someone at your level, and make salary adjustments based on that.
Of course, HR drones' heads exploded when asked to consider two dimensions of things...
|
|
|
|
|
Funny you should say that: in the late '80s, I wrote some stuff for British [pa]Telecom, and the last part of the project involved me actually being on site for a few weeks, during which I learned that the working day there consisted of the following:
1. Start of working day: 09:00.
2. Show up for work: 09:15. Go to cafeteria. Breakfast.
3. Start working: 09:45.
4. Elevenses: 11:00. Go to cafeteria.
5. Work some more: 11:20.
6. Lunch: 12:00. Go to cafeteria. And f*** it - have a few beers, too.
7. Work some more: 13:15.
8. Afternoon tea: 15:00. Go to cafeteria. Have coffee to recover from the beer at lunch.
9. Work some more: 15:20.
10. Go home: 16:30.
11. End of working day: 17:00.
...and the amount of work I did during that period was staggering. I came to dread the cafeteria -- in fact, after a few days, work began to feel like a vacation. It was astounding.
|
|
|
|
|
Not with all programmers. Some devs, specially young single mid-20s type devs like to work overtime (even without pay) and 50-60 hour weeks would not be unusual to them, nor does it affect their productivity all that much.
|
|
|
|
|
I get paid an annual salary.
For that salary I have to do a job.
The time taken to do that job makes no difference to what I get paid.
There is a nominal daily or weekly minimum of hours to be worked, but no maximum.
Some men are born mediocre, some men achieve mediocrity, and some men have mediocrity thrust upon them.
|
|
|
|
|
chriselst wrote: but no maximum.
Yes there is, 24 hours in one day. 
|
|
|
|
|
That depends which planet you're on.
Some men are born mediocre, some men achieve mediocrity, and some men have mediocrity thrust upon them.
|
|
|
|
|
But I do not work on Betelgeuse, only vacation there.
|
|
|
|
|
Are you tired of Ursa Minor Beta? 
|
|
|
|
|
And when the clocks go back? That takes you over 24hours for that day! 
|
|
|
|
|
I remember one job the time sheet system complained at anything over 20 hours. Regularly broke it and we had to get a fix to permit 100+ hours in a week.
|
|
|
|
|
I'm in the same boat. However, the OP looks to be under contract and not a salaried employee (maybe I'm wrong), he's getting paid for each hour worked, who cares what the other people are doing?
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
|
|
|
|
|
Quite.
I read is as he's brilliant, and everyone else is sh*t, which is why he gets paid the big bucks as a contractor, but because the sh*t salaried people work longer hours than he is prepared to it makes his sticking rigidly to the clock and going home look bad.
He isn't bad, he's good, he's better in fact.
It's so unfair.
Beats fists on floor, threatens to hold breath until passes out, and so on.
Some men are born mediocre, some men achieve mediocrity, and some men have mediocrity thrust upon them.
|
|
|
|
|
meeee-kin-owww!
Put your claws back before you rip your handbag! 
|
|
|
|
|
You can't worry about what you have no control over.
chriselst wrote: threatens to hold breath until passes out
Oh goody! 
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
|
|
|
|
|
Well...I *am* pretty awesome, but that's beside the point; thank you very much for noticing.
The larger point is that expectations of estimates get created based upon unrealistic results. Billing an 8 hour day but spending "14" hours on those tasks pollutes any project plan and makes honest assessments of the effort necessary to complete work look "slow." Then you lose more time trying to explain to people why things won't just be done when they come in the next morning as if by magic.
Past behavior sets future expectations and "your" lies end up directly impacting my ability to sell an honest product.
"I need build Skynet. Plz send code"
|
|
|
|
|
Re-read the OP's post. You completely missed the point.
When management sees an estimated 1,000 hour project complete "on time" they estimate all future projects with that project as the scale. If the project actually took 1,500 hours to complete? Guess what, the next one will, too.
The worst thing is the people who KNOW this is true, but estimate that same project at 1,000 hours anyway as it's what management/clients expect.
|
|
|
|
|
I didn't miss the point, I was making a joke, although some people don't understand what they are reading is a joke unless it has a joke icon.
Although his point wasn't quit your interpretation in my opinion.
Someone else nailed it when they talked about the phrase billable hours. Absolutely the management need to know who long something really took, but just because those on a salary stop all night to get something working doesn't mean that they were not recording their time against the project, I'd be very surprised if they were not.
Even more important they they understand what those hours were spent on. Did the initial dev take longer than expected, did it come back from testing with a load of extra work needing doing. Where the devs not good enough, the spec not good enough, the requirements gathering not good enough.
Maybe it really should have taken 1,000 hours, but took 1,500 because something went badly wrong.
Surely better to fix what went wrong and do the next one in 1,000 hours than just keep the crap and stretch it out to 1,500 instead.
Some men are born mediocre, some men achieve mediocrity, and some men have mediocrity thrust upon them.
|
|
|
|
|
jeron1 wrote: I have to ask, what do you care what the salaried employees do?
The real problem of course is that it means that the professionals don't understand the impact of that on the business. There are probably many but some include
- There is an expectation that everyone should work those hours
- Some employees don't want to work that long but do because of the expectations.
- Some employees cant work that long but feel like they are not contributing.
- Some employees that work that long, like doing so, but resent the ones that don' also do it.
- The above two impact moral in various ways. And moral is something that has been proven to impact productivity.
- When a normal work week consumes all the time that employees have then when an emergency develops something will fail because there are no hours left.
- Often such extra work is never added into the project thus there is no way a business can create an accurate project plan.
- The loss of a employee can hurt a normal project but, because employees have extra time, they can make up for that. Obviously when there is no extra time no one can make up for it.
- Over work very likely means cutting corners, which can impact quality. Doesn't of course mean that it it crap but it is unlikely that it as good as it could have been.
|
|
|
|
|
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
