I don't think the point of planning poker is to let engineers set their own deadlines. Our deadlines are the end of each 2-week iteration, but the process should still work with other artificial deadlines imposed by someone outside of engineering. The point of planning poker is to figure out how much development can be accomplished by the deadline. If the result of the process yields an incomplete product, it's up to management to adjust the deadlines to accommodate more development.
That's what I thought too, but she sees it as engineers setting their own deadlines and thus giving themselves too long to do something. She seems to think that unless there's constant pressure on her engineers, that they'll skive.
One particular example is her perception of enjoyment of work. She thinks that if an engineer is enjoying what they're doing, they'll spend too long on it. One of the senior guys (who used to be a manager himself) is constantly getting hassled about this. He really enjoys doing low-level multi-threaded real-time stuff and can churn out thousands of lines of working code in a few days, but she thinks he could do it faster if only he weren't "enjoying" it.
Deadlines appear out of nowhere. She doesn't set them up front. If she thinks something's taking too long (maybe because more investigation was required or the existing code was very badly written and needs refactoring just to understand) an artificial deadline of "tomorrow afternoon" is often pulled out of her hat.
The good news for you is that you might be able to help your PHB grok this while making her feel empowered rather than feeling like she's losing control. You just have to remind her that the process allows her or her superiors to set the deadlines and allows her to accurately figure out how much development can be done in that time period so that scheduling can be accurate and the expectations of her superiors can be set and met. Nowhere in the process is she losing control. It's just important for her to understand that asking engineers, even those with decades of experience, for time estimates will yield incorrect results.
She won't accept this. She can't understand that time estimates are approximate. She thinks that after a few scrum iterations, time estimates should become consistently perfect. She want to be able to predict down to the quarter hour how long every task will take every time.
Thanks for replying to my rant, anyway. It made me feel better.
Luckily, one of our senior developers holds her hand a lot of the time now, so things are improving. She does listen to him. He's started having design review meetings for us and has managed to get her to split some task up into smaller chunks. We'll see how it goes.
We do planning poker too, but we made the cards ourselves:-)
My PHB is not a software developer and she doesn't really understand software development despite having managed a software team for several years. Bringing in Lean and Agile was her idea, though, and I quite like it.
She has a big problem with accepting time estimates, though, and we have very disparate ability levels in our team. I'm roughly in the middle, but we have two guys in their 50s with decades of experience who can do large amounts of very complex work accurately and quickly, and one newbie who used to be a mechanical engineer until a year ago.
The first problem our PHB has is in understanding that software is hard to write and that someone with 20+ extra years of experience will do more more quickly than someone with only 5 years, or even 6 months. When we estimate times, they usually come out heavily biased towards what the most experienced people guess. This is a natural consequence of the feedback inherent in the planning poker process.
The second problem is that the numbers in planning poker are supposed to be relative estimates, not absolute times. Our PHB makes 1 == 1 day == 7.5 hours (8 hours sometimes, even although we only do 7.5 hour days).
The third mistake she makes is having the estimates as hard deadlines. Despite the fact that she knows estimates have to change as investigations progress, and despite the fact that she publically claims to accept that estimates can go up, she gets very angry if a task takes longer than the estimate, even if there were barriers such as test systems not being available.
The fourth mistake she makes is not having tasks accurately specified. So when we go to estimate times we get a problem statement such as "the foo widget on the bar product didn't work one Tuesday afternoon." Often it turns out to be a can of worms to investigate, first of all, which can be a week's work in itself. Then there is the design and then the coding and testing.
The fifth mistake that she makes is not breaking down tasks into their components, i.e. investigate, design, implement, regression test.
You're only supposed to work on stuff "on the backlog" and I have been balled at and accused of being a feckless, ignorant time/money-wasting useless item for helping stuck colleagues (i.e. being part of a team) and doing code reviews (a very important part of the process which the senior developers are very hot on). "Is that what the customer's paying for?"
She's got it into her tiny little pointy-haired head that every task I do keeps getting longer and longer. This is patently nonsense. The last task I did was estimated at 23 hours and I did it in 10.5. Her little head all but exploded.
I have to give her daily status reports detailing where I spent my time to the nearest 15 minutes per task. I explain exactly what I'm doing and why the customer is paying for it. My senior colleagues (who are constantly at war with her about these things) support me, so I am lucky.
The other day she has asked me for more information. She wants a spreadsheet (in addition to daily status reports) with estimated times vs. actual times for my tasks.
She seems to think that we are taking the Mickey with the estimates, especially since I finished the last task so quickly compared with the others. She is utterly obsessed with these time estimates.
The reason that my last task was so quick was because it was a modification to a system that I'd designed and written. The estimate was a kind of average for other team members (who would have a learning curve)...
So I'm being micromanaged and watched like a hawk. It's very tiresome and patronising. I'm a busy, diligent person, trying to do my best. I know I'm doing the right thing, unfortunately she's mad and there's a huge RIF coming up. I know she's pretty hard on some of my other colleagues too, but she's being even more patronising and condescending to them...
We had Scrum trainers come to site and she argued and argued with them. She seems to be paranoid that letting engineers set their own deadlines is a skiver's charter.
Today we have theories that challenge some foundations. For example, this paper [metaresearch.org] points out that if the speed of gravity were to be limited to 1c then our Solar system (just as all other) would spiral into the Sun pretty fast. It turns out, orbital mechanics calculations use infinite speed of gravity, and Pluto always "knows" exactly and instantly where the Sun is - not where it used to be hours ago. This is a very interesting paper.
It's interesting if you like a good laugh.
Merely getting from there to here would consume so much energy
An ideal round trip in a potential field consumes zero energy. A pendulum can swing for a very long time, limited only by losses in the thread. Our rockets consume a lot of energy just because they are so incredibly inefficient.
Right, right, wrong.
You do mention the continuous streaming of knowledge, and that might work, but it depends on willingness to spend considerable energy on an exchange that you will gain little out of (if you are an advanced civ.) Earth has nothing to say, except basics of our life.
Broadcasting an analogue radio signal is simple and relatively cheap.
We have absolutely no evidence that FTL travel or communication is possible. There is no evidence in nature itself and there is no evidence of alien civillisations having developed FTL travel. Our theories of Physics do not predict the possibility of FTL travel.
Therefore, we are highly unlikely to be targeted by some evil alien race for target practice, food or Lebensraum.
Merely getting from there to here would consume so much energy that there would be no point in plundering any physical resources from Earth. It would be much cheaper simply to produce them at home.
As for the futility of communicating with aliens slowly over vast distances, I think you are being unreasonably pessimistic. The mere discovery of the existence of intelligent alien life would be of vast benefit to our science and philosophy. We could communicate with aliens slowly over many decades. Although a two-way conversation would be difficult, we could constantly stream information about our science and culture to them, and them to us. Any fool can see that both sides would stand to benefit immensely.
You presuppose that an advanced civilisation would not deliberately broadcast radio signals for others to detect?
As another poster has mentioned, a very advanced civilisation would realise that radio technology is cheap and simple so new technological civilisations are very likely to discover it early on (as did our own).
Not only would they therefore be trying to detect radio broadcasts from space, but I'm sure they might do some deliberate broadcasting of their own towards likely stars, in the hope ob being detected.
Since Slackware 13.0 came out I've been seeding the CD and DVD images (32- and 64-bit). I'm also seeding a NetBSD iso and OpenOffice.org.
In all those months, I've not uploaded a single byte of OOo, but Slackware is constantly hammering away.
I've never torrented anything illegally.
Someone needs to start a campaign to preserve the rights of legitimate bittorrent users, so that the message is put across that it is a very useful tool and not just an aid to law-breaking.
Idealistic, young, shrewd people know that working 80+ hours a week for a megacorp is a hiding to nothing since by definition, megacorps are marketing-driven and can't produce anything truly interesting and exciting.
If you are really clever, you will work for a reasonable company 35-45 hours a week and pursue your dreams in your own time on your own terms.
Why sacrifice yourself to a bunch of ignorant, blinkered PHBs?
Statistics are very important when testing a system. You really need to know (especially if the bug was intermittent) what the probability is of NOT seeing the error per test run iteration.
It's not good enough to say, "It happens one in ten times, so if I run it 11 times I will definitely see the bug if it's still there."
The probability of not seeing the bug per test is 9 in 10 i.e. 90% or 0.9. These probabilities multiply, so if you perform the experiment (do a test run) 10 times, the probability of NOT seeing the bug (with the unfixed code) is 0.9^10 i.e. 0.349 or about 35%.
Would you be confident with that?
If you wanted a 1% probability (0.01) of not seeing the bug (in the unfixed code) how many runs would it take? Well, do your logs.
0.01 = 0.9^x
x=43.7
So you would need to run the test 44 times to have a 99% confidence that you'd fixed the bug.
I mean, I don't have to have a license to own a handgun, nor do I have to register one with my state [nraila.org] or federal govt....why should I need a license to just access the internet?
There hasn't been much of the "soap" part yet. Mainstream media is more interested in who won the dancing and who's "loving" who to bother with trifling matters such as this.
Not enough people care because not enough people know what's going on, and they are not likely to find out on their own. People are lazy and stupid.
As for the "ballot" part, most people can't even be bothered to do that either.
We don't care. We are apathetic. By the way, who is Katie Price having sexual relations with this week?
This was how I remember hearing it as well. In addition, the 487SX was a 486 that couldn't guarantee the main processor so the main processor was switched off. I believe i486 boards used to have a co-processor slot that could take either an 80387 or an i487SX.
Not quite.
The 487SX was a full 486DX but sold as a coprocessor (a little cheaper than a full 80486DX). You could (and people did) buy a 486 motherboard and an 80487SX only instead of the more expensive 80486DX.
The 80487SX was a triumph of intel marketing over reality.
The 80486 had a build in 8k (IIRC) L1 cache as well as FPU. The 80386 had no cache. The 80486 was optimised such that many of the common instructions ran faster that the 80386 (and similarly for the 80387). Back in the day, with unoptimised software (i.e. compiled for 286) the 486 was about twice as fast as the 386 at the same clock speed. Compared to a 386 without a 387 copro (which was identical to one of the 287s incidentally), a full-blown 486DX was an order of magnitude more powerful. Doom anyone?
So, instead of making a poor explosive device, would an instrument designed to puncture the fuselage be more effective? For example, a strong spring and a tapered metal bolt might be enough.
The whole British Magnox series is very interesting in terms of architecture and technical design.
They ran on natural uranium metal (no enrichment required), were graphite moderated and used carbon dioxide and the primary coolant. Most were run under manual control. In fact, a lot of the plant was manually operated too.
All but the very first generation (Calder Hall and Chapel Cross) could be, and were, refueled on-load. The refueling programmes (implemented monthly) were usually worked out by hand. Over four years, I did many a refueling programme.
At Bradwell, the reactor gas inlet temperature was about 180C and 360ish at the outlet. The maximum electrical output was 246MW (on a very cold day when the river Blackwater was cold) and each of the two reactors did about 480MW thermal.
Each site had two reactors, apart from Calder Hall and Chapel Cross which had four.
Off the top of my head, the sites were Bradwell, Sizewell A, Dungeness A, Hinkeley Point A, Odlbury, Berkeley and Hunterston A, Calder Hall, Chapel Cross and Tawsfynydd (the only one build on a lake).
Odlbury (the first concrete pressure-vessel nuclear power plant and the first ever with once-through boilers) has a verydistinctivebuilding. I think it might have been used in a 1970s episode of Dr. Who.
My PHB is just that - she started out in Admin. and worked her way up to managing a team of software developers. She hasn't a clue about software development. Not quite, "I think that mauve has the most RAM" but not far off.
A few weeks ago she put a great deal of pressure (stupid deadline) of one of our senior developers. I got diverted from my task do doing a code review and running my new automated regression test suite to help him meet his deadline. Our other senior developer dropped his task and helped out with some testing too. (I'm not senior, just one of the regular guys).
Our PHB left at about 19:00 as usual and two of us we left. The code review took 4 to 5 hours. As usual the PHB had no idea that this was 2500 lines of code touching many modules in C and C++. This is embedded real time stuff that runs on two platforms.
We actually got finished at 19:30. The poor guy was under such pressure to get his stuff delivered (i.e. to cut all possible corners) that he broke the unit tests in the nightly build.
A week later, we were pleasantly surprised when we all received an official letter from our PHB cc'd to more senior PHBs about what a great job we'd done! They all emailed us personally to thank us.
Anyway, the poor guy got humiliated by the PHB in front of everyone for breaking the build and a couple of weeks later I got the telling off of my life from our dear PHB for wasting time! "Your time is not your own! Your time is not your own while you're here! There are people who pay us..." This lasted half an our!
I'm not the one who spends 3 hours a day surfing the internet.
My crime? Doing unit tests, refactoring my code and doing code reviews. Oh, and helping people for 10 minutes when they are stuck.
That assumes you can actually be bothered to type those commands. Many "professional software engineers" are out there who can't even bring themselves to do that much work in a day...
They are paid more than me, and they expect me to help...
You miss the point. Every time a new version of Windows is due, Microsoft starts talking down the old version. Windows 7 is currently the best thing since sliced bread. How long will it be until it isn't good enough for us any more and we should be anxious to buy Windows 8?
And to answer your slight - yes, for something like a manned Mars mission with 128:129 odds of surviving I'd be first in line if I could. I probably wouldn't because thousands of others would be trying to get the #1 spot as well.
Slashdot Mirror
I don't think the point of planning poker is to let engineers set their own deadlines. Our deadlines are the end of each 2-week iteration, but the process should still work with other artificial deadlines imposed by someone outside of engineering. The point of planning poker is to figure out how much development can be accomplished by the deadline. If the result of the process yields an incomplete product, it's up to management to adjust the deadlines to accommodate more development.
That's what I thought too, but she sees it as engineers setting their own deadlines and thus giving themselves too long to do something. She seems to think that unless there's constant pressure on her engineers, that they'll skive.
One particular example is her perception of enjoyment of work. She thinks that if an engineer is enjoying what they're doing, they'll spend too long on it. One of the senior guys (who used to be a manager himself) is constantly getting hassled about this. He really enjoys doing low-level multi-threaded real-time stuff and can churn out thousands of lines of working code in a few days, but she thinks he could do it faster if only he weren't "enjoying" it.
Deadlines appear out of nowhere. She doesn't set them up front. If she thinks something's taking too long (maybe because more investigation was required or the existing code was very badly written and needs refactoring just to understand) an artificial deadline of "tomorrow afternoon" is often pulled out of her hat.
The good news for you is that you might be able to help your PHB grok this while making her feel empowered rather than feeling like she's losing control. You just have to remind her that the process allows her or her superiors to set the deadlines and allows her to accurately figure out how much development can be done in that time period so that scheduling can be accurate and the expectations of her superiors can be set and met. Nowhere in the process is she losing control. It's just important for her to understand that asking engineers, even those with decades of experience, for time estimates will yield incorrect results.
She won't accept this. She can't understand that time estimates are approximate. She thinks that after a few scrum iterations, time estimates should become consistently perfect. She want to be able to predict down to the quarter hour how long every task will take every time.
Thanks for replying to my rant, anyway. It made me feel better.
Luckily, one of our senior developers holds her hand a lot of the time now, so things are improving. She does listen to him. He's started having design review meetings for us and has managed to get her to split some task up into smaller chunks. We'll see how it goes.
We do planning poker too, but we made the cards ourselves :-)
My PHB is not a software developer and she doesn't really understand software development despite having managed a software team for several years. Bringing in Lean and Agile was her idea, though, and I quite like it.
She has a big problem with accepting time estimates, though, and we have very disparate ability levels in our team. I'm roughly in the middle, but we have two guys in their 50s with decades of experience who can do large amounts of very complex work accurately and quickly, and one newbie who used to be a mechanical engineer until a year ago.
The first problem our PHB has is in understanding that software is hard to write and that someone with 20+ extra years of experience will do more more quickly than someone with only 5 years, or even 6 months. When we estimate times, they usually come out heavily biased towards what the most experienced people guess. This is a natural consequence of the feedback inherent in the planning poker process.
The second problem is that the numbers in planning poker are supposed to be relative estimates, not absolute times. Our PHB makes 1 == 1 day == 7.5 hours (8 hours sometimes, even although we only do 7.5 hour days).
The third mistake she makes is having the estimates as hard deadlines. Despite the fact that she knows estimates have to change as investigations progress, and despite the fact that she publically claims to accept that estimates can go up, she gets very angry if a task takes longer than the estimate, even if there were barriers such as test systems not being available.
The fourth mistake she makes is not having tasks accurately specified. So when we go to estimate times we get a problem statement such as "the foo widget on the bar product didn't work one Tuesday afternoon." Often it turns out to be a can of worms to investigate, first of all, which can be a week's work in itself. Then there is the design and then the coding and testing.
The fifth mistake that she makes is not breaking down tasks into their components, i.e. investigate, design, implement, regression test.
You're only supposed to work on stuff "on the backlog" and I have been balled at and accused of being a feckless, ignorant time/money-wasting useless item for helping stuck colleagues (i.e. being part of a team) and doing code reviews (a very important part of the process which the senior developers are very hot on). "Is that what the customer's paying for?"
She's got it into her tiny little pointy-haired head that every task I do keeps getting longer and longer. This is patently nonsense. The last task I did was estimated at 23 hours and I did it in 10.5. Her little head all but exploded.
I have to give her daily status reports detailing where I spent my time to the nearest 15 minutes per task. I explain exactly what I'm doing and why the customer is paying for it. My senior colleagues (who are constantly at war with her about these things) support me, so I am lucky.
The other day she has asked me for more information. She wants a spreadsheet (in addition to daily status reports) with estimated times vs. actual times for my tasks.
She seems to think that we are taking the Mickey with the estimates, especially since I finished the last task so quickly compared with the others. She is utterly obsessed with these time estimates.
The reason that my last task was so quick was because it was a modification to a system that I'd designed and written. The estimate was a kind of average for other team members (who would have a learning curve)...
So I'm being micromanaged and watched like a hawk. It's very tiresome and patronising. I'm a busy, diligent person, trying to do my best. I know I'm doing the right thing, unfortunately she's mad and there's a huge RIF coming up. I know she's pretty hard on some of my other colleagues too, but she's being even more patronising and condescending to them...
We had Scrum trainers come to site and she argued and argued with them. She seems to be paranoid that letting engineers set their own deadlines is a skiver's charter.
Today we have theories that challenge some foundations. For example, this paper [metaresearch.org] points out that if the speed of gravity were to be limited to 1c then our Solar system (just as all other) would spiral into the Sun pretty fast. It turns out, orbital mechanics calculations use infinite speed of gravity, and Pluto always "knows" exactly and instantly where the Sun is - not where it used to be hours ago. This is a very interesting paper.
It's interesting if you like a good laugh.
Merely getting from there to here would consume so much energy
An ideal round trip in a potential field consumes zero energy. A pendulum can swing for a very long time, limited only by losses in the thread. Our rockets consume a lot of energy just because they are so incredibly inefficient.
Right, right, wrong.
You do mention the continuous streaming of knowledge, and that might work, but it depends on willingness to spend considerable energy on an exchange that you will gain little out of (if you are an advanced civ.) Earth has nothing to say, except basics of our life.
Broadcasting an analogue radio signal is simple and relatively cheap.
We have absolutely no evidence that FTL travel or communication is possible. There is no evidence in nature itself and there is no evidence of alien civillisations having developed FTL travel. Our theories of Physics do not predict the possibility of FTL travel.
Therefore, we are highly unlikely to be targeted by some evil alien race for target practice, food or Lebensraum.
Merely getting from there to here would consume so much energy that there would be no point in plundering any physical resources from Earth. It would be much cheaper simply to produce them at home.
As for the futility of communicating with aliens slowly over vast distances, I think you are being unreasonably pessimistic. The mere discovery of the existence of intelligent alien life would be of vast benefit to our science and philosophy. We could communicate with aliens slowly over many decades. Although a two-way conversation would be difficult, we could constantly stream information about our science and culture to them, and them to us. Any fool can see that both sides would stand to benefit immensely.
Xenophobia is misplaced in this situation.
You presuppose that an advanced civilisation would not deliberately broadcast radio signals for others to detect?
As another poster has mentioned, a very advanced civilisation would realise that radio technology is cheap and simple so new technological civilisations are very likely to discover it early on (as did our own).
Not only would they therefore be trying to detect radio broadcasts from space, but I'm sure they might do some deliberate broadcasting of their own towards likely stars, in the hope ob being detected.
Since Slackware 13.0 came out I've been seeding the CD and DVD images (32- and 64-bit). I'm also seeding a NetBSD iso and OpenOffice.org.
In all those months, I've not uploaded a single byte of OOo, but Slackware is constantly hammering away.
I've never torrented anything illegally.
Someone needs to start a campaign to preserve the rights of legitimate bittorrent users, so that the message is put across that it is a very useful tool and not just an aid to law-breaking.
The UK has a law where citizens (usually brown ones with beards) can be detained for a month and a half without charge, usually in HMP Belmarsh.
Scotty grimaced, stole a quick gulp of whiskey from his flask
That would be whisky.
It's the only way to write real code.
Idealistic, young, shrewd people know that working 80+ hours a week for a megacorp is a hiding to nothing since by definition, megacorps are marketing-driven and can't produce anything truly interesting and exciting.
If you are really clever, you will work for a reasonable company 35-45 hours a week and pursue your dreams in your own time on your own terms.
Why sacrifice yourself to a bunch of ignorant, blinkered PHBs?
Statistics are very important when testing a system. You really need to know (especially if the bug was intermittent) what the probability is of NOT seeing the error per test run iteration.
It's not good enough to say, "It happens one in ten times, so if I run it 11 times I will definitely see the bug if it's still there."
The probability of not seeing the bug per test is 9 in 10 i.e. 90% or 0.9. These probabilities multiply, so if you perform the experiment (do a test run) 10 times, the probability of NOT seeing the bug (with the unfixed code) is 0.9^10 i.e. 0.349 or about 35%.
Would you be confident with that?
If you wanted a 1% probability (0.01) of not seeing the bug (in the unfixed code) how many runs would it take? Well, do your logs.
0.01 = 0.9^x
x=43.7
So you would need to run the test 44 times to have a 99% confidence that you'd fixed the bug.
I mean, I don't have to have a license to own a handgun, nor do I have to register one with my state [nraila.org] or federal govt....why should I need a license to just access the internet?
Because the pen is mightier than the sword.
A worthy parable isThe Passion of St Tibulus.
Down with that sort of thing.
There hasn't been much of the "soap" part yet. Mainstream media is more interested in who won the dancing and who's "loving" who to bother with trifling matters such as this.
Not enough people care because not enough people know what's going on, and they are not likely to find out on their own. People are lazy and stupid.
As for the "ballot" part, most people can't even be bothered to do that either.
We don't care. We are apathetic. By the way, who is Katie Price having sexual relations with this week?
If you want to stop buying china products them you need to stop buying any Laptop sold in the USA.
American laptops are made of clay?
This was how I remember hearing it as well. In addition, the 487SX was a 486 that couldn't guarantee the main processor so the main processor was switched off. I believe i486 boards used to have a co-processor slot that could take either an 80387 or an i487SX.
Not quite.
The 487SX was a full 486DX but sold as a coprocessor (a little cheaper than a full 80486DX). You could (and people did) buy a 486 motherboard and an 80487SX only instead of the more expensive 80486DX.
The 80487SX was a triumph of intel marketing over reality.
The 80486 had a build in 8k (IIRC) L1 cache as well as FPU. The 80386 had no cache. The 80486 was optimised such that many of the common instructions ran faster that the 80386 (and similarly for the 80387). Back in the day, with unoptimised software (i.e. compiled for 286) the 486 was about twice as fast as the 386 at the same clock speed. Compared to a 386 without a 387 copro (which was identical to one of the 287s incidentally), a full-blown 486DX was an order of magnitude more powerful. Doom anyone?
So, instead of making a poor explosive device, would an instrument designed to puncture the fuselage be more effective? For example, a strong spring and a tapered metal bolt might be enough.
The whole British Magnox series is very interesting in terms of architecture and technical design.
They ran on natural uranium metal (no enrichment required), were graphite moderated and used carbon dioxide and the primary coolant. Most were run under manual control. In fact, a lot of the plant was manually operated too.
All but the very first generation (Calder Hall and Chapel Cross) could be, and were, refueled on-load. The refueling programmes (implemented monthly) were usually worked out by hand. Over four years, I did many a refueling programme.
At Bradwell, the reactor gas inlet temperature was about 180C and 360ish at the outlet. The maximum electrical output was 246MW (on a very cold day when the river Blackwater was cold) and each of the two reactors did about 480MW thermal.
Each site had two reactors, apart from Calder Hall and Chapel Cross which had four.
Off the top of my head, the sites were Bradwell, Sizewell A, Dungeness A, Hinkeley Point A, Odlbury, Berkeley and Hunterston A, Calder Hall, Chapel Cross and Tawsfynydd (the only one build on a lake).
Odlbury (the first concrete pressure-vessel nuclear power plant and the first ever with once-through boilers) has a very distinctive building. I think it might have been used in a 1970s episode of Dr. Who.
Very good advice.
My PHB is just that - she started out in Admin. and worked her way up to managing a team of software developers. She hasn't a clue about software development. Not quite, "I think that mauve has the most RAM" but not far off.
A few weeks ago she put a great deal of pressure (stupid deadline) of one of our senior developers. I got diverted from my task do doing a code review and running my new automated regression test suite to help him meet his deadline. Our other senior developer dropped his task and helped out with some testing too. (I'm not senior, just one of the regular guys).
Our PHB left at about 19:00 as usual and two of us we left. The code review took 4 to 5 hours. As usual the PHB had no idea that this was 2500 lines of code touching many modules in C and C++. This is embedded real time stuff that runs on two platforms.
We actually got finished at 19:30. The poor guy was under such pressure to get his stuff delivered (i.e. to cut all possible corners) that he broke the unit tests in the nightly build.
A week later, we were pleasantly surprised when we all received an official letter from our PHB cc'd to more senior PHBs about what a great job we'd done! They all emailed us personally to thank us.
Anyway, the poor guy got humiliated by the PHB in front of everyone for breaking the build and a couple of weeks later I got the telling off of my life from our dear PHB for wasting time! "Your time is not your own! Your time is not your own while you're here! There are people who pay us..." This lasted half an our!
I'm not the one who spends 3 hours a day surfing the internet.
My crime? Doing unit tests, refactoring my code and doing code reviews. Oh, and helping people for 10 minutes when they are stuck.
Considering their new home has five earth masses at the very least, they might as well get used to 5.0G. Ouch.
Not if it has a radius of 14300km (8950mi). Then it would be 1g.
That assumes you can actually be bothered to type those commands. Many "professional software engineers" are out there who can't even bring themselves to do that much work in a day...
They are paid more than me, and they expect me to help...
You miss the point. Every time a new version of Windows is due, Microsoft starts talking down the old version. Windows 7 is currently the best thing since sliced bread. How long will it be until it isn't good enough for us any more and we should be anxious to buy Windows 8?
And to answer your slight - yes, for something like a manned Mars mission with 128:129 odds of surviving I'd be first in line if I could. I probably wouldn't because thousands of others would be trying to get the #1 spot as well.
You can't argue with that.
Lose an Arse launch and ...
Is that anything like a Bombay bed-bath?