Despite that, it certainly is a particularly aggressive myth, especially in the service industry.
You would think that the tech types around here would understand how marginal rates work, it is a fairly straight-forward math and logic problem. On a related note, I wonder why software is so buggy?
>>Also the repayment of the debt is a flat rate on all earnings, that increases depending on gross earnings.
That is why rational tax systems don't apply higher rates on all earnings, but only to the next dollar earned. That way, every dollar earned results in more take-home pay.
It is kind of funny that the Australian UNIVERSITY debt system failed both math and logic. Probably more a reflection on the intelligence of lawmakers than of university types.
>>(Hey, most of the last 10% is taxes anyway, right)
Not Right.
The idea that at a certain point, the govt takes most of your earnings in taxes is an urban legend. For anybody working by the hour, there is no "tipping point" where the govt keeps most of each additional dollar - it is just untrue.
>>If everyone did this (4x9hr days), we could avoid tons of layoffs nationwide. A company can avoid layoffs by cutting hours and pay. If everybody at every company had their hours and pay cut, their bills remain the same, so the workers' spendable income after covering expenses is either gone or greatly reduced - You have just created a recession.
>>that's what prototypes, iteration, and capacity planning are for
So, we are in complete agreement that performance is not an end stage activity.
Good!
OH,
So sorry, I thought we were discussing the merits of throwing more hardware at bad code.
I had not realized this was the discussion for the semantics of the word "optimization."
Bitter experience has taught me that performance must start with design optimization, long before code optimization.
Sorry for the snarl, I have been working 6 weeks on "optimizing" a rather critical piece of code where performance was a complete afterthought. We have managed to speed it up by an order of magnitude, but poor performance is "baked in" to the design at every level, so there is only so much we can do.
If the first time you ever address performance is by "measuring what's slow", then performance was indeed an afterthought - after design, after coding, after testing.
If you only start thinking about performance that late in the game, your design will probably include more than one peformance degrading decision that is just too painful to rewrite.
As a database guy, I would say that:
Database locking issues with a poor design won't be fixed no matter how much hardware you throw at it, it will just lock up faster.
Database structures are one of the first products of development, and many (most) developers just try to model the data without any thought to performance.
The other terrible mistake that many coders make is to process records and fields one at a time instead of using bulk operations.
The old saw about "Premature Optimization is Evil" is false:
Making performance a late afterthought guarantees doom that no amount of hardware can fix.
When it is busy at the post office, they go on break, the line be damned. Employees just wander around behind the counter in full view of the long long lines - there is no urgency at all.
All the big retailers schedule extra help during busy business times. When it is extra busy at any modern store, they call all the employees to the cash registers - even the managers will man the registers when it is busy.
Say what you want about private enterprise, but it is hard to argue that they don't care about taking your money!
If the guy down the street is better at taking your money, he will do it and the first guy will improve or go out of business.
With government, there is no guy down the street to push for improvement. It is that simple.
Biking is good.
Be more than careful - a few drivers are hostile to sharing the road and most won't notice you.
Cut carbohydrate consumption - high carb consumption makes you fat in the middle.
Diabetes is an occupational risk for programmers as we get older. Many of the fat programmers my age (50) are diabetic.
Another good reason to cut carbohydrates and increase exercise.
Ok that is the drunk version, but I went to all kinds of trainings, and 99% was useless. Just write an app that does.SOMETHING. in language @#$%, then you learn something. Then read a book about it, and you will be better than any certified monkey.
Congratulations!
Daily Drunkard's Award for Brilliant Insight
Congratulations on your first project not being a disaster.
The higher-ups know that your boss is not doing the work with his own two hands.
I own a small software company, and had a student / tester guy who I gave a small programming project to. He really put all his best effort into it. He was so proud of his work that he insisted on getting the recognition he deserved.
I gave it to him. He was ignoring his primary job responsibilities, and he spent several times as long as a junior coder would have, and his code was such that we needed to refactor / toss out all his work.
A month later he let me know that since he was going to be graduating from DEVRY soon, he really expected to work full time coding at 4 times the money. What an idiot!
Can you guess how this story ends?
Multi geared bikes need lots of trips to the shop, and even then leave you stranded sometimes.
Not a good selling point for bikes.
As you point out, totally reliable bikes are heavy and no fun.
How can you sell the sweat and hassle to people who grew up with Mom driving them 6 blocks to school?
I am a former bike shop rat.
Bikes require a lot more maintenance per mile than a modern car.
"Dutch Bikes" (Omafiets) may be as sturdy as you would hope, but have never been sold here in the US.
We seem to prefer flashier, flimsier, and cheaper rides.
The bikes sold in the US are not good commuter bikes - way too many trips back to the shop.
After 20 years of the slothful sedentary life of a programmer,
I have returned to commuting by bike to get exercise for health reasons.
Dude!
It is a dangerous way to get to work.
Ride too far to the right - and cars push you even further - into parked cars, truck mirrors, sewer grates, and as far as the curb.
Idiots in trucks and SUVs have no idea how wide their right side mirrors are - they WILL hit you.
Drivers simply assume you out of existence and pass much too close.
Assuming a cyclist out of existence does work - do it a few times, and the cyclist ceases to exist.
Ride out further into the lane (the only safe place to ride), and people honk, spit, rev engines as a challenge, and follow along menacing you with their god given power as DRIVERS.
It would take like 2 seconds for a car to pass wide - but many people are just deeply offended and assume (incorrectly) a cyclist has no rights to the road.
Then there are the young punks with horsepower who bully cyclists.
I have been hit with cokes and even a quart of chocolate ice cream by these guys.
The ice cream dang near knocked me down into the road in front of traffic - a deadly place to be.
As much as I would like to share your vision of more commuting by bike, it is just not safe.
You are being too harsh. Clueless, yes. Dimwits? I have seen some work up to half-wits.
Then there are a few in-house developers who are pretty good - and going to leave. Working in-house almost always degenerates into doing at least some tech support, and that kills developer productivity.
>> Certifications.. do not, in any way, indicate a person's ability to do a particular job.
Exactly correct. I have seen a negative correlation - more certs = less skill. Perhaps my sample size is too small or perhaps those without skill and experience really need to bolster their resumes. Hmmmm.
Slashdot Mirror
And how many people have fish tape, really.
Most of us just use duct tape when we need to repair a fish.
Despite that, it certainly is a particularly aggressive myth, especially in the service industry.
You would think that the tech types around here would understand how marginal rates work, it is a fairly straight-forward math and logic problem.
On a related note, I wonder why software is so buggy?
>>Also the repayment of the debt is a flat rate on all earnings, that increases depending on gross earnings.
That is why rational tax systems don't apply higher rates on all earnings, but only to the next dollar earned. That way, every dollar earned results in more take-home pay.
It is kind of funny that the Australian UNIVERSITY debt system failed both math and logic.
Probably more a reflection on the intelligence of lawmakers than of university types.
>>Of course, if a company doesn't avoid layoffs, those laid off workers find their pay and hours cut a lot more
Correct.
It is a good solution for one company - it will not work at all when applied to all companies.
>>(Hey, most of the last 10% is taxes anyway, right)
Not Right.
The idea that at a certain point, the govt takes most of your earnings in taxes is an urban legend.
For anybody working by the hour, there is no "tipping point" where the govt keeps most of each additional dollar - it is just untrue.
>>If everyone did this (4x9hr days), we could avoid tons of layoffs nationwide.
A company can avoid layoffs by cutting hours and pay.
If everybody at every company had their hours and pay cut, their bills remain the same, so the workers' spendable income after covering expenses is either gone or greatly reduced - You have just created a recession.
>>that's what prototypes, iteration, and capacity planning are for
So, we are in complete agreement that performance is not an end stage activity.
Good!
OH,
So sorry, I thought we were discussing the merits of throwing more hardware at bad code.
I had not realized this was the discussion for the semantics of the word "optimization."
Bitter experience has taught me that performance must start with design optimization, long before code optimization.
Sorry for the snarl, I have been working 6 weeks on "optimizing" a rather critical piece of code where performance was a complete afterthought.
We have managed to speed it up by an order of magnitude, but poor performance is "baked in" to the design at every level, so there is only so much we can do.
If the first time you ever address performance is by "measuring what's slow", then performance was indeed an afterthought - after design, after coding, after testing.
If you only start thinking about performance that late in the game, your design will probably include more than one peformance degrading decision that is just too painful to rewrite.
As a database guy, I would say that:
Database locking issues with a poor design won't be fixed no matter how much hardware you throw at it, it will just lock up faster.
Database structures are one of the first products of development, and many (most) developers just try to model the data without any thought to performance.
The other terrible mistake that many coders make is to process records and fields one at a time instead of using bulk operations.
The old saw about "Premature Optimization is Evil" is false:
Making performance a late afterthought guarantees doom that no amount of hardware can fix.
When it is busy at the post office, they go on break, the line be damned. Employees just wander around behind the counter in full view of the long long lines - there is no urgency at all.
All the big retailers schedule extra help during busy business times. When it is extra busy at any modern store, they call all the employees to the cash registers - even the managers will man the registers when it is busy.
Say what you want about private enterprise, but it is hard to argue that they don't care about taking your money! If the guy down the street is better at taking your money, he will do it and the first guy will improve or go out of business.
With government, there is no guy down the street to push for improvement. It is that simple.
Biking is good. Be more than careful - a few drivers are hostile to sharing the road and most won't notice you. Cut carbohydrate consumption - high carb consumption makes you fat in the middle. Diabetes is an occupational risk for programmers as we get older. Many of the fat programmers my age (50) are diabetic. Another good reason to cut carbohydrates and increase exercise.
You seem sober now, so the Daily Drunkard's Award is reserved for somebody who has earned it today.
Ok that is the drunk version, but I went to all kinds of trainings, and 99% was useless. Just write an app that does .SOMETHING. in language @#$%, then you learn something. Then read a book about it, and you will be better than any certified monkey.
Congratulations! Daily Drunkard's Award for Brilliant Insight
Congratulations on your first project not being a disaster.
The higher-ups know that your boss is not doing the work with his own two hands.
I own a small software company, and had a student / tester guy who I gave a small programming project to. He really put all his best effort into it. He was so proud of his work that he insisted on getting the recognition he deserved.
I gave it to him. He was ignoring his primary job responsibilities, and he spent several times as long as a junior coder would have, and his code was such that we needed to refactor / toss out all his work.
A month later he let me know that since he was going to be graduating from DEVRY soon, he really expected to work full time coding at 4 times the money. What an idiot! Can you guess how this story ends?
Multi geared bikes need lots of trips to the shop, and even then leave you stranded sometimes.
Not a good selling point for bikes.
As you point out, totally reliable bikes are heavy and no fun.
How can you sell the sweat and hassle to people who grew up with Mom driving them 6 blocks to school?
I am a former bike shop rat.
Bikes require a lot more maintenance per mile than a modern car.
"Dutch Bikes" (Omafiets) may be as sturdy as you would hope, but have never been sold here in the US.
We seem to prefer flashier, flimsier, and cheaper rides.
The bikes sold in the US are not good commuter bikes - way too many trips back to the shop.
After 20 years of the slothful sedentary life of a programmer,
I have returned to commuting by bike to get exercise for health reasons.
Dude!
It is a dangerous way to get to work.
Ride too far to the right - and cars push you even further - into parked cars, truck mirrors, sewer grates, and as far as the curb.
Idiots in trucks and SUVs have no idea how wide their right side mirrors are - they WILL hit you.
Drivers simply assume you out of existence and pass much too close.
Assuming a cyclist out of existence does work - do it a few times, and the cyclist ceases to exist.
Ride out further into the lane (the only safe place to ride), and people honk, spit, rev engines as a challenge, and follow along menacing you with their god given power as DRIVERS.
It would take like 2 seconds for a car to pass wide - but many people are just deeply offended and assume (incorrectly) a cyclist has no rights to the road.
Then there are the young punks with horsepower who bully cyclists.
I have been hit with cokes and even a quart of chocolate ice cream by these guys.
The ice cream dang near knocked me down into the road in front of traffic - a deadly place to be.
As much as I would like to share your vision of more commuting by bike, it is just not safe.
>>Most in-house developers are clueless dimwits
You are being too harsh.
Clueless, yes.
Dimwits?
I have seen some work up to half-wits.
Then there are a few in-house developers who are pretty good - and going to leave.
Working in-house almost always degenerates into doing at least some tech support, and that kills developer productivity.
>> Certifications.. do not, in any way, indicate a person's ability to do a particular job.
Exactly correct.
I have seen a negative correlation - more certs = less skill.
Perhaps my sample size is too small or perhaps those without skill and experience really need to bolster their resumes.
Hmmmm.