Can someone explain to me why an IR thermometer even works?
The two reasons I would expect them to not work are:
- I would expect different materials to emit different amounts of IR light for a given temperature. So you couldn't just look at the intensity of IR light to gauge even surface temperature, without specifying the substance.
- When cooking meats, what you're mostly looking for is the internal temperature, not the surface temperature. And I would expect an IR thermometer to only be able to measure surface temperature.
This is low-tech, but it's yielded consistent, good results for me:
Texture and taste are best when it's medium-rare on the inside. Once I accepted this, everything fell into place and everyone now loves the results I get.
And, to get my results:
- Use high heat on the grill.
- Judge done-ness by how much resistance the steak offers when you push on it with tongs or whatever. I'm sure this could be measured, but it only takes a few steaks to developed your own judgment.
- Letting the steak rest for 5 minutes before serving really is a good idea. It's when the final internal cooking occurs (so you can avoid over-cooking the outside), and it seems to reduce how much juices leak out when you cut it.
- It's worthwhile to spend your money on a smaller cut of good steak, than a bigger cut of cheap steak. (If you're serving the steak on its own merits, as opposed to in a chili, stew, etc.)
I have a Dell M6500, and can vouch for the build quality and warranty support. OTOH, I paid $3000 for it a few years ago. Only good think about the price was I talked my salesman down from the $3800 list price for my configuration.
Okay, let me explain the structure a little. That might clarify the issue for you. I'll use the problem of information assurance officer (IAO) as an example. These are the people that will shut down your computers because they have a concern, often without talking to you, and with no sense of risk/benefit trade-offs.
(Joe programmer) - Guy working on project.
(Jane first-line manager) - Joe's boss. The one whom we're debating whether or not she's a "good" manager.
(Mordak) - Denier of Information Services. The IAO for Joe's and Jane's organization.
(Michael Scott) - The lowest-level government operative who has the authority to balance Joe's project needs vs. Mordak's paranoia.
The problem: Even though Mordak and Joe might be part of the same government agency, Michael Scott works in Washington, and has no clue that Joe can't get work done because of Mordak. There are 8 layers of org-chart between Joe and Michael Scott. And still 7 layers between Jane and Michael Scott.
Result: Michael Scott will never hear about Joe's problems, until 75% of the people under Michael Scott have the same problem as Joe. And then, the day before Michael Scott takes action, he's promoted to some other job, and Joe goes back to square one.
In a situation like this, there's basically nothing Jane can do to fix the problem, aside from running over Mordak in the parking lot. Which is tempting, but ultimately a poor choice and one to be avoided.
However, in my subjective opinion, the costs outweigh the benefits. Perhaps they wouldn't matter for someone who's career aspirations are to be a generic business drone. But for someone who primarily wants to write great software, the overall burden is awful.
I guess most of the federal agencies I've dealt with weren't well-functioning (or have a differing opinion on what the "right thing" is).
Perhaps. Although, from looking at other comments on this article, it's starting to sound like all kinds of organizations can be severaly dysfunctional.
I can only speak to my own experience. I've worked in industry, academia, and govt. Of all my jobs, the govt. job is the one where my coworkers' and my motivations have been the least self-serving. YMMV, obviously.
I'm sorry, but if you're developing in anything other than machine language, you're really leaving performance on the table. No namby pamby assembly, no wishy washy COBOL, no effete C, and definitely none of those worse options. Write it in machine language or know that you're an incompetent hack.
I'm disgusted at the inefficiency of your greenhorns' code. If you want moderately fast code, write new microcode. If you're a little better, use an FPGA. If you're a real man, your programming language should involve masks and X-ray lithography.
Government managers care about accountability, you are right. They care about not being the one being held accountable, that is about it - from my experience.
They will approve anything, as long as they can point the finger at someone else when shit goes wrong.
Apparently I've been more fortunate than you. My experiences with low-level managers has been much more positive.
This is why government organizations should be kept to a minimum. In industry, when the deadwood has accumulated, either it gets cleared out or the company dies. In government, you just get a funding increase.
I agree with the deadwood issue, but there are also some dynamics that favor having work done by government. The big one is that there's essentially no profit motive. In a well-functioning federal agency, all of the staff are encouraged to "do the right thing" for the people they serve, rather than maximize profit.
Secondly, because it's harder to fire someone from the U.S. federal government than from a U.S. private company, employees may be more willing to report illegal activity, because there may be less fear of effective retribution. Although my confidence in this has been eroded in recent years by seeing less whistle-blower protection than I would have expected.
To clarify: it's the labor cost of ordering the laptops / compilers that would show up as "overhead". The cost of the actual hardware / software would show up a project-related costs regardless of who's soul was consumed by making the order happen.
For example, suppose you needed to order some laptops for your developers, and some compilers as well.
Shouldn't that be handled by the manager or someone?
The actual coders should never have to look up the prices on any of their tools. New hardware should just show up as soon as the manager can complete all the paperwork and the political fights.
Good question. The reason is that if someone in an administrative / managerial role orders the hardware, it shows up as an "overhead" cost. Congress has made it clear that overhead costs need to be reduced. However, Congress wasn't willing to lighten the regulations that help drive up these overhead costs. So the only real option left to agency executive who aren't willing to push back on stupid Congressional mandates is to shift administrative work onto the software developers. Sure, it means the work is getting done by people with a much higher hourly rate, and it's an awful, dispiriting distraction to those people who should be coding. But that's "not my problem" from the perspective of spineless leaders who care about the appearance of efficiency, rather than actual efficiency.
You must not have a manager who cares about building your career, or maybe you aren't sufficiently motivated to move up. Might want to find a new boss or an injection of testosterone to get the juices flowing.
This is not something even a good boss can really solve for an employee. The fundamental issue, in my mind, is that the people who write, interpret, and enforce the bureaucracy's rules, will get beaten up only if the problem they're trying to prevent actually occurs. For example, a Section 508 compliance officer will get beaten up if they let someone buy a code analyzer that's not easily usable by someone who's color blind. Or an information assurance officer will get beaten up if there was any risk that a supposed vulnerability (even a false positive) went unpatched.
But those people get in no trouble if they (a) bring projects to their knees for lack of needed hardware/software, or (b) add weeks of delay to a project because they had a false-positive vulnerability report, which they "just to play it safe" take the project's source control server offline until the project members can prove that the vulnerability is in fact a false positive.
Working for the federal government can be awesome. I.e., keeping your fellow citizens safe in various ways is far more satisfying than is padding some CEO's excessive bonus. But between this bureaucratic crap, and having every Republican candidate for public office slander you to score political points, I'd say it's a wash at best.
Point being, the Federal government has an unimaginable capacity for shackling very good programmers, and sucking their capacity for excellence. That might explain why the federal government gets such mediocre results (at best), despite making a decent effort to hire from MIT, etc.
Slashdot Mirror
Actually, if it feels like my cheeks, it means it's a grilled tomato.
I should probably hit the gym more often.
No, it means I've showered and driven away!
Can someone explain to me why an IR thermometer even works?
The two reasons I would expect them to not work are:
- I would expect different materials to emit different amounts of IR light for a given temperature. So you couldn't just look at the intensity of IR light to gauge even surface temperature, without specifying the substance.
- When cooking meats, what you're mostly looking for is the internal temperature, not the surface temperature. And I would expect an IR thermometer to only be able to measure surface temperature.
This is low-tech, but it's yielded consistent, good results for me:
Texture and taste are best when it's medium-rare on the inside. Once I accepted this, everything fell into place and everyone now loves the results I get.
And, to get my results:
- Use high heat on the grill.
- Judge done-ness by how much resistance the steak offers when you push on it with tongs or whatever. I'm sure this could be measured, but it only takes a few steaks to developed your own judgment.
- Letting the steak rest for 5 minutes before serving really is a good idea. It's when the final internal cooking occurs (so you can avoid over-cooking the outside), and it seems to reduce how much juices leak out when you cut it.
- It's worthwhile to spend your money on a smaller cut of good steak, than a bigger cut of cheap steak. (If you're serving the steak on its own merits, as opposed to in a chili, stew, etc.)
Honestly, I wouldn't even know where to start.
I have a Dell M6500, and can vouch for the build quality and warranty support. OTOH, I paid $3000 for it a few years ago. Only good think about the price was I talked my salesman down from the $3800 list price for my configuration.
Okay, let me explain the structure a little. That might clarify the issue for you. I'll use the problem of information assurance officer (IAO) as an example. These are the people that will shut down your computers because they have a concern, often without talking to you, and with no sense of risk/benefit trade-offs.
(Joe programmer) - Guy working on project.
(Jane first-line manager) - Joe's boss. The one whom we're debating whether or not she's a "good" manager.
(Mordak) - Denier of Information Services. The IAO for Joe's and Jane's organization.
(Michael Scott) - The lowest-level government operative who has the authority to balance Joe's project needs vs. Mordak's paranoia.
The problem: Even though Mordak and Joe might be part of the same government agency, Michael Scott works in Washington, and has no clue that Joe can't get work done because of Mordak. There are 8 layers of org-chart between Joe and Michael Scott. And still 7 layers between Jane and Michael Scott.
Result: Michael Scott will never hear about Joe's problems, until 75% of the people under Michael Scott have the same problem as Joe. And then, the day before Michael Scott takes action, he's promoted to some other job, and Joe goes back to square one.
In a situation like this, there's basically nothing Jane can do to fix the problem, aside from running over Mordak in the parking lot. Which is tempting, but ultimately a poor choice and one to be avoided.
Citations, please.
Maybe, but I'm not seeing that happen.
I generally agree with your points.
However, in my subjective opinion, the costs outweigh the benefits. Perhaps they wouldn't matter for someone who's career aspirations are to be a generic business drone. But for someone who primarily wants to write great software, the overall burden is awful.
Perhaps. Although, from looking at other comments on this article, it's starting to sound like all kinds of organizations can be severaly dysfunctional.
I can only speak to my own experience. I've worked in industry, academia, and govt. Of all my jobs, the govt. job is the one where my coworkers' and my motivations have been the least self-serving. YMMV, obviously.
Well, it the 22 GW was the average output over some hour, then it's:
(2.2E10 Watts ) * (3.6E3 seconds) = 7.92E13 Joules.
I think.
It's just gigawatts, not gigawatts per hour.
I was thinking that. Maybe they meant that average power output, over one hour, was 22 GW?
I'm sorry, but if you're developing in anything other than machine language, you're really leaving performance on the table. No namby pamby assembly, no wishy washy COBOL, no effete C, and definitely none of those worse options. Write it in machine language or know that you're an incompetent hack.
I'm disgusted at the inefficiency of your greenhorns' code. If you want moderately fast code, write new microcode. If you're a little better, use an FPGA. If you're a real man, your programming language should involve masks and X-ray lithography.
What has education come to these days???
I've give a lot to be able to show the public the costs, financial and otherwise, of having the various mandates in place.
Government managers care about accountability, you are right. They care about not being the one being held accountable, that is about it - from my experience.
They will approve anything, as long as they can point the finger at someone else when shit goes wrong.
Apparently I've been more fortunate than you. My experiences with low-level managers has been much more positive.
I agree with the deadwood issue, but there are also some dynamics that favor having work done by government. The big one is that there's essentially no profit motive. In a well-functioning federal agency, all of the staff are encouraged to "do the right thing" for the people they serve, rather than maximize profit.
Secondly, because it's harder to fire someone from the U.S. federal government than from a U.S. private company, employees may be more willing to report illegal activity, because there may be less fear of effective retribution. Although my confidence in this has been eroded in recent years by seeing less whistle-blower protection than I would have expected.
I wonder if this is avoidable, or if all large organizations are doomed to have this quality.
Suffice it to say, your concerns don't apply to my situation.
To clarify: it's the labor cost of ordering the laptops / compilers that would show up as "overhead". The cost of the actual hardware / software would show up a project-related costs regardless of who's soul was consumed by making the order happen.
Agreed, but one of the things the government is supposed to be accountable for is efficiency.
As you correctly pointed out, red tape incurs a real cost. So beyond a certain point, red tape meant to prevent excessive spending is self-defeating.
Shouldn't that be handled by the manager or someone?
The actual coders should never have to look up the prices on any of their tools. New hardware should just show up as soon as the manager can complete all the paperwork and the political fights.
Good question. The reason is that if someone in an administrative / managerial role orders the hardware, it shows up as an "overhead" cost. Congress has made it clear that overhead costs need to be reduced. However, Congress wasn't willing to lighten the regulations that help drive up these overhead costs. So the only real option left to agency executive who aren't willing to push back on stupid Congressional mandates is to shift administrative work onto the software developers. Sure, it means the work is getting done by people with a much higher hourly rate, and it's an awful, dispiriting distraction to those people who should be coding. But that's "not my problem" from the perspective of spineless leaders who care about the appearance of efficiency, rather than actual efficiency.
You must not have a manager who cares about building your career, or maybe you aren't sufficiently motivated to move up. Might want to find a new boss or an injection of testosterone to get the juices flowing.
This is not something even a good boss can really solve for an employee. The fundamental issue, in my mind, is that the people who write, interpret, and enforce the bureaucracy's rules, will get beaten up only if the problem they're trying to prevent actually occurs. For example, a Section 508 compliance officer will get beaten up if they let someone buy a code analyzer that's not easily usable by someone who's color blind. Or an information assurance officer will get beaten up if there was any risk that a supposed vulnerability (even a false positive) went unpatched.
But those people get in no trouble if they (a) bring projects to their knees for lack of needed hardware/software, or (b) add weeks of delay to a project because they had a false-positive vulnerability report, which they "just to play it safe" take the project's source control server offline until the project members can prove that the vulnerability is in fact a false positive.
Working for the federal government can be awesome. I.e., keeping your fellow citizens safe in various ways is far more satisfying than is padding some CEO's excessive bonus. But between this bureaucratic crap, and having every Republican candidate for public office slander you to score political points, I'd say it's a wash at best.
Point being, the Federal government has an unimaginable capacity for shackling very good programmers, and sucking their capacity for excellence. That might explain why the federal government gets such mediocre results (at best), despite making a decent effort to hire from MIT, etc.