Date: Tue, 16 Oct 2007 02:28:36 +0000
Reply-To: toby dunn <tobydunn@HOTMAIL.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: toby dunn <tobydunn@HOTMAIL.COM>
Subject: Re: SAS job levels redux
Content-Type: text/plain; charset="iso-8859-1"
To add to Lou's thoughts, I have a regional upper limit to what I can make. Currently I have pretty much maxed out the amount I can make as a SAS programmer in my area. other compnies have tried to recruite me away and as soon as I state what I currently make they quickly just say thanks be=ut we cant even come close to matching that. What I am left with is Cost Of Living Adjustments every year.
Simple economics ( he he he I actually get to use my Masters in Economics) tells one that there is an upper limit to how much any thing is worth. In our case it is Programming, at some point supply meets demand and we have price. Now we could break this down further and get into first or second stage Hedonic Model and start pricing out what each of the programmer's talents are worth, but even then it will reach an upper limit.
So you want your guys to get more and more money for basically doing the same job better year after year. Okay sounds great on the surface and heck I cant blam you. But realize that as they get better and better at programming there is only so much improvement they will be able to bring to the table year after year. At some point the cost to learn something new will not justify the pay increase.
Now the since they will bring less and less to the table year after year what incentive is there for a company to keep giving them anything above a cost of living increase. Nothing!!!!! So the programmers must bring something that will generate some added benefit to the company to justify the raise. One thing they could do is learn a new language and use that to help improve the business. Another thing is to use their knowledge of SAS programming and business knowledge and move into management. Either way they have to bring some new talent to the table above and beyond SAS
As one of my old Business Profs use to say, "There Aint No Economic Santa Clause"..... Toby Dunn Compromise is like telling a lie, it gets easier and easier. Each compromise you make, that becomes your standard. Perfection doesnt exist, once you reach it, its not perfect anymore. It means something else.> Date: Mon, 15 Oct 2007 20:57:19 -0400> From: lpogodajr292185@COMCAST.NET> Subject: Re: SAS job levels redux> To: SAS-L@LISTSERV.UGA.EDU> > "Wanda Upole" <Wanda_Upole@HGSI.COM> wrote in message> news:OF407504BE.3C21D439-ON85257375.0057CC9B-85257375.005A733D@hgsi.com...> > Has anybody read this?> >> > First of all, I can't imagine a situation where programming output> > is a "commodity." Even if it were, the code, which is often one of> > the deliverables, definitely is not.> > What you can or cannot imagine says more about your imagination than it does> about the actual situation in a particular business or industry. One> "programming output" commonly encountered is payroll - do you really think> that some payroll processing company out there could charge double the going> rate and make it with most companies?> > I work in the clinical trials field. The output generally is a series of> tables, listings, and occasionally graphs. Most of the stuff dealing with> patient safety and disposition is pretty much of a muchness from trial to> trial, to the point where programs can often be copied and tweaked a little> to report on the next trial. Some companies have macro libraries that> produce the standard reports, and there are products for sale or licensing> out there that do much the same thing. And hanging over all of that is> India and China, with scads of programmers able and willing to produce the> same outputs at lower cost, though their costs are rising. The CDISC> standard will further commodify this stuff - as the data inputs get more> standardized, it takes less effort and skill to produce the outputs.> > Efficacy results are a little more fragmented, but even there, different> indications have at least some standard reports. Areas like ADHD, or solid> tumors, or ECG studies, all have their own patterns and more or less> standard tables.> > Most of this stuff can be programmed by people who don't have a lot of> programming experience (anywhere from 6 months to a few years). And in all> of this, there's little to distinguish the tables/listings produced by one> company from those produced by another, and a pharmaceutical company that> thinks your charges too high can easily contract with another firm willing> to produce these outputs at a more or less market determined price.> > Whether or not the program code is one of the deliverables depends on the> policies of the particular firm and/or the stipulations of a given contract.> > > > There is some point at which that price simply will not support a> > > pay increase> >> > You could say that about any job, no matter how high or low. But> > you can see that in the programming world many positions never reach> > that point, by the number of people who leave their jobs to become> > consultants.> > I was an independent consultant for over 10 years. Over that period, I had> a total downtime of a month. I did well - and on a given job, I could> command a rate 3 to 4 times what some of the less experienced consultants I> worked with could get, and in terms of raw dollars, maybe 3 times what the> experienced, permanent employees doing the same type of work were getting.> I got those rates for many of the reasons you've mentioned. But you still> top out as a programmer, and reach a point where if you want to increase> your pay beyond cost of living type increases, you have to do something> more, or something else.> > > > no matter how good a programmer may be, there is a limit to how much> > s/he> > > can produce per unit time> >> > That's possible, but I claim that the limit of the most skilled> > programmers> > is so far above the limit of the lesser skilled as to seem limitless. And> > "seem" is not the same thing as "is".> > > that argument assumes that "productivity" is defined the way you seem to> > be> > using it--as quantity of output. If you define it as, or even consider as> >> > a factor, quality of output and code, then productivity probably is> > limitless.> > Most companies don't care much about the quality of the program code. Too> bad, but that's the way it is. If the stuff runs and doesn't consume too> much in the way of computing resources, they're happy, provided the output> is correct. I'm defining productivity as quantity of output because that's> what my firm gets paid for - so many dollars per table, or listing, or> graph.> > I personally care about the quality of the program code. I can, and have,> randomly taken a program that produces a standard table and rewritten it for> demonstration purposes. The improvement can be dramatic - the log can be> literally 1/100 the size of that produced by the original, and the wall time> 1/10 or less. But is the result any "better"? Will the client pay more for> the table I wrote than they will for the original, simply because the code> is higher quality? In case you have any doubt, the answer is no.> > In terms of programmer time, I generally (not always, but more often than> not) can program a table or dataset in one-third to one-fifth the time it> takes the average programmer in this business. No matter how efficient my> code may be, my productivity as measured by output someone is willing to pay> for, is not limitless and I don't see how it ever could be.> > > > You want to continue doing the same job but want more more money.> >> > No, as I explained before, even experienced programmers are continually> > improving and learning new things.> > I'd say only (not "even") experienced programmers are continually learning> new things - those that don't quickly become obsolete and find they have to> move on to something less demanding. I've been doing this (programming) for> pushing 30 years. If I didn't run the Red Queen's Race I would've been> obsolete at least 25 years ago. And today, no one (not even me) cares about> the stuff I learned back then - it has as much practical day-to-day> consequence as knowing how to chip flint arrowheads.> > > And if by "job" you mean "job title,"> > that's true of many positions--the CEO of a company probably will never> > have a different job in the company, but she would be awfully upset if> > she didn't get a nice raise now and then.> > The CEO is a manager - if you want a manager's perks, you have to become a> manager. The world isn't always fair. But that's not what I meant - it> seemed to me that the original complaint was about the lack of a "technical> track" beyond a certain level - that sounds like "job title" to me. It> would be nice if there were such a track - I'd still be primarily a> programmer, and programming is my first love. I'm explaining why I don't> think one is possible.> > > >> > "Lou" <lpogodajr292185@COMCAST.NET>> > Sent by: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>> > 10/12/2007 08:53 PM> > Please respond to> > "Lou" <lpogodajr292185@COMCAST.NET>> >> >> > To> > SAS-L@LISTSERV.UGA.EDU> > cc> >> > Subject> > Re: SAS job levels redux> >> >> >> >> >> >> > "Wanda Upole" <Wanda_Upole@HGSI.COM> wrote in message> > news:OF5599306C.EAC9FFC9-ON85257372.004F16EF-85257372.0051C913@hgsi.com...> > > Wow, that's an outrageously shortsighted attitude. And from a manager!> > No> > > wonder> > > this is a problem.> > >> > > What will you get for your additional money, you ask? First of all, you> > > get to keep> > > your most productive employees. (What's the attrition rate in your> > group,> > > by the> > > way?)> >> > My attrition rate over the management portion of my career is under> > industry> > averages, especially if we leave out things like an employee leaving> > because> > a spouse's job moves the family too far away for the employee to stay in> > the> > job, or leaving because of the birth of a child, and just consider people> > leaving for more money. For the last 12 months, it's been zero (negative,> > actually, because the programming staff is larger now that it was then,> > and> > no one has left). The people who report to me are generally paid above> > industry averages, and I work aggresively to keep it that way. One of the> > arguments I use with my management to get increases approved is that> > they're> > saving the substantial recruiting fee that will almost inevitably be paid> > if> > someone has to be replaced. If the company splits that potential saving> > with the employee, both the company and the employee will be better off.> > I've been successful at getting people paid more than the salary band> > they're in officially entitle them too, and at getting percentage> > increases> > several times over the official limit set by company policy.> >> > > The best, most experienced programmers are many times more> > > productive> > > than junior people.> >> > I'm well aware of that. I'm one of the most experienced programmers in> > the> > company, and I see daily evidence of the difference experience makes. I've> > seen people of low to mid-level experience struggle for hours to solve a> > problem that an experienced person can solve in minutes. I try to let> > people attempt to solve the problems they run up against, and if it's> > necessary that for me to come up with a solution, I try to show them how> > to> > find the solution so that next time they'll be able to do it on their own.> > I first became a manager because I was a "go to" person, because I could> > handle the more difficult, non-routine tasks, because I saw and solved> > problems that no one else recognized existed, and my managers recognized> > that. I try to recognize it as well.> >> > > They also mentor junior people so that *they* become> > > more> > > productive. Highly skilled programmers can make an entire group better> > > and more> > > productive. Things might get done without them, but they definitely> > will> > > not get done> > > as well or as efficiently.> > >> > > And even the best programmers are continually improving and learning new> > > things.> > > Why shouldn't they advance like everyone else? And "advancing"> > shouldn't> > > have> > > to mean that you stop programming to do something else (managing). Why> > > would> > > you take somebody away from their work because they're good at it?> >> > I have no quarrel with anything you've said above. But there are economic> > realities to consider. Programmers in my department produce outputs for> > customers. As hard as we may try to differentiate ourselves from the> > multitude of other companies providing similar services, for the most part> > our deliverables are pretty much commodities, and the price the company> > can> > get for its product is set by the market. If anything, that price is> > declining now that programming can be done literally anywhere on the> > globe,> > and not all areas are accustomed to pay levels prevalent in the US. There> > is some point at which that price simply will not support a pay increase -> > no matter how good a programmer may be, there is a limit to how much s/he> > can produce per unit time. If costs exceed revenue, no one will have a> > job.> >> > So we come back to my question that you take exception to. You want to> > continue doing the same job but want more more money. What do I (standing> > in for the company as a whole) get for the additional money? If your> > productivity, either directly or indirectly, brings in enough revenue to> > support the additional pay, fine. If it doesn't, we have a problem.> >> > I think that basic set of circumstances applies pretty widely, to> > programmers as much as someone assembling widgets on an assembly line. I> > don't want to take anyone away from work they're good at and like/want to> > do, but if they're not satisfied with the pay that work brings in, then> > they> > have to make a choice. Either learn to be satisfied with that pay level,> > or> > start doing something else. If you're an expert programmer, good at> > handling> > people, like to mentor, continually work at updating your skills and> > learning new things, you're a pretty good candidate for becoming a manager> > (but only if you want to). If what you want is the "fun" part of managing> > -> > the mentoring, the directing of others' activities, organizing the work,> > and> > seeing it through to completion - without the responsibility of assuring> > successes and heading off failures, of measuring results (and apportioning> > rewards and their opposite appropriately), the paperwork drudgery, the> > longer hours, the employee relations, etc., well, rightly or wrongly,> > that's> > not the way things work.> >> > > For some education, start with the links in the e-mails from Alan> > > Churchill and Ronald> > > Fehd. Your employees will thank you.> > >> > >> > >> > >> > > "Lou" <lpogodajr292185@COMCAST.NET>> > > Sent by: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>> > > 10/12/2007 09:40 AM> > > Please respond to> > > "Lou" <lpogodajr292185@COMCAST.NET>> > >> > >> > > To> > > SAS-L@LISTSERV.UGA.EDU> > > cc> > >> > > Subject> > > Re: SAS job levels redux> > >> > >> > >> > >> > >> > >> > > > > From: Wanda_Upole> > > > >> > > > > Our HR department recognizes only 4 levels of SAS programmer.> > > > > (The titles are Programmer I, Programmer II, Programmer III,> > > > > and Principal Programmer, but that's not really important to> > > > > the issue.) The problem is that once a programmer reaches the> > > > > highest level, there is nowhere to go as a programmer. In> > > > > order to be promoted, and move into a higher salary category,> > > > > they have to go into management. The only option to remain a> > > > > programmer and keep increasing your salary seems to be to> > > > > leave the company and become a consultant.> > > > >> > > > > So what I'm asking for is examples of systems where SAS> > > > > programmers have more than 4 job levels, or that allow> > > > > programmers to advance significantly without moving into> > > > > management. I've heard that the federal> > > > > government has a special technical track that allows people> > > > > to increase in grade past the usual management grade without> > > > > becoming managers, but I don't know the details. Are there> > > > > any more examples out there? (I'm> > > > > particularly interested in the biotech/pharmaceutical> > > > > industry, but I'll take what I can get.)> > > >> > >> > > As a programming manager type with a double handful of direct reports, I> > > have to ask - what will I get for the additional money? It sounds like> > > you> > > want to keep doing the same job but get paid more for it. If you can do> > > that beyond what are essentially cost of living increases, let me know> > how> > > it's done - I for one would jump at it, both for myself and for my> > staff.> > >> > > I don't know about becoming a consultant to increase you "salary" - I> > > spent> > > over a decade as a consultant, had a blast, made decent money, but> > didn't> > > get rich at it. You make the big(ger) bucks by forming a company,> > > drumming> > > up business, and hiring other people to do the programming - in other> > > words,> > > by becoming a manager. Haven't been a consultant for 8 or 9 years now,> > > but> > > from what I see, consulting fees today are the same as or less than I> > was> > > making back then.
Climb to the top of the charts! Play Star Shuffle: the word scramble challenge with star power.