He may be alive, but is he sane? I can't imagine dealing with TSA, gate agents, and all of the other hassles that go with air travel that many times.
It's like any other B.S. in life, if you do it enough, it doesn't bother you. TSA will always be a sore spot for a lot of people because they just don't encounter it often enough to develop the social callouses.
The "service" personnel in coach are actually safety officers - but rather than have them sit around looking like air marshals, they attempt to get them to keep the customers happy. Of course, at the wages they pay, it's amazing there aren't more dramatic Take this Job and Shove It events.
Mid 1990s, American Airlines, Miami to Boston - 6+ hours in the air non-stop. One time I got a 3/4 ounce bag of peanuts. The next time I flew that route it was only 1/2 ounce of peanuts.
If I was about to faint, I'm sure I could have begged for more, they might have even had some stale soda crackers available, upon request.
Here is your 4-ounce Dr. Pepper and complimentary half-bag of potato chips.
Apparently, you've never flown First Class. On a KLM hop from London to Amsterdam, I sat in First - the chips and soda were in the back, but it was lunchtime and a decent meal was provided in First. More impressive than the food was the fact that one man took a little longer to finish than the rest of us. When he did hand his tray to one stewardess, another stewardess pressed a button that set off a chime in the cockpit - within 5 seconds the pilot announced and started our descent into Amsterdam.
If you're not paying full fare, you're just baggage.
My first car was imported to Florida from Ohio, without air-conditioning (and was understandably inexpensive, especially when I purchased it in June). Over the next three months, I developed the habit of stopping every hour to purchase an ice-drink (Slurpee from 7-11), or just travelling at night. Sheepskin seat covers to wick the sweat were also very helpful.
Direct ingestion of ice works, and in my experience, one liter of crushed ice lasted about 45 minutes for comfort, 90 minutes before there were possible health concerns from being exposed to 40C+ heat. Of course, in the car I had access to a guaranteed strong wind and some shade, might be more taxing on the body in the open square.
While your answer was mostly ok, the last paragraph ruined it. There are no people who are not confident programmers, because everyone is trying their best.
In the ideal touchy-feely world where code reviews benefit everyone, you are absolutely right.
Back in my life, I had a coder who was having a terrible time getting a routine to run quickly enough. He resisted over the shoulder help. He ignored outline sketches of how to do it. When it came time for code review, he pulled me aside and stated outright that he preferred one on one help - the same help he had been resisting for weeks. Turns out that the reason his code was so slow was because he had an unnecessary level of loop nesting, slowing things down by a factor of about 100. He couldn't, or wouldn't, fix it after several of his peers outlined the solution for him. When I finally rewrote it for him, he added comments to "see me about this part of the code" because he just didn't understand it. He had a Ph.D. in Physics and years of teaching experience.
Of course, you may be right, he might not have had a confidence problem, he asked for a 30% raise after that. There are some people who seek jobs in programming who are clearly better suited to other endeavors. Sadly, if they are experienced enough, they can say all the right things for several months - but the truth does come out eventually.
I ran a shop with 2 B.S. graduates and 2 Ph.D.s. The main difference between them was that the B.S. graduates could understand and execute simple instructions like "put your name on the top of this form where it says "Name________"". The Ph.D.s pretty much embodied the picture from the Wizard of OZ's degree in "Thinkology" - they'd take a long time to work on a small problem and 90% of the time come up with nothing better than was obvious in the first 5 minutes, often they'd miss the obvious easy kill and end up taking a long time to do something the hard way.
That said, one of the Ph.D.s was pretty sharp, and once in awhile he'd come out with something pretty cool - but it was a long time between gems.
To expect people to find the time in their schedules to try and understand the sofwtare that one of their colleagues has written is impractical.
Funny thing I find: some programmers can get more accomplished in a 30 hour work week than others can in a 200 hour month.
If you spend 5 hours a week developing the social rapport required to actually work "together" instead of in silos, and another 5 hours a week transferring knowledge from the good programmers to the not so good ones (and "good" is not a simple scale, even the "best" programmers have things they can learn from others who might not be as "good" overall), holy crap, you've "wasted" 25% of your standard 40 hour work week.
If you succeed in transfer of knowledge, cross pollination, and all that other crap that many programmers believe they are too good to benefit from, that 25% "waste" of the good guy should more than pay off in improvement of his skills, and the skills of those who are learning from him.
And, the guy that takes 7x as many hours to accomplish the same task, is usually also producing an inferior product in the end. Even if code review just gets his product quality level up without speeding anything up in the future, if the code was really worth writing, the improvement in quality will be worth the 25% additional investment (fewer post delivery bug fixes, earlier opportunity for new business, etc.)
Code reviews are good for finding bugs and - if you happen to have one - confirming to a coding style guide.
I used to think style guides were a "Good Idea (TM)," but, then, I started getting lazy and importing other people's source code. Big chunks of it. From within the company, from LGPL sources, etc., and, guess what? Reformatting all that code to fit a style guide is a colossal waste of time.
I actually like the "personal style" that we use here, every programmer has their own preferred way of writing their C code. As a programmer, you should be able to decipher code regardless of the style, so, now, when I see that particular form of commenting and bracket placement, I know who to go to for an explanation of "what the hell were you thinking here?"
I've rarely seen code reviews find anything useful. They mostly turn into nit-pick sessions about naming conventions while real bugs slip right through. And they're always done at the last minute
Clearly, you're doing it wrong. Not saying that your particular shop is capable of doing it right, but if nobody is even trying to do it right, what do you expect?
The problem is that the need for code reviews is driven by lax, sloppy developers who don't see regression testing as a requirement, and who foist crappy, untested code that, in many cases, they haven't even tested.
Code review and regression testing are separate animals.
Code review is an application of the hive mind to the problem at hand, and an exchange of knowledge among the worker bees which can, in an ideal world, lead to better productivity for everyone after the meeting.
Regression testing is an (imperfect) attempt to be sure that requirements are met.
The two are complimentary, both can be misused, abused, and turned into a mockery of what they should be.
But the software only has to be 'good enough' for people to buy it, so there's no ammunition for developers to use to get a better schedule.
This is why "life safety" industries have quality standards that require documentation of design controls, verification and validation activities.
Thing is, most industries have "fatal accidents," where the business itself is killed by relying on a bunch of technology that nobody really understands. Capitalistic evolution hasn't had enough generations of software based companies for the "fit and nimble" mammals to take down the dinosaurs yet.
I commit almost hourly, reviews are for when the team needs to understand what's going on in the code.
In the "serial monogamy" relationship that developers have with code around here, divorce and re-marriage time is usually when a review is appropriate.
Warnings and lint are a start, but they say nothing about whether or not things actually work.
When the required functionality is specified, and a test procedure that actually tests the required functionality (to the degree appropriate for each function's level of concern) passes successfully, then I'll say that the code itself doesn't need further review.
When new specs come along, or a new programmer is added to the project, some form of code review is called for.
Longer answer: Code Reviews are a "best practice" that really needs to be driven by management and ingrained in the culture as "one of those things that you do" like showing up on time every day (even if that time is 10am), participating in Scrum, turning in your timesheet, etc.
If management is lax and doesn't require code reviews on a regular basis (or, even worse, does them "as needed"), then it is an awkward unpleasant process that can become counterproductive.
So, most places I have worked have treated code review in the "as needed" category, they come up once every year or so, and it feels like more of a flogging for the coder who is being reviewed than a productive forum for learning. Apparently, in 20 years of coding, my management hasn't ever felt the need to review my code. Regulatory agencies have demanded verification and validation, but that is an entirely different thing from programmer to programmer review of how code works.
When I have been in the management chair, I pushed to have some kind of meaningful code review at least every 3 months. That's not often enough, but the places where I was in management were usually of a cultural mindset that code review was a waste of time.
That belief that code reviews are a waste of time seems to be most dearly held by the people who either a) are not confident programmers, b) confident programmers who aren't really that good, c) have (or take) no responsibility for quality and maintenance of a significant code base, or d) don't understand programming at all.
Not long enough to pay off the amount of hardware required to generate the rent.
Within a few months, the power company would have you flagged, if you're in a free electricity apartment, no doubt they would inform the landlord and law enforcement just incase your're running a grow house or meth lab.
When they find out that you're making money with computers, somebody will probably call the Secret Service - it might take 6 months, but sooner or later somebody is going to have a warrant to search the premises and examine the contents of the computers. All this is assuming that the landlord doesn't just pull the plug on your operation by backing out of the lease you signed and either a) charging you for electricity, b) evicting you and your equipment outright, or c) just cutting off electric service to your apartment.
Would make an interesting test case for the ACLU - if you want to live your life as a test case for the ACLU.
Yeah, I bought one of those "stupidly optimized" workstation cards to go with AutoDesk Inventor - as recommended by the AutoDesk certified training center professionals.
Damn card would power-spike the system bus and cause a power-fail reboot every time certain rotate operations were performed - real helpful it was.
I feel like it just doesn't make sense to purposefully confuse the public by not coming up with reasonable names.
I agree, but... if they were to try to create a naming scheme that could be understood by the average Wal-Mart shopper, they would still fail.
I would want a GPU name to convey:
- Number of pipelines
- Speed/Capability of pipelines
- Amount of memory
- Speed of memory
- Software compliance (itself a multidimensional variable)
So, when I compare a VP350UG266-G2X11 to a VP350SG233-G2X11, I know that what I'm getting is more video memory, but at a lower speed, and the same pipeline capabilities.
It seems like Chinese would be a better language to focus on, given the worries that many people have about that country.
I'm afraid that Chinese is so foreign as to break the US Intelligence Advanced Research Projects model.
I think Mexican Spanish is in focus because of physical proximity and the English-Spanish language barrier. The Canadian lingusitic border is a little more porous (until you reach Quebec...)
We are currently performing maintenance. Please try again later.
If there truly are only 21M bitcoin maximum, it's a genuinely stupid currency because only a small fraction of the world's population can even hold one. I think China just passed 450M registered internet users...
Also, how long before all 21M coin are mined? Not long at $8/coin, I'm sure.
Slashdot Mirror
He may be alive, but is he sane? I can't imagine dealing with TSA, gate agents, and all of the other hassles that go with air travel that many times.
It's like any other B.S. in life, if you do it enough, it doesn't bother you. TSA will always be a sore spot for a lot of people because they just don't encounter it often enough to develop the social callouses.
The "service" personnel in coach are actually safety officers - but rather than have them sit around looking like air marshals, they attempt to get them to keep the customers happy. Of course, at the wages they pay, it's amazing there aren't more dramatic Take this Job and Shove It events.
Mid 1990s, American Airlines, Miami to Boston - 6+ hours in the air non-stop. One time I got a 3/4 ounce bag of peanuts. The next time I flew that route it was only 1/2 ounce of peanuts.
If I was about to faint, I'm sure I could have begged for more, they might have even had some stale soda crackers available, upon request.
Here is your 4-ounce Dr. Pepper and complimentary half-bag of potato chips.
Apparently, you've never flown First Class. On a KLM hop from London to Amsterdam, I sat in First - the chips and soda were in the back, but it was lunchtime and a decent meal was provided in First. More impressive than the food was the fact that one man took a little longer to finish than the rest of us. When he did hand his tray to one stewardess, another stewardess pressed a button that set off a chime in the cockpit - within 5 seconds the pilot announced and started our descent into Amsterdam.
If you're not paying full fare, you're just baggage.
My first car was imported to Florida from Ohio, without air-conditioning (and was understandably inexpensive, especially when I purchased it in June). Over the next three months, I developed the habit of stopping every hour to purchase an ice-drink (Slurpee from 7-11), or just travelling at night. Sheepskin seat covers to wick the sweat were also very helpful.
Direct ingestion of ice works, and in my experience, one liter of crushed ice lasted about 45 minutes for comfort, 90 minutes before there were possible health concerns from being exposed to 40C+ heat. Of course, in the car I had access to a guaranteed strong wind and some shade, might be more taxing on the body in the open square.
While your answer was mostly ok, the last paragraph ruined it. There are no people who are not confident programmers, because everyone is trying their best.
In the ideal touchy-feely world where code reviews benefit everyone, you are absolutely right.
Back in my life, I had a coder who was having a terrible time getting a routine to run quickly enough. He resisted over the shoulder help. He ignored outline sketches of how to do it. When it came time for code review, he pulled me aside and stated outright that he preferred one on one help - the same help he had been resisting for weeks. Turns out that the reason his code was so slow was because he had an unnecessary level of loop nesting, slowing things down by a factor of about 100. He couldn't, or wouldn't, fix it after several of his peers outlined the solution for him. When I finally rewrote it for him, he added comments to "see me about this part of the code" because he just didn't understand it. He had a Ph.D. in Physics and years of teaching experience.
Of course, you may be right, he might not have had a confidence problem, he asked for a 30% raise after that. There are some people who seek jobs in programming who are clearly better suited to other endeavors. Sadly, if they are experienced enough, they can say all the right things for several months - but the truth does come out eventually.
the jackass-with-a-Doctor's-degree
I ran a shop with 2 B.S. graduates and 2 Ph.D.s. The main difference between them was that the B.S. graduates could understand and execute simple instructions like "put your name on the top of this form where it says "Name________"". The Ph.D.s pretty much embodied the picture from the Wizard of OZ's degree in "Thinkology" - they'd take a long time to work on a small problem and 90% of the time come up with nothing better than was obvious in the first 5 minutes, often they'd miss the obvious easy kill and end up taking a long time to do something the hard way.
That said, one of the Ph.D.s was pretty sharp, and once in awhile he'd come out with something pretty cool - but it was a long time between gems.
To expect people to find the time in their schedules to try and understand the sofwtare that one of their colleagues has written is impractical.
Funny thing I find: some programmers can get more accomplished in a 30 hour work week than others can in a 200 hour month.
If you spend 5 hours a week developing the social rapport required to actually work "together" instead of in silos, and another 5 hours a week transferring knowledge from the good programmers to the not so good ones (and "good" is not a simple scale, even the "best" programmers have things they can learn from others who might not be as "good" overall), holy crap, you've "wasted" 25% of your standard 40 hour work week.
If you succeed in transfer of knowledge, cross pollination, and all that other crap that many programmers believe they are too good to benefit from, that 25% "waste" of the good guy should more than pay off in improvement of his skills, and the skills of those who are learning from him.
And, the guy that takes 7x as many hours to accomplish the same task, is usually also producing an inferior product in the end. Even if code review just gets his product quality level up without speeding anything up in the future, if the code was really worth writing, the improvement in quality will be worth the 25% additional investment (fewer post delivery bug fixes, earlier opportunity for new business, etc.)
Code reviews are good for finding bugs and - if you happen to have one - confirming to a coding style guide.
I used to think style guides were a "Good Idea (TM)," but, then, I started getting lazy and importing other people's source code. Big chunks of it. From within the company, from LGPL sources, etc., and, guess what? Reformatting all that code to fit a style guide is a colossal waste of time.
I actually like the "personal style" that we use here, every programmer has their own preferred way of writing their C code. As a programmer, you should be able to decipher code regardless of the style, so, now, when I see that particular form of commenting and bracket placement, I know who to go to for an explanation of "what the hell were you thinking here?"
The secret to code reviewing is very simple: Don't be a Dick (tm).
So very true, but since virtually all programmers are male....
I've rarely seen code reviews find anything useful. They mostly turn into nit-pick sessions about naming conventions while real bugs slip right through. And they're always done at the last minute
Clearly, you're doing it wrong. Not saying that your particular shop is capable of doing it right, but if nobody is even trying to do it right, what do you expect?
The problem is that the need for code reviews is driven by lax, sloppy developers who don't see regression testing as a requirement, and who foist crappy, untested code that, in many cases, they haven't even tested.
Code review and regression testing are separate animals.
Code review is an application of the hive mind to the problem at hand, and an exchange of knowledge among the worker bees which can, in an ideal world, lead to better productivity for everyone after the meeting.
Regression testing is an (imperfect) attempt to be sure that requirements are met.
The two are complimentary, both can be misused, abused, and turned into a mockery of what they should be.
But I don't have all the time in the world, so I do what I can given the time that I've been given to get work done.
So you, like me, are posting on /. at 11AM EST.
>
But the software only has to be 'good enough' for people to buy it, so there's no ammunition for developers to use to get a better schedule.
This is why "life safety" industries have quality standards that require documentation of design controls, verification and validation activities.
Thing is, most industries have "fatal accidents," where the business itself is killed by relying on a bunch of technology that nobody really understands. Capitalistic evolution hasn't had enough generations of software based companies for the "fit and nimble" mammals to take down the dinosaurs yet.
I commit almost hourly, reviews are for when the team needs to understand what's going on in the code.
In the "serial monogamy" relationship that developers have with code around here, divorce and re-marriage time is usually when a review is appropriate.
Warnings and lint are a start, but they say nothing about whether or not things actually work.
When the required functionality is specified, and a test procedure that actually tests the required functionality (to the degree appropriate for each function's level of concern) passes successfully, then I'll say that the code itself doesn't need further review.
When new specs come along, or a new programmer is added to the project, some form of code review is called for.
Longer answer: Code Reviews are a "best practice" that really needs to be driven by management and ingrained in the culture as "one of those things that you do" like showing up on time every day (even if that time is 10am), participating in Scrum, turning in your timesheet, etc.
If management is lax and doesn't require code reviews on a regular basis (or, even worse, does them "as needed"), then it is an awkward unpleasant process that can become counterproductive.
So, most places I have worked have treated code review in the "as needed" category, they come up once every year or so, and it feels like more of a flogging for the coder who is being reviewed than a productive forum for learning. Apparently, in 20 years of coding, my management hasn't ever felt the need to review my code. Regulatory agencies have demanded verification and validation, but that is an entirely different thing from programmer to programmer review of how code works.
When I have been in the management chair, I pushed to have some kind of meaningful code review at least every 3 months. That's not often enough, but the places where I was in management were usually of a cultural mindset that code review was a waste of time.
That belief that code reviews are a waste of time seems to be most dearly held by the people who either a) are not confident programmers, b) confident programmers who aren't really that good, c) have (or take) no responsibility for quality and maintenance of a significant code base, or d) don't understand programming at all.
That is blatant greed
Why else would you put up with undergraduate pre-med harassment, med school entry b.s., and hazing (residency)?
The AMA is largely to blame for the current "attitude skew" of M.D.s in America.
Not long enough to pay off the amount of hardware required to generate the rent.
Within a few months, the power company would have you flagged, if you're in a free electricity apartment, no doubt they would inform the landlord and law enforcement just incase your're running a grow house or meth lab.
When they find out that you're making money with computers, somebody will probably call the Secret Service - it might take 6 months, but sooner or later somebody is going to have a warrant to search the premises and examine the contents of the computers. All this is assuming that the landlord doesn't just pull the plug on your operation by backing out of the lease you signed and either a) charging you for electricity, b) evicting you and your equipment outright, or c) just cutting off electric service to your apartment.
Would make an interesting test case for the ACLU - if you want to live your life as a test case for the ACLU.
Yeah, I bought one of those "stupidly optimized" workstation cards to go with AutoDesk Inventor - as recommended by the AutoDesk certified training center professionals.
Damn card would power-spike the system bus and cause a power-fail reboot every time certain rotate operations were performed - real helpful it was.
I feel like it just doesn't make sense to purposefully confuse the public by not coming up with reasonable names.
I agree, but... if they were to try to create a naming scheme that could be understood by the average Wal-Mart shopper, they would still fail.
I would want a GPU name to convey:
- Number of pipelines
- Speed/Capability of pipelines
- Amount of memory
- Speed of memory
- Software compliance (itself a multidimensional variable)
So, when I compare a VP350UG266-G2X11 to a VP350SG233-G2X11, I know that what I'm getting is more video memory, but at a lower speed, and the same pipeline capabilities.
Yeah, that'll help the Wal-Mart shoppers.
As metaphores are invented on the fly it is pretty hard to make a meaningfull database of them.
Most speakers don't invent on the fly, most speakers parrot things they have heard before.
It seems like Chinese would be a better language to focus on, given the worries that many people have about that country.
I'm afraid that Chinese is so foreign as to break the US Intelligence Advanced Research Projects model.
I think Mexican Spanish is in focus because of physical proximity and the English-Spanish language barrier. The Canadian lingusitic border is a little more porous (until you reach Quebec...)
Oh, fractional coin, what a wonderful idea. O.K., so, now, at 0.00019867 coin per hour, and $8/coin that's about $1 per month for mining.
We are currently performing maintenance. Please try again later.
If there truly are only 21M bitcoin maximum, it's a genuinely stupid currency because only a small fraction of the world's population can even hold one. I think China just passed 450M registered internet users...
Also, how long before all 21M coin are mined? Not long at $8/coin, I'm sure.