Sounds a bit like that Simpsons episode, The Secret War of Lisa Simpson. Bart: I know, I'll go to my room to think about what I did. Homer: Oh, no, your room is full of toys. You're going to the, uh, garage. Bart: You're the boss. Marge: I tell you, Chief, I just don't know what we're going to do with him. Wiggum: You know, you do have options. [Bart rides by the living room window on a lawn mower]
In this thread, I've seen posts of the kind "The employer is right--web sites should be blocked," "Fire the unproductive people," and so on. What these posts are missing is something very key--happy employees are more productive than unhappy ones, happy people are those with control, and one aspect of control is being able to decide whether to waste time or use it wisely. The employer who blocks web sites is essentially saying, "We don't trust you to be intelligent enough to decide when to work and when to screw around. We don't believe there is a maximum number of productive hours in a time quanta, the remainder of which need to be spent on other things, or only damage will be done. We know better than you what is your best work strategy."
Who would want to work for an employer that effectively says, "We hire incompetent, unproductive employees?" At best, it's insulting to the person being hired. At worst, the person being hired is competent, and now he's got incompetent, unproductive coworkers to deal with.
I've read two really good items on the subject of estimating software schedules. The first is Painless Software Schedules by Joel Spolsky, the Joel in Joel on Software. It's a quick read, and a lot of the comments here are giving the same advice all spread out. Even more useful is Waltzing With Bears by Tom DeMarco (ISBN 0932633609) (very talented author, I strongly recommend Peopleware to everyone), which is about managing risk on software projects, especially as it relates to time. This is one of the fundamental errors in the question "How long will it take?"--the inquirer wants an exact amount of time, so if you say it will take four hours, it should take exactly four hours. The problem is, you may luck out--someone may have had that feature in the program once already, and it was removed, so all you need to do is call some fully-tested code from a different place, or there may be high coupling, so that what looks like a really simple, straightforward change is insanely hard. Those two factors put together means giving an estimate should be something like "No more than forty hours, 75% probability of finishing within twenty-four hours, 50% chance of finishing within six hours, 25% of finishing within four hours, no quicker than an hour." As part of Waltzing With Bears, Tom DeMarco (and I assume others) put together a Riskology spreadsheet, intended to allow you to estimate schedule probability curves, which allows combining multiple probability curves to get an estimate more like "No faster than eight months, 75% within six and a half months, 50% within five months, 25% within ten weeks, no faster than four weeks." And always make sure the first number people hear is the worst case scenario--that's the one they're going to remember.
Mike, and everyone else at Looking Glass: You guys did some damn fine work. Thief (and even more, Thief II, to say nothing of System Shock 2) is reason enough to have a Windows box.
Windows Vista and Mac OS X appear to be very similar, at least if this video is any indication. The audio is from a preview of Windows Vista, while the video is a live Macintosh desktop.
Not just software engineer, but did you notice the guy listed as having the best job works at EA on games? After that, I just couldn't take the article seriously.
Even better, have two competing companies (or one open source, one closed source; the idea is, two discrete organizations create the method) provide the equipment to run each type of election. In this case, one company would provide the touchscreen voting machine that creates the paper ballot, filled out suitably for an optical scanner to read. An optical scanner then scans that ballot later on (or just if necessary, depending on how corrupt/wholesome whoever has interest in this decides the first organization is). If there's a substantial discrepency, you know that at least one of the organizations is failing to provide an accurate count, and a hand recount may be performed in this case, almost certainly indicating which organization is more corrupt. Fraud would still be possible in the case of both organizations cooperating to rig an election, but this may still be caught by a hand recount.
Borderline nothing. This statement is treasonous, and Houston police chief Harold Hurtt should be arrested on charges of terrorism--because as I understand the administration's statements, that's what terrorists do: Try to destroy the American way of life.
Why bother with clothes? We've almost got eInk, which takes a lower current to change state than would cause any injury (though it would be perceptible). Instead of having white and black sides, have fleshtone and not fleshtone, and inject it into the skin.
Re:What's wrong with a laughter track?
on
IT Crowd On-line
·
· Score: 1
It's probably a standard, USian reaction to laughter tracks. Here, if anything is intended to be a joke, it gets canned laughter added after it. This ruins any subtle humor, since the canned laughter draws attention to every intended joke, and emphasizes the failure of jokes that aren't funny, which leads people to be hostile to laugh tracks in general.
I've done this twice with OpenBSD. It's not quite fire and forget (things like the OpenSSH vulnerability still rear their ugly head), but you can plan on kernel patches every six months and keep services to a minimum.
Joel on Software posted a very useful book list, which extends more to the management of programming than to any specific language. This makes it more generally useful than yet another C book.
Slashdot Mirror
Sounds a bit like that Simpsons episode, The Secret War of Lisa Simpson.
Bart: I know, I'll go to my room to think about what I did.
Homer: Oh, no, your room is full of toys. You're going to the, uh, garage.
Bart: You're the boss.
Marge: I tell you, Chief, I just don't know what we're going to do with him.
Wiggum: You know, you do have options.
[Bart rides by the living room window on a lawn mower]
In this thread, I've seen posts of the kind "The employer is right--web sites should be blocked," "Fire the unproductive people," and so on. What these posts are missing is something very key--happy employees are more productive than unhappy ones, happy people are those with control, and one aspect of control is being able to decide whether to waste time or use it wisely. The employer who blocks web sites is essentially saying, "We don't trust you to be intelligent enough to decide when to work and when to screw around. We don't believe there is a maximum number of productive hours in a time quanta, the remainder of which need to be spent on other things, or only damage will be done. We know better than you what is your best work strategy."
Who would want to work for an employer that effectively says, "We hire incompetent, unproductive employees?" At best, it's insulting to the person being hired. At worst, the person being hired is competent, and now he's got incompetent, unproductive coworkers to deal with.
I've read two really good items on the subject of estimating software schedules. The first is Painless Software Schedules by Joel Spolsky, the Joel in Joel on Software. It's a quick read, and a lot of the comments here are giving the same advice all spread out. Even more useful is Waltzing With Bears by Tom DeMarco (ISBN 0932633609) (very talented author, I strongly recommend Peopleware to everyone), which is about managing risk on software projects, especially as it relates to time. This is one of the fundamental errors in the question "How long will it take?"--the inquirer wants an exact amount of time, so if you say it will take four hours, it should take exactly four hours. The problem is, you may luck out--someone may have had that feature in the program once already, and it was removed, so all you need to do is call some fully-tested code from a different place, or there may be high coupling, so that what looks like a really simple, straightforward change is insanely hard. Those two factors put together means giving an estimate should be something like "No more than forty hours, 75% probability of finishing within twenty-four hours, 50% chance of finishing within six hours, 25% of finishing within four hours, no quicker than an hour." As part of Waltzing With Bears, Tom DeMarco (and I assume others) put together a Riskology spreadsheet, intended to allow you to estimate schedule probability curves, which allows combining multiple probability curves to get an estimate more like "No faster than eight months, 75% within six and a half months, 50% within five months, 25% within ten weeks, no faster than four weeks." And always make sure the first number people hear is the worst case scenario--that's the one they're going to remember.
Other reading:
Coding Horror, How Long Would It Take If EVERYTHING Went Wrong?
Software Estimation: Demystifying the Black Art by Steve McConnell
Google on Estimating Software Projects
Knowing eBay, it will be 30 or so someones, all offering the actual meteorite.
Mike, and everyone else at Looking Glass: You guys did some damn fine work. Thief (and even more, Thief II, to say nothing of System Shock 2) is reason enough to have a Windows box.
Shame, really.
Windows Vista and Mac OS X appear to be very similar, at least if this video is any indication. The audio is from a preview of Windows Vista, while the video is a live Macintosh desktop.
Not just software engineer, but did you notice the guy listed as having the best job works at EA on games? After that, I just couldn't take the article seriously.
For more insightful advice of this nature, see 10 Stupid Mistakes Made by the Newly Self-Employed, first linked from Joel Spolsky's Reddit page and later on the front page of Reddit.
Yeah! I mean, that's long enough to perform an utterance sufficient to rewrite the laws of physics with enough time left to move 30 feet.
And cue the search-and-replace Stephen King posts. Truly a Norweigan icon.
Even better, have two competing companies (or one open source, one closed source; the idea is, two discrete organizations create the method) provide the equipment to run each type of election. In this case, one company would provide the touchscreen voting machine that creates the paper ballot, filled out suitably for an optical scanner to read. An optical scanner then scans that ballot later on (or just if necessary, depending on how corrupt/wholesome whoever has interest in this decides the first organization is). If there's a substantial discrepency, you know that at least one of the organizations is failing to provide an accurate count, and a hand recount may be performed in this case, almost certainly indicating which organization is more corrupt. Fraud would still be possible in the case of both organizations cooperating to rig an election, but this may still be caught by a hand recount.
I'm not reading all that.
Borderline nothing. This statement is treasonous, and Houston police chief Harold Hurtt should be arrested on charges of terrorism--because as I understand the administration's statements, that's what terrorists do: Try to destroy the American way of life.
I meant for a display, not as a clothes replacement. Envision a PDA that you can not lose and have at all times, and we'll be on the same page.
Why bother with clothes? We've almost got eInk, which takes a lower current to change state than would cause any injury (though it would be perceptible). Instead of having white and black sides, have fleshtone and not fleshtone, and inject it into the skin.
It's probably a standard, USian reaction to laughter tracks. Here, if anything is intended to be a joke, it gets canned laughter added after it. This ruins any subtle humor, since the canned laughter draws attention to every intended joke, and emphasizes the failure of jokes that aren't funny, which leads people to be hostile to laugh tracks in general.
They say replying to your own Slashdot posts is among the first signs of madness.
I've done this twice with OpenBSD. It's not quite fire and forget (things like the OpenSSH vulnerability still rear their ugly head), but you can plan on kernel patches every six months and keep services to a minimum.
Given the results of the Sony debacle, I'm inclined to believe that Symantec et al would not face extreme criminal charges.
If you're going to do this, why not just use /dev/null as the primary output device? Save the expense of using an extra sound card.
I wouldn't worry about it, it still couldn't be as painful as reading The Andromeda Strain by Michael Crichton.
Joel on Software posted a very useful book list, which extends more to the management of programming than to any specific language. This makes it more generally useful than yet another C book.
Mind your neighbor doesn't make a Burns sun-blocker.
Yes, you're missing something. The DMCA is a US law. This is a story about UK law.
I don't know, you want to be careful with Protocol Seven.