Do you seriously believe that BP is "fingerpointing" instead of working hard to stop/limit the flow?
They have every incentive to deploy every possible asset that can be deployed effectively to stop/limit the flow. This mess is a PR and financial nightmare for BP and the earlier the flow stops, the earlier the pain stops. I've not seen any evidence they are not doing so. Of course, they might not be. However, the fact that they don't instantly act on the recommendation of/. experts who think they should just "nuke" the well doesn't indicate they aren't, it just suggests they are using good engineering practices rather than acting recklessly on emotional hope.
They aren't going to admit fault now (although, it sounds like they screwed up big time via a series of moderate screwups), but they seem to be taking responsibility for fixing the problem.
Indeed, most of the finger pointing has resulted from the politicians getting involved and staging political shows. If anything, this distracts the engineers and management from fixing the problem. The politicians should shut up until it's fixed. The government should keep a close eye on it (unfortunately, I doubt the government can do much to fix it except hire the same folks that BP hires) and use a big stick if necessary. But, until it's fixed, I want every bit of talent at BP (or hired by BP) attending to fixing the problem, not making PowerPoint slides for Congressional hearings. The time to argue is later, the time to fix it is now.
I believe the summary misstates the article (I know that's shocking).
The summary:
A vessel at the surface will use 30,000 horsepower pumps to slam kill mud and clay into the well's bent riser,
The article:
It will use the BOP's three-inch-diameter choke and kill lines, which open into the space between the well's casing and the drill pipe that runs up the riser. The lines are being cut and spliced into hoses connected to the Q4000, a vessel on the surface, whose 30,000-horsepower pumps will drive a dense mix of clay and other substances called kill mud into the lines.
The kill line is part of the BOP. Nothing is being forced back down the riser (the bent, broken, patched, leaking mile long pipe now laying on the ocean floor).
Here's nice graphic showing what they seem to be trying to do.
Why do you think they are/were trying to "save the well"?
From the early days of the disaster, BP has (I think) said they were going to permanently cap the well with "concrete" via the relief wells. They started drilling the first relief well very quickly - I was surprised how soon they had a drill rig out there, those things aren't stocked on the shelf at WalMart.
Or, to rephrase... Explosives are often used to put out oil well fires on land. Then, utilizing the remaining wellhead (and possibly Christmas tree) structure (which, fortunately, weren't all vaporized by cowboys who think "if some explosives are good, more are better"), crews cap the well using mechanical means (such as installing a new valve).
It seems to me that the last thing that one would want to do in this case is blow up the BOP - it's routing, and apparently choking off much of, the flow. If a failed explosive attempt were to destroy/disconnect the BOP yet not seal the well I think we would be looking back at the current flow nostalgically. Given the apparent lack of experience using explosives to deal with a situation like this it seems likely too risky to attempt -- given that the relief wells are eventually expected to solve the problem.
I recall the early laser printers in use internally at Xerox - the ones I saw were a standard copier modified/altered to be a printer. From a distance, the biggest hint that it was a printer and not a copier was an extra box stuck on the end and, behold, an Alto nearby.
Of course, IIRC, they wouldn't function as a copier anymore, so maybe it doesn't count.
Who said we would get material (esp. if it's just something like DNA) from only one or two parents?
It seems if you caught the potential extinction early, one could actually collect material from many diverse samples of the species across the widest possible geographical range.
In the wild, diversity is affected by geographical distance between members of the species - this is not true in the lab. When it came time to recreate the species, couldn't you have a more diverse initial population than the endangered species had enjoyed in a long time because you can create pairings that would never have occurred in the wild?
Also, suppose the lab could do some sort of random DNA cutting/splicing between samples and even introduce some targeted "random" mutations to create an almost infinite number of unique "offspring" which are all members of the species - possibly in a few days one could create more diversity than had ever existed in the wild. Of course, the lab would need to decide which to keep and which to discard early in the developmental cycle - we probably don't want 100 unique mastodons for every human on earth (although I might change my mind about this after sampling a properly cooked mastodon ribeye steak).
2. Individuals being held criminally accountable for corporate behavior
That's a pretty high bar.
Mere inadvertent oversight or bad judgment isn't criminal. Although extraordinary negligence can in some cases be criminal, that doesn't cover very many cases.
We don't yet know enough about this case, but who should be criminally negligent?
The low level guys on the rig who made some bad decisions and/or agreed to continue working knowing that at least one of the contributing factors existed?
The highest executive who knew about the individual BOP problems (there is probably no one very high up that knew about either the individual problems or the collection of all the problems)?
The CEO and all the board members "because they should have known and insure that processes were implemented to prevent anything slipping through the cracks"?
If we move the bar too low for criminal negligence in the US, programmers will just go to work for WalMart as greeters.
I sure as heck am not going to risk 20 years in jail because I didn't fully test and verify every edge case in every runtime routine my code calls - even though I "should" on the off chance that my code may eventually, in some obscure way, end up killing someone (such as, the wrong answer from a database query results in ordering too many tons of potatoes for a Walmart store and while trying to stack the extra potatoes, a worker is crushed):)
In any event, I certainly can't expect the CEO to be any more liable for her work than I am for mine. (The corporation is of course equally liable for both our work).
[Warning, this entire post is United States centric as that's the system I know best.]
When the losses impact the general public (not just willingly participating investors and customers who voluntarily chose to take the risks of being an investor or customer of the corporate entity), the general public still bears the damage costs if the company goes BK due to causing damages well in excess of its true assets.
It would seem to make sense to require companies to post bonds and/or dependable insurance and/or maintain sufficient assets to cover the damage they can cause to the general public in worst case disasters. Of course, this is impractical in some cases (for example, the worst possible scenario for multiple simultaneous nuclear power plant disasters, while HIGHLY unlikely, could cause an enormous amount of long term damage -- well beyond what a single company who owned all the failed power plants can have the assets to cover). In some cases, this leads to government mandated "risk pools", sometimes funded by mandatory industry "contributions", with liability caps for individual companies.
However, it's important to note that individuals, not just corporations, rarely are able to fulfill their obligations to compensate victims for "worst case damages" arising from their actions. Therefore, one should be very careful before complaining about "corporate responsibility" in such cases.
Consider that a "really bad case" auto accident can result in damages in the range of (present value) tens of millions of USD. Consider, for example, an accident where the "not at fault" car had two young and highly skilled and compensated parents in the front seat and seventeen year old twins (both very smart and with bright futures having just completed their second year at Harvard with stellar performance) in the back seat. In the accident, all four individuals suffer substantial permanent but non-fatal brain damage and are all rendered quadriplegic. All four require 7x24 care for the rest of their lives and lost the ability to ever perform work for meaningful compensation. The damages include:
Future lost wages of parents and kids. Say 2 parents at $200K/yr for 40 years = $16M and 2 kids at average of $100K/yr (probably substantially lower than average annual wages over the life of a stellar Harvard grad in present value) each for 45 years of work = $9M for a total of $25M in lost wages.
The incremental cost of quality 7x24 care for four brain damaged quadriplegics above and beyond what a similar life style would have cost them in the absence of the accident, along with costs of additional health problems associated with their compromised condition. Even assuming a somewhat decreased life span due to the injuries, figure 50 years * 4 *$250K/year = $50M.
Harder to calculate "pain and suffering". A jury would decide this -- "Dear Jury, when you go into the jury room to determine damages, ask yourself 'What is the minimum lump sum payment you would accept to give up your current life style and exchange it for the suffering my poor client will experience for the rest of their lives?". In any event, this would probably be millions of dollars per person, so I'll call it $5M*4 = $20M.
So, I think fairly conservatively, we have $25M+$50M+$20M = $95M in damages.
Knowing that it's conceivable that anyone could cause such an accident (even a pedestrian inadvertently crossing a street against a red light could cause the driver of our unfortunate family's car to swerve and lose control resulting in this accident -- so even people who only walk to mass transit could be liable for this case), fellow/.er's, ask yourselves: Do you have assets or insurance to compensate for the damages you caused in such a case? I would wager that over 95% of those reading this have to answer "NO".
Indeed, I'll bet the vast majority of/.ers who even think of such things (whi
There can be no more, because none are currently alive.
is perhaps too strong a statement given likely advances in biology et al. Is a species extinct if sufficient material (such as egg+sperm or maybe just DNA) exists to recreate the species with current technology? What about with reasonably anticipated future technology?
Having RTFA (okay, not wanting to be banned from/., I only S(kimmed)TFA), it quotes a chap named Simon Humphreys ("the British Computing Society's coordinator of computing at school" - whatever that means) as:
"The Computing A Level is not intended as a programming course but a course that covers the fundamentals of computing of which programming (and problem solving) form a key component."
Not being sufficiently familiar with A Levels, I'll take this as fact.
It seems that C, having at least some notion of pointers, would be valuable in helping tie together the lower levels to the higher levels. True, assembly might be better, but it's used so little now that it's rarely of much specific later use (as contrasted to so much FOSS being in C that one is likely to run into C eventually). For example, if one knows C, one might be able to better grok why the Linux kernel isn't being rewritten in VB.Net 2008.
But, I suppose there is only so much time to teach stuff between text messages.
But the problem in the Gulf is not the fire (there is no fire except the controlled burns of the slick that they are attempting from time to time), it's the "flowing" oil.
On land, the explosives put out the fire, the oil flow remains and workers then cap that flow mecanically once the fire is out. The explosives are not used to cap the well.
Ahh..., but is the accounting of time spent strong enough to protect the programmer?
Work done on your computer on company (or University) time is typically the property of the company (or, in this case, the University) - utilization of any company (or University) resource is typically enough to make it a work product of one's employment. The question isn't if all resources used were company (or University) resources.
If there is not strict time accounting (clock in/out and what you spent your time on while "at work") of both your professional time and your personal time and the code you're working on is generally the same as the code you work on at work, you're going to need a whole lot of high priced legal help to defend your position (and if you had the resources and inclination to pick a fight in this domain, you simply would have asked your attorney this question instead of asking us/. idiots).
Generally, if you care, quit your position, wipe your hard drives, and in the future carefully partition your "volunteer" work and your paid work.
Yep, it sucks -- but I've seen people spend a whole lot of money on lawyers for naught on cases like this. Or, just play the roulette wheel and figure that this code really isn't that important and no one is going to fight you over anything short of outright code theft.
It's true that Google will let you go wherever you want...
Unfortunately they will track everywhere you go and add that info into their galactic databases. Then they will use that info to help sell you crap. But it will be convenient, you won't even have to bother to actually order stuff - Google will just know what you want and order it for you (conveniently debiting your bank account and adding a nominal Google Product Procurement Fee to the charge). Google will even know when you will be home to receive it (since, of course, you SHALL use Google calendar) when it's delivered by Google Parcel Service.
Although, IMHO, it's all futile in the end and reflects the misplaced arrogance of humans. I'd short humans and go long on bacteria and cockroaches.
The climate on Earth will change to the point that today's humans can't live on it without their population slowly declining - eventually to zero. Humans evolve poorly for a variety of reasons:
They bear children in small numbers and relatively late in life (fewer generations per unit of climate change compared to, say, bacteria or cockroaches).
There aren't very many humans on Earth (individual humans require a lot of resources to prosper so, compared to bacteria and cockroaches, there can't be as many of them) resulting in fewer opportunities for beneficial random mutations to arise.
For as long as they can, humans will fight their only (albeit, remote) hope for survival -- their own evolution via natural selection -- by focusing on keeping individuals alive rather than keeping the species viable. Therefore those humans who are, by chance, genetically better suited to survival in the changed climate will have to compete for resources with those who are not as well suited but were "artificially" kept alive to breed (although this is a political and emotional bias, albeit perhaps rooted in genetics, and eventually this will end as survival instincts overcome political correctness it will likely happen too late even if humans could evolve quickly enough to adapt).
About the only hope for long term (many millions of years) survival of humans seems to be to continually populate planets/chunks of matter elsewhere in the universe that happen to, in that particular era, have an environment well suited for human existence. However, this seems quite unlikely to happen -- at this point, there are no planets known to humans which even come close to meeting this requirement so humans would have to travel and explore way beyond where they've even sent man made objects so far and, I suspect, only a tiny percentage of environments qualify and humans are unlikely to find one before they are focusing all resources on short term survival rather the space exploration.
That said, yes, humans can probably accelerate or delay the demise of their species (maybe by tens or hundreds of thousands of years?) and maybe this is worth something to some folks -- although caring one way or the other seems rather illogical to me. No matter what, the end game is going to be painful for those who have to play it -- either way, the last generations of humans will likely live horrible (by current standards) lives and die horrible (by current standards) deaths as they desperately fight a losing battle for survival. Not pretty, but inevitable IMHO.
Well at least we agree that the world would be a much better place if developers would spend more time thinking and less time coding.
Although there are certainly times when brainstorming et al is very helpful, good developers know when that's needed and seek it out -- there's no need to push it on them. I'm actually more likely to seek collaboration in a office environment. First, I only need to disturb one person. Second, I usually want to collaborate with a particular person or two for a particular problem -- I really don't want the input from people who know little about the problem or subsystem as it just distracts the conversation and extends its duration.
In my experience, "team designs" addressing complex problems usually seem to work on the surface but often have serious and sometimes fatal flaws deep down (esp. in the areas of concurrency and fault recovery). Team design leaves too little time to linger on one person's passing concern - something that doesn't quite pass the sniff test - the team moves on.
For simple things, if team design is needed, probably the problem is that most members of the team should find another career more suited to their interests/skills. None of this is to say that collaboration is not appropriate, but it's a small percentage of the time and the environment should be optimized for what is appropriate the majority of the time. This is especially the case if, as in the bullpen vs. cubicle vs. office discussion, structured collaboration is not interfered with in any way by selecting the same environment (offices) that optimizes that which one spends most of their time on.
This seems like a religious argument on both sides. I've experienced "team design" type environments and, invariably, I can tear holes in the designs much more easily than in designs that were the product of one, or occasionally two, skilled developers. Perhaps somewhere there is an alternate universe where this is not true - I'd love to be a fly on the wall to see that to understand why it's not true (different problem domain? different developer experience level? different accountability? different priorities on quality vs. feature vs. schedule?)
Absolutely. If the quality of the output isn't important enough to provide developers with an environment with minimal distractions, it's probably not worth paying US wages for and likely should be off-shored.
Umm... that "sales and all the other riffraff" probably actually have a clue about how customers are using your product and/or why prospects are/are not buying it and/or why it is/is not meeting their needs. Yep, you need to keep the price of entry a little high, but I'd much rather talk to a good SE, support or sales person about the product than be distracted by some developer bragging about his clever (NOT) solution for problem X or pontificating about some non-work related topic (I expect some non-work related chatter, it's just that two people chattering for a few minutes in one of their private offices gives them both a break but if they do it in a room of ten people, it distracts eight other people)
Although, maybe some SEC employees should have worked in that configuration, it might have discouraged some of their less productive web surfing if they feared being surprised by the boss!
It's so sad that our industry has gotten to this point where the discussion is not over "offices vs. cubicles" but over "bullpen layout A vs. bullpen layout B". Most of development work is actually solitary and productivity and quality (in the terms of correctness) benefits from the ability to concentrate, which in turn is much easier when there are fewer distractions.
Much (probably most) of my career I've had a private office and, compared to those times I was in a cubicle bay, I got more work and better quality work done in the office environment. Although, that may be not entirely due to the office vs. cubicle difference as the companies that gave offices to developers were also understood more about what developers needed to be productive - less PHB MBA crap and heavy handed IT rules etc.
The need for continuous collaboration suggests that interfaces are not well documented or perhaps even well defined and/or the system/feature architecture is not well thought out. It also suggests that too much information is "in people's heads" -- and hence the company will incur unnecessary expense if one or more people get hit (very hard) by a bus (or, I suppose, a buss) or leaves the company. This isn't to say some collaboration isn't necessary (certainly for brainstorming about design issues and for the occasional "WTF is this code trying to do and why?") - indeed, if no ad hoc collaboration is needed, I suspect that too much effort has been expended on design and documentation. There's a happy medium.
So, the answer to the original question is "Yes, every workspace needs to be surrounded by floor to ceiling walls except for a door that closes! I once worked at a company which was locating to new facilities which were being built out for us. The facilities folks decided that cubicles for all was the answer. The developers pretty much stood up and said "over our dead bodies" and in the end all developers had private offices except for very junior ones (this actually made some sense because the less experienced one is, I think the more likely one is to learn from "random chatter" vs. be distracted by it - the first discussion you overhear about cache coherency models is much more valuable than the 30th one). Funny thing was, I noticed that even the facilities folks mostly had their own offices in the end - even though they were the ones arguing that wasn't necessary and citing studies that cubicles were more productive!
Anything past that is useless to humans (just magnify the section of the picture you are looking at if you don't want to see the entire picture at once.)
I don't think this is always the case for working at a computer monitor.
When doing development, esp. debugging systems with many threads/processes, I sometimes have a lot of windows open (many code modules, variable watch windows, stack traces for many threads, etc.) and never really "look at the entire screen". My focus flits around the screen at the thing of interest at that instant. My eyes are moving and my head moves slightly (left/right, up/down and, probably to the dismay of ergonomics police, forward/backward a bit) throughout this - no mouse movement, no scroll/zoom keys etc - these are all way too slow. When I'm focusing on a small piece of the screen, I want a lot of pixels there so I can read the (now tiny) fonts w/o strain. There is some limit to this of course.
The limit of comfortable head/eye movement limits the size of the monitor - and that may be somewhere around 30", but the number of useful pixels on that screen are only limited by how small a piece of that screen I can focus on by moving my head/eyes.
Well, he could have just released the passwords - his arrogant refusal to do so coupled with the stupidity of the City in not making sure that no IT person had this much power is what landed him in jail. He could have avoided that outcome at almost no cost by releasing the passwords.
I would argue that the passwords are the property of the city and hence he stole them. Just as if he had taken the only copy of the payroll program and refused to return it. All employee manuals, agreements, and NDAs I've seen in recent years stipulate that all copies of confidential information (which, passwords would seem to be) must be returned to the employer. Passwords really seem no different that a product marketing roadmap in this respect.
This, by the way, is one reason why all that "sealed password envelope" crap is nonsense. At a minimum, these envelopes need to be opened and the passwords tested randomly from time to time - and if they are not right, the IT person responsible for keeping the envelopes up to date should get fired - no questions asked.
Slashdot Mirror
Do you seriously believe that BP is "fingerpointing" instead of working hard to stop/limit the flow?
/. experts who think they should just "nuke" the well doesn't indicate they aren't, it just suggests they are using good engineering practices rather than acting recklessly on emotional hope.
They have every incentive to deploy every possible asset that can be deployed effectively to stop/limit the flow. This mess is a PR and financial nightmare for BP and the earlier the flow stops, the earlier the pain stops. I've not seen any evidence they are not doing so. Of course, they might not be. However, the fact that they don't instantly act on the recommendation of
They aren't going to admit fault now (although, it sounds like they screwed up big time via a series of moderate screwups), but they seem to be taking responsibility for fixing the problem.
Indeed, most of the finger pointing has resulted from the politicians getting involved and staging political shows. If anything, this distracts the engineers and management from fixing the problem. The politicians should shut up until it's fixed. The government should keep a close eye on it (unfortunately, I doubt the government can do much to fix it except hire the same folks that BP hires) and use a big stick if necessary. But, until it's fixed, I want every bit of talent at BP (or hired by BP) attending to fixing the problem, not making PowerPoint slides for Congressional hearings. The time to argue is later, the time to fix it is now.
The summary:
The article:
The kill line is part of the BOP. Nothing is being forced back down the riser (the bent, broken, patched, leaking mile long pipe now laying on the ocean floor).
Here's nice graphic showing what they seem to be trying to do.
Why do you think they are/were trying to "save the well"?
From the early days of the disaster, BP has (I think) said they were going to permanently cap the well with "concrete" via the relief wells. They started drilling the first relief well very quickly - I was surprised how soon they had a drill rig out there, those things aren't stocked on the shelf at WalMart.
Or, to rephrase... Explosives are often used to put out oil well fires on land. Then, utilizing the remaining wellhead (and possibly Christmas tree) structure (which, fortunately, weren't all vaporized by cowboys who think "if some explosives are good, more are better"), crews cap the well using mechanical means (such as installing a new valve).
It seems to me that the last thing that one would want to do in this case is blow up the BOP - it's routing, and apparently choking off much of, the flow. If a failed explosive attempt were to destroy/disconnect the BOP yet not seal the well I think we would be looking back at the current flow nostalgically. Given the apparent lack of experience using explosives to deal with a situation like this it seems likely too risky to attempt -- given that the relief wells are eventually expected to solve the problem.
Actually, for perhaps 35 years :)
I recall the early laser printers in use internally at Xerox - the ones I saw were a standard copier modified/altered to be a printer. From a distance, the biggest hint that it was a printer and not a copier was an extra box stuck on the end and, behold, an Alto nearby.
Of course, IIRC, they wouldn't function as a copier anymore, so maybe it doesn't count.
Now get off my lawn.
Who said we would get material (esp. if it's just something like DNA) from only one or two parents?
It seems if you caught the potential extinction early, one could actually collect material from many diverse samples of the species across the widest possible geographical range.
In the wild, diversity is affected by geographical distance between members of the species - this is not true in the lab. When it came time to recreate the species, couldn't you have a more diverse initial population than the endangered species had enjoyed in a long time because you can create pairings that would never have occurred in the wild?
Also, suppose the lab could do some sort of random DNA cutting/splicing between samples and even introduce some targeted "random" mutations to create an almost infinite number of unique "offspring" which are all members of the species - possibly in a few days one could create more diversity than had ever existed in the wild. Of course, the lab would need to decide which to keep and which to discard early in the developmental cycle - we probably don't want 100 unique mastodons for every human on earth (although I might change my mind about this after sampling a properly cooked mastodon ribeye steak).
Chemotherapy is, in fact, also used to extend life for some terminally ill cancer patients (such as some cases of stage IV colon cancer).
That's a pretty high bar.
Mere inadvertent oversight or bad judgment isn't criminal. Although extraordinary negligence can in some cases be criminal, that doesn't cover very many cases.
We don't yet know enough about this case, but who should be criminally negligent?
If we move the bar too low for criminal negligence in the US, programmers will just go to work for WalMart as greeters.
:)
I sure as heck am not going to risk 20 years in jail because I didn't fully test and verify every edge case in every runtime routine my code calls - even though I "should" on the off chance that my code may eventually, in some obscure way, end up killing someone (such as, the wrong answer from a database query results in ordering too many tons of potatoes for a Walmart store and while trying to stack the extra potatoes, a worker is crushed)
In any event, I certainly can't expect the CEO to be any more liable for her work than I am for mine. (The corporation is of course equally liable for both our work).
When the losses impact the general public (not just willingly participating investors and customers who voluntarily chose to take the risks of being an investor or customer of the corporate entity), the general public still bears the damage costs if the company goes BK due to causing damages well in excess of its true assets.
It would seem to make sense to require companies to post bonds and/or dependable insurance and/or maintain sufficient assets to cover the damage they can cause to the general public in worst case disasters. Of course, this is impractical in some cases (for example, the worst possible scenario for multiple simultaneous nuclear power plant disasters, while HIGHLY unlikely, could cause an enormous amount of long term damage -- well beyond what a single company who owned all the failed power plants can have the assets to cover). In some cases, this leads to government mandated "risk pools", sometimes funded by mandatory industry "contributions", with liability caps for individual companies.
However, it's important to note that individuals, not just corporations, rarely are able to fulfill their obligations to compensate victims for "worst case damages" arising from their actions. Therefore, one should be very careful before complaining about "corporate responsibility" in such cases.
Consider that a "really bad case" auto accident can result in damages in the range of (present value) tens of millions of USD. Consider, for example, an accident where the "not at fault" car had two young and highly skilled and compensated parents in the front seat and seventeen year old twins (both very smart and with bright futures having just completed their second year at Harvard with stellar performance) in the back seat. In the accident, all four individuals suffer substantial permanent but non-fatal brain damage and are all rendered quadriplegic. All four require 7x24 care for the rest of their lives and lost the ability to ever perform work for meaningful compensation. The damages include:
So, I think fairly conservatively, we have $25M+$50M+$20M = $95M in damages.
/.er's, ask yourselves: Do you have assets or insurance to compensate for the damages you caused in such a case? I would wager that over 95% of those reading this have to answer "NO".
/.ers who even think of such things (whi
Knowing that it's conceivable that anyone could cause such an accident (even a pedestrian inadvertently crossing a street against a red light could cause the driver of our unfortunate family's car to swerve and lose control resulting in this accident -- so even people who only walk to mass transit could be liable for this case), fellow
Indeed, I'll bet the vast majority of
Well, at least they would try if given the opportunity!
is perhaps too strong a statement given likely advances in biology et al. Is a species extinct if sufficient material (such as egg+sperm or maybe just DNA) exists to recreate the species with current technology? What about with reasonably anticipated future technology?
Not being sufficiently familiar with A Levels, I'll take this as fact.
It seems that C, having at least some notion of pointers, would be valuable in helping tie together the lower levels to the higher levels. True, assembly might be better, but it's used so little now that it's rarely of much specific later use (as contrasted to so much FOSS being in C that one is likely to run into C eventually). For example, if one knows C, one might be able to better grok why the Linux kernel isn't being rewritten in VB.Net 2008.
But, I suppose there is only so much time to teach stuff between text messages.
Ah, yes, of course these experts in geology, oil wells, and nuclear explosions should have a lot of useful input (almost as much as /.ers).
But the problem in the Gulf is not the fire (there is no fire except the controlled burns of the slick that they are attempting from time to time), it's the "flowing" oil.
On land, the explosives put out the fire, the oil flow remains and workers then cap that flow mecanically once the fire is out. The explosives are not used to cap the well.
Ahh..., but is the accounting of time spent strong enough to protect the programmer?
/. idiots).
Work done on your computer on company (or University) time is typically the property of the company (or, in this case, the University) - utilization of any company (or University) resource is typically enough to make it a work product of one's employment. The question isn't if all resources used were company (or University) resources.
If there is not strict time accounting (clock in/out and what you spent your time on while "at work") of both your professional time and your personal time and the code you're working on is generally the same as the code you work on at work, you're going to need a whole lot of high priced legal help to defend your position (and if you had the resources and inclination to pick a fight in this domain, you simply would have asked your attorney this question instead of asking us
Generally, if you care, quit your position, wipe your hard drives, and in the future carefully partition your "volunteer" work and your paid work.
Yep, it sucks -- but I've seen people spend a whole lot of money on lawyers for naught on cases like this. Or, just play the roulette wheel and figure that this code really isn't that important and no one is going to fight you over anything short of outright code theft.
It's true that Google will let you go wherever you want...
Unfortunately they will track everywhere you go and add that info into their galactic databases. Then they will use that info to help sell you crap. But it will be convenient, you won't even have to bother to actually order stuff - Google will just know what you want and order it for you (conveniently debiting your bank account and adding a nominal Google Product Procurement Fee to the charge). Google will even know when you will be home to receive it (since, of course, you SHALL use Google calendar) when it's delivered by Google Parcel Service.
The climate on Earth will change to the point that today's humans can't live on it without their population slowly declining - eventually to zero. Humans evolve poorly for a variety of reasons:
About the only hope for long term (many millions of years) survival of humans seems to be to continually populate planets/chunks of matter elsewhere in the universe that happen to, in that particular era, have an environment well suited for human existence. However, this seems quite unlikely to happen -- at this point, there are no planets known to humans which even come close to meeting this requirement so humans would have to travel and explore way beyond where they've even sent man made objects so far and, I suspect, only a tiny percentage of environments qualify and humans are unlikely to find one before they are focusing all resources on short term survival rather the space exploration.
That said, yes, humans can probably accelerate or delay the demise of their species (maybe by tens or hundreds of thousands of years?) and maybe this is worth something to some folks -- although caring one way or the other seems rather illogical to me. No matter what, the end game is going to be painful for those who have to play it -- either way, the last generations of humans will likely live horrible (by current standards) lives and die horrible (by current standards) deaths as they desperately fight a losing battle for survival. Not pretty, but inevitable IMHO.
Well at least we agree that the world would be a much better place if developers would spend more time thinking and less time coding.
Although there are certainly times when brainstorming et al is very helpful, good developers know when that's needed and seek it out -- there's no need to push it on them. I'm actually more likely to seek collaboration in a office environment. First, I only need to disturb one person. Second, I usually want to collaborate with a particular person or two for a particular problem -- I really don't want the input from people who know little about the problem or subsystem as it just distracts the conversation and extends its duration.
In my experience, "team designs" addressing complex problems usually seem to work on the surface but often have serious and sometimes fatal flaws deep down (esp. in the areas of concurrency and fault recovery). Team design leaves too little time to linger on one person's passing concern - something that doesn't quite pass the sniff test - the team moves on.
For simple things, if team design is needed, probably the problem is that most members of the team should find another career more suited to their interests/skills. None of this is to say that collaboration is not appropriate, but it's a small percentage of the time and the environment should be optimized for what is appropriate the majority of the time. This is especially the case if, as in the bullpen vs. cubicle vs. office discussion, structured collaboration is not interfered with in any way by selecting the same environment (offices) that optimizes that which one spends most of their time on.
This seems like a religious argument on both sides. I've experienced "team design" type environments and, invariably, I can tear holes in the designs much more easily than in designs that were the product of one, or occasionally two, skilled developers. Perhaps somewhere there is an alternate universe where this is not true - I'd love to be a fly on the wall to see that to understand why it's not true (different problem domain? different developer experience level? different accountability? different priorities on quality vs. feature vs. schedule?)
Absolutely. If the quality of the output isn't important enough to provide developers with an environment with minimal distractions, it's probably not worth paying US wages for and likely should be off-shored.
Umm... that "sales and all the other riffraff" probably actually have a clue about how customers are using your product and/or why prospects are/are not buying it and/or why it is/is not meeting their needs. Yep, you need to keep the price of entry a little high, but I'd much rather talk to a good SE, support or sales person about the product than be distracted by some developer bragging about his clever (NOT) solution for problem X or pontificating about some non-work related topic (I expect some non-work related chatter, it's just that two people chattering for a few minutes in one of their private offices gives them both a break but if they do it in a room of ten people, it distracts eight other people)
How do you get your reptile brain to turn down the fight or flight response?
You don't - you just invoke the fight response and shoot the people behind you - problem solved.
Although, maybe some SEC employees should have worked in that configuration, it might have discouraged some of their less productive web surfing if they feared being surprised by the boss!
It's so sad that our industry has gotten to this point where the discussion is not over "offices vs. cubicles" but over "bullpen layout A vs. bullpen layout B". Most of development work is actually solitary and productivity and quality (in the terms of correctness) benefits from the ability to concentrate, which in turn is much easier when there are fewer distractions.
Much (probably most) of my career I've had a private office and, compared to those times I was in a cubicle bay, I got more work and better quality work done in the office environment. Although, that may be not entirely due to the office vs. cubicle difference as the companies that gave offices to developers were also understood more about what developers needed to be productive - less PHB MBA crap and heavy handed IT rules etc.
The need for continuous collaboration suggests that interfaces are not well documented or perhaps even well defined and/or the system/feature architecture is not well thought out. It also suggests that too much information is "in people's heads" -- and hence the company will incur unnecessary expense if one or more people get hit (very hard) by a bus (or, I suppose, a buss) or leaves the company. This isn't to say some collaboration isn't necessary (certainly for brainstorming about design issues and for the occasional "WTF is this code trying to do and why?") - indeed, if no ad hoc collaboration is needed, I suspect that too much effort has been expended on design and documentation. There's a happy medium.
So, the answer to the original question is "Yes, every workspace needs to be surrounded by floor to ceiling walls except for a door that closes! I once worked at a company which was locating to new facilities which were being built out for us. The facilities folks decided that cubicles for all was the answer. The developers pretty much stood up and said "over our dead bodies" and in the end all developers had private offices except for very junior ones (this actually made some sense because the less experienced one is, I think the more likely one is to learn from "random chatter" vs. be distracted by it - the first discussion you overhear about cache coherency models is much more valuable than the 30th one). Funny thing was, I noticed that even the facilities folks mostly had their own offices in the end - even though they were the ones arguing that wasn't necessary and citing studies that cubicles were more productive!
Anything past that is useless to humans (just magnify the section of the picture you are looking at if you don't want to see the entire picture at once.)
I don't think this is always the case for working at a computer monitor.
When doing development, esp. debugging systems with many threads/processes, I sometimes have a lot of windows open (many code modules, variable watch windows, stack traces for many threads, etc.) and never really "look at the entire screen". My focus flits around the screen at the thing of interest at that instant. My eyes are moving and my head moves slightly (left/right, up/down and, probably to the dismay of ergonomics police, forward/backward a bit) throughout this - no mouse movement, no scroll/zoom keys etc - these are all way too slow. When I'm focusing on a small piece of the screen, I want a lot of pixels there so I can read the (now tiny) fonts w/o strain. There is some limit to this of course.
The limit of comfortable head/eye movement limits the size of the monitor - and that may be somewhere around 30", but the number of useful pixels on that screen are only limited by how small a piece of that screen I can focus on by moving my head/eyes.
Well, he could have just released the passwords - his arrogant refusal to do so coupled with the stupidity of the City in not making sure that no IT person had this much power is what landed him in jail. He could have avoided that outcome at almost no cost by releasing the passwords.
I would argue that the passwords are the property of the city and hence he stole them. Just as if he had taken the only copy of the payroll program and refused to return it. All employee manuals, agreements, and NDAs I've seen in recent years stipulate that all copies of confidential information (which, passwords would seem to be) must be returned to the employer. Passwords really seem no different that a product marketing roadmap in this respect.
This, by the way, is one reason why all that "sealed password envelope" crap is nonsense. At a minimum, these envelopes need to be opened and the passwords tested randomly from time to time - and if they are not right, the IT person responsible for keeping the envelopes up to date should get fired - no questions asked.