I agree. I maintain a set of perl scripts for integrating our software, in which I eschew use of the implicit variables ($_, etc) and they are easy for anyone who is newer to the language to pick up. I hope you'll agree the heavy use of the implicit variables can make for a steep uphill climb for the novice. A Perl program which makes no concessions to readability can resemble line noise pretty easily.
I think regexes are a bit harder for most people. I'm not bad at them, but i've had to sit and look at some of them for awhile.
In my mind, simply the 50% above the median. Even in the depths of the dot bomb era, good devs had work. Speaking for myself, my computer background, and I'm middle of the road, has provided a great living for a long time.
most programming languages are human comprehensible... provided you've been trained in them.
Haven't worked in Perl much, have we?
Re:Who Cares What Language, It Reeks of Poor Desig
on
Why COBOL Could Come Back
·
· Score: 2, Informative
Since COBOL doesn't have subroutines or any way to pass parameters save global variables, I would say that is a safe bet.
Actually that is what CICS and other architecture layers are used for. What we like to refer to as a COBOL program is usually a module or piece of a larger system flow. The language doesn't provide robust support for modularization, so various architects developed frameworks to support the need. One of the aspects of that is that many systems are composed of small, fairly simple modules which are passed a communications control record, which is used for inter-module communication. Within each module, you're right, all variables are global, but COBOL modules in these systems tend to be comparable in size to class files in the Java I work with today.
It's possible, and fairly common even, for large COBOL systems to have quite a bit of architecture and structure available. Sure, I like modern stuff better, but it's just ignorant to pretend that modern coding practices emerged in 1997 like a mushroom after the rain.
Try harder. I've been doing this for 30 years. Hypotheticals like you're bringing up fly in the face of the current labor market, where unemployment for developers is less than 4%. If you don't keep your staff happy today, they'll leave. If any of you were in management of a development team, you'd know this. This has been true for good developers for my entire career, so I'm inclined to think it will continue.
I'm not going to defend Apple. If they're breaking the law, they should have their head handed to them, and they probably will. But listening to all these folks whining about how abused they are is making me want to puke. Go work in a Burger King for an afternoon, where you -will- get OT pay, and then come back and tell us you're hurting. Every person responding here is making multiples of the median family income in the US, and would do well to be a little thoughtful about being on the winning side, instead of acting like whiny children who didn't get as much frosting on their piece of cake.
The FLSA and most states have an exemption for managerial and professional jobs. Professional jobs are those which require an extended period of study to attain the skills required. These typically include accounting, medicine, engineering and similar roles. The FLSA doesn't mandate OT pay for programmers.
What they will fire you for is not getting your work done. However, when the rate of unemployment for skilled programmers is hovering around 4%, it's a rare company that is going to get rid of someone who is otherwise productive, just because he won't work 45-50 hours. Contrary to popular belief, employers are not always stupid. What really happens to people that aren't willing to put out at the rate of others on the team is they get passed over for raises and promotions.
At the end of the day, the good programmers don't usually need to work long hours, because they get shit done while they are there. Even at MSFT in the glory days, people who really wanted to manage their work life could generally find a way to do so, and can certainly do so today.
instead on the actual problem, which is that highly skilled people are working over time for nothing
Let's start by convincing me that this is a problem. These highly skilled people are also highly paid. Overtime pay is important, I will assert, because low paid people deserve a fair wage for their time.
A software developer who makes a $90k salary doesn't quite fit the description. $90k is about $45/hour, if you work 40 hour weeks, and about $34 an hour if you average 50 hour weeks. $34 an hour is hardly starvation money. Whether this is a fair wage for their time is a matter of negotiation between the employee and the employer, in my opinion.
The lack of overtime compensation is not forcing people into poverty, and it's not even abuse. It's apparently a condition of the employment at Apple, that some people don't like. Fair enough - find another job that doesn't demand that level of work.
The right way to state this is that highly paid people are being tasked with work that takes more than 40 hours a week. They are complaining about that, and trying to use the government to renegotiate their salary. I suggest that they go move to France, where the government will help them do so. In the US, I'll be surprised if they succeed, because the laws in most states are pretty clear that professional work is generally excluded from requirements for overtime pay. Professional work is usually defined as that which requires a lengthy period of study to attain, such as accounting, medicine, and engineering.
Personally, I am a little disgusted with the whining attitude of the gen x'rs. I have worked hours over my career that make these claims look paltry by comparison. The result, over time, was that I advanced in my career, and made some significant money when our company went public. My parents did the same. My grandfather worked his ass off on a farm, and was dirt poor. The chinese are working their asses off for $50 a month.
If you all want civil service work conditions, go get a job working for the post office, and see how much fun that is. Develoment is hard, and to make a business of it sometimes means stretching your self. Toughen up and grow a sack. Or understand that you are relegating yourself to the group of workers that your managers will look at as being solely interested in what's in it for you, and therefore placing yourself on the list of those to jettison whenever cuts need to be made.
I will gently suggest that there are at least 5 reports of knives traveling through the x-ray on the thread that I've seen so far. I'm one of them, but maybe I'm a random lunatic. This is a non-trivial non-detection rate, even if 50% of the reports are bullshit.
Let's estimate this. If you say that 20,000 people read this thread today, and that the me-too rate (people for whom this is true, but didn't report) is +100% (doubles the reported, verified rate), and that 70% of the population flies, and that a million people a day fly, let's see, that equals(5*.5*2/(20,000*.7)*1,000,000) = 307 people a day who are likely to be getting a knife through airport security.
You have one father-in-law who asserts that it can't be done. I'll bet that it happens at least 100 times a day.
I had a knife go through security undetected in my backpack on 2/20/08, from Seattle to Tucson. Your father-in-law says it can't be done. Who should I believe? Me, who saw it with my own eyes? Or your Dad, who says it can't be done?
Call me a lunatic, but I'm not going with your dad-in-law.
I have carried various pieces of metal through the detectors experimentally for several years now. I can confidently tell you that it is child's play to get a box cutter the likes of what was used in 9/11 through an airport detector today. The only airport that found my red herring was Omaha.
I usually use a golf ball mark repair tool, of which several fairly large versions can be found. They have rather more steel than most small knives. I am also told by a high pierced friend of mine that surgical steel doesn't usually set the detector off.
In what universe is it possible that nobody's ever been given a pay cut, or issued back pay?
In what state, anywhere in the US, Europe, or elsewhere in the world, has a payroll system -ever- had to handle temporarily reduced checks for an entire large workforce, accumulating the difference between the fixed amount and a real owed amount, handling the tax consequences, union contract consequences and benefit consequences, so that one check can be issued now, and another issued later to catch up the amount? What if the benefits deductions are greater than the face amount?
What do you think it would take, for General Electric, or General Motors, or the Post Office, or the Army to implement such a change, in either a legacy system, or the newest Peoplesoft system? Have you ever implemented a new payroll system? Do you realize that it commonly takes a year to configure one and roll one out for a large organization? I guarantee you that this would be catastrophic, regardless of whether the payroll system is old as dirt, or the latest version of Peoplesoft/SAP/Oracle, or one of the payroll services. This is simply not a situation that payroll systems have had to be designed to do.
I have an accounting degree and background, and have implemented 3 payroll/accounting systems over my career. While there is almost certainly grandstanding and politicking going on, the problem is almost certainly not being exaggerated.
Your first problem will be finding 'grep'. Or a command prompt.
COBOL is trivial. It's the mainframe environment that is hard. It's not even that complex. It's just that it's different, the toolsets are literally primitive, and you have few of the productivity aides that you are accustomed to. There is no s/this/that/g.
I'll give $3 to the first person who can explain to me why on Earth you need to edit the software to change people's salary
Because in prior salary changes, you didn't have to remember the old salary, accumulate the difference, and pay that difference back when the budget passes, then restore the salary, then correct the 401(k), insurance, and other withholdings.
Oh, and if there's a math error, you'll get sued. By the Feds.
Oh, and it needs to run in the same batch window as the old system. Without upgrading the hardware, of course, because the budget is frozen.
Changing the salary is, as most people noted, probably relatively trivial. It's the undoing that is a little more complicated.
You have to remember, this system works for the original design specification. The only reason there is a problem is that the fiscal situation dropped a requirements bomb onto the IT organization. This would be a problem if the thing was running on Java/Oracle or whatever your favorite brand of system sugar is.
This is the type of problem known as The Black Swan It's tough to plan for requirements that emanate from a situation never seen before.
Well, if he's older, I can believe it. I have 25 years experience, including with COBOL, recent coding experience in Java, Perl, SQL, and Python, am competent with HTML and CSS, and can't get a sniff for a development role. The 10 years in the middle in management kills a technical career.
And try to do it without having grep at your fingertips. The real issue with COBOL development is that the toolsets have not kept pace with the rest of the world, and no-one who can use Eclipse/NetBeans/IntelliJ wants to feel the pain.
Slashdot Mirror
I agree. I maintain a set of perl scripts for integrating our software, in which I eschew use of the implicit variables ($_, etc) and they are easy for anyone who is newer to the language to pick up. I hope you'll agree the heavy use of the implicit variables can make for a steep uphill climb for the novice. A Perl program which makes no concessions to readability can resemble line noise pretty easily.
I think regexes are a bit harder for most people. I'm not bad at them, but i've had to sit and look at some of them for awhile.
In my mind, simply the 50% above the median. Even in the depths of the dot bomb era, good devs had work. Speaking for myself, my computer background, and I'm middle of the road, has provided a great living for a long time.
Since basically forever. See this
most programming languages are human comprehensible... provided you've been trained in them.
Haven't worked in Perl much, have we?
Since COBOL doesn't have subroutines or any way to pass parameters save global variables, I would say that is a safe bet.
Actually that is what CICS and other architecture layers are used for. What we like to refer to as a COBOL program is usually a module or piece of a larger system flow. The language doesn't provide robust support for modularization, so various architects developed frameworks to support the need. One of the aspects of that is that many systems are composed of small, fairly simple modules which are passed a communications control record, which is used for inter-module communication. Within each module, you're right, all variables are global, but COBOL modules in these systems tend to be comparable in size to class files in the Java I work with today.
It's possible, and fairly common even, for large COBOL systems to have quite a bit of architecture and structure available. Sure, I like modern stuff better, but it's just ignorant to pretend that modern coding practices emerged in 1997 like a mushroom after the rain.
Try harder. I've been doing this for 30 years. Hypotheticals like you're bringing up fly in the face of the current labor market, where unemployment for developers is less than 4%. If you don't keep your staff happy today, they'll leave. If any of you were in management of a development team, you'd know this. This has been true for good developers for my entire career, so I'm inclined to think it will continue.
I'm not going to defend Apple. If they're breaking the law, they should have their head handed to them, and they probably will. But listening to all these folks whining about how abused they are is making me want to puke. Go work in a Burger King for an afternoon, where you -will- get OT pay, and then come back and tell us you're hurting. Every person responding here is making multiples of the median family income in the US, and would do well to be a little thoughtful about being on the winning side, instead of acting like whiny children who didn't get as much frosting on their piece of cake.
And that's fair. If it's the law, Apple should comply with the law. I'll be pretty surprised if Apple isn't in compliance with the law, though.
The FLSA and most states have an exemption for managerial and professional jobs. Professional jobs are those which require an extended period of study to attain the skills required. These typically include accounting, medicine, engineering and similar roles. The FLSA doesn't mandate OT pay for programmers.
What they will fire you for is not getting your work done. However, when the rate of unemployment for skilled programmers is hovering around 4%, it's a rare company that is going to get rid of someone who is otherwise productive, just because he won't work 45-50 hours. Contrary to popular belief, employers are not always stupid. What really happens to people that aren't willing to put out at the rate of others on the team is they get passed over for raises and promotions.
At the end of the day, the good programmers don't usually need to work long hours, because they get shit done while they are there. Even at MSFT in the glory days, people who really wanted to manage their work life could generally find a way to do so, and can certainly do so today.
instead on the actual problem, which is that highly skilled people are working over time for nothing
Let's start by convincing me that this is a problem. These highly skilled people are also highly paid. Overtime pay is important, I will assert, because low paid people deserve a fair wage for their time.
A software developer who makes a $90k salary doesn't quite fit the description. $90k is about $45/hour, if you work 40 hour weeks, and about $34 an hour if you average 50 hour weeks. $34 an hour is hardly starvation money. Whether this is a fair wage for their time is a matter of negotiation between the employee and the employer, in my opinion.
The lack of overtime compensation is not forcing people into poverty, and it's not even abuse. It's apparently a condition of the employment at Apple, that some people don't like. Fair enough - find another job that doesn't demand that level of work.
The right way to state this is that highly paid people are being tasked with work that takes more than 40 hours a week. They are complaining about that, and trying to use the government to renegotiate their salary. I suggest that they go move to France, where the government will help them do so. In the US, I'll be surprised if they succeed, because the laws in most states are pretty clear that professional work is generally excluded from requirements for overtime pay. Professional work is usually defined as that which requires a lengthy period of study to attain, such as accounting, medicine, and engineering.
Personally, I am a little disgusted with the whining attitude of the gen x'rs. I have worked hours over my career that make these claims look paltry by comparison. The result, over time, was that I advanced in my career, and made some significant money when our company went public. My parents did the same. My grandfather worked his ass off on a farm, and was dirt poor. The chinese are working their asses off for $50 a month.
If you all want civil service work conditions, go get a job working for the post office, and see how much fun that is. Develoment is hard, and to make a business of it sometimes means stretching your self. Toughen up and grow a sack. Or understand that you are relegating yourself to the group of workers that your managers will look at as being solely interested in what's in it for you, and therefore placing yourself on the list of those to jettison whenever cuts need to be made.
I will gently suggest that there are at least 5 reports of knives traveling through the x-ray on the thread that I've seen so far. I'm one of them, but maybe I'm a random lunatic. This is a non-trivial non-detection rate, even if 50% of the reports are bullshit.
Let's estimate this. If you say that 20,000 people read this thread today, and that the me-too rate (people for whom this is true, but didn't report) is +100% (doubles the reported, verified rate), and that 70% of the population flies, and that a million people a day fly, let's see, that equals(5*.5*2/(20,000*.7)*1,000,000) = 307 people a day who are likely to be getting a knife through airport security.
You have one father-in-law who asserts that it can't be done. I'll bet that it happens at least 100 times a day.
I had a knife go through security undetected in my backpack on 2/20/08, from Seattle to Tucson. Your father-in-law says it can't be done. Who should I believe? Me, who saw it with my own eyes? Or your Dad, who says it can't be done?
Call me a lunatic, but I'm not going with your dad-in-law.
Oh wait, you did that already... ;-)
Just wait till you're there, son. Men never quit being horny geek-boys. Which I'm currently still OK with.
Now, get off my yard.
And what can we conclude that events like this are relatively common, well known, and still no planes are getting hijacked?
Could it be that no-one is trying to hijack them anymore?
What's worse, theatre or hyperbole?
How about disbelieving evidence when it contradicts your world view?
I have carried various pieces of metal through the detectors experimentally for several years now. I can confidently tell you that it is child's play to get a box cutter the likes of what was used in 9/11 through an airport detector today. The only airport that found my red herring was Omaha.
I usually use a golf ball mark repair tool, of which several fairly large versions can be found. They have rather more steel than most small knives. I am also told by a high pierced friend of mine that surgical steel doesn't usually set the detector off.
Bingo. The best thing they could do is give us back our pocketknives.
Yeah, that's probably fair. I think the sweet spot for getting work in hands on technical work is between about 3 and 8 years of experience.
Wait until you're a parent of a 16 yr old daughter, and all her friends start looking hot to you.
-Must- -not- -stare-...
In what universe is it possible that nobody's ever been given a pay cut, or issued back pay?
In what state, anywhere in the US, Europe, or elsewhere in the world, has a payroll system -ever- had to handle temporarily reduced checks for an entire large workforce, accumulating the difference between the fixed amount and a real owed amount, handling the tax consequences, union contract consequences and benefit consequences, so that one check can be issued now, and another issued later to catch up the amount? What if the benefits deductions are greater than the face amount?
What do you think it would take, for General Electric, or General Motors, or the Post Office, or the Army to implement such a change, in either a legacy system, or the newest Peoplesoft system? Have you ever implemented a new payroll system? Do you realize that it commonly takes a year to configure one and roll one out for a large organization? I guarantee you that this would be catastrophic, regardless of whether the payroll system is old as dirt, or the latest version of Peoplesoft/SAP/Oracle, or one of the payroll services. This is simply not a situation that payroll systems have had to be designed to do.
I have an accounting degree and background, and have implemented 3 payroll/accounting systems over my career. While there is almost certainly grandstanding and politicking going on, the problem is almost certainly not being exaggerated.
Your first problem will be finding 'grep'. Or a command prompt.
COBOL is trivial. It's the mainframe environment that is hard. It's not even that complex. It's just that it's different, the toolsets are literally primitive, and you have few of the productivity aides that you are accustomed to. There is no s/this/that/g.
I'll give $3 to the first person who can explain to me why on Earth you need to edit the software to change people's salary
Because in prior salary changes, you didn't have to remember the old salary, accumulate the difference, and pay that difference back when the budget passes, then restore the salary, then correct the 401(k), insurance, and other withholdings.
Oh, and if there's a math error, you'll get sued. By the Feds.
Oh, and it needs to run in the same batch window as the old system. Without upgrading the hardware, of course, because the budget is frozen.
Changing the salary is, as most people noted, probably relatively trivial. It's the undoing that is a little more complicated.
You have to remember, this system works for the original design specification. The only reason there is a problem is that the fiscal situation dropped a requirements bomb onto the IT organization. This would be a problem if the thing was running on Java/Oracle or whatever your favorite brand of system sugar is.
This is the type of problem known as The Black Swan It's tough to plan for requirements that emanate from a situation never seen before.
I suspect that there is no problem changing the pay rate. the problem is accumulating the back pay, and figuring out the tax implications.
And testing the resulting system before you put it into production, which I would estimate at 40% of the budget.
Well, if he's older, I can believe it. I have 25 years experience, including with COBOL, recent coding experience in Java, Perl, SQL, and Python, am competent with HTML and CSS, and can't get a sniff for a development role. The 10 years in the middle in management kills a technical career.
And try to do it without having grep at your fingertips. The real issue with COBOL development is that the toolsets have not kept pace with the rest of the world, and no-one who can use Eclipse/NetBeans/IntelliJ wants to feel the pain.