Oh I WISH that where possible.. Problem here is that you are going to have to prove two things.. 1. that the sick child who couldn't be vaccinated really couldn't (easy) and 2. That they only could have got the sickness from THAT specific child (hard). Then you are going to have to come up with a way to measure actual damages....
First, this opinion was brought to us by ONE (that's 1) published study that found a POSSIBLE but not confirmed link between the compounds with mercury that where used in *some* vaccines at the time. Since then three things have happened.
1. The published study has been found to be invalid due to errors in their facts and methods and has been recalled by the publisher and the authors have been discredited for their shoddy work.
2. Multiple studies have been done since that verifies that the original findings where incorrect and that there is in fact no link to vaccines that used mercury compounds and autism.
3. ALL modern vaccines have stopped using the compounds in called into question by the now discredited and disproven study decades ago.
There is NO LINK to autism from vaccines....They don't use the chemicals in question anymore, and even if they did the link was disproven.
Not to mention that we now KNOW what causes autism and it's NOT mercury exposure as a child.
So go grab your kids and take them to the pediatrician and get them vaccinated unless the doctor has a reason they shouldn't be.
What part of "rule of thumb" do you not get? There are times when it's done, but it should be avoided.
The reason is easy to get if you think about it. Functions start at the top and should end at the bottom... Returns in between are (generally) "bad form" because it's easy to miss them when looking at the source code.
BTW, this applies double when you are actually returning a value to the caller... Still there are exceptions, but in general, one return, at the bottom, is best.
"GOTO" existed before subroutines and functions were added, and it was back in the days of line numbers. This was the point where the main menu part of a program had to jump over to the appropriate part of the program, now we just call the appropriate routine.
GOTO predates just about everything but the CPU. It's a mirror of the "Jump to:" machine instruction that is common to EVERY Processor I've ever seen.
Man, you just blew another coding rule of thumb....
There should be only ONE return statement in a function, especially when said function doesn't have a return value...Exceptions to this should be CLEARLY commented to not confuse those who maintain your code.
THE ONLY RULE is that rules are meant to make you think carefully before you break them.
Rules are for the guidance of the wise and obedience by fools.
Oh they have one more purpose... To become the coding standard for a new language and be enforced by the compiler pre-processor so the fools who don't want to follow the rules won't have a choice.... Don't believe me? What was all this JAVA hoopla?
Is that because they were warned by Djikstra that it would be harmful to use it haphazardly? Or is it for some other reason?
I think it's the result of "lint" output that would harp about "goto" statements and gung-ho CS students that took the "don't use GOTO" message to heart...
It's amazing that XP is so bug-ridden that there are still critical vulnerabilities left after 12 years of patching. Even more amazing is that people are lining up to buy Windows 10 from the same company.
But, but, it's going to be BETER... They changed the name and upped the version number to 10!
Still, if you do layoffs and accurately target your low performers (which few companies seem to be able to get totally right) then the top employees who have the skills and can get jobs are going to start walking out the door too. Who wants to work at a place that's all gloom and doom anyway, especially if you have skills that will take you someplace else?
So, yes, layoffs can be helpful, but it's like chemotherapy, the lessor of two evils. You do chemo because the problems it causes you are less severe than the cancer you are trying to treat. Same think applies to layoffs, or at least it should.
I worked at a place once that routinely did layoffs about once a year. Their theory was that they would hire lots of people, too many people for the work they had, then go though and cull the heard every so often to weed out the under performing and keep the top performers. It was a horrible place to work, with everybody angling to cook the performance numbers so they looked good and stabbing others in the back to stay on the top of the pile. Office politics and culture was something to behold. I stayed at that place only long enough to keep it from being a blight on my resume and BAILED at almost exactly 2 years. That's what most of their staff did so they spent a lot of time training, only to watch their best and brightest jump ship about the time they really became useful. You cannot run an effective engineering company that way and they've since gone bankrupt.
So I don't think it's a good idea to do what you suggest over the long term. You don't use layoffs to cull your heard and dump your underperformers. The better approach is to do it with the performance review and have raises based on merit. But the REAL problem here is actually measuring performance in an objective way and keeping HR lawyers happy when you do so. If you don't strike the right balance and really know who's valuable and who's not so much you will harm the company by laying off the wrong people some time, or get your butt sued because you cannot prove you didn't discriminate or something.
But the best approach is to only hire good people and only as many as you can support with the work you have, managing your workload to keep it steady as possible so you don't have to cycle though hiring and firing all the time. But that takes management effort and planning along with a willingness to forego the instant profit in this quarter for the promise of better future results. Something I think MBA's tend to not think too much about because their bonus TODAY is tied to performance TODAY and most of them would rather bag $10 now over $100 next year.
Sounds like the last place I worked.... Large contract abruptly ended with very little notice and the mass exodus of the best and brightest ensued even before the formal announcement of the contract getting pulled.
I got lucky in that I had already decided that it was time to jump ship because it was obvious the performance on the contract that kept 50% of the building employed was extremely sub par and my trying to keep the stuff around me on the ethical up and up was starting to ruffle feathers. I had a job offer about 3 months before they started mowing down their staff.
Word to the wise... When you start to see multiple higher ups bailing on the project, taking other assignments, leaving for companies you never heard of and retiring, at an ever increasing rate, it's past time to get your resume on the street.
I don't question the short term plan, but the long term one. I can understand that there are times when the finances simply CANNOT be ignored and you have to do the layoff of some, to save the whole. I worked a company for 10 years that cycled from about 1,500 employees down to 500 and back to 1,800 only to get my pink slip on their second dip to below 500. I listened to the earnings conference calls, I knew *why* it had to be done from the dollars and cents, profit/loss and all that, but I can tell you it's BAD for the company. Sort of like Chemotherapy is BAD for your health, but you may have no choice.
You MUST have a plan to deal with the negative effects on moral and productivity BEFORE you start cutting staff or your little cost cutting measure will turn into a full scale brain drain and bring your company to ruin.
The smart ones have been thinking "sinking ship" for awhile by now... Now they see the bilge water flowing up in the boat as the crew is throwing the cargo over the side...
If the company they purchased didn't have anything of value going on, why would they buy them?
All I'm saying is that once you start the cycle of layoffs, you simply MUST have a viable recovery plan that assumes your best and brightest will voluntarily follow those you involuntarily escorted out the door, you are in trouble. And I'm not talking about a "Let's work smarter AND harder" pep talk at the next all hands meeting, I'm talking about actually doing something that will work to make the company money so everybody can stay employed.
It's rare that anybody can walk into an organization from the outside, accurately asses the strengths and weaknesses, and come up with even a viable short term plan in a few months that takes it from loosing money to break even. It's even more remote that this plan will be successful if it STARTS by laying off a lot of people who are well known because everybody will now be walking around thinking they have a target on them. Sort term, this goes badly..
Well there AC, in my 20+ years in the business of software development, I've been let go for financial reasons twice, watched others get canned about a dozen times and had to hand out pink slips myself twice. I've seen how the show is run at a number of places and observed a number of things about layoffs which are common to all of them.
First, and most obvious, layoffs are extremely hard on the staff that remains. Productivity and happiness all take a huge dive for everybody. The workplace feels oppressive and EVERYBODY starts thinking about leaving.
Second, even if you lay off the bottom performers, you are going to loose about the same across the top. So if you take 10% off the bottom, unless you do something drastic, you loose 10% off the top. I worked for a company that *routinely* (about once a year) laid off the lowest 10% performers, and it was a horrible place.
Think about these two things that I'm sure they don't mention to the MBA's while they are in school. An MBA is taught about profit and how to manage costs because that is what you can easily quantify. So, the MBA goes out and thinks that he needs to cut X dollars out of his labor cost to break even, so he tells his staff to prep a list of people to layoff that meets that cost savings goal. The low value employees are *usually* the targets, the underperforming and highest paid are too. Heaven help you if you fall into more than one of those categories.
MBA's do the dollars and cents stuff, and when layoffs are warranted due to dollars and cents it's a BAD situation. When it's driven by poor performance, especially poor enough performance that you just got sold off and to stem the bleeding the new owners start in with the hatchet, it's REALLY BAD.
So, like it or not, this worker bee knows what commonly happens and generally why the MBA's do what they do. I don't envy their position, nor do I want to be in their shoes, but I've seen enough young bucks with the ink still drying on their Master's diplomas to recognize the common mistakes they make over and over and the raft full of "experienced" MBA's who still haven't learned better.
Layoffs = accelerated attrition of your best talent
Loss of best talent = dying company = falling sales = unprofitable
Back to the beginning.
In this case, the death spiral will continue until a leader emerges that actually has a workable vision that fits within the resources left. Given the strained resources of the purchase and being "unprofitable" already, it's going to be interesting to see if they actually HAVE a plan for developing something that will work.
IMHO, it's a long shot... Now that the bean counters and MBA's are out chopping heads, things will get worse before they get better.
There is a LOT of context missing from your little example, but never fear, a few comments would/could clear that up.
Look, the bulk of what I end up putting into my code as "comments" is what seems pretty obvious to me, but I spend a lot of time implementing code based on industry specifications (IEEE, RFC's and others). When doing such work, it's usually a good idea to leave behind a way to link back to the specification being implemented (for my sake and for the sake of the programmer behind me) so it's easy to find.
I also tend to opine about each method's reason for existence, including what inputs it expects, what exceptions it might throw and what output you can expect. One thing I make a point to document in function and class headers is any place where this code may have some hidden affect on something, especially something you didn't pass in. I do this in the header, mainly because it's easer for the programmer that comes behind me, but also because we use doxygen to convert all this stuff into documents for later reference.
No, Comments are a necessity for my job and I think if you think about it, yours too. Maybe not as detailed as what I go though, but a very good discipline for a coder.
First time I saw one, my first thought was "Now that's just NOT smart to have a car that small.." Since then I found out what they are called. Oxymoron....
Ok.. I'll help Buzz then and take over when he's done. Who am I to take away his satisfaction of having the first punch?
Everybody knows we now have confirmation that there are footsteps on the moon, amazingly exactly where we said we went and picked up rocks.. Seems we have independently obtained pictures now.
I'd take pieces of the Moon to give to people or to show off to strangers.
I know of one moon rock you can actually touch if you wanted too. I think was at the CosmoSphere in Hutchison KS http://www.cosmo.org/mu_artifa...
In fact, I'd strongly suggest that if you really insist we didn't go to the moon that you visit both the Cosmosphere in Kansas and the Smithsonian Air & Space museum in Washington DC and go though their exhibits that have the artifacts and facts on the subject. I'm sure you will learn something.
Slashdot Mirror
Oh I WISH that where possible.. Problem here is that you are going to have to prove two things.. 1. that the sick child who couldn't be vaccinated really couldn't (easy) and 2. That they only could have got the sickness from THAT specific child (hard). Then you are going to have to come up with a way to measure actual damages....
Oh this is pretty much crap you know...
First, this opinion was brought to us by ONE (that's 1) published study that found a POSSIBLE but not confirmed link between the compounds with mercury that where used in *some* vaccines at the time. Since then three things have happened.
1. The published study has been found to be invalid due to errors in their facts and methods and has been recalled by the publisher and the authors have been discredited for their shoddy work.
2. Multiple studies have been done since that verifies that the original findings where incorrect and that there is in fact no link to vaccines that used mercury compounds and autism.
3. ALL modern vaccines have stopped using the compounds in called into question by the now discredited and disproven study decades ago.
There is NO LINK to autism from vaccines....They don't use the chemicals in question anymore, and even if they did the link was disproven.
Not to mention that we now KNOW what causes autism and it's NOT mercury exposure as a child.
So go grab your kids and take them to the pediatrician and get them vaccinated unless the doctor has a reason they shouldn't be.
You can't average a bunch of averages.
Oh sure you can... It's just not going to lead you to the answer you where likely looking for...
Ah come on, it's 6 one way and half a dozen the other..
Lies, damn lies and statistics...
I prefer to keep the gluttons away from my lunches as well. It's hard to deal with gluten intolerance when they're eating all of my food.
I think you need to go to diversity training for that comment. We are all inclusive here at Slashdot, where we all are gluttons for punishment...
What part of "rule of thumb" do you not get? There are times when it's done, but it should be avoided.
The reason is easy to get if you think about it. Functions start at the top and should end at the bottom... Returns in between are (generally) "bad form" because it's easy to miss them when looking at the source code.
BTW, this applies double when you are actually returning a value to the caller... Still there are exceptions, but in general, one return, at the bottom, is best.
Here is your reference... http://en.wikipedia.org/wiki/R...
Only on the right family of processors....
However, when properly used, NOTHING is faster or has a smaller memory footprint. There ARE reasons for this stuff...
"GOTO" existed before subroutines and functions were added, and it was back in the days of line numbers. This was the point where the main menu part of a program had to jump over to the appropriate part of the program, now we just call the appropriate routine.
GOTO predates just about everything but the CPU. It's a mirror of the "Jump to:" machine instruction that is common to EVERY Processor I've ever seen.
Man, you just blew another coding rule of thumb....
There should be only ONE return statement in a function, especially when said function doesn't have a return value...Exceptions to this should be CLEARLY commented to not confuse those who maintain your code.
THE ONLY RULE is that rules are meant to make you think carefully before you break them.
Rules are for the guidance of the wise and obedience by fools.
Oh they have one more purpose... To become the coding standard for a new language and be enforced by the compiler pre-processor so the fools who don't want to follow the rules won't have a choice.... Don't believe me? What was all this JAVA hoopla?
Is that because they were warned by Djikstra that it would be harmful to use it haphazardly? Or is it for some other reason?
I think it's the result of "lint" output that would harp about "goto" statements and gung-ho CS students that took the "don't use GOTO" message to heart...
It's amazing that XP is so bug-ridden that there are still critical vulnerabilities left after 12 years of patching. Even more amazing is that people are lining up to buy Windows 10 from the same company.
But, but, it's going to be BETER... They changed the name and upped the version number to 10!
Still, if you do layoffs and accurately target your low performers (which few companies seem to be able to get totally right) then the top employees who have the skills and can get jobs are going to start walking out the door too. Who wants to work at a place that's all gloom and doom anyway, especially if you have skills that will take you someplace else?
So, yes, layoffs can be helpful, but it's like chemotherapy, the lessor of two evils. You do chemo because the problems it causes you are less severe than the cancer you are trying to treat. Same think applies to layoffs, or at least it should.
I worked at a place once that routinely did layoffs about once a year. Their theory was that they would hire lots of people, too many people for the work they had, then go though and cull the heard every so often to weed out the under performing and keep the top performers. It was a horrible place to work, with everybody angling to cook the performance numbers so they looked good and stabbing others in the back to stay on the top of the pile. Office politics and culture was something to behold. I stayed at that place only long enough to keep it from being a blight on my resume and BAILED at almost exactly 2 years. That's what most of their staff did so they spent a lot of time training, only to watch their best and brightest jump ship about the time they really became useful. You cannot run an effective engineering company that way and they've since gone bankrupt.
So I don't think it's a good idea to do what you suggest over the long term. You don't use layoffs to cull your heard and dump your underperformers. The better approach is to do it with the performance review and have raises based on merit. But the REAL problem here is actually measuring performance in an objective way and keeping HR lawyers happy when you do so. If you don't strike the right balance and really know who's valuable and who's not so much you will harm the company by laying off the wrong people some time, or get your butt sued because you cannot prove you didn't discriminate or something.
But the best approach is to only hire good people and only as many as you can support with the work you have, managing your workload to keep it steady as possible so you don't have to cycle though hiring and firing all the time. But that takes management effort and planning along with a willingness to forego the instant profit in this quarter for the promise of better future results. Something I think MBA's tend to not think too much about because their bonus TODAY is tied to performance TODAY and most of them would rather bag $10 now over $100 next year.
Sounds like the last place I worked.... Large contract abruptly ended with very little notice and the mass exodus of the best and brightest ensued even before the formal announcement of the contract getting pulled.
I got lucky in that I had already decided that it was time to jump ship because it was obvious the performance on the contract that kept 50% of the building employed was extremely sub par and my trying to keep the stuff around me on the ethical up and up was starting to ruffle feathers. I had a job offer about 3 months before they started mowing down their staff.
Word to the wise... When you start to see multiple higher ups bailing on the project, taking other assignments, leaving for companies you never heard of and retiring, at an ever increasing rate, it's past time to get your resume on the street.
I don't question the short term plan, but the long term one. I can understand that there are times when the finances simply CANNOT be ignored and you have to do the layoff of some, to save the whole. I worked a company for 10 years that cycled from about 1,500 employees down to 500 and back to 1,800 only to get my pink slip on their second dip to below 500. I listened to the earnings conference calls, I knew *why* it had to be done from the dollars and cents, profit/loss and all that, but I can tell you it's BAD for the company. Sort of like Chemotherapy is BAD for your health, but you may have no choice.
You MUST have a plan to deal with the negative effects on moral and productivity BEFORE you start cutting staff or your little cost cutting measure will turn into a full scale brain drain and bring your company to ruin.
The smart ones have been thinking "sinking ship" for awhile by now... Now they see the bilge water flowing up in the boat as the crew is throwing the cargo over the side...
If the company they purchased didn't have anything of value going on, why would they buy them?
All I'm saying is that once you start the cycle of layoffs, you simply MUST have a viable recovery plan that assumes your best and brightest will voluntarily follow those you involuntarily escorted out the door, you are in trouble. And I'm not talking about a "Let's work smarter AND harder" pep talk at the next all hands meeting, I'm talking about actually doing something that will work to make the company money so everybody can stay employed.
It's rare that anybody can walk into an organization from the outside, accurately asses the strengths and weaknesses, and come up with even a viable short term plan in a few months that takes it from loosing money to break even. It's even more remote that this plan will be successful if it STARTS by laying off a lot of people who are well known because everybody will now be walking around thinking they have a target on them. Sort term, this goes badly..
Well there AC, in my 20+ years in the business of software development, I've been let go for financial reasons twice, watched others get canned about a dozen times and had to hand out pink slips myself twice. I've seen how the show is run at a number of places and observed a number of things about layoffs which are common to all of them.
First, and most obvious, layoffs are extremely hard on the staff that remains. Productivity and happiness all take a huge dive for everybody. The workplace feels oppressive and EVERYBODY starts thinking about leaving.
Second, even if you lay off the bottom performers, you are going to loose about the same across the top. So if you take 10% off the bottom, unless you do something drastic, you loose 10% off the top. I worked for a company that *routinely* (about once a year) laid off the lowest 10% performers, and it was a horrible place.
Think about these two things that I'm sure they don't mention to the MBA's while they are in school. An MBA is taught about profit and how to manage costs because that is what you can easily quantify. So, the MBA goes out and thinks that he needs to cut X dollars out of his labor cost to break even, so he tells his staff to prep a list of people to layoff that meets that cost savings goal. The low value employees are *usually* the targets, the underperforming and highest paid are too. Heaven help you if you fall into more than one of those categories.
MBA's do the dollars and cents stuff, and when layoffs are warranted due to dollars and cents it's a BAD situation. When it's driven by poor performance, especially poor enough performance that you just got sold off and to stem the bleeding the new owners start in with the hatchet, it's REALLY BAD.
So, like it or not, this worker bee knows what commonly happens and generally why the MBA's do what they do. I don't envy their position, nor do I want to be in their shoes, but I've seen enough young bucks with the ink still drying on their Master's diplomas to recognize the common mistakes they make over and over and the raft full of "experienced" MBA's who still haven't learned better.
MBA's + Bean Counting = Layoffs
Layoffs = accelerated attrition of your best talent
Loss of best talent = dying company = falling sales = unprofitable
Back to the beginning.
In this case, the death spiral will continue until a leader emerges that actually has a workable vision that fits within the resources left. Given the strained resources of the purchase and being "unprofitable" already, it's going to be interesting to see if they actually HAVE a plan for developing something that will work.
IMHO, it's a long shot... Now that the bean counters and MBA's are out chopping heads, things will get worse before they get better.
There is a LOT of context missing from your little example, but never fear, a few comments would/could clear that up.
Look, the bulk of what I end up putting into my code as "comments" is what seems pretty obvious to me, but I spend a lot of time implementing code based on industry specifications (IEEE, RFC's and others). When doing such work, it's usually a good idea to leave behind a way to link back to the specification being implemented (for my sake and for the sake of the programmer behind me) so it's easy to find.
I also tend to opine about each method's reason for existence, including what inputs it expects, what exceptions it might throw and what output you can expect. One thing I make a point to document in function and class headers is any place where this code may have some hidden affect on something, especially something you didn't pass in. I do this in the header, mainly because it's easer for the programmer that comes behind me, but also because we use doxygen to convert all this stuff into documents for later reference.
No, Comments are a necessity for my job and I think if you think about it, yours too. Maybe not as detailed as what I go though, but a very good discipline for a coder.
You didn't answer the question. (grin)..
First time I saw one, my first thought was "Now that's just NOT smart to have a car that small.." Since then I found out what they are called. Oxymoron....
Let me guess... It got away?
Ok.. I'll help Buzz then and take over when he's done. Who am I to take away his satisfaction of having the first punch?
Everybody knows we now have confirmation that there are footsteps on the moon, amazingly exactly where we said we went and picked up rocks.. Seems we have independently obtained pictures now.
I'd take pieces of the Moon to give to people or to show off to strangers.
I know of one moon rock you can actually touch if you wanted too. I think was at the CosmoSphere in Hutchison KS http://www.cosmo.org/mu_artifa...
In fact, I'd strongly suggest that if you really insist we didn't go to the moon that you visit both the Cosmosphere in Kansas and the Smithsonian Air & Space museum in Washington DC and go though their exhibits that have the artifacts and facts on the subject. I'm sure you will learn something.